#9220: type roles for unboxed arrays -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries | Version: 7.8.1 (other) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): As I see it "representational" has to do with the representation of Haskell values as closures (usually on the heap). That's different from the representation of the "underlying value" in an unboxed or storable array. For example, if I needed to process packed arrays of 24-bit integers, I might create a newtype of Int and write a Storable instance for it with `sizeOf _ = 3`. (Admittedly this is a somewhat contrived scenario.) The same considerations also apply to `Ptr`. (Indeed, a storable array is little more than a `Ptr` under the hood.) But `Ptr` is an inherently unsafe/unmanaged sort of thing. If you want to know how many items' worth of space is allocated in an area pointed to by a `Ptr`, you have to keep track of it yourself. Unboxed/storable arrays are supposed to be a safe abstraction on top of raw memory areas. That's why I think it's reasonable to have different defaults between unboxed/storable arrays and `Ptr`s. (And it is in some sense a matter of defaults, since there is still `unsafeCoerce` when you happen to know that the memory layouts match up properly.) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9220#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler