Add direct support for primative merge, split, and mix in DML

[EvanKirshenbaum]

Probably the most urgent ask for protocols is the ability to simply merge and split drops. At the moment, merging can only be done using unsafe_walk:

define merge(pad center, dir to_d1, dir to_d2) -> drop {
  [[
     (center + to_d1)'s drop : unsafe_walk(to_d1 turned around);
     (center + to_d2)'s drop : unsafe_walk(to_d2 turned around);
  ]]
  return center's drop;
}

This is ugly (as, of course, it should be), but we can definitely do better.

In the code I've sketched out for OSU, I simply have drops get into position relative to one another, and then have one drop say

d1 : accept merge from north

while the other says

d2: merge into south

"In position", in this case means that d2 is two pads north of d1. By putting a pad in between, the code can use normal (rather than unsafe) motion. The resulting drop will be at d1's current location and will have d1's identity, and the d2 drop ceases to exist.

My initial thought was that accept merge returns the new drop while merge into doesn't return anything, but I'm now thinking that they should probably both return the new drop. This will allow the user to continue whichever path makes the most sense, noting that

1. It would be a really bad idea to try to continue both paths and
2. Whichever one is continued, the location will be that of the "accepting" drop. That is, logically, "merge into" moves and "accept merge from" does not.

In addition, if the drops say, in parallel

d1 : mix with south
d2 : mix with north

when they're in position, the drops will merge to the center and then split back into their original positions, each retaining its own identity.

Finally, we also need a way to split a drop (likely one that was merged earlier and then walked) into two smaller one. For that, we can say

split to east

As with the merge operations, the resulting drop will be two pads to the east.

We can take advantage of the future drop notion (#283) by adding an optional clause that takes a variable name:

split to east as d3

This will allow us to say things like

   future drop lower_right;
   future drop upper_right;
   future drop upper_left;
   drop lower_left = C;
   
   [[
      lower_left : split to south as lower_right
                 : split to north as upper_left
                 : down 2 : east 5;
      lower_right : east 7
                  : split to north as upper_right;
      upper_right : north 2;
      upper_left : east 5;
   ]]

Here, a large drop is split into four:

• lower_left splits off lower_right to the south and upper_left to the north before moving into position.
• When lower_right is split off, it moves into position and splits off upper_right.
• When upper_right and upper_left are split off, they move into position.

Migrated from internal repository. Originally created by @EvanKirshenbaum on Aug 02, 2023 at 4:47 PM PDT.

[EvanKirshenbaum]

This issue was referenced by the following commits before migration:

• b6d0895 by @EvanKirshenbaum on Aug 03, 2023 at 11:20 AM PDT
• 9e0dec6 by @EvanKirshenbaum on Aug 03, 2023 at 2:47 PM PDT
• 9beaa4e by @EvanKirshenbaum on Aug 04, 2023 at 4:01 PM PDT
• 85ac7e2 by @EvanKirshenbaum on Aug 17, 2023 at 10:52 AM PDT

[EvanKirshenbaum]

For merging and mixing, the appropriate thing to do is probably to take advantage of the MultiDropProcess facility, but it's been so long since I've looked at it that I'll have to refresh my memory. Alternatively, I could just hang something on the in-between pad. That might well wind up with much the same mechanism as MultiDropProcess, which I'd rather not reinvent, but it might be simpler just because I know that I only have to worry about two drops.

Migrated from internal repository. Originally created by @EvanKirshenbaum on Aug 02, 2023 at 4:51 PM PDT.

[EvanKirshenbaum]

Looking at MultiDropProcess, it actually looks pretty straightforward. The only thing that will be tricky is that it assumes that it will be handing the incoming drops out to their original futures, and we want merge into to get the accept merge drop back out. I don't know if this means that I should add more mechanism to MultiDropProcessType that's used by MultiDropProcess.iterator.do_post() (probably) or try to do some fancy future plumbing.

Migrated from internal repository. Originally created by @EvanKirshenbaum on Aug 02, 2023 at 5:10 PM PDT.