Python syntax in Lisp and Scheme

[Raffael Cavallaro]

In article <m1d6d9njkr.fsf at tti5.uchicago.edu>,
 Matthias Blume <find at my.address.elsewhere> wrote:

> Most of the things that macros can do can be done with HOFs with just
> as little source code duplication as with macros.

Most, but not all. From <http://okmij.org/ftp/papers/Macros-talk.pdf>

"One sometimes hears that higher-order functions (and
related non-strictness) make macros unnecessary. For
example, In Haskell, 'if' is a regular function. However,
every language with more syntax than lambda-calculus
has phrases that are not expressions. Examples of such
second-class forms are: type, module, fixity and other
declarations; binding forms; statements. Only macros
can expand into a second-class object. The result of a
function is limited to an expression or a value."


> (And with macros
> only the source code does not get duplicated, the same not being true
> for compiled code.  With HOFs even executable code duplication is
> often avoided -- depending on compiler technology.)

So you're willing here to trade code size for readability. The pro-macro 
camp (myself included) find that macros make source code easier to read 
and write than the equivalent HOF solution. We're willing to trade that 
ease of use for a little compiled code size, especially when this means 
you can write your code in what amounts to a domain specific language.


> > This can only be accomplished with functions if you're
> > willing to write a set of functions that defer evaluation, by, say
> > parsing input, massaging it appropriately, and then passing it to the
> > compiler. At that point, however, you've just written your own macro
> > system, and invoked Greenspun's 10th Law.
> 
> This is false.  Writing your own macro expander is not necessary for
> getting the effect.  The only thing that macros give you in this
> regard is the ability to hide the lambda-suspensions.

But this hiding of the lambda-suspensions is the whole point. Why look 
at how the code works unless you have to? Why not work in a syntax, a 
domain specific language, that matches the problem? Put the complexity 
into one place (the macro) and make the rest of the code easier to 
write, and clearer to read.

For me, macros are about making the code one writes match the problem 
one is thinking about. HOFs seem to me to be about looking cleverly 
functional, not making the code look like the problem domain.