[erlang-questions] re cursive fun()
Tue Oct 7 13:32:37 CEST 2008
On Tue, Oct 7, 2008 at 4:43 AM, Richard O'Keefe <ok@REDACTED> wrote:
> On 6 Oct 2008, at 3:11 am, Ciprian Dorin Craciun wrote:
> > About this subject, I would ask if isn't it better / easier /
> > clearer to add a special function name / keyword that would refer to
> > the function itself. This would also have a few advantages:
> Please write an EEP about this.
> > * first it will solve the recursivity problem described above;
> The particular example here seems to be one that would have been
> better addressed using existing debugging tools.
> Recursiveness is not a problem; it's *anonymous* recursive
> > * (maybe) it could also improve efficiency (because you know
> > exactly what function you're calling, without any lookup); (this is
> > just an assumption, maybe inside the beam file the lookup does not
> > exist); (certainly it is more efficient than the proposed solution ---
> > sending the function as an argument;)
> The best recommendation that has been given is to use a plain
> ordinary top level function. This is _already_ more efficient
> than anything based on funs could be (because it is _certain_
> not to need to unpack or repack outer variables), and it is
> certainly easier to get your head around (*some* variables
> in a function refer to outer variables, *some* do not,
> despite having the same name as outer variables).
> > * it will assist in refactoring --- changing a recursive function
> > name will have no impact on it's code;
> Yes it will. Suppose we add something like
> Factorial = fun:Self (N) when N > 1 -> N*Self(N-1)
> ; (N) when N >= 0 -> 1
> [Factorial(X) || X <- [3,1,4,1,5,9,2,6,5,3,5]]
> Changing "Self" in one place means it had better be changed
> in other places. For that matter, changing "Factorial" in
> one place means it has to be changed in other places.
> > * it could clearly mark the fact that the function calls itself.
> It's hard to see how. The mere existence of a mark (such as :Self)
> is no guarantee that the body of the function *uses* it. And if
> you are thinking in terms of something like this_fun(), please,
> we've suffered enough from C already, and don't need any more like
> that. Consider
> F = fun:Outer (...) ->
> ... G = fun:Inner (...) ->
> ... Inner(X) ...
> ... Outer(Y) ...
> ... Outer ... G ...
Is there any problem write this think this way?
F = begin
Outher = fun(OSelf, ...) ->
Inner = fun(ISelf, ....) ->
... ISelf(ISelf, X) ...
... OSelf(OSelf, Y) ...
... OSelf(OSelf, ...) ... Inner(Inner, ...) ...
fun(Args) -> Outher(Outher, Args) end
For Example factorial:
Fact = begin F = fun(_, 0) -> 1; (Self, N) -> Self(Self, N-1)*N end, fun(N)
-> F(F, N) end end.
Some nontrivial example:
4> UpToGen = begin
Outher = fun(_OSelf, M, M) -> ;
(OSelf, Step, M) ->
Inner = fun(_ISelf, N) when N>M -> ;
(ISelf, N) -> [N |
ISelf(ISelf, N+Step) ]
[Inner(Inner, 0) | OSelf(OSelf, Step+1, M)]
fun(Max) -> Outher(Outher, 1, Max) end
> With a hook like this, the inner function can not only refer to
> itself, but also to the function that contains it. With a
> 'this_fun()' approach, it can't.
> > As for disadvantages I really do not see any.
> Try looking just a _little_ harder.
> > P.S.: I think this solution could be equally applied to all
> > languages (mainly Lisp like).
> Most functional languages don't *need* it because they
> have 'letrec'. (In Lisp it's called 'labels'.)
> Even BCPL had letrec,
> let F(...) = E1
> and G(...) = E2
> and H(...) = E3
> was a letrec in which F G and H could refer to each other.
> > _______________________________________________
> > erlang-questions mailing list
> > erlang-questions@REDACTED
> > http://www.erlang.org/mailman/listinfo/erlang-questions
> erlang-questions mailing list
--Hynek (Pichi) Vychodil
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions