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, MSGID_SHORT,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!utgpu!watmath!clyde!att!rutgers!mailrus!uflorida!gatech!hubcap!billwolf From: billwolf@hubcap.clemson.edu (William Thomas Wolfe,2847,) Newsgroups: comp.lang.ada Subject: Re: Collective response to := messages Message-ID: <3702@hubcap.UUCP> Date: 1 Dec 88 03:09:57 GMT References: <10913@ulysses.homer.nj.att.com> Sender: news@hubcap.UUCP Reply-To: wtwolfe@hubcap.clemson.edu List-Id: >From article <10913@ulysses.homer.nj.att.com>, by dsr@hector.UUCP (David S. Rosenblum): > Alternatively, suppose ":=" overloadings are required to have an in out-mode > parameter to represent the target variable. Then it would be impossible > to assign to an undefined variable, because the variable would first be > constraint-checked when it is passed in to the assignment procedure. This is a question which applies to any assignment procedure, whether ":=" or "ASSIGN". The way I do it is to use in-out mode and implement the ADT as a pointer to a descriptor. That way, I take advantage of the fact that all pointers are automatically initialized to null, and I use the null-pointer state as the "empty" or "undefined" state of my ADT. I'd prefer that all data types were automatically initialized to "undefined", so I could save the space and time associated with the pointer, but the workaround does get the job done. >> The problems mentioned pertain specifically to this implementation >> only; if EVEN were implemented as a limited private type within an >> appropriate package, all the operations mentioned would be available >> only through the procedures/functions provided. Type conversions >> would not be legally expressible in the usual notation, most attributes >> would not be defined, etc. Ada 83 allows us to do all of these things, >> but not in the "conventional" notation. > > That's the whole point of why you don't need assignment overloading!!! > You can also do assignment with limited private types, but not in the > "conventional" notation. All you need to do is provide an "appropriate > subprogram". Yes, I've been doing exactly that for a long time now. >> Only assignment and destruction play vital roles in the evaluation of >> parameters and in the creation and destruction of variables (particularly >> with regard to block entry and exit). It is the fact that the language >> does not consider the impact of these mechanisms upon the ADT paradigm, >> mechanisms which can play havoc with our abstractions, that compels us >> to call for changes in the language with regard to the ability to >> define specific procedures for assignment and destruction which are >> taken into consideration by these mechanisms. > > We can argue about implicitly invoked destruction mechanisms some other time, > since Ada provides no such animal. And Ada's parameter passing mechanisms > are defined implicitly, beyond the reach of the programmer, as they should > be (again to enforce type checking)--they have nothing to do with assignment > at the source level. Regarding your assignment "abstraction", all I can > offer is the suggestion that reduction to LCD form is an over-specification > of what I consider to be the normal semantics of an assignment operation, > and it is better left to another procedure [...] The LCD example is not mine, and I'll leave it to the author of the example to make whatever counterpoints are appropriate. But with regard to the point concerning enforcement of type checking, I'd like to point out that the example you gave was one in which you did NOT define an ADT; all you did was define a local record type. I made the suggestion earlier that the definition of assignment, comparison, and other operators be restricted to the package specification in which the (limited) private ADT type was defined. The intent was to prohibit the implementation of an assignment operator over some limited private type declared somewhere else (e.g., TEXT_IO.FILE_TYPE). Another point: the ADT-handling package could leave the denominator as an undefined integer if it jolly well felt like it, as long as it met the requirements imposed by the package specification. I don't see how that would constitute any violation of type checking. >> It is entirely possible that given the desire of AJPO to minimize the >> extent of changes in the language, it will not be possible to get Ada >> to provide complete support for the abstract data type paradigm. Ada >> was explicitly intended as an interim solution, covering the range >> 1983..20xx, and not as "the perfect language". Perhaps for Ada it is >> already too late. But the issue needs to be thoroughly discussed, >> because it is a major area in which Ada has "missed the boat". > > I tend to agree with your last comment. But Ada's abstraction mechanisms > will never be improved in the next revision without a proposal that is > carefully thought out and is fully consistent with the goals of the > language. As I've tried to illustrate, none of the proposals I've seen > for assignment overloading come close to meeting these criteria. I think providing complete support for the abstract data type paradigm is fully consistent with the goals of the language; as for carefully thought out proposals, a major purpose of this discussion is to uncover bugs in the details of the proposal prior to filing the 9X revision forms (which were made available by AJPO at Tri-Ada '88). The points that have been made by you and others have done that. Whether the finalized request will be within AJPO's tolerance for change is, of course, still very much an open question. But in this language or the next, the abstraction mechanisms available to programmers will be significantly stronger as a result. Bill Wolfe wtwolfe@hubcap.clemson.edu