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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,c7ea1cb7a2beb2ee X-Google-Attributes: gid103376,public From: Robert A Duff Subject: Re: Disallowing Pre-Defined Operations Date: 2000/03/17 Message-ID: #1/1 X-Deja-AN: 598858011 Sender: bobduff@world.std.com (Robert A Duff) References: <8a9eeg$qtv$1@newpoisson.nosc.mil> <8ababr$c3u$1@wanadoo.fr><8afhed$f9v$1@newpoisson.nosc.mil> <8aoifb$49f$1@newpoisson.nosc.mil> Organization: The World Public Access UNIX, Brookline, MA Newsgroups: comp.lang.ada Date: 2000-03-17T00:00:00+00:00 List-Id: claveman@fern.com (Charles H. Sampson) writes: > O. K., here's an example. It's not meant to meaningful, just to > show the problem, although I hope that the name for the integer variable > suggests how it could be used meaningfully. This example has been > tested on GNAT. The exact error messages depend on the compiler, but > both GNAT and Green Hills 1.8.9a both complain about the ambiguity. > > procedure Disallow is > > type Time_Type is new Float; > type Delta_Time_Type is new Float; > > function "-" (L, R: Time_Type) return Delta_Time_Type; > function "-" (L, R: Time_Type) return Time_Type is abstract; > > TT1, TT2 : Time_Type; > Elapsed_Seconds : Integer; > > begin > Elapsed_Seconds := Integer (TT1 - TT2); > end Disallow; The problem here, as I'm sure you understand, is the type conversion. Type conversions don't supply any useful information to resolve the inner expression. So yes, you have to add qualification in this case ("Integer(Delta_Time_Type'(TT1 - TT2))"). In *most* cases, there will be some context that helps resolve something like "TT1 - TT2", so you won't need a qualified expression. As I recall, during the Ada 9X design, abstract subprograms were originally defined to work the way you want: they would disappear entirely, and not make anything ambiguous. This was changed primarily because of implementation difficulty, and also, as I said above, it's no big deal, because ambiguities won't happen often, and when they do, you can always qualify. I don't remember what the implemention difficulty was; perhaps it was a difficulty for *existing* implementations only. So I think what you're really asking for is not a new feature, but for "abstract" to work the way you would like. That's reasonable, but IMHO not important enough to (1) change the way "abstract" works, or (2) add a new feature that is almost the same as "abstract". > Certainly the qualified expression would remove any ambiguity, but > the point of my original post was to be allowed to restrict pre-defined > operations in such a manner that there is no ambiguity to begin with. I can't get excited about these ambiguities, because they are so rare. > Again, as I said in my original post, if you use another type to > define what multiplication by a real literal means, you open yourself up > to multiplication by any value of that type, not just literals. Why is that bad? That other type represents the notion of a dimensionless quantity, so multiplication by any value of that type makes sense -- not just literals. > Fine. Then rephrase my question to being about the ability to de- > fine exactly the operations that exist for a type. Unfortunately, I > seem to be inheriting ones that I don't want. Or, you could use a private type, and lose the things you *do* want, such as literals. Or, if we were talking about integers, you would lose thing like array indexing and case statements. To me, that's the crux of the problem: Ada allows you to redefine *some* things (like "+" and "-"), but not other things, like literals and array indexing. I don't like that. > I hope that some of the above clarifies how a disallowed operation > would differ from an abstract operation. Yes, I now understand what you're asking for. > For the idea I have in mind, however ill-formed it might be, rever- > sion to the pre-defined operations would indeed be a flaw, because the > disallowed pre-defined operation would simply not exist. It seems like > one thing for an existing operation to lose its abstractness in generics > but it's quite another for a conceptually non-existent operation to come > into being. Presumably you could invent some way of defining the contract: You could define a generic formal integer type that has no "abs" or "**" operators, and then the actual would be required to have all the operators that the formal has (the actual would be *allowed* to have "abs" and/or "**", but not required). Sounds like a lot of mechanism for something that isn't even the "right" way to do this sort of thing. (I think the "right" way involves defining what the operations *are*, not defining the ones that might have been but I don't want. Ada almost gives you that with private types, but the loss of literals et al is annoying.) - Bob