I've not written a Scheme macro since. I've written hundreds of Kernel operatives though.
I was also a typoholic previously, but am in remission now thanks to Kernel.
An example: building the equivalent of a switch statement, but that compares (via string equality) with a set of strings. The macro would translate this into code that would do something like a decision tree on string length or particular characters at particular positions.
Basically anything that's done with a preprocessor in another language can be done with macros in Lisp family languages.
I use C preprocessor macros extensively and don't have the typical dislike for them that many people have - though I clearly understand their limitations and the advantage Scheme macros have over them.
Since learning Kernel, the boundary of "compile time" and "runtime" is more blurry - I can write operatives which behave somewhat like a macro, and I do more "multi-stage" programming, where one operative optimizes its argument to produce something more efficient which is later evaluated - though there are still limitations due to the inability to fully compile Kernel.
As one example, I've used a kind of operative I call a "template", which evaluates its free symbols ahead of time but doesn't actually evaluate the body. When we later apply the some operands it replaces the bound symbols with the operands, looking up any symbols to produce an expression which we don't need to immediately evaluate either - but this expression has all symbols fully resolved. This is somewhere between a macro and regular operative.
Consider:
($define! z 10)
($define! @add-z
($template (x y)
(+ x y z)))
([#applicative: +] x y 10)
> ($let ((x 9)
(y 7))
(@add-z (* x 3) (- y 13)))
([#applicative: +] ([#applicative: *] 9 3) ([#applicative: -] 7 13) 10)
---
The $template form above isn't too difficult to implement. I've iterated several forms of this - some which only partially resolved the bound symbols, but lost them in a RAID failure. An earlier version which has some issues I still have because I put it online:
($provide! ($template)
($define! $resolve-free-symbols
($vau (params expr) env
($cond
((null? expr) ())
((pair? expr)
(cons (apply (wrap $resolve-free-symbols)
(list params (car expr))
env)
(apply (wrap $resolve-free-symbols)
(list params (cdr expr))
env)))
((symbol? expr)
($if (member? expr params)
expr
(eval expr env)))
(#t expr))))
($define! $resolve-bound-symbols
($vau (params expr) env
($cond
((null? expr) ())
((pair? expr)
(cons (apply (wrap $resolve-bound-symbols)
(list params (car expr))
env)
(apply (wrap $resolve-bound-symbols)
(list params (cdr expr))
env)))
((symbol? expr)
($if (member? expr params)
(eval expr env)
expr))
(#t expr))))
($define! zip
($lambda (fst snd)
($cond
(($and? (null? fst) (null? snd)) ())
(($and? (pair? fst) (pair? snd))
(cons (list (car fst)
(list* (($vau #ignore #ignore list)) (car snd)))
(zip (cdr fst) (cdr snd)))))))
($define! $template
($vau (params body) senv
($let ((newbody
(eval (list $resolve-free-symbols params body) senv)))
($vau args denv
(eval (list $resolve-bound-symbols params newbody)
(eval (list* $bindings->environment
(zip params args))
denv)))))))
At present the best interpreter is klisp, and the fastest is bronze-age-lisp, which uses klisp - with parts of hand-written 32-bit x86 assembly.
I've been working on a faster interpreter for a number of years as a side project, optimized for x86_64 with some parts C and some parts assembly. It has diverged in some parts from the Kernel report, but still retains what I see are the key ingredients.
My modified Kernel has optional types, and we have operatives to `$typecheck` complex expressions ahead of evaluating them. I intend to go all in on the "multi-stage" aspect and have operatives to JIT-compile expressions in a manner similar to the above template.
I've written a number of less complete interpreters over the years. I currently have a long-running side-project to provide a more complete, highly optimized implementation for x86_64.