vector and GeneralizedNewtypeDeriving

Christian Höner zu Siederdissen choener at
Thu May 15 11:06:23 UTC 2014


As an avid user of unboxed vectors (with a dozen libraries using them
with many newtypes), I've basically been using vector-th-unbox, which is
fine for parameter-free newtypes.

Viele Gruesse,

* Carter Schonwald <carter.schonwald at> [15.05.2014 04:15]:
>    this is an issue i'll be running into shortly, otoh I don't think many
>    folks are writing new unboxed vector instances and related engineering
>    :)A 
>    On Wed, May 14, 2014 at 10:02 PM, John Lato <jwlato at> wrote:
>      Hi Richard,
>      Thanks for pointing me to the ticket; I agree that's the issue (although
>      I'm glad to have you and Simon confirm it). A I've summarized the issue
>      and raised the priority, and Simon linked to this thread.
>      I would have expected this would have affected a lot users, but as I
>      haven't heard many complaints (and nobody else said anything here!)
>      maybe the impact is smaller than I thought.
>      Thanks,
>      John
>      On Wed, May 14, 2014 at 6:02 AM, Richard Eisenberg <eir at>
>      wrote:
>        Is this an instance ofA ?
>        I think so.
>        The problem boils down to the fact that Vector and MVector are data
>        families and are thus (currently) exempted from the roles mechanism.
>        (Or, more properly, may *only* have nominal roles.) There is no
>        technical reason for this restriction. It's just that the feature
>        would take a few solid days of work to implement and I wasn't aware of
>        a concrete use case.
>        Here is such a use case.
>        If you agree that you've hit #8177, please post to that bug report and
>        raise the priority to High -- being able to coerce Vectors seems very
>        reasonable indeed, and we should support it. I doubt the feature will
>        land in 7.8.3 (depending on the timeline for that release), but I'll
>        get to it eventually. (Or, if you feel this is more critical in the
>        larger picture, shout more loudly on the ticket and perhaps I can
>        squeeze it in before 7.8.3.)
>        Thanks,
>        Richard
>        On May 13, 2014, at 9:39 PM, John Lato <jwlato at> wrote:
>          Hello,
>          Prior to ghc-7.8, it was possible to do this:
>          > module M where
>          >
>          > import qualifiedA Data.Vector.Generic.Base as G
>          > import qualified Data.Vector.Generic.Mutable as M
>          > import Data.Vector.Unboxed.Base -- provides MVector and Vector
>          >
>          > newtype Foo = Foo Int deriving (Eq, Show, Num,
>          > A  A A M.MVector MVector, G.Vector Vector, Unbox)
>          M.MVector is defined as
>          > class MVector v a where
>          > A  A  basicLength :: v s a -> Int
>          etc.
>          With ghc-7.8 this no longer compiles due to an unsafe coercion, as
>          MVector s Foo and MVector s Int have different types. A The error
>          suggests trying -XStandaloneDeriving to manually specify the
>          context, however I don't see any way that will help in this case.
>          For that matter, I don't see any way to fix this in the vector
>          package either. A We might think to define
>          > type role M.MVector nominal representational
>          but that doesn't work as both parameters to M.MVector require a
>          nominal role (and it's probably not what we really want anyway).
>          A Furthermore Data.Vector.Unboxed.Base.MVector (which fills in at
>          `v` in the instance) is a data family, so we're stuck at that point
>          also.
>          So given this situation, is there any way to automatically derive
>          Vector instances from newtypes?
>          tl;dr: I would really like to be able to do:
>          > coerce (someVector :: Vector Foo) :: Vector Int
>          am I correct that the current machinery isn't up to handling this?
>          Thanks,
>          John
>          _______________________________________________
>          Glasgow-haskell-users mailing list
>          Glasgow-haskell-users at
>      _______________________________________________
>      Glasgow-haskell-users mailing list
>      Glasgow-haskell-users at

> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <>

More information about the Glasgow-haskell-users mailing list