2 patches for repository http://darcs.net/screened:

patch 13bfe4748acbf8cdf8d33702185feae94a47badc
Author: Ben Franksen <ben.franksen@online.de>
Date:   Thu Aug 29 18:24:43 CEST 2019
  * turn RepoPatch into a constraint synonym
  
  This has a lot of advantages wrt maintenance and gets us rid of a few orphan
  instances. Also included a few minor cleanups in Darcs.Patch.RepoPatch.

patch cb5482f2b66867a0cd03d32625e15380f4e65858
Author: Ben Franksen <ben.franksen@online.de>
Date:   Thu Aug 29 18:30:03 CEST 2019
  * turn PrimPatch into a constraint synonym

Attachments

• patch-preview.txt
• turn-repopatch-into-a-constraint-synonym.dpatch
• unnamed

I am not expecting these two patches to be controversial, so I'll screen
them soon. Shout if you have objections.

The principle is fine with me.

Just to note that one practical consequence of this change is that
if you really need a PrimPatch constraint but omit it, instead
of the type-checker telling you that, you get a stream of messages
about the individual classes. You have to be paying a bit of 
attention to realise that the right fix is to add PrimPatch rather
than writing out a huge constraint by hand.

> Just to note that one practical consequence of this change is that
> if you really need a PrimPatch constraint but omit it, instead
> of the type-checker telling you that, you get a stream of messages
> about the individual classes. You have to be paying a bit of 
> attention to realise that the right fix is to add PrimPatch rather
> than writing out a huge constraint by hand.

I noticed that, too.

My conclusion from this and the problem with using class constraints on
type family applications is that we should think carefully before we
apply this idiom. As I see it, for RepoPatch the benefits outweigh these
problems, but for PrimPatch I'm not so sure.