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.5 required=5.0 tests=BAYES_00,INVALID_MSGID, PP_MIME_FAKE_ASCII_TEXT autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII X-Google-Thread: 103376,c7ea1cb7a2beb2ee X-Google-Attributes: gid103376,public From: claveman@fern.com Subject: Re: Disallowing Pre-Defined Operations Date: 2000/03/12 Message-ID: <8afhed$f9v$1@newpoisson.nosc.mil>#1/1 X-Deja-AN: 596358276 Distribution: world References: <8a9eeg$qtv$1@newpoisson.nosc.mil> <8ababr$c3u$1@wanadoo.fr> X-Complaints-To: usenet@newpoisson.nosc.mil X-Trace: newpoisson.nosc.mil 952846605 15679 128.49.4.5 (12 Mar 2000 07:36:45 GMT) Organization: Computer Sciences Corporation NNTP-Posting-Date: 12 Mar 2000 07:36:45 GMT Newsgroups: comp.lang.ada Date: 2000-03-12T07:36:45+00:00 List-Id: In article <8ababr$c3u$1@wanadoo.fr>, Jean-Pierre Rosen wrote: > >Charles H. Sampson a �crit dans le message : >8a9eeg$qtv$1@newpoisson.nosc.mil... >> During the deliberations that led to Ada 95, was a mechanism for >> disallowing the pre-defined operations of a type considered? By "disal- >> lowing" I mean some way of informing the compiler that an attempt to use >> a certain pre-defined operation is a compile-time error. Did anyone >> even ask for it? (Obviously I didn't, even though I've thought since >> the mid-eighties that it would be a useful capability to have.) > >Not only was it considered - it's there. > >> As an example of what I'm talking about, consider a package that >> implements three distinct floating-points types for measuring length, >> area, and volume. The pre-defined "+" and "-" are acceptable and there >> are obvious redefinitions of "*" and "/" in some cases. However, the >> pre-defined "/" for operands of the same type don't make sense and it >> would be nice to get a compile-time warning if one of them is used. > >function "/" (L, R : Length) return length is abstract; > Wow, that was a surprise! I'm quite familiar with the concepts of abstract types and abstract subprograms in the object-oriented context. I've even given presentations on Ada's special approach to OO. Maybe that familiarity led me astray. Reading too fast, I didn't catch that an abstract subprogram doesn't have to be an operation of an abstract, or even a tagged, type. I've been lovingly fondling the LRM the last couple of days and I'm still not certain what's going on here. Whatever it is, it appears not to work. The only test I've run so far has been with the Green Hills compiler and it doesn't like this use of abstract for this purpose. Making educated guesses, it appears that the reason is this: Defining the type as abstract makes the operation illegal to call but it doesn't hide it. Extracting from my particular case, if I have the two declara- tions function "-" (L, R : Time_Type) return Delta_Time_Type; function "-" (L, R : Time_Type) return Time_Type is abstract; and I later have the subexpression TT1 - TT2, where the two values are both of type Time_Type, and this subexpression is part of an appropri- ately constructed expression, then the Green Hills compiler complains of an ambiguity. As I see it, it's saying, "I can't tell if you're refer- ring to the o. k. "-" that returns a value of type Delta_Time_Type or if you're referring to the other one, which would be illegal if that's what you meant." Even if M. Rosen is right and Green Hills is wrong, this approach still doesn't work for me because the problem with literals (mentioned in my original post) still remains. To restate it, if I could use this technique to rule out function "*" (L, R : Delta_Time_Type) return Delta_Time_Type; then I would have also ruled out multiplying a delta time by a real lit- eral. Even if this worked (works), I find it lacking in esthetics. A point I always make when arguing in favor of Ada is that it usually al- lows us to say what we mean in a fairly direct fashion. When we want to say that a type or a subprogram is abstract, we don't have to use some totally non-intuitive notation such as might be found in a more popular language. We simply say "is abstract". If the feature that I want were available, I'd really like to see something like function "-" (L, R : Time_Type) return Time_Type is disallowed; (Since there is a strong aversion to adding reserved words to Ada, we could probably get by with "is not". ;-)) Another responder mentioned that disallowing operations would have an impact on generics. That's true, and a point that I have never con- sidered. I'll consider it as soon as I have this abstract subprogram stuff straightened out. At the very least, the contract model would have to become much more elaborate and I doubt that many people have the stomach for working on that. Finally, one responder has mentioned that it could be handled by a non-standard pragma. Maybe so, but there's that problem with generics to contend with. In any case, non-standard pragmas are not worth a lot to somebody who is interested in portable code, like me. Charlie -- ****** For an email response, my user name is "sampson" and my host is "spawar.navy.mil".