Three Dollar Quill

All right. The flake8-black maintainers stepped up pretty quickly, so everything was working right by sometime this morning. Thanks for that.

I wrote a basic evolution method, and set it up to be used. There are a more to go. I think for now, I'll focus on the ones without tricky issues.

And, that didn't fully work, because the logic for combining Dynamic metadata is annoyingly fiddly. (A lowlight of this effort was realizing that I'd forgotten that I'd implemented some required logic, because it was in a function with a name that did not indicate that it should be there.)

Before I touch any more of this, I'm going to go over the flex concept, carefully.

The basic idea is that a given invocation will have some values that vary, not based on the base structure of the invocation, but based on values passed into the function that constructs the invocation. To produce the required variation, the caller needs to provide a mapping from registry values to something that can fit in a path. Let's call one of these sites of caller-parameterized variation Flex objects. A given invocation can have many Flex objects, and what they do is take a set of keys and associated functions, and pass that data into each Flex object.

This promises to get even more confusing, because this isn't the order that the current code does things, but maybe it should do them in this order.

Anyway, I've got a scenario I'm trying to work out that's confusing me. There are two broadly different "modes" of carrying out the Flex operation, based on whether the goal is to produce an "input" or an "output" to the invocation. At the invocation level, Flexes are introduced in "output" mode, and reused in "input" mode. The result of this is that there could be a Flex that got several keys associated with it in "output" mode, and then, when it's used in "input" mode, the object it produces must not provide any keys that aren't required by outputs from the invocation. The only way I see right now to make this vaguely tractable is to require that all outputs are specified using Flex objects, which ought to be fine in this context.

So, what do we know about this situation? Well, "output" mode Dynamics require that no associated Dynamics provide a key that is not known to them, which means that the keys available for Flex operations must be a superset of all keys provided by any part of the invocation. And that means that when we carry out a Flex in input mode, we want the resulting Dynamic to provide the intersection of its keys and the provided keys.

Stepping away from this code for a bit and then coming back gave me the perspective I needed to properly understand it. I now properly understand that this code is a confusing monster.

I'm going to try to chip away at this code for a while, but I think I need to accept that, for a while, this could very well end up being something where I put in a lot of effort to get back a little progress.

Anyway, I don't want to drag this out any more, so I'm going to wrap this up and ponder my decisions.

Good night.