I think that many interpreters go further down the path of pretending to be hardware than what makes sense in most cases; allocating a chunk of memory and prete

I think that many interpreters go further down the path of pretending to be hardware than what makes sense in most cases; allocating a chunk of memory and pretending it's the entire world, pure byte code etc. You can get pretty decent performance for substantially less effort by reusing more features of the host language, enums or tail calling closures for ops, inlining values without bit twiddling etc. I still feel there's a point in having two separate representations though, one for reasoning about the code at a higher level and one for execution; it also gives you a compilation phase as a consequence, which allows nailing decisions statically and avoiding run time performance hits. Lisp makes an interesting implementation language, since it allows easily generating and compiling code straight to the host language, which adds another layer of interesting possibilities for optimization.