do...until wisdom needed...

[Jeremy Hylton]

>>>>> "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