24 Dec 1996 22:12:17 -0500

Related articles |
---|

[6 earlier articles] |

Re: User definable operators fjh@mundook.cs.mu.OZ.AU (1996-12-15) |

Re: User definable operators burley@gnu.ai.mit.edu (Craig Burley) (1996-12-18) |

Re: User definable operators jdean@puma.pa.dec.com (1996-12-18) |

Re: User definable operators neitzel@gaertner.de (1996-12-18) |

Re: User definable operators tim@franck.Princeton.EDU (1996-12-20) |

Re: User definable operators nkramer@cs.cmu.edu (Nick Kramer) (1996-12-20) |

Re: User definable operators hrubin@stat.purdue.edu (1996-12-24) |

Re: User definable operators preston@tera.com (1996-12-26) |

Re: User definable operators burley@gnu.ai.mit.edu (Craig Burley) (1996-12-26) |

Re: User definable operators mfinney@inmind.com (1996-12-26) |

Re: User definable operators leichter@smarts.com (Jerry Leichter) (1996-12-27) |

Re: User definable operators genew@mindlink.bc.ca (1996-12-28) |

Re: User definable operators WStreett@shell.monmouth.com (1996-12-29) |

[7 later articles] |

From: | hrubin@stat.purdue.edu (Herman Rubin) |

Newsgroups: | comp.compilers |

Date: | 24 Dec 1996 22:12:17 -0500 |

Organization: | Purdue University Statistics Department |

References: | 96-12-088 96-12-110 96-12-147 |

Keywords: | design |

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

--

Post a followup to this message

Return to the
comp.compilers page.

Search the
comp.compilers archives again.