FAQ Topic - What is a function statement? (2010-05-24)
FAQ server
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.
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.
Example of function statement (nonstandard):
// Nonstandard syntax, found in GMail source code. DO NOT USE.
try {
// FunctionDeclaration not allowed in Block.
function Fze(b,a){return b.unselectable=a}
/*...*/
} catch(e) { _DumpException(e) }
Implementations that have the function statement extension process ` Fze `
as a Statement, in order, while other known implementations evaluate
` Fze ` upon entering the execution context that it appears in.
For consistent behavior across implementations, avoid function statement;
use either ` FunctionExpression ` or ` FunctionDeclaration ` instead.
Example of ` FunctionExpression ` (valid):
var Fze;
try {
Fze = function(b,a){return b.unselectable=a};
/*...*/
} catch(e) { _DumpException(e) }
Example of ` FunctionDeclaration ` (valid):
// Program code
function aa(b,a){return b.unselectable=a}
http://jibbering.com/faq/example/functionStatement.html
https://mail.mozilla.org/pipermail/es-discuss/2008-February/005314.html
http://groups.google.com/group/comp.lang.javascript/msg/aa9a32d0c6ae0342
http://groups.google.com/group/comp.lang.javascript/msg/3987eac87ad27966
http://nanto.asablo.jp/blog/2005/12/10/172622
(Article in Japanese)
The complete comp.lang.javascript FAQ is at
http://jibbering.com/faq/
--
The sendings of these daily posts are proficiently hosted
by http://www.pair.com.
kangax
> -----------------------------------------------------------------------
> 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.
> 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.
MDC, unfortunately, doesn't describe Mozilla's function statements very
well, so I did it in NFE article, for anyone interested �
<http://yura.thinkweb2.com/named-function-expressions/#function-statements>
Curiously, older Safari (<=3.0.4) and some versions of Blackberry
browser implement function statements identically to Mozilla's extension.
[...]
--
kangax
Thomas 'PointedEars' Lahn
> On 5/23/10 7:00 PM, 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.
>> 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.
>
> MDC, unfortunately, doesn't describe Mozilla's function statements very
> well, so ...
... you should edit it.
PointedEars
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)
Garrett Smith
> -----------------------------------------------------------------------
> FAQ Topic - What is a function statement?
> -----------------------------------------------------------------------
>
> The term function statement has been widely and wrongly used to
> describe a ` FunctionDeclaration `.
New FAQ Topic idea:
| What is a FunctionDeclaration?
?
Dmitry A. Soshnikov
> On 5/23/10 7:00 PM, 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.
>> 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.
>
> MDC, unfortunately, doesn't describe Mozilla's function statements very
> well, so I did it in NFE article, for anyone interested �
> <http://yura.thinkweb2.com/named-function-expressions/#function-statements>
>
>
Yep, as addition an appropriate section from my article:
<http://dmitrysoshnikov.com/ecmascript/chapter-5-functions/#feature-of-named-function-expression-nfe>
with all consequences for some SpiderMonkey versions:
<http://dmitrysoshnikov.com/ecmascript/chapter-5-functions/#nfe-and-spidermonkey>
and JScript:
<http://dmitrysoshnikov.com/ecmascript/chapter-5-functions/#nfe-and-jscript>
Dmitry.
Dmitry A. Soshnikov
There should be described the general points of this type of
functions:
<http://dmitrysoshnikov.com/ecmascript/chapter-5-functions/#function-
declaration>
To avoid some technical terms (because this is a FAQ, but not a deep
article), it can be described as:
This is a function which:
- always has a name;
- is created before the code execution;
- available for an execution via its name before and after its
definition in the source code position (in contrast see <link
FunctionExpression />);
- can appear in the source code position directly either at /Program/
level or in the FunctionBody of another function (in any other
position FunctionDeclaration cannot appear, i.e. it is impossible to
define it in the expression or statement position; in contrast see
some implementations extension <link FunctionStatement />).
P.S.: in addition, it is a bit ugly to use BNF non-terminals such as
<FunctionStatement> and other. They are related only with lexical
grammar lexers/parsers, but not with human reading. I prefer a
<Function Expression> instead.
Dmitry.
Ry Nohryb
> -----------------------------------------------------------------------
> 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:
12.5: The if Statement: Syntax: if ( Expression ) Statement
javascript: f(); if (0) function f () { alert("Declaration, Smith, DE-
CLA-RA-TION") };
Safari, Chrome, Opera, IE: "Declaration, Smith, DE-CLA-RA-TION"
Mozillas: TypeError: f is not a function.
12.1 Block: Syntax: { StatementList }
javascript: { f(); function f () { alert("Declaration, Smith, DE-CLA-
RA-TION") }; }
Safari, Chrome, Opera, IE: "Declaration, Smith, DE-CLA-RA-TION"
Mozillas: TypeError: f is not a function.
12.6 Iteration Statements: Syntax: do Statement while(Expression);
javascript: f(); do function f () { alert("Declaration, Smith, DE-CLA-
RA-TION") } while (0);
Safari, Chrome, Opera, IE: "Declaration, Smith, DE-CLA-RA-TION"
Mozillas: TypeError: f is not a function.
12.6 Iteration Statements: Syntax: while ( Expression ) Statement
javascript: f(); while (0) function f () { alert("Declaration, Smith,
DE-CLA-RA-TION") };
Safari, Chrome, Opera, IE: "Declaration, Smith, DE-CLA-RA-TION"
Mozillas: TypeError: f is not a function.
12.6 Iteration Statements: Syntax: for (Expression; Expression ;
Expression) Statement
javascript: f(); for (;false;) function f () { alert("Declaration,
Smith, DE-CLA-RA-TION") }
Safari, Chrome, Opera, IE: "Declaration, Smith, DE-CLA-RA-TION"
Mozillas: TypeError: f is not a function.
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.
Dmitry A. Soshnikov
Well, all excluding Mozilla are wrong. 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?
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? And I think for some it would be
convenient to define functions in the declaration view.
Such dynamically created (on condition at runtime) functions (exactly in
declaration view I mean) there are even in PHP.
Dmitry.
Richard Cornford
> On 24.05.2010 16:44, Ry Nohryb wrote:
>>> --------------------------------------------------------
>>> FAQ Topic - What is a function statement?
>>> --------------------------------------------------------
>
>>> 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:
> 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.
> 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.
> 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.
> 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.
Richard.
Ry Nohryb
wrote:
> On 24.05.2010 16:44, Ry Nohryb wrote:
> > On May 24, 1:00 am, "FAQ server"<javascr...@dotinternet.be> wrote:
>
> >> 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:
>
> > 12.5: The if Statement: Syntax: if ( Expression ) Statement
>
> > javascript: f(); if (0) function f () { alert("Declaration, Smith, DE-
> > CLA-RA-TION") };
>
> > Safari, Chrome, Opera, IE: "Declaration, Smith, DE-CLA-RA-TION"
> > Mozillas: TypeError: f is not a function.
>
>
> > etc, etc.
>
> Well, all excluding Mozilla are wrong.
No, no one but Smith is wrong : his statement is obviously false: "in
ECMAScript, a ` FunctionDeclaration ` cannot appear as a Statement" is
FALSE.
> Mozilla is right only because of section 16 of the ECMA-262-3.
All of them are fully compliant.
--
Jorge.
Ry Nohryb
> New FAQ Topic idea:
>
> | What is a FunctionDeclaration?
Good idea, but only if not written by you. Leave it for Cornford,
*please*.
--
Jorge.
Dmitry A. Soshnikov
> 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.
Richard Cornford
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.
Dmitry A. Soshnikov
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.
Garrett Smith
> On May 24, 1:00 am, "FAQ server"<javascr...@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
Garrett Smith
> On May 24, 3:35 pm, "Dmitry A. Soshnikov"<dmitry.soshni...@gmail.com>
> wrote:
>> On 24.05.2010 16:44, Ry Nohryb wrote:
>>> On May 24, 1:00 am, "FAQ server"<javascr...@dotinternet.be> wrote:
>>
>>>> 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:
>>
>>> 12.5: The if Statement: Syntax: if ( Expression ) Statement
>>
>>> javascript: f(); if (0) function f () { alert("Declaration, Smith, DE-
>>> CLA-RA-TION") };
>>
>>> Safari, Chrome, Opera, IE: "Declaration, Smith, DE-CLA-RA-TION"
>>> Mozillas: TypeError: f is not a function.
>>
>>> (...)
>>
>>> etc, etc.
>>
>> Well, all excluding Mozilla are wrong.
>
> No, no one but Smith is wrong : his statement is obviously false: "in
> ECMAScript, a ` FunctionDeclaration ` cannot appear as a Statement" is
> FALSE.
>
No, no one but Jorge Chamorro is wrong (and only apparently now that an
actual claim was made).
A Statement cannot begin with "function". Any implementation that allows
for such production is providing a syntax extension.
>> Mozilla is right only because of section 16 of the ECMA-262-3.
>
> All of them are fully compliant.
Providing a syntax extension is not a conformance violation.
John G Harris
wrote:
<snip>
>No, no one but Smith is wrong : his statement is obviously false: "in
>ECMAScript, a ` FunctionDeclaration ` cannot appear as a Statement" is
>FALSE.
<snip>
If he changed it slightly to
"in ECMAScript a FunctionDeclaration cannot appear everywhere that a
Statement can appear."
then it would be completely accurate and true.
John
--
John Harris
kangax
> On May 24, 2:35 pm, Dmitry A. Soshnikov wrote:
[...]
>> 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.
The difference in convenience becomes more apparent once we "zoom out"
from `x = function(){}` vs `function x(){}` comparison.
Take a look at something like `addListener` abstraction, and one of the
possible ways to implement it. As you're well aware of, forking function
definition based on certain condition is an extremely common scenario
when it comes to cross-browser scripting:
var addListener, docEl = document.documentElement;
if (isHostMethod(docEl, 'addEvenListener')) {
addListener = function () {
/* ... */
};
}
else if (isHostMethod(docEl, 'attachEvent')) {
addListener = function (){
/* ... */
};
}
Specifics aside, what we're dealing with here is this:
var addListener;
if (/* ... */) {
addListener = function () { };
}
else if (/* ... */) {
addListener = function () { };
}
The inconvenience in this case is that we need to first define
`addListener` variable before assigning function object to it.
Knowing how variable declaration works in ECMAScript (i.e. that
`addListener` is "hoisted"), we could shorten this version like this:
if (/* ... */) {
var addListener = function () { };
}
else if (/* ... */) {
addListener = function () { };
}
- but this just has too much chance of looking like a mistake (or
confuse reader of the code), and is a pattern I would rather stay away from.
The benefit of function statements becomes even more apparent once we
bring the subject of function identifiers into a picture. To aid in
debugging/profiling (IIRC, you found this argument bogus last time I've
heard :)), `addListener` could be given an identifier like so:
var addListener;
if (/* ... */) {
addListener = function addListener() { };
}
else if (/* ... */) {
addListener = function addListener() { };
}
I personally know libraries that follow such pattern (their authors are
also well aware of NFE bugs in IE).
Note that some of the NFE issues are "worked around" here by using same
identifiers for variable (to assign function to) and actual function.
Now, if we were to utilize function statements in a previous example,
the snippet becomes rather elegant:
if (/* ... */) {
function addListener() { }
}
else if (/* ... */) {
function addListener() { }
}
I've seen another pattern, like this:
function addListener() { /* ... */}
if (/* ... */) {
addListener = function () { /* ... */ }
}
- but it only solves the identifiers problem partially.
And on a related note, implementations that extend function objects with
"name" property (such as Mozilla) usually populate that property with
identifier of a function during its declaration.
var f = function g(){};
f.name; // "g"
function h(){}
h.name; // "h"
In those implementations there's an added cost of not having "proper"
`name` value (if that matters, for whatever reason) when using
expressions instead of declarations.
All in all, I don't particularly find function statements to be an
amazing boon, but I can see how they are useful; I would take them any
day if not for complete uselessness in context of general web, where
backwards compatibility issues would probably render them to be more of
a danger than a convenience.
I'm curious how committee is going to handle these issues, as "block
functions" appear to be scheduled for ES harmony, and are already on the
list of proposals (not just in strawman section) :) �
<http://wiki.ecmascript.org/doku.php?id=harmony:proposals>
--
kangax
Garrett Smith
How about:
| in ECMAScript a FunctionDeclaration is not a Statement; it cannot
| appear everywhere that a Statement can.
Asen Bozhilov
> By the way, I have any idea why they didn't standardized Function
> Statements in the 5th edition?
>
> 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? And I think for some it would be
> convenient to define functions in the declaration view.
FunctionStatement does not provide any syntactical differences with
FD. But provides differences during instantiation stage. Function
Declarations are instated on entering on execution context, but
Function Statements during evaluation of the statement in which they
are defined. That provides a confusion in the readers of the code. For
example:
if (true) {
function F(){
//...
}
}
else {
function F(){
//...
}
}
F();
Which function will be invoked? Yes, you know the answer, but that
example can be extended and code in these statement can be increased.
When you read the code you will be need to see parent statement to
catch that function is actually FS. That break readability of the code
and does not provide any benefits comparing with FunctionExpression
there can be assigned reference on variable. Actually if I modify that
example to use FunctionExpression the readability problem is gone away
and I think maintaining is better.
var F;
if (true) {
F = function () {
//...
}
}
else {
F = function () {
//...
}
}
When I need FunctionStatement behavior I always use
FunctionExpression. That I do for readability and for unexpected
behavior which can be provided by extension on the language. These
extensions can be treat in different way in different
implementations.
Garrett Smith
> Dmitry A. Soshnikov wrote:
>
>> By the way, I have any idea why they didn't standardized Function
>> Statements in the 5th edition?
>>
Brendan's comments in the es-discuss message linked from the entry
indicate that time was the matter.
> var F;
> if (true) {
> F = function () {
> //...
> }
> }
> else {
> F = function () {
> //...
> }
> }
>
[...]
That approach is used for function rewriting. The idea is to create a
function gets the correct function, performing the test of which
function to get in scope of the outer function. I like this pattern,
which Richard has coined the "Russian Doll".
With function rewriting, conditional tests are performed on an as-needed
basis. If that function is never called, the feature tests are not
performed. The practical implication is a function that may or may not
be called. For example, the developer cannot be certain that the user
will click on a button which triggers an event handler that he has coded.
There are variations, but they basically boil down to something that
resembles the following:
myModule.meth = meth ;
function meth (obj, type) {
var meth;
cond = typeof document.createDesktopApplication != "undefined";
if(cond) {
meth = function(obj, type){ /*...*/ };
} else {
meth = function(obj, type){ /*...*/ };
}
(myModule.meth = meth)(obj, type);
}
Caveat: if `meth` nested function makes a `this` reference, it will not
be `myModule` but global object or, in ES5, null.
Garrett Smith
> On 5/23/10 7:00 PM, 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.
>> 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.
>
> MDC, unfortunately, doesn't describe Mozilla's function statements very
> well, so I did it in NFE article, for anyone interested �
> <http://yura.thinkweb2.com/named-function-expressions/#function-statements>
>
I've linked the article from the "what is (function{/*...*/})" entry and
from the FAQ notes It's a great article and everybody should read it.
Would it be redundant to link to it again from this entry? The
"Functions" section has no main text. Perhaps the link could go there,
provided something were written as a main entry for that section.
> Curiously, older Safari (<=3.0.4) and some versions of Blackberry
> browser implement function statements identically to Mozilla's extension.
>
Interesting. Maybe Safari changed to match IE so they could get badly
authored IE-only sites working.
Dmitry A. Soshnikov
Yes, I do. As the whole explanation above. But maybe your description
will be useful for those who will be read this and don't know about it.
> but that
> example can be extended and code in these statement can be increased.
> When you read the code you will be need to see parent statement to
> catch that function is actually FS. That break readability of the code
> and does not provide any benefits comparing with FunctionExpression
> there can be assigned reference on variable. Actually if I modify that
> example to use FunctionExpression the readability problem is gone away
> and I think maintaining is better.
>
> var F;
> if (true) {
> F = function () {
> //...
> }
> }
> else {
> F = function () {
> //...
> }
> }
>
I think this is mostly relates to your habit. If it would obviously
defined in the spec (even without mentioning a separate function type),
but saying some small note e.g. "if FD appears a statement position,
then it is created during the code execution". And that's all -- you
have already another habit and it is convenient and readable for you.
You don't even think that it is something strange.
> When I need FunctionStatement behavior I always use
> FunctionExpression.
Of course you do, because if you program for the web, you (most likely)
program cross-browsing. If you program only for particular
implementation -- why just not to use all the additional features and
sugar provided by the implementation? It is convenient. I used all the
stuff -- let, array extras (even they weren't standardized yet -- I
didn't think about it, I just used them) array comprehensions,
__noSuchMethod__, etc programming one project only for Gecko
implementation and was happy. I could also use function statements, but
I don't remember that I did. Why? Don't know, maybe also just a habit to
function expression for that.
> That I do for readability and for unexpected
> behavior which can be provided by extension on the language.These
> extensions can be treat in different way in different
> implementations.
The current situation with "unexpected behavior" (which actually is
expected, since we know the results in all major and minor
implementations) is well known and goes without saying.
Dmitry.
Dmitry A. Soshnikov
> On 5/24/2010 2:14 PM, Asen Bozhilov wrote:
>> Dmitry A. Soshnikov wrote:
>>
>>> By the way, I have any idea why they didn't standardized Function
>>> Statements in the 5th edition?
>>>
>
> Brendan's comments in the es-discuss message linked from the entry
> indicate that time was the matter.
>
In that reply in ML he said just some common phrase. That there were
some more important things to do and that IE already has done some
logical bugs (yes, they are, even if Brendan doubted how should FS be
treated -- logically, by a conditional control flow it should be treated
as Gecko treats, but not the IE of course). Anyway, as I said, I don't
feel a big need in such functions (because already have a habit to use a
FE in this case), but that just was interesting why if for Mozilla it
was easy, then why the spec says that it is hard to distinguish (and the
answer is simple -- they just used their own lexer/parser implementation).
<snip>
>
> There are variations, but they basically boil down to something that
> resembles the following:
>
> myModule.meth = meth ;
>
> function meth (obj, type) {
> var meth;
> cond = typeof document.createDesktopApplication != "undefined";
> if(cond) {
> meth = function(obj, type){ /*...*/ };
> } else {
> meth = function(obj, type){ /*...*/ };
> }
> (myModule.meth = meth)(obj, type);
> }
>
Yes, the pattern is known, but why do you use a separate `meth` function
of the global context, and additionally `meth` method of the `myModule`?
And after the `meth` function ends, it still the same, because used
local var `meth` and it assigned to the method `meth`. Why no to do
directly on `myModule.meth` all this implementation? Just an abstract
example, I guess or there is something logical in it?
Dmitry.
Ry Nohryb
wrote:
> (...) If it would obviously
> defined in the spec (even without mentioning a separate function type),
> but saying some small note e.g. "if FD appears a statement position,
No that's not all: saying that would not be correct.
--
Jorge.
Dmitry A. Soshnikov
Just skip it, it was an abstract small note (no more). I know that it's
not all. But it doesn't matter in the case. What _is_ essential, is my
phrase to Asen, that if it would _somehow_ (do you see this word?
somehow -- that means -- we concentrate on something else, this
"somehow" isn't essential at the moment) standardized, then maybe it
wouldn't be something strange for him ;)
Dmitry.
Ry Nohryb
>
> You have communicated well enough that you don't understand what you're
> arguing about.
Aha, so you still don't get it. (unbelievable)
> 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.
No matter how much more fluent your English is nor how much better
your manners are for your rather limited comprehension ability drives
you invariably to botched conclusions, e.g. the statements in this FAQ
entry.
> New killfile, entry #1: Jorge Chamorro
Oh, Smith, you are breaking my heart.
I think someday I'm going to publish another, different, up-to-date,
much improved *official* cljs FAQ, one that you can't screw up. With
daily and weekly posts here and all. Yeah. Open to edit for ~anyone
with a clue, except you, of course, because of the "with a clue"
clause.
--
Jorge.
Ry Nohryb
Ok. Sorry.
--
Jorge.
Richard Cornford
Looking at implementat6ion source code is always an option, but the
odds are you will end up finding out that one does one thing and
another does another, so there aren't many generalisations to be made
from that source.
> although, it also seems to me logical if some implementation
> makes optimizations based even on parsing stage.
Yes, I didn't mean to imply that only compilation would be context
sensitive.
>>> 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.
Where the test for understanding would be their ability to explain why
the 'choices' were made (which pre-supposes that there was a choice
and that the code observed is no just the result of reproducing the
code of others without (fully) understanding it).
<snip>
>> 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).
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.
>> 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.
I am fairly sure we will not be seeing an ECMAScript specification
expressed in terms of ML (in my lifetime at least).
> 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.
Yes, that is the circular problem I mentioned above.
> In general, yes, an abstract algorithmic language (or even just
> abstract algorithms) is enough for the technical spec for
> implementers.
Which brings us back to the context free grammars, which work for
specifications but do impose limitations on how things can be
expressed and so do make introducing a FunctionStatement a lot more
complex then simply handling a FunctionDeclaration differently
depending on context.
>> (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
(that would be a 'mailing list' ML, not a 'metalanguage' ML <URL:
http://en.wikipedia.org/wiki/ML_(programming_language) >)
> Douglas Crockford was arguing that a spec should be
> described that every JS programmer can understand it.
That is one of the things that worried me about the proposal to do the
spec in ML; that learning another programming language as a
prerequisite for understanding the spec is a little much to ask of the
average (and especially javascript) programmer.
> 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.
It shouldn't be too difficult for someone capable of (reasonably)
logical thought processes (which is pretty much necessary for an
effective programmer) and sufficiently familiar with the language in
which the text is written to eventually understand a technical
specification in detail. However, there are lots of things that could
be done (at minimum in terms of additional text explanation (of the
algorithms and their implications)) that could speed that process up.
Previous ECMA 262 versions have not been that easy to approach for a
newcomer, so there is plenty of room for improvement without asking
the result to come anywhere near 'an interesting literary read'.
Of course if there were any really decent (and in depth) books on
javascript then it may not be necessary for those seeking
understanding to go to the specification, and so much less need for an
understandable spec.
> Although, some (including me) provides the alternative spec
> description in more human view ...
<snip>
Javascript learning form the web suffers from two things; 1. There is
a mass of bogus information and very poor advice available on the web
(as there is less standing in the way of its publication than standing
in the way of bad books on the subject). 2. Almost any (Google, etc.)
search on the subject of javascript will be swamped in hits from pages
that contain NOSCRIPT elements declaring that "this page works best
with javascript enabled" (or the like).
It is nice that there are good resources available, but newcomers are
going to be hard pressed to tell the good from the bad.
> 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".
The name of the thing ("variable hoisting" in this case) is of limited
use without knowing what that thing does (or how it works), so the
explanation still needs to be somewhere.
> 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.
Javascript implementations written in javascript raise some
interesting questions. Narcissus uses javascript regular expressions
to implement its regular expressions. Take that to its extreme and
Narcissus stops existing, and you run the code it would be executing
in Narcissus is the javascript engine that would otherwise be running
Narcissus. Go the other way and insist that Narcissus provide an
implementation for everything (regular expressions, primitives,
representations of IEEE double precision numbers, math operations on
those reprehensions, etc., etc.) and you are asking more of that
implementation than of any other.
Richard.
Richard Cornford
So at this point the possibilities are that - addListener - is either
undefined or it is a native function.
> The inconvenience in this case is that we need to first
> define `addListener` variable before assigning function
> object to it.
Don't actually need to if the destination of - addListener - is as a
property of the global object as an assignment to an undeclared
Identifier is going to do that. But it is still a good idea to declare
it.
> Knowing how variable declaration works in ECMAScript (i.e.
> that `addListener` is "hoisted"), we could shorten this
> version like this:
>
> if (/* ... */) {
> var addListener = function () { };}
>
> else if (/* ... */) {
> addListener = function () { };
>
> }
>
> - but this just has too much chance of looking like a
> mistake (or confuse reader of the code),
Yes, let's not do that.
> and is a pattern I would rather stay away from.
>
> The benefit of function statements becomes even more apparent
> once we bring the subject of function identifiers into a
> picture. To aid in debugging/profiling (IIRC, you found this
> argument bogus last time I've heard :)),
> `addListener` could be given an identifier like so:
>
> var addListener;
> if (/* ... */) {
> addListener = function addListener() { };}
>
> else if (/* ... */) {
> addListener = function addListener() { };
>
> }
>
> I personally know libraries that follow such pattern (their
> authors are also well aware of NFE bugs in IE).
Now the possible values for - addListener - are undefined or a native
function, except in JScript, where the undefined option no longer
exists. (Granted that won't matter much in this case as presumably one
branch of a listener attaching method will use IE's available
facilities, but I mention it as a comment on the 'pattern' (and the
understanding NFE bugs claimed by those employing it; the results are
now environment dependent.
> Note that some of the NFE issues are "worked around" here by
> using same identifiers for variable (to assign function to)
> and actual function.
Some perhaps, but not all.
> Now, if we were to utilize function statements in a previous
> example, the snippet becomes rather elegant:
I am always suspicious of "elegant" as a justification for code
authoring style.
> if (/* ... */) {
> function addListener() { }}
>
> else if (/* ... */) {
> function addListener() { }
>
> }
Now at this point the possibilities are that - addListener - is a
native function, or it has never been declared. This modifies the
possibilities for verifying the viability of adding listeners in the
environment. The undefined or native function discrimination can be
made in several ways, the simplest of which is type-conversion to
boolean. The 'never declared' or native function discrimination is
going to require of - typeof - test or a try-catch to avoid the
exception that would be thrown at an attempt to read the undeclared
Identifier's value.
> I've seen another pattern, like this:
>
> function addListener() { /* ... */}
> if (/* ... */) {
> addListener = function () { /* ... */ }
>
> }
>
> - but it only solves the identifiers problem partially.
It also disregards the possibility that the environment odes not
provide either of the possible options, denying the possibility of
planned clean degradation.
> And on a related note, implementations that extend function objects with
> "name" property (such as Mozilla) usually populate that property with
> identifier of a function during its declaration.
>
> var f = function g(){};
> f.name; // "g"
>
> function h(){}
> h.name; // "h"
>
> In those implementations there's an added cost of not having
> "proper" `name` value (if that matters, for whatever reason)
> when using expressions instead of declarations.
As function - name - properties are non-standard and not universally
supported that could only be a consideration for specialised contexts.
> All in all, I don't particularly find function statements to
> be an amazing boon, but I can see how they are useful;
I don't mind whether they exist or not.
> I would
> take them any day if not for complete uselessness in context
> of general web, where backwards compatibility issues
Backwards compatibility? Isn't the behaviour in 'current' browser
inconsistent enough to introduce 'issues'?
> would probably render them to be more of a danger than a
> convenience.
Yes, they are not of general use at the moment, and will probably stay
like that for some time to come.
> I'm curious how committee is going to handle these issues,
> as "block functions" appear to be scheduled for ES harmony,
> and are already on the list of proposals (not just in
> strawman section) :)
> <http://wiki.ecmascript.org/doku.php?id=harmony:proposals>
It will be interesting to see. While claiming JavaScript(tm)
compatibility, environments that did implement Function Statements
have tended to switched to handling their declarations more in the way
JScript does (presumably out of expedience) so going back the other
way may not be popular (even without considering Microsoft's influence
on the question).
Ricahrd.
Dmitry A. Soshnikov
Yep, I hope so.
> <snip>
>>> 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).
>
> 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? Or I didn't understand
correctly? In other case (if no), how if all the spec is described with
the languages itself (strict, not-strict, doesn't matter much) can avoid
circular problem?
>
>> 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.
>
> Yes, that is the circular problem I mentioned above.
>
Yeah, but I didn't get the solving of this issue mentioned above.
>> In general, yes, an abstract algorithmic language (or even just
>> abstract algorithms) is enough for the technical spec for
>> implementers.
>
> Which brings us back to the context free grammars, which work for
> specifications but do impose limitations on how things can be
> expressed and so do make introducing a FunctionStatement a lot more
> complex then simply handling a FunctionDeclaration differently
> depending on context.
>
Yes, true.
>>> (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
>
> (that would be a 'mailing list' ML, not a 'metalanguage' ML<URL:
> http://en.wikipedia.org/wiki/ML_(programming_language)>)
>
Woops, sorry for confusing; yes, I meant "mailing list" where you meant
"metalanguage".
>> Douglas Crockford was arguing that a spec should be
>> described that every JS programmer can understand it.
>
> That is one of the things that worried me about the proposal to do the
> spec in ML; that learning another programming language as a
> prerequisite for understanding the spec is a little much to ask of the
> average (and especially javascript) programmer.
>
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.
>> 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.
>
> It shouldn't be too difficult for someone capable of (reasonably)
> logical thought processes (which is pretty much necessary for an
> effective programmer) and sufficiently familiar with the language in
> which the text is written to eventually understand a technical
> specification in detail.
Yes of course, a more-less qualified programmer should understand that
technical algorithms. Another question, that exactly JS programmer is
free from knowing implementation level terminology and aspects, because
he has a right to think in abstractions provided by the JS. From the
other hand, what provides/defines that abstractions? It should be some
documentation of the technology. And the specification is a good
candidate for that documentation.
> However, there are lots of things that could
> be done (at minimum in terms of additional text explanation (of the
> algorithms and their implications)) that could speed that process up.
> Previous ECMA 262 versions have not been that easy to approach for a
> newcomer, so there is plenty of room for improvement without asking
> the result to come anywhere near 'an interesting literary read'.
>
Yes, only if it won't turned out into the literary book, but not the
technical spec.
> Of course if there were any really decent (and in depth) books on
> javascript
I have some plans about it (will you be a one of my reviewers? ;)). 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.
>> Although, some (including me) provides the alternative spec
>> description in more human view ...
> <snip>
>
> Javascript learning form the web suffers from two things; 1. There is
> a mass of bogus information and very poor advice available on the web
> (as there is less standing in the way of its publication than standing
> in the way of bad books on the subject). 2. Almost any (Google, etc.)
> search on the subject of javascript will be swamped in hits from pages
> that contain NOSCRIPT elements declaring that "this page works best
> with javascript enabled" (or the like).
>
Yes, unfortunately. From the other hand to publish knowledge in the blog
is more "alive", i.e. if there are some errs in the book -- they are
static until errata or the new edition. In the blog we always can keep
info up-to-date.
Hm.. google.ru for the "ecmascript" requests gives my blog on the second
place :P and that's without any actions for SEO or somethings (I don't
even know how to do this).
> It is nice that there are good resources available, but newcomers are
> going to be hard pressed to tell the good from the bad.
That's can be fixed.
>> 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".
>
> The name of the thing ("variable hoisting" in this case) is of limited
> use without knowing what that thing does (or how it works), so the
> explanation still needs to be somewhere.
Yes, I said so (recently reviewing one book). Of course, for
understanding (abstractly, in the mind) some thinking out concepts (as
that "variable hoisting") can be used. The only thing is required --
that such thinking out concepts do not confuse even more. But to
completely clarify the things the spec can help.
Dmitry.
John G Harris
wrote:
Also completely accurate and true, and better.
John
--
John Harris
John G Harris
wrote:
<snip>
>FunctionStatement does not provide any syntactical differences with
>FD. But provides differences during instantiation stage. Function
>Declarations are instated on entering on execution context, but
>Function Statements during evaluation of the statement in which they
>are defined.
<snip>
Which definition of FunctionStatement are you using? Definition A, which
hasn't been published; or definition B, which also hasn't been
published?
When a term has no single published definition you need to say what you
mean. Otherwise you are guaranteed to be wrong by somebody's definition.
John
--
John Harris
Ry Nohryb
> On Mon, 24 May 2010 at 13:33:59, in comp.lang.javascript, Garrett Smith
>
> >| in ECMAScript a FunctionDeclaration is not a Statement; it cannot
> >| appear everywhere that a Statement can.
>
> Also completely accurate and true, and better.
If you mean a statement, as in : A.4 Statements: Block
VariableStatement EmptyStatement ExpressionStatement IfStatement
IterationStatement ContinueStatement BreakStatement ReturnStatement
WithStatement LabelledStatement SwitchStatement ThrowStatement
TryStatement,
I'm not sure. What would be an example ? A piece of code with a spot
in which you could put any statement but not a function declaration ?
--
Jorge.
Johannes Baagoe
> 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"?
--
Johannes
Garrett Smith
| in ECMAScript a FunctionDeclaration is not a Statement; there are
| places where a Statement may appear and a FunctionDeclaration may not.
It might be acceptible to use just that and drop the first part of the
sentence it was in.
| The term "function statement" has been widely and wrongly used to
| describe a FunctionDeclaration. This is misleading because in
| ECMAScript, a FunctionDeclaration is not a Statement; there are
| places where a Statement may appear and a FunctionDeclaration may not.
|
| To add to this confusion, some implementations, including Mozillas',
| provide a syntax extension called function statement. This is allowed
| under section 16 of ECMA-262, Editions 3 and 5.
I changed "notably Mozillas'" to "including Mozillas'" to indicate that
there are others, without having to spell out a list of blackberry,
Safari versions, etc. The point is that "function statement" doesn't
mean what most think it means; function statement is a syntax extension
and best avoided by using either FunctionDeclaration or FunctionExpression.
Richard Cornford
> On 25.05.2010 15:40, Richard Cornford wrote:
<snip>
>> 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.
> Or I didn't understand correctly? In other case (if no), how
> if all the spec is described with the languages itself
> (strict, not-strict, doesn't matter much) can avoid circular
> problem?
That alternative would not solve the circular problem, and would
probably be pretty useless.
<snip>
>>> Recently in ML
>>
>> (that would be a 'mailing list' ML, not a 'metalanguage' ML
>> <URL: http://en.wikipedia.org/wiki/ML_(programming_language) >)
>
> Woops, sorry for confusing; yes, I meant "mailing list" where
> you meant "metalanguage".
>
>>> Douglas Crockford was arguing that a spec should be
>>> described that every JS programmer can understand it.
>>
>> That is one of the things that worried me about the proposal to do
>> the spec in ML; that learning another programming language as a
>> prerequisite for understanding the spec is a little much to ask
>> of the average (and especially javascript) programmer.
>
> 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. From the point of view of
someone wanting to gain a detailed understanding of javascript it would
not be such a good idea.
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)).
>>> 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.
>>
>> It shouldn't be too difficult for someone capable of (reasonably)
>> logical thought processes (which is pretty much necessary for an
>> effective programmer) and sufficiently familiar with the language
>> in which the text is written to eventually understand a technical
>> specification in detail.
>
> Yes of course, a more-less qualified programmer should understand
> that technical algorithms. Another question, that exactly JS
> programmer is free from knowing implementation level terminology
> and aspects, because he has a right to think in abstractions
> provided by the JS. From the other hand, what provides/defines
> that abstractions? It should be some documentation of the
> technology. And the specification is a good candidate for that
> documentation.
Yes, it remains to be seen how the transition form ES3 terminology to
ES5 terminology (where they differ) works out.
<snip>
>> Of course if there were any really decent (and in depth) books on
>> javascript
>
> I have some plans about it (will you be a one of my reviewers? ;)).
Time allowing (at least of a version in English).
> 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.
<snip>
> Hm.. google.ru for the "ecmascript" requests gives my blog on
> the second place :P
Yes, but the absolute beginner is interested in learning 'JavaScript'
and has not yet found out what ECMAScript is.
> 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.
Richard.
Dr J R Stockton
september.org>, Mon, 24 May 2010 00:45:43, Garrett Smith
<dhtmlk...@gmail.com> posted:
>On 5/23/2010 4:00 PM, FAQ server wrote:
>> -----------------------------------------------------------------------
>> FAQ Topic - What is a function statement?
That is not a Frequently Asked Question; nothing like it.
>New FAQ Topic idea:
>
>| What is a FunctionDeclaration?
Likewise.
If you want to write pedantic tutorial material, or a Glossary and/or
Interpretation for ECMA 262, then you should do it on a Web site of your
own, or bury it among the Notes.
--
(c) John Stockton, nr London UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Proper <= 4-line sig. separator as above, a line exactly "-- " (RFCs 5536/7)
Do not Mail News to me. Before a reply, quote with ">" or "> " (RFCs 5536/7)
John G Harris
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.
Unfortunately, 'may' is a dangerous word to use in a specification or
similar.
You may not walk on the grass
meaning it is forbidden.
It may not rain today
meaning it is a possibility.
I first saw this in a hardware interface spec which said
At this time, parity may not be correct.
Guess which meaning was intended :-)
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."
John
--
John Harris
John G Harris
wrote:
>On May 25, 4:49�pm, John G Harris <j...@nospam.demon.co.uk> wrote:
>> On Mon, 24 May 2010 at 13:33:59, in comp.lang.javascript, Garrett Smith
>>
>> >How about:
>> >| in ECMAScript a FunctionDeclaration is not a Statement; it cannot
>> >| appear everywhere that a Statement can.
>>
>> Also completely accurate and true, and better.
>
>If you mean a statement, as in : A.4 Statements:
Gawd, you can't even copy-and-paste accurately! It's Statement,
singular.
>Block
>VariableStatement EmptyStatement ExpressionStatement IfStatement
>IterationStatement ContinueStatement BreakStatement ReturnStatement
>WithStatement LabelledStatement SwitchStatement ThrowStatement
>TryStatement,
>
>I'm not sure. What would be an example ? A piece of code with a spot
>in which you could put any statement but not a function declaration ?
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.
John
--
John Harris
Ry Nohryb
>
> 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"
> (...)
>
> 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* ?
TIA,
--
Jorge.
Ry Nohryb
>
> 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."
Keep trying.
--
Jorge.
Dmitry A. Soshnikov
> 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.
Garrett Smith
> 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.
Ry Nohryb
>
> > "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.
John G Harris
wrote:
>On May 26, 5:24�pm, John G Harris <j...@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
Ry Nohryb
> 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...@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.
John G Harris
wrote:
<snip>
>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.
You need to be accurate : ECMAScript permits extensions, but it's only a
Function Declaration if you say it is.
As you do say it is, you have to require it to be processed the way that
ECMA 262 requires Function Declarations to be processed. That is, the
declaration is processed *before* the code surrounding it is executed.
As a result, the function is declared unconditionally. Even if the
declaration is inside an if, while, or for statement the declaration is
always actioned even if code execution never passes through the
declaration text.
As Function Declarations are actioned unconditionally it is completely
pointless to hide them inside any kind of Statement. It is worth while
pointing this out to beginners.
You have demonstrated that this is what IE and a few others do. You have
also demonstrated that Mozilla is incompatible. It is worth while
warning beginners of this : they can't predict how their code is going
to behave if they use this extension.
John
--
John Harris