some random cleanups related to the rebase refactoring
3 patches for repository darcs-unstable@darcs.net:screened:

patch dca9c5b9376c5f8ba6572cbed260de5473a33984
Author: Ganesh Sittampalam <ganesh@earth.li>
Date:   Fri Feb 12 23:56:05 GMT 2016
  * abstract out checking whether a Named is internal

patch e76a9e074404dc76ead47c8e93104e6b5a30ca8b
Author: Ganesh Sittampalam <ganesh@earth.li>
Date:   Fri Feb 12 23:56:05 GMT 2016
  * drop re-exports from Darcs.Patch.Rebase

patch a4a7034615a1bbcbf3b7af64092d584e759d65a1
Author: Ganesh Sittampalam <ganesh@earth.li>
Date:   Fri Feb 12 23:56:05 GMT 2016
  * Get rid of the need for DummyPatch in Darcs.Patch.Match

Attachments

• abstract-out-checking-whether-a-named-is-internal.dpatch
• patch-preview.txt
• unnamed

* abstract out checking whether a Named is internal: OK
    * replace 'isInternal' by 'runInternalChecker'
    * MaybeInternal: remove 'flIsInternal', moved to Named as
'namedIsInternal'
    * Internal, Match.dropn, Match.safetake: we just use
'namedIsInternal' on (map hopefully ps)
    * in Tag and Match: use namedInternalChecker instead of
patchInternalChecker
    * looks good.

* drop re-exports from Darcs.Patch.Rebase: OK

* Get rid of the need for DummyPatch in Darcs.Patch.Match:

Here I have a doubt. If getting rid of DummyPatch is important, why are
there remaining cases in in D.P.Match ?

On 18/03/2016 19:15, Guillaume Hoffmann wrote:

> * Get rid of the need for DummyPatch in Darcs.Patch.Match:
> 
> Here I have a doubt. If getting rid of DummyPatch is important, why are
> there remaining cases in in D.P.Match ?

Good question. I originally introduced DummyPatch to replace a case
where Prim was being used effectively as a dummy patch type, probably so
I could decouple the generic code in D.P.Match from any (real) specific
patch type.

It was an improvement on using Prim, but still a bit of a code smell: if
the code we are working with genuinely cares about a patch type
DummyPatch is unlikely to be right, and if it doesn't care about a patch
type then why does it need one in the first place.

I think in practice it's used for code where the patch type doesn't
matter but imperfectly factored types/abstractions mean that one still
has to be supplied.

Ideally we'd get rid of the lot, either by passing in the real patch
type or by factoring the patch type parameter out of the code. In
practice here I probably just removed some cases that were an obstacle
to other refactorings or that I happened to notice along the way. Given
that there are still uses of it, the patch comment is slightly
inaccurate, sorry about that.

Well ok, then the change is sound in itself, in spite of the patch name.

Accepting the bundle.