Explanation of macros; Haskell macros

[Stephen J. Bevan]

"Coby Beck" <cbeck at mercury.bc.ca> writes:
> Here's a nice example from some production code I wrote that is easy to
> grok.

I follow it to a certain extent but the problem now is that we are
given a solution with together with an explanation of what it does,
but we don't know all the details of the problem that shaped the
solution.  Therefore while it is possible to agree that the macro
version obviously hides a lot of detail, it isn't entirely clear if
that is the best way to hide it or even if that detail is required.

I'm not asking you to give the full requirements for your program,
only explaining why if it isn't clear what the problem is then nobody
can easily tell if the macro-based solution is an improvement over
anything else.  For example, if the commands have any kind of grammar
then solution is to define the grammar and let a parser generator take
care of parsing and building an AST.  Whether the parser generator is
an extension of the language (as is possible in Lisp and Forth) or a
separate language (most other languages) is to a certain extent an
implementation detail.  At the other extreme is a simple flat file
that is processed by an AWK program to generate source in the target
language.  To someone used to using macros, the AWK approach looks
like a really poor substitute for a subset of what macros can do and
it is from that perspective.  However, the AWK route is also an
approach that can solve a lot of simple problems, probably even the
one you solved using macros.  Note I'm not going to argue that it any
solution using AWK is *better* than using a macro based solution, only
that to sell macros to someone using the AWK approach the pitch has to
convince them that the macro approach is significantly better in
order to be worth investing the time and effort to learn.  What
constitues "significant" obviously varies.