Documentation

A BuiltinRuntime represents a possibly partial builtin application, including an empty builtin application (i.e. just the builtin with no arguments).

Applying or type-instantiating a builtin peels off the corresponding constructor from its BuiltinRuntime.

BuiltinCostedResult contains the cost (an ExBudget) and the result (a BuiltinResult val) of the builtin application. The cost is stored strictly, since the evaluator is going to look at it and the result is stored lazily, since it's not supposed to be forced before accounting for the cost of the application. If the cost exceeds the available budget, the evaluator discards the result of the builtin application without ever forcing it and terminates with evaluation failure. Allowing the user to compute something that they don't have the budget for would be a major bug.

Evaluators that ignore the entire concept of costing (e.g. the CK machine) may of course force the result of the builtin application unconditionally.

A data wrapper around a function returning the BuiltinRuntime of a built-in function. We use data rather than newtype, because GHC is able to see through newtypes and may break carefully set up optimizations, see https://github.com/IntersectMBO/plutus/pull/4914#issuecomment-1396306606

Using data may make things more expensive, however it was verified at the time of writing that the wrapper is removed before the CEK machine starts, leaving the stored function to be used directly.

In order for lookups to be efficient the BuiltinRuntimes need to be cached, i.e. pulled out of the function statically. See makeBuiltinMeaning for how we achieve that.

Look up the runtime info of a built-in function during evaluation.