On Tuesday 05 August 2003 1:51 pm, Simon Peyton-Jones wrote:
The real question is: why does GHC distinguish kind * from kind #?
For example, Int has kind * Int# has kind #
The main reason is this: a polymorphic function assumes that values of type 'a' are represented by a pointer. For example: const :: a -> b -> a const assumes that its arguments are represented by pointers. The machine instructions simply would not work if it was passed (say) two double-precision floats, of type Double#.
All right. I do expect the compiler to yell if a polymorphic function is ever effectively applied to an unboxed value. Does this mean that forcing kinds to # will not work, for example as in
id# :: (a :: # ) -> a id# x = x ? For some reason GHC does not produce any code for this definition, although it seems to be able to inline it and simplify it away.
In the particular case I am considering, I do expect all polymorphic functions to have been inlined and simplified away. Would it make sense to have GHC complain about polymorphic functions being applied to unboxed values as late as possible? Since it really is an implementation issue, couldn't the restriction be postponed until after inlining and simplification (since GHC does a great job there)? I understand that it would make it difficult for a programmer to know when some piece of code will be accepted or rejected. So maybe I should just use Template Haskell for those portions of the code that have to avoid manipulating boxed values. I guess that would allow me to use do-notation. Thanks for the clarifications! -- Sebastien