Re: Disallowing Pre-Defined Operations

[Tucker Taft <stt@averstar.com>]

"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