FAQ Topic - What is a function statement? (2010-05-24)
in [JavaScript]
|
From: Ry Nohryb on 24 May 2010 10:40 On May 24, 9:45 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: > New FAQ Topic idea: > > | What is a FunctionDeclaration? Good idea, but only if not written by you. Leave it for Cornford, *please*. -- Jorge.
From: Dmitry A. Soshnikov on 24 May 2010 10:44 On 24.05.2010 18:07, Richard Cornford wrote: > On May 24, 2:35 pm, Dmitry A. Soshnikov wrote: >> On 24.05.2010 16:44, Ry Nohryb wrote: >>> On May 24, 1:00 am, FAQ server wrote: >>>> -------------------------------------------------------- >>>> FAQ Topic - What is a function statement? >>>> -------------------------------------------------------- >> >>>> The term function statement has been widely and wrongly >>>> used to describe a ` FunctionDeclaration `. This is >>>> misleading because in ECMAScript, a ` FunctionDeclaration >>>> ` cannot appear as a Statement. >> >>> You're misleading, and your screwed-up FAQ too: > <snip> >> Well, all excluding Mozilla are wrong. > > All are right (to the extent that Ry Nohryb observed/demonstrated) > because in every case what they are doing can qualify as an extension > to ECMAScript. Seems I didn't understand/translate correctly Ry Nohryb's description. You mean -- it doesn't matter -- whether it is a function declaration (which is created on entering the context) or a function statement (which the same as function expression and created by the Function constructor is created at code execution), i.e. both of them can be treated as just an allowed extension? > >> Mozilla is right only because of >> section 16 of the ECMA-262-3. >> >> By the way, I have any idea why they didn't standardized Function >> Statements in the 5th edition? > > There was an attempt to move function declarations into the set of > Statements. When I looked at the proposed drafts at the time it was > clear that the work in doing that had hardly been started and what > they had would never work. But that was quite near their proposed > completion date for the new spec so it was probably easier to go back > to what had been there before than to resolve the issues trying to > make them a type of statement was going to bring up. > I see, so maybe it was too hard to update their parsers and the "level of convenience" was recognized as not so high to deal with that. >> That strange phrase from the spec /"ExpressionStatement cannot >> start with the *function* keyword because that might make it >> ambiguous with a FunctionDeclaration"/ is really strange -- >> because how then Mozilla distinguishes FD from FS? Easy I >> guess, by the context of the source code position. For what >> to write it in the spec (including 5th edition), if it is easy >> to distinguish? > > Have you noticed that section 5.1.1 (3rd Ed.) is entitle "Context-Free > Grammars"? It is quite a change to switch from context-free to context > dependent. > Yes, of course, I understand. So, the Mozilla just extended their parser for that. >> And I think for some it would be convenient to >> define functions in the declaration view. > <snip> > > How much difference in 'convenience' would there be? You can evaluate > a function expression conditionally and assign the result to a > variable, so whatever the job is it can be done with existing syntax. > So the difference in convenience is that between writing - x = > function(n){ ... }; - and - function x(n){ ... } -, which doesn't seem > that much. > Well, it's another question. I think there is nothing bad to have such alternative. From the other hand, today I see (e.g. in some Node.js files) that some always use function expressions to define a function (even, if it isn't required) -- yes, making anonymous functions assigning them to variables. Maybe it is already a habit, maybe just for to be consistent (because some module functions in Node.js should be exported as FE's into the special /exports/ object, or to /this/ value as this == exports there), maybe to avoid the fact that FD available before definition in the source code position. But it is. So for them of course there's no convenience/difference in using a function declaration style conditionally, because they always use function expressions. I think it is a matter of taste (if all using conditions are the same and provides the same results). Personally, I don't feel a big need in function statements (and do no use them of course) but just it was interesting for me, why if for Mozilla it was easy to implement it, then why the spec continues to write that it is somehow hard. Yes, a context free grammar can be the answer. Dmitry.
From: Richard Cornford on 24 May 2010 11:31 On May 24, 3:44 pm, Dmitry A. Soshnikov wrote: > On 24.05.2010 18:07, Richard Cornford wrote: >> On May 24, 2:35 pm, Dmitry A. Soshnikov wrote: >>> On 24.05.2010 16:44, Ry Nohryb wrote: >>>> On May 24, 1:00 am, FAQ server wrote: >>>>> -------------------------------------------------------- >>>>> FAQ Topic - What is a function statement? >>>>> -------------------------------------------------------- > >>>>> The term function statement has been widely and wrongly >>>>> used to describe a ` FunctionDeclaration `. This is >>>>> misleading because in ECMAScript, a ` FunctionDeclaration >>>>> ` cannot appear as a Statement. > >>>> You're misleading, and your screwed-up FAQ too: >> <snip> >>> Well, all excluding Mozilla are wrong. > >> All are right (to the extent that Ry Nohryb observed/demonstrated) >> because in every case what they are doing can qualify as an >> extension to ECMAScript. > > Seems I didn't understand/translate correctly Ry Nohryb's > description. You mean -- it doesn't matter -- whether it is > a function declaration (which is created on entering the > context) or a function statement (which the same as function > expression and created by the Function constructor is created > at code execution), i.e. both of them can be treated as just > an allowed extension? Yes, ECMA syntax doesn't allow for either so if they are there they must be extensions. Extensions are allowed so neither can be considered wrong (on the surface, even if IE's treating named function expressions as 'out of context' function declarations, and so potentially producing two function objects, is so unhelpfully odd that it would be better considered a bug than an extension). There has never been any reason for expecting two different ECMAScript implementations to have the same extensions, so there is no reason for expecting the same non-(ECMA)standard syntax to result in the same behaviour in two different environments. (Of course if an environment claims to be JavaScript(tm) compatible in addition to being ECMAScript compatible then it should be reproducing the extensions found in JavaScript(tm)). <snip> >>> That strange phrase from the spec /"ExpressionStatement cannot >>> start with the *function* keyword because that might make it >>> ambiguous with a FunctionDeclaration"/ is really strange -- >>> because how then Mozilla distinguishes FD from FS? Easy I >>> guess, by the context of the source code position. For what >>> to write it in the spec (including 5th edition), if it is easy >>> to distinguish? > >> Have you noticed that section 5.1.1 (3rd Ed.) is entitle >> "Context-Free Grammars"? It is quite a change to switch from >> context-free to context dependent. > > Yes, of course, I understand. So, the Mozilla just extended > their parser for that. Many of the compiling optimisations that are possible are very context related so it is very likely that most (of not all) production javascript compliers are context sensitive in reality, even if the language's specification does not require that. >>> And I think for some it would be convenient to >>> define functions in the declaration view. >> <snip> > >> How much difference in 'convenience' would there be? You can >> evaluate a function expression conditionally and assign >> the result to a variable, so whatever the job is it can be >> done with existing syntax. So the difference in convenience >> is that between writing - x = function(n){ ... }; - and >> - function x(n){ ... } -, which doesn't seem that much. > > Well, it's another question. I think there is nothing bad to > have such alternative. I can see nothing wrong with having the alternative, and we do have that alternative. What we don't have is any guarantee of having that alternative everywhere (which, given we know that the same syntax will be subject to alternative interpretation in some environments, makes the alternative non-viable for non-specialised use) . > From the other hand, today I see (e.g. in some Node.js files) > that some always use function expressions to define a function > (even, if it isn't required) It is a gathering trend, and one I have commented on from time to time. Generally I don't approve of that trend. I think that if a function can be a function declaration then it should be (and the cases when it cannot be one are the special cases), but that probably is a matter of style/taste. > -- yes, making anonymous functions assigning them to > variables. Maybe it is already a habit, maybe just for to be > consistent (because some module functions in Node.js should > be exported as FE's into the special /exports/ object, or to > /this/ value as this == exports there), maybe to avoid the > fact that FD available before definition in the source code > position. But it is. So for them of course there's no > convenience/difference in using a function declaration style > conditionally, because they always use function expressions. > > I think it is a matter of taste (if all using conditions are > the same and provides the same results). Personally, I don't > feel a big need in function statements (and do no use them of > course) but just it was interesting for me, why if for Mozilla > it was easy to implement it, then why the spec continues to > write that it is somehow hard. Yes, a context free grammar can > be the answer. There was a proposal to do the new (then ES4) spec in ML; to have the whole ECMAScript language fully defined in the form of ML code. That could have included a parser and so not be so bound by how ECMAScript is currently defined. I didn't think that was such a great plan as it would have rendered the spec even more esoteric than it already is (and I wasn't buying the argument that those who could not understand the spec could then learn the language from books, given how very bad most javascript books are), but it would have been interesting to see the outcome. Richard.
From: Dmitry A. Soshnikov on 24 May 2010 13:28 On 24.05.2010 19:31, Richard Cornford wrote: > On May 24, 3:44 pm, Dmitry A. Soshnikov wrote: >> On 24.05.2010 18:07, Richard Cornford wrote: >>> On May 24, 2:35 pm, Dmitry A. Soshnikov wrote: >>>> On 24.05.2010 16:44, Ry Nohryb wrote: >>>>> On May 24, 1:00 am, FAQ server wrote: >>>>>> -------------------------------------------------------- >>>>>> FAQ Topic - What is a function statement? >>>>>> -------------------------------------------------------- >> >>>>>> The term function statement has been widely and wrongly >>>>>> used to describe a ` FunctionDeclaration `. This is >>>>>> misleading because in ECMAScript, a ` FunctionDeclaration >>>>>> ` cannot appear as a Statement. >> >>>>> You're misleading, and your screwed-up FAQ too: >>> <snip> >>>> Well, all excluding Mozilla are wrong. >> >>> All are right (to the extent that Ry Nohryb observed/demonstrated) >>> because in every case what they are doing can qualify as an >>> extension to ECMAScript. >> >> Seems I didn't understand/translate correctly Ry Nohryb's >> description. You mean -- it doesn't matter -- whether it is >> a function declaration (which is created on entering the >> context) or a function statement (which the same as function >> expression and created by the Function constructor is created >> at code execution), i.e. both of them can be treated as just >> an allowed extension? > > Yes, ECMA syntax doesn't allow for either so if they are there they > must be extensions. Extensions are allowed so neither can be > considered wrong Yes, it seems quite logical. > (on the surface, even if IE's treating named function > expressions as 'out of context' function declarations, and so > potentially producing two function objects, is so unhelpfully odd that > it would be better considered a bug than an extension). There has > never been any reason for expecting two different ECMAScript > implementations to have the same extensions, so there is no reason for > expecting the same non-(ECMA)standard syntax to result in the same > behaviour in two different environments. (Of course if an environment > claims to be JavaScript(tm) compatible in addition to being ECMAScript > compatible then it should be reproducing the extensions found in > JavaScript(tm)). > Yes, that's true. > <snip> >>>> That strange phrase from the spec /"ExpressionStatement cannot >>>> start with the *function* keyword because that might make it >>>> ambiguous with a FunctionDeclaration"/ is really strange -- >>>> because how then Mozilla distinguishes FD from FS? Easy I >>>> guess, by the context of the source code position. For what >>>> to write it in the spec (including 5th edition), if it is easy >>>> to distinguish? >> >>> Have you noticed that section 5.1.1 (3rd Ed.) is entitle >>> "Context-Free Grammars"? It is quite a change to switch from >>> context-free to context dependent. >> >> Yes, of course, I understand. So, the Mozilla just extended >> their parser for that. > > Many of the compiling optimisations that are possible are very context > related so it is very likely that most (of not all) production > javascript compliers are context sensitive in reality, even if the > language's specification does not require that. > To say precisely we have to analyze the source codes of the implementation; although, it also seems to me logical if some implementation makes optimizations based even on parsing stage. > >> From the other hand, today I see (e.g. in some Node.js files) >> that some always use function expressions to define a function >> (even, if it isn't required) > > It is a gathering trend, and one I have commented on from time to > time. Generally I don't approve of that trend. I think that if a > function can be a function declaration then it should be (and the > cases when it cannot be one are the special cases), but that probably > is a matter of style/taste. > Yes, moreover, the most general purpose of a function expression to be used in an expression, e.g. as an functional argument for some higher-order function (relating e.g to the lambda calculus), and _do not pollute the outer variable object/environment record_. In contrast a function declaration from this position -- is just a casual subroutine for a code reuse and encapsulating/abstracting some actions. But seems, some once have seen that "coolness" can use FE everywhere. Well, they are free to do that, that their choice. The only thing I want, that they understand why do they use it and whether it is really needed to use exactly a function expression. >> -- yes, making anonymous functions assigning them to >> variables. Maybe it is already a habit, maybe just for to be >> consistent (because some module functions in Node.js should >> be exported as FE's into the special /exports/ object, or to >> /this/ value as this == exports there), maybe to avoid the >> fact that FD available before definition in the source code >> position. But it is. So for them of course there's no >> convenience/difference in using a function declaration style >> conditionally, because they always use function expressions. >> >> I think it is a matter of taste (if all using conditions are >> the same and provides the same results). Personally, I don't >> feel a big need in function statements (and do no use them of >> course) but just it was interesting for me, why if for Mozilla >> it was easy to implement it, then why the spec continues to >> write that it is somehow hard. Yes, a context free grammar can >> be the answer. > > There was a proposal to do the new (then ES4) spec in ML; to have the > whole ECMAScript language fully defined in the form of ML code. That > could have included a parser and so not be so bound by how ECMAScript > is currently defined. Yeah, I've heard something about it. Recent mailings also provides some spec described in alternative syntax (lambda JS if I remember correctly). > I didn't think that was such a great plan as it > would have rendered the spec even more esoteric than it already is Depends, we have to see. The idea to describe a spec on the language itself at least deserves attention. Although, it is a bit odd -- we don't know yet a language (we're reading a spec), but already see this language in algorithm descriptions. In general, yes, an abstract algorithmic language (or even just abstract algorithms) is enough for the technical spec for implementers. > (and I wasn't buying the argument that those who could not understand > the spec could then learn the language from books, given how very bad > most javascript books are), but it would have been interesting to see > the outcome. > Recently in ML Douglas Crockford was arguing that a spec should be described that every JS programmer can understand it. That's a noble idea of course, but seems he forgets that a technical spec -- is a technical spec (i.e. a requirements specification), but isn't an interesting literary reading. Although, some (including me) provides the alternative spec description in more human view (i.e. not only dry theoretical algorithms, but also "an interesting literary" descriptions without losing in the accuracy of the spec's info). So don't think that a technical algorithms will be changed to just a just descriptions. The most parts of the spec help to understand how does something work (again -- just an exact algorithm). But at the same time the ECMAScript provides its own abstraction level, and exactly ECMAScript programmers are not required to think about _implementations details_. It could be easier to say them that there is something called as a "variable hoisting" (a thinking out simplified concept to understand the things), rather than, "the handling of the execution context code is divided on two stages: the entering the context and the code execution, and all data (vars, FD, formal parameters) are created at the first stage -- that's why they are available before the definition in the source code position". Yes, it will be interesting to see the outcome, although, we already can see some implementation on JS -- Narcissus -- there all that algorithms are described very interesting on JavaScript. Dmitry.
From: Garrett Smith on 24 May 2010 14:18
On 5/24/2010 5:44 AM, Ry Nohryb wrote: > On May 24, 1:00 am, "FAQ server"<javascr...(a)dotinternet.be> wrote: >> ----------------------------------------------------------------------- >> FAQ Topic - What is a function statement? >> ----------------------------------------------------------------------- >> >> The term function statement has been widely and wrongly used to >> describe a ` FunctionDeclaration `. This is misleading because in >> ECMAScript, a ` FunctionDeclaration ` cannot appear as a Statement. > > You're misleading, and your screwed-up FAQ too: > I think I got what that was intended to mean. > 12.5: The if Statement: Syntax: if ( Expression ) Statement > Now I'm not sure. > javascript: f(); if (0) function f () { alert("Declaration, Smith, DE- > CLA-RA-TION") }; > This is looking like another case of you getting frustrated while trying to explain something that you think you understand, badly. > Safari, Chrome, Opera, IE: "Declaration, Smith, DE-CLA-RA-TION" > Mozillas: TypeError: f is not a function. > That is probably some sort of evidence supporting your personal beliefs about the language. > 12.1 Block: Syntax: { StatementList } > That is the production for Block. [...] [snip more examples] > etc, etc. > >> To add to this confusion, some implementations, notably Mozillas', provide >> a syntax extension called function statement. This is allowed under >> section 16 of ECMA-262, Editions 3 and 5. > > To your confusion, might be. The whole thing, reworded, could end up > being true. But the way you've got it worded now, it isn't. > -- > Jorge. You have communicated well enough that you don't understand what you're arguing about. The problem is not a (just) matter of English; yours is barely comprehensible. No, the problem is that you disrupt discussions with your misunderstanding and irrelevant quips in a childish way. It is a deficit to the discussion and a waste of time. New killfile, entry #1: Jorge Chamorro |