recursive arrow functions

Claus Reinke claus.reinke at
Sun Apr 1 07:36:10 PDT 2012

> Today I have noticed one interesting remark from Douglas Crockford on 
> arrow functions: "you will need to use the old functions to write 
> self-recursive functions" - 
> Is that really going to be the case ? I was so much looking forward to 
> [proper tail 
> calls]( 
> and making arrow functions incompatible would be really bad, specially 
> since they seem to be more functiony than current functions. Why not allow 
> naming arrow function or have some syntax for making recursive calls ?

That post needs to be updated to the current spec (this-handling).
Since it is already attracting attention, it is too late to retract it.

Let-bindings already allow for some forms of recursion. To get
recursion at expression level, you can always define your own
recursion combinator. Something like

    // ref(f) produces f(rec(f) modulo some eta-expansions
    let rec = (f)=> (..args)=> f( (..args)=>rec(f)(..args), ..args )

Applying rec to an arrow function would supply the latter with a
self-reference and

    rec( (f,n) => (n>1 ? n*f(n-1) : n) )(6)

would then return 720. This would work even without consensus
on named arrow functions.

I would suggest that utilities like 'rec' and my earlier 'getthis'
(renamed to 'fn') should go into a standard library. To get a feel
for what other utilities make sense in ES6, partial implementations
of ES6 need to start supporting the (brand-new) arrow consensus.


More information about the es-discuss mailing list