FAQ Topic - What is a function statement? (2010-05-24)
in [JavaScript]
|
From: Dmitry A. Soshnikov on 26 May 2010 13:18 On 26.05.2010 0:22, Richard Cornford wrote: > Dmitry A. Soshnikov wrote: >> On 25.05.2010 15:40, Richard Cornford wrote: > <snip> >>> There was a proposal to take (strict mode) JS as defined in ES5 >>> and use that to define anything added in later specs. That >>> avoids the circular problem of needing to understand JS before >>> being able to study the spec in order to understand JS. >> >> Didn't get it, you mean -- "anything added" will be described >> with JS and all previous algorithm -- as they were? > > Yes, that is what I meant. > It seems inconsistent, I don't see a big need to split a specification's algorithms on exactly algorithm descriptions and a real code. <snip> >> Now (when I found out what was "ML" meant) it seems odd for me too. >> If it would have a status of the general algorithmic language, >> then this is another talk, and I can accept it. But to learn first >> some functional language to be able to read a technical >> specification of another language (to implement this language) is >> (at first glance at least) a very odd proposal. > > If the specification is (only) intended for people who are writing > implementations then defining it in ML is maybe not such a bad idea as > there is quite a good chance that ML will be familiar to them (from > their CS education) or they can be expected to be the sorts of people > who could quickly pick up a new language. Yes, of course; I also use a pseudo-code to describe some spec's algorithms, as practice shows, it's even easier to understand for many JS programmers. > From the point of view of > someone wanting to gain a detailed understanding of javascript it would > not be such a good idea. > Yeah, and moreover, besides implementers, the standard is being read by many other interested programmers. Although, if some language has intuitive syntax (or e.g. similar for some widely spread or being used in educational institution), then it can be used as an algorithmic. Many languages (excluding some esoteric, such as e.g. Brainfuck) semantically (and even syntactically) are very similar to each other. Additionally, they can have some own ideological aspects, but in general, if a programmer can understand (usually imperative) algorithms, then he can easily map that algorithms on the language. The only thing, repeat, it is desirable that such language would have a status of a "common algorithmic language". > A specification in ML has some advantages. For one thing, the > specification's code is then effectively an implementation and can > tested by executing it. It is also apparently possible to 'prove' things > about ML code in an automated/algorithmic way. I don't know the details > of this (so don't ask (me)). > Regarding exactly ML, yeah, decoratively (as it is a functional language) an algorithm can be described even better than an imperative algorithm. Just like mathematical combined equations. >> I have some plans about it (will you be a one of my reviewers? ;)). > > Time allowing (at least of a version in English). > Great, I think it worth that all. I'll contact you later (or maybe even a publisher editor will do that, as she do in my case). >> I'm going to collect some my old articles, improve them, to review >> very carefully with some professionals, to add stuff from the ES5 >> and publish it as a book. I had negotiations with publishers >> (thanks to Stoyan Stefanov), some already ready to publish it >> now, but I have to freeze it for some time (have to finish some >> business). So will back a bit later to this plan. >> >>> then it may not be necessary for those seeking >>> understanding to go to the specification, and so much less need >>> for an understandable spec. >> >> No, as addition it worth to read the spec anyway. The stylistics >> of some author -- is one thing, the original spec -- is another, >> it's a good addition. > > Yes, the style of an author in explaining things can be counter > productive. For example, there is a 'popular' book which insist on > calling the Activation/Variable object the "call object", effectively > leaving those who learn from that book possibly talking a different > language from everyone else. > If you mean Flanagan and his book, yes, I know that he used some own alternative terminology (additionally, he provides some other his made-up concepts, e.g. separating Undefined and Null types from the primitive type to the /trivial/ type). But, I talked to him recently, and he said that think that his book is still complex to understand for some programmers. So, I guess, he used such simplified concepts for exactly to make explanation easier. On the one hand, it is a noble idea, and of course, an audience of a book will be higher/wider. From the other hand, such simplifications shouldn't break an accuracy of the information. And that exactly my objective. I won't use that ugly BNF non-terminals of course (and don't use now) in explanations, because think that a good article/book isn't just a verbatim copy-paste from the specification. And at the same time I won't simplify the terminology. The book will be oriented for the limited audience -- already experienced in the JS and in the programming as a whole -- I don't see a sense to write yet another book describing /if-else/ operators. >> and that's without any actions for SEO or somethings (I don't even >> know how to do this). > <snip> > > It (not really) surprising how effective a search engine optimisation is > achieved from properly (semantically) marked-up explanatory text. > Yes, seems so. Dmitry.
From: Garrett Smith on 26 May 2010 14:32 On 5/26/2010 8:36 AM, John G Harris wrote: > On Tue, 25 May 2010 at 10:54:31, in comp.lang.javascript, Garrett Smith > wrote: >> On 5/25/2010 9:35 AM, Johannes Baagoe wrote: >>> Garrett Smith : >>> >>>> How about: >>>> | in ECMAScript a FunctionDeclaration is not a Statement; it cannot >>>> | appear everywhere that a Statement can. >>> >>> English is not my mother tongue, but I choke on "everywhere that", plain >>> "everywhere" would seem to be enough. >>> >>> I also fear a logical ambiguity. Does it mean "There is at least one place >>> in which a Statement can appear and a FunctionDeclaration cannot", or >>> "Everywhere a Statement can appear, a FunctionDeclaration cannot"? >>> >> >> | in ECMAScript a FunctionDeclaration is not a Statement; there are >> | places where a Statement may appear and a FunctionDeclaration may not. > <snip> > > Unfortunately, 'may' is a dangerous word to use in a specification or > similar. > Right. Negation of "may" is "must not". "...where a Statement may appear and a FunctionDeclaration must not." > > > Let's have another go at it : > > "in ECMAScript a FunctionDeclaration is not a Statement; there are > places in a program where a Statement is permitted but a > FunctionDeclaration is not." Looks right to me. I'm going to update the entry with that.
From: Ry Nohryb on 26 May 2010 14:38 On May 26, 8:32 pm, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: > > > "in ECMAScript a FunctionDeclaration is not a Statement; there are > > places in a program where a Statement is permitted but a > > FunctionDeclaration is not." > > Looks right to me. I'm going to update the entry with that. Hurry up! -- Jorge.
From: John G Harris on 26 May 2010 15:44 On Wed, 26 May 2010 at 09:18:14, in comp.lang.javascript, Ry Nohryb wrote: >On May 26, 5:24�pm, John G Harris <j...(a)nospam.demon.co.uk> wrote: >> Gawd, you can't even copy-and-paste accurately! It's Statement, >> singular. > >Either that or that you can't read, Johnny: ES3 specs, page 162: "A.4 >Statements" So you copied this A.4 Statements Statement : and then deleted the second word. Weird. >> Surely you've seen this : >> >> � do Statement while ( Expression ); >> >> Inside a 'do' statement you must put another Statement (exactly one). >> You mustn't put a FunctionDeclaration there. > >You can do it and it's not an error, see: >http://groups.google.com/group/comp.lang.javascript/msg/a8bf14d724e82d77 >sooo, could you please post a example that proves your (and Garrett's) >point, *please* ? You can write anything you like where it says Statement, but whatever it is it's most certainly not an ECMAScript FunctionDeclaration. If the browser or whatever accepts what you write it will then do whatever its unpublished specification says, but it won't call it a FunctionDeclaration because that would be a non-conformance in anything claiming to conform to ECMAScript. John -- John Harris
From: Ry Nohryb on 26 May 2010 16:14
On May 26, 9:44 pm, John G Harris <j...(a)nospam.demon.co.uk> wrote: > On Wed, 26 May 2010 at 09:18:14, in comp.lang.javascript, Ry Nohryb > wrote: > > >On May 26, 5:24 pm, John G Harris <j...(a)nospam.demon.co.uk> wrote: > >> Gawd, you can't even copy-and-paste accurately! It's Statement, > >> singular. > > >Either that or that you can't read, Johnny: ES3 specs, page 162: "A.4 > >Statements" > > So you copied this > > A.4 Statements > Statement : > > and then deleted the second word. Weird. Not weird, it's called to copy-paste the text "A.4 Statements". > >> Surely you've seen this : > > >> do Statement while ( Expression ); > > >> Inside a 'do' statement you must put another Statement (exactly one). > >> You mustn't put a FunctionDeclaration there. > > >You can do it and it's not an error, see: > >http://groups.google.com/group/comp.lang.javascript/msg/a8bf14d724e82d77 > >sooo, could you please post a example that proves your (and Garrett's) > >point, *please* ? > > You can write anything you like where it says Statement, but whatever it > is it's most certainly not an ECMAScript FunctionDeclaration. Q: It looks like a function declaration, walks like a function declaration, and quacks like a function declaration, and the specs *permit* a function declaration there because syntax extensions are permitted, so what ? A: That this FAQ entry is pointless in the way it's worded right now. -- Jorge. |