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.7 required=5.0 tests=BAYES_00,INVALID_DATE, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 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 List-Id: 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 -------------------------------------------------------------------