A Real-life VM

July 17th, 2003 in Design

While doing the dishes tonight, I was thinking about a simulation VM that mimics the low-level semantics of the real world. Data-types would match substance, the basic constructs of all matter. Functional abstractions would model the interactions between pieces of matter. And threads of execution would simulate the application of energy to the system.

Matter is essentially data that changes frequently, based on interactions and unseen forces. Most interactions can be modeled as data with an algorithmic aspect — the data as part of a matter-map and the interaction as functionality. Threads of energy would iterate related interactions, which in turn would aply the datum of the matter with the algorithms of the interactions.

I’m sure that this isn’t an entirely accurate picture of the universe, but it is an interesting approach to modeling it. The part that really struck me was that it could be implemented as a high-level . The of the machine would know how to combine the , with the result as new matter and energy. Execution as energy; functional definition as combinatory and interaction code; and data as matter. Seems simple.

Here’s an example, in pseudo-matter-perl:

($matter, $energy) = combine(2 * $H2, $O);
$e = &$energy($matter);
print "$e, $matter, $energyn";

Running the simulation would yield:

$ ./make_water
572 kJ, 2 * (H2O), 0x4358FFE8

The Perl-ish example above shows that a VM wouldn’t really be needed, if a suitable abstraction could be designed. I was too lazy to come up with an assembly syntax for the universe, a hint that an abstraction might be a simpler path. A concrete simulation-VM, though, would allow the operations to be highly optimised, and would allow the basic language to mirror the domain more precisely.

Thinking about a universe simulator was a good way to escape the reality of doing the dishes. It reminded me that VMs are a domain-abstraction tool, with advantages and disatvantages over language-constrained abstractions. I would probably favour the VM-approach, mostly because of the fine-grain of control it yields over the language and data layouts, and the distance it gives you from the limitations of existing languages. But the advantage comes at the cost of complexity, which is at odds with my lazy nature.