Expression evaluator decides module call values using instances.Expander and namedvals.State #34545

This new method calculates the static Module address corresponding to the receiver, effectively discarding any instance keys present in the containing module instance path.

This is just a variation of the pre-existing ModuleInstance.Call that returns its result as a single value of type AbsModuleCall. This should really have been the signature of ModuleInstance.Call in the first place, but it took us some time to realize that we would benefit from an absolute address type for module calls themselves as opposed to the instances they imply once expanded, and so AbsModuleCall didn't exist at the time we originally wrote ModuleInstance.Call. Perhaps one day we'll update all existing callers of ModuleInstance.Call to use ModuleInstance.AbsCall instead, but for now we'll be pragmatic and keep both to avoid causing unnecessary churn.

This is a similar idea to Expander.ExpandModule but for situations where we already know exactly which containing module we're evaluating inside, and thus we can just pluck out the leaf instance keys of that specific dynamic call, rather than the full recursive expansion of every containing module. Expander.ExpandModule is useful when implementing DynamicExpand for a graph node because main graph nodes always represent static configuration objects, but this new Expander.ExpandAbsModuleCall is more appropriate for use during expression evaluation of references to a module call because in that case we'll know which specific module instance address we're using as the evaluation scope. A future commit will actually use this new method from the expression evaluator in the modules runtime.

We've been gradually improving the design of how we keep track of "named values" such as output values, but the expression evaluator for output values was still doing some things in more manual/bespoke way, rather than making use of the new abstractions. We'll now use a combination of instances.Expander and namedvalues.State as the source of truth for which instances exist for a given module call and what output values each of those instances have. The configuration remains the decider for which output value names are declared, but the final result associated with each of the declared output values is tracked by namedvalues.State. This also removes the temporary namedvals GetOutputValuesForModuleCall method we added as a stopgap to allow introducing the namedvals.State API without such a disruptive rewrite of our output value handling. We have no further need for that helper because instances.Expander already knows which instances should exist for each module call, and the configuration knows which output values should exist in the result, and so namedvals only needs to be able to return one final output value result at a time, via namedvals.State.GetOutputValue. With all of the tricky inline logic factored out of this part of the evaluator, the TestEvaluatorGetModule test becomes considerably simpler since it's no longer the evaluator's responsibility to choose between various different sources for the module output values depending on the situation, and instead we just need to set the evaluator and the instance expander up in a realistic way, with the correct handling of both of those utilities already being covered by this package's main integration tests.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Expression evaluator decides module call values using instances.Expander and namedvals.State #34545

Expression evaluator decides module call values using instances.Expander and namedvals.State #34545

Commits on Jan 19, 2024