RFC -- HYGIENIC MACROS IN PYTHON
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
>>>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.
>> 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:
More information about the Python-list