[Haskell-cafe] jhc speed

[Andrea Vezzosi]

2009/2/22 Luke Palmer <lrpalmer at gmail.com>:
> On Sun, Feb 22, 2009 at 8:15 AM, John Meacham <john at 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 at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>