Nah, if it's this topic, more like how AllegroCache object-database maps high-level commands on database manipulation in LISP that look similar to regular manipulation of objects to lower-level LISP that's more efficient which compiles to machine code that efficiently implements those structures on target CPU. Typical ORM's take two things that are very different from one another and never intended to match up then try to force them to match up. Not a great example.
Here's another for you: Lilith. Assembly is messy. So, they create a stack machine (M-code - P-code variant) that idealizes it plus easily compiles to it or implementable at CPU level. Then, they create a 3GL called Modula-2 that's closer to how they express programs but has underlying model of M-code and outputs M-code. In theory, they could go further like 4GL's did to build domain-specific languages that abstract away boiler plate with code generation but still consistent with Modula-2 style. And so on. Easier in functional languages but I'm sure you can see the pattern.
That's what you usually get out of the DSL or interpreter approaches if using a LISP, Haskell, or imperative language designed to make it easy. Languages designed to do them well. A series of transforms with a certain amount of consistency from start to finish. These days, there's even safety techniques for the transforms that they didn't have way back in the day. :)