The eth_sendTransaction RPC call, when you omit the to field, is designed to run calldata as opcodes for arbitrary execution associated with the address of the future contract address to be created, to allow for the behavior of a constructor. Technically, it does not even have to result in a contract creation.
A couple weeks ago I had a dream that I attempted the eth_sendTransaction trick with eth_call, by omitting the to field in the payload, and it behaved similarly. I tested it out at some point, and it turns out it actually worked. So this would theoretically allow you to write compact evm snippets that performed complex data aggregation tasks across the network and format a massive return buffer and offload as much client side processing to an RPC cluster as you wanted, especially when existing view layers were non existent, inefficient, or otherwise not worth the gas money of deploying your own, especially when the nature of the queries on your dapp are updating in complex ways.
What it does
How I built it
I created a table of opcodes, and designed logic for passing over nested lists in as few passes as possible to encode static pointers accurately in the final pass.
Challenges I ran into
Silly things involving off by one errors when calculating the size of final segments and the minimal jumpdest push width, etc
Accomplishments that I'm proud of
I have never heard of this eth_call trick, and I'm not sure if it exists as an unintended consequence of RPC call objects. I'm not sure if I am the first to discover it has a use case.
What I learned
A lot! As discussed.
What's next for emasm
Extra function to validate an AST for errors, and generic ABI encode/decode macros