Metasyntax/Macros

[Paddy McCarthy]

bokr at oz.net (Bengt Richter) wrote in message news:<bb0pqu$2qq$0 at 216.39.172.122>...
> On 27 May 2003 12:00:24 -0700, paddy3118 at netscape.net (Paddy McCarthy) wrote:
> 
> >alloydflanagan at attbi.com (A. Lloyd Flanagan) wrote in message news:<a8b7f07a.0305141356.344f0e69 at posting.google.com>...
> >> paddy3118 at netscape.net (Paddy McCarthy) wrote in message news:<2ae25c6b.0305140003.dbd812e at posting.google.com>...
> >> <excerpt>
> >> > and create a Python class. By choosing a careful set of macros the
> >> > resultant {ython-with-macros source could be understandable to people
> >> > with only the domain specific language knowledge,
> >> > 
> >> </expert>
> >> 
> >> And only those people.  The trouble with macros in general, and C
> >> macros in particular, is that they can be used to mangle the language
> >> into almost any form the macro-writer wants.  The result is something
> >> that does not make sense to any other person on the planet.
> >> 
> >> IMHO, we already have plenty of languages that are ideal for writing
> >> unreadable code.  Let's not turn Python into one of them.
> >> 
> >> If you want a language with a powerful designed-in macro facility,
> >> check out Lisp.
> >
> >But that *is* the point. I don't want a Lisp or a C or a Rebol macro
> >facility.
> >I just have not closed my mind to the thought of macros within Python.
> >I just haven't thought of a pythonic way of doing it.
> >
> >Any implimentation I guess would have to include modification and
> >introspection of the parser so something like help(__statements__) and
> >help(__operators__) would print the docstrings of statements together
> >with details on how the statement is parsed, or the associativity etc
> >of operators (including the built-in ones).
> >
> >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.
> 
> It just occurred to me that the tokenizer separates out string tokens
> before anything is compiled, so if there were a special kind of string
> syntax like raw string syntax but with, say, '$' as a prefix instead of
> 'r', then that string could be treated specially at tokenization time.
> 
<<SNIP>>
> Just HOTTOMH, so fire away ;-)
> 
> Regards,
> Bengt Richter

Hi Bengt,
Read your email, and can see that you've carefully thought about some
implimentation issues too.
With you syntax of recognising macros by a $'...' construct I wonder
if you could get a lot of your functionality by adapting one of the
many HTML templating systems so that instead of outputting HTML that
is sent to a browser, the output is python sent to the python
interpreter.
I think Alex has a cookbook entry for templating that has variable
macro recognisers that could probably be adapted.
The only thing is, I don't think this solution provides enough of
Python like documentation and modularisation of macros.
But please, this is just my opinion, and I don't mean to offend, just
air my views.

Thanks for your Idea,  Paddy.