On May 11, 2011, at 4:01 PM, Allen Wirfs-Brock wrote:
> On May 11, 2011, at 9:53 AM, Brendan Eich wrote:
>
>> ...
>>
>> 3. Blocks as implicitly quoted code could be like zero-argument lambdas,
>> with break, continue, return, |this|, and |arguments| referred to any outer
>> function or loop/switch statement. This suggests something like the Ruby-ish
>> syntax Isaac sketched recently, mooted by various people in the past:
>>
>> array.map({|x| x * 2 }) // YAY!
>>
>> Problems:
>>
>> 3a. Basis case is {}, an object initialiser. Patchable by requiring {||},
>> but ugh.
>
> In practice, such null blocks would probably seldom occur. Particularly, if
> the convention was for functions taking "block" arguments to treat
> undefined/null as the do nothing block.
Unlike functions taking function arguments, since null() and undefined() are
inevitable errors. Do we really want to fork the funarg world in two?
When I rant against idealism and perfect being possible, I'm not just waxing
philosophical. We live in a world of trade-offs. There is "better" but it
rarely comes without something, however marginal or minority-share use-case,
getting "worse".
Rubyists may cheer blocks in JS but we need to avoid making things strictly
more complicated, in fork-the-subset-of-functions-taking-function-arguments
terms, e.g.
>> 3b. The objection raised repeatedly when we discussed lambdas here, that
>> return unwinding an outer function, or throwing an error if the outer
>> function call has already returned, is as big a hazard and source of
>> confusion as -- or bigger than! -- any completion-return downside.
>
> I can't speak to Ruby usage, but such errors are a rare occurrence in
> Smalltalk where such blocks are the only way to express control abstractions.
> Don't know if the same would be true for JS.
Evidently not unless we model existing control flow statements as magic
functions taking blocks. E.g., if is a function taking its condition, then
outside the parenthesized (or paren-free if we do that!) condition, one or two
blocks.
> Would people try to use such blocks as event handlers??
I suggested they would, because the syntax is so much shorter.
> The actual runtime test that is needed to test for already returned can be
> pretty cheap. It would probably be possible to add a way to test whether a
> block contains any non-local exists. Any code that wants to make sure it
> doesn't see should errors could test their block arguments before stashing
> them way. Of course, that just replace on error with a different earlier
> error.
Right, and a testing via code reflection onus.
Ruby is far from simple, btw. Check out
http://samdanielson.com/2007/3/19/proc-new-vs-lambda-in-ruby
and the wikipedia page it references.
Looks like Proc.new but not lambda can return from its caller.
>> 3c. The use of {| (possibly with space in between) is an unambiguous
>> extension, but formal parameters inside |...| delimiters creates a problem
>> for http://wiki.ecmascript.org/doku.php?id=harmony:parameter_default_values.
>> We would need the default value expression to be parenthesized if its
>> precedence were | (bitwise-or) or looser.
>>
>> Other than these, AFAICT blocks as lambdas offering shorter function-like
>> syntax are pretty good. Should we reconsider them?
>
>
> I think this is an area that really cries out for an experimental design and
> implementation.
User testing is hard, lots of confounders, hard to control. We'd need scale. We
could try experimental annexes in ES.next for better function syntax, classes,
other hard nuts to crack. Advise that if implemented they must track the
annexes (or separate TRs, don't care). Only after some consensus emerges (if it
does) do we standardize.
I don't see a quantitative way to decide, but this might be worth the overhead.
Thoughts?
/be
>
> Allen
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
