[Haskell-cafe] improved jhc manual

[John Meacham]

On Sun, Jun 15, 2014 at 10:10 PM,  <musicdenotation at gmail.com> wrote:
> The implementation of unboxed types and defined kinds in JHC appears to be incompatible with GHC (`Int_` instead of `Int#`, `data kind` instead of just `data` and promote every suitable type). Please fix this.

They are different because they are somewhat different things. GHC and
jhc have very different intermediate and back end languages, ghc's is
based on system F with a backend distantly descended from the G
machine and jhc has an intermediate language based on a PTS similar to
the lambda-cube* and a backend descended from boquit's GRIN
intermediate language and these decisions constrain the semantics of
unboxed values for both compilers.

Likewise, the type systems are different in some ways, for instance
jhc supports polymorphism of unboxed types so there is no need for 1#
and 1## being different types. It has a different kind hierarchy
because in the back end 'evaluation' and 'case matching' are
independent operations which in ghc they are intertwined, so you can
directly branch on a value if you know it is already evaluated which
is a particularly advantagous. jhc unboxed constructors are normal so
no special Hash syntax is needed to denote them.

Since jhc has no run-time it's unboxed values need to be at a lower
level than GHC's to take advantage of optimizations based on that. For
instance, ghc has independent types for unboxed Int's and Word's,
however, as far as a CPU is concerned there are only values of a
certain bit width and no signendedness information is on the type. Jhc
follows CPU operations. It just happens that the instance Num Word in
jhc uses unsigned primitives and the instance Num Int uses signed ones
but they both are boxed 'Bits32_' underneath.

The kind extensions were independently developed hence the different
syntax, I am not a fan of eating syntax or filling the data tables
with most likely unused kinds automatically... but I  may change my
mind on that in the future, User defined kinds are still fairly new so
I want to see more how they are used in practice for a while, In any
case, PolyKinds are next up in the kind system for implementation.

*My IL is very similar to and was inspired by Henk actually
(http://www.staff.science.uu.nl/~jeuri101/MSc/jwroorda/)


-- 
John Meacham - http://notanumber.net/