2009/2/22 Luke Palmer <lrpal...@gmail.com>: > On Sun, Feb 22, 2009 at 8:15 AM, John Meacham <j...@repetae.net> wrote: >> >> On Sun, Feb 22, 2009 at 03:36:34PM +0100, Peter Verswyvelen wrote: >> > Would it be possible to separate the frontend (Haskell to Core) and >> > backend >> > (Core to machine code) from the Haskell compilers (requiring a standard >> > Core >> > language?) >> > I'm not sure how many extensions required a change to the Core language. >> >> Well, it depends on what you mean by 'core'. If you mean a desugared >> version of haskell, I think such a front end could be quite useful. > > By the way, coming up pretty soon, I will need a desugared annotated Haskell > for Dana. If anybody has something like this in the works, I'd love to help > with it. If it does not exist by the time I need it, I will make it, so if > anyone is interested in working on it with me, let me know :-)
The ghc-api exposes a type for annotated source: http://haskell.org/ghc/docs/latest/html/libraries/ghc/GHC.html#t%3ATypecheckedSource Not that i know how to use it. > Luke > > >> >> in >> particular, I'd like to see a standalone implementation of template >> haskell. If you mean something lower level, as in the ghc core >> intermediate language the compiler uses internally, or jhc's core or >> grin representation, things get a bit more tricky. >> >> Although many core languages are somewhat similar, based on a typed >> lambda calculus of some sort, the details will differ, and translating >> between them can be lossy. >> >> For instance, looking at jhc core: >> http://repetae.net/computer/jhc/manual.html#jhc-core-type-system >> you can see it has a very rich language for dealing with strictness and >> boxedness. For instances, a boxed value known to be in WHNF actually has a >> different _type_ than one that is possibly unevaluated. Such >> distinctions are quite useful for jhc's back end but not so much for >> ghc's, hence ghc core doesn't make that distinction and any translation >> between the two would 'lose' that useful information. >> >> In other cases things are even worse, for instance ghc has a powerful >> type equality concept in its core language which jhc has no counterpart >> for, so that information will be lost on translation. But losing that >> information will actually cause the core to not type check, since ghc >> core can type some things jhc core cannot (and vice versa) so coercions >> or other mechanisms to bypass the type system will have to be >> introduced. >> >> So, it is certainly possible to translate between the two, in fact, I >> made a jhc core -> ghc core translator, but the code it produced was >> necessarily riddled with unsafeCoerce#'s for everywhere the type systems >> didn't quite match up. >> >> John >> >> >> -- >> John Meacham - ⑆repetae.net⑆john⑈ >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
