Brendan Eich wrote:
On Oct 16, 2008, at 7:04 PM, Waldemar Horwat wrote:
The parser is required to backtrack until it either finds an expansion
of the grammar that doesn't generate a syntax error or until it
discovers that they all do. You can choose to make additional syntax
errors as
Maciej Stachowiak wrote:
I think it might be better to write the official ES3.1 grammar in this
way, even though it is a little annoying and repetitive, so it can more
readily be verified that the language grammar has no ambiguities by
running through a parser-generator like yacc or bison
On Oct 17, 2008, at 11:05 AM, Waldemar Horwat wrote:
Brendan Eich wrote:
Is this a perfectly valid for-in statement?
for (a = b in c);
Not according to ES3's grammar. An assignment expression is not
valid on
the left of the for-in's in:
/IterationStatement /*:*
* ...*
*
On Oct 17, 2008, at 11:30 AM, Brendan Eich wrote:
In that case the -NoIn sub-grammar should apply, extended to
LetExpressionNoIn. So
for (let (a = b) c in d);
Sorry, of course that should have been
for (var a = let (b = c) b in d);
/be
___
This turned out to be an interoperability problem. json2.js does not
include milliseconds, and the implementation I just checked in for
Mozilla does. I think the standard should mandate millisecond
precision so that UTC dates can survive a round trip.
- Rob
On Thu, Oct 16, 2008 at 3:25 PM,
Here's a clearer case that Firefox gets wrong (or your grammar gets wrong,
depending on your point of view):
function f() {return f}
var x = 3;
let (a = 1) a ? f : x++();
The grammar states that the last statement must evaluate to f. Firefox gives
a syntax error. This is incorrect because
Dave Herman wrote:
What is your point? To write a recursive factorial I'd write either:
lambda f(x) {
if (x == 0)
1;
else
f(x - 1);
}
or:
function f(x) {
if (x == 0)
return 1;
else
return f(x - 1);
}
Right, good, so far we're on the same page.
Either one is subject
On Oct 17, 2008, at 12:25 PM, Waldemar Horwat wrote:
Here's a clearer case that Firefox gets wrong (or your grammar gets
wrong, depending on your point of view):
function f() {return f}
var x = 3;
let (a = 1) a ? f : x++();
The grammar states that the last statement must evaluate to f.
What you appear to be saying is that wrapping the call to g()
inside another statement indicates that it will not be tail-recursive.
No, that's not what I'm saying-- that's a given and not relevant.
What I'm trying to say is that trying to make return into a
tail-calling form is clunky
On Oct 17, 2008, at 3:39 PM, Brendan Eich wrote:
On Oct 17, 2008, at 12:25 PM, Waldemar Horwat wrote:
Here's a clearer case that Firefox gets wrong (or your grammar gets
wrong, depending on your point of view):
function f() {return f}
var x = 3;
let (a = 1) a ? f : x++();
The grammar
On Oct 17, 2008, at 3:47 PM, Brendan Eich wrote:
On Oct 17, 2008, at 3:39 PM, Brendan Eich wrote:
On Oct 17, 2008, at 12:25 PM, Waldemar Horwat wrote:
...
let (a = 1) a ? f : x++();
The grammar states that the last statement must evaluate to f.
Firefox gives a syntax error. This is
Brendan Eich wrote:
On Oct 17, 2008, at 3:47 PM, Brendan Eich wrote:
On Oct 17, 2008, at 3:39 PM, Brendan Eich wrote:
Er, you are right, I should have acknowedged this point. The rest of
my post is about x++() not being a valid sentence, which supports your
argument.
While we don't have
No, I must have misunderstood what you meant by wrapping the call to
g() inside another statement -- I thought you were referring to
wrapping it in a context such as
{ -- ; stmt; }
which would obviously not be a tail position. But this:
lambda f(x) {
if (x == 0)
1;
else
f(x -
On Oct 16, 2008, at 3:40 PM, Brendan Eich wrote:
For now I favor the lambda expression form as well as the lambda
block form.
Good thing I added For now. Since I'm convinced by Waldemar's
argument against ambiguity, I have to drop support for the lambda
expression form. It could be
On Oct 17, 2008, at 11:17 AM, Waldemar Horwat wrote:
Maciej Stachowiak wrote:
As to the else issue, I don't think that ambiguity can be avoided,
but bison lets you solve that with %nonassoc, which is a sound
disambiguation mechanism.
It can. I have a machine-validated ES3 (and ES4
The parser is required to backtrack until it either finds an
expansion of the grammar that doesn't generate a syntax error or
until it discovers that they all do. You can choose to make
additional syntax errors as per chapter 16, but that does not
relieve you of the backtracking requirement.
On Oct 17, 2008, at 7:36 PM, Eric Suen wrote:
Are you sure about that, because you using hand written top-down
parser,
Is it confirmed by a top-down parser generator like ANTLR?
I haven't used ANTLR or any other LL(*) parser generator, no.
I found http://code.google.com/p/antlr-javascript/
17 matches
Mail list logo
