Re: User definable operators

tim@franck.Princeton.EDU (Tim Hollebeek)
20 Dec 1996 17:18:19 -0500

          From comp.compilers

Related articles
[4 earlier articles]
Re: User definable operators ddean@CS.Princeton.EDU (1996-12-15)
Re: User definable operators dennis@netcom.com (1996-12-15)
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)
[9 later articles]
| List of all articles for this month |

From: tim@franck.Princeton.EDU (Tim Hollebeek)
Newsgroups: comp.compilers
Date: 20 Dec 1996 17:18:19 -0500
Organization: Chemistry Department, Princeton University
References: 96-12-088 96-12-110
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.


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.


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 ...).


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


Tim Hollebeek |
Electron Psychologist |
Princeton University | email: tim@wfn-shop.princeton.edu
----------------------| http://wfn-shop.princeton.edu/~tim (NEW! IMPROVED!)
--


Post a followup to this message

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