Concise functions, Nonexistent lambdas, Explicit tail calls

[Brendan Eich]

On Dec 9, 2008, at 4:15 PM, Jon Zeppieri wrote:

> On Tue, Dec 9, 2008 at 5:42 PM, Michael Day <mikeday at yeslogic.com>  
> wrote:
>> Or practically any other keyword we can think of. So this problem  
>> exists for
>> many of the proposed syntactic extensions to JavaScript. Is there  
>> any way
>> other than opt-in to introduce to new keywords without breaking  
>> existing
>> code?
>
> Aside from picking really odd keywords?  I don't think so.  That's why
> people have been discussing the use of non-identifier ASCII
> punctuation.

Opt-in versioning was required for let and yield in JS1.7 -- it's a  
fait accompli.


>>> The benefit seems vanishingly small.  I don't think it's enough to
>>> cover the (admittedly minor) cost in language complexity.
>>
>> Mozilla already has expression comprehensions, albeit without the
>> parentheses, so this aspect can be evaluated now.
>
> JS also has a more powerful expression language than ES, so it
> wouldn't be an entirely accurate evaluation.  It could be that Harmony
> will adopt many of the JS additions, though.

I wasn't sure whether "expression comprehensions" meant expression  
closures:

function hi() "there";

or array comprehensions:

   return [i*i for (i in nat(N))];


>> Everything currently in the specification describing functions will  
>> still
>> need to be there, even if some of it is rewritten to be expressed  
>> in terms
>> of lambdas. On top of that, lambdas will need to be described. This  
>> will
>> make the spec longer, and have more constructs that need to be  
>> understood.
>
> Harmony almost certainly won't use the pseudocode specification style
> of current ES specs.  So, I have no idea how long the spec will be.  I
> do know, however, that having more things to describe does not
> necessarily entail a longer text, and I also know that length and
> complexity don't have as simple a relation to one another as you seem
> to imply.

The relations are not simple. But I have to say that the lambda-coded  
for loop examples:

https://mail.mozilla.org/pipermail/es-discuss/2008-October/007822.html

were not what I would call clear specifications -- at least not to the  
audience of JS implementors working in C++ or a similar language, and  
not experienced lambda-coders.

/be
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20081209/3f78665b/attachment.html>