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


More information about the es-discuss mailing list