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: <10962@ulysses.homer.nj.att.com> Date: 5 Dec 88 14:07:20 GMT References: <10959@ulysses.homer.nj.att.com> <3736@hubcap.UUCP> 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 <3736@hubcap.UUCP> billwolf@hubcap.clemson.edu writes: | | Well, you are quoted above as saying (correct me if I'm wrong...) that | Ada somehow required that a variable be defined after assignment, and | that a user-defined assignment such as the one you described could leave | a component undefined and therefore violate strong typing. Yes, that was an exaggeration that I am more than happy to retract. Replace that statement with "Ada doesn't feel like allowing a variable to have a value outside of its type after an assignment to the variable. Your example certainly didn't demonstrate any weaknesses in Ada's type checking semantics, which has been the real crux of the whole discussion. | | As far as I'm concerned, if we implemented your example as a user-defined | ADT, the only problem that could occur would be failure of the implementor | to properly respond to a request for the value of the denominator. If the | implementor handles the request properly, it wouldn't matter if there were | undefined components; the user can never access them anyway, and in general | will never know the difference. In other words, the implementor may well | view the state in which the denominator is undefined as a valid state of | the ADT. I see nothing wrong with that. | For the umpteenth time, the point of my example was to show that user-definable assignment is a means of circumventing type checking. I was not concerned with the mindset of the implementor or the user of the abstraction--we can talk all day about what an ideal safe programmer would do. If you find such a weak semantics for := acceptable, then you are certainly entitled to your opinion. I'm just suggesting that you'll probably never see such a semantics in Ada. I'm afraid I've exhausted whatever supply of insight I may have been able to offer on assignment overloading. I feel I've spent more space quoting the reference manual on language fundamentals than I have on arguing any substantive points. In short, Ada is not a language to consider using if you desire (1) condoned mechanisms for circumventing type checking, (2) parameter passing mechanisms defined in terms of assignment, as assignment is defined at the source level. ------------------------------------------------------------------- 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 -------------------------------------------------------------------