Explanation of macros; Haskell macros

[Joachim Durchholz]

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!"

Indeed.

> 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 
this?

>> 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 
>> un-Lispish.
>> (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.)

Regards,
Jo