Polymorphic kinds

[Simon Peyton-Jones]

| 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 =3D x

That should really be rejected. You couldn't call it because you'd have
to instantiate 'a' to Int# or Double#, and that would mean different
code for different calls.

| 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)?

One could imagine that, but the error messages would be utterly opaque
-- because they'd refer to code that was quite different to what the
programmer wrote.  I don't know how to make this work nicely, I'm
afraid. =20

One clue: take a look at the UArray library. =20
=09
http://www.haskell.org/ghc/docs/latest/html/base/Data.Array.Unboxed.html

UArray is parameterised by Int, Float, Double, but it describes arrays
that hold Int#, Float#, Double# respectively.  Maybe you could re-use
ideas from there?

Simon

|=20
| 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.
|=20
| Thanks for the clarifications!
|=20
| --
| Sebastien