[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 simonpj):

 Here's my summary

  * Plan A:
    * If an unboxed array of `Age` stores (unboxed) ages in a 16-bit field,
 but an unboxed array of `Int` stores (unboxed) ints in a 32-bit field,
 then it would be wrong to coerce from unboxed-array-of-`Age` to unboxed-
 array-of-`Int`.  (The field width is described by `sizeOf` in the
 `Storable` class.)
    * This is not an unreasonable scenario.  Perhaps you invented the
 newtype precisely because ages have a narrower range of values than ints.
    * In that case, unboxed arrays should have nominal role for their
 element type, and the GND example in comment:11 should rightfully fail.

  * Plan B:
    * An alternative is to insist that the `sizeOf` method should yield the
 same result for a newtype as for its underlying representation type.
    * Then a representational role for the element type would be justified.
    * Which would allow more expressive coercions; notably the GND in
 comment:11

 I was originally voting for Plan B.  But (a) it relies on an unenforced
 user convention about `Storable` instances, and (b) there are reasonable
 situations in which you might want a different width for a newtype.

 So on reflection I think Plan A is probably right.  If we adopt it, we
 should add a digest of this thread (e.g. the above Plan A/B notes) as a
 Note with the role declaration.

 The core-libraries committee is already cc'd.  Edward, we need a decision
 for 7.10.  Thanks.

 Simon

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9220#comment:18>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler