Concise functions, Nonexistent lambdas, Explicit tail calls
Brendan Eich
brendan at mozilla.com
Tue Dec 9 16:25:32 PST 2008
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>
More information about the Es-discuss
mailing list