Re' Ruby and Python doing it too:
http://stackoverflow.com/questions/7219541/what-is-the-difference-between-semicolons-in-javascript-and-in-python
I don't write in Ruby, but do a tiny bit of Python now and then, so, I can,
to an extend imagine what the difference is. Python would always understand
the end of line as if it was an end of the statement, so, if you consider
the terms of regular expressions it's "hungry", i.e. it'd terminate at
first possibility, rather then wait until all possibilities are exhausted.
ECMAScript, on the contrary, in most cases, will look as far as possible,
unless it can establish a syntax error (however, the example with a return
and a dangling expression after it is the opposite).
To be honest, I don't think there is a big difference, and, in my opinion,
both approaches are bad :) But I also think that infix functions and a
plethora of different kinds of parenthesis are also stupid... so, you will
probably disagree with me :)
ECMAScript-like languages, and, especially AS3 are particularly ill-suited
for running through REPL because the lookahead required to "understand" the
statement may be extremely long (bash or Lisp would be examples of exactly
the opposite, both these languages can parse the input almost on the
character-by-character basis). Lookahead in this case is the number of
characters one needs to read to unambiguously parse the last token being
consumed by the parser. For example:
{ (String.fromCharCode(13).valueOf()) : 13 }
Suppose the last token consumed by the parser was the '{', you then need to
read through to the colon in order to make a decision was it a code block,
or an object literal, the part after the '{' and up to ':' would be the
lookahead. It is also funny that if there was a linebreak before the colon,
and there wasn't a white space after it, something like this:
{ (String.fromCharCode(13).valueOf())
:foo while(true); }
It would not be an object literal! :)
I think that Guido and Matsumoto actually believed that the absence of the
semicolon makes it easier to read or understand the code - this is, in my
opinion, subjective, but a Python'ist would certainly argue that they are.
In terms of parsing (i.e. ease of understanding for computer programs),
certainly, the statements that terminate in semicolon win in Fortran-like
languages (*sigh* would you imagine people do that out of their own will,
to themselves, and they were actually so enthusiastic about doing that?)...
Regardless, I think that dropping or enforcing support for any particular
language feature is probably not within our realm... I'm not even sure how
this would be possible to do, because, with ECMAScript, at least, you have
an address to file a complaint (although, nobody will listen to you, but
you can get the steam off). With Adobe - I don't know... AS3 is,
practically, a non-standard, not even an extension of ECMAScript... there's
no body in Adobe that I know of, that is responsible for how the language
functions... well, the good sides of closed source... In some way, MXMLC
was, de facto, an authority in how AS3 should be spelled, but then the
imminent change in the new compiler... there will be some corner cases
obviously.
So, now that I think of it... wait, how were we going to write a compiler
for the language that... well, in practice, nobody knows what that language
is like! :) Seriously, what if some behavior in MXMLC was not intended, or
a hoax? :) What if you tested it against version X of MXMLC, but the
majority used version Y of MXMLC, where that features used to act
differently? MXMLC mostly follows the ES4 draft, but it is imprecise and
doesn't implement many features.
Besides, there are some truly bizarre choices. For example, the 'new' that
is used with only one literal - new <int>[1, 2, 3]; Of course, it's
understandable, it's because of E4X, which would otherwise be impossible to
distinguish from an XML literal. But, why on earth, if it is known that '<'
and '>' create so much problems use them for something which is not XML?
Using vectors in MXML - again, vectors were added after MXML already
existed, and the ES4 was abandoned...
Will Adobe accept ES5 as the language for the future versions of player? -
who knows, it's, again, not within our realm. I believe that ES5 is even
worse then ES3, but I think that they both are just too bad, so it doesn't
matter that much. The motivation behind this family of languages always was
to make them as dumb as possible, while the history of using them was in
some ironical way a history of a mentally impaired child struggling against
his illness :(
