RFC -- HYGIENIC MACROS IN PYTHON

phil hunt philh at comuno.freeserve.co.uk
Sat Feb 9 19:26:54 EST 2002


On Fri, 08 Feb 2002 17:09:51 GMT, Courageous <jkraska at san.rr.com> wrote:
>On Fri, 8 Feb 2002 13:18:22 +0000, philh at comuno.freeserve.co.uk (phil hunt) wrote:
>
>>On Fri, 08 Feb 2002 01:42:51 GMT, Courageous <jkraska at san.rr.com> wrote:
>>>
>>>>It's just that being forced -- "for my own good" -- not to use certain
>>>>features because someone has decreed them intrinsically bad, doesn't
>>>>appeal to me at all.
>>>
>>>Sure. You realize that a hygienic macro doesn't prevent you from
>>>modifying things by consequence, right? All it does is require for
>>>you to mean it; this caters to Python's phenonomenon of least
>>>surprise. Imagine the following
>>>
>>>>>> i = 3
>>>>>> j = 4
>>>>>> mymacro i
>>>>>> print j
>>>5
>>>
>>>That would vex some folks.
>>
>>It would vex me in someone else's code unless there was a good reason for
>>it and it was well documented.
>>
>>> But that's exactly what a non hygienic
>>>macro can do.
>>
>>And it's exactly the behaviour I want a macro to be able to do.
>
>>defmacro incj:
>>   j = j + 1
>
>>In a non-hygenic macro system it is easy to see what underlying Python
>>code gets produced. In your system it isn't -- 
>
>Perhaps only because it hasn't been explained well enough. The only
>way the above macro definition could work without issuing an exception
>is if j already exists in the global namespace. Using current python
>forms, it would simply fail.

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.


-- 
===== Philip Hunt ===== philh at comuno.freeserve.co.uk =====
Herbivore, a zero-effort email encryption system. Details at:
<http://www.vision25.demon.co.uk/oss/herbivore/intro.html>






More information about the Python-list mailing list