#2959: Merge in LambdaVM (Haskell to Java/JVM bytecode translator)
---------------------------------+------------------------------------------
Reporter: kgardas | Owner:
Type: feature request | Status: new
Priority: normal | Milestone: _|_
Component: Compiler | Version: 6.11
Keywords: | Difficulty: Unknown
Os: Unknown/Multiple | Testcase:
Architecture: Unknown/Multiple | Failure: None/Unknown
---------------------------------+------------------------------------------
Comment(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.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2959#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
