Re: vector and GeneralizedNewtypeDeriving
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 pgpHViYUjKRAe.pgp Description: PGP signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: vector and GeneralizedNewtypeDeriving
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. > ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: vector and GeneralizedNewtypeDeriving
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. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: vector and GeneralizedNewtypeDeriving
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 :) 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). 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 >> >> >> > > ___ > 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
Re: vector and GeneralizedNewtypeDeriving
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 > > > ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: vector and GeneralizedNewtypeDeriving
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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: vector and GeneralizedNewtypeDeriving
Not by anything I've tried yet, no. On Tue, May 13, 2014 at 10:40 PM, Carter Schonwald < carter.schonw...@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 >> >> > ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: vector and GeneralizedNewtypeDeriving
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 > > ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
vector and GeneralizedNewtypeDeriving
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
Re: "GeneralizedNewtypeDeriving"
*query* Ah. So it does. Thanks. I'll learn this language yet (^_~) On 27/12/2011, Chris Dornan wrote: > That’s as maybe but last time I looked (I don’t have it to hand) the OED > generally accepts –ize or –ise spellings for British English (maybe even > favouring the former). > > Chris > > From: glasgow-haskell-users-boun...@haskell.org > [mailto:glasgow-haskell-users-boun...@haskell.org] On Behalf Of David Fox > Sent: 27 December 2011 14:50 > To: Matthew Farkas-Dyck > Cc: GHC users > Subject: Re: "GeneralizedNewtypeDeriving" > > My guess is that Americans were involved. > On Mon, Dec 26, 2011 at 7:24 AM, Matthew Farkas-Dyck > wrote: > Just of curiosity, why is it spelt with a z? Is it spelt thus in > Scottish English? I thought that "generalised" is written throughout > Great Britain. > > Cheers, > MFD > > ___ > 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
RE: "GeneralizedNewtypeDeriving"
That’s as maybe but last time I looked (I don’t have it to hand) the OED generally accepts –ize or –ise spellings for British English (maybe even favouring the former). Chris From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-users-boun...@haskell.org] On Behalf Of David Fox Sent: 27 December 2011 14:50 To: Matthew Farkas-Dyck Cc: GHC users Subject: Re: "GeneralizedNewtypeDeriving" My guess is that Americans were involved. On Mon, Dec 26, 2011 at 7:24 AM, Matthew Farkas-Dyck wrote: Just of curiosity, why is it spelt with a z? Is it spelt thus in Scottish English? I thought that "generalised" is written throughout Great Britain. Cheers, MFD ___ 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
Re: "GeneralizedNewtypeDeriving"
My guess is that Americans were involved. On Mon, Dec 26, 2011 at 7:24 AM, Matthew Farkas-Dyck wrote: > Just of curiosity, why is it spelt with a z? Is it spelt thus in > Scottish English? I thought that "generalised" is written throughout > Great Britain. > > Cheers, > MFD > > ___ > 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
"GeneralizedNewtypeDeriving"
Just of curiosity, why is it spelt with a z? Is it spelt thus in Scottish English? I thought that "generalised" is written throughout Great Britain. Cheers, MFD ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
