Explanation of macros; Haskell macros
joachim.durchholz at web.de
Mon Nov 3 17:37:49 CET 2003
Pascal Costanza wrote:
> When you want to bind to a resource, you usually have to make sure that
> you also unbind again later on. The standard pattern in many languages,
> modulo syntactic variations, is this:
> try: bind resource
> do something
> finally: unbind resource
> Now, this is admittedly not an example for a particularly sophisticated
> protocol. Therefore, one of the usual gut reactions from people who are
> not used to macros yet is "but I can do this with higher order functions!"
> However, what this example already shows is: The with-bound-resource
> macro doesn't tell you anything about how it achieves its goals. Yes,
> the natural way to implement this example is with a HOF, but you could
> also use a completely different approach. _With macros you can build
> abstractions that completely hide their implementation details._
I can completely hide implementation details with HOFs, too. At least
for my personal definition of "completely" - macros might have a
different idea of that.
> This becomes especially useful as soon as your protocols become more
> sophisticated, and you need to insert instructions at arbitrary places
> in the code being passed to a macro, or need to control evaluation of
> the code being passed in some other details.
Inserting "at arbitrary places" seems rather unmodular to me.
Either the macro would have to know about the code that it's being used
in, so that it can identify the places where to insert the code.
Or the code using the macro will have to pass information to the macro -
which, in a HOF context, means that the code using the HOF approach will
have to pass the code for "before the insertion point" and "after the
insertion point" as separate parameters, and the HOF would do the
necessary linkage between the two codes.
I'm not sure that macros offer a significant gain here.
> Because of this high level of expressive power that macros provide,
> Common Lispers use them regularly even for simple things. You can
> effectively write domain-specific abstractions that don't leak, and
> therefore it is justified to use them even for simple protocols.
OK, but the same can be said for HOFs.
The question is: in what ways are macros superior to HOFs to accomplish
>> Um, well, yes, there is one thing that macros can do: extending syntax
>> in ways that aren't part of the original language syntax. E.g.
>> replacing all those parentheses by indentation, or something similar
>> (Extending syntax in such ways is a mistake IMHO, but YMMV. Anyway,
>> I'm more interested in the question if there's any /semantics/ that
>> can be done via macros but not via compile-time evaluation.)
> Compile-time evaluation is a red herring.
See it this way: Macros are a way to create blocks of code. HOFs that
return functions do the same: they take a few functions (and possibly
some value arguments), stick them together, and return the result. If
the HOF is evaluated at compile time (something that I'd expect if both
functions and values submitted to the HOF are constant), then you too
have a mechanism that creates a block of code.
The working point is slightly farther down the pipeline: not at the
abstract syntax level but at the semantics level (in practice, this
would be somewhere around "decorated abstract syntax", SSA
representation, basic blocks, or so).
> Macros do their job by
> rewriting abstract syntax trees. (Lisp and macros go very well together
> because in Lisp, you essentially program using a notation that maps
> directly to an internal syntax tree, nearly without any parsing overhead.)
I agree that macros should work on the abstract syntax tree, not at the
lexical level like the C/C++ preprocessor.
> Since the syntax tree is usually available at compile time, that's the
> natural time to let macros do their job. However, in theory it wouldn't
> be a problem to use macro expansion at runtime.
Hmm... it would be highly unpracticable, I'd think.
>> Does anybody have a keyword-style list of useful applications of the
>> macro facilities?
> Do you have a keyword-style list of useful applications of functions?
I think you forgot a smiley - at least, that question is entirely silly.
If you have a real point to make, please make it explicit; I have too
little time to devote to decoding your intents. (And if you don't want
to spend time on trivialities, then please understand that I don't, too.)
More information about the Python-list