Allow packet-level environment overlay #38
Comments
|
Wait, there's a problem: sub-seeds are passed an environment entirely derived by the caller, which means that seeds that expect a given environment to be set will not have that environment set when called as a sub-expression. The fix is to make it so let/let-multi don't derive an entire environment but rather an overlay. That overlay is put over top of the base environment for each seed when grow() is called. When this is fixed, update the TODO in README. |
…at is overlaid on top of the default environment for each seed in the packet before being executed as a top-level seed. Note that there is a non-intuitive behavior, documented in a TODO in README, where seeds executed as sub-seeds of parents in other packets will not have the base environment they expect, since currently the enviroment for a sub-seed is entirely defined by the calller seed, which might come from a different context. That makes this feature less useful than it might otherwise be, because seeds that are entrypoints can't rely on having baseline variables set. Part of #38.
Now it applies as the last step in each seed before it executes, which is notionally equivalent to having a let-multi at the top of each. This allows seeds to be confident that their values are set by them and not accidentally by calling seeds. Part of #38.
|
There's still one weird edge case: if you have nested seeds where inside the nested seed it changes the environment overlay with an additional let, it will be re-overriden by the seed's environment before it's executed. This seems like the kind of weird edge case that will be rare but when it bites will be REALLY confusing. We could make it so |
The best practice is to set a particular
memoryandstore(and, in the future,prefix) that uses a distinctive prefix (e.g.komoroske.com) at the root of each seedGraph to make sure that all of the references within it use the same model/store/prefix.)However, this quickly gets extremely repetitive in packets that contain lots of entrypoints, and for ones that are intermediate entrypoints, requires duplicative environment
let-multistatements that were already done by seeds that called them.We should add a property,
environment, in a packet. It's an optional property, and should specify anEnvironmentDataoverlay. The starter environment for each seed in the packet will have that environment overlaid on whatever the previous environment was. It's as though each root-level seed is wrapped in a (hidden)let-multiwith those properties.What should the property be named?
environmentis a bit misleading because it implies it's the entire environment when really it's an overlay.letis a bit wrong because semantically it's alet-multi.varsis wrong because we usevarto mean retrieve the environment.envis wrong because that's the only place in user-facing semantics that call it that.When combined with #37, the convention will be to set a
prefixin the packet-level environment every time.A typical use case for this will be to set a namespace, but also set things like the
model. The latter requires the former. Perhaps have the value be an object or an array of EnvironmentData. If it's an array then it should create the environment by overlaying each time. Actually, this might not be required, becausenamespaceis late bound, so you can set it in the same block as another thing.Originally tracked in #36.
The text was updated successfully, but these errors were encountered: