
Implementing a JIT Compiled Language with Haskell and LLVM - andars
http://www.stephendiehl.com/llvm/
======
jpetitto
I've implemented this toy compiler (minus JIT) in Java, following the tutorial
on the LLVM website (which uses C). After browsing through the Haskell code,
it is incredible how much more suitable a statically-typed, functional
language is for compiler development when compared to an imperative language
like Java. The code is much more terse and most importantly, readable.

~~~
chrisseaton
Yes languages like Haskell and Lisp are excellent for compiler development, as
a compiler is one big pure function that involves a lot of transformations on
recursive data structures. And what are language academics interested in
doing? Implementing languages. So the languages they design are often suited
to that task.

~~~
tmk1108
Would you say something like Clojure is also suitable for compiler development
or not?

~~~
chrisseaton
Well any turing complete language is suitable for compiler development work,
but yeah Clojure is designed around symbolic computation, recursion and things
like that.

~~~
reitzensteinm
Can we stop pulling out this turing complete quip?

That's like asking on a cooking forum how to open a coconut, and the reply
being well any physical object with mass can technically open a coconut with
the correct application of force, but yeah, you should probably use a machete.

~~~
pron
BTW, the guy you replied to is part of the team working on what is probably
the most advanced compiler technology breakthrough in the last decade
(Truffle/Graal). So he's not "technically right", but has actually contributed
to the world's most revolutionary compiler (which is written neither in
Haskell nor a Lisp).

~~~
reitzensteinm
I was replying to what he said, not who he is.

~~~
pron
I think that's relevant context which proves that your analogy in this
particular case is inappropriate. He's a chef working in one of the world's
greatest restaurants and he's _not_ using a machete to open the coconut.
Therefore, there are probably good reasons to prefer another tool and the
advantages of a machete are probably not that big (or are offset by other
factors). Again -- in this particular case.

So while the "any Turing complete language" is an over-generalization, so is
"use the right tool for the job". Programming languages are not at all like
knives or hammers as they are 1/ terribly expensive 2/ require constant
training 3/ require specialization and 4/ each designed to be general-purpose.
It's more productive to use just one language you know best than keep
switching to a completely different one that's marginally better at the
particular task at hand.

------
jdreaver
This is common knowledge for a lot of people, but I have found the author's
"What I Wish I Knew When Learning Haskell" article is awesome too:

[http://dev.stephendiehl.com/hask/](http://dev.stephendiehl.com/hask/)

------
ghc
It just so happens that the author is hiring Haskell engineers right now to do
related work:
[https://twitter.com/smdiehl/status/642790047163375616](https://twitter.com/smdiehl/status/642790047163375616)

------
the_french
Last semester for a compiler course I was taking we had to implement a
compiler for a subset of Go (called GoLite), with free reign over language
choices. I chose to implement a compiler[0] using Haskell and LLVM, this
article helped a _lot_ when I was writing codegen, especially since it was my
first real Haskell project.

However, some of the most interesting and important issues are left out of it.
Some examples are implementing exceptions, threading, imports, garbage
collection, closures , etc.. I would love a more advanced version of this
article that discusses how to implement a more advanced compiler with more
modern features (specifically in LLVM).

[0] github.com/xldenis/mgc

------
arthurcolle
Sorry for offtopic but anyone know performance benchmarks LLVM vs BEAM ?

~~~
troutwine
They're not really comparable things. One is a bytecode VM (BEAM) and the
other is a bunch of compilation infrastructure. As well, BEAM is optimized for
heavy network-oriented concurrency and only incidentally is not-slow on a CPU.
If you run a CPU-only race with a BEAM targeting language (Erlang, Elixir, LFE
etc etc) you're going to be disappointed.

~~~
arthurcolle
Thank you for the compare/contrast!

