On Dec 11, 2008, at 7:33 AM, P T Withington wrote:
On 2008-12-11, at 03:21EST, Brendan Eich wrote:
Again, what problem are you solving? I hate to add it, but I mean
"real-world problem", one you can show biting deployed code on the
web, or tell a few anecdotes about. Not hypothetical problems from
a spec (ES1 had a few of those too).
My name is Joe Hacker, and I have a question.
I am planning on buying into es3.1, and I want to know wether your
semicolon insertion plan is going to prevent me from doing that?
Here are 2 bugs that I hit currently, and an anecdote:
Bug 1:
return
answerWithSideEffect();
I believe you have fixed that in your campaign proposal. Under the
previous administration's plan, a semi-colon was inserted so this
returned undefined, and never executed the next line, much to my
disappointment.
Glad you mentioned this. The restricted productions for break and
continue to label, and postfix ++ and --, have this potential problem
too, but return\noverlong-expression is the only one that bites. jwz
gave me grief in the ancient days over it. Crock brought it up as the /
casus belli/ behind the desire to remove ASI from 3.1 strict mode when
we were meeting in Oslo this past July.
This is the bath-water to try to throw out, while keeping the ASI baby
in strict mode.
At the Oslo meeting we talked about how the true bug with ASI applied
to return\nexpr was the dead code left in its wake -- the expr; on its
own after the return, unreachable by control flow in the common case.
I proposed analyzing dead code and making it a strict error for return
to orphan an expression statement.
(It's true that sometimes one hacks an early return into code to debug
(binary search a large function for a bug, e.g.), and this would not
be possible in strict mode. The debugger driver who is bisecting would
have to comment out the strict pragma.)
Then at a later meeting (I think the Redmond one in September, which I
missed) it was argued this was too onerous, since ECMA-262 does not
require much compile-time analysis.
There are two general cases (pretend bar() is a really long expression):
1. if (foo) {
return
bar();
}
baz();
and
2. if (foo)
return
bar();
The braced case (1) is clear, because the basic block containing bar()
has only one predecessor, which ends in return. This case can be
detected while parsing -- no control flow graph dominator relation
computation required.
The unbraced case (2) cannot be "corrected" to
if (foo)
return bar();
without analyzing harder (say, trying to prove foo is a constant
truthy value) and even then guessing what is meant. And we should not
guess based on any complicated rules or analyses. So the ES1-3 ASI
rule *should* apply in this case, resulting in
if (foo)
return;
bar();
Is it really too onerous (upon implementors) for strict mode to make
case (1) an error?
Bug 2:
foo = function() {...}
(...)
Under the previous administration, this did not do what I expected,
because I came from a language where semicolons after close braces
were optional. What is your campaign proposal for this issue?
I don't propose anything. This is the first non-hypothetical report
I've heard in all the years; sorry it hit you.
While people do leave semicolons off after assignment statements,
including ones with function expressions as the right-hand side
expression, it's rare to start the next statement with (.
The fact is that C and other languages that do not require ; after a
function definition's closing brace *do* require it after function
declarations (prototypes), and after other declarations and statements.
Anecdote 1:
I have a syntax directed editor which pretty much forces me to
insert semicolons, because it does not have a powerful enough
analyzer to figure out where semicolons would be inserted
implicitly, and it relies on semicolons to do its auto-indenting.
How does your campaign plan to address the issue of syntax directed
editors? Will they be burdened with the tax of having to implement
a full parser (that can gracefully recover from incomplete code
fragments) in order to correctly predict implicit semicolons?
Yeah, that is the right trade-off. Joe Hacker benefits, Tucker Super-
Hacker works harder. Sorry, but you are l33t and your skilz are better
remunerated than Joe's.
/be
_______________________________________________
Es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
