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 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe