Maybe the JVM could be abused so that all of the haskell code is within one "function", so as to avoid java's notion of a function boundary and implement our own using just goto? Or does the JIT operate on entire functions at a time?
On Fri, Jun 26, 2009 at 1:23 PM, John A. De Goes<j...@n-brain.net> wrote: > > JVM 7 has tail calls, and if you don't want to wait for that, "goto" works > perfectly well for self-recursive functions. Other techniques can deal with > mutual recursion, albeit at the cost of performance. > > Regards, > > John A. De Goes > N-Brain, Inc. > The Evolution of Collaboration > > http://www.n-brain.net | 877-376-2724 x 101 > > On Jun 26, 2009, at 6:26 AM, Maarten Hazewinkel wrote: > >> >> On 26 Jun 2009, at 14:09, Timo B. Hübel wrote: >> >>> And here comes my question: If there is anybody with proper knowledge >>> about >>> this issue, I would really like to know what are those things that are >>> missing? For example, Clojure lacks proper tail recrusion optimization >>> due to >>> some missing functionality in the JVM. But does anybody know the details? >> >> Basically, the JVM lacks a native ability to do tail calls. It does not >> have an >> instruction to remove/replace a stack frame without executing an actual >> return >> to the calling method/function. >> >> With the heavy use of recursion in functional programs, this is an >> important >> feature in a language implementation to avoid stack overflows. >> >> Some language implementations (Scala) can do partial workarounds by >> turning >> the generated code into a loop in the compiler, but this is frequently >> limited >> to only deal with self-recursive calls, and does not deal with the general >> case >> (X-calls-Y-calls-Z-calls-X...), which a proper implementation of >> tail-calls at >> the JVM level would allow. >> >> At the JIT level (below the JVM spec level) some implementations may >> actually do >> the tail call optimization anyway, but this is beyond the control of a >> language >> implementation, and would result in a situation where the behaviour of >> your >> program depends on particular implementations/versions/parameters of the >> JVM >> running it. That is something to be avoided if possible. >> >> >> Maarten Hazewinkel >> maarten.hazewin...@gmail.com >> >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe