Semantics and abstract syntax of lambdas

[Dave Herman]

Lex Spoon wrote:
> The technique is to include an expression form which contains a
> sequence of statements followed by an expression.  In Scala, the
> syntax looks like this:
>
>   { statement1; statement2; result_expression }
>
> So you can do things like:
>
>  { val x = 1; val y = 2; x+y }
>
> The result would be 3.  I'm not sure what the best syntax would be for
> JavaScript, but surely there is room somewhere.

I mostly agree; I was originally going to propose this but then I  
realized that since JS already has completion values (i.e., even  
statements produce results-- I gather this was originally added so  
that `eval' can take a syntactic representation of a Program and still  
return a useful value) so I thought we should just reuse that instead  
of adding a new, possibly unnecessary mechanism.

But I suspect the completion values are relatively obscure and not  
really understood by users. Worse, there are some statement forms that  
don't produce a completion value and some really obscure corner cases  
-- including some that make it undecidable which substatement will  
actually produce the completion.

So I would be interested in a simple syntactic form like Lex's  
suggestion. Imagine for a moment the following idea didn't cause  
parsing problems (it does, but bear with me). Say we had a sequence- 
expression form:

     { stmt; ... ; stmt; => expr }

and then add two kinds of block literals, a block-statement form and a  
sequence-expression form:

     ^(x1,...,xn) { stmt; ... ; stmt }
     ^(x1,...,xn) { stmt; ... ; stmt; => expr }

1. Tail position would only be a property of *expressions*, not  
statements [1]. That's simpler.
2. There's no "accidental return" hazard because you have to  
explicitly use the => form.
3. It doesn't break Tennent because the return position is a fixed  
part of the syntax, not a separate operator whose meaning gets  
captured by lambda.

It does make lambda-as-control-abstraction a few characters more  
expensive. More immediately, this notation is obviously wildly  
conflicting with the object-literal syntax. I probably should leave it  
to the syntax warriors to figure out how to spell this in unambiguous  
ASCII. But there's the idea.

Dave

[1] IOW, the only tail positions would be:

- the tail expression of a sequence-expression
- the two branches of a ? :
- the second operand of the || operator