Operators for everything (was Re: Operators for matrix)

[Michael Hudson]

digitig at cix.co.uk (Tim Rowe) writes:

> In article <m3em4ld5t3.fsf at atrus.jesus.cam.ac.uk>, mwh21 at cam.ac.uk 
> (Michael Hudson) wrote:
> 
> > Sorry, but eh?  I fail to understand you, I think.
> > 
> > Example usage of what I'm talking about:
> > 
> > def add(x,y):
> >     return x + y
> > 
> > 1 @add 1
> >   ==> 2
> 
> My problem is that identifiers that refer to overloaded infix operators 
> must begin with a @ (and presumably any identifier beginning with @ must 
> be an overloaded infix operator). Hey, why not force integers to begin 
> with a %, strings with a $...
> 
> I don't like it because it makes programs harder to read. One of the 
> reasons I don't like Perl is that it tends to look as if the whole program 
> is obscene and has been censored with $@**!& special symbols! One of the 
> advantages of Python is that there is little of this nonsense, and I would 
> hate to see it added to. I don't think extensible infix is worth it.

Oh, fair enough.  That's not what I read in your first post, though!
(I just re-read it, and it still makes very little sense to me...)

> By the way, /I'd/ expect x add y to set x to x + y, leave y alone and 
> return None (or x + y if this were comp.lang.c). I'd expect x plus y to 
> have the behaviour you expect of add. I'm undecided whether that's a 
> problem with infix or the perennial problem of choosing good identifiers!

Crikey, are you an assembly programmer?  I took the name from the
__add__ special method name... (to me, plus is the symbol, addition is
the operation; would you prefer __star__ to __mul__).

pointless-ly y'rs
M.

-- 
  Arrrrgh, the braindamage!  It's not unlike the massively
  non-brilliant decision to use the period in abbreviations 
  as well as a sentence terminator.  Had these people no 
  imagination at _all_?                 -- Erik Naggum, comp.lang.lisp