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,c7ea1cb7a2beb2ee X-Google-Attributes: gid103376,public From: Tucker Taft Subject: Re: Disallowing Pre-Defined Operations Date: 2000/03/15 Message-ID: <38D001D7.4D6E4284@averstar.com> X-Deja-AN: 597979214 Content-Transfer-Encoding: 7bit References: <8a9eeg$qtv$1@newpoisson.nosc.mil> <8ababr$c3u$1@wanadoo.fr><8afhed$f9v$1@newpoisson.nosc.mil> <8aoifb$49f$1@newpoisson.nosc.mil> X-Accept-Language: en Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@inmet2.burl.averstar.com X-Trace: inmet2.burl.averstar.com 953156056 4214 141.199.8.164 (15 Mar 2000 21:34:16 GMT) Organization: AverStar (formerly Intermetrics) Burlington, MA USA Mime-Version: 1.0 NNTP-Posting-Date: 15 Mar 2000 21:34:16 GMT Newsgroups: comp.lang.ada Date: 2000-03-15T21:34:16+00:00 List-Id: "Charles H. Sampson" wrote: > ... > >You'll have to post the exact code if we're to understand what's going > >on there (all of the ops declared, and the supposedly ambiguous > >statement). And the error message. > > 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; > > >You should be able to do TT1 - TT2, so long as the context determines > >the type. Eg, "X := TT1 - TT2;" will work, if X is a variable of type > >Delta_Time_Type. And "Delta_Time_Type'(TT1 - TT2)" will work no matter > >what the context. > > 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. It is true that "abstract" operations are not removed from consideration by overload resolution. They are still there, but they are illegal to call. The problem you have is the explicit conversion to Integer. The operand of a conversion must be unambiguous without using any additional context. If you assigned "TT1-TT2" to an object of type Delta_Time_Type, then the compiler would resolve the call to your non-abstract operator. As you wrote it here, it is ambiguous, even though the second possible interpretation is abstract. So you are correct that "abstract" does not accomplish all that you might like, because it does not remove the operator from consideration by overloading. We considered having abstract operations completely invisible, but that was not done for some good reason that I can no longer remember ;-). > ... > I hope that some of the above clarifies how a disallowed operation > would differ from an abstract operation. As to the other two questions, > remember, my original question was whether this subject had been consid- > ered during the Ada 95 deliberations, although I obviously have an in- > choate proposal in mind if it wasn't. With that background, I think I > know what I want in answer to the other two questions. At the point of > the declaration, the operation ceases to exist. For the second ques- > tion, I see no reason why the mechanism shouldn't apply to tagged types. > (I don't have a feel for the utility of the idea in this case.) For the > third question, it seems like the usual scope rules should apply. There- > fore, using the usual mechanisms of the language, it should be possible > to add a definition later in the scope, although this wouldn't be over- > riding since there is nothing to override. We did think about this a bit in the Ada 9X process. It couldn't apply to tagged types, because operations can be reached via dispatching, so you can't remove operations upon inheritance. It could work for untagged types, but I suspect that it was a desire for consistency between tagged and untagged types that kept us from having abstract operations of an untagged type "disappear" completely. I understand your goal, and it is reasonable. The usual question is whether it is worth the cost. There are so many great ideas that are possible, but only so many can be accommodated in a single language. What you really want are a small number of very powerful and flexible concepts that allow you to solve all the interesting problems elegantly and safely. Personally, I would like a full-up "units" capability, where generally A * A => A is not defined, since that doesn't balance from a units point of view. I have some ideas how to get there, and would be interested in opinions from others. The techniques using discriminants are unsatisfactory in my view, and too "heavy." VHDL has the notion of "units" built into the language, and its approach should probably be evaluated. > ... > Charlie > -- > ****** > > For an email response, my user name is "sampson" and my host > is "spawar.navy.mil". -- -Tucker Taft stt@averstar.com http://www.averstar.com/~stt/ Technical Director, Distributed IT Solutions (www.averstar.com/tools) AverStar (formerly Intermetrics, Inc.) Burlington, MA USA