I'm struggling with the same problem: I'm a Lisp programmer who's writing a commercial game, in my case a Unity engine game, which requires C#.
I've opted for a less elegant, but technically simple strategy: I'm writing all the build tools/content tools in Clojurescript, and then writing only the core game engine in raw C#.
Next, I'm using http://bridge.net to cross-compile the game engine into javascript, which I can then link to from clojurescript so that all unit tests and 90% of all QA testing can be done via clojurescript tooling, without any C# in sight.
This allows me to deploy a commercial game in "native" C# without any performance penalty, but with as few lines of C# as humanly possible.
That sounds like a great approach. I often wondered how to get Scheme code running in Unity.
Can you fire up a REPL while the game is running? That would be huge.
Many years ago I experimented with the idea of creating games for iOS in Chicken Scheme. Because I'm exceedingly lazy and did not want to bother with cross-compilation – unless it became a serious project – I just told Chicken's compiler to stop at the C code generation step. The Makefile would then copy the generated (and quite unreadable) C code to the XCode project, and then compile the whole thing together with any Objective-C code I had.
With very little setup code, you could embed arbitrarily large Chicken programs. And given Chicken's excellent C interop, the Objective-C code could easily call Scheme functions (the reverse is not as trivial, so I just wrote wrappers for the handful of Objective-C functions I needed – which weren't many in a game).
The only piece missing at the time was that Chicken did not have OpenGL-ES bindings. I solved that by copying code from Gambit Scheme, and using a couple of very trivial macros to make it compatible.
That worked beautifully. I could even start a remote REPL and instantly change running code over the network, no matter if it was running in a real device or the simulator. And I mean instantly: the next rendered frame would already have the changes.
Then I hit my roadblock: I had successfully solved the technical problem, so I lost interest in pursuing the game, which was ostensibly the reason why I had embarked on this detour to begin with. Oh well.
Using Clojure CLR would make the build process simple, at the cost of some complexity and likely a performance penalty in the deployed application.
On the other hand, my strategy makes the final deployed application dead simple and fast, but leads to a build process that's complex and messy.
It seems objectively true that the latter approach is going to be less risky, because if the final deployed game doesn't work well, the whole project is f###ed.
The only way to mitigate this risk and still stay with 100% Lisp is to create your own Lisp compiler, which is exactly what OP did... but that way lies insanity :)
Have you explored Arcadia at all? It uses the Clojure CLR port to hook into Unity with some sweet repl goodness.
https://github.com/arcadia-unity/arcadia
There seems to be some active development and I hope it works out great.
I've opted for a less elegant, but technically simple strategy: I'm writing all the build tools/content tools in Clojurescript, and then writing only the core game engine in raw C#.
Next, I'm using http://bridge.net to cross-compile the game engine into javascript, which I can then link to from clojurescript so that all unit tests and 90% of all QA testing can be done via clojurescript tooling, without any C# in sight.
This allows me to deploy a commercial game in "native" C# without any performance penalty, but with as few lines of C# as humanly possible.