TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy


Options: Use Classic View

Use Proportional Font
Show HTML Part by Default
Condense Mail Headers

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

Print Reply
Sender: "Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
Date: Wed, 21 Apr 1999 17:14:11 -0400
Reply-To: Michael Feldman <[log in to unmask]>
From: Michael Feldman <[log in to unmask]>
Content-Transfer-Encoding: 7bit
In-Reply-To: <[log in to unmask]> from "Samuel Mize" at Apr 21, 1999 03:51:02 PM
Content-Type: text/plain; charset=us-ascii
MIME-Version: 1.0
Parts/Attachments: text/plain (47 lines)
[said Sam to Mike to Tucker to Rick]

> The other technical issues seem pretty simple to solve:

Sure, if you write the rules to allow only simple cases.
I'm going to play devil's advocate with you here. (Hey,
I'm a prof, that's my job!:-))
> > 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.

Which means they are all equal precedence? That's very restrictive -
why can;t I write A # B % C and specify that it means A # (B % C),
that is, % takes precedence over #?
> >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.

Sure, fine as far as you go. But after all, if C can have ternary
operators, why not Ada? If I can write X ? Y : Z in C and have
? and : be part of the same operator, and you won;t let me do it
in Ada, forget Ada!
> >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.)

But your extensions are so minimal that they wouldn;t make much
difference in the real extensibility of the language, and we'd
pay a price in readability. Insufficiently high payoff for the effort.:-)

> Sam Mize