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

Ben Franksen bugs at darcs.net
Sat Aug 31 15:13:55 UTC 2019


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

>> 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?
> 
> I've been doing more with it off and on to try to get a better handle on
> some underlying model for conflictors, in particular looking at things
> like minimal contexts and how those relate to the patches actually
> mentioned in the conflictor. I'd like to get some higher-level
> understanding of the rules for commuting conflictors, not just the
> operational description we have at the moment. I haven't really figured
> out anything illuminating yet though.

And ultimately it all comes down to establishing general permutivity
(for all n>=2 and including consistency of failure). I am convinced it
should be possible to formally derive the commute rules from that
requirement.

I have also come to see merging as the more fundamental operation
compared to commuting. The direct definition of cleanMerge is nicely
symmetric and easy to understand. I really should rebase the patches and
send them.

>> 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?
> 
> A state could just be a set recording the PrimCores already applied.

Yes, I guess this is how one would abstractly construct one concrete
ApplyState. However, the set (or type) of all ApplyStates has a bit more
stucture, as not all such sets are valid states. I was curious about a
more declarative way to characterize the states i.e. the allowed sets.

> But I'm not sure what use it would be at the moment.

Just pure fun mathematics :-) It would shed light on the algebraic
structure of patch algebras. For instance, as these are prim patches, no
two elements may be in the set that are conflicting. And for each
element, it must also contain its dependencies. Note how the first
condition limts what we may add to an existing (valid) set, and how the
latter limits what we can remove from it.

>> I can see now why doing this as a name wrapper around a unit
>> patch type isn't easy or perhaps even impossible.
> [...]
>>> 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.
> 
> Good point that a name wrapper around unit wouldn't work. But I think I
> could just reuse PrimCore for the name as well as for the primitive
> patch contents, and then use a helper function to guarantee that the
> same is used for both. (Which is logically equivalent to what I already
> have, as the Ident instance returns the PrimCore.)

But that would mean we have to duplicate the prim patch data, which I
find ugly. Your PrimContainer class would fit a better.

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


More information about the darcs-devel mailing list