TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy


Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
"Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
Wed, 21 Apr 1999 15:51:02 -0500
Samuel Mize <[log in to unmask]>
<[log in to unmask]> from "Michael Feldman" at Apr 21, 99 04:09:56 pm
text/plain; charset=US-ASCII
Samuel Mize <[log in to unmask]>
text/plain (86 lines)
[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.

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

Sam Mize

Samuel Mize -- [log in to unmask] (home email) -- Team Ada
Fight Spam: see \\\ Smert Spamonam