RFC -- HYGIENIC MACROS IN PYTHON

[Quinn Dunkan]

On Sun, 10 Feb 2002 18:03:00 GMT, Courageous <jkraska at san.rr.com> wrote:
>
>>So I wouldn't be able to do that macro expansion. This means the macro
>>processor is conceptually more complex, and therefore more difficult
>>to learn and probably has more bugs in it too.
>
>Potentially. However, hygienic macro systems are better known for
>introducing less comprehensional complexity. Likewise, it's usually

Another way of looking at the hygienic or not macro thing is:

hygienic macros prevent the programmer from doing variable capture, which
if you use it indicriminately, can cause an unholy mess, though they do so
at the cost of incresed complexity (though you are disputing this here,
I personally find it much easier to understand (or design) a non-hygienic
system) and reduced flexibility (sometimes you want variable capture).

Stated this way, it seems clear (to me at least) that a pythonic macro system
would be non-hygienic.  Consider:

private and protected object attributes prevent the programmer from modifying
object attrs in clients willy-nilly, which, if you do it indiscriminately,
can cause an unholy mess, though they do so at the cost of increased complexity
(new keywords, new access rules, etc.) and reduced flexibility (sometimes
you want to muck with private attributes).

It seems like non-hygienic macros fall in the philosophy of "trust the
programmer", which is in line with dynamic typing, signature oriented
interfaces, etc.