three small proposals: the bikeshed cometh!

Mark S. Miller erights at google.com
Thu Apr 29 16:18:21 PDT 2010


On Thu, Apr 29, 2010 at 10:03 AM, Brendan Eich <brendan at mozilla.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20100429/98f8b735/attachment-0001.html>


More information about the es-discuss mailing list