Thanks for the clear explanation, Brendan - I think I understand the
concerns now. And if not, I don't mind looking foolish : )
I just looked at the code for the Dart parser and it basically queues
tokens until it finds the matching right paren (recursively counting nested
parens). It peeks at what comes afterward (like a => or {), and then it
goes back to the original left paren and resumes parsing, dequeueing the
already scanned tokens.
Would this technique work for us? The problem that I see is that in JS,
you can't really tokenize without also parsing (because of the cursed
lexical ambiguity on '/').
kevin
On Thu, Mar 8, 2012 at 2:35 PM, John Tamplin <[email protected]> wrote:
> On Thu, Mar 8, 2012 at 1:08 PM, Brendan Eich <[email protected]> wrote:
>
>> Another which I cited just a few messages back: parsing ( params ) as (
>> expr ), as any top down parser must until it gets to an arrow or other
>> distinguishing token ({ on same line as ), e.g.), can be considered
>> future-hostile. params should be declarative, but expr must now cover all
>> future declarative syntax, including optional guards.
>>
>
> For this particular problem, the Dart parser looks ahead to see if it
> could be a function declaration. If so, it parses it that way, otherwise
> it parses as a parenthesized expression. I don't know if this sort of
> approach would be considered acceptable here or not (it does impose some
> restrictions on the scanner for n-token lookahead).
>
> --
> John A. Tamplin
> Software Engineer (GWT), Google
>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
