recursive arrow functions

Claus Reinke claus.reinke at talk21.com
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" - 
> http://www.yuiblog.com/blog/2012/03/30/what-is-the-meaning-of-this
>
> Is that really going to be the case ? I was so much looking forward to 
> [proper tail 
> calls](http://wiki.ecmascript.org/doku.php?id=harmony: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.

Claus
 



More information about the es-discuss mailing list