block lambda revival
Jorge
jorge at jorgechamorro.com
Sat May 21 10:38:35 PDT 2011
On 21/05/2011, at 16:43, Brendan Eich wrote:
> On May 20, 2011, at 9:55 PM, Peter Michaux wrote:
>> On Fri, May 20, 2011 at 5:54 PM, Brendan Eich <brendan at mozilla.com> wrote:
>>> An essential part of this proposal is a paren-free call syntax
>>
>> Why is that essential?
>
> The argument, as I understand it from Smalltalk, Ruby, and E experts, is empirical, and in part a matter of intentional design: users write blocks as actual parameters to make control abstractions. Most such abstractions taking block arguments do not let those blocks escape through the heap or a return value -- the blocks are downward funargs. This aids in making new control abstractions more efficient than functions to implement, as well as more usable. Built-in control flow statements have (optionally) braced bodies that do not need parenthesization, so why should new ones created by users passing blocks?
>
> When I wrote essential, I was not claiming that there's a logical proof of necessity. Rather I was declaring that this strawman includes paren-free block-argument-bearing call expressions as an essential design element. (...)
<fwiw>
I for one do like explicit call()s better, the way it's always been in JS. ( and it's just 2 chars ), perhaps because I can't avoid to see it as a plus to share syntax with C.
C is one of the -if not the- most important languages in history, and I can see good reasons for you wanting to borrow from its syntax back then, in 1995 (but even now, too, because it's *still* one of the most important and popular languages)
But I can't say so much of borrowing from coffeescript's syntax ? Perhaps in 30 years, we'll see :-)
Why the (sudden) urge to copy so many bits ( paren-free, -> // =>, etc ) of coffee's syntax ? (does JS have an identity crisis now ?)
WRT the syntactic noise that these () ; {} etc introduce in the source: I don't like the way children write their SMSs either, everything are shorthands and there's no punctuation marks: sure it's faster to write, but not easier to read.
A bit less (syntactic) noise would be good. But a bit less isn't "let's make a new JS that not even a JS programmer can recognize".
I'm a JS programmer that isn't ashamed of its C heritage, and I don't think JS.next needs that breaking change.
I'd put the stress in the other important things more than in trying to make it look more "current-fashion".
</fwiw>
> Chopping it out chops down the whole strawman.
No paren-free call()s, no {|| ... } blocks ? Why ?
WRT lexical `this`: I think a simple (illegal var name) in the first parameter position, for example '@', might serve :
({ lex:lexicalThis, dyn:dynamicThis }).lex().dyn();
function lexicalThis () {
var that= this;
{|@,a,b,etc| assert(this === that)}();
return this;
}
function dynamicThis () {
var that= this;
{|a,b,etc| assert(this !== that)}();
return this;
}
--
Jorge.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110521/8e45cff2/attachment.html>
More information about the es-discuss
mailing list