<div dir="auto">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).</div><div class="gmail_extra"><br><div class="gmail_quote">On Dec 6, 2016 10:40 PM, "Richard Eisenberg" <<a href="mailto:eir@cis.upenn.edu">eir@cis.upenn.edu</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I don't have an opinion about whether or not David's design is desirable, but I can comment on implementation feasibility.<br>
<br>
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.<br>
<br>
Unless someone sees another way, which I may well have missed.<br>
<br>
Richard<br>
<br>
> On Dec 5, 2016, at 2:18 PM, David Feuer <<a href="mailto:david.feuer@gmail.com">david.feuer@gmail.com</a>> wrote:<br>
><br>
> As discussed in [1], we now have<br>
><br>
> type role Array nominal representational<br>
> type role IOArray nominal representational<br>
> type role UArray nominal nominal<br>
> type role IOUArray nominal nominal<br>
> type role StorableArray nominal nominal<br>
> type role STArray nominal nominal representational<br>
> type role STUArray nominal nominal nominal<br>
><br>
> There are good reasons for these, as described in the ticket, but in<br>
> some particular cases, they're overkill. It might be nice to expose<br>
> the representational equivalence locally, with the understanding that<br>
> the user has to ensure that the Ix, Storable, etc., instances are<br>
> compatible. I think the place for these is likely Data.Array.Unsafe,<br>
> although they'd need to be defined in GHC.Arr. For boxed arrays, it's<br>
> sufficient to expose a Coercion between partially applied<br>
> constructors. For unboxed arrays, such a coercion doesn't do much<br>
> (because the element type has a nominal role), so I think only<br>
> Coercions between the fully-applied constructors are really useful for<br>
> those. For STArray and STUArray, I don't *think* we want to expose a<br>
> coercion to change the state thread type; anyone fussing at such a low<br>
> level is probably importing GHC.Arr anyway.<br>
><br>
> arrayCoercion :: Coercible i j => Coercion (Array i) (Array j)<br>
> ioarrayCoercion :: ...<br>
><br>
> uarrayCoercion :: (Coercible i j, Coercible a b) => Coercion (UArray i<br>
> a) (UArray j b)<br>
> iouarrayCoercion :: ...<br>
> storablearrayCoercion :: ...<br>
><br>
> starrayCoercion :: Coercible i j => Coercion (STArray s i) (STArray s j)<br>
> stuarrayCoercion :: (Coercible i j, Coercible a b) => Coercion<br>
> (STUArray s i a) (STUArray s j b)<br>
><br>
> [1] <a href="https://ghc.haskell.org/trac/ghc/ticket/9220" rel="noreferrer" target="_blank">https://ghc.haskell.org/trac/<wbr>ghc/ticket/9220</a><br>
> ______________________________<wbr>_________________<br>
> Libraries mailing list<br>
> <a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/libraries</a><br>
<br>
</blockquote></div></div>