Re: [Haskell-cafe] jhc speed

2009/2/22 Luke Palmer :

On Sun, Feb 22, 2009 at 8:15 AM, John Meacham 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%3ATypecheck... 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