[darcs-devel] [patch1880] decouple RepoPatchV3 impl from NamedPrim

[Ben Franksen]

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

>> Can you put this code online somewhere? It doesn't have to work or even
>> compile, just for reading.
> 
> Attached. (If you do want to run it just do things like "printWithMin
> rSTUV" in cabal v2-repl. It's the example from the camp paper showing
> why we have to look at the conflicting set when commuting. The things in
> angle brackets are contexts, on the left-hand side of the | are the live
> patches and on the right-hand side are the reverted ones.)

I finally had the leisure to look at this code. I think this is
brilliant! I can see now why doing this as a name wrapper around a unit
patch type isn't easy or perhaps even impossible.

Your technique is very useful to formalize concrete examples. It is a
bit unfortunate that the 'conflicts' and 'dependencies' must be fixed
statically and cannot be configured at runtime. This means we cannot use
it for quickcheck or leancheck tests, at least not as is. Perhaps this
could be done with a helper class, similar to Commute, where we pass in
the "commutation behavior" as an extra parameter. Also, your patch type
is a fixed, finite type. I'd say we could as well use String for
PrimCore to get an infinite supply of prims.

This could be used for far more than just examining a few concrete
examples we find interesting. For instance, I find it interesting to
investigate which definitions of 'conflicts' / 'dependencies' satisfy
our patch laws. E.g. does permutivity hold for the example type you
defined? How large is the (finite!) set of possible 'dependencies' such
that all your patch laws hold? Can we combine conflicts and dependencies
into a single data structure, something like a matrix?

Furthermore: your ApplyState is trivial, which is okay for the purpose
you had in mind. But I wonder: is it possible to construct, for every
finite PrimCore-like type and each set of conflicts and dependencies
such that the patch laws hold, a suitable "model" of a state, such that
sequences of the corresponding Prim type map to (all) partial bijections
on that state?

> I expect if I did need to use the wrapper I could hide the boilerplate
> in the utility functions, so it'd just be a bit of extra clutter but not
> too annoying.

As far as I understand your code I would have thought this isn't be
possible. The generic wrapper would already have an instance Commute
defined that delegates the actual commutation to the base type, which
doesn't have the identifiers and therefore cannot commute as prescribed
by 'dependencies'. I was therefore ready to admit we may actually need
something like your PrimContainer class.

Cheers
Ben

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