Metasyntax/Macros

[Michael Glassford]

I think possibly what the OP was looking for was something like REBOL
dialects (http://rebol.com/docs/core23/rebolcore-15.html#sect9), which need
not be implemented as macros at all--certainly not in a way that has all the
drawbacks of C macros.

Mike



Terry Reedy wrote:
> "Paddy McCarthy" <paddy3118 at netscape.net> wrote in message
> news:2ae25c6b.0305151348.1ddda895 at posting.google.com...
>> "Terry Reedy" <tjreedy at udel.edu> wrote in message
> news:<iUudnYfQA-6tHV-jXTWcqw at comcast.com>...
>>> "Paddy McCarthy" <paddy3118 at netscape.net> wrote in message
>>> news:2ae25c6b.0305140003.dbd812e at posting.google.com...
>>>> I went googling for messages on Python and adding a macro facility,
>>>> but ended up with just too many hits and got lost.
>>>>
>>>> The reason I was looking was that I can get envisage an application
>>>> but seemed to remember that the addition of macros to Python got
>>>> shot down before but could not remember the reasons.
>
> Yes.
>
>>> They are all in the hits you gave up on ;-)  (Try just those in
>>> 2002.) One quick summary is that Guido wants Python code to look
>>> like Python code and be more or less universally readable by other
>>> Python programmers.  He is not going to be the one to help fork
>>> Python into separate sublanguage communities.
>
> My impression is that GvR has opposed non-ASCII/Unicode identifiers,
> and certainly non-English 'native language' keywords, both of which
> *have* been suggested as additions to standard Python, for much the
> same reason.
>
> Please remember that I am acting here as a reporter as much as a
> protagonist.  You more are less asked for reasons.
>
>> Ahh, are you saying then that with other languages that have such a
>> facility, there is a lot of support for syntax generated by sets of
>> macros?
>
> Not sure what you are asking but let me try this.  The C preprocessor
> is used for various reasons.  1) Macros enable generic functions like
> max(x,y) (x <= y? x: y).  Python functions are generic already.  2)
> They enable inline 'functions'.  This improves execution speed but
> with some readability problems (and possible bugs) when there are
> side-effects.  3) They define constants, which again is about speed,
> and thereby less a concern for Python.  4) They can be used to write
> 'C' code that look a lot like, for instance, Pascal.  I believe there
> were once programming shops that had private Pascal/C coding
> standards.  But this ghettoized programmers who worked therein.
>
> From what people have said, Lisp macros are even more powerful, for
> both use and abuse, but they are ourside my experience.
>
>>>>  module my_mod (x,y,z) ...
>>>>
>>>> and create a Python class.
>>>
>>> This shows the problem already.  'Module' is already in use to refer
>>> to modules, which are different from classes.  If a person has such
>>> a misunderstanding, what will they make of sys.modules?  -- or of
>>> the word 'module' in all current Python
>>> writings.
>
>> I guess my example was too simple.
>
> I think it was perfect.  This falls under category 4 above.
>
> ...
>> Such code may be less readable to the 'out=of-domain' Pythoneer,
>
> Python is about readability.
>
>> but *should* be more readable to the Verilog programmer,
>
> At the price of being ghettoized.  You are free to use domain-specific
> names for values, functions, and classes (user-defined types) and call
> the result Python.  You can also use (and abuse) the metaclass
> facility to do some of the things people do with sophisticated macro
> facilities (and call the result Python, though with enough 'abuse',
> one might be stretching it).  You can even take the source and rename
> the keywords and do whatever, but then maybe you should call it
> PMCPython or VeriPython and take responsibility for supporting the
> users.  (For all I know, this sort of thing has already been done.)
>
> Once a second set of keywords were allowed, there would soon be a
> hundred.  Whereas I like Python for having a set small enough that I
> can usually remember them.
>
> Terry J. Reedy