[Python-3000] Proposal: Metasyntax operator
Phillip J. Eby
pje at telecommunity.com
Thu Jul 20 18:10:07 CEST 2006
At 01:58 AM 7/20/2006 -0700, Talin <talin at acm.org> wrote:
>I'd like to propose a standard way to represent one of these syntactical
>variables. The syntax I would like to see is '?x' - i.e. a question mark
>followed by the variable name.
>
>The reason for choosing the question mark is that this is exactly how
>many languages - including expert systems and inference engines -
>represent a substitution variable. The other reason, which was only of
>minor consideration, is that the '?' is one of the few symbols in Python
>whose meaning is not already assigned.
>
>The actual meaning of ? would is very simple:
>
> '?x' is equivalent to '__quote__("x")'
>
>Where __quote__ is a user-defined symbol accessible from the current scope.
I'd like to just point out that having a syntax for AST literals, i.e.,
simply having something like `foo+bar*23` result in an AST, gives you a
better result in several ways:
1. No ugly symbols next to every name
2. "and", "or", "if", "for", "yield", and even lambda expressions can be
used without further chicanery
3. The AST can be constructed at compilation time
If we were going to have ?x mean something special, I'd want it to instead
be a *reverse* syntactic operation. For example, if backquotes denoted an
AST literal (and I know Guido's not going to allow that, but it's
convenient for an example), then ? would be an escape to reference a
*non-AST* expression to be inserted. E.g.::
`x + ?y`
Would mean "take the runtime value of Y and insert it as a child node of
the AST at the position shown".
Of course, for this to work you'd have to come up with a better AST literal
syntax than backquotes. About the only thing that comes to mind at the
moment is using the backslash, followed by an atom. So "\x" would be an
AST literal for the symbol "x", and "\(x+y)" would be an AST literal for x+y.
I seem to recall that at one time Guido suggested that this type of thing
should just use strings, however, and I don't know if that's still his
position.
More information about the Python-3000
mailing list