[darcs-users] Patch Theory in action

Kevin Smith yarcs at qualitycode.com
Sun Nov 23 19:32:35 UTC 2003


David Roundy wrote:
> On Sat, Nov 22, 2003 at 09:29:56PM +0100, Marnix Klooster wrote:
>>Again for what it's worth: here is a proposal for an alternative
>>notation.

I like the proposal. I could quibble with parts of it, but as a whole I 
find it much easier to follow than the current notation.

> Well, I like primes.  To me P1 and P2 look like two unrelated patches,
> while P and P' look like two patches representing the same change.  (But
> the notation shouldn't require which choice one makes in any case.)

True. I can live with the primes, although I have concerns (see below).

>> P = Q : P and Q are exactly the same patch: for every tree
>>         they either both are inapplicable, or they both
>>         give the same result tree.
>>     [NOTE: So commutation would be written as P1;Q1 = Q2;P2;
>>            see the following notation.]
> 
> 
> That's not really true.  Commutation doesn't just indicate that the
> composition of the two patches is the same patch in each case, it also
> indicates that the two commuted patches correspond to the same two
> *changes* in reverse order.

But wouldn't the resulting trees after P1;Q1 and Q2;P2 be identical? If 
so, then if patch R1 *is* P1;Q1 and patch R2 *is* Q2;P2, then R1 = R2.

> An interesting feature of darcs is that "rename file F to G" is actually
> defined even if file F doesn't exist.  :)  In other words, I decided to let
> (my notation)
> 
>   {mv F G} {add F} <---> {add G} {mv F G}
> 
> It seems a little silly, but causes no problems, as long as {rm G} {mv F G}
> doesn't commute.

So adding a file and then moving it is commutable with moving a 
non-existent file and then adding a file of the new name.

But moving a file and then deleting the new file cannot commute with 
deleting a file and then moving the non-existent file to a new name?

Why? Or perhaps more to the point, why would it cause problems if those 
two did commute?

> Well, I'm afraid I do like superscripts and subscripts! :) (Although I also
> appreciate your imput).

One of my problems with the current notation is that you can have P1'-1, 
which when written with super and subscripts looks like P decorated with 
three different kinds of "1". (The ' looks like a superscript 1). Very 
confusing.

So if you're going to keep the ' I would strongly encourage you to adopt 
~ or ! (or perhaps even the haskell oddity /) as the inversion flag.

> Composition of patches would be represented as is done currently (except in
> revese order, since the tree is now on the left), or optionally with a
> latex \cdot (or o in your notation).
> 
> <0|ABC

Hooray! The notation itself looks baroque to me, but very livable.

> I still think a commute operator is necesary, and like the <---> operator
> for this.  But I need to be clearer about <---> being an operation (or
> function?), not just a relationship.  

I'm ok with <--->, and I view it as a relationship, not just an 
operation. If someone hands me valid patches A, B, A' and B' then
    <0|AB <---> <0|B'A'
even though I didn't perform any operations myself.

There is a commute function which given AB will return B'A'. But 
commutability is a state. Am I missing something?

Cheers,

Kevin





More information about the darcs-users mailing list