Proposal: Expose Coercions for unboxed arrays

[David Feuer]

Richard, there's currently no way to change the roles in different modules,
but it's possible to "tunnel" through the roles using Coercions exposed by
the defining module (in which the user-provided roles are ignored).

On Dec 6, 2016 10:40 PM, "Richard Eisenberg" <eir at cis.upenn.edu> wrote:

> I don't have an opinion about whether or not David's design is desirable,
> but I can comment on implementation feasibility.
>
> GHC doesn't have a built-in way to have certain roles in some modules and
> other roles in other modules. I don't see anything drastically wrong with
> such a feature, but it does not currently exist. So to implement David's
> suggestion, we would have to have version of these types exposed from some
> Unsafe module and then newtypes around each one exposed in the normal
> interface.
>
> Unless someone sees another way, which I may well have missed.
>
> Richard
>
> > On Dec 5, 2016, at 2:18 PM, David Feuer <david.feuer at gmail.com> wrote:
> >
> > As discussed in [1], we now have
> >
> > type role Array nominal representational
> > type role IOArray nominal representational
> > type role UArray nominal nominal
> > type role IOUArray nominal nominal
> > type role StorableArray nominal nominal
> > type role STArray nominal nominal representational
> > type role STUArray nominal nominal nominal
> >
> > There are good reasons for these, as described in the ticket, but in
> > some particular cases, they're overkill. It might be nice to expose
> > the representational equivalence locally, with the understanding that
> > the user has to ensure that the Ix, Storable, etc., instances are
> > compatible. I think the place for these is likely Data.Array.Unsafe,
> > although they'd need to be defined in GHC.Arr. For boxed arrays, it's
> > sufficient to expose a Coercion between partially applied
> > constructors. For unboxed arrays, such a coercion doesn't do much
> > (because the element type has a nominal role), so I think only
> > Coercions between the fully-applied constructors are really useful for
> > those. For STArray and STUArray, I don't *think* we want to expose a
> > coercion to change the state thread type; anyone fussing at such a low
> > level is probably importing GHC.Arr anyway.
> >
> > arrayCoercion :: Coercible i j => Coercion (Array i) (Array j)
> > ioarrayCoercion :: ...
> >
> > uarrayCoercion :: (Coercible i j, Coercible a b) => Coercion (UArray i
> > a) (UArray j b)
> > iouarrayCoercion :: ...
> > storablearrayCoercion :: ...
> >
> > starrayCoercion :: Coercible i j => Coercion (STArray s i) (STArray s j)
> > stuarrayCoercion :: (Coercible i j, Coercible a b) => Coercion
> > (STUArray s i a) (STUArray s j b)
> >
> > [1] https://ghc.haskell.org/trac/ghc/ticket/9220
> > _______________________________________________
> > Libraries mailing list
> > Libraries at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20161206/2a047d39/attachment.html>