Three Dollar Quill

Traveled back, and had time to consider the names in MOTR. I've ended up having to reconsider something that was bothering me last time: I've managed to build part of the system thoroughly and pervasively around a concept that I can't figure out a good name for. It's as if I'm a carpenter who is perfectly skilled on a technical level, but I don't know the word for "join", so I have no idea how to explain what I'm doing.

Basically, suppose you have a data type called a Label, which has a type parameter with no run-time effect, and it compares by identity instead of by structure. This means you can (provided the proper plugin code exists) construct containers that map a Label[M[T]] to a N[T], for some M and N. I call the type mapping Label[T] to T, Box. The metaphor here is that the box has a label on it, and the label indicates what's in there. Now, suppose M[T] is tuple[T, ...]. If you apply the corresponding label to a Box, then the value is a collection of T. But if you have a container with the given M, but N[T] is just T, then that same label maps to a single T. This could be a choice of T from the collection in the Box, and because it's a choice, I call it a Selection.

I went a little crazy with custom container types once I got the plugin working, but those two types end up enabling a lot. Clearly, once you have these types, and the right labels, you can convert a function that takes values of types into a function that takes a Box. And if some of the labels are to collections where you just need one value, you can get that value out of a Selection. In the context where I'm using these functions, it makes sense to want them to, instead of returning a value directly, actually return a generator that yields something called Facts, and then terminates with the value. There are some obvious questions here about whether these values can actually be expected to be in the relevant containers, and pinning down the answers to those questions is where a lot of the code at this level of abstraction comes from. But the first question I think I need to answer here is, given a function that takes a box and a selection, and yields facts before stopping with a value, what do we call that?

(There are some changes I want to make to the code later that will somewhat obscure this relationship at a syntactic level, but I'd rather ignore that caveat.)

The idea of all of this is that the top-level invocation will yield the facts associated with every possible selection that can be made from the box. (Where the definition of "every possible selection" is actually very subtle and fiddly.)

I wonder if one of those parenthesized statements could help. Like, if the underlying function is just a nullary function that returns a generator. (Or possibly just an arbitrarily resumable generator...) That object is now wholly defined by its output behavior, which is to calculate a value and yield facts as a side effect.

This feels like there's something to figure out from this perspective, but it's like I'm missing a piece...

I'll just have to think about it later, because it's getting late and I feel my mind fogging up.

Good night.