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