Discussion: new operators for numerical computation

[John Lull]

At the dawn of the third millenium (by the common reckoning),
hzhu at localhost.localdomain (Huaiyu Zhu) wrote (with possible
deletions):

> On Thu, 20 Jul 2000 11:49:01 -0400, Paul Magwene <paul.magwene at yale.edu> wrote:
> >Konrad Hinsen wrote:

> >A(+.*)B

> There is one reason this will not be accepted eventually.  The parathesis
> suggests the possibility of a calculas of operators within them, when, in
> fact, operators are hardcoded in the C program.  John Lull had given a clear
> explanation why this is so.

I think your objection here is to the '+.*' bit, rather than the
parentheses. Correct?  Do you have the same objection to the simple
(*) ?

I really like the general form of this proposal, but am a bit troubled
by the use of parentheses.  I wish there was another character
available, such that (at some future time) this mechanism might be
extended to permit arbitrary named operators to be added -- something
like

   a :*: b

evolving to permit

   a :opName: b

where the surrounding :: flags both of these to the compiler as
operators handled in a standard way -- the first pre-defined by the
language, the second defined by either object.

Parentheses & brackets clearly can't be extended this way, since
a(opName) and b[opName] already have clear meanings to the compiler.
Braces likely would not work for a similar reason.

I don't know that : is the appropriate character to use here, nor
whether its use would cause other problems during lexical analysis.  I
think it's worth considering any characters that might be appropriate.

Somehow the :: isn't quite as satisfying or obvious in matrix
applications as () or [].  I kind of like the degree symbol someone
else proposed as the modifier.  Too bad it's not more generally
available.

In any case, we don't *need* to solve the general problem -- but it
wouldn't hurt to consider it.  If such a mechanism had been already in
Python, we probably wouldn't be having this discussion.

Regards,
John