Syntax sugar for partial application

Alexander Jones alex at
Thu Apr 9 21:44:01 UTC 2015

Using an indiscriminate `?` is quite inflexible as you wouldn't be able to
reorder the arguments.

In Swift there is a nice feature whereby you can avoid naming arguments in
closures and refer to the args by `$1` `$2` `$3` etc., e.g.

    val g = { f($1, foo, $2, bar, $3) }

which is equivalent to the more verbose

    val g = { arg1, arg2, arg3 in f(arg1, foo, arg2, bar, arg3) }

which is nice as it trivially unifies partial application with closure

Given that the boat has sailed on arrow functions in ES6 now, something like

    const g = ($1, $2, $3) => f($1, foo, $2, bar, $3)

could be shortened right now to

    const g = (...$) => f($[0], foo, $[1], bar, $[2])

and I suppose a new syntax could shorten that to something like

    const g = #f(#0, foo, #1, bar, #2)

which I naively believe wouldn't be too much of a problem for the grammar.
It doesn't really save you that much typing though.

(Also, re your comment about `this`, arrow functions explicitly have
lexical `this`!)

On 9 April 2015 at 15:11, Jussi Kalliokoski <jussi.kalliokoski at>

> On Thu, Apr 9, 2015 at 4:04 PM, liorean <liorean at> wrote:
>> Do we really need it?
>> Your «foo(1, ?, 2);» is equivalent to «a=>foo(1,a,2)».
>> Your «foo(?, 1, ???);» is equivalent to «(a,...b)=>foo(a,1,...b)».
>> Your «foo(1, ???, 2);» is equivalent to «(...a)=>foo(...[1,...a,2])».
> Not exactly. Using the placeholder syntax, `this` remains context
> dependent, whereas with your examples you get `null` as `this`.
> This might not seem like such a big deal until you consider it in
> combination with the proposed bind syntax [1].
> Also in your examples, redefining `foo` will lead to different results.
> The placeholder syntax has a lot more room for optimization in the JIT
> compiler (the partially applied result is guaranteed to have no side
> effects for example, so the compiler can create a version of the original
> function where it can inline the specified arguments; less moving parts,
> easier to optimize).
> [1]
>> Also, the ? token is already taken by the ternary conditional
>> operator. Do we really want to overload it here for a nullary
>> operator/special form, when we have as low overhead syntax as we
>> already do in fat arrows for doing the exact same thing?
>> --
>> David "liorean" Andersson
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at
> _______________________________________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list