do...until wisdom needed...

[Neelakantan Krishnaswami]

On Wed, 18 Apr 2001 16:07:29 +0200, Alex Martelli <aleaxit at yahoo.com> wrote:
>"Neelakantan Krishnaswami" <neelk at alum.mit.edu> wrote in message
>news:slrn9dpnnd.hs0.neelk at alum.mit.edu...
>> On Tue, 17 Apr 2001 00:03:38 +0200, Alex Martelli <aleaxit at yahoo.com>
>wrote:
>> >
>> > Yes, 'hygienic macros' WOULD help cut these discussions short.  Pity
>> > this benefit (basically restricted to c.l.p) would be balanced by
>> > the productivity loss engendered by the actual existence of such
>> > macros in the language -- a language which may have ANY 'syntactic
>> > feature' ensures any given program is impossible to understand
>> > unless you first study the exact set of macros used by its
>> > author:-).
>>
>> I note that precisely the same argument can be made about adding
>> functions to a language.
>
> Reality easily proves that your "note" is a falsehood: despite the
> existence of functions in Python, Usenet STILL buzzes with long
> discussions by people who whine about Python not having their
> favourite doodad.  Their existence doesn't cut these discussions
> short.  So, how can you make this statement?

Perhaps because you misunderstood what I actually wrote? That means
I've not been clear, so I'll try again. 

> If the difference in power between functions and macros is not clear
> to you, maybe a refresher in first-order versus higher- order logic
> might help.  This power applies to both discussion- cutting
> abilities and confusion-generation potential.

No, the difference between functions and macros is not at all clear.
This is because the macro systems I am used to are all Turing complete.
Likewise, having first-class functions makes the sublanguage with only
lambda and function application Turing-complete.

Specifically, consider the untyped call-by-name lambda calculus. In
this system, a function application is equivalent to rewriting all of
the bound variable references of the function with the term passed as
an argument to the function. Simple enough. Now, imagine that we add a
hygienic macro system to this language, in which we can describe a
syntactic form and what it is rewritten into.

So the order of evaluation of this language is:

1. Expand the macros, avoiding variable capture through hygiene.
2. Evaluate the function applications, avoiding variable capture
   through lexical scoping.

Now, observe that in the pure call-by-name lambda calculus, the order
of evaluation of the terms does not matter. All you have done by
introducing a macro system is to add a synonym for lambdas and
function application.

This property is called confluence, and the proof is called the
Church-Rosser theorem. I'm sure you know this, of course, but
somewhere out there there's a college student out there who is
being shocked that CS is actually turning out to be relevant, for
sufficiently small values of relevance. :)

This is what I mean by "precisely the same argument can be made about
adding functions to an imperative language."

If you find this unconvincing, let me point out that the precisely the
same difficulties are encountered marrying dynamic linking with either
of inline functions or macros. Furthermore, it's a very common style
in Scheme to write a higher-order function and then provide a macro as
syntactic sugar for it, relying on the compiler to eliminate the
unneccessary closure allocation.

Theory, compiler engineering, and programming practice all coincide
here; I don't know of any more convincing argument that the presence
or absence of a macro system is a matter of engineering and user
interface design, not of any fundamental semantic differences.

The engineering considerations are vitally important, of course.  I
know a number of people that won't consider moving from Lisp because
they can't meet their performance targets without the ability to
specify to the compiler the transformations needed to make the clear
and maintainable version of their program run with acceptable
speeds. The same thing is even true with C++ -- there are a lot of
people who are absolutely dependent on template metaprogramming to
enable the maintainable versions of their programs to perform
acceptably.

I'm really surprised you consider any of this controversial. 


Neel