[Haskell-cafe] I want to write a compiler

[John Meacham]

On Sat, Mar 07, 2009 at 07:45:06PM -0600, Austin Seipp wrote:
> (On that note, I am currently of the opinion that most of LHC's major
> deficiencies, aside from a few parser bugs or some needed
> optimizations, comes from the fact that compiling to C is currently
> our only option; because of it, we have no exception handling or
> proper garbage collection at all. As well, the runtime system is a
> little needlessly 'clever' (if small and understandable) so it can
> deal with that.)

It would be interesting if you could revive the ghc back end I wrote for
jhc in lhc. the code is still in the repository but was disabled a while
ago, and I was just fretting over whether I should just delete it from
the codebase as an interesting experiment. I mainly used it as a
debugging aid once upon a time, but it was difficult to keep up to date
with the C back end. I know it is sort of a silly back end, but it might
be interesting.

> Having dealt with GRIN as I work on LHC (when time now permits...) I
> can say that it's a reasonable strategy and in practice it turns out
> pretty well, but if you're not into optimizing the code, then STG
> might be a better fit.

I think a big deciding factor here would be the answer to one question
"do you want to deal with unboxed values in your compiler internally?"
As in, you plan on a lazy language, so, do you ever want to open up
those thunks and deal with unboxed values in your compiler guts or do
you want to treat them as abstract boxes to be evaluated by the runtime?
if you do want to think about unboxed values, for optimization or other
purposes, bite the bullet and go for something like GRIN as the back end
and support unboxed values all the way through to the front end from the
get go. If you really only want to support lazy thunks, go with one of
the quasi virtual machine style implementations like STG.

        John

-- 
John Meacham - ⑆repetae.net⑆john⑈