On May 21, 2011, at 11:07 AM, Peter Michaux wrote:

> On Sat, May 21, 2011 at 10:50 AM, Brendan Eich <[email protected]> wrote:
>> On May 21, 2011, at 9:50 AM, Peter Michaux wrote:
> 
>>> In another thread, some people were suggesting {||}
>>> as an exact alternative to the thin arrow.
>> 
>> Yes, I cited the thread in the strawman. So what? Chopping proposals into 
>> little pieces does not help, we've seen this before.
> 
> But the two strawmans conflate ideas unnecessarily.

Conflate is pejorative and unnecessarily is false. It's a matter of design 
choice, not necessity.

We seem to go in circles a lot. What part of "integrated design" was unclear? 
If somehow the whole is rejected, we can pluck out parts and propose them 
separately, or better: as part of alternative integrated designs.

In particular, I explicitly rejected paren-free call syntax for any function, 
proposing this novelty only where the actual arguments are block-lambdas. 
Paren-full, comma-separated call syntax still works.

Paren-free call syntax in general is problematic on grammatical and 
backward-compatibility grouns. Tying it to block-lambdas as new expression 
forms avoids these problems. I don't think you acknowledged this design 
decision, which goes against separating paren-free calls out as a strawman.


> Someone out there
> may want thin arrow lambdas without paren free calling.

People want many things. We are considering only certain proposals, within 
certain bounded periods, and doing our best. We're not going to consider 
everything, and (see above, and to repeat myself) we are not chopping 
everything up into minimal parts and considering all combinations.


> If they do
> then how do they choose between the {||} lambda paren free verses the
> arrow function strawmans. They cannot.

Too bad.


> There are several issues that can be dealt with separately.
> 
> 1) Should new syntax be introduced for functions?

We are past this and considering multiple strawmen.


> 2) Should lambdas be introduced? If so what would there syntax be?

This is not a question-posing exercise or even a Socratic dialog. It's a 
proposal/disposal process, already well under way. With block lambda revival, 
my answers are "yes" and "Ruby-esque".


> 3) Should paren free calls be introduced?

I'm not proposing this in general, and I do not believe anyone else on TC39 
will.

/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to