Re: Dispatching and generics - language lawyer question

[Robert A Duff <bobduff@shell01.TheWorld.com>]

Hi, Ben.

"Ben Brosgol" <brosgol@world.std.com> writes:

> As another interesting case, suppose that you declare an integer type T with
> "mod" specified as abstract.  If "mod" on the formal type is invoked from
> the generic body, then either the instantiation Ada.Text_IO.Integer_IO(T)
> would need to be rejected (a rather flagrant violation of the "contract
> model") or else the predefined "mod" would need to reemerge.

Yes, that *is* an interesting case, which I hadn't thought of.

Note that for tagged types, the generic declares whether it wants to
accept types with abstract primitive ops, so the instantiation can be
rejected without violating the contract model.  It's uncomfortable that
there are misc. rules like this that distinguish tagged types from
untagged types.  Could we do better if designing the language from
scratch?  (I think many such rules are needed for compatibility with Ada
83.)  I'm not sure what the right answer is in this case.

I'm disappointed that nobody answered my previous question -- what
should the rules about predefined operators in generics be?  I don't
like the current Ada rules (which require reemergence of the "wrong"
operator), but the alternatives are uncomfortable in various ways.
Christoph Grein, or anybody else want to comment?

Here's an interesting case: a generic Sort routine, that takes "<" as a
parameter.  (Or it could be called "Less_Than" -- it doesn't matter what
it's called, or whether it's an operator symbol.)  The Sort routine
might require that the "<" behave in certain ways (like if A<B and B<C
both return True, then A<C should always return True).  Is there any way
to specify that (other than via comments)?  Is there some way to design
the language so that the generic Sort could formally require such
properties of "<"?

This is similar to the Text_IO.Integer_IO example, where the code wants
to assume that "mod" behaves according to some mathematical rules.
(I'm not even sure how to state those rules precisely.)

- Bob