[Haskell-cafe] Haskell/JDK/tail-calls etc. (please vote on bug No. 6804517)

[Jason Dagit]

On Sun, Sep 19, 2010 at 5:15 PM, Stephen Sinclair <radarsat1 at gmail.com> wrote:
> On Sun, Sep 19, 2010 at 3:51 PM, Karel Gardas <karel.gardas at centrum.cz> wrote:
>>
>> Hello,
>>
>> from time to time request for Haskell running on top of Java's VM pops
>> on the haskell related mailing list and then usually dies off when
>> someone mentions that JDK does not have proper support for tail-calls. I
>> think haskell community might do something with this fact or at least
>> attempt to do something with it. I think the proper request for
>> enhancement is here:
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6804517
>>
>> if you agree with it (as it's proposed on the rfe's mentioned blog
>> article[1]), then please either join or if you are already a member of
>> SDN then just login and vote for this bug. That's something we can do
>> for free and will take just few minutes yet perhaps push a little bit
>> more weight behind this bug (err, just 4 votes now, why's that?).
>
> Even if tail recursion is not properly supported, I've never really
> understood why this is an *total* impediment to getting it working on
> the JVM.  I mean, yes it sucks, but there are ways to do it anyway
> (trampolining for one).  They are usually _slow_ methods (which
> trampoline is), but if it's the difference between being able to run
> on the JVM and not, you would think that someone would think running
> on JVM slowly is better than not running on it at all...
>
> Maybe that's not the case though, maybe it would actually be bad for
> Haskell's rep to run slowly on JVM compared to other languages.

I don't think the biggest hurdles to running Haskell on the JVM are
related to tail call [1].  Lazy evaluation mostly gets rid of the
need, but having it has been shown to be beneficial [2].

There have been successful attempts to get Haskell on the JVM [3].

The big problems, as I understand them, are maintenance and type
interaction at the source to source level (Haskell <--> Java).
Rewriting GHC's RTS to work on the JVM is a big engineering effort and
maintaining the JVM RTS and compiler backend is a task that the Simons
have said they don't want to take on.  They have said that they would
accept those changes in GHC if someone else was willing and able to
maintain that part of the compiler [4].

The source to source interactions between Java and Haskell have been
solved in packages like jvm-bridge [5], but I'm not sure if that
approach would work for a Haskell to JVM compiler.

I think the lack of tail call hurts the effort but is not a show
stopper by any means.  In fact, I don't believe there are any show
stoppers at the technical level and if GHC ever gets a proper
volunteer to maintain the JVM support then I think it would be all
green lights.  As SPJ points out in [1], Scala gets by without the JVM
supporting "proper" tail call.

I hope that helps!
Jason

[1] http://www.mail-archive.com/haskell-cafe@haskell.org/msg47997.html
[2] http://cgi.cse.unsw.edu.au/~dons/blog/2008/05/16#fast
[3] http://www.cs.rit.edu/~bja8464/lambdavm/
[5] http://haskell.org/haskellwiki/GHC:FAQ#Why_isn.27t_GHC_available_for_.NET_or_on_the_JVM.3F
[5] http://semantic.org/jvm-bridge/