First, I agree that using things like "Debug ifTrue: [...]" is a simple,
direct way to accomplish things that doesn't require any compiler
hackery.  I do it all the time and the results seem pretty good.  It's
especially nice because it doesn't require any new syntax, and thus it's
easier to read (not that other systems are *hard* to read, but every
little bit helps).  So far, when programming I try to prioritize
flexibility, then readability, and finally performance.  In the case
under discussion, the tradeoff is in a lot of flexibility, a moderate
amount of readability, and probably very little performance.  Heck,
let's go with the more flexible and more readable scheme!  We're trying
to be software developers most of the time, not mere *programmers*
hacking away.


Regarding preprocessing in general, consider that a simple C-style
preprocessor is really a pain to work with.  Preprocessed code is harder
to read, harder to debug, and less flexible.  People should seriously
think about it before they do this to their code!  Is it really worth
the performance or code size gained?  Sometimes, but it should be done
with care.

That rant aside, probably the best way to optimize programs is to use
*safe* partial evaluation--ie, safe compiler optimizations.  An
interesting slant on this is systems like MrSpidey, which give feedback
to the programmer on what optimizations are possible and why.  For
example, the system can tell you that a certain expression can be
completely evaluated at runtime, or if it can't, the system can tell you
why.  There are several advantages to this kind of system:

	1. The code is still plain Lisp code, so you can use it in other Lisp
systems, and other Lispers can read your code.

	2. The changes are safe, because they are formally verified by the
compiler.  Most importantly, if you make a change that invalidates some
optimization, the compiler will just stop making the optimization.  With
manual partial evaluation, you have to remember to explicitly go remove
some optimization you've made, or you'll get incorrect code.

I can't find a reference right now to the paper I read on this style of
optimizing, but a general MrSpidey page is at:

	http://www.cs.rice.edu/CS/PLT/packages/mrspidey/

I hope people continue to experiment with this style of optimizing
programs....



-Lex