return when desugaring to closures

[Waldemar Horwat]

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 
>> mandatory.
> 
> 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.

    Waldemar