Although I don't know what the current JVM lacks to properly act as a functional backend, it appears that JVM 1.7 will be at least better suitable to support dynamic languages. See: The Da Vinci Machine Project http://openjdk.java.net/projects/mlvm/ Arvid On Fri, Jun 26, 2009 at 2:09 PM, Timo B. Hübel wrote:

...

Incidentally, I am looking for someone well versed in the JVM who wants to help spearhead a JVM back end for jhc.

I would love to see this! With the current advent of all those languages targeting at the JVM (Groovy, Scala, Clojure) I think a JVM backend for a Haskell compiler could, together with proper Java interop, make for a major breakthrough of Haskell in general.

Unforunately, as I can tell from my halfknowledge, the JVM lacks some important functionality required for properly targeting functional language features on the JVM.

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?

Thanks, Timo _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

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. There is a conflict between preserving stack layout and efficient tail calls. Unfortunately, stack inspection appears to be used for security aspects in JVM. That doesn't make tail calls impossible, but may have slowed down progress as this argument always comes up in discussing tail calls on the JVM (since its byte code isn't just an internal detail, but an externally used API). None of the various partial workarounds are quite satisfactory (jumps work only locally, there is an upper size limit on how much code can be considered as local, trampolines return before each call, there are alternatives that clear the stack not before each call, but every n calls, ..., see the various Haskell to Java/JVM papers). I was curious about the current state (the issue is as old as JVM), and here's what I've found so far (more concrete/official info would be appreciated): tail calls in the VM [2007] http://blogs.sun.com/jrose/entry/tail_calls_in_the_vm RFE: Tail Call Optimization [2002] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4726340 [2009] http://wikis.sun.com/display/mlvm/TailCalls Tail Call Optimization in the Java HotSpot(TM) VM [2009] http://www.ssw.uni-linz.ac.at/Research/Papers/Schwaighofer09Master/ Still cooking, still not done, it seems, but perhaps closer than ever? Claus

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.hazewinkel@gmail.com

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On Fri, Jun 26, 2009 at 10:44 AM, Daniel Peebles wrote:

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?

As I recall, this has been tried, but there's a limit (64k?) on function body size that you immediately run in to. Also, this would seem likely to get seriously in the way of optimizations and use of the JVM's slightly-higher-than-assembly level of abstraction. I think the second reason, for example, is why people (to my knowledge) haven't tried the otherwise well suited Cheney-on-the-MTA scheme...Stack as nursery is cute, but I think you want to work with the JVM, not against it. AHH

I don't have a source, but I know tail calls have been implemented (in a patch) and tested, and at the JVM Summit everyone was saying this was definitely going to be released in JVM 7. 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 11:27 AM, Claus Reinke wrote:

...

JVM 7 has tail calls,

Source, please? JSR-292 seems the most likely candidate so far, and its draft doesn't seem to mention tail calls yet. As of March this year, the people working on tail calls for mlvm [1], which seems to be the experimentation ground for this, did not seem to expect any fast route:

http://mail.openjdk.java.net/pipermail/mlvm-dev/2009-March/000405.html

There have been years of rumours and plans, so it would be nice to have concrete details, before any fp-on-jvm implementation design starts to rely on this.

Claus

[1] http://openjdk.java.net/projects/mlvm/

There has been a scheme with tail recursion on the JVM for a long time IIRC. SISC right? At least I am fairly certain it does. On Friday, June 26, 2009, Timo B. Hübel wrote:

...

Incidentally, I am looking for someone well versed in the JVM who wants to help spearhead a JVM back end for jhc.

I would love to see this! With the current advent of all those languages targeting at the JVM (Groovy, Scala, Clojure) I think a JVM backend for a Haskell compiler could, together with proper Java interop, make for a major breakthrough of Haskell in general.

Unforunately, as I can tell from my halfknowledge, the JVM lacks some important functionality required for properly targeting functional language features on the JVM.

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?

Thanks, Timo _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Hi Timo, On Fri, Jun 26, 2009 at 5:09 AM, Timo B. Hübel wrote:

...

Incidentally, I am looking for someone well versed in the JVM who wants to help spearhead a JVM back end for jhc.

I would love to see this! With the current advent of all those languages targeting at the JVM (Groovy, Scala, Clojure) I think a JVM backend for a Haskell compiler could, together with proper Java interop, make for a major breakthrough of Haskell in general.

Unforunately, as I can tell from my halfknowledge, the JVM lacks some important functionality required for properly targeting functional language features on the JVM.

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?

My brief research into why the JVM lacks tail calls indicated that tail calls do not play nicely with the JVM security model and make stack traces harder to manage. Although, I have also heard that tail call of some form is expected to appear in java 1.7. Jason

Jason, CAL's syntax is not std Haskell syntax. Best wishes, --greg On Thu, Jun 25, 2009 at 11:10 AM, Jason Dusek wrote:

2009/06/24 Greg Meredith :

...

Better support for "std" Haskell syntax

What does this mean, actually? Better support for standard Haskell syntax than what?

-- Jason Dusek

-- L.G. Meredith Managing Partner Biosimilarity LLC 1219 NW 83rd St Seattle, WA 98117 +1 206.650.3740 http://biosimilarity.blogspot.com