I know you are well aware of the LetExpression form that was in proposed
ES4 and has been implemented in Firefox since JS 1.7 -- why are you
sounding like you've never heard of it?
In the grammar for proposed ES4, LetExpression was under
PrimaryExpression. That's where I'm suggesting LambdaExpression might
fit. IOW:
PrimaryExpression ::= ...
| LetExpression
| LambdaExpression
LetExpression ::= let ( LetBindingList ) CommaExpression
LambdaExpression ::= lambda FunctionSignature LambdaExpressionBody
> 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.
Okay, sure. This is already a bizarre corner case of the grammar. So it
means in that case you'd have to parenthesize the lambda expression.
Let's look at what we're talking about here; you can't write something
like this:
for (x = lambda() foo in bar; ....)
I don't imagine this being all that common; how often do loop variables
get bound to procedures? In fact, this is probably *more* likely to come
up with let-expressions:
for (x = let(tmp = f()) tmp in obj; ...)
In any case, parenthesization resolves the issue. A corner case, yes,
but IMO this is just part of the wartiness of the for-in syntax, and not
reason enough to ban new expression forms.
> What you'd want to write instead would be:
>
> f = lambda(x) x;;
It might be possible to patch up this problem with more cleverness in
the semicolon-insertion algorithm, but that way madness surely lies.
Anyway, I'm already convinced that (lambda Formals Statement) is not
going to work out. I think we're in agreement there.
>> 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.
This is a problem with all compound expression forms that end in an
expression (e.g., yield and let). I don't feel that's reason enough to
ban them all.
> 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.
As I see it, the major benefits of `lambda' are
a) introducing a low-level and compositional primitive that is useful
for code generation (as a target language for compilers, macros, or
other language features defined by desugaring), and
b) creating a clearer place in the language syntax to enforce tail
calling by eliminating `return'
These needs aren't addressed by `function' and almost certainly can't be.
> If there is a bug with local functions, then fix that one instead
> instead of sowing confusion by having two concepts.
Recall that `lambda' does not include `return', `this', `var', or
`arguments'. We're not about to eliminate those from `function'! (Nor
would I advocate doing so-- even if we could somehow rewrite the entire
web.)
Maybe you don't feel that the issues addressed by `lambda' are important
enough to warrant the new feature, but "just change `function'" is a not
a realistic argument.
Dave
_______________________________________________
Es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
