TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

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

Print Reply
Subject:
From:
Michael Feldman <[log in to unmask]>
Reply To:
Michael Feldman <[log in to unmask]>
Date:
Wed, 21 Apr 1999 17:14:11 -0400
Content-Type:
text/plain
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.:-)
>
[snip]

> Sam Mize
>
Mike

ATOM RSS1 RSS2