Re: Disallowing Pre-Defined Operations

[Robert A Duff <bobduff@world.std.com>]

claveman@fern.com writes:

>      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."

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.

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.

>      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.

You could define another type specifically for numeric literals.  After
all, in "X * 2.5", 2.5 is not a time, it's conceptually a dimensionless
quantity.  You presumably want to allow multiplication by a named
number, as well.

>      Even if this worked (works), I find it lacking in esthetics.

An abstract subprogram is exactly a subprogram that can't be called.
That's true for both tagged and untagged, although the rules that ensure
this property are more complicated in the tagged case, because they need
to account for dispatching calls.

It does seem a bit backwards, perhaps: you might like to declare the
operations that *do* exist, not the ones that don't.  Most of the time,
most programmers don't bother with all this stuff, presumably for that
reason.

Note that you don't want to make these *types* abstract -- just some of
the operations.  There is no such thing as an abstract untagged type.

>...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;

And how would this differ from the concept of an abstract subprogram?
Is it allowed for tagged types?  Does it have all the same rules about
overriding as abstract subprograms do?

> (Since there is a strong aversion to adding reserved words to Ada, we
> could probably get by with "is not".  ;-))

Various suggestions along those lines were made during the Ada 9X
project.  Norm Cohen was particularly good at coming up with this sort
of thing, and I think he suggested "is abs" instead of "is abstract",
since "abs" was already reserved in Ada 83.  I was never quite sure if
he was joking or not -- certainly "is abs" looks pretty ugly to my eyes.

>      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.

Actually, in an instance, all the operations revert to the predefined
ones anayway, so I don't see a problem (although many people think that
reversion is itself a language flaw).

>      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.

Such a pragma (whether language-defined or implementation-defined) would
be in extremely bad taste, IMHO.  Pragmas should not have a strong
effect on the high-level semantics of the language.

- Bob