[Haskell-cafe] Haskell on JVM

Simon, et al, It might be interesting to look at CALas a non-blank-slate beginning for Haskell on the JVM. To my mind there are three things that this needs to make it a real winner: - Much, much better Java interop. Basically, the bar to meet here is S

Re: [Haskell-cafe] Haskell on JVM

Incidentally, I am looking for someone well versed in the JVM who wants to help spearhead a JVM back end for jhc. If someone is interested, please join the j...@haskell.org mailing list. Jhc already cross compiles to a number of architectures so it may be an easier task than a ghc port. (or good pr

Re: [Haskell-cafe] Haskell on JVM

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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/ma

Re: [Haskell-cafe] Haskell on JVM

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? > > --

Re: [Haskell-cafe] Haskell on JVM

> 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, togeth

Re: [Haskell-cafe] Haskell on JVM

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.

Re: [Haskell-cafe] Haskell on JVM

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 functi

Re: [Haskell-cafe] Haskell on JVM

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. >

Re: [Haskell-cafe] Haskell on JVM

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, Sc

Re: [Haskell-cafe] Haskell on JVM

On Fri, Jun 26, 2009 at 7:12 AM, David Leimbach wrote: > There has been a scheme with tail recursion on the JVM for a long time > IIRC. SISC right? > Ah SISC is interpreted. Clojure is compiled. At least that may be the key difference to making it work or not. > > At least I am fairly certai

Re: [Haskell-cafe] Haskell on JVM

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

Re: [Haskell-cafe] Haskell on JVM

Since the JVM doesn't seem to support tail call optimization, I suppose one could could directly manipulate the bytecodes generated by jhc to do TCO. One challenge would be the garbage collector, since Haskell and Java have very different working sets of what is still being used. -- Regards, Casey

Re: [Haskell-cafe] Haskell on JVM

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-br

Re: [Haskell-cafe] Haskell on JVM

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 wrote: > > JVM

Re: [Haskell-cafe] Haskell on JVM

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? >

Re: [Haskell-cafe] Haskell on JVM

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 fas

Re: [Haskell-cafe] Haskell on JVM

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

Re: [Haskell-cafe] Haskell on JVM

On Fri, Jun 26, 2009 at 03:26:34PM +0200, 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 examp

Re: [Haskell-cafe] Haskell on JVM

Claus Reinke wrote: |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. U