[Python-Dev] Re: [Fwd: Discussion: Introducing new operators formatrix computation]

[Huaiyu Zhu]

On Fri, 14 Jul 2000, Eric S. Raymond wrote:

> Huaiyu Zhu <huaiyu_zhu@yahoo.com>:
> > This is not a call for a special language for matrix only.  But we do need
> > enough binary operators to override with.  The additional operators
> > might be useful at other places as well.
> > 
> > In matlab the following operations are all different from each other
> > 
> > a+b        a.+b  
> > a-b        a.-b
> > a*b        a.*b
> > a/b        a./b
> > a\b        a.\b
> > a^b        a.^b
> > 
> > What python operators can we override for them all? Just one additional
> > symbol for so many new binary operators is a good bargain, IMO.
> 
> Put this way, I'm more inclined to support it.  I might even be tempted
> to add .| and .& for lattice algebras.  
>
> I agree that supporting user-defined syntax threatens to fragment the
> language.  To avoid that, perhaps it would be best to leave what are in
> effect user-definable hooks in Python's lexical space.
 
Completely agree.  That's what the issue is about.  More information is
given below in my quote from c.l.p.

> This could address Greg's desire for an infix max and min as well.
> 
> The design question becomes: what undefined binary tokens do we
> want to add the the language core?  With what precedence?  What is
> the compiler to assume about associativity?

Given what's quoted below, would you think . is the best choice?  Not to say
its attractiveness to all the matlab crowd.

------------------------ start quote -----------------------------

On Thu, 13 Jul 2000 16:35:57 -0600, Bjorn Pettersen <bjorn@roguewave.com>
wrote: 

>I fully understand your desire to make the syntax for your domain
>specific notation as intuitive as possible.  For people who don't know
>matlab however, .+ et. al. have no pre-defined meaning. Since + has a
>predefined meaning of addition, most people when overloading it will do
>"additive" things with it, e.g. concatenating to sequences. Since .+
>doesn't have a pre-defined meaning I'm afraid people will override it
>with random semantics...
>
>If you want to do matlab syntax, perhaps a better approach would be to
>write your own expression parser?
>

Hmm, I see what you mean:  If a certain syntax is not meaningful to all the
users, don't expose it to all of them lest they came up with random
incompatible usages.  Sounds reasonable, but ...

Point 1.  We _can_ assign a universal meaning to dot operators, as
"componentwise operators".  For example

[1, 2] + [3, 4]             # [1, 2, 3, 4]
[1, 2] .+ [3, 4]            # [4, 6]
['a','b'] * 2               # ['a','b','a','b']
["a","b"] .* 2              # ['aa', 'bb']
{'a':1, 'b':1} .+ {'a':1, 'c':1}   # {'a':2, 'b':1, 'c': 1}
'abc' .+ 'def'              # exception: you must define string.__dot_add__

This could be useful in all sorts of situations.  Of course people can still
override it with incompatible meanings at their own discretion, just as they
could do to anything else.


Point 2. If users in completely disjoint domains override a certain type of
binary operators with incompatible meanings, is there great harm?  Providing
a few operators for user adoptation might even prevent grotesque overriding
of more core operators.  After all, there is almost endless supply of names
for classes, modules, function and so on, but there is almost no binary
operators free for adoption.


Point 3. A special parser could work, (and if the patch under discussion is
not accepted we'll just keep it around for use with matrix computation), as
long as it is made quite orthogonal to other parts of the language.  This
way people using it will not be left behind other developments of the
language.  However, I still think a unified parser with overridable
operators present a smaller risk of fragmentation.

Huaiyu