2010-04-06
- Macro Conclusions

========================================================================
>>> Macro Conclusions

Macros are extremely powerful, but this also means that their usage
should be restricted only to situations where they are really needed.
You can view any function as extending the current collection of tools
that you provide -- where these tools are much more difficult for your
users to swallow than plain functions: evaluation can happen in any way,
with any scope, unlike the uniform rules of function application.  An
analogy is that every function (or value) that you provide is equivalent
to adding nouns to a vocabulary, but macros can add completely new rules
for reading, since using them might result in a completely different
evaluation.  Because of this, adding macros carelessly can make code
harder to read and debug -- and using them should be done in a way that
is as clear as possible for users.

When should a macro be used?

* Providing cosmetics: eliminating some annoying repetitiveness and/or
  inconvenient verbosity.  This is usually macros that are intended to
  beautify code, for example, we could use a macro to make this bit of
  the Sloth source:

            (list '+ (box (scheme-func->prim-val + #t)))
            (list '- (box (scheme-func->prim-val - #t)))
            (list '* (box (scheme-func->prim-val * #t)))

  look much better, by using a macro instead of the above.  We can try
  to use a function, but we still need two inputs for each call -- the
  name and the procedure:

            (sfpv '+ + #t)
            (sfpv '- - #t)
            (sfpv '* + #t)

  and a macro can eliminate this (small, but potentially dangerous)
  redundancy.

* Altering the order of evaluation: as seen with the `orelse' macro, we
  can control evaluation order in our macro.  This is achieved by
  translating the macro into Scheme code with a known evaluation order.
  We even choose not to evaluate some parts, or evaluate some parts
  multiple times (eg, the `for' macro).

  Note that by itself, we could get this if only we had a more
  light-weight notation for thunks, since then we could simply use
  functions.  For example, a `while' function could easily be used with
  thunks:

    (define (while cond body)
      (when (cond)
        (body)
        (while cond body)))

  if the syntax for a thunk would be as easy as, for example, using
  curly braces:

    (let ([i 0])
      (while { (< i 10) }
        { (printf "i = ~s\n" i) (set! i (+ i 1)) }))

* Introducing binding constructs: macros that have a different binding
  structure from Scheme's.  These kind of macros are ones that makes a
  powerful language -- for example, we've seen how we can survive
  without basic built-ins like `let'.  For example, the `for' macro has
  it's own binding structure.

* Defining data languages: macros can be used for expressions that are
  not Scheme expressions themselves.  For example, the parens that wrap
  binding pairs in a `let' form are not function applications.  Some
  times it is possible to use quotes for that, but then we get run-time
  values rather than being able to translate them into Scheme code.
  Another usage of this category is to hide representation details that
  might involve implicit lambda's (for example, `delay') -- if we define
  a macro, then there is a single point where we control whether an
  expression is used within some `lambda' -- but it it was a function,
  we'd have to change every usage of it to add an explicit lambda.

It is also important to note that macros should not be used too
frequently.  As said above, every macro adds a completely different way
of reading your code -- a way that doesn't use the usual "nouns" and
"verbs", but there are other reasons not to use a macro.

One common usage case is as an optimization -- trying to avoid an extra
function call.  For example, this:

  int min(int x, int y) {
    if ( x < y ) then return x; else return y;
  }

might seem wasteful if you don't want a full function call on every
usage of `min'.  So you might be tempted to use this instead:

  #define min(x,y) x<y ? x : y

you even know the pitfalls of C macros so you make it more robust:

  #define min(x,y) (((x)<(y)) ? (x) : (y))

But small functions like the above are things that any decent compiler
should know how to optimize, and even if your compiler doesn't, it's
still not worth doing this optimization because programmer time is the
most expensive factor in any computer system.  In addition, a compiler
is committed to doing these optimizations only when possible (eg, it is
not possible to in-line a recursive function) and to do proper in-lining
-- unlike the `min' CPP macro above which is erroneous in case `x' or
`y' are expressions that have side-effects.

========================================================================
>> Sidenote: why are macros so difficult in other languages?

Macros are an extremely powerful tool in Scheme (and other languages in
the Lisp family) -- how come nobody else uses them?

Well, people have tried to use them in many contexts.  The problem is
that you cannot get away with a simple solution that does nothing more
than textual manipulation of your programs.  For example, the standard C
preprocessor is a macro language, but it is fundamentally limited to
very simple situations.  This is still a hot topic these days, with
modern languages trying out different solutions (or giving up and
claiming that macros are evil).

Here is an example that was written by Mark Jason Dominus ("Higher Order
Perl") -- you might write the following macro:

  #define square(x) x*x

which doesn't work because

  2/square(10)

expands to

  2/10*10

which is 2, but you wanted 0.02.  So you need this instead:

  #define square(x) (x*x)

but this breaks because

  square(1+1)

expands to

  (1+1*1+1)

which is 3, but you wanted 4.  So you need this instead:

  #define square(x) ((x)*(x))

But what about

  x = 2;
  square(x++)

which expands to

        ((x++)*(x++))

?  So you need this instead:

  int MYTMP;
  #define square(x) (MYTMP = (x), MYTMP*MYTMP)

but now it only works for ints; you can't do square(3.5) any more.  To
really fix this you have to use nonstandard extensions, something
like:

  #define square(x) ({typedef xtype = x; xtype xval = x; xval*xval; })

or more like:

  #define square(x) ({typedef xtype = (x); xtype xval = (x); xval*xval; })

And that's just to get trivial macros, like "square()", to work.

========================================================================

You should be able to appreciate now the tremendous power of macros.
This is why there are so many "primitive features" of programming
languages that can be considered as merely library functionality given a
good macro system.  For example, people are used to think about OOP as
some inherent property of a language -- but in PLT Scheme there are at
least two very different object systems that come with plt, and several
others in user-distributed code.  All of these are implemented as a
library which provides the functionality as well as the necessary syntax
in the form of macros.  So the basic principle is to have a small core
language with powerful constructs, and make it easy to express complex
ideas using these constructs.

This is an important point to consider before starting a new DSL
(reminder: domain specific language) -- if you need something that looks
like a simple DSL but might grow to a full language, you can extend an
existing language with macros to have the features you want, and you
will always be able to grow to use the full language if necessary.  This
is particularly easy with Scheme, but possible in other languages too.

========================================================================

Side note: the the principle of a powerful but simple code language and
easy extensions is not limited to using macros -- other factors are
involved, like first-class functions.  In fact, "first class"-ness can
help in many situations, for example: single inheritance + classes as
first-class values can be used instead of multiple inheritance.

========================================================================