and it looks just like normal code, but really you are just passing a data structure to the compile-bunny function. The direct equivalent in Python is awful:
but you can build up a pretty decent EDSL in Python for this sort of thing with operator overloading, similar to what Sympy does:
x.set(y[i] + x).compile()
That looks a lot more like normal Python code, but getting it working is a bigger hassle than in more conventional Lisps where you can just quote whatever S-expression. (Of course, your compiler has to handle each type of expression sooner or later, so this isn't as big a deal as it might sound.)
But neither one of these is compiling your Python code. Python's bytecode may give you a head start on that if you do want to do it.
> your compiler has to handle each type of expression sooner or later, so this isn't as big a deal as it might sound
It's a bigger deal than you think. Not only can you leverage the CL parser on the front end so that you can convert code to data simply by prefixing it with a quote, but you can also leverage the CL compiler on the back end to generate the final code. So you don't have to build a complete back end. All you have to do is translate your language into Common Lisp and then pass that on to the CL compiler. That is almost always orders of magnitude simpler than writing a complete back end. The only time it doesn't work is if your language has semantics that are fundamentally different from CL. (The classic example of this is call/cc.) But 99% of the time you don't need this, and so 99% of the time writing a compiler in CL is 1% of the work it otherwise would be.
This is awkward because I'm mansplaining your own project back to you, but, as I understand it, you were compiling to the 68(HC?)11, which your CL compiler back end didn't support, so I don't think it helped you in that way, to generate the final code. Unless I've misunderstood something fundamental?
Depending on how the compiler was structured, it could have helped you in some other way, like doing target-independent optimizations, if there was a way to get some kind of IR out of it instead of native code for the wrong CPU.
I agree that there are lots of cases where the approach you're describing works very well and has a huge payoff, though I've only done it with C, JS, and Lua compilers rather than CL compilers. Usually it's been more like 20% of the work rather than 1% of the work, but maybe that depends on the level of optimization you're hoping for.
But neither one of these is compiling your Python code. Python's bytecode may give you a head start on that if you do want to do it.