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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,4c86cf2332cbe682 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1995-01-24 11:37:38 PST Newsgroups: comp.lang.ada Path: pad-thai.cam.ov.com!noc.near.net!inmet!henning!stt From: stt@henning.camb.inmet.com (Tucker Taft) Subject: Re: Ada.strings.bounded problems? Message-ID: Sender: news@inmet.camb.inmet.com Organization: Intermetrics, Inc. References: <3fomrv$7i9@disunms.epfl.ch> <3frlfa$rp2@gnat.cs.nyu.edu> <1995Jan23.135503@lglsun.epfl.ch> Date: Tue, 24 Jan 1995 19:24:18 GMT Date: 1995-01-24T19:24:18+00:00 List-Id: In article <1995Jan23.135503@lglsun.epfl.ch>, Robb Nebbe wrote: >... Clearly the semantics as they are defined, which allow the >reemergence of predefined equality, are not desirable ... Actually, the Ada 9X design team proposed in 1991 or thereabouts that predefined operators would never "reemerge" in generics or composite operations. However, at least at the time, there were those who defended the Ada 83 behavior as *desirable*, mostly based on examples where a generic which presumed predefined semantics for an operator could become quite confused if the operators did not satisfy various presumed invariants. For example, one might presume that X < Y implied not X >= Y. However, one could imagine an overriding of the predefined operators such that there were "incomparable" values, and both X < Y and X >= Y would return False. At the time, the example that was mentioned several times was an overriding of user-defined operators to create modular arithmetic. It was easy to construct generics which could get pretty confused because they presumed normal non-modular invariants such as A > 0 implies A + B > B. Text_IO.Integer_IO was one possible example of this. Although we (the design team) argued for no reemergence at the time, we ultimately reached the conclusion that, for untagged types, predefined operators should continue to reemerge, as they did in Ada 83. I suppose upward compatibility was the strongest argument, though the argument about desirability and simplicity of semantics for generics was considered as well. Fully general support for user-defined "=" came somewhat later during the Ada 9X design process, but in any case the goal was to treat "=" *more* like other operators, rather than *less*. Having decided to retain predefined operator reemergence for scalar types, we were reluctant to make a special case for the equality operator on untagged record types. The same thing applied to untagged derived types. Basically, we decided that tagged types would be used for "fully" abstract types, since only on such types could you handle levels of indirection, etc., where a user-defined equality was clearly important. In other words, we decided to keep uniformity across all untagged types, and across all tagged types, but sacrifice some uniformity between tagged and untagged types. The general "philosophical" difference between tagged types and untagged types is that untagged types are simpler and leaner and better for relatively "concrete" types, whereas tagged types are a bit more expensive but more flexible and better for more "abstract" types. For derived types, untagged derived types are presumed to be types that are essentially identical internally, but with a strong type distinction created between them to help support compile-time checking of one sort or another (such as two integer types where one counts apples and the other oranges). Tagged derived types (i.e. type extensions), on the other hand, are potentially completely different internally from their parent type, and it is intentionally possible to *avoid* strong compile-time type distinctions between them by using a class-wide type, which makes sense when the differences are merely implementation differences, rather than significant interface differences. Or in short, untagged derived types can be used to create arbitrary interface differences on top of identical implementations, whereas tagged type extensions can be used to preserve a common interface across significantly different implementations. >Maybe the cost of not providing consistant semantics between tagged >and untagged record types will exceed the cost of introducing an >upward incompatability, maybe not. ... There was also the issue of consistency between untagged record types and untagged non-record types. As mentioned above, we chose to make the "break" between tagged and untagged. One could instead have made the break between records and non-records, but we felt that was not as natural a breaking point, particularly since in Ada 83, one could implement a given private type with a record or a non-record without any signicant effect on the clients. > ... It is a really tough call right >now. Especially since there really isn't any data, just speculation, >to base the decision on. It is always painful to break consistency. Clearly the issue of reemergence of predefined operators will continue to reemerge over time ;-). >Robb Nebbe -Tucker Taft stt@inmet.com Ada 9X Mapping/Revision Team Intermetrics, Inc.