Re: Type family equation violates injectivity?

[Alexander V Vershilov]

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  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 > 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  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
>>>>>>>
>>>>>>>
>>>>>>>

Re: Type family equation violates injectivity?

[Alexander V Vershilov]

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  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  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
> 
>
>
> 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 
> 
>  (v 
> 
>  :: * -> *) = (mv 
> 
>  :: * -> * -> *) | 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

Re: Notes from Ben's "contribute to ghc" discussion

[Alexander V Vershilov]

I think I'm a bit late for the party.

I'm speaking with the newcomer hat on, as basically I have
contributed only few trivial patches. So not sure if my experience
matter.

Originally I was submitting patches using Trac, but then was kindly
asked (IIRC by Simon Marlow) to use Phab instead. Surprisingly enough
I had no problems with Phab, and setup took about 15 minutes
(most of that time I spend on php compilation). Student that I used
to co-mentor this year on HSoC also said that he had zero problems
with Phab and that it took 5 minutes to set everything up. So from
my personal point of view problem of the Phabricator are heavily
overrated.

Whenever you do non trivial (not simple documentation fix) amount
of work and documentation needs to be read highly preside the
complexity of the work for submitting patch. Review requests and
email that is sent is greatly structured, latest changes on  github
makes small step toward but anyway not that good. Also for almost
all the changes I had to contact #ghc or persons who is familiar with
that subsystem and always had great and prompt feedback.

What I'm written above doesn't mean that it's nowhere to improve.
Documentation on the wiki may be structured better and sometimes
it's very hard to get the actual state by reading it. Especially if there
was some ongoing discussion without highlighting the outcome.

As many already highlighted in this thread having a single account for
trac, phab and ideally popular system people people already use will be
beneficial.  Without that I think other improvements will not work well.

Also it would be nice if it was possible to automate some actions like
adding a link from trac to Phab. I remember spending much time on
trying to recall correct syntax to add link to Phab.

About GitHub based contribution. It looks great for me for *all
types* of the patches. But.. bot (or for some time person) should
migrate *all* the patches to Phab, closing the threads for comments.
Bot should write some welcome message than with a link to Phab
request and intruction how to allow Phab to use github account
and read email if there is no account yet.
This way when review had happened author will automatically receive
all review comments with links to Phab, I'll hardly get that following
a link to github is any harder than following link to Phab (assuming
Phab  to login using github account). If user addressed comment
he should be able to just force-push/update his branch and new revision
should be created by bot. PR on github should be closed whenever Phab
request will be closed, so it would be trackable using GitHub only.

This way github-ish users could use tool that they used to, but also
reviewers to use the tool they also used to. All the review
comments will be stored in the single place, no revisions will be lost.
This way could be automated and there will be no strange questions
about what is large patch and what is not. The only people who use
are ones that doesn't use email to receive review comments and can
use only GitHub interface to read that, but I doubt that such users exists.

--
Alexander

On 24 September 2016 at 04:44, Simon Peyton Jones via ghc-devs
 wrote:
> Friends
>
>
>
> Here are the notes I took from session 2 of the Haskell Implementors
> Meeting.  The bolding is my choice of emphasis.
>
>
>
> Simon
>
>
>
> ·Doc bugs.Two kinds
>
> o   Typos.   Friction stops me
>
> o   Explanations needed e.g. read/show
>
> ·Lightweight pushes
>
> ·Make user manual into its own repo, to make it easier to take pull
> requests.  But that makes it harder when making synchronised changes to GHC
> and user manual.
>
> ·Auto-push: Ability to push to Phab and have it committed
> automatically if it validates.
>
> ·Style guides.  Is having a defined style solving a problem we don’t
> really have?  One piece of guidance: adhere to the style of the surrounding
> code.  Low priority.
>
> ·Docker images.   We should have one.
>
> ·Remove old documentation!
>
> ·Cross compilation is difficult.
>
> ·Have a GHC StackOverflow on haskell.org   (Jacob Zalewski
> jakz...@gmail.com offers to do this! – thank you).  It has a useful new
> Documentation feature.   Eg this would be good for “how do I look up a
> RdrName to get a Name… there seem to be six different functions that do
> that”.
>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>



