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@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
