On Nov 30, 2008, at 12:28 AM, Peter Michaux wrote:

On Sat, Nov 29, 2008 at 11:53 PM, Brendan Eich <[EMAIL PROTECTED]> wrote:
On Nov 29, 2008, at 11:33 PM, Peter Michaux wrote:

This would allow writing

var foo = {|a, b, c| ...};

which could be written even shorter as

var foo(a, b, c) {...};

Why ever would you want to use 'var' there? Could foo be reassigned to
denote 42, or "hello"?

Yes it could be reassigned.

You didn't say why, though -- what is the use-case?


The later is more consistent with the following which would also be
necessary at times.

lambda(a, b, c) {...}

Necessary for what use-case?

I believe the same ones as for {|a, b, c| ...}. For example, if one
wants to pass an anonymous lambda to another lambda.

But why do you need to start such a lambda *expression* with a Greek letter-name keyword?

Function expressions and definitions in ES3 start with 'function', true enough. Allen's lambda syntax is simply an alternative proposal for the expression case. It doesn't make a compound lambda + binding form.


lambda(a, b, c) {...}
function(a, b, c) {...}
class(a, b, c) {...}

Especially the syntax for lambda and function declarations seem as
though they should be symmetrical because they will be called the same
way: "foo()".

This seems good as far as it goes, but the 'lambda' keyword is overlong and obscure to some (I already agreed with you that it's le mot juste in a previous thread; but Allen's proposal avoids any mot at all, in favor of punctuation).

But why have three defining forms for callables? Sure, compatibility may require two. But three? The weakest link here is class, without more motivation (which I believe exists, see below).


This also makes me thing that class's should be called
the same way. That is, the "new" should be optional just like it is
for Array constructor, for example.

Some constructors behave differently when called. This could be considered a rare quirk but (1) people like doing it in their own abstractions; (2) it's desirable for self-hosting the quirky built-ins.

But again, a class is not just another kind of function. It's a higher- integrity factory for higher-integrity instances. Whether one calls it via new or directly as a function is secondary. Its syntax can differ from function if necessary (not gratuitously).

IOW I think your argument oversimplifies.

I believe that TC39 agrees that classes should be generative (nesting a class in another class or function makes a new, distinct class "type" on each evaluation), and (unrelated point) optionally anonymous as your list shows. But this does not follow simply from borrowed/ desugared-to function syntax or semantics. Classes may grow hair that functions won't, and lambdas must not (if they are to be worthy of the name).

/be
_______________________________________________
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to