We are evaluating how Cadence programs can be executed using an alternative approach, namely compilation (code generation). Programs executed using the alternative approach must behave exactly like the current approach, interpretation using the interpreter.
Currently the implementation of the majority of the built-in functionality of Cadence is part of the package implementing the interpreter, interpreter. The implementation is also tightly coupled to the interpreter.
If we can find a way to decouple the built-in functionality from the interpreter, we can reuse it for the alternative execution approach, and do not have to re-implement the functionality, which is a lot of work, and very difficult to get correct, as it must function exactly like the existing solution.
Decouple and define (an) interface(s) for the following components, so they can be reused outside of the interpreter:
Values (interpreter.Value and implementations)
Static types (interpreter.StaticType and implementations)
Encoding (encode.go and decode.go)
This is difficult, as values are tightly coupled to the interpreter (most functions of the values get passed the full interpreter).
We might want to refactor the code gradually instead of all parts all at once.
interpreter.Value methods depend on the Interpreter for the following categories of operations, for example:
Metering of computation: ReportComputation
Metering of memory usage: MeterMemory
Get configuration: for example to determine if feature is enabled (e.g. tracing), invoke callbacks, etc.
Tracing: e.g. reportDictionaryValueDestroyTrace
Resource tracking: e.g. withResourceDestruction
Reference tracking: e.g. invalidateReferencedResources
Function value invocation: e.g. invokeFunctionValue
Storage writes: e.g. WriteStored, RemoveReferencedSlab
Storage reads: e.g. ReadStored
Ensure invariants: e.g. withMutationPrevention
Atree validation: e.g. maybeValidateAtreeValue, maybeValidateAtreeStorage
Static type conversion and validation: e.g. MustConvertStaticToSemaType, ExpectType, checkContainerMutation
We are evaluating how Cadence programs can be executed using an alternative approach, namely compilation (code generation). Programs executed using the alternative approach must behave exactly like the current approach, interpretation using the interpreter.
Currently the implementation of the majority of the built-in functionality of Cadence is part of the package implementing the interpreter,
interpreter. The implementation is also tightly coupled to the interpreter.If we can find a way to decouple the built-in functionality from the interpreter, we can reuse it for the alternative execution approach, and do not have to re-implement the functionality, which is a lot of work, and very difficult to get correct, as it must function exactly like the existing solution.
Decouple and define (an) interface(s) for the following components, so they can be reused outside of the interpreter:
interpreter.Valueand implementations)interpreter.StaticTypeand implementations)encode.goanddecode.go)This is difficult, as values are tightly coupled to the interpreter (most functions of the values get passed the full interpreter).
We might want to refactor the code gradually instead of all parts all at once.
interpreter.Valuemethods depend on theInterpreterfor the following categories of operations, for example:ReportComputationMeterMemoryreportDictionaryValueDestroyTracewithResourceDestructioninvalidateReferencedResourcesinvokeFunctionValueWriteStored,RemoveReferencedSlabReadStoredwithMutationPreventionmaybeValidateAtreeValue,maybeValidateAtreeStorageMustConvertStaticToSemaType,ExpectType,checkContainerMutation