Documentation

We need to account for the costs of evaluator steps and also built-in function evaluation. The models for these have different structures and are used in different parts of the code, so inside the valuator we pass separate objects about most of the time . It's convenient for clients of the evaluator to only have to worry about a single object, so the CostModel type bundles the two together. We could conceivably have different evaluators with different internal costs, so we keep the machine costs abstract. The model for Cek machine steps is in UntypedPlutusCore.Evaluation.Machine.Cek.CekMachineCosts.

The part of MachineParameters that is individual for each semantics variant of DefaultFun.

CaserBuiltin isn't included, because it only explicitly depends on the protocol version and not the language version (even though there's an implicit dependency on the language version: older languages don't support Case in general, but it's safe to ignore that, because support for Case is controlled by the AST version, which is a separate check during deserialisation).

At execution time we need a BuiltinsRuntime object which includes both the cost model for builtins and their denotations. This bundles one of those together with the cost model for evaluator steps and a CaserBuiltin specifying how casing on values of built-in types works. The val type will be CekValue when we're using this with the CEK machine.

This just uses toBuiltinsRuntime function to convert a BuiltinCostModel to a BuiltinsRuntime.