recursive arrow functions
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" -
> Is that really going to be the case ? I was so much looking forward to
> [proper tail
> 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
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