the env system code is unecessarily fiddly. The current env system is
the second env system, so the layer system will be the third
implementation of the env system.
the environment in which we run our tests is a layered environment like
the scope in a programming language, but unlike with nested closures,
tea permits the user to supply match tags to skip what would be stack
frames in a system based on nested closures. It's more easily understood
as being a system of layers, and that we skip non-matching layers.
the env system also had the problem that it was a tree that was
dynamically constructed as a side-effect of the execution tree, but each
chain only needs to read its own ancestry in the environment tree.
Having a single tree poses challenges for parellelizing the execution of
different test chains, so instead, I would rather keep a list of layers
for each chain, instead of keeping a single environment tree that is
shared across all chains in the run. Additionally, the env system was
sparse; tests that save no data put no nodes in the env tree. I would
like to be able to display to users the layers available to their test
in certain error cases so that they can understand why a match may have
failed. Right now, in practice, encountering a match failure in a test
plan is confusing to understand.
I keep writing these one-off when I actually use tea. It seems like it's
worth including. It's especially useful for the root test, where you
don't necessarily want to create a test, but want to create a starting
environment. Exporting a type that always passes is preferrable to
making an explicit environment type, since we can maintain our
guarantees that our environment isn't an invalid value.
Jordan Orelli