Concise functions, Nonexistent lambdas, Explicit tail calls

Jon Zeppieri jaz at bu.edu
Tue Dec 9 16:15:05 PST 2008


On Tue, Dec 9, 2008 at 5:42 PM, Michael Day <mikeday at yeslogic.com> wrote:
> Hi Jon,
>
>> This will break existing code:
>>
>> http://www.google.com/codesearch?q=lang%3Ajavascript+%22var+fun%22&hl=en&btnG=Search+Code
>
> As will "lambda":
> http://www.google.com/codesearch?hl=en&lr=&q=lang%3Ajavascript+%22var+lambda%22&sbtn=Search
>
> 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.


>
>> 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.

>
>>> Refraining from adding a new lambda construct will make JavaScript easier
>>> to
>>> specify...
>>
>> If you're right about this, I'd consider it a powerful argument
>> against the lambda proposal.  It's not obvious, however.
>
> 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.


> And I'm not convinced that describing functions in terms of lambdas makes
> them easier for implementors to understand than just describing their
> behaviour directly.

What does it mean to describe their behavior "directly"?  The current
ES specifications use a certain style of pseudo-assembly, along with a
host of fictional entities, attributes, &c.  That is to say, they use
a certain ad-hoc language that may or may not reflect the structure of
an actual implementation.  How is a description in this language any
more direct than a description in an extended lambda calculus?
They're both specification languages, only the latter is far better
understood.

-Jon


More information about the Es-discuss mailing list