Concise functions, Nonexistent lambdas, Explicit tail calls
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:
> As will "lambda":
> Or practically any other keyword we can think of. So this problem exists for
> other than opt-in to introduce to new keywords without breaking existing
Aside from picking really odd keywords? I don't think so. That's why
people have been discussing the use of non-identifier ASCII
>> 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.
>> 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
> 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
More information about the Es-discuss