Brian Beckman has some interesting observations on tree (recursive) and list (looping) representations of programs:
For some time, it was popular to experiment with VMs (virtual machines)that accepted programs represented as trees or graphs or relatedalgebraic structures. ...
However, most workers have completely abandoned this approach and goneback to instruction sets as the preferred representation at the VMboundary. ...
Since trees and their relatives are an inherently recursive datastructure, feeding them to the VM means that the VM needs to do thepedestrian step of boiling off recursive definitions before it can getto its real job. ...
Recursion is great for describing things, but lousy for executingthings. Describing things is the compiler's job, and executing thingsis the VM's job.
However, most workers have completely abandoned this approach and goneback to instruction sets as the preferred representation at the VMboundary. ...
Since trees and their relatives are an inherently recursive datastructure, feeding them to the VM means that the VM needs to do thepedestrian step of boiling off recursive definitions before it can getto its real job. ...
Recursion is great for describing things, but lousy for executingthings. Describing things is the compiler's job, and executing thingsis the VM's job.
Sounds like Herbert Simon's old descriptive vs. prescriptive dichotomy. My question is: why not send both to the VM? Then the VM can execute the instruction list immediately, but if the program needs to reflect, the tree is right there. (Of course, the instruction list would have to be (partially) recompiled if the program modified the tree.)
Also, isn't Ruby still directly executing trees?
Recent Comments