Re: Disallowing Pre-Defined Operations

[claveman@fern.com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4468 bytes --]

In article <8ababr$c3u$1@wanadoo.fr>,
Jean-Pierre Rosen <rosen.adalog@wanadoo.fr> wrote:
>
>Charles H. Sampson <claveman@cod.nosc.mil> 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".