optional "function" keyword
Herby Vojčík
herby at mailbox.sk
Fri Mar 9 00:02:35 PST 2012
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
More information about the es-discuss
mailing list