<p dir="ltr">I would be very much opposed, personally, to such an unsafe global pragma. Something like</p>
<p dir="ltr">deriving instance {-# UnsafeNewtypeDerivation #-} Foo Bar</p>
<p dir="ltr">would seem more reasonable. I'd also really like to see a less awkward story for these unboxed vector types, ideally one that would also enable unboxed non-vector containers more easily. I imagine I'm not the only one interested in unboxed priority queues and maps and sets and things.</p>
<div class="gmail_quote">On Mar 24, 2015 10:45 AM, "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">The notes to #9220 explain this fairly well, I think.<br>
<br>
But, Wren's desire is reasonable. The real reason that GND can't work here is that the safety condition lives outside the type system.<br>
<br>
It seems to me like one way forward is to allow an unsafe GND, via some pragma. It would be dead-easy to implement (modulo surface syntax): just change `coerce` to `unsafeCoerce` in the produced code.<br>
<br>
Richard<br>
<br>
On Mar 24, 2015, at 10:25 AM, wren romano <<a href="mailto:winterkoninkje@gmail.com">winterkoninkje@gmail.com</a>> wrote:<br>
<br>
> On Tue, Mar 24, 2015 at 10:15 AM, Reid Barton <<a href="mailto:rwbarton@gmail.com">rwbarton@gmail.com</a>> wrote:<br>
>> On Tue, Mar 24, 2015 at 9:57 AM, wren romano <<a href="mailto:winterkoninkje@gmail.com">winterkoninkje@gmail.com</a>><br>
>> wrote:<br>
>>><br>
>>> So I was working on porting my libraries to work for GHC 7.10 and I<br>
>>> ran into a snag. Unlike the concrete type Data.Array.Array,  the<br>
>>> concrete type Data.Array.Unboxed.UArray is defined as being nominal in<br>
>>> the second type argument— is this a bug?<br>
>><br>
>> No, see <a href="https://ghc.haskell.org/trac/ghc/ticket/9220" target="_blank">https://ghc.haskell.org/trac/ghc/ticket/9220</a>.<br>
><br>
> Fair enough.<br>
><br>
><br>
> To be clearer, my actual goal is to automatically derive the (IArray<br>
> UArray) instance for a newtype. The newtype has semantic content (like<br>
> Sum or Product), but no representational content (i.e., New and Old<br>
> have the same size and the same valid bit patterns). This worked fine<br>
> in GHC 7.8 and prior, and should still be fine since it doesn't run<br>
> into the sorts of issues raised by that bug report. Again, the goal is<br>
> to automatically derive the instance rather than doing it manually,<br>
> since I really want to just inherit the underlying instance at the new<br>
> type.<br>
><br>
> --<br>
> Live well,<br>
> ~wren<br>
> _______________________________________________<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" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
><br>
<br>
_______________________________________________<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" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div>