[Haskell-cafe] jhc speed

[John A. De Goes]

I think doing this work would improve the design of GHC by improving  
modularity and factoring out generalized abstractions.

The richest possible core language makes the most sense for a common  
core, because what's not needed can always be discarded. From your  
description, it sounds like such a common core language would be a  
hybrid of jhc and ghc core, because each contains more information for  
particular subsets of the language.

Layering higher-level primitives on lower-level primitives also makes  
sense, as it's a very flexible approach.

How much support and direction can you provide if we get enough people  
interested in this?

Regards,

John A. De Goes
N-BRAIN, Inc.
The Evolution of Collaboration

http://www.n-brain.net    |    877-376-2724 x 101

On Feb 22, 2009, at 7:45 AM, John Meacham wrote:

> On Sun, Feb 22, 2009 at 07:25:26AM -0700, John A. De Goes wrote:
>>
>> Is there any conceivable factoring of GHC that would allow you to
>> sandwich the core of jhc in between the front and back ends of GHC?  
>> Or
>> are the architectures so fundamentally incompatible as to make this
>> impossible?
>
> Well, it wouldn't really be useful sandwiched between the front and  
> back
> end of ghc, the main advantages jhc has over ghc's model are in its
> lower level optimizations closer to the back end. Feeding ghc core  
> into
> jhc shouldn't be impossible. Oddly enough, I have written a ghc back  
> end
> for jhc, mainly for testing purposes rather than a serious back end.
>
> The tricky part isn't so much the translation of ghc to jhc core, the
> type system and representation are quite similar, but the difference  
> in
> the primitives that the two systems expect to exist. for instance, ghc
> has high level primitives, such as operations on Integers and  
> primitive
> types that high signedness. While jhcs primitives are much lower  
> level,
> it has no special concept of Integer for instance, you implement  
> Integer
> either in pure haskell code or FFI bindings to GMP or some other way,
> and jhc's primitive numerical types are simply bit patterns with no
> interpretation, for instance
>
> data Int = I Bits32_
> data Word = W Bits32_
>
> and the only thing that makes Int signed and Word not is in the 'Num'
> instances for those types.
>
> That said, i don't see any reason a ghc-core front end for jhc  
> wouldn't
> be possible, an adapter library could be written to provide ghc style
> primitives on top of the jhc ones. It would certainly be an  
> interesting
> project.
>
>
>        John
>
>
> -- 
> John Meacham - ⑆repetae.net⑆john⑈
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe