On Sun, Jun 15, 2014 at 10:10 PM,
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/