[Haskell-cafe] Good article on why implementing a functional back end is really different

[Neil Mitchell]

Hi

> Help.  I need support for a technical argument: why going to an intermediate
> form for an existing functional back end like Haskell really, truly is
> better for implementing a functional language than is going to an
> intermediate form like the Java intermediate form and re-doing all the
> various specialized mechanism needed to support a true lazy functional
> language.

To clarify in my mind: You have a functional language, and you are
trying to debate whether to translate to a core language based on an
imperative model or a functional model is most appropriate?

I would suggest that both are appropriate. Typically, a tool will
first translate Haskell to a form of "Core" language, see the Yhc.Core
paper or the GHC.Core paper floating around for approximate details.
Both of these Core languages are essentially subsets of Haskell,
perhaps with some additional annotations etc.

After this, GHC converts to C--, and Yhc to bytecode - both following
a much more imperative model. From here they can be executed/compiled
as required.

Usually, performing optimisations/analysis on the Core language is
much more pleasant - so if you do need to do a substantial amount of
work on the Core language, a functional one would be advantageous. As
for directly translating from Haskell to Java, without going through a
Core language, I think that would be an example of premature
optimisation - you _will_ have a Core language representing desugared
Haskell somewhere, if you never have it explicit then it will only
exist in the minds of the programmers.

Thanks

Neil