Re: Automatic Semicolon Insertion: value vs cost; predictability and control; alternatives
On 17/04/2011, at 19:44, Dmitry A. Soshnikov wrote: (...) Since usually, a programmer puts a one logical sentences per line -- *for what* you need additional statement/expression termination besides the new line itself? The useless actions in this case can be compared with masochism. (...) AFAIK, the parser is mostly 'greedy' and keeps parsing and skipping over \n trying to compose the longest sentence that makes sense. This is a feature (IMO) that allows us to break complex/longish statements/expressions onto several lines, for better readability, a feature I wouldn't want to ditch by making \n a statement/expression terminator, except, perhaps, in some very few special situations. -- Jorge. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Automatic Semicolon Insertion: value vs cost; predictability and control; alternatives
- there is no rule-of-thumb understanding (programmers
have to look up or memorize all restricted productions,
Here is a quibble: there is a rule, or set of rules
.. Not quite as bad as you wrote.
Sorry, I didn't notice that my attempted summary could be
read as dramatizing the issue!-) The issue is overheated enough,
my intention was merely to be concise in giving an impression
of where I see the issues.
The bigger problem is not the rule-space but the mixed
significance and insignificance of line terminators.
..
.. The line terminator having
selective meaning due to ASI as an error correction procedure,
and of course in restricted productions, creates an expectation
that line terminators matter in general.
However, going down that road leads to CoffeeScript, or
(somewhat more conservatively due to the use of : at end
of head forms, and a lot older) Python. It's a steep slippery slope.
I was trying to point out that CoffeeScript, Python, Ruby, ..
all have subtly different systems, which in turn differ from
Haskell's system, and others in that space. It is not useful
to throw them into a single pigeon hole. The remainder
or your reply shows that you are aware of that, so I am
surprised that you start with this misleading statement!-)
It may be useful to look at the individual features of these
different systems, not to make Python/CoffeeScript/Haskell
coders feel at home, but to select a combination that fits
Javascript, and Javascript coders' expectations. And finally
stops getting in the way of Javascript language designers.
Good points. The keystroke tax with ; and {} in JS is an issue.
It is a tax at the margin on all effort creating and maintaining
source, though, so I expect over time lower-tax syntaxes to
win. The trick is migrating JS code into a new standardized
edition without creating new runtime errors by failing to
catch migration errors.
Understood.
Reformulating the spec could be done but we would need
to keep the ES5 or classic ASI spec around. Spec
complexity and the opportunity cost of the work to increase
it in this area will hurt -- probably a lot.
Anyway, we'd need a more complete strawman spec to
evaluate, to get further.
Since this is likely material for ES/next/next, and the proposal
deadline for ES/next seems to be near, I'll focus on the callback
nesting issue first.
However, it would be useful to have a Javascript implementation
of a Javascript parser and unparser (precisely reproducing the
source). Then one could prototype such syntax modifications
as source-to-source translators, perhaps even testing whether
a rewrite changes parse-followed-by-unparse results.
There are lots of parsers, and some pretty-printers, but I'd like
it to be in Javascript (rather than in Haskell;-), so that some of
you are likely to use it, and it needs to work for me on Windows.
Or would you be happy if I used one of the Haskell libs for JS?-)
And blog posts seem to be more about trouble with ASI
than about usefulness of ASI [2,4,5].
Beware negativity and confirmation biases here.
If did my references correctly, those posts were explanatory,
in the direction: you cannot avoid ASI, so you better understand
how it works.
ASI is relied on by tons of content, without complaints (or
praise). It goes without notice when it works, which is often
when a ; was left off where the formal grammar requires it.
Very likely. Coders may not even be aware when they rely
on ASI.
So ASI as it stands in Javascript
now does not only make life harder for programmers but
for spec writers (and readers), too.
The spec didn't change, so we are riding on that sunk cost.
I wasn't referring to the ASI spec. When browsing the list
archives, I noticed that discussions of syntax tend to drift
into parser issues, and sometimes, when contributors have
almost settled on a suggestion, out of nowhere comes an
ASI issue (if we split this over two lines, it is going to be
ambiguous). Or simple operator proposals such as modulo
operators have to consider restricted productions.
My impression was that ASI concerns are hampering
language development, because ASI doesn't operate
separately - it is entwined with the grammar.
It's easy to exaggerate here, but it seems to me the big
deal is not ASI costs already sunk. Rather it is how to
lighten the syntax and make ASI more usable, in a new
edition.
Agreed. I just wanted to point out that ASI costs are ongoing.
What we could use is some validated alternative that has
no runtime migration error gotchas.
But even if the alternative has a nice specification, how to
validate that it doesn't ruin people's coding patterns without
knowing what those coding patterns are?
HSI would need some tweaking to be suitable for Javascript
coding styles (though some tweaks could be copied from
Haskell, I just omitted them to bring out the core ideas).
I think your effort developing a draft spec would be great.
Good to know.
Re: Automatic Semicolon Insertion: value vs cost; predictability and control; alternatives
On Apr 17, 2011, at 6:07 PM, Garrett Smith wrote: On 4/17/11, Brendan Eich bren...@mozilla.com wrote: On Apr 17, 2011, at 10:52 AM, Claus Reinke wrote: [TLDR] ASI is not going to be removed. I don't know why you think it could be. Why not? Iif developers would stop doing that then eventually, can't it be removed? Define eventually. We can't remove 'with' from ES5 + reality JS on any definite schedule. Developers are not a unitary audience with the same time horizons. Much JS on the web is unmaintained. It may or may not replaced for years or decades. This is all kind of beside the point. We cannot remove 'with' or ASI from ES5 + reality, not-opted-into-Harmony JS as specified by ECMA-262 in any edition in sight. Let's rediscuss when we can. Until then it's a waste of time. This is not to say it can't or won't happen. It may but it could take longer than you care to wait. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Automatic Semicolon Insertion: value vs cost; predictability and control; alternatives
On Apr 17, 2011, at 6:44 PM, Dmitry A. Soshnikov wrote: The question is not that it's hard or not. IMO an explicit semicolon is really a syntactic noise in the language. In goes to the early era of C/Pascal, etc. No, much earlier. Algol 60 used semicolons as separators (not terminators), IIRC. IMO, the semicolon should be inserted only when there is ambiguous syntactic construction, or, e.g. when you want to put more than one sentence in one line. foo() bar() is *not* subject to ASI right now. It is plausibly a deletion bug of some kind. In my experience it would be a mistake to error-correct it without the hint of bar() coming on a later line from foo(), which is what ES1-5.1 all specify. Changing a future edition to allow this, i.e., to insert ; as an error correction, could be done. It would be a relaxation of the syntax rules. But I do not think it's a good idea, and it does not help to address the negative space effect ASI creates, where users expect newline to be significant. It doesn't address the restricted production problem either. The primary use-case there is return am_i_overlong_and_the_return_value_or_a_later_expr_stmt(); /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Automatic Semicolon Insertion: value vs cost; predictability and control; alternatives
On Apr 18, 2011, at 1:45 AM, Claus Reinke wrote: The bigger problem is not the rule-space but the mixed significance and insignificance of line terminators. .. .. The line terminator having selective meaning due to ASI as an error correction procedure, and of course in restricted productions, creates an expectation that line terminators matter in general. However, going down that road leads to CoffeeScript, or (somewhat more conservatively due to the use of : at end of head forms, and a lot older) Python. It's a steep slippery slope. I was trying to point out that CoffeeScript, Python, Ruby, .. all have subtly different systems, which in turn differ from Haskell's system, and others in that space. No, your original post mentioned none of CoffeeScript, Python, or Ruby. You mentioned only Haskell. It is not useful to throw them into a single pigeon hole. I certainly did not throw Haskell into a single pigeonhole with CoffeeScript or Python. And my reply does not contain the word Ruby at all! I do group CoffeeScript and Python together, while acknowledging their differences (please, no pedantic nit-picking on this point). They both have in common indentation-based block (or similar control or body) structure, with significant newlines. The remainder or your reply shows that you are aware of that, so I am surprised that you start with this misleading statement!-) What was misleading? You injected Ruby and implied I put Haskell in the same category as CoffeeScript, Python and Ruby, cited above. It seems to me the shoe is on the other foot. Grump! However, it would be useful to have a Javascript implementation of a Javascript parser and unparser (precisely reproducing the source). Then one could prototype such syntax modifications as source-to-source translators, perhaps even testing whether a rewrite changes parse-followed-by-unparse results. There are lots of parsers, and some pretty-printers, but I'd like it to be in Javascript (rather than in Haskell;-), so that some of you are likely to use it, and it needs to work for me on Windows. Or would you be happy if I used one of the Haskell libs for JS?-) Narcissus is actively developed, Tachyon is another metacircular VM (we are joining forces between these two), there are more than a few others out there. But they all lack the bottom-up grammar validation (modulo classic-ASI) that we need to be sure we're not just having fun hacking, with insufficient tests. And blog posts seem to be more about trouble with ASI than about usefulness of ASI [2,4,5]. Beware negativity and confirmation biases here. If did my references correctly, those posts were explanatory, in the direction: you cannot avoid ASI, so you better understand how it works. That's fine, but this you better understand [ASI] conclusion is a change from what you wrote previously. Your entire paragraph was: It is interesting that even the ES5 spec has no convincing ASI examples, only clarifying examples (7.9.2). And blog posts seem to be more about trouble with ASI than about usefulness of ASI [2,4,5]. So ASI as it stands in Javascript now does not only make life harder for programmers but for spec writers (and readers), too. and I replied objecting to the conclusion from negatively biased blog posts that ASI makes life harder. It also makes life easier but there are no blog posts to cite. ASI is relied on by tons of content, without complaints (or praise). It goes without notice when it works, which is often when a ; was left off where the formal grammar requires it. Very likely. Coders may not even be aware when they rely on ASI. My point, which seems to override your ASI as it stands ... [makes] life harder for programmers [and] spec writers. ASI makes some things easier (reduces costs of constructing JS programs quickly, or in a preferred ;-free style) and it makes other things harder. We can agree on this at least. Is ASI a net loss across history and all developers? I doubt it, but it would be great to improve -- I have no doubt that it is not the last, best solution of its kind. Still, ASI will be hard to get rid of, and a new system would need to interoperate within the spec and implementations, and in developers' minds. I wasn't referring to the ASI spec. When browsing the list archives, I noticed that discussions of syntax tend to drift into parser issues, and sometimes, when contributors have almost settled on a suggestion, out of nowhere comes an ASI issue (if we split this over two lines, it is going to be ambiguous). Yes, that's true. Or simple operator proposals such as modulo operators have to consider restricted productions. Indeed, although it's questionable how many identifier-named infix operators we want to add. My impression was that ASI concerns are hampering language development, because ASI doesn't operate separately - it is entwined with the grammar. Language
Automatic Semicolon Insertion: value vs cost; predictability and control; alternatives
The idea of ASI seems to be to reduce syntactic clutter, possibly
making programs more readable, which is a laudable goal. But
if the reduction in symbol noise comes at the cost of a rise in
complexity of error-prone interpretation, that actually reduces
readability. And few things frustrate programmers more than
not being able to predict or control what happens to their code
(subjectively, not objectively: preferably without detailed spec).
That is by no means a new problem [2,3], but a solution seems
hard to come by, as summarized by Brendan in [3]:
Just the emotion around ASI makes me want to reach for
greater clarity and (if possible) improvements down the line.
But yeah, it's low priority and the risk for reward looks high.
Javascript is not the only language with some form of semicolon
insertion, and programmer satisfaction with this feature seems
to vary widely across languages, suggesting that implementations
of ASI differ as well.
These differences are important - experiences with related, but
different features in different languages should inform, not bias
discussion of ASI in Javascript. and different tools that achieve
similar goals might offer additional design options.
So, I thought it might be helpful to contrast Javascript's approach
with one that does not seem to stir up so much negative emotion.
// Javascript semicolon insertion (ASI)
There are several aspects of Javascript ASI that I find worrying:
- ASI is triggered by linebreaks
- ASI depends on error correction
- ASI depends on restricted productions
Taken together, this reduces both predictability of and control
over semicolon insertion:
- there is no rule-of-thumb understanding (programmers
have to look up or memorize all restricted productions,
and notice all errors in their code, to the extent that both
of these control ASI; if they miss an error that triggers
ASI, the code they are looking at is not the same code
that the JS implementation sees, hindering debugging)
- there is little programmer control (programmers can add
linebreaks, but that alone isn't sufficient; only combining
linebreaks with restricted productions or correctable
errors will result in ASI; programmers sometimes add
linebreaks, not knowing that or when this will invoke
ASI, assuming that linebreaks are just whitespace;
programmers sometimes omit semicolons, erroneously
assuming that ASI will fix it)
[Btw, it would be great if one could write something like
/*OPTIONS: warn-ASI */ and get parser warnings whenever
ASI kicks in (during development). It might be useful for ES
to standardize the idea of such pragmas (passing hints and
options to tools, in source comments), since they are already
in use (eg, jslint).]
// Haskell semicolon insertion (HSI)
For comparison, if we take Haskell's semicolon insertion (HSI),
and throw out all the special cases not needed for Javascript,
the rules are simple, predictable, and fully under programmer
control (rather than grammar author control):
1 semicolon insertion happens for syntax involving blocks
(always preceded by some keyword):
keyword { .. ; .. ; .. }
2 if the opening brace following such a keyword is
omitted, the start-column of the next token establishes
a baseline for automatic semicolon/end brace insertion
3 following lines beginning with a non-white token that is
- indented more: continue the preceding statement
- indented equally: start a new statement in the block
- indented less: end the block
That is it. HSI has the following useful properties:
- if programmers use a construct that uses braces and
semicolons, they don't have to look in the grammar
for details, they know that HSI will be possible (1)
- if programmers do not want HSI, all they need to do
is make their braces and semicolons explicit (2);
(HSI will not insert additional semicolons if all
braces are explicit)
- programmers can use linebreaks to clean up their code;
the _combination_ of linebreak and relative indentation
(more/equal/less) of the next line controls HSI (3)
- only omitted braces and indentation control HSI (2,3);
in particular, semicolons are not inserted to correct
errors, and HSI behaves uniformly for all blocks and
all kinds of statement (again, no need to consult the
grammar for restricted productions)
- since semicolon insertion is controlled by indentation,
not error correction, it does not limit grammar design
(no new ambiguities due to interaction with HSI)
The differences between the two approaches to semicolon
insertion are substantial (programmer control/systematic
predictability vs grammar author control/memorization
of special cases and attempted error correction).
When I first encountered HSI, I wrote all my {;} explicitly,
because it was always presented as a layout rule and I
Re: Automatic Semicolon Insertion: value vs cost; predictability and control; alternatives
On Apr 17, 2011, at 10:52 AM, Claus Reinke wrote:
- there is no rule-of-thumb understanding (programmers
have to look up or memorize all restricted productions,
Here is a quibble: there is a rule, or set of rules enumerated by restricted
productions.
So indeed, viewed production by production, there are too many rules to
memorize, whether concrete or abstracted only a little bit (e.g., *either*
break or continue with label is restricted to have [no LineTerminator here]
between the keyword and the label).
However, one can abstract further by thinking about all the goto-like forms
being restricted (continue, break, return, and for unclear reasons since the
expression is not optional, throw).
This does not cover postfix ++/--, so two rules. Not quite as bad as you wrote.
The bigger problem is not the rule-space but the mixed significance and
insignificance of line terminators.
What we observe is that programmers come to expect ASI where there is no ASI.
So, e.g.,
foo
(bar, baz);
involves no ASI (no error to correct, no restricted production), but it looks
like two statements. The line terminator having selective meaning due to ASI as
an error correction procedure, and of course in restricted productions, creates
an expectation that line terminators matter in general.
However, going down that road leads to CoffeeScript, or (somewhat more
conservatively due to the use of : at end of head forms, and a lot older)
Python. It's a steep slippery slope.
For comparison, if we take Haskell's semicolon insertion (HSI),
and throw out all the special cases not needed for Javascript,
the rules are simple, predictable, and fully under programmer
control (rather than grammar author control):
1 semicolon insertion happens for syntax involving blocks
(always preceded by some keyword):
keyword { .. ; .. ; .. }
2 if the opening brace following such a keyword is
omitted, the start-column of the next token establishes
a baseline for automatic semicolon/end brace insertion
3 following lines beginning with a non-white token that is
- indented more: continue the preceding statement
This is going to enrage CoffeeScripters and Pythonistas, and with good reason.
They'll want a new block (no leading keyword required), not continuation of the
preceding line. Especially with let, const, and block-local functions.
I'm not saying this is bad or good on balance. Indeed, it beats having to
\-escape a newline to continue an overlong statement in Python.
But it is different yet again from nearby or layered languages, and of course
it's not ASI as JS has had since forever.
- indented equally: start a new statement in the block
This satisfies the expectation created by the selective meaning of line
terminators.
- indented less: end the block
This is great if you buy the rest.
Predictability (both in reading and in writing code) and the
reduction of syntax noise soon won me over. Still, it is useful
to have the option of no HSI interference, if one generates
code with a simple tool, if one wants to make all inserted {;}
explicit, or when whitespace is messed with (emails).
Also, explicit and implicit style can be combined.
Good points. The keystroke tax with ; and {} in JS is an issue. It is a tax at
the margin on all effort creating and maintaining source, though, so I expect
over time lower-tax syntaxes to win. The trick is migrating JS code into a new
standardized edition without creating new runtime errors by failing to catch
migration errors.
Also, some of the pessimism surrounding ASI reform [3]
stems from the limitations of current spec tools, such as
restricted productions, so looking at other ways to insert
semicolons might help.
Reformulating the spec could be done but we would need to keep the ES5 or
classic ASI spec around. Spec complexity and the opportunity cost of the work
to increase it in this area will hurt -- probably a lot.
Anyway, we'd need a more complete strawman spec to evaluate, to get further.
It is interesting that even the ES5 spec has no convincing
ASI examples, only clarifying examples (7.9.2).
That is the same old language from ES1, IIRC.
And blog
posts seem to be more about trouble with ASI than about
usefulness of ASI [2,4,5].
Beware negativity and confirmation biases here.
ASI is relied on by tons of content, without complaints (or praise). It goes
without notice when it works, which is often when a ; was left off where the
formal grammar requires it.
So ASI as it stands in Javascript
now does not only make life harder for programmers but
for spec writers (and readers), too.
The spec didn't change, so we are riding on that sunk cost.
It's easy to exaggerate here, but it seems to me the big deal is not ASI costs
already sunk. Rather it is how to lighten the syntax and make ASI more usable,
in a new edition.
It would be useful to know examples of ASI working well
for
Re: Automatic Semicolon Insertion: value vs cost; predictability and control; alternatives
On 4/17/11, Brendan Eich bren...@mozilla.com wrote: On Apr 17, 2011, at 10:52 AM, Claus Reinke wrote: [TLDR] ASI is not going to be removed. I don't know why you think it could be. Why not? Iif developers would stop doing that then eventually, can't it be removed? It is not hard at all to write code that does not rely on ASI. Existing code that relies on ASI would fail, so making ASI an error today would not be feasible because many sites would break. It might sound naive, but can ASI be phased-out? How can we get developers to stop using ASI? Can ASI be made to be an error for strict mode? IIRC Asen proposed that a couple of years ago. What if ASI were to trigger a warning to developers? ES5 does not define warning. By warning, I mean an error condition that is reported by the implementation but does not trigger abrupt completion (Deprecated production: missing semicolon, line 29). The warning may be hidden but activated in a debugging environment (as optionally provided by the implementation). -- Garrett ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Automatic Semicolon Insertion: value vs cost; predictability and control; alternatives
On 17.04.2011 21:07, Garrett Smith wrote: On 4/17/11, Brendan Eichbren...@mozilla.com wrote: On Apr 17, 2011, at 10:52 AM, Claus Reinke wrote: [TLDR] ASI is not going to be removed. I don't know why you think it could be. Why not? Iif developers would stop doing that then eventually, can't it be removed? It is not hard at all to write code that does not rely on ASI. The question is not that it's hard or not. IMO an explicit semicolon is really a syntactic noise in the language. In goes to the early era of C/Pascal, etc. Since usually, a programmer puts a one logical sentences per line -- *for what* you need additional statement/expression termination besides the new line itself? The useless actions in this case can be compared with masochism. So it's a noise. But a completely different thing is the implementation of ASI and all subtle/tricky/buggy cases related with it which exactly causes dislike of the ASI. If the ASI had been implemented perfectly -- will you still continue to put this noise explicitly? Why? IMO, the semicolon should be inserted only when there is ambiguous syntactic construction, or, e.g. when you want to put more than one sentence in one line. It's like a grouping operator -- usually we use it when we need to solved the precedence conflict, we don't use it manually everywhere, because it's, obviously, noisy and useless. The same with this semicolon. If we need specify such a place -- we put it. If we need to prolong the statement to several lines -- use slash (or anything else) -- but these are rare cases. Personally I always used semicolon when was programming on JS, but -- only to support style guide accepted in the company. I think I wouldn't now, however, yeah, there're very subtle case because of current implementation of ASI exactly in JS which will cause the issues. So still I'd prefer to use semicolon in JS. However, I wouldn't in Coffee/Ruby of course. (Deprecated production: missing semicolon, line 29). It's seems to me as an old era of typing-lovers. The machine should know where I *assume* the ending of a statement. It's not me who should do this dirty job every line! But when the machine is not smart enough, I can help it by placing the semicolon explicitly and these should be rare cases. Dmitry. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Automatic Semicolon Insertion: value vs cost; predictability and control; alternatives
On Sun, Apr 17, 2011 at 12:07 PM, Garrett Smith dhtmlkitc...@gmail.com wrote: On 4/17/11, Brendan Eich bren...@mozilla.com wrote: On Apr 17, 2011, at 10:52 AM, Claus Reinke wrote: [TLDR] ASI is not going to be removed. I don't know why you think it could be. Why not? Iif developers would stop doing that then eventually, can't it be removed? We have a saying at Mozilla: Don't break the web. If a browser vendor removed ASI support from their ES engine, many existing sites would stop working. Their users would switch to other browsers. ES5 does not define warning. By warning, I mean an error condition that is reported by the implementation but does not trigger abrupt completion (Deprecated production: missing semicolon, line 29) Most ES runs in browsers. If a browser shows a warning, it shows it to the end user of a web site--the wrong person. To put this another way, if a browser started showing warnings for ASI, their users would be informed that many existing sites are deprecated productions or something. They would switch to other browsers. -j ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Automatic Semicolon Insertion: value vs cost; predictability and control; alternatives
do modern _javascript_ implementations actually "insert" semicolons? i would assume that the parser would simply adhere to a set of rules when parsing in to an AST and those rules would govern what ends a particular statement, one of those rules being a semicolon. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Automatic Semicolon Insertion: value vs cost; predictability and control; alternatives
On 4/17/11, Jason Orendorff jason.orendo...@gmail.com wrote: On Sun, Apr 17, 2011 at 12:07 PM, Garrett Smith dhtmlkitc...@gmail.com wrote: On 4/17/11, Brendan Eich bren...@mozilla.com wrote: On Apr 17, 2011, at 10:52 AM, Claus Reinke wrote: [TLDR] ASI is not going to be removed. I don't know why you think it could be. Why not? Iif developers would stop doing that then eventually, can't it be removed? We have a saying at Mozilla: Don't break the web. If a browser vendor removed ASI support from their ES engine, many existing sites would stop working. Their users would switch to other browsers. I wrote eventually. As naive as it may seem, it is conceivable that newly written scripts could be authored so that they don't rely on ASI (yeah right, you say). And if that happened then the number of scripts that rely on ASI would diminish in number. ASI is often unintentional. If I do that (and I have) I definitely wnat to know right away; not after I deploy my app. Intell-J warns for this in the js editor. A standard warning for ASI would be helpful in this way. I know it sounds fantastical, but before saying impossible, think about this: What effectively discourage authors from using ASI (intentionally or otherwise)? ES5 does not define warning. By warning, I mean an error condition that is reported by the implementation but does not trigger abrupt completion (Deprecated production: missing semicolon, line 29) Most ES runs in browsers. If a browser shows a warning, it shows it to the end user of a web site--the wrong person. Why must the browser show the message to the end user? I didn't suggest that, so why are you? The implementation (script engine) can emit warnings (for Firebug, MSIE debugger, etc). My idea for standard warnings comes from my contempt for things like this: It is recommended that ECMAScript implementations either disallow this usage of FunctionDeclaration or issue a warning when such a usage is encountered. which mentions warnings but the spec doesn't say what a warning really is. -- Garrett ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Automatic Semicolon Insertion: value vs cost; predictability and control; alternatives
On 4/17/11, Mikeal Rogers mikeal.rog...@gmail.com wrote: do modern javascript implementations actually insert semicolons? Function.prototype.toString says yes. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Automatic Semicolon Insertion: value vs cost; predictability and control; alternatives
On 17 April 2011 20:09, Garrett Smith dhtmlkitc...@gmail.com wrote: Function.prototype.toString says yes. That's not a really valid evaluation IMO. At least in mozilla's case, the semi colon appears in this by virtue of the bytecode decompiler putting a semicolon at the end of every statement. The source-code-as-compiled is not actually stored anywhere. Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Automatic Semicolon Insertion: value vs cost; predictability and control; alternatives
Implementation specific -- JSC Function.prototype.toString returns the exact input string for the body of the function. --Oliver On Apr 17, 2011, at 5:09 PM, Garrett Smith wrote: On 4/17/11, Mikeal Rogers mikeal.rog...@gmail.com wrote: do modern javascript implementations actually insert semicolons? Function.prototype.toString says yes. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Automatic Semicolon Insertion: value vs cost; predictability and control; alternatives
On 4/17/11, Wes Garland w...@page.ca wrote: On 17 April 2011 20:09, Garrett Smith dhtmlkitc...@gmail.com wrote: Function.prototype.toString says yes. That's not a really valid evaluation IMO. At least in mozilla's case, the semi colon appears in this by virtue of the bytecode decompiler putting a semicolon at the end of every statement. The source-code-as-compiled is not actually stored anywhere. OK, thanks for pointing it out. -- Garrett ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
