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

[Dmitry A. Soshnikov]

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,

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]

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).

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]

(...) 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 (...)

No that's not all: saying that would not be correct.

 

[Dmitry A. Soshnikov]

No that's not all: saying that would not be correct.

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.

 

[Ry Nohryb]

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

Ok. Sorry.

 

[Richard Cornford]

To say precisely we have to analyze the source codes of the
implementation;

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.

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).

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.

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.

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]

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 () { };

}

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]

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.


Yes, I didn't mean to imply that only compilation would be context
sensitive.


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).

Yep, I hope so.

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?

Yes, that is the circular problem I mentioned above.

Yeah, but I didn't get the solving of this issue mentioned above.

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.

(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".

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.

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.

<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 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 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]

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.

John

 

[John G Harris]

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

 

[Ry Nohryb]

On Mon, 24 May 2010 at 13:33:59, in comp.lang.javascript, Garrett Smith


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 ?

 

[Garrett Smith]

Garrett Smith :


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.

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]
september.org>, Mon, 24 May 2010 00:45:43, Garrett Smith

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.

 

[John G Harris]

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 G Harris]

| 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

 

[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,

 

[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.

 

[Dmitry A. Soshnikov]

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.

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.

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).

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.

<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]

<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.