I Accidentaly Wrote a Compile-Time Executable State Machine
philippegroarke.com
philippegroarke.com
I'm pretty sure I once made a cream sauce that went full von neumann self-reproducing automaton, grey goo territory (well, technically it was more of a beige goo). Fortunately it seemed limited to incorporating organic material, so it was contained by the pan. Testing it with a small sugar cube an hour later, I determined that it had gone inert, and therefore safe to eat. It was delicious, but I'm pretty sure some component did remain active, but has maintained a steady-state equilibrium inside of my duodenum.
It seems harmless, but I often have strange dreams about breaking out of a biological prison and converting the world to more of the same substance. When I die, I should probably be cremated.
I probably shouldn't have interpreted Knuth's works as cook books.
Each module's connections and parameters was described in an external file, parsed and interpreted at compile time to generate an optimised audio graph containing only the necessary elements, from the available template modules in our signal processing library. The rare compilation errors were wild, and so was debugging it (logging through the visitor pattern).
[1] The end product was actually a microphone emulation algorithm, but some of its architecture looked a lot like a modular synth. https://slatedigital.com/virtual-microphone-system/
In D it's generally used for compile-time code generation. The regex module in the stdlib for example can compile regexes to bytecode along with the rest of your program, obviating the need for having a regex cache or for compiling regexes on the fly.
Of course it can also be used for... less useful stuff. I still think everyone should at some point try writing a compile-time brainfuck compiler in D[0]. A couple dozen lines of fairly simple code and suddenly you can use brainfuck as a DSL in your D program. You get a compiler backend with optimization for free.
As another example of a useful application might be reading and parsing a config file. That way you can quite easily configure a complex "custom" compilation without resorting to complex makefiles and whatnot.
Which leads me into another neat one: compile-time parser generation. Pegged.d can generate and compile a lexer/parser for any PEG grammar you like. Again it gets compiled at compile time and linked into your program seamlessly. Which is incredibly convenient for e.g. parsing config files and whatnot at compile time.
You might even get all fancy and parse a graphql schema or SOAP wsdl file or what have you and automatically generate an API interface at compile time. The advantage here being that e.g. calling an API function that doesn't exist or with the wrong argument types leads to a compile-time error instead of a run-time error!
So in general compile time function evaluation is really useful for moving work from run-time to compile-time. The above examples are mostly code generation -- which I imagine is less of a thing in lisp due to macros -- but it can be used for any computation that can be done at compile time. It's basically constant folding[1] on steroids.
I could go on giving examples since compile time function evaluation is so wildly widely applicable, the sky is the limit really.
[0] it really is surprisingly easy given the mixin function D provides. Just translate the brainfuck code to D code and mixin() it to get it all compiled in to the final program.