On Wed, 29 Dec 2004 11:42:00 -0600, Mike Meyer <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] 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
--
http://mail.python.org/mailman/listinfo/python-list
