On Jun 1, 2011, at 10:07 AM, Jorge wrote:
>>> A block:
>>> { noLabelHere ... }
>>>
>> We didn't talk about this change. It is yet another migration early-error to
>> consider.
>
> But it's not very usual to begin a block with a label.
You're right, and it can be an ArrowBodyBlock, not a backward-compatible Block,
so this is only a refactoring-from-function-to-arrow-syntax tax. Good idea.
>> It's certainly simpler than a more powerful parsing algorithm than LR(1),
>
> If you
>
> 1.- keep the familiar { block } syntax for first class blocks, and
> 2.- use {|| ... } for shorter functions syntax and
> 3.- keep the (obligatory) parens as the call() operator
>
> wouldn't we gain everything in the arrow syntax and block lambdas strawmen,
> except for paren-freeness ?
No, some people object to the cleverness of block-lambdas, the TCP preservation
for break, continue, return, and |this|, and the completion-return too.
Paren-free syntax for block-lambdas as control abstractions is controverisal,
but less so, and IMHO trumped up (since when was C# in its multi-version glory
designed holistically at 1.0? LINQ and other innovations have come relatively
quickly).
Block-lambdas are more divisive because they introduce novel runtime semantics,
akin to throwing uncatchable-except-by-the-VM exceptions.
Arrow function syntax is just syntax, so it is an easier sell, provided the
grammar and semantics can be added to the ECMA-262 framework without too much
trouble.
> And, wouldn't that be easier for the current (proven) parsers, and pose
> almost zero risks in this respect ?
The parsing problems of arrows are really only in the ECMA-262 spec-space, not
in real implementations.
> And, wouldn't that be in line the already known, much appreciated by many of
> us, current JS (and C) style ?
>
> { block }( call ) or {|| ... }( call )
Since when can you call a block in JS or C?
A function expression is not a block, it starts with 'function(' at the least.
> foo bar baz ... wtf ? foo(bar(baz)) ? foo(bar)(baz) ? foo(bar)(baz)() ? meh!
> This syntax introduces ambiguities !
Not the way the strawman grammar works. Did you read it?
Here you seem to be inveighing against the paren-free CallWithBlockArguments
production, not against arrow function syntax. Yet you switch targets
immediately:
> Do David and Jeremy like it ? Good for them. Do JavaScripters like it ? The
> least we can say is that it's quite polemical :
> <https://github.com/rails/rails/commit/9f09aeb8273177fc2d09ebdafcc76ee8eb56fe33>
What are you talking about now? Arrows or call-with-block-lambda-argument
paren-free calls? The two are entirely separate strawmen, the latter part of
block-lambdas.
If by David you mean DHH, didn't he endorse CoffeeScript, which uses arrow
function syntax, and not any Ruby-ish block-lambda proposal from me? Please
keep your arguments straight!
>> but we might want to cross that bridge anyway for arrow functions.
>
> <fwiw>
>
> Arrow syntax is extraneous to JS developers. It's an unnecessary, radical
> style change. And ugly: there are JS developers that just *don't*like* it.
People say that about block-lambdas and not just for the non-function-looking
syntax -- especially for the semantics, which are novel.
> So, why ?
I think the shoe is on the other foot.
Look, I wrote up both
http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax and
http://wiki.ecmascript.org/doku.php?id=strawman:block_lambda_revival to give
both the arrow fans (not just CoffeeScript, it is in many languages and math-y
notation systems) and block-lambdas (originated in Smalltalk, also in a more
layered form in Ruby) both a fair shake.
Don't shoot the messengers who want only one, or neither. And don't shoot me
for drafting these. JS's function syntax with mandatory return in braced body
is too long. But fixing that is not a simple matter of *only* shortening
function to some ugly and conflicted punctuator. It's not a matter of
pretending block-lambdas are blocks and are already callable. It requires
careful work to meet several often-conflicting goals and requirements.
> Paren-free(ness) is a fashion: foo bar baz, what's a function, who's calling
> who ? with which parameters ? Meh! Ambiguities.
How about you stop ranting and read the block-lambda grammar.
> </fwiw>
>
>> If we succeed there, we may not need such an incompatible restriction on
>> labels.
>
> -1
-1 on what, the incompatible change being rejected? It isn't necessary anyway:
we can split Block and ArrowBodyBlock or anything like it. So cheer up!
/be_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
