Python syntax in Lisp and Scheme
amoroso at mclink.it
Mon Oct 13 14:55:39 CEST 2003
[The original followup was to comp.lang.python. But since Alex mostly
discusses Lisp features, and we probably both don't subscribe to each
other's group, I follow up to both of them]
Alex Martelli writes:
> As in, no lisper will ever admit that a currently existing feature is
> considered a misfeature?-)
Paul Graham is possibly the best known such lisper. You may check the
documents about the Arc dialect at his site.
>> What makes you think that macros have farther reaching effects in this
>> regard than functions? If I call a method and pass it a function object,
>> I also don't know what the method will do with it.
> Of course not -- but it *cannot possibly* do what Gat's example of macros,
> WITH-MAINTAINED-CONDITION, is _claimed_ to do... "reason" about the
> condition it's meant to maintain (in his example a constraint on a variable
> named temperature), about the code over which it is to be maintained
> (three functions, or macros, that start, run, and stop the reactor),
> presumably infer from that code a model of how a reactor _works_, and
> rewrite the control code accordingly to ensure the condition _is_ in fact
> being maintained. A callable passed as a parameter is _atomic_ -- you
> call it zero or more times with arguments, and/or you store it somewhere
> for later calling, *THAT'S IT*. This is _trivially simple_ to document and
> reason about, compared to something that has the potential to dissect
> and alter the code it's passed to generate completely new one, most
> particularly when there are also implicit models of the physical world being
> inferred and reasoned about. Given that I've seen nobody say, for days!,
The word "reason" looks a bit too AI-sh: macros do much more mundane
things. If I correctly understand Erann Gat's example in the nuclear
reactor context, things would work like this.
Some domain primitives--e.g. for controlling temperature,
starting/stopping the reactor, etc.--would be written by, or with the
help of, nuclear reactor experts. These primitives, typically
implemented as ordinary functions/classes, would embody a model of how
the reactor works. At this point, there's nothing different with what
would be done with other languages.
Now suppose you have a code module in which you have to "maintain" a
certain condition in the reactor. By "maintain" I mean arrange a
possibly long sequence of calls to domain primitives in such a way
that the condition is maintained (e.g. call the function that starts
the reactor with appropriate arguments, call functions for getting
temperature sensor readings with other arguments, check the
temperature readings and take appropriate decisions based on the
values, etc.). I guess this is also what would be done with other
A WITH-MAINTAINED-CONDITION macro would just provide syntactic sugar
for that possibly long statement/expression sequence for "maintaining"
the condition. That's it. It would typically accept parameters
describing the condition, and would generate the right sequence of
domain primitives with appropriate parameters.
WITH-MAINTAINED-CONDITION wouldn't have its own nuclear reactor model,
or other physical model. It would merely generate code templates,
mostly calls to ordinary functions, that the programmer would write
anyway (or put into a higher level function). Documenting such a macro
would be as easy as documenting the individual functions and/or an
equivalent function with internal calls to domain primitives.
Erann: is my understanding correct?
Alex: how would this way of using macros be dangerous?
Paolo Amoroso <amoroso at mclink.it>
More information about the Python-list