[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: macros vs. blocks
>>>>> "Anton" == Anton van Straaten <anton@appsolutions.com> writes:
Anton> Michael Sperber wrote:
>> While everything else you say is true, SSAX:make-parser is a poor
>> example for an intrinsic use of macros: it's a macro purely for
>> efficiency reasons (at least it was the last time I looked at it) and
>> has a trivial counterpart in procedural form.
Anton> You could have put it a bit more gently!
Sorry. I'm German, after all :-)
Anton> Whose side are you on? ;)
I'm on the side of using macros only where there's significant
benefit. I do agree there are a number of situations where there is
significant benefit.
Anton> Performance is one of the purposes of the macro in this case, but it's not
Anton> the only one. The SSAX:make-parser macro takes up to seven named callbacks
Anton> as arguments. Not all of the callbacks have to be supplied; defaults will
Anton> be used for those that are omitted. The call looks something like:
Anton> (SSAX:make-parser
Anton> NEW-LEVEL-SEED (lambda (...) ...)
Anton> UNDECL-ROOT (lambda (...) ...))
Anton> ...where the capitalized names name the subsequent callback procedure.
Anton> This design serves at least two purposes, which I'll describe before
Anton> comparing to the alternatives:
Anton> First, it provides a convenient interface for constructing parsers. The
Anton> host language here, Scheme, doesn't intrinsically have named arguments to
Anton> procedures, but that feature has been created for this macro, and used to
Anton> provide three of the usual benefits of named arguments: the ability to omit
Anton> arguments, to list them in arbitrary order, and the improved readability
Anton> that can come from explicitly naming them. Together, this allows a complex
Anton> parser to be constructed quite flexibly, with a single expression, while
Anton> retaining comprehensibility.
Well, the alternative is simply saying:
(SSAX:make-parser
'NEW-LEVEL-SEED (lambda (...) ...)
'UNDECL-ROOT (lambda (...) ...))
This doesn't look all that bad to me. (In fact, I did just that for
the original PLT/Scheme 48 port of SSAX which I did in April or so, so
I know that it works. It's possible to get rid of even that by
DEFINEing the keywords to something. Some Lisp/Scheme dialects
implicitly define identifiers starting with a : to symbols with the
same name which also solves the problem.)
So I think macros purely for the purpose of quote-sprinkling seems
like overkill to me. If applied too liberally (as in the case of the
scsh shell subsystem, for example), it can lead to confusing programs.
Anton> Now, on to performance: some people have suggested that this is
Anton> unimportant.
All the performance gains in this case could be gained from a
reasonable inlining compiler. I don't know if Oleg's done any
measurements, but the original motivation for making SSAX:maker-parser
came from making it run faster in the Gambit-C *interpreter*.
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla