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