[GHC] #9220: type roles for unboxed arrays

[GHC]

#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