defun a{defun b{+} 1 2 b}
->defun a{1 2 a.b}defun a.b{+}This mechanism self propagatesdefun a{defun b{defun c{+ +} 3 c} 1 2 b}->defun a{1 2 a.b}defun a.b{defun c{+ +} 3 c}->defun a{1 2 a.b}defun a.b{3 a.b.c}defun a.b.c{+ +}Postal is now 230 lines, 231 with the addition of , to argv[-i a.asm , b.asm] -> [-i a.asm -i b.asm]Which also self propagates[-i a.asm , b.asm , c.asm] -> [-i a.asm -i b.asm , c.asm] -> [-i a.asm -i b.asm -i c.asm]Thinking of making it .b -> a.b rather than b -> a.bThis would expand to be .xxx -> [name].xxxCould expand it so that given a a.b a.b.c a.b.c.d and in scope a.b.c.d -> a.b.c.d..c -> a.b.c…b -> a.bAnd perhaps. -> a.b.cUnfortunately, this system doesn't look self propagatingMaybe I have the macro/defun dichotomy all wrong and everything should be a macro with a sigil system to define whether to inline or notThere. Now func expands as if a macro, func() calls as if a function and &func pushes a pointer to func. And since every function call is now tied with macro expansion, every function is now a function template and therefore I've got function templates. And since every function is actually a function template before being turned into a function when called, unused functions are no longer included in the binary. This of course makes function names even more cryptic in the outputted source since the name is now based on the actual source code of the function. I'll probably have to hash the desym function now since FASM doesn't like labels with more than 255 charsWith all the hassles of merging functions and macros, Postal is now at 247. Bleh, I had gained so much ground to lose it all in that simplification of the syntax. Oh well, that's still 50 lines less than the peak