Re: User definable operators

  William Clodius <wclodius@lanl.gov> wrote:
>>Many programming languages allow the user to overload of language
>>defined operators. But a few languages also allow the user to define
>>their own operators. I would like to have some feedback on the
>>experience of others with user definable operators with respect to
>>specifying their syntax, associativity, precedence, semantics (e.g.,
>>side effects or not), etc.


Charles Fiterman <cef@geodesic.com> writes:
> Further, it's important to allow new operators. There are dot products
> and cross products and we need symbols for both. Having something like
> unicode as the symbolic base is ideal because computer math can look
> like published math. Very brilliant people have worked on mathematical
> symbolism for centuries and produced a highly readable
> result. Throwing it away on abominations like sqrt for the radical
> sign is pure evil.


Tim Hollebeek <tim@wfn-shop.Princeton.EDU> wrote:
>On the other hand, mathematical notation is typically highly ambiguous
>as written; the "obvious" meaning is chosen based on context. For
>example, "f(a+b)" means either f evaluated at a + b, or f times a + b,
>depending whether f is a function or not. If you consider that
>functions can really be expressions too (like (f \compose g)(a + b))
>things get worse. Mathematica uses [] for functions for this very
>reason.


This particular ambiguity is typically blocked in most computer
languages anyhow. In any of them, using xy for the product of x and y
is prohibited, and I know of none for which even 2x is allowed.


Leaving out the operator for multiplication, or for & as a logical
operator, is typically banned. Even Polish and reverse Polish
notation needs an end of symbol "operator".


>In fact, Mathematica's syntax is a good place to look for trouble
>spots in computer usage of contemporary math symbolism. The
>distinction between f[x] and f[x_] is another example (though in that
>case it it really due to the fact that conventional notation doesn't
>distinguish dummy variables from values as well as it should. Ideally
>everyone would start using the notation f(.) = 3(.) + 2, but then we
>need a standard way of distinguishing multiple dummy variables ...).


I agree with this, but outside of the lambda-calculus and programming
languages using it, I know of none. So what we need is more
versatility, not less.


And of course C uses parentheses for making a single entity, and []
for a particular type of function, namely array element, and it only
allows this for one-dimensional arrays.


>Mathematical symbolism has as many nasty historical features as most
>old software programs, unfortunately.


But mathematics has never refuse to allow new operators, or new
notation. It sometimes has been slow to adopt them.


One would think that language designers would have learned from this,
and gone in the direction of greater versatility, not less. Of
course, it is necessary to have a lot more characters than the 95,
including space, allowed by ASCII.


Notation has to be overloaded to be of reasonable length. By the time
one reads the lengthy variable names which seem to delight the
computer people, the structure of the expression is lost. It is
necessary to let the user invent notation, if necessary, and for the
language and compiler to help, not hinder.




--
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
hrubin@stat.purdue.edu Phone: (317)494-6054 FAX: (317)494-0558
--

Return to the comp.compilers page.
Search the comp.compilers archives again.