Explanation of macros; Haskell macros

[Coby Beck]

"Stephen J. Bevan" <stephen at dino.dnsalias.com> wrote in message
news:m3sml3cjtf.fsf at dino.dnsalias.com...
> "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.

The problem was a fairly ordinary one and is easy to describe at a high
level.  The server existed to control a complicated configuration process
and later process data according to the result.  It was a simple socket
server and I got to dictate the form of the commands and arguments.
Ultimately, it boiled down to (funcall command client-session args).

So I needed (wanted) a way to, in one stroke,
- define the method, properly specialized on the session object
- ensure it became an allowed function to call
- define a way to gather the arguments needed from the client
  according to number of args and the type of each.
- provide a facility for arbitrarily complex validation of any
  of the arguments or combinations thereof.
- ensure that any changes, enhancements or additions to
  argument passing would require a single point of change in my code.

Additional benefits:
- automatically provided information to a kind of "help" facility.
- allowed for very informative error messages, both in the debug
  environment and as returned data for clients.
- simplified the main server loop while remaining completely flexible

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

Hopefully the above is enough of a spec.  I would be very happy to learn
other approaches, there are always many ways to skin a cat. (how un-PC is
that saying these days ;)

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

I was fortunate to be the one defining the API so I came up with a very
clever way of having named and optional arguments that could be atoms or
lists defined by ( and ) characters.  (I should patent that ;)

I did have to define a set of safe-read functions for lists and integers and
strings etc for a combination of security and timing-out reasons.  But the
grammar was just s-expressions.  (It was culture shock for the Java client
coders, and I think they still would say SOAP was better though it is beyond
me why).

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

If the target language is Lisp, then not "looks like", but "is".  I think
you know that, though.  I actually have macros I use now that generate
strings of SQL code, some of it as format strings that will be used at a
later stage of processing (a "format string" would be something like "SELECT
NEW.~A FROM ~A WHERE ~A > 3" where the ~A's get filled with variables later)

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

This trade-off is not unique to macros, it is what we all face all the time
with new and maybe better tools or approaches.  The start-up cost makes the
first uses too expensive.  I don't know AWK at all, I'm sure if I did I
would not just open that file in emacs and use a few keyboard macros as
often...

"By the time I walk to the shed and get the socket wrench, I'll have already
got this nut off with the vice-grips..."  And it's true!  The problem being
that then at nut number five I'm thinking "if I had just gone to get that
socket wrench in the beginning, this next nut would already be off"  I have
to confess I am guilty of that all the time....But I try not to kid myself
that vice-grips are generally the best tool for removing nuts and bolts.

But back to macros, and really any language feature, they are all just tools
and it is always a judgment call as to what the best tool for a job is and
judgements are always subjective.  It is very hard to convince anyone that a
tool they are completely unfamiliar with is the best one for some problem
they never thought they had.

-- 
Coby Beck
(remove #\Space "coby 101 @ big pond . com")