From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE,
	MSGID_SHORT autolearn=no autolearn_force=no version=3.4.4
Path: utzoo!attcan!uunet!cme-durer!leake
From: leake@cme-durer.ARPA (Stephe Leake)
Newsgroups: comp.lang.ada
Subject: Re: Collective response to := messages
Message-ID: <755@marvin.cme-durer.ARPA>
Date: 30 Nov 88 14:37:30 GMT
References: <8811282217.AA04896@ajpo.sei.cmu.edu> <24856@sri-unix.SRI.COM>
Organization: National Bureau of Standards, Gaithersburg, MD
In-reply-to: trent@unix.SRI.COM's message of 29 Nov 88 21:08:27 GMT
List-Id: <comp.lang.ada>


There seems to be a point of confusion concerning overloading of ":=".
Some people assume that the (overloaded) semantics of ":=" apply to
parameter passing. This seems to be a reasonable assumption, and I
think the current Ada parameter passing semantics are equivalent to
the current Ada assignment semantics. However, other types of
overloading (such as for "*") only apply when the overloaded symbol
appears _explicitly_; thus an argument could be made that the
overloaded ":=" should only be used for explicit assignments, not the
implicit ones in parameter passing. Personally, I think parameter
passing should be the same as assignment, but I just wanted to point
out the confusion.

In Ray Trent's discussion of the Fraction Abstract Data Type, he
implies that "*" and "/" do not reduce fractions to LCD form, but ":="
does. It seems to me, therefore, that he is talking about 2 data
types; LCD_Fractions and Fractions. This removes the need to overload
":=". "*" and "/" take either type and return Fraction. Then, since
there are two types involved, the compiler will remind maintainers to
include the explicit LCD operation;

A : LCD_Fraction;
B, C : Fraction;

A := B /C ; 	-- illegal
A := To_LCD_Fraction (B / C);	-- legal

I don't think ":=" should be overloadable just so we can hide type
conversions; this is one of the main complaints about C - one can
never be _sure_ what type something is.

The example above brings up a suggestion; type names should be
overloadable by functions, so we can define type conversion functions
that look like the type conversions available to scalar types. Ie the
function "To_LCD_Fraction" above should be named "LCD_Fraction". I
don't know which section of the LRM to refer to here; overloading
rules seem very scattered.

Ray Trent says:
	> The LRM explicitly says that intermediate
	> results need not follow the constraints of the ADT.
Where does it say this?

I second the motion for allowing:

  if A in (B | C | D | Q | Y | N) then
    ...
  end if;

(note that I added parentheses). Currently, we can get the same effect
with a subtype, but _only_ if B | C | D | Q | Y | N can be _uniquely_
described by a range constraint, which is often not the case. This is
leaning further towards defining sets in Ada, something that PASCAL
has always had. There are certainly problems with fully implementing
sets, but I think this extension is a good one.

Stephe Leake 	(301) 975-3431 		leake@cme.nbs.gov
National Institute of Standards and Technology
(formerly National Bureau of Standards)
Rm. B-124, Bldg. 220
Gaithersburg, MD  20899