Not by anything I've tried yet, no. On Tue, May 13, 2014 at 10:40 PM, Carter Schonwald < carter.schonwald@gmail.com> wrote:

can you get the deriving to work on a newtype instance MVector s Foo = .... ?

On Tue, May 13, 2014 at 9:39 PM, John Lato wrote:

...

Hello,

Prior to ghc-7.8, it was possible to do this:

...

module M where

import qualified 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, M.MVector MVector, G.Vector Vector, Unbox)

M.MVector is defined as

...

class MVector v a where 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. 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. 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). 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@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

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). 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 wrote:

Is this an instance of https://ghc.haskell.org/trac/ghc/ticket/8177 ? 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 wrote:

Hello,

Prior to ghc-7.8, it was possible to do this:

...

module M where

import qualified 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, M.MVector MVector, G.Vector Vector, Unbox)

M.MVector is defined as

...

class MVector v a where 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. 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. 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). 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@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Greetings, 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, Christian * Carter Schonwald [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 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 wrote:

Is this an instance ofA https://ghc.haskell.org/trac/ghc/ticket/8177 ? 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 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@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Hi Richard, Following your comment, I created a new ticket, https://ghc.haskell.org/trac/ghc/ticket/9112, for this issue. I'm not entirely sure I follow all the subtleties of your analysis, but I think it's correct. On Wed, May 14, 2014 at 9:10 PM, Bryan O'Sullivan wrote:

On Wed, May 14, 2014 at 7:02 PM, John Lato wrote:

...

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.

I think people just haven't migrated much to 7.8 yet. This is definitely a substantial problem.