comp.lang.ada
 help / color / mirror / Atom feed
From: dvdeug@x8b4e53cd.dhcp.okstate.edu (David Starner)
Subject: Re: Function name problem
Date: 2000/01/16
Date: 2000-01-16T00:00:00+00:00	[thread overview]
Message-ID: <85stib$a2g1@news.cis.okstate.edu> (raw)
In-Reply-To: B4A76C00.4583%Harald.Schmidt@tomcat.de

On Sun, 16 Jan 2000 12:37:21 +0100, Harald Schmidt <Harald.Schmidt@tomcat.de> wrote:
>in article 85qecu$24r$1@nnrp1.deja.com, Jeff Carter at
>jrcarter001@my-deja.com wrote on 15.01.2000 19:30:
>
>> A function declaration with the function designator (name) in quotation
>> marks (such as "=") defines an operator. The set of operator symbols is
>> fixed in Ada. While you can define operators for your types, as you did
>> with "=", you cannot create new operator symbols, as you tried to do
>> with "==". See ARM 4.5, 6.1, and 6.6.
>
>Thank you very much for this info. But can someone
>explain why this restriction exists?

Because it's a pain to implement, and it rarely improves readability.

(1) Where do you put the new operator? Any fixed place will be wrong
much of the time, and a flexible place will kill the parsing speed,
cause much pain for parser writers, and make the program hard to read.
f := a % b && c == d; could have almost any precedence, and since 
builtin precedence is already enough of a readibility problem . . .

(2) What do you gain from it? "==" is an example of why not to have it;
Writing C in Ada is a sure way to annoy and confuse anyone else reading
it. If I could use Unicode in writing programs, I can see a few places
where mathematical symbols would make nice operators, but still, 
a {dot symbol} b and a {cross symbol} b aren't superior enough to
Dot(a,b) and Cross (a, b) to make the precidence and readibility
problems worth it.

I will also note that POP-11(?) and ML allow this, but most other modern
languages found it too much trouble. (Java doens't allow operator overloading,
the Modula 3 people probably found it took too many pages in the standard, etc.)To be vague, I'd like to point out that Stroustroup had a commentary on why not
for C++ somewhere - Design and Evolution of C++, maybe?

-- 
David Starner - dstarner98@aasaa.ofe.org
If you wish to strive for peace of soul then believe; 
if you wish to be a devotee of truth, then inquire.
   -- Friedrich Nietzsche




  reply	other threads:[~2000-01-16  0:00 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-01-15  0:00 Function name problem Harald Schmidt
2000-01-15  0:00 ` Matthew Heaney
2000-01-15  0:00 ` Jeff Carter
2000-01-16  0:00   ` Harald Schmidt
2000-01-16  0:00     ` David Starner [this message]
2000-01-16  0:00       ` David A. Cobb
2000-01-16  0:00         ` David Starner
2000-01-17  0:00           ` David A. Cobb
2000-01-17  0:00             ` David Starner
2000-01-17  0:00               ` Jeff Carter
2000-01-16  0:00       ` David C. Hoos, Sr.
2000-01-16  0:00         ` David Starner
2000-01-18  0:00         ` Howard W. LUDWIG
2000-01-16  0:00     ` Matthew Heaney
2000-01-16  0:00       ` Harald Schmidt
2000-01-16  0:00         ` Gautier
2000-01-17  0:00         ` Matthew Heaney
2000-01-26  0:00       ` Florian Weimer
2000-01-15  0:00 ` Pascal Obry
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox