defun a{defun b{+} 1 2 b}

->

defun a{1 2 a.b}

defun a.b{+}

This mechanism self propagates

defun 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.b

This would expand to be .xxx -> [name].xxx

Could 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.b

And perhaps

. -> a.b.c

Unfortunately, this system doesn't look self propagating

Maybe I have the macro/defun dichotomy all wrong and everything should be a macro with a sigil system to define whether to inline or not

There. 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 chars

With 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