[said Michael to Tucker] > [said Tucker to Rick] > > > > 1. Is it possible to generate user defined binary operators? > > > No. > > > > > 2. If not, then why not? ... > Readability is an important issue here, and implementation is another. I agree with your overall point. I do think you summarized it well as: > operator overloading lets you add > semantic content to the language without changing the syntax. But I'm not sure your other arguments are as strong. Here's how I understand things. This isn't Pronouncements From The Mount, I'm interested in corrections or other viewpoints. - - - - - Ada is designed so you can do syntax analysis of code without having to do semantic analysis. That is, we know that A := B (C, D); A := C + D; are legal syntax, without knowing exactly what A, B, C and D mean at the semantic level. However, if the user could create new infix functions, the syntax could not be analyzed separately from semantics. EG, without the semantics, we could not tell if this is legal syntax: A := C B D; The ability to divide these levels can be important if you're trying to pack a compiler onto a small machine by breaking it into separate passes. It helps a lot to simplify the job of writing any compiler. And, it's helpful for some tools that only want to consider syntax (like a syntax-aware editor). - - - - - The other technical issues seem pretty simple to solve: > Allowing arbitrary operator symbols would require the writer to > specify, somehow, what the precedence of the new operator was. They're all user-precedence, below the normal operators. >This > would, in turn, require some new syntax to specify it, If you declare a one- or two-argument function and the name is in quotes, it's an infix function. >and would also > require compilers to support arbitrarily large and complex precedence > tables. Just one more table (user-level), which would be handled much like any table of user-defined identifiers. (This may be where my inexperience in compiler design weakens my argument. I don't know how much modern compilers depend on having static tables for syntax analysis.) - - - - - So I would say we have two strong arguments. First, Tucker's point on readability, which is similar to the reasons for excluding a general macro capability. We want the code to reflect its structure, down into the level of expressions, and to disallow unreadable things like: A := B C D E F G H I J K L M N O P Q R S T; Curses := A @ ! B ## $ % C; Second, the fact that the syntax and semantic levels are held strongly apart in Ada, which makes it easier to build tools for, and easier to learn and teach. Best, Sam Mize -- Samuel Mize -- [log in to unmask] (home email) -- Team Ada Fight Spam: see http://www.cauce.org/ \\\ Smert Spamonam