Polymorphic kinds

Simon Peyton-Jones simonpj@microsoft.com
Tue, 5 Aug 2003 16:00:10 +0100

| All right.  I do expect the compiler to yell if a polymorphic function
| 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

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?


| 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