"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]>