-- 
Alexander
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Proposal for removing transformers dependency

[Alexander V Vershilov]

As a result of this thread I have created Phab Diff [1]. It contains
required fixes in compiler and ghc-transformers-instance package.

I have tested result on 2 following usecases:

1. I have installed in a sandox transformers-0.3 and ghc-heap-view
   that uses them and ghc-lib. (Doesn't require ghc-tf-instances)
2. I have installed in a sandbox ghc-tf-instaces and ghc-mtl
   that uses ghc-lib and ghc-tf-instances. Some fixes were required
   but they all were pretty straighforward to implement.

[1] https://phabricator.haskell.org/D626

On 21 January 2015 at 18:51, Alexander V Vershilov
 wrote:
> Hello.
>
> I'm coming with a proposal for removing transformers dependency
> from ghc library. The reason for this proposal that it's not possible
> to build consistent environment where a modern libraries (that depend
> on a newer transformers or mtl-2.2) and libraries that use ghc API
> are used together. And often people are tend to use version that is
> bundled with ghc, even if newer are available.
>
> As transformers usage are quite limited in ghc, and it's really relevant
> in ghc-bin, it's possible to duplicate the code, and provide required
> fixes in ghc-bin.cabal. As a result ghc uses it's own MonadIO, MonadControl
> and Strict State, and ghc-bin.cabal (ghc/*) uses ones from transformers.
>
> I have prepared a proof of concept [1], however it doesn't look very clean
> and it's quite possible that will require some generalization, for example
> introduction of the ghc-transformers-instances package that will have
> all required instances.
>
> Should I continue doing this? Are there any things to consider and fix?
>
> [1] https://github.com/qnikst/ghc/compare/wip/remove-tf
> --
> Alexander



-- 
Alexander
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Proposal for removing transformers dependency

[Alexander V Vershilov]

On 22 January 2015 at 10:37, Herbert Valerio Riedel  wrote:
> On 2015-01-21 at 17:19:42 +0100, Alexander V Vershilov wrote:
>> I thought about providing package ghc-transformers-instances, that will
>> provide instances for transformers's type classes for user. So
>> ghc-tf-instances will depend on current ghc, and current transformers that
>> could be provided by user environment.
>
> So the price is seems to be mostly to tolerate orphan instances (and
> potentially having to copy more code from transformers into ghc, if one
> wants to use more features in ghc's code).

Yes, if I didn't miss any other relevant issue.
It's possible that we will need some coercion between Strict State
that comes with GHC and one that is in transformers.

> One would have to make sure to keep that package updated everytime a new
> transformers or ghc package version is released, as well as making sure
> to always test all supported combinations of ghc/transformers versions
> before making a new releases.
>
> One thing to keep in mind though is that then 'haskeline' (which is
> needed by GHCi) still remains a consumer of 'transformers', so we'd
> still have to bundle a 'transformers' package version with GHC even if
> `ghc` doesn't depend on it anymore. Somewhat related, the `ghc` ->
> `Cabal` dependency was broken up in GHC 7.10 but we'll still bundle
> `Cabal` with GHC 7.10.

>From a distro-developer perspective (gentoo) the only relevant library
is ghc library,
and ghc-bin is an executable, so in the worst case user will end up with
having 2 different transformers package. But there will be no transformers
madness as no library pulls concrete version.

> I'm not sure how much this helps Stackage which I assume would
> constraint transformers to a single version, and therefore force a
> reinstall of the haskeline version shipped with GHC with a different
> version of transformers.

I don't know about a Stackage but at least Gentoo allow to install additional
version for packages that are shipped with ghc and ghc library do not
depend on it,
it also handles a case when versions are equal, and then installation is a noop.

Thinking of  haskeline user will have problems only in case if user's haskeline
version is equal to shipped with GHC but depends on a different tf version.
I think that in this case force installing will lead to some level of breakage,
however all executables (ghc-bin) and new libraries will continue working.
Workaround is to make a minor version bump in haskeline and this can be
done purely on a distro-level.

> Fwiw, I welcome decoupling libraries from the GHC distribution as every
> exposed library adds to the synchronisation-with-upstream-overhead when
> preparing new GHC releases, in addition to adding implicit version
> constraints to the package database.
>
> With a GHC release-management hat on though: As for GHC 7.10.1, it's
> rather late... at the very least it needs to get into RC2 (whose cut off
> is tomorrow) for that to happen.

Great. I'll try to cleanup code, and prepare ghc-tf-instances today, test of
the packages that depend on the ghc library in order to understand if
ghc-tf-instances solution works and then send diff to a Phab.

Every tips, suggestions, or reminders of things that I should check will
be gladly accepter.

> Cheers,
>   hvr

-- 
Alexander
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Proposal for removing transformers dependency

[Alexander V Vershilov]

Ok. In this case, I'm interested in main users of ghc library,
as I have to make sure that they will not be broken by
any changes that I'm introduce? I can take few from hackage
but maybe there are ones that users care about. So I can
validate my solution.

--
Alexander

On 22 January 2015 at 03:11, Kazu Yamamoto  wrote:
> Hi,
>
> I also hope that this is integrated into GHC 7.10.
>
> --Kazu
>
>> Hello.
>>
>> I'm coming with a proposal for removing transformers dependency
>> from ghc library. The reason for this proposal that it's not possible
>> to build consistent environment where a modern libraries (that depend
>> on a newer transformers or mtl-2.2) and libraries that use ghc API
>> are used together. And often people are tend to use version that is
>> bundled with ghc, even if newer are available.
>>
>> As transformers usage are quite limited in ghc, and it's really relevant
>> in ghc-bin, it's possible to duplicate the code, and provide required
>> fixes in ghc-bin.cabal. As a result ghc uses it's own MonadIO, MonadControl
>> and Strict State, and ghc-bin.cabal (ghc/*) uses ones from transformers.
>>
>> I have prepared a proof of concept [1], however it doesn't look very clean
>> and it's quite possible that will require some generalization, for example
>> introduction of the ghc-transformers-instances package that will have
>> all required instances.
>>
>> Should I continue doing this? Are there any things to consider and fix?
>>
>> [1] https://github.com/qnikst/ghc/compare/wip/remove-tf
>> --
>> Alexander
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs



-- 
Alexander
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Proposal for removing transformers dependency

[Alexander V Vershilov]

I thought about providing package ghc-transformers-instances, that will
provide instances for transformers's type classes for user. So
ghc-tf-instances will depend on current ghc, and current transformers that
could be provided by user environment.
On Jan 21, 2015 7:15 PM, "Herbert Valerio Riedel" 
wrote:

> On 2015-01-21 at 16:51:55 +0100, Alexander V Vershilov wrote:
>
> [...]
>
> > As transformers usage are quite limited in ghc, and it's really relevant
> > in ghc-bin, it's possible to duplicate the code, and provide required
> > fixes in ghc-bin.cabal. As a result ghc uses it's own MonadIO,
> MonadControl
> > and Strict State, and ghc-bin.cabal (ghc/*) uses ones from
> > transformers.
>
> ...but doesn't this effectively mean that the instances provided by the
> `ghc` package are of little use or rather can't be easily combined with
> code that builds on top of the original `transformers` classes everyone
> else uses?
>
> Cheers,
>   hvr
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Proposal for removing transformers dependency

[Alexander V Vershilov]

Hello.

I'm coming with a proposal for removing transformers dependency
from ghc library. The reason for this proposal that it's not possible
to build consistent environment where a modern libraries (that depend
on a newer transformers or mtl-2.2) and libraries that use ghc API
are used together. And often people are tend to use version that is
bundled with ghc, even if newer are available.

As transformers usage are quite limited in ghc, and it's really relevant
in ghc-bin, it's possible to duplicate the code, and provide required
fixes in ghc-bin.cabal. As a result ghc uses it's own MonadIO, MonadControl
and Strict State, and ghc-bin.cabal (ghc/*) uses ones from transformers.

I have prepared a proof of concept [1], however it doesn't look very clean
and it's quite possible that will require some generalization, for example
introduction of the ghc-transformers-instances package that will have
all required instances.

Should I continue doing this? Are there any things to consider and fix?

[1] https://github.com/qnikst/ghc/compare/wip/remove-tf
-- 
Alexander
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs