Source maps can be a good start, but there are a few things about clvm and similar compilation targets that may need at least one more step. In javascript, the vast majority of code the vm executes comes from a source file, is read once and ultimately referenced by address. Doing that, it’s easy to centralize the information needed to map a specific statement (however the vm stores that internally) to a souce map reference. You wouldn’t have source map info for the function that results from calling the Function constructor. At least in chialisp, there is a lot of code that passes on or modifies the environment as a normal clvm value (a lot like calling a function that results from the Function constructor in javascript).
If care is not taken, it can be difficult or expensive to determine whether some clvm value passed to apply matches a function from the original clvm code. Really the difficulty boils down to these specifics:
- Determine as well as possible the heritage of values passed to apply to recover their relationship to specific parts of the input clvm expression.
- No statements means no high level sequencing outside of either functions or individual forms.
- Very compact structure means that individual subexpression can have the same clvm representation, which means that a simple 1-1 mapping of literal values in apply isn’t sufficient.
- Javascript environments are mutable hashes with names that have inferrable mappings. clvm only has numeric environment references, and they only take place after a full apply. A system with as much power as dwarf is likely needed to fully recover variable assignments in every context.