#9220: type roles for unboxed arrays -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.8.1 Libraries | 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 ekmett): (Wrote the bulk of this before you replied, figured I'd send it anyways) Hrmm, actually one could argue a stronger statement, it seems to me that Plan B is inconsistent. How would you even construct a type for, say, endian swapping, or going to/from network order for a Word32 upon storage, you'd still want the underlying type to be a newtype, rather than just randomly throw in a bottom with an unnecessary 'data' for no reason, and I've seen both of these as instances in the wild as part of larger Storable types. Also merely having sizeOf agree isn't sufficient to ensure correctness. Consider the above case of order swapping on storage, sizeOf gives the same answer in the above case, and if you coerced a boxed array nothing changes, but if you coerced an unboxed array you'd get all the characters spontaneously byte reversing due to effectively going through a "reinterpret_cast<>". It strikes me that two very different things would be happening semantically there, so having UArray have a nominal element type, even though Array is able to (and should be) representational makes sense to me. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9220#comment:22 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler