We need to write in Alacrity an interpreter for the Alacrity VM, defined as a trivial bytecode representation of the last stage of the compiler, i.e. currently the "BL" language.
Indeed, treating code as data is the only way that we can support large programs and/or programs dynamically defined on a side-chain:
An Ethereum contract is limited to 24KB per contract, and though it is possible to define and use libraries, both the definition and use are expensive (the use exponentially so with library depth).
A BCH covenant is limited to 520 bytes / 201 instructions per frame, 25 frames per 10-minute block (that takes 60 minutes to confirm), and while a program may involve as many frames as we want, large computations at a time are just not practical.
When using a contracts on a side-chain, proper contract execution must itself be checkable from the main-chain as part of checking the proper functioning of the side-chain. In that execution, the code of side-chain contracts is data as far as the main-chain contract is concerned.
Yes, there are reflection techniques that can sometimes be used to create code from the data so as to evaluate it more efficiently on the main chain. But economic efficiency, not CPU efficiency, is what we're looking for, and I don't think it ever justifies such dynamic compilation step.
We need to write in Alacrity an interpreter for the Alacrity VM, defined as a trivial bytecode representation of the last stage of the compiler, i.e. currently the "BL" language.
Indeed, treating code as data is the only way that we can support large programs and/or programs dynamically defined on a side-chain: