Path: utzoo!utgpu!watmath!clyde!att!ulysses!hector!dsr
From: dsr@hector.UUCP (David S. Rosenblum)
Newsgroups: comp.lang.ada
Subject: Re: Collective response to := messages
Message-ID: <10917@ulysses.homer.nj.att.com>
Date: 1 Dec 88 14:54:34 GMT
References: <8811282217.AA04896@ajpo.sei.cmu.edu> <24856@sri-unix.SRI.COM> <755@marvin.cme-durer.ARPA>
Sender: netnews@ulysses.homer.nj.att.com
Reply-To: dsr@hector.UUCP (David S. Rosenblum)
Organization: AT&T Bell Laboratories, Murray Hill, NJ
Lines: 52

In article <755@marvin.cme-durer.ARPA> leake@cme-durer.ARPA (Stephe Leake) writes:
>
>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.

They are not the least bit equivalent, for several reasons.  The most
obvious reason is that an implementation is free to pass composite
parameters by reference, although no implementation can "assign by
reference".  No source-level assignment operation is "invoked" to achieve
parameter passing.  Parameter passing is a language facility that is
implemented by the compiler, just as is, say, looping.

>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.

I personally believe such an interpretation of parameter passing creates
more confusion instead of less.  In essence, this interpretation adds yet
another special case to the scope and visibility rules--it allows a
subprogram call to "see past" a visible redefinition of assignment to
a predefined one that has been hidden.

>A : LCD_Fraction;
>B, C : Fraction;
>
>A := B /C ; 	-- illegal
>A := To_LCD_Fraction (B / C);	-- legal
>
>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.

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.


-------------------------------------------------------------------
David Rosenblum			UUCP: {ucbvax, decvax}!ulysses!dsr
AT&T Bell Laboratories		ARPA: dsr@ulysses.att.com
600 Mountain Ave.		      dsr%ulysses@att.arpa
Murray Hill, NJ 07974-2070
(201) 582-2906
-------------------------------------------------------------------