Branko Čibej wrote on Thu, Jun 27, 2013 at 20:13:20 +0200: > On 27.06.2013 19:33, Daniel Shahaf wrote: > > Philip Martin wrote on Thu, Jun 27, 2013 at 17:47:54 +0100: > >> Daniel Shahaf <danie...@elego.de> writes: > >> > >>> My own answer to "how to change Ev2 to enable representing > >>> rotate(A,A/B/C)": > >>> > >>> I think the above means we have to modify move() to use SRC arguments > >>> relative to the start state of the edited tree, rather than to its > >>> current state. > >>> If we do that, we could represent your commit as: > >>> mv(A/B/C, A); mv(A/B, A/B); mv(A, A/B/C);. > >>> > >>> While we're making changes, I wonder if we should nuke rotate(). I have > >>> several reasons: > >> I've been thinking of that as well. rotate was not it the first draft > >> of Ev2, it was added when I asked how to order the moves in a swap. > >> > >> You have ordered these "start state" moves by depth order of the > >> destination, which seems reasonable. I think that implies that the > >> destination refers to the current state which is the same as the final > >> state. > >> > > +1. The current state == the final state due to the Once Rule: every > > node is the destination of exactly one editor call. > > That's not what the Once Rule says; and if you think about it, it's > impossible unless move and copy get contents/props arguments just like > add and alter.
Right. Contents and property mods may follow, but tree changes may not.
