On Tue, Mar 6, 2012 at 5:14 PM, David Herman <[email protected]> wrote:
> On Mar 6, 2012, at 1:55 PM, Brendan Eich wrote:
>
> > The risk here may be small but people have run into it before in CL and
> other LISPs and expression languages. It's a bit scary in JS, what with
> OCAP the fundamental security model. So I don't think we should treat it
> lightly and TC39 has not, so far.
>
> Perhaps. OTOH, the half-measure of only partly shortening JS functions,
> i.e.:
>
> myList.map((x) { return x + 1 })
>
> vs
>
> myList.map((x) { x + 1 })
>
> or
>
> myList.map({|x| x + 1})
>
> is disappointing. Moreover, it essentially means abandoning ever having
> TCP lambda. Now, I know that some in the community look at block-lambda
> with suspicion (although I'm tempted to call BLUB -- don't knock it till
> you've tried it). As ever, we have kind of a Mexican stand-off between
>
> - block lambda (funky pipes, freaks some people out)
> - TCP-respecting shorter function (possible return-value leak, freaks some
> people out)
> - shorter functions with return (still verbose, possible return-value
> leak, precludes ever having TCP-respecting lambda)
>
I'm going to stick my neck out and my foot in my mouth... I would prefer
block lambdas, because of the function expression scope win, but like you
said, funky pipes are freaky ;)
Here's where the foot goes in the mouth... Why couldn't ()[no
LineTerminatorHere]{} be used with block lambda's semantics?
*ducks*
>
> Dave
>
> _______________________________________________
> es-discuss mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
