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

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