Discussion: Introducing new operators for matrix computation

Huaiyu Zhu hzhu at localhost.localdomain
Thu Jul 13 20:31:58 EDT 2000


On Thu, 13 Jul 2000 16:35:57 -0600, Bjorn Pettersen <bjorn at 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





More information about the Python-list mailing list