return when desugaring to closures
waldemar at google.com
Wed Oct 15 14:36:01 PDT 2008
Dave Herman wrote:
>> Please specify what you are proposing. The one proposal I've seen is:
>> Expression ::= ... | lambda Formals Statement
> Yes, that's what I meant, or at least what I thought Yuh-Ruey meant.
>> This is not particularly useful because then even assign a lambda to a
>> variable would be a syntax error,
> Why is that?
Because there exists no sequence of grammar production expansions that would expand to "a = lambda() x;".
>> and you'd introduce a bizarre asymmetry into the ExpressionNoIn case.
> Can you explain?
Look at how the ExpressionNoIn cases are handled in the existing grammar. They are necessary. If you have an expression that contains a statement that contains an expression that contains the keyword "in" then you'll introduce a grammatical ambiguity into for-in statements.
>> The questions you'd have to answer are:
>> - Where in the expression grammar would you introduce a lambda?
> I assume you mean what is the precedence. I'm not sure, although
> presumably it would be about the same as `let' expressions.
There is no such thing as a "let expression".
I don't mean precedence. I mean which rule in the expression grammar would describe a lambda. Precedence is a side effect of that, but obviously not all syntax can be captured by the concept of precedence.
>> - Is lambda a reserved word?
> This is a relevant question for any number of alternative syntaxes for
> lambda. I would think it would be the same as `let'.
>> - How does it interact with semicolon insertion? As written, if the
>> Statement were an expression statement then the semicolon would be
> Why is that? If that were so then I would be absolutely opposed to
> Yuh-Ruey's syntax: the appeal of the idea was unifying the
> expression-body and statement-body form into one single definition.
It's mandatory because the grammar and semicolon insertion rules say so. Btw, to properly terminate a lambda expression you'd need *two* semicolons. Here's why one would be insufficient:
f = lambda(x) x;
(a + b) && c;
would parse the body of the lambda as the expression "x;", the "(a + b)" as an argument to the lambda, and the rest as applying to the result of calling the lambda. What you'd want to write instead would be:
f = lambda(x) x;;
>> - Do you really want to have extra semicolons in the middle of
>> statements? Now you're forced to accept things like the following:
>> for (; lambda() x++;, lambda() y++;,; lambda() z++;) ...
> Thanks, these were the kinds of nastinesses I was worried about.
> Arbitrarily mixing statements into expression contexts does indeed
> appear to get pretty convoluted. Perhaps just enforcing the block form
> of lambda is enough to keep things from getting too mixed up,
> specifically, by enforcing syntactic delimiters between expressions.
>> Overall, this syntax does not look promising. It's likely to get you
>> into complexity trouble.
> Do you prefer (lambda Formals Block | lambda Formals Expression)?
Speaking purely from a syntactic perspective:
- The block form is fine.
- The expression form has problems. It's hard to distinguish an expression that's part of the lambda from an expression that's part of the surrounding expression.
> [Personally I'm fine with that.] Or do you oppose any lambda expressions
> at all? Or did you have something else in mind?
I don't see enough of a benefit to warrant inclusion of a new lambda concept. It's just another way of doing what local functions can do. If there is a bug with local functions, then fix that one instead instead of sowing confusion by having two concepts.
More information about the Es-discuss