Greg Stein wrote on Wed, Jun 26, 2013 at 05:30:10 -0400:
> On Wed, Jun 26, 2013 at 5:25 AM, Daniel Shahaf <danielsh_at_elego.de> wrote:
> > Philip Martin wrote on Wed, Jun 26, 2013 at 09:30:42 +0100:
> >> Greg Stein <gstein_at_gmail.com> writes:
> >>
> >> > You're affecting six nodes, so I think you should be able to pack this
> >> > down into touching 6 nodes once each. I believe this will work:
> >> >
> >> > move(A/B, X/Y/Z/B)
> >> > rotate(A, X/Y/Z)
> >> > move(X/Y, A/B/C/Y)
> >> > rotate(X, A/B/C)
> >>
> >> Yes, I think that works.
> >
> > This effectively uses temporary nodes (X/Y/Z/B and A/B/C/Y). I thought
> > one of the goals of Ev2 design was to not need such nodes. (This also
> > ties to my thread about what state the SRC argument of move() should be
> > relative to.)
>
> Only in Pedantic Bizarro Land.
>
> Come on, Daniel. There are no manufactured nodes. Those two are the
> final nodes, after a bit of parent rearrangement.
>
> We are not making up A2 or X2, as in Philip's original email. The
> commit process is not creating nodes that exist only during the txn.
> All nodes survive the txn.
X2 was a temporary name. A/B/C/Y is a temporary name. Neither the name
X2 nor the name A/B/C/Y survives the txn.
>
Well. As I said, my intuition is the "walk down the resulting tree in
preorder" view. I suppose what is done here could be described as "walk
the resulting tree in postorder" --- that is, at the time move() or
rename() is called, the tree being moved in is at its final shape.
With respect to the (/D moved from /A/C:1 ; /B moved from /A:1) example
from yesterday, the solution (mv A B; mv B/C D) is not postorder, since
it modifies B/C after move(_, B); but the solution (mv A/C D; mv A B) is
postorder.
I think the (move, move, move, rotate(6)) solution for my 9-node example
is postorder, but it's hard to tell due to /X and /X/Y/Z both being
move-targets inside rotate().
> Why are you being pedantic here? I see it as argumentative, rather
> than constructive. :-(
>
Considering IRC yesterday, I wonder if you're being overly sensitive.
Just to be explicit, constructiveness is my intent here.
Daniel
> Cheers,
> -g
Received on 2013-06-26 11:47:07 CEST