>>>>> "AMK" == Andrew Kuchling <akuchlin at mems-exchange.org> writes:
AMK> Paul Prescod <paulp at ActiveState.com> writes:
>> And if some smart people can use hygenic macros to make Python
>> code that is more maintainable or readable, why should they be
>> disallowed?
AMK> I'm increasingly opposed to new Python features, but I'm still
AMK> not ruling out the idea of hygenic macros. Their presence
AMK> might remove the pressure to add new features, which would mean
AMK> the language core would be that more stable. I expect it's
AMK> very difficult to provide a simple interface for them in
AMK> Python, though, because the syntax, and the resulting parse
AMK> trees, are more complicated and less regular than in Lisp;
AMK> maybe I'm just pessimistic, though.
Me, too.
There's a nice paper, "Quasiquotation in Lisp," by Alan Bawden that
says everything worth knowing about quasiquotation:
http://www.bawden.org/alan/
The paper emphasizes the synergy between S-expressions and
quasiquotation, although it sets out three goals for a successful
quasiquotation system:
"""
* Quasiquotation should enable the programmer to write down what she
wants the output to look like, modified only slightly in order to
parameterize it.
* The parameter expressions should appear inside the template, in the
position where their values will be inserted.
* The underyling data structures manipulated by quasiquotation should
be rich enough to represent recursively defined data structures such
as expressions.
"""
While I think I would like to see a good program-generating technique
for Python, I can't see how to make it work well because Python
doesn't have any data structures for representing Python programs
other than code objects and strings. Neither seems useful for
quasiquotation.
Jeremy
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4