Re: Discriminants of tagged types

["Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr>]

Le Wed, 27 Oct 2010 19:58:50 +0200, J-P. Rosen <rosen@adalog.fr> a écrit:
> Reminder:
> I1 : Integer;  -- Can take all values of type Integer
> I2 : Integer range 1..10; -- Constraint, restricts to value 1..10
>
> with:
> type Rec (D: Disc) is ....
>
> I must declare:
> R1: Rec (1); -- Constraint, restricts to value 1 of discriminant.
>
> Wouldn't it be nice to have a variable that could hold all values of
> type Rec? Naturally, this is written as:
> R2: Rec;

This is to be written as “R2: Rec;” only if there is no way to know what  
the discriminant should be. I may lack experiences (which is a never  
ending story… (I like this old-movie's song)), so I may be wrong : R2, as  
it is a variable, will be assigned sooner or later, and this assignment  
will come with discriminant(s). I feel there is a way to infer this  
constraint (possibly using nested blocks to ease, although SPARK does not  
support it) in may be near to all cases.

If ever R2 is assigned to a value which males it change its constraints,  
this isn't any more the same layout, so a bit not the same type. What  
about saying this is no more the same object ?

In

    procedure Any_Name
    is
       R1 : Rec (Expression_1);
       R2 : Rec (Expression_2);
       R  : Rec;
    begin
       R := R1; -- (1)
       R := R2; -- (2)
    end;

I feel the R of (1) terminates at (2) and at (2) a new R is born. Someone  
may argue R is just assigned a new value. I feel there is two R here. But  
this is not so much easy to have a clear idea here, as functional  
programming aficionados will even argue “I := 1; I := 2;” also create two  
different things.

I can easily handle polymorphism in my mind, when it comes with dynamic  
binding like with tagged types (see later for more on this). Here, I have  
difficulties to see polymorphism, as I see two different objects just  
sharing the same storage (like with clumsy optimization).

To me, it is a bit (I say a bit, there is a kind of level here) like doing  
:

    procedure Any_Name_2
    is
       Time : Time_Type;
    begin
       Time := Lunch_Time;
       -- Do something with dinner time (ex. adjust
       -- Time to get a meaningful lunch time).
       -- ...
       -- Let us suppose we never have to do
       -- computation on Lunch_Time interspersed
       -- with computations on Party_Time, so
       -- we decided to “save” a variable and
       -- use one variable for both
       -- ...
       Time := Party_Time;
       -- Do some computation on party time, idem.
    end;

If we are to compute the exact time of lunch and the exact time of party,  
I would prefer to use two variables.

When we do “R := R1; R := R2;”, what about checking we are not doing  
something similar to the above ?

At least, that is like blurring subtypes. If we had :

    procedure Any_Name_3
    is
       Astronomical_Distance : Distance_Type range 1 .. <big value>;
       Every_Day_Distance : Distance_Type range 1 .. <humanized value>;
    begin
       -- Would want to mix Astronomical_Distance and
       -- Every_Day_Distance in a same variable here ?
       null;
    end;

Something similar : would want a parameter of a procedure, which could  
receive either Subtype_1 or Subtype_2 ?

This make sense with dynamic binding and dispatching parameter, because we  
have overloaded methods. But here, can we have a method which is  
specialized for both ?

When I talk about “methods” here, this can means any sequence of  
instructions inside of a method.


TBH, I will have to check if I used this in the past and why (I said all  
the above, while I am not sure I really never did it on my own side).


-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.