return page history
α-wwwiki
::
history/recursion/20130617-223749.txt
editor : alpha [82.249.195.240] 2013/06/17 22:37:49 _h1 recursion _p Today (on 2013/05/17) lambdatalk knows recursive functions through the javascript language : {pre 1) via a call to an inside recursive function °°{define fac (n) function _fac (n) { return (n< 1)? 1 : n*_fac(n-1); } return _fac(n); }°° -> {define fac (n) function _fac (n) { return (n< 1)? 1 : n*_fac(n-1); } return _fac(n); } °°{fac 6}°° -> {fac 6} 2) via an arguments.callee() °°{define fac2 (n) return (n< 1)? 1 : n*arguments.callee(n-1); }°° -> {define fac2 (n) return (n< 1)? 1 : n*arguments.callee(n-1);} °°{fac2 6}°° -> {fac2 6} 3) via a lambda function °°{{lambda (n) return (n< 1)? 1 : n*arguments.callee(n-1);} 6}°° -> {{lambda (n) return (n< 1)? 1 : n*arguments.callee(n-1);} 6} } _p The previous version of lambdatalk knew lisp-like recursion : {pre °° {define fac (n) {< n 1} 1 {* n {fac {-- n}}}} } °°} _p But the way the lambdatalk parser worked on recursive functions has been considered too "ugly" compared to the standard "native" way and has been abandonned. Until now ... Wait and see, and tomorrow recursion could reappear. Anyway, it has been seen that playing with the parser's loop consumes too much of the processor power and stack space to be a useful way ; calling the Javascript underlying language is certainly more effective.