Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!cornell!batcomputer!itsgw!steinmetz!uunet!cme!leake
From: leake@cme.nbs.gov (Stephe Leake)
Newsgroups: comp.lang.ada
Subject: Re: Collective response to := messages
Message-ID: <772@marvin.cme.nbs.gov>
Date: 7 Dec 88 16:07:42 GMT
References: <8811282217.AA04896@ajpo.sei.cmu.edu> <24856@sri-unix.SRI.COM> <755@marvin.cme-durer.ARPA> <10917@ulysses.homer.nj.att.com>
Organization: National Institute of Standards & Technology, Gaithersburg, MD
Lines: 41
In-reply-to: dsr@hector.UUCP's message of 1 Dec 88 14:54:34 GMT

In article <10917@ulysses.homer.nj.att.com> dsr@hector.UUCP (David S. Rosenblum) writes:

   As I argued in the case of assignment, overloading of type conversion is
   overloading of a basic operation, and such a facility would allow
   one to circumvent type checking.  As you suggested above, we don't want
   to turn Ada into C.

Type checking _cannot_ be circumvented by overloading of type
conversion! Consider:

type DEGREES is digits 6 range 0.0 .. 360.0;
type RADIANS is digits 6;

function DEGREES (Item : in RADIANS) return DEGREES
is
begin
	return Item * 180.0 / PI;	-- range constraint is checked!
end;

Since the underlying Ada type checking is done on the function result,
no circumvention of type checking is possible.

On the other hand, the fact that type conversion is a basic operation
is significant; allowing overloading would mean changing it to a
normal operation (is "normal" the complement of "basic"?), with
corresponding changes in visibility. As I see it, there are two gains;
first, I get to name my type conversion functions the same as the
implicit type conversions (ie DEGREES instead of TO_DEGREES).  Second,
I get to hide the implicit conversion, which is appropriate in the
case of DEGREES and RADIANS. However, Ada provides limited types for
hiding purposes, so this second point is not really valid (although a
limited type seems like a lot of effort for such a simple thing,
remember that Ada was intended for maintainers, not programmers :-).
So it probably isn't worth persuing. (Sigh - one of these days I'll
have a really good idea :-).

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