On Mon, 7 Dec 1998, Matthew Heaney wrote:
> If you import that type as a private, you'll have to import literals
> too:
>
> generic
> type T is private;
> One : in T;
> with function "+" (L, R : T) return T is <>;
Actually, in the design I suggested there is no need for literals.
Instead, one would include generic formal subprograms that return
a set of values necessary to for instantiation with any private
type.
For example,
generic
type Item is private;
with function Zero_Equivalent return Item;
with function Tic_First return Item;
with function Increment return Item;
with function Tic_Last return Item;
 Now the arithmetic and relational operators
 Use default notation for all operators
with function "+" (L, R : Item) return Item is <>;
 etc.
package Generic_Math_Ops is end Generic_Math_Ops;
With this model, one can instatiate with a record type such as a fraction,
an access type, or any other type for which assignment is permitted. This
can also be used as a package for instantiating under the rules of
generic formal package parameters. For example,
with Generic_Math_Ops;
generic
with package Math_Ops is new Generic_Math_Ops ... ;
package Statistical_Analysis is
 any set of services here
end Statistical_Analysis;
If you do instantiate with a type for which there is a set of predefined
operators, the use of the default reduces the number of actual arguments.
I prefer to define generic formal functions rather than constants to make
the design more flexible. In fact, I have eschewed the use of deferred
constants in favor of functions for ordinary packages. Deferred constants
are not as maintainable as functions returning constant values.
Richard Riehle
[log in to unmask]
http://www.adaworks.com
