Other notes

[Bengt Richter]

On Wed, 29 Dec 2004 11:42:00 -0600, Mike Meyer <mwm at mired.org> wrote:

>bearophileHUGS at lycos.com writes:
>
>> @infix
>> def interval(x, y): return range(x, y+1) # 2 parameters needed
>>
>> This may allow:
>> assert 5 interval 9 == interval(5,9)
>
>I don't like the idea of turning words into operators. I'd much rather
>see something like:
>
>@infix('..')
>def interval(x, y):
>    return range(x, y + 1)
>
>assert 5 .. 9 == interval(5, 10)
>
I like that for punctuation-character names.

OTOH, there is precedent in e.g. fortran (IIRC) for named operators of the
form .XX. -- e.g., .GE. for >= so maybe there could be room for both.

A capitalization _convention_ would make such infix operators pretty readable
even if the names were'nt always the best, e.g.,

    for x in 5 .UP_TO_AND_INCLUDING. 9:
        ...

Hm, you could make

     x .infix. y

syntactic sugar in general (almost like a macro) for

     infix(x, y)

and you could generalize that to permit .expression. with no embedded spaces, e.g.,

     x .my_infix_module.infix. y
for
     my_infix_module.infix(x, y)

or to illustrate expression generality ridiculously,

     a = x .my_infix_module.tricky_func_factory_dict[random.choice(range(4))](time.time()). y

for
     a = my_infix_module.tricky_func_factory_dict[random.choice(range(4))](time.time())(x, y)

<aside>
I wonder if it's a good idea to post ridiculous but functionally illustrative uses
of possibly good ideas, or if the net effect detracts from the reception of the ideas.
Also verbiage like this ;-/
</aside>

If '..' were special-cased as a synonym for __nullname__ you could handle it
by def __nullname__(x, y): whatever, but since it's punctuation-only, your @infix('..')
seem preferable.

Hm, ... if single (to exlude .infix.) missing dotted names defaulted to __nullname__,
I wonder what that would open up ;-)  obj. would be obj.__nullname__, which could be
defined as a concise way of referring to the one special attribute or property.
And .name would be __nullname__.name -- which with the approriate descriptor definition
in the function class could make .name syntactic sugar for self.name (or whatever the first arg
name was).  ... just musing ;-)

>This would also allow us to start working on doing away with the magic
>method names for current operators, which I think would be an
>improvement.
>
>As others have pointed out, you do need to do something about operator
>precedence. For existing operators, that's easy - they keep their
>precedence. For new operators, it's harder.
>
>You also need to worry about binding order. At the very least, you
>can specify that all new operators bind left to right. But that might
>not be what you want.
Yes. My .expression. infix if implemented essentially as a left-right
rewrite-as-soon-as-you-recognize macro would create the precedence rules
of the macro-rewritten source. Which might cover a fair amount of useful
ground. Needs to be explored though. E.g.,

  x .op1. y .op2. z => op2(op1(x, y), z)

But you could override with parens in the ordinary way:

  x .op1. (y .op2. z) => op1(x, op2(y, z))

But
  2 * x + 3 .op1. y => 2 * x + op1(3, y)

Etc. Well, something to think about ;-)


Regards,
Bengt Richter