
| 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

On Tuesday 05 August 2003 4:00 pm, Simon Peyton-Jones wrote:
| > 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.
GHC (after modifying the parser to allow # to stand for the kind of unlifted type) seems to behave very nicely with this definition - it does not generate any code for it, and inlines its uses; so the problem never actually arises (but I expect it would for more complex code). I guess I shouldn't rely on that, anyhow.
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?
Interesting! It seems that just writing wrappers around my new primitive operations, that do boxing and unboxing as appropriate, works out just fine - GHC does all the expected unboxing. So it is not worth trying to work with boxed values directly. Great, thanks! :-) -- Sebastien
participants (2)
-
Sebastien Carlier
-
Simon Peyton-Jones