Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Javascript > FAQ Topic - What is a function statement? (2010-05-24)

Reply
Thread Tools

FAQ Topic - What is a function statement? (2010-05-24)

 
 
John G Harris
Guest
Posts: n/a
 
      05-25-2010
On Mon, 24 May 2010 at 14:14:45, in comp.lang.javascript, Asen Bozhilov
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
 
Reply With Quote
 
 
 
 
Ry Nohryb
Guest
Posts: n/a
 
      05-25-2010
On May 25, 4:49*pm, John G Harris <(E-Mail Removed)> 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: 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.
 
Reply With Quote
 
 
 
 
Garrett Smith
Guest
Posts: n/a
 
      05-25-2010
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.

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.
 
Reply With Quote
 
Dr J R Stockton
Guest
Posts: n/a
 
      05-25-2010
In comp.lang.javascript message <htdar8$46t$(E-Mail Removed)-
september.org>, Mon, 24 May 2010 00:45:43, Garrett Smith
<(E-Mail Removed)> 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)
 
Reply With Quote
 
John G Harris
Guest
Posts: n/a
 
      05-26-2010
On Tue, 25 May 2010 at 09:08:37, in comp.lang.javascript, Ry Nohryb
wrote:
>On May 25, 4:49*pm, John G Harris <(E-Mail Removed)> 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
 
Reply With Quote
 
John G Harris
Guest
Posts: n/a
 
      05-26-2010
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.

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
 
Reply With Quote
 
Ry Nohryb
Guest
Posts: n/a
 
      05-26-2010
On May 26, 5:24*pm, John G Harris <(E-Mail Removed)> 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"

> (...)
>
> 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....bf14d724e82d77
sooo, could you please post a example that proves your (and Garrett's)
point, *please* ?

TIA,
--
Jorge.
 
Reply With Quote
 
Ry Nohryb
Guest
Posts: n/a
 
      05-26-2010
On May 26, 5:36*pm, John G Harris <(E-Mail Removed)> wrote:
>
> 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.
 
Reply With Quote
 
Dmitry A. Soshnikov
Guest
Posts: n/a
 
      05-26-2010
On 26.05.2010 0:22, Richard Cornford wrote:
> Dmitry A. Soshnikov wrote:
>> On 25.05.2010 15:40, Richard Cornford wrote:

> <snip>
>>> There was a proposal to take (strict mode) JS as defined in ES5
>>> and use that to define anything added in later specs. That
>>> avoids the circular problem of needing to understand JS before
>>> being able to study the spec in order to understand JS.

>>
>> Didn't get it, you mean -- "anything added" will be described
>> with JS and all previous algorithm -- as they were?

>
> Yes, that is what I meant.
>


It seems inconsistent, I don't see a big need to split a specification's
algorithms on exactly algorithm descriptions and a real code.

<snip>

>> Now (when I found out what was "ML" meant) it seems odd for me too.
>> If it would have a status of the general algorithmic language,
>> then this is another talk, and I can accept it. But to learn first
>> some functional language to be able to read a technical
>> specification of another language (to implement this language) is
>> (at first glance at least) a very odd proposal.

>
> If the specification is (only) intended for people who are writing
> implementations then defining it in ML is maybe not such a bad idea as
> there is quite a good chance that ML will be familiar to them (from
> their CS education) or they can be expected to be the sorts of people
> who could quickly pick up a new language.


Yes, of course; I also use a pseudo-code to describe some spec's
algorithms, as practice shows, it's even easier to understand for many
JS programmers.

> From the point of view of
> someone wanting to gain a detailed understanding of javascript it would
> not be such a good idea.
>


Yeah, and moreover, besides implementers, the standard is being read by
many other interested programmers. Although, if some language has
intuitive syntax (or e.g. similar for some widely spread or being used
in educational institution), then it can be used as an algorithmic. Many
languages (excluding some esoteric, such as e.g. Brain****) 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.
 
Reply With Quote
 
Garrett Smith
Guest
Posts: n/a
 
      05-26-2010
On 5/26/2010 8:36 AM, John G Harris wrote:
> On Tue, 25 May 2010 at 10:54:31, in comp.lang.javascript, Garrett Smith
> wrote:
>> On 5/25/2010 9:35 AM, Johannes Baagoe wrote:
>>> Garrett Smith :
>>>
>>>> How about:
>>>> | in ECMAScript a FunctionDeclaration is not a Statement; it cannot
>>>> | appear everywhere that a Statement can.
>>>
>>> English is not my mother tongue, but I choke on "everywhere that", plain
>>> "everywhere" would seem to be enough.
>>>
>>> I also fear a logical ambiguity. Does it mean "There is at least one place
>>> in which a Statement can appear and a FunctionDeclaration cannot", or
>>> "Everywhere a Statement can appear, a FunctionDeclaration cannot"?
>>>

>>
>> | in ECMAScript a FunctionDeclaration is not a Statement; there are
>> | places where a Statement may appear and a FunctionDeclaration may not.

> <snip>
>
> Unfortunately, 'may' is a dangerous word to use in a specification or
> similar.
>


Right. Negation of "may" is "must not".

"...where a Statement may appear and a FunctionDeclaration must not."

>
>
> Let's have another go at it :
>
> "in ECMAScript a FunctionDeclaration is not a Statement; there are
> places in a program where a Statement is permitted but a
> FunctionDeclaration is not."


Looks right to me. I'm going to update the entry with that.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
FAQ Topic - What is (function(){ /*...*/ })() ? (2011-02-12) FAQ server Javascript 14 02-13-2011 05:16 PM
OFF TOPIC:Re: C compiler question (I hope this is on topic) jacob navia C Programming 5 05-30-2010 02:22 PM
FAQ Topic - What questions are on-topic for CLJ? (2008-10-16) FAQ server Javascript 1 10-16-2008 12:03 PM
There are no more messages on this topic. All messages in this topic may have expired or been deleted Coach 02 Computer Support 1 03-12-2007 03:44 PM
FAQ topic pointers David Fisher C++ 6 02-03-2004 04:05 AM



Advertisments