Other notes

[Steve Holden]

Bengt Richter wrote:

> On Wed, 29 Dec 2004 13:11:43 -0500, Steve Holden <steve at holdenweb.com> wrote:
> 
[...]
>>
>>Well, perhaps you can explain how a change that's made at run time 
>>(calling the decorator) can affect the parser's compile time behavior, 
>>then. At the moment, IIRC, the only way Python code can affect the 
>>parser's behavior is in the __future__ module, which must be imported at 
>>the very head of a module.
> 
> Good point, which I didn't address in my reply. (in fact I said I liked
> @infix('..') for punctuation-char-named ops, but I was too busy with my
> idea to think about that implementation ;-)
> 
Well, that explains the lack of detail. I realize that you are more 
likely than most to be able to come up with an implementation.

> Potentially, you could do it dynamically with a frame flag (to limit the damage)
> which said, check all ops against a dict of overloads and infix definitions while
> executing byte code for this frame. Of course, the compiler would have to defer
> some kinds of syntax error 'til run time. I.e., '..' would have to be translated
> to OP_POSSIBLE_CUSTOM_INFIX or such. I doubt if it would be worth doing.
> 
Right. I can't say I think deferring syntax errors until runtime is a 
good idea.

> OTOH, I think my suggestion might be ;-) I.e., just do a macro-like (not a general
> macro capability for this!!) translation of expressions with dots at both ends and
> no embedded spaces (intial thought, to make things easier) thus:
>     x .expr. y =>  expr(x, y)
> 
> when expr is a simple name, you can use that expression format to call a two-arg function
> of that name, e.g.,
> 
>     def interval(x, y): return xrange(x, y+1)
>     for i in x .interval. y: print i,  # same as for i in interval(x, y): print i,
> 
> but you could also write stuff like
> 
>     def GE(x,y): return x is MY_INFINITY or x >= y
>     if x .GE. y: print 'x is greater than y'
> 
> The .expr. as expression would allow module references or tapping into general
> expression and attribute magic etc. I.e., (untested)
> 
>    from itertools import chain as CHAIN
>    for k,v in d1.items() .CHAIN. d2.items(): print k, v
> 
> or if you had itertools imported and liked verbose infix spelling:
> 
>    for k,v in d1.items() .itertools.chain. d2.items(): print k, v
> 
> or define a hidden-attribute access operation using an object's dict
> 
>    def HATTR(obj, i):
>        try: return vars(obj)[i]
>        except KeyError: raise AttributeError('No such attribute: %r', i)
> 
>    if thing .HATTR. 2 == 'two': print 'well spelled'
> 
> or
>    from rational import rat as RAT
> 
>    if x .RAT. y > 1 .RAT. 3: do_it()
> 
> or
>    your turn ;-)
> 
Well, I can see that Fortran programmers might appreciate it :-). And I 
suppose that the syntax is at least regular enough to be lexed with the 
current framework, give or take. It would lead to potential breakage due 
to the syntactic ambiguity between

	module .function. attribute

and

	module.function.attribute

though I don't honestly think that most people currently insert 
gratuitous spaces into attribute references.

> 
[precedence and associativity]
> 
> My suggestion if implemented with left-right priority would be easy to
> implement (I think ;-) And you could always override order with parens.

Now you're just trying to make it easy :-)

regards
  Steve
-- 
Steve Holden               http://www.holdenweb.com/
Python Web Programming  http://pydish.holdenweb.com/
Holden Web LLC      +1 703 861 4237  +1 800 494 3119