Other notes

[Jp Calderone]

On Thu, 30 Dec 2004 15:16:42 -0600, Mike Meyer <mwm at mired.org> wrote:
>Jp Calderone <exarkun at divmod.com> writes:
> 
> > On Wed, 29 Dec 2004 12:38:02 -0600, Mike Meyer <mwm at mired.org> wrote:
> >>Jp Calderone <exarkun at divmod.com> writes:
> >> >   This aside, not even Python 3.0 will be flexible enough to let you define
> >> > an infix decorator.  The language developers are strongly against supporting 
> >> > macros, which is what an infix decorator would amount to.
> >> 
> >> Could you please explain how allowing new infix operators amount to
> >> supporting macros?
> >
> >   You misread - I said "what an infix decorator would amount to".  Adding 
> > new infix operators is fine and in no way equivalent to macros.
> 
> You misread, I said "allowing new infix oerpators amount to supporting
> macros?"

  Clearly neither of us is following the point of the other here.  
Let me start over.

  Defining an infix decorator means changing the language in such 
a way that one function can change the syntax rules used in the 
definition of another function.  It has nothing to do with the '@'
syntax, since:

    @x
    def y(...): ...

  is no different than:

    def y(...): ...
    y = x(y)

  If one works to define an infix operator, both should.  Otherwise, 
what is being used is not a "decorator" as it is currently defined.

  So my initial point was that If @infix("..") somehow works but 
y = infix("..")(y) does not, it is not a decorator.  If it does, 
then I believe what you have added to Python is macros.

> 
> >> >   Now, they might be convinced to add a new syntax that makes a function 
> >> > into an infix operator.  Perhaps something like this:
> >> >
> >> >     def &(..)(x, y):
> >> >         return range(x, y + 1)
> >> 
> >> And while you're at it, explain how this method of defining new infix
> >> operators differs from using decorators in such a way that it doesn't
> >> amount to supporting macros.
> >
> >   Simple.  You can't do anything except define a new infix operator with 
> > the hypothetical "def &( <operator> )" syntax.  With real macros, you can 
> > define new infix operators, along with any other syntactic construct your
> > heart desires.
> 
> You failed to answer the question. We have two proposed methods for
> adding new infix operators. One uses decorators, one uses a new magic
> syntax for infix operators. Neither allows you to do anything except
> declare new decorators. For some reason, you haven't explained yet,
              ^^^^^^^^^^
  I assume you mean "infix operators" here.  If so, this is likely 
the point on which we disagree.

  If you are suggesting adding "@infix('[punctuation]')" to the Python 
grammar, then I understand how you would see that as something 
less than macros.  This is not how I interpreted the remarks.

> you think that using decorators to declare infix operators would
> amount to macros, yet using a new syntax wouldn't. Both require
> modifying the grammer of the language accepted by the parser. How is
> it that one such modification "amounts to macros", whereas the other
> doesn't?

  Adding a new syntax for infix operator declaration is the same 
as the addition of any other syntax.  It has nothing to do with 
macros, it is just new syntax.

  Adding the ability for arbitrary functions to modify the syntax 
used to define other arbtitrary functions, what would have to 
happen for @infix('..') to work, is adding macros.

  Hope I have expressed things more clearly,

  Jp