So, assuming that these two are valid function expressions that mean
roughly the same thing:
a: (x) { return "x" }
b: function (x) "x"
and then you might conclude that this is as well:
c: (x) "x"
So far, so good, I think.
What about these?
d: (x) (y)
e: (x) (y) { return "z" }
f: (x) (y) ("z")
g: (x) (y) "z"
Leaving aside block lambda TCP freaky-deakiness, I'm not sure mentally
how to even parse those. I suppose you could just say that you're not
allowed to start an expression-bodied-auto-return function with a (,
maybe?
I'm not sure. But it is certainly weird and confusing.
If e and g both desugar to:
h: function (x) { return function (y) { return "z" }}
then that could be extremely useful to me. Every ceremonial token has
been stripped, leaving only the meaningful bits. It's especially
lovely for curry-able functions that are multiply-called:
i: curryableFn (a) (b) (c, d) { .. do lots of stuff with a, b, c,
and d .. }
gogoAsync(args, curryableFn(1)(2)) // calls the resulting cb, a
and b pre-set.
On Thu, Mar 8, 2012 at 19:35, Kevin Smith <[email protected]> wrote:
> I think we can use a modification of the Dart technique to parse "=>"
> functions:
>
> On encountering "(" in a context where an expression is acceptable, you can
> try to parse it as ( Expression ) or as ( FormalParameterList ).
>
> Attempt to parse it as a formal parameter list, enqueuing each token
> encountered. Either the parameter list will be successfully parsed or not.
>
>
> If a parameter list is successfully parsed, then
>
> peek at the next token to see if it's a "=>". If it is, then
> clear the queued tokens and continue parsing as normal.
> If it's not a "=>", then put the queued tokens back into the token
> stream and restart parsing from the original "(", this time as
> an expression.
>
> otherwise, if we fail to parse the parameter list, then
>
> put the queued tokens back into the token stream and restart
> parsing from the original "(", this time as an expression.
>
> Lemma: The "lookahead" token stream that we queue while attempting to parse
> ( FormalParameterList ) will be identical to the token stream that we would
> have queued if we had attempted to parse ( Expression ).
>
> Thanks,
> kevin
>
>
> On Thu, Mar 8, 2012 at 4:28 PM, Kevin Smith <[email protected]> wrote:
>>
>> 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
>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
