| 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 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. One clue: take a look at the UArray library. 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 | | 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