"Dr. Alan Barnes" <[log in to unmask]> writes:
> A related issue arose a few weeks ago when I redefined "/" and "**"
> for modular numbers in a package of the form:
>
> GENERIC
> TYPE Zed_N IS MOD <>;
> PACKAGE Mod_Pack IS
>
> NotInvertible, Zero_To_Power_Zero, Modulus_Too_Large : EXCEPTION;
>
> FUNCTION "**"(A : Zed_N; N : Integer) RETURN Zed_N;
[snip]
> If simply instantiate the package and USE it in a client
>
> TYPE Z31 IS MOD 31;
> PACKAGE Mod31 IS NEW Mod_Pack(Z31);
> USE Mod31;
>
> then the definitions of Standard."/" and Standard."**" are not overridden and
> a program using "/" and "**" with arguments of type Z31 is ambiguous
> and will not compile (with gnat).
This is a bit confused. The primitive operators "/" and "**" for type
Z31 are not defined in package Standard. They are implicitly declared
at the point of declaration of the type Z31.
Non-primitive operations that are made (directly) visible via a use
clause never override predefined operations for the type. The only way
to override a predefined operation of the type is to ... override the
predefined operation of the type.
> Suprisingly the situation is different if the package is not generic:
>
> PACKAGE Mod31 IS
> TYPE Z31 IS MOD 31;
> -- rest of package unchanged (apart from renaming fo Zed_N)
No, not surprising if you understand the difference between a primitive
and non-primitive operation. In the non-generic version above, you
override the predefined operations, so there is no ambiguity.
> If you simply WITH and USE this package the program compiles but the
> new overloadings of "/" and "**" are ignored and the ones from
> Standard are used.
Again, this is confused. The operations don't come from Standard. They
are implicitly declared at the point of declaration of the type.
The language was carefully designed so that the meaning of a program
doesn't change whether or not a use clause is used. This is to avoid
what is called a "Beaujolais effect"; see the Ada FAQ for more info.
The basic idea is that operations made available via a use clause are
used only if the same operation isn't available directly via a renaming
declaration or because it's primitive.
So the operations from Mod_Pack aren't used, because the same operation
is available via a primitive operation of the type.
> To override the Standard definitions in the client in either case you
> can do
>
> FUNCTION "/"(A, B : Z31) RETURN Z31 RENAMES Mod31."/";
> FUNCTION "**"(A : Z31; N : Integer) RETURN Z31 RENAMES Mod31."**";
>
> This seems rather messy, but I couldn't see a way of avoiding it.
It may seem messy, but that language was designed this way for a
reason. For the reader of your code, there's no ambiguity about what
"/" and "**" mean.
If you want to "override" primitive operations for the type, then it's
better to do this:
PACKAGE Mod_Pack IS
NotInvertible, Zero_To_Power_Zero, Modulus_Too_Large : EXCEPTION;
GENERIC
TYPE Zed_N IS MOD <>;
FUNCTION Generic_Exp (A : Zed_N; N : Integer) RETURN Zed_N;
-- returns A**N. When N < 0 and Inverse(A) does not exist
-- raises the exception NotInvertible
-- raises the exception Zero_To_Power_Zero if 0**0 is formed.
GENERIC
TYPE Zed_N IS MOD <>;
FUNCTION Generic_Divide (A, B : Zed_N) RETURN Zed_N;
-- returns A*Inverse(B) mod n if Inverse(B) exists
-- else raises the exception NotInvertible
GENERIC
TYPE Zed_N IS MOD <>;
FUNCTION Generic_Inverse(A : Zed_N) RETURN Zed_N;
-- returns the inverse of A mod n if it exists
-- else raises the exception NotInvertible
GENERIC
TYPE Zed_N IS MOD <>;
FUNCTION Generic_IsInvertible(A : Zed_N) RETURN Boolean;
-- returns True if A has an inverse mod n, otherwise returns False
END Mod_Pack;
with Mod_Pack;
package Z31_Types is
type Z31 is mod 31;
function Predefined_Div (L, R : Z31)
return Z31 renames "/";
function "/" is new Mod_Pack.Generic_Divide (Z31);
function Predefined_Exp (A : Z31; N : Integer)
return Z31 renames "**";
function "**" (A : Z31; N : Integer)
return Z31 is new Mod_Pack.Generic_Exp (Z31);
...
end Z31_Types;
However, I don't recommend you override predefined operators of a type
anyway. Pick a different name, like Div. Then you can use your generic
package approach.
It may seem like heresy to say so, but I think it was a mistake for the
language to allow a programmer to override predefined operators of a
(scalar) type. "+" should always mean "+", and "/" should always mean
"/".
It's not that much syntactic overhead to say
X := Div (Y, Z);
instead of
X := Y / Z;
Using a function operation named Div (instead of a function operator
named "/") avoids all these headaches you're having trying to replace
predefined operators for the type, and makes it clear that a special
divide operation is being called.
> I guess the reason for the above is that you cannnot TACITLY change the
> meaning of a program with a USE which overrides operators in
> Standard. However it is not clear to me why the sitaution is different
> for generic and non-generic packages.
The situation is not different for generic and non-generic packages.
In you generic version, you were merely creating more operations for the
original type; you were not overriding (or otherwise replacing) the
operations that were already defined for the formal type.
It is as if someone gives you a pair of binoculars. The binoculars
don't replace your eyeballs. If someone says "Hey, look at this" then
look-with-eyeballs is assumed. But if you want the thing to be viewed
using the binoculars, then the someone has to say "Hey, look at this
with your binoculars."
In the non-generic version, you really were overriding the predefined
operation of the type. To continue the analogy, this is like getting a
new set of eyeballs.
At the point of declaration of the type, the predefined operations for
the type are implicitly declared:
PACKAGE Mod31 IS
TYPE Z31 IS MOD 31;
Implicit declaration of
FUNCTION "**"(A : Z31; N : Integer) RETURN Z31;
Implicit declaration of
FUNCTION "/"(A, B : Z31) RETURN Z31;
Implicit declaration of <other predefined operations>
...
end Mod31;
but then you explicitly override the predefined operations with your
own:
PACKAGE Mod31 IS
TYPE Z31 IS MOD 31;
<Implicit, predefined operations>
FUNCTION "**"(A : Z31; N : Integer) RETURN Z31;
FUNCTION "/"(A, B : Z31) RETURN Z31;
...
end Mod31;
The operations "**" and "/" explicitly override the predefined
operations for the type. They are primitive, but not predefined.
But again, I don't recommend you do this anyway. Better names would be
function Exp (A : Z31; N : Integer) return Z31;
function Div (A, B : Z31) return Z31;
> Also if an operator from Standard is given a new overloading by a
> renaming declaration in a (non-generic) package declaration, then a
> client program which WITH's and USE's the package and attempts to use
> the overloaded operators is again ambiguous and will not compile.
Yes. The compiler tells you when there's ambiguity.
> Again the reason for the different behaviour is not clear to me. Is
> this situation covered by the LRM? If so, where? Or is it a
> 'feature' in gnat?
There is no "different behavior."
Read the Ada83 Rationale.
Read about what the "Beaujolais effect" in the Ada FAQ.
<http://www.adahome.com/>
Here is an excerpt from a post a made to comp.lang.ada on Jan 24, 1997,
with subject "Environment Variables":
(start of excerpt)
The rules for use are as follows. To resolve the reference to the
operation, the compiler looks in successively outer scopes for an explicit
operation declaration or rename, until it hits the unit containing the type
declaration (where presumably the operation is primitive). The units named
in a use clause are considered only *after* this has been done.
Localizing a use clause only limits the scope to which the use clause
applies; it doesn't give the operations in the named unit any kind of
"priority" when resolving the reference. The operations of the unit named
in the use clause are still considered only after not finding explicit
declarations or renames, no matter how "near" it appears to the invokation
of the operation. (end of excerpt)
Matt
<mailto:[log in to unmask]>