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 <danielsh_at_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.
Received on 2013-07-01 14:17:58 CEST