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.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,18f7f6e041b3e0bf X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-07-31 03:46:36 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news.tele.dk!small.news.tele.dk!130.133.1.3!fu-berlin.de!uni-berlin.de!dialin-145-254-034-035.arcor-ip.NET!not-for-mail From: Dmitry A.Kazakov Newsgroups: comp.lang.ada Subject: Re: Dispatching and generics - language lawyer question Date: Thu, 1 Aug 2002 00:52:33 +0200 Message-ID: References: Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: dialin-145-254-034-035.arcor-ip.net (145.254.34.35) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Trace: fu-berlin.de 1028112394 35861695 145.254.34.35 (16 [77047]) User-Agent: KNode/0.4 Xref: archiver1.google.com comp.lang.ada:27515 Date: 2002-08-01T00:52:33+02:00 List-Id: Robert A Duff wrote: > "Ben Brosgol" writes: > >> As another interesting case, suppose that you declare an integer type T >> with >> "mod" specified as abstract. If "mod" on the formal type is invoked from >> the generic body, then either the instantiation Ada.Text_IO.Integer_IO(T) >> would need to be rejected (a rather flagrant violation of the "contract >> model") or else the predefined "mod" would need to reemerge. > > Yes, that *is* an interesting case, which I hadn't thought of. > > Note that for tagged types, the generic declares whether it wants to > accept types with abstract primitive ops, so the instantiation can be > rejected without violating the contract model. It's uncomfortable that > there are misc. rules like this that distinguish tagged types from > untagged types. Could we do better if designing the language from > scratch? (I think many such rules are needed for compatibility with Ada > 83.) I'm not sure what the right answer is in this case. [away from Ada 95] There should be only tagged types and no untagged ones. Then I suppose the formal derived types will do the whole work, because the set of all available operations will be defined by the root type. All types tagged means only that T'Class exists for all but class-wide types. The tag should be kept in the instances of T'Class and class-wide pointers, but not in the values of T, so no performance hit when objects are specific. > I'm disappointed that nobody answered my previous question -- what > should the rules about predefined operators in generics be? I don't > like the current Ada rules (which require reemergence of the "wrong" > operator), but the alternatives are uncomfortable in various ways. > Christoph Grein, or anybody else want to comment? > > Here's an interesting case: a generic Sort routine, that takes "<" as a > parameter. (Or it could be called "Less_Than" -- it doesn't matter what > it's called, or whether it's an operator symbol.) The Sort routine > might require that the "<" behave in certain ways (like if A both return True, then A to specify that (other than via comments)? Is there some way to design > the language so that the generic Sort could formally require such > properties of "<"? [far away form Ada 95] You should simply have different root types. Transitive_Ordered should be a[!] root type for "all" types with transitive "<". "All" means the types you want to pass the actual parameter. Of course then the language should allow creating supertypes on-fly, because one cannot foresee all possible root types like Ada tries with its classification of formal types. Let Integer is not a descendant of Transitive_Ordered. Then one could create a "proxy" type which is simultaneously a supertype of Integer and a subtype of Transitive_Ordered. [The compiler should check that "<" be implemented.] So Integer would become a subtype Transitive_Ordered in the given context and thus could be used as an actual parameter of the generic. This of course would require MI and dynamically maintained dispatch tables. > This is similar to the Text_IO.Integer_IO example, where the code wants > to assume that "mod" behaves according to some mathematical rules. > (I'm not even sure how to state those rules precisely.) Well, this is about LSP. No one can enforce semantics of an operation. However, the difference between what we have in Ada now and what I would like to have, is that presently operations of a private formal type are matched by their profiles. This warranties absolutely nothing. With generic derived types, you would have a subtype relation which assumes a meaningfull implementation of the root type operations. -- Regards, Dmitry Kazakov www.dmitry-kazakov.de