[Haskell-cafe] I want to write a compiler

[Austin Seipp]

Excerpts from John Meacham's message of Mon Mar 09 07:28:25 -0500 2009:
> 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.

Indeed, I stumbled upon it whilst looking at how unsafeCoerce worked
(to find out it is super-duper-special and implemented as part of E.)
I think it's actually pretty clever, and who knows, maybe it could be
useful as at least a debugging aid. :)

> 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
> 

This is a very good point I hadn't even thought about! Indeed, since
GRIN represents thunks in a defunctionalized way - encoded as nodes -
dealing with boxed/unboxed values becomes more of the compiler's job,
since the nature of unboxed values etc. becomes more transparent.

Since you bring this up, I figure this decision also had some
influence on E in lhc/jhc, considering its type system is rich enough
to distinguish values in whnf/boxed/unboxed etc.?

Austin