block lambda revival

[Jorge]

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>