On naming space and the good use of qualified expression

On naming space and the good use of qualified expression

[Mehdi Saada]

At that point of the program, I have three "/" operators visibles:
function "/" (A: T_Rational, B: T_Rational) return T_Rational;
function "/" (A: T_Integer, B: T_Integer) return T_Integer;
function "/" (A: T_Integer, B: T_Integer) return T_Rational; -- my constructor method
which makes this expression ambiguous:
Result.Coef(Ind) := Poly_A.Coef(Ind+1) * (Ind+1)/1;
(Coef is an array of T_Rational, Ind is of the same type as the index)

For the first time, I grasp what "namespace polution" means. I overestimated the compiler's smartness. I tried then:
Result.Coef(Ind) := Poly_A.Coef(Ind+1) * T_Rational'((Ind+1)/1);
As I thought qualified expression were a means to inform the compiler of the intended type of the parenthesed expression, so that it could choose based on the litteral inside AND the different visible homonymous functions.
But I got the same error with or without qualified expression:
p_poly_v1_g.adb:82:71: expected private type "T_Rational" defined at p_rationals_g.ads:11, instance at p_poly_v1_g.ads:19
p_poly_v1_g.adb:82:71: found type "Standard.Integer"

Was I mistaken about qualified expressions ?
How can I express myself so that the compiler understand, BESIDES prefixing every single operators with P_Rationals, which is ugly.
I try to understand the use of "use type" and use "all type ...", but I don't manager to for the moment. The language doesn't help, when confronted with new technical stuff. I get it better through exemples...

Re: On naming space and the good use of qualified expression

[Niklas Holsti]

On 18-01-19 19:51 , Mehdi Saada wrote:
> At that point of the program, I have three "/" operators visibles:
> function "/" (A: T_Rational, B: T_Rational) return T_Rational;
> function "/" (A: T_Integer, B: T_Integer) return T_Integer;
> function "/" (A: T_Integer, B: T_Integer) return T_Rational; -- my constructor method
> which makes this expression ambiguous:
> Result.Coef(Ind) := Poly_A.Coef(Ind+1) * (Ind+1)/1;
> (Coef is an array of T_Rational, Ind is of the same type as the index)
>
> For the first time, I grasp what "namespace polution" means.
> I overestimated the compiler's smartness. I tried then:
> Result.Coef(Ind) := Poly_A.Coef(Ind+1) * T_Rational'((Ind+1)/1);
> As I thought qualified expression were a means to inform the compiler
> of the intended type of the parenthesed expression, so that it could
> choose based on the litteral inside AND the different visible homonymous
> functions.

Perhaps you also have a set of overloaded "+" operators, and the 
confusion is in the expression Ind+1 ?

That is, should the computation be:

   Ind + 1, as Integer + Integer -> Rational

followed by

   (Ind + 1) / 1, as Rational / Integer -> Rational ?

Or should it be:

    Ind + 1, as Integer + Integer -> Integer

followed by

    (Ind + 1) / 1, as Integer / Integer -> Rational ?

Just a guess, of course...

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: On naming space and the good use of qualified expression

[AdaMagica]

Am Freitag, 19. Januar 2018 18:51:06 UTC+1 schrieb Mehdi Saada:

Don't know why qualification does not work - too little information (no compilable code). Maybe the problems is somewhere else.

But:
> At that point of the program, I have three "/" operators visibles:
> function "/" (A: T_Rational, B: T_Rational) return T_Rational;  (1)
> function "/" (A: T_Integer, B: T_Integer) return T_Integer;     (2)
> function "/" (A: T_Integer, B: T_Integer) return T_Rational;    (3)

When dealing with rational numbers, I do not see the purpose of (2). Why do you need truncation? Remove it and many problems will be gone.

I have complete rational arithmetics package in
http://www.christ-usch-grein.homepage.t-online.de/Ada/Dimension/SI.html
which can handle any mixture of whole and rational numbers.

Re: On naming space and the good use of qualified expression

[Jeffrey R. Carter]

On 01/19/2018 06:51 PM, Mehdi Saada wrote:
> At that point of the program, I have three "/" operators visibles:
> function "/" (A: T_Rational, B: T_Rational) return T_Rational;
> function "/" (A: T_Integer, B: T_Integer) return T_Integer;
> function "/" (A: T_Integer, B: T_Integer) return T_Rational; -- my constructor method
> which makes this expression ambiguous:
> Result.Coef(Ind) := Poly_A.Coef(Ind+1) * (Ind+1)/1;

Note that this should be evaluated as

(Poly_A.Coef (Ind + 1) * (Ind + 1) ) / 1

and understanding it requires knowing what "*" operators are visible.

> Result.Coef(Ind) := Poly_A.Coef(Ind+1) * T_Rational'((Ind+1)/1);

This looks like it should work, but without a complete reproducer I can't tell 
why it doesn't.

-- 
Jeff Carter
"Every sperm is sacred."
Monty Python's the Meaning of Life
55

Re: On naming space and the good use of qualified expression

[Mehdi Saada]

There's DEFINITELY something fishy here:
Result.Coef(Ind) := P_Rationals."/"((Ind+1),1);

gave the same result:
p_poly_v1_g.adb:82:42: expected private type "T_Rational" defined at p_rationals_g.ads:11, instance at p_poly_v1_g.ads:19
p_poly_v1_g.adb:82:42: found type "Standard.Integer"
gnatmake: "p_poly_v1_g.adb" compilation error


Then, I had the idea of renaming P_Rationals."/", which solves a bit of the ambiguity, pointing at the fact that:

type T_Entier is range <>;
subtype T_Entier_Pos is T_Entier range 1..T_Entier'Last;
subtype T_Degre is Natural range 0..Max;

Ding Dong !! Found it ! Indeed, rational operators are defined for T_Entier, in the P_Rational package. I then merely changed the definitions by:

Max : Positive;
Max_Degre: T_Entier := T_Entier(Max);
subtype T_Degre is T_Entier range 0..Max_Degre;

It works now. Ah, I feel smart now. Every little thing Ada does is magic.. Thanks to the idea of renaming "/", which gave me the supplement of informations I needed to figure things out.
Also, I forgot I had the operator
function "*"(R1 : T_Rationnel; R2 : T_Entier)  return T_Rationnel;
which removes the need of using the construct.
AdaMagica: 1)went on your website, love your humor. I think I'll begin dreaming of Lady Ada, and probably her infamous father too. 2) Specifications are part of the exercice, I can't change it too much or use an already made package, which would, well, negate the entire aim of the exercice :-P