[Haskell-cafe] jhc speed
John A. De Goes
john at n-brain.net
Sun Feb 22 10:48:57 EST 2009
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?
John A. De Goes
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?
>> are the architectures so fundamentally incompatible as to make this
> Well, it wouldn't really be useful sandwiched between the front and
> 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
> jhc shouldn't be impossible. Oddly enough, I have written a ghc back
> 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
> the primitives that the two systems expect to exist. for instance, ghc
> has high level primitives, such as operations on Integers and
> types that high signedness. While jhcs primitives are much lower
> it has no special concept of Integer for instance, you implement
> 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
> be possible, an adapter library could be written to provide ghc style
> primitives on top of the jhc ones. It would certainly be an
> John Meacham - ⑆repetae.net⑆john⑈
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
More information about the Haskell-Cafe