20 Dec 1996 17:18:19 -0500

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] |

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.