Polymorphic kinds

[Sebastien Carlier]

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