[darcs-devel] [patch1844] automatically specialize merging and equality for sequences of patches with identity

[Ben Franksen]

Ben Franksen <ben.franksen at online.de> added the comment:

> I definitely agree about needing a clear structural versus semantic
> difference. Perhaps also nominal, though hopefully it can be merged
> with one or both of the other concepts.

Hm, nominal equality would be my IdEq2 class, right? Removing that as a
separate concept is what this patch is about, after all, so yes to that.

After experimenting with structural equality, I am now leaning towards
understanding it in a local sense. That is, instances should not be
built by recursively calling structural equality. Instead they should
use only the semantic equality for their ingredients. This is normally
faster (except with the FL instances for patches without nominal
equality). More importantly, it avoids over-specifying properties.

This would not impair effectiveness of property tests: We test all
relevant properties separately for each layer of the patch type
hierarchy. The higher level types are always parameteric in the lower
level patch type, so we can rely on them not to break the properties of
their ingredients.

> The `Eq2 (FL P)` instance has always scared me and your message
> about generic instances inspired me to investigate if we can do
> without it and instead be more explicit about what we want at call
> sites.

When I discovered the instance Eq2 (FL p) I felt not scared but
relieved. I was glad to know that I never have to care about possible
re-orderings when comparing sequences. IMO this is as it should be.

I am also pretty sure that we always want this kind of equality for FLs
and RLs, even for most properties. Because this is the only equality
that matters, and requiring patches to be in the same order would be an
over-specification.

We also have tests that ensure order inside a sequence doesn't matter
("consistent tree flattenings", for which I plan to send an improved
version that is more general, i.e. tries all possible permutations of an
arbitrary sequence of patches).

I am also quite sure that optimizing semantic equality using nominal
equality is safe everywhere. The Eq2 FL instance may be slow for patches
w/o identity but honestly I no longer care much about optimizing the
buggy old patch formats.

> I'm still trying to figure out why findCommonAndUncommon
> apparently requires it to call partitionFL...

I don't think it is required, it's just an implementation detail. In
fact I think findCommonAndUncommon could be refactored to call
findCommonFL after splitting the patchsets at the latest common tag. I
was planning to make this change but had more pressing things to do
(like fixing conflict resolution for V3, and now being side-tracked with
equality refactors).

__________________________________
Darcs bug tracker <bugs at darcs.net>
<http://bugs.darcs.net/patch1844>
__________________________________