Isaac Schlueter wrote:
So, assuming that these two are valid function expressions that mean
roughly the same thing:
a: (x) { return "x" }
b: function (x) "x"
and then you might conclude that this is as well:
c: (x) "x"
So far, so good, I think.
What about these?
d: (x) (y)
e: (x) (y) { return "z" }
f: (x) (y) ("z")
g: (x) (y) "z"
Leaving aside block lambda TCP freaky-deakiness, I'm not sure mentally
how to even parse those. I suppose you could just say that you're not
allowed to start an expression-bodied-auto-return function with a (,
maybe?
I'm not sure. But it is certainly weird and confusing.
If e and g both desugar to:
h: function (x) { return function (y) { return "z" }}
+1! (how else should they be? IMO, this is the only sane interpretation)
Alas :-/ you would need infinite lookahead since you can't tell it from
the call. The best thing would be if there are other parens to use
instead of ( and ) for this(ese) shorter function(s).
[=x, y] x+y // function (x, y) { return x+y; }
[=x] [=y] "z" // function (x) { return function (y) { return "z"; }; }
[=x] (y) "z" // error anyway
[=x] (y) (z) // 1. function (x) { return (y)(z); } |
// 2. (function (x) { return (y); })(z);
// Probably the former.
I also though about using
<x, y> x+y
<x> <y> "z"
<x> (y) "z"
<x> (y) (z)
I can see only minor problems: cannot pack tightly with < and << (but
who would compare or bitshift by function; this should not happen often)
and parameter default values using '>'.
Possible Smalltalk-inspired precedent is also:
(:x, y) x+y
(:x) (:y) "z"
(:x) (y) "z"
(:x) (y) (z)
I think I like this most...
Herby
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
