Re: Disallowing Pre-Defined Operations

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

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