Metasyntax/Macros

[Donald 'Paddy' McCarthy]

A. Lloyd Flanagan wrote:
> paddy3118 at netscape.net (Paddy McCarthy) wrote in message news:<2ae25c6b.0305271100.77be6881 at posting.google.com>...
> 
>>alloydflanagan at attbi.com (A. Lloyd Flanagan) wrote in message > 
>>As for producing code that no one can read: Yes! Documentation and
>>introspection must be a part of a good Python macro system but I think
>>it is analogous to using a package. Unless you read-up about it, you
>>don't know what a package does. Python helps by having things like
>>help(). For any proposed macro solution Python would need appropriate
>>help and debugging extensions!
>>
>>Maybe the default behavior when in interactive mode could be for each
>>macro instance to have its expansion printed when it is encountered.
>>This default could be then be optionally turned off.
> 
> 
> Hmmm... interesting.  OK, I'll reserve judgement until I see something
> more concrete.  I think you're definitely approaching it with the
> right ideas.  Good luck!!

I went back to the Python Language Reference Manual, it may or may not 
be used in the current interpreter but my thoughts are along the lines of:
   * Introduce a keyword 'macro' that binds a macro definition to a name.
   * A bit like a class or function definition, after the macro 
definition is made, the interpreter is modified to expand any instances 
of the macro found in the manner specified in the macro body.
   * The macro object should have a disable method that when called will 
stop the interpreter from expanding the macro.
   * The scope of the macro definition should NOT be like that of other 
names. It should be in force until disabled, or the same name is bound 
to a different macro (whereapon that macro is enabled), or from when a 
previousely disabled macro is re-enabled.
   ^ Their should be a way to (hierarchically), group macros together so 
that they can be imported/exported/enabled/disabled as a group, or part 
of the hierarchical group.

Defining a macro:
-----------------



from __future__ import macros

macro IN_MACRO:
   ''' - Verilog like input definition
   in a,b,c   ==expands to==> a = In("a"); b = In("b"); c = In("c")
   '''
   # New syntax extension rules (productions) use equals sign.
   # whitespace on RHS of = below can be any or no white
   # -space separators found in source,
   input_stament = 'in' __name__ ( ',' __name__ )*
   # extend the predefined statements with the new input statement
   # Can also be interpreted as stating where to look for the new macro
   __statement__ = __statement__ | input_statement
   # Save some typing :-)
   i = input_statement
   # Compute the expansion (I have used := for this )
   expand := i[0] ' = In("'i[0]'")' \
     ( __newline__ i[1][j] ' = In("'i[1][j]'")' )*[ for j in len(i[1])]
   # macro definitions return their expansion
   return expand

in x, y,  zed

IN_MACRO.disable()

in s
Traceback (  File "<interactive input>", line 1
     in s
      ^
SyntaxError: invalid syntax

########################

In the scheme above, all the standard language productions would be 
available within a macro definition with the usual double underscore 
pre- and suffix, allowing them to be redifiened such as the redefinition 
of what constitutes a statement above.
The new productions capture the syntax of the macro, and the expansion 
rules show how to expand the captured syntax to a replacement that is 
re-scanned by the interpreter (for maybe other macros as well).

I added a doc string :-)

The expansion rule might be too much in the realms of pseudo-code in the 
notation given for expanding arbitrarily repeated productions. The [for 
j ...] bit being after the (... i[1][j]...

As well as __newline__, __indent__, and __dedent__ could be used to 
produce arbitrary indenting in expansions, based, of course, on the 
indentation of the original macro

I guess a macro could be setup to be recognised in an expression and 
expand to complete an expression and also have statements.

I guess macros could be grouped by allowing macros to either define a 
single macro or contain macro definitions (a statement that is just the 
name of a pre-defined macro could also add the macro to the group)

macro a:
   pass

macro b:
   pass

macro c:
   a
   b


c.disable()
# both a and b are now inactive

c.b.enable()
# equivalent to b.enable() in this case

######################

I have read Bengt's post. (thanks).
His ideas were different from mine - but it did prompt me to write 
something more.

Paddy.