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,18f7f6e041b3e0bf X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-07-29 13:39:08 PST Newsgroups: comp.lang.ada Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!bloom-beacon.mit.edu!nycmny1-snh1.gtei.net!news.gtei.net!priapus.visi.com!news-out.visi.com!hermes.visi.com!uunet!ash.uu.net!world!news From: Robert A Duff Subject: Re: Dispatching and generics - language lawyer question Sender: news@world.std.com (Mr Usenet Himself) Message-ID: Date: Mon, 29 Jul 2002 20:38:34 GMT References: NNTP-Posting-Host: shell01.theworld.com Organization: The World Public Access UNIX, Brookline, MA X-Newsreader: Gnus v5.7/Emacs 20.7 Xref: archiver1.google.com comp.lang.ada:27460 Date: 2002-07-29T20:38:34+00:00 List-Id: Hi, Ben. "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. 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