I found these using the flag of GHC -fwarn-redundant-constraints .

As this flag returns sometimes false positives, I had to manually check
whether said constraints were really redundant by compiling.

The most common redundant constraints were:

* Functor when Monad is already required, not a problem since GHC 7.10
* Repopatch
* IsRepoType
* Patchy
* ApplyState p ~ Tree

The weirdest / most doubtful case is the following:

~~~
instance (IsHunk p, PatchListFormat p, Patchy p) => Patchy (FL p)
instance (IsHunk p, PatchListFormat p, Patchy p) => Patchy (RL p)
~~~

Which seems to only need:

~~~
instance (Patchy p) => Patchy (FL p)
instance (Patchy p) => Patchy (RL p)
~~~

I will screen this in a couple of days in case someone discovers this is
incorrect.


patch a448b9779110a652518dbfdd16e530d93215f150
Author: Guillaume Hoffmann <guillaumh@gmail.com>
Date:   Mon Feb 26 13:40:36 -03 2018
  * eliminate redundant constraints in Darcs.Repository

patch 0f1d11bd1d54e0f847f3f136592bcb0a82292621
Author: Guillaume Hoffmann <guillaumh@gmail.com>
Date:   Mon Feb 26 13:40:17 -03 2018
  * eliminate redundant constraints in Darcs.Patch

patch e8795ae71453accbb86dad3e4497151ad9612f81
Author: Guillaume Hoffmann <guillaumh@gmail.com>
Date:   Mon Feb 26 13:30:16 -03 2018
  * eliminate redundant constraints in Darcs.Util

Attachments

• eliminate-redundant-constraints-in-darcs_util.dpatch

I am screening them now, no problems I can see.

My previous comment about Patchy made me look into what was this
typeclass for.

Patchy is simply a subclass of Apply, Invert and Commute. The idea
seemed to be to write smaller contexts. However, I found that in most
places, Patchy was used instead of just one or two of the aforementioned
classes.

Also, "Patchy" is not a very informative name, unlike for instance,
Matchable, another empty class. Nor is it very all-encompassing, unlike
RepoPatch which is a subclass of almost 20 classes.

Moreover, many modules import Darcs.Patch.Patchy in order to import
other class definitions, so API-wise this does not look great.

So I went ahead and removed the Patchy class, and found that many
functions now have amore understandable context.

After that, I compiled again Darcs with -fwarn-redundant-constraints,
and could further removed unneeded constraints all over the place.

I'm screening this followup bundle.

Attachments

• stop-using-patchy-in-the-test-harness.dpatch

I think that Patchy is also trying to express a higher-level concept, 
that these classes are the fundamentals of what it means to be a patch.

Yes! I agree fully wrt Patchy, been thinking similar thoughts now and again.

Ganesh: yes, and I guess this is correlated with the contemporary
documentation about patch theory, that talks about commutation and
inversion, but falls short of the issue of conflicts (Patchy is not a
subclass of Conflict nor Merge).

To make reviewing easier, here is a diff of before/after the patches of
this ticket:

http://lpaste.net/2558136303078080512

Self-accept.