Opened 9 years ago

Closed 5 years ago

#2959 closed feature request (wontfix)

Merge in LambdaVM (Haskell to Java/JVM bytecode translator)

Reported by: kgardas Owned by:
Priority: normal Milestone:
Component: Compiler Version: 6.11
Keywords: Cc: andy.adamsmoran@…, johnw@…
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:


Hello, it would really be nice to see LambdaVM[1] merged in. I'm afraid that with GHC quickly evolving we might end with LambdaVM drifting away to the nearly unmergeable state. It would be a pity definitely, since IMHO there is a lot of work presented in this Haskel->JVM implementation. Thanks for considering it! Karel [1]:

Change History (9)

comment:1 Changed 9 years ago by igloo

difficulty: Unknown
Milestone: 6.12 branch

The problem with merging it in (apart from the initial work to do the merge) is that then people working on GHC need to keep it working.

Could it be easily modified to use the GHC API instead?

comment:2 Changed 8 years ago by guest

I want to give my vote for Karel's request.

comment:3 Changed 8 years ago by simonmar

Milestone: 6.12 branch_|_

For this to be merged in, we need at the very least

  • an active maintainer, willing to work with us to merge it and to keep it working
  • tests
  • documentation

And we'd need to do a thorough code and design review. This is a significant piece of work, and so far we've had no interaction with anyone involved in building it.

For now, I'm moving it out of the 6.12.1 milestone, since I very much doubt that it can happen in that timeframe. If the pieces come together, then we can consider it for a future milestone.

comment:4 Changed 8 years ago by ganesh

Type of failure: None/Unknown

See also #368

comment:5 Changed 8 years ago by balliet

Hi, I'm the author of LambdaVM. I was recently pointed here by a potential LambdaVM user, I had no idea a ticket existed for it. Apologies for not posting sooner.

I'd agree with Simon M that LambdaVM is really in no state to be merged into the GHC tree right now. Aside from me not having time right now to update it for GHC HEAD, and maintain it, there are a few other issues:

  • At the time I was writing LambdaVM I was more or less using the LambdaVM tree as my GHC playground. There are lots of patches that aren't directly related to LambdaVM. Some of them probably should probably be dumped, and others merged separately from LambdaVM. This all needs to be sorted out.
  • I made lots of deep changes to the compiler that might sit well with everyone. For example, plumbing sub-word size types (Word8#, etc) though the whole compiler, to better support interfacing with existing java code. I split the unlifted kind into ptr and non-ptr subkinds, to support some level of polymorphism with unlifted types (java object types are foreign imported unlifted types). The unboxed array types are parametrized over their element type (for example UArray# Word#), since int[] and byte[] are very different in the JVM. Finding a happy medium between proper JVM support and over complicating the rest of the compiler will probably take some work.
  • I'm not happy at all with how the JVM backend is invoked. Right now it is setup as a separate "way", which was convenient because I could have a native and JVM compiler in one binary, but I think I'm really abusing the "way" system with this. We'd have to figure out a story for cross compilers (which is more or less what LambdaVM is). I hate to have to do what gcc does, and require a totally separate binary for each target. It seems that with all the DynFlags plumbing that is already in place supporting multiple targets in one binary (at least in the front end at least) should be possible.

And that is just the stuff I could remember off the top of my head (which hasn't been in it for a while).

While I wouldn't hold your breath waiting for this all to come together, I wouldn't give up on it yet. I still have to finish my thesis (which is the reason LambdaVM exists) one of these days (hopefully soon, the school isn't going to be happy with me if I don't get on that...) and when that happens I'll certainly update LambdaVM to GHC HEAD. After the thesis is behind me I can think about trying to merge it. So stay tuned.

comment:6 Changed 5 years ago by morabbin

Cc: andy.adamsmoran@… added

What's the status of LambdaVM?

comment:7 Changed 5 years ago by JohnWiegley


comment:8 Changed 5 years ago by JohnWiegley

Cc: johnw@… added

comment:9 Changed 5 years ago by igloo

Resolution: wontfix
Status: newclosed

In the absence of evidence to the contrary, I assume that it is still not suitable for merging, so I'll close the ticket.

Note: See TracTickets for help on using tickets.