Experimental compilation of Haskell to Erlang
Hi, Some time ago I became interested in compilation of Haskell programs (via Yhc Core) to Erlang to be able to run Haskell code in Erlang environment. This experiment seems to have been successful, so I'd like to publish its results for everyone to read and criticize. Results of the experiment are described in this Haskell Wiki article: http://www.haskell.org/haskellwiki/Yhc/Erlang/Proof_of_concept Any feedback is appreciated. Thanks. -- Dimitry Golubovsky Anywhere on the Web
Dimitry Golubovsky wrote:
Hi,
Some time ago I became interested in compilation of Haskell programs (via Yhc Core) to Erlang to be able to run Haskell code in Erlang environment.
Two (somewhat tangental) thoughts come to mind. 1. Should it not, in theory at least, be *relatively* easy to target Haskell at anything that has a graph reduction machine? (You target Erlang, somebody else has targetted JavaScript, I myself attempted to target Java...) 2. How come all these projects use Yhc? According to the wiki, Yhc doesn't even _work_ yet. What gives?
Hi
Some time ago I became interested in compilation of Haskell programs (via Yhc Core) to Erlang to be able to run Haskell code in Erlang environment.
Two (somewhat tangental) thoughts come to mind.
1. Should it not, in theory at least, be *relatively* easy to target Haskell at anything that has a graph reduction machine? (You target Erlang, somebody else has targetted JavaScript, I myself attempted to target Java...)
It's a fair bit of engineering work, there are some design decisions to be made - such as how to interface with the host language (if at all). Theoretically its not that hard to come up with something, but it is a fair amount of effort.
2. How come all these projects use Yhc? According to the wiki, Yhc doesn't even _work_ yet. What gives?
These projects use Yhc.Core - a Core language to which Haskell can be translated. At the moment, Yhc is the only compiler that can generate Yhc.Core, but Yhc.Core is a complete abstraction layer. There is currently work going on to translate GHC.Core to Yhc.Core, which would mean that you can then translate any GHC program (including rank-2-implicit-polymorphic-linear-super-ADTs etc.) to Yhc.Core, and then on to Erlang. The actual translation is trivial, but getting GHC.Core out of GHC for all the base libraries is hard. The reason I use Yhc.Core is because its a nice standalone library, with useful tools and functionality, which is highly stable. There is no library which is comparable. Thanks Neil
Neil Mitchell wrote:
Hi
Two (somewhat tangental) thoughts come to mind.
1. Should it not, in theory at least, be *relatively* easy to target Haskell at anything that has a graph reduction machine? (You target Erlang, somebody else has targetted JavaScript, I myself attempted to target Java...)
It's a fair bit of engineering work, there are some design decisions to be made - such as how to interface with the host language (if at all). Theoretically its not that hard to come up with something, but it is a fair amount of effort.
To be sure, I doubt it's what you'd call "trivial". I just ment it looks easier than, say, translating C to Pascal or something.
2. How come all these projects use Yhc? According to the wiki, Yhc doesn't even _work_ yet. What gives?
These projects use Yhc.Core - a Core language to which Haskell can be translated. At the moment, Yhc is the only compiler that can generate Yhc.Core, but Yhc.Core is a complete abstraction layer. There is currently work going on to translate GHC.Core to Yhc.Core, which would mean that you can then translate any GHC program (including rank-2-implicit-polymorphic-linear-super-ADTs etc.) to Yhc.Core, and then on to Erlang. The actual translation is trivial, but getting GHC.Core out of GHC for all the base libraries is hard.
The reason I use Yhc.Core is because its a nice standalone library, with useful tools and functionality, which is highly stable. There is no library which is comparable.
I see... [I think.]
On Mon, May 19, 2008 at 09:00:53PM +0100, Andrew Coppin wrote:
It's a fair bit of engineering work, there are some design decisions to be made - such as how to interface with the host language (if at all). Theoretically its not that hard to come up with something, but it is a fair amount of effort.
To be sure, I doubt it's what you'd call "trivial". I just ment it looks easier than, say, translating C to Pascal or something.
Actually, It is generally harder. The ghc back end for jhc was far more problematic than the C backend to keep working. The simple reason is what I call 'impedance mismatch'. ghc and jhc have sightly different semantics for unboxed values, the primitives don't quite map one to one. optimizations that are needed for jhc's back end hurt when translated to ghc. The high level of haskell is a hinderance more, because it means compilers do a lot more behind the scenes so there is a lot more "stuff" to cause conflicts. A graph reduction machine in C is fairly easy and only needs to be done once, but one size doesn't fit all and starting from scratch can be much easier than trying to shoehorn another back end onto your code. John -- John Meacham - ⑆repetae.net⑆john⑈
participants (4)
-
Andrew Coppin -
Dimitry Golubovsky -
John Meacham -
Neil Mitchell