paren-free call expressions

Claus Reinke claus.reinke at
Thu May 26 01:19:47 PDT 2011

> ECMAScript doesn't curry its function declarations. A function does take 
> all its arguments at once (and not as a tuple value), and since we can 
> even supply too few or too many arguments when calling a function, trying 
> to
> mimic SML will only bring pain.

I thought so, too, for a long time. But it turns out that ECMAScript
already supports currying, in definitions and applications, including
the usual application by juxtaposition syntax (curried definitions are
more awkward).

What is confusing the issue is that each ES function takes a single
argument, but that argument is a variable-length array in disguise,
not a fixed-size tuple. Also, the syntax for curried function definitions
is so awkward that programmers prefer to pack their arguments
into a single argument array (uncurried).

Current practice:

// curried
function addC(x) { return function (y) { return x+y; }; }
log( addC (1) (2) );

// uncurried
function add (x,y) { return x+y; }
log( add (1,2) );

// the arguments list really wants to be an array
function addA () { return arguments[0]+arguments[1]; }
var args = [1,2];
log( addA.apply (null,args) );

Part of the Harmony proposals is to make this last point
clearer, by introducing destructuring of formal parameters,
spreads for arrays and rest parameters

// the arguments list really wants to be an array
function addH (...args) { return args[0]+args[1]; }
let args = [1,2];
log( addH (...args) );

This makes it fairly obvious that the argument "list", which
is commonly used as an arguments array, can also be seen
as an array argument with non-standard syntax.

If we look at the addC example again, we already have
paren-free _calls_ in ES, it is just that ES forces us to _wrap
every argument_ -even numeric literals- in an array, written
in parens instead of brackets.

The ES way towards fully paren-free call syntax seems to
go via:

    (a) making curried definitions simpler
    (b) not having to wrap each argument as an array,
        (in the same step, we would start using [..] instead
          of (..) if we really mean to pass an array)

That does not mean that this will be trivial to accomplish
within the constraints of backwards compatibility and ES
grammar. My own attempt is still pretty awkward

    Flattening syntactic tail nests (paren-free, continued)

    Control structure proxies (aka monads, cps, and their relatives)

but if more hands, eyes, and minds could join the attempt,
I do not think ES is beyond hope here!-)

> Much as I like SML and Haskell, their function application syntax 
> (literally "exp ::= exp_1 exp_2" [1]) just won't work for ECMAScript. It's 
> pretty in its simplicity, but ECMAScript is long past simplicity on this 
> point.

ES can't afford to lose support for its vast and variable installed
code base, but that does not imply that simplicity cannot be
offered as an option. The need is there, so big indeed that real
world JS programmers introduce preprocessors to make their
work easier. Some of them would jump at the opportunity to
drop their preprocessing (perhaps not the preprocessor authors;-).



More information about the es-discuss mailing list