Ok, either way it might be nice to just make it a minor bump. I’ll see what I can do :)
On Fri, Jan 4, 2019 at 10:09 AM Alexander V Vershilov < alexander.vershi...@gmail.com> wrote: > I can't answer your question before I will port inline-r to the newer > vector. I would prefer to support both version and keep CPP around, like > you suggested, but the answer depends on the amount of changes I need to > keep. If that would be few lines of code then I'll go with that, in the > side if the amount of changes will be comparable with a module size, then > I'd prefer to cut out older versions. > > On Fri, Jan 4, 2019, 18:04 Carter Schonwald <carter.schonw...@gmail.com > wrote: > >> Would it be easier if you can do a conjunction on vector and base version >> in your cpp should you want to support both sides ? >> >> On Fri, Jan 4, 2019 at 9:59 AM Alexander V Vershilov < >> alexander.vershi...@gmail.com> wrote: >> >>> For inline-r we have added a revision that sets upper limit, so now >>> hackage and stackage should both be happy. I'm not sure if any Linux >>> distribution provides inline-r as a package but that should be normal >>> situation for them. Next version will either set lower dependency boundary >>> or will keep a code that will run with both APIs. So from my perspective >>> any solution (even keeping things as-is) will be ok. >>> >>> >>> On Fri, Jan 4, 2019, 17:31 Carter Schonwald <carter.schonw...@gmail.com >>> wrote: >>> >>>> Hrmmm. Here’s what I’ll do: I’ll make the same release a minor version >>>> bump and make the bug fix bump version unbuildable. >>>> >>>> Would this help matters ? >>>> >>>> On Fri, Jan 4, 2019 at 9:23 AM Carter Schonwald < >>>> carter.schonw...@gmail.com> wrote: >>>> >>>>> Yeah, I later found it impacted one of my own pieces of code too, in >>>>> that I needed to make still further type families injective. >>>>> >>>>> I do think that a lot of vectors current module structure reflects a >>>>> desire for injectivity coupled with historical a lack of mechanism for >>>>> guaranteeing it. >>>>> >>>>> Mess up on my part for sure. :) >>>>> >>>>> On Fri, Jan 4, 2019 at 8:11 AM Boespflug, Mathieu <m...@tweag.io> wrote: >>>>> >>>>>> Hi Carter, >>>>>> >>>>>> thanks for looking into this. We were initially surprised to see a >>>>>> breaking change in a point release, but no biggy. It's pretty hard to >>>>>> offer >>>>>> strong stability guarantees without automated tooling to catch this kind >>>>>> of >>>>>> thing, and these things happen. We'll patch up HaskellR shortly. >>>>>> >>>>>> Best, >>>>>> >>>>>> >>>>>> On Sun, 30 Dec 2018 at 01:06, Carter Schonwald < >>>>>> carter.schonw...@gmail.com> wrote: >>>>>> >>>>>>> To be clear : I’m annoyed with myself that this impacted a package >>>>>>> that depends on vector, but this does seem to be the case that the >>>>>>> newest >>>>>>> bug fix release for vector actually revealed a broken design for the >>>>>>> vector >>>>>>> instances / data types in the inline-r package. >>>>>>> >>>>>>> To;dr — I suggest patching inline-r to remove the s parameter in its >>>>>>> immutable vector data types >>>>>>> >>>>>>> On Sat, Dec 29, 2018 at 6:48 PM Carter Schonwald < >>>>>>> carter.schonw...@gmail.com> wrote: >>>>>>> >>>>>>>> so i took a look .. (also the inline-r devs seem to have done a >>>>>>>> hackage revision so you wont hit that issue in your current setup if >>>>>>>> you do >>>>>>>> a cabal update ..) >>>>>>>> and it seems like the type definitions in inline-r are kinda bogus >>>>>>>> and you should get them patched ... >>>>>>>> >>>>>>>> the MVector type class, and related type families, all assume your >>>>>>>> mutable type has the last two arguments as the io/state token and then >>>>>>>> the >>>>>>>> element type >>>>>>>> >>>>>>>> eg >>>>>>>> basicLength :: v s a -> Int >>>>>>>> <http://hackage.haskell.org/package/base-4.12.0.0/docs/Data-Int.html#t:Int> >>>>>>>> >>>>>>>> >>>>>>>> i looked at >>>>>>>> https://github.com/tweag/HaskellR/blob/1292c8a9562764d34ee4504b54d93248eb7346fe/inline-r/src/Data/Vector/SEXP.hs#L346-L374 >>>>>>>> and >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> as a point of grounding this chat >>>>>>>> the injective type familly in question is defined by the follwoing >>>>>>>> >>>>>>>> >>>>>>>> --#if MIN_VERSION_base(4,9,0)type family Mutable >>>>>>>> <http://hackage.haskell.org/package/vector-0.12.0.2/docs/src/Data.Vector.Generic.Base.html#Mutable> >>>>>>>> (v >>>>>>>> <http://hackage.haskell.org/package/vector-0.12.0.2/docs/src/Data.Vector.Generic.Base.html#local-6989586621679032525> >>>>>>>> :: * -> *) = (mv >>>>>>>> <http://hackage.haskell.org/package/vector-0.12.0.2/docs/src/Data.Vector.Generic.Base.html#local-6989586621679032526> >>>>>>>> :: * -> * -> *) | mv -> v#elsetype family Mutable (v :: * -> *) :: * >>>>>>>> -> * -> *#endif >>>>>>>> >>>>>>>> anyways, it looks like the Pure / immutable vector data type in >>>>>>>> inline-r has a spurious state token argument in its definition that >>>>>>>> shouldn't be there, OR there need to be two "s" params in inline-r >>>>>>>> instead >>>>>>>> of the one >>>>>>>> >>>>>>>> heres the full code i linked to in question >>>>>>>> >>>>>>>> >>>>>>>> -- | Mutable R vector. Represented in memory with the same header >>>>>>>> as 'SEXP' >>>>>>>> >>>>>>>> -- nodes. The second type parameter is phantom, reflecting at the >>>>>>>> type level the >>>>>>>> -- tag of the vector when viewed as a 'SEXP'. The tag of the vector >>>>>>>> and the >>>>>>>> -- representation type are related via 'ElemRep'. >>>>>>>> data MVector s ty a = MVector >>>>>>>> { mvectorBase :: {-# UNPACK #-} !(SEXP s ty) >>>>>>>> , mvectorOffset :: {-# UNPACK #-} !Int32 >>>>>>>> , mvectorLength :: {-# UNPACK #-} !Int32 >>>>>>>> } >>>>>>>> -- | Internal wrapper type for reflection. First type parameter is >>>>>>>> the reified >>>>>>>> -- type to reflect. >>>>>>>> newtype W t ty s a = W { unW :: MVector s ty a } >>>>>>>> instance (Reifies t (AcquireIO s), VECTOR s ty a) => G.MVector (W t >>>>>>>> ty) a where >>>>>>>> >>>>>>>> data Vector s (ty :: SEXPTYPE) a = Vector >>>>>>>> { vectorBase :: {-# UNPACK #-} !(ForeignSEXP ty) , vectorOffset >>>>>>>> :: {-# UNPACK #-} !Int32 , vectorLength :: {-# UNPACK #-} !Int32 >>>>>>>> } >>>>>>>> >>>>>>>> >>>>>>>> type instance G.Mutable (W t ty s) = Mutable.W t ty >>>>>>>> Anyways, the fix here is to remove the s param from the Pure >>>>>>>> version of W and "Sexp Vector" >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Sat, Dec 29, 2018 at 6:16 PM Carter Schonwald < >>>>>>>> carter.schonw...@gmail.com> wrote: >>>>>>>> >>>>>>>>> were you using the same version of vector in both setups? >>>>>>>>> >>>>>>>>> in the most recent vector release we made mutable type family >>>>>>>>> injective in the vector package for ghc's that support it ... >>>>>>>>> >>>>>>>>> On Sat, Dec 29, 2018 at 1:50 PM Dominick Samperi < >>>>>>>>> djsamp...@gmail.com> wrote: >>>>>>>>> >>>>>>>>>> When I use v8.6.3 of GHC under Ubuntu to install the inline-r >>>>>>>>>> package >>>>>>>>>> I get the error "Type family equation violates injectivity >>>>>>>>>> annotation," and >>>>>>>>>> a type variable on the LHS cannot be inferred from the RHS, due to >>>>>>>>>> the lack of injectivity (I suppose). >>>>>>>>>> >>>>>>>>>> On the other hand, v8.0.2 of GHC (shipped with Haskell Platform >>>>>>>>>> under >>>>>>>>>> Ubuntu) does not have this problem (it has other problems). >>>>>>>>>> >>>>>>>>>> Has something changed in the latest version of the compiler that >>>>>>>>>> might >>>>>>>>>> cause this? Possible work-around? >>>>>>>>>> >>>>>>>>>> FYI, the line that triggers the error is: >>>>>>>>>> type instance G.Mutable (W t ty s) = Mutable.W t ty >>>>>>>>>> >>>>>>>>>> The variable that cannot be inferred is 's'. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Dominick >>>>>>>>>> _______________________________________________ >>>>>>>>>> ghc-devs mailing list >>>>>>>>>> ghc-devs@haskell.org >>>>>>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>> ghc-devs mailing list >>>>>>> ghc-devs@haskell.org >>>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>>>>>> >>>>>> _______________________________________________ >>>> ghc-devs mailing list >>>> ghc-devs@haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>>> >>>
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
