Simple pipettor support for macro language

[EvanKirshenbaum]

Back in June (before my hours got reduced), I was working on #147, which was essentially this issue, but the implementation got tacked onto the end of #164, reifying off-board locations in the main body of the MPAM. Things have changed enough on the master branch that I don't want to take the time to try and get that stable and finished, but now that the OSU folks want to actually use macros that involve (manual) pipetting, it would be nice to re-import the macro language changes.

For reference, here's the original comment from #147:

As soon as I get the code to work again with the Opentrons (#82), people are going to want to use it.

I don't think that there's any reason to want to reify the pipettor itself, but it will probably be worthwhile to add a type for extraction point (and also extraction port, extraction hole, hole, port(?) and the like) and be able to ask about that as a "maybe" attribute of a pad. And where a pad implicitly converts to its extraction point. It will probably also be worth having a "pipetting target" ("pipettor target") type that includes extraction points and wells.

Then we have functions equivalent to

add = builtin(pipetting target, liquid)
add = builtin(pipetting target, volume)
remove = builtin(pipetting target, volume)

where if you add a volume to a well that has a reagent, you reuse that reagent, and otherwise you add the interactive reagent.

If/when we get imperatives (#139), this could become

add 20 uL to (3,4);
remove the well's volume from the well;
// and with some convenience functions:
empty the well;
fill the well with reagent "R";

Migrated from internal repository. Originally created by @EvanKirshenbaum on Jan 30, 2023 at 10:49 AM PST.

[EvanKirshenbaum]

This issue was referenced by the following commits before migration:

• b8ce9502417a5035753009a1d5935ebdc9276965 by @EvanKirshenbaum on Jan 30, 2023 at 4:11 PM PST
• 2d278f6ceb87e6f41201d67753819bafc972d3c2 by @EvanKirshenbaum on Jan 30, 2023 at 4:59 PM PST

[EvanKirshenbaum]

Thinking about the interaction, a bit, I think that I want the built-ins to return functionals with incomplete arguments, so that you can say, e.g.,

add(w, 5uL of r1)
add(w, 5uL)
w : add(5uL of r1)

That is, if you only provide the liquid or volume, you get a function that takes a pipetting target and returns no value.

Thinking a bit more (and as a prompt for a new issue), it might be useful to have it be a general feature that if you use some distinguishing value for an argument to a function call (say _), you get a function that binds all of the other values and takes a value for that position. That is, add(_, vol) would be return a function that took an argument of the appropriate type and called add with the volume bound as the second parameter.

Migrated from internal repository. Originally created by @EvanKirshenbaum on Jan 30, 2023 at 11:01 AM PST.