On Thu, Apr 29, 2010 at 10:03 AM, Brendan Eich <[email protected]> wrote:
[...]
> // 2.) Shorthand for "function", aka the "not lambda"
>
> [...]
>
> // equivalent:
> function(){ return 10; }
> #(){ return 10; }
> #{ return 10; } // no args, optionally elide ()
>
>
> This does several things at once, and we have discussed one of them:
> turning the completion value of the body into the return value.
>
> The objection to this, voiced clearly by Waldemar, is the unintended
> completion value in tail position leaking out as a return value. This is
> hard to see and test for, and it requires ugly void operator usage, or a
> dummy final value, to control.
>
> Dave Herman has recently proposed
> http://wiki.ecmascript.org/doku.php?id=strawman:let_expressions, which
> include an explicit "completion value here" prefix: => 10; in tail position
> would result in 10, and without => the result would be the undefined value.
>
>
> * equivalent semantics to the function(){} syntax
>
>
> No, not equivalent because tail position completion values are not return
> values with functions. Again semantics matter, not just syntax.
>
First of all, +1 for Dave's let expression syntax. The ASI issues I just
raised are details. Whatever answers we arrive at for those, I'm still +1 on
let expressions.
Second, +1 on "#" as a short way to define closures, whether they are simply
replacing the "function" keyword or introducing a genuine lambda.
Third, given the first two, +1 on "#" reviving lambda, with Dave's same "=>"
replacing the notion of completion value within the lambda body.
I know that in the past I have advocated let expressions while agreeing to
drop lambda. However, now that I've had time to sleep on introducing let
expressions into the language, I think the marginal psychological complexity
of introducing lambda along with let is not so great after all. And it
avoids a different source of confusion. For example, without lambda, when
people improve iteration code like
for (var i = 0; i < arr.length; i++) {
// ...
if (pred(arr[i])) { return arr[i]; }
// ...
}
to use the new array generics, they will often first write
arr.forEach(function(el) {
// ...
if (pred(el)) { return el; }
// ...
});
which won't work at all. By contrast, if "#" means lambda,
arr.forEach(#(ev) {
// ...
if (pred(el)) { return el; }
// ...
});
will work just fine. The array generics really are our first
non-special-form control abstractions. Control abstractions without a
TCP-respecting lambda will simply be confusing. Control abstractions without
a short function call syntax (whether meaning lambda or function) are simply
too verbose.
Even if lambda remains rejected, I'd still prefer "#" for "function", rather
than to leave the current verbosity unrepaired.
--
Cheers,
--MarkM
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
