[Haskell-cafe] Haskell on JVM
pumpkingod at gmail.com
Fri Jun 26 13:44:20 EDT 2009
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<john at 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.
> 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
>>> 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
>> to the calling method/function.
>> With the heavy use of recursion in functional programs, this is an
>> feature in a language implementation to avoid stack overflows.
>> Some language implementations (Scala) can do partial workarounds by
>> the generated code into a loop in the compiler, but this is frequently
>> to only deal with self-recursive calls, and does not deal with the general
>> (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
>> implementation, and would result in a situation where the behaviour of
>> program depends on particular implementations/versions/parameters of the
>> running it. That is something to be avoided if possible.
>> Maarten Hazewinkel
>> maarten.hazewinkel at gmail.com
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
More information about the Haskell-Cafe