Type roles for UArray?

[Richard Eisenberg]

I wasn't thinking of a global pragma -- something much closer to what you propose.

I actually think we should go further and come up with a unified story around different "deriving" mechanisms. GHC currently has 3:

1) Haskell98-style, including extensions like DeriveFunctor. These "derivings" are baked in.
2) GND
3) DeriveAnyClass, a new extension, intended to be used with generics, that produces an empty instance declaration. The methods are intended to be filled in by (perhaps generic) default implementations.

This thread proposes a new mechanism: unsafeGND. And perhaps more are waiting in the wings. Users should be able to specify the mechanism, and if that mechanism is unavailable, GHC should error. When more than one mechanism is non-trivially applicable, GHC should error. (The "non-trivial" is there to rule out errors for, say, deriving Eq via Haskell98 or via GND: both result in the same behavior.)

I leave it to others to bikeshed about syntax. :)

Richard

On Mar 24, 2015, at 10:54 AM, David Feuer <david.feuer at gmail.com> wrote:

> I would be very much opposed, personally, to such an unsafe global pragma. Something like
> 
> deriving instance {-# UnsafeNewtypeDerivation #-} Foo Bar
> 
> 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.
> 
> On Mar 24, 2015 10:45 AM, "Richard Eisenberg" <eir at cis.upenn.edu> wrote:
> The notes to #9220 explain this fairly well, I think.
> 
> 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.
> 
> 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.
> 
> Richard
> 
> On Mar 24, 2015, at 10:25 AM, wren romano <winterkoninkje at gmail.com> wrote:
> 
> > On Tue, Mar 24, 2015 at 10:15 AM, Reid Barton <rwbarton at gmail.com> wrote:
> >> On Tue, Mar 24, 2015 at 9:57 AM, wren romano <winterkoninkje at gmail.com>
> >> wrote:
> >>>
> >>> So I was working on porting my libraries to work for GHC 7.10 and I
> >>> ran into a snag. Unlike the concrete type Data.Array.Array,  the
> >>> concrete type Data.Array.Unboxed.UArray is defined as being nominal in
> >>> the second type argument— is this a bug?
> >>
> >> No, see https://ghc.haskell.org/trac/ghc/ticket/9220.
> >
> > Fair enough.
> >
> >
> > To be clearer, my actual goal is to automatically derive the (IArray
> > UArray) instance for a newtype. The newtype has semantic content (like
> > Sum or Product), but no representational content (i.e., New and Old
> > have the same size and the same valid bit patterns). This worked fine
> > in GHC 7.8 and prior, and should still be fine since it doesn't run
> > into the sorts of issues raised by that bug report. Again, the goal is
> > to automatically derive the instance rather than doing it manually,
> > since I really want to just inherit the underlying instance at the new
> > type.
> >
> > --
> > Live well,
> > ~wren
> > _______________________________________________
> > Libraries mailing list
> > Libraries at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> >
> 
> _______________________________________________
> 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/20150324/dedd538e/attachment.html>