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: <10922@ulysses.homer.nj.att.com> Date: 2 Dec 88 14:49:56 GMT References: <10906@ulysses.homer.nj.att.com> <24922@sri-unix.SRI.COM> 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 <24922@sri-unix.SRI.COM> trent@unix.sri.com (Ray Trent) writes: >In an article dsr@hector.UUCP (David S. Rosenblum) writes: >>domains and algebras. However, assignment is a concept that is peculiar to >>programming languages, so in a sense you're comparing apples and oranges. > >Untrue. "Let S = foo" is an idea from mathematics. But this is an aside. This is NOT assignment as we know it in programming languages. You don't later assign new values to S, there is no "storage" of foo in S, etc. Your expression is simply a use of the equality relation to state an assumption or axiom. You are guaranteed from the substitutivity of equality that ALL subsequent occurrences of S may be replaced by "foo". Substitutivity of this kind is not a property of assignment. >>And most "sensible" definitions of assignment that I know of describe >>assignment simply in terms of placing a value in a variable or memory > >Except C's definition, of course, which is that = is an operator that >returns a value and has a domain and range. Yes, assignment in C is an operator. And you've just justified further the argument that Ada's assignment is NOT an operator, since it returns no value. It's seems silly to use such high-falutin' terms as "domain" and "range" to describe assignment in C though, because due to C's weak enforcement of type constraints, assignment can operate on arbitrary unions of domains. >>meaning, but you are not able to override Ada's type checking. Thus, >>allowing overloading of assignment (or any basic operation) would seriously >>weaken Ada's strong typing features. > >I'm afraid unchecked programming already does that. If the language >designers were sooooo concerned about strong typing, why was unchecked >programming included at all? Was it perhaps because programmers know >that strong typing is a crock? I'd rather have nastiness like non-strong >typing out in the open, rather than hidden away in places where it >can't necessarily be found. (like package bodies, for example) Yes, unchecked programming is provided in the language, but its use is heavily discouraged. The semantics of unchecked programming are largely left to the discretion of the implementor, therefore making unchecked programming a highly non-portable feature of the language. And note the following (admittedly difficult-to-enforce) admonition in the LRM: "Whenever unchecked conversions are used, it is the programmer's responsibility to ensure that these conversions maintain the properties that are guaranteed by the language for objects of the target type. Programs that violate these properties by means of unchecked conversions are erroneous." (Book 13, Chapter 10.2, Verse 3). "Correct use" of Ada demands a good faith effort to construct portable programs. (Pardon the weasel wording.) If you believe strong typing to be a crock (and I'm one programmer that DOESN'T "know" that it's a crock), then why are you lamenting the unsatisfactory character of Ada's abstraction mechanisms? (Maybe you never said this; I'm getting confused as to who has argued what.) C gives you all the "abstraction" mechanisms you seem to desire--a wide open window to the implementation details of your data types. We seem to be getting away from the subject. Somebody has suggested allowing overloading of assignment in Ada. I have been arguing against this proposal from the hypothetical viewpoint of a person in charge of updating the language. Arguments about some of Ada's fundamental language philosophies seem out of place in this context. >I'm just saying it [assignment] wasn't designed right the first time. I would >argue that if assignment cannot be overloaded in any situation then >"=" should not be overloadable in any situation. In fact, I think >it's inconsistant to allow overloading of any kind if you don't allow >overloading of all kinds. This seems like an arbitrary argument. Overloading of operators (in the Ada sense) seems justifiable, since the operators aren't directly concerned with the semantics of strong typing. You can give kooky semantics to your favorite mathematical operator, but those semantics may be characteristic of an abstraction. However, overloading of Ada's basic operations does not seem justifiable, because they are intimately concerned with the implementation of strong typing. ------------------------------------------------------------------- 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 -------------------------------------------------------------------