"unconstrained subtype in component declaration" vs "discriminant in constraint must appear alone"

"unconstrained subtype in component declaration" vs "discriminant in constraint must appear alone"

[Mehdi Saada]

this message "unconstrained subtype in component declaration"
arises from this:

    subtype Limit_number is Natural range 0..51;
    type CARDS is new Natural range Limit_number'Range;
    type Sets_of_Card is array (Limit_number range <>) of Cards;
    function INITIALIZATION (Nb: Nombre_cartes) return Sets_of_Card;
         type CARDS_SETS (Nb: Nombre_cartes) is record
         Set: Sets_of_Card := INITIALIZATION (Nb);
    end record;

okay,
then this "Set: Sets_of_Card (0..nb-1) := INITIALIZATION (Nb);"
gives "discriminant in constraint must appear alone" !
|[{|@]ŋ¤£# !!

How do you do ?

Re: "unconstrained subtype in component declaration" vs "discriminant in constraint must appear alone"

[J-P. Rosen]

Le 22/02/2021 à 01:14, Mehdi Saada a écrit :
> this message "unconstrained subtype in component declaration"
> arises from this:
> 
>      subtype Limit_number is Natural range 0..51;
>      type CARDS is new Natural range Limit_number'Range;
>      type Sets_of_Card is array (Limit_number range <>) of Cards;
>      function INITIALIZATION (Nb: Nombre_cartes) return Sets_of_Card;
>           type CARDS_SETS (Nb: Nombre_cartes) is record
>           Set: Sets_of_Card := INITIALIZATION (Nb);
>      end record;
> 
> okay,
> then this "Set: Sets_of_Card (0..nb-1) := INITIALIZATION (Nb);"
> gives "discriminant in constraint must appear alone" !
> |[{|@]ŋ¤£# !!
> 
> How do you do ?
> 
1) Forget about Integer, if you want an independent integer type, define 
it as such:
type Cards is range 0..51;
(BTW: why not 1..52?)

2) Components of arrays and records must have a definite size

3) Sets_of_Card (0..nb-1)
I think you meant Sets_of_Card (nb-1). Yes, you cannot make computations 
in a discriminant constraint. Although this may seem sometimes 
frustrating to the user, it was required for implementation reasons. 
However, in your case, using the natural range of 1..52 would avoid the 
issue.

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: "unconstrained subtype in component declaration" vs "discriminant in constraint must appear alone"

[AdaMagica]

J-P. Rosen schrieb am Montag, 22. Februar 2021 um 07:32:27 UTC+1:
> 3) Sets_of_Card (0..nb-1) 
>Yes, you cannot make computations 
> in a discriminant constraint. Although this may seem sometimes 
> frustrating to the user, it was required for implementation reasons. 

Remeber, a discriminant is a record component like the others, so it covers some bits.
If it were allowed to be used in expressions, either each result would need a storage place of its own or a reevaluation at every use of the object.

Re: "unconstrained subtype in component declaration" vs "discriminant in constraint must appear alone"

[Jeffrey R. Carter]

On 2/22/21 1:14 AM, Mehdi Saada wrote:
> 
>      subtype Limit_number is Natural range 0..51;
>      type CARDS is new Natural range Limit_number'Range;
>      type Sets_of_Card is array (Limit_number range <>) of Cards;

The problem domain is a physical deck of cards. A deck is a sequence where the 
order is important and each card has a position in the deck. When talking about 
the position of a card in a deck, we talk about the first card, the second card, 
..., the last card. When counting the cards in a deck, we use the numbers 1, 2, 
..., N. The only use of zero might be to refer to the number of cards in an 
empty deck.

When modeling this problem domain in software, we should use the same concepts 
and terminology, so we should use the numbers 1 .. N for the positions of cards 
in a deck of N cards. When we do this, your problem disappears.

Another feature we see in the problem domain is that a deck has a maximum size 
(the total number of cards), but its current size may change. Your approach 
doesn't model this very well.

You might want to look at PragmARC.Cards.Decks.General

https://github.com/jrcarter/PragmARC/blob/Ada-12/pragmarc-cards-decks-general.ads

-- 
Jeff Carter
"My dear Mrs. Hemoglobin, when I first saw you, I
was so enamored with your beauty I ran to the basket,
jumped in, went down to the city, and bought myself a
wedding outfit."
Never Give a Sucker an Even Break
111

Re: "unconstrained subtype in component declaration" vs "discriminant in constraint must appear alone"

[Dmitry A. Kazakov]

On 2021-02-22 11:14, AdaMagica wrote:
> J-P. Rosen schrieb am Montag, 22. Februar 2021 um 07:32:27 UTC+1:
>> 3) Sets_of_Card (0..nb-1)
>> Yes, you cannot make computations
>> in a discriminant constraint. Although this may seem sometimes
>> frustrating to the user, it was required for implementation reasons.
> 
> Remeber, a discriminant is a record component like the others, so it covers some bits.
> If it were allowed to be used in expressions, either each result would need a storage place of its own or a reevaluation at every use of the object.

Yes, though if the implementation would dope all indefinite 
representations, not just arrays, then keeping some more things in the 
dope or evaluating them would not be a big issue.

The ultimate goal is, of course, removing the dope if static. Be it 
array bounds, discriminants or type tag.

P.S. Composition of a dope from the dopes of the components is basically 
the same problem as full multiple inheritance. If the language had one 
it could have both.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: "unconstrained subtype in component declaration" vs "discriminant in constraint must appear alone"

[Mehdi Saada]

So typical, you ask for a technical issue, they respond "your strategy is bad" X-D
The exo says explicitely "do not use the magic number 52"... whatever ;-)

"If it were allowed to be used in expressions, either each result would need a storage place of its own or a reevaluation at every use of the object."
I understand the point. But does / will it change with the Static aspect on functions, ensuring it would not have to re-evaluated at each call ?
I just intend to initialize the value once and done. It is a default value, not a dynamic predicate.

Re: "unconstrained subtype in component declaration" vs "discriminant in constraint must appear alone"

[Mehdi Saada]

> You might want to look at PragmARC.Cards.Decks.General 
> https://github.com/jrcarter/PragmARC/blob/Ada-12/pragmarc-cards-decks-general.ads > -- 
> Jeff Carter

Pleeease my dear, it's a beginner's exo - Ada 95 the craft of oriented programming, what's the fun in looking for an expert's implementation ?

Re: "unconstrained subtype in component declaration" vs "discriminant in constraint must appear alone"

[Jeffrey R. Carter]

On 2/22/21 3:21 PM, Mehdi Saada wrote:
> 
>> You might want to look at PragmARC.Cards.Decks.General
>> https://github.com/jrcarter/PragmARC/blob/Ada-12/pragmarc-cards-decks-general.ads > --
>> Jeff Carter
> 
> Pleeease my dear, it's a beginner's exo - Ada 95 the craft of oriented programming, what's the fun in looking for an expert's implementation ?

You might want to look at the public part of the spec for design ideas.

I don't know what an "exo" is. I'm pretty sure English doesn't use the word.

-- 
Jeff Carter
"My dear Mrs. Hemoglobin, when I first saw you, I
was so enamored with your beauty I ran to the basket,
jumped in, went down to the city, and bought myself a
wedding outfit."
Never Give a Sucker an Even Break
111

Re: "unconstrained subtype in component declaration" vs "discriminant in constraint must appear alone"

[J-P. Rosen]

Le 22/02/2021 à 16:02, Jeffrey R. Carter a écrit :
> I don't know what an "exo" is. I'm pretty sure English doesn't use the 
> word.
Pretty common abbreviation of "exercise" in french...

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: "unconstrained subtype in component declaration" vs "discriminant in constraint must appear alone"

[J-P. Rosen]

Le 22/02/2021 à 15:20, Mehdi Saada a écrit :
> I just intend to initialize the value once and done. It is a default value, not a dynamic predicate.
Then:
Set: constant Sets_of_Card := INITIALIZATION (Nb);

You don't need to specify the discriminants if it can be inherited from 
the initial value. And of course, if it doesn't change, it should be 
declared as a constant.

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: "unconstrained subtype in component declaration" vs "discriminant in constraint must appear alone"

[Dmitry A. Kazakov]

On 2021-02-22 15:20, Mehdi Saada wrote:

> I just intend to initialize the value once and done. It is a default value, not a dynamic predicate.

There are three categories of "once":

1. Once per compilation, static
2. Once per object instantiation, subtype/dynamic constraint
3. Once per object update
------
and any time any place, variable.

As J-P said, you can have whatever expressions in #1, just remove 
discriminants.

In other cases you can add more discriminants and a constructing 
function. E.g. replace

    type T (L : Positive) is
       A : S (0..L - 1);
    end record;

with

    type T (<>) is private;
    function Create (L : Positive) return T;
private
    type T (L : Positive; Upper : Natural) is
       A : S (0..Upper);
    end record;

    function Create (L : Natural) return T is
    begin
       return Result : T (L, L - 1) do
          ... -- Some initialization
       end return;
    end Create;

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: "unconstrained subtype in component declaration" vs "discriminant in constraint must appear alone"

[Mehdi Saada]

> There are three categories of "once": 
> 2. Once per object instantiation, subtype/dynamic constraint 
Sorry, I mean that, and it's meant to be mutable, for which I forgot the := default_discrimant_value).

> As J-P said, you can have whatever expressions in #1, just remove 
> discriminants. 
Actually
 type CARDS_SETS (Nb: Nombre_cartes := 0) is record
         Set: Sets_of_Card := INITIALIZATION (Nb);
      end record;
gives "unconstrained subtype in component declaration" so I'm forced to put a constraint despite the defaults.
I would have supposed that the constraint would come from the default value, or from a value in an aggregate.

But I scrapped the "no 52" for
type CARDS_SETS (Nb: Nombre_cartes := 0) is record
         Set: Sets_of_Card (1..Nb) := INITIALIZATION (Nb);
      end record;
and it's good.

What a wealth of gems I can get from a bunch of cards X-D

Re: "unconstrained subtype in component declaration" vs "discriminant in constraint must appear alone"

[Mehdi Saada]

Please help figure out this:

 type CARDS is new cards_numbers range 1..52;
-->
        41:10 missing case values: -128 .. 0
        41:10 missing case values: 5 .. 127
        41:25 subtype of expression is not static, alternatives must cover base type
from --> 
[card in CARDS, of course]
 	case (card / 13) +1 is
            when 1 => put("Spades");
            when 2 =>put("Hearts");
            when 3 =>put("Spades");
            when 4 =>put("Clovers");
         end case;

how can the compiler not know that CARD is limited from 1 to 52, including 0 for the base type (type Cards_numbers is range 0..52)

also what's wrong here:
Context => 
      type Sets_of_Card is array (Nombre_cartes range <>) of Cards;
 type CARDS_SETS (Nb: Nombre_cartes := 0) is record
         Set: Sets_of_Card (1..Nb) := INITIALIZATION (Nb);
      end record;
pack.nb =  5
pack.set'last =  5
faulty line:
PACK := (pack.nb-1, Pack.Set(pack.set'First..Pack.Nb-1));
issue:
raised CONSTRAINT_ERROR : discriminant check failed

and why is this expression not rejected:
         Pack := (pack.nb+1, pack.set & Card);
while this one is rejected ? 
Pack := (pack.nb+1, pack.set & CARDS_SET'(1=> Card));
a95cop1.adb:126:39: invalid operand types for operator "&"
this works but overkill... -> Pack := (pack.nb+1, (pack.set with delta PACK.NB+1 => Card));

Re: "unconstrained subtype in component declaration" vs "discriminant in constraint must appear alone"

[AdaMagica]

0012...@gmail.com schrieb am Dienstag, 23. Februar 2021 um 23:06:19 UTC+1:
> Please help figure out this: 
> 
> type CARDS is new cards_numbers range 1..52; 
> --> 
> 41:10 missing case values: -128 .. 0 
> 41:10 missing case values: 5 .. 127 
> 41:25 subtype of expression is not static, alternatives must cover base type 
> from --> 
> [card in CARDS, of course] 
> case (card / 13) +1 is 
> when 1 => put("Spades"); 
> when 2 =>put("Hearts"); 
> when 3 =>put("Spades"); 
> when 4 =>put("Clovers"); 
> end case; 
> 
> how can the compiler not know that CARD is limited from 1 to 52, including 0 for the base type (type Cards_numbers is range 0..52) 

Because Card/13 + 1 is a value in CARDS, and there is a rule that all values of the type must be covered.
Define a subtype covering only 1..4 and subtype convert the expression, then it shoud be fine.

Re: "unconstrained subtype in component declaration" vs "discriminant in constraint must appear alone"

[Jeffrey R. Carter]

On 2/23/21 11:06 PM, Mehdi Saada wrote:
> 
>   type CARDS is new cards_numbers range 1..52;
> -->
>          41:10 missing case values: -128 .. 0
>          41:10 missing case values: 5 .. 127
>          41:25 subtype of expression is not static, alternatives must cover base type

This tells you why.

> from -->
> [card in CARDS, of course]
>   	case (card / 13) +1 is
>              when 1 => put("Spades");
>              when 2 =>put("Hearts");
>              when 3 =>put("Spades");
>              when 4 =>put("Clovers");
>           end case;
> 
> how can the compiler not know that CARD is limited from 1 to 52, including 0 for the base type (type Cards_numbers is range 0..52)

You have "Spades" twice. It would be clearer and less error-prone to have

when 1 | 3 =>
    Put ("Spades");

if that's what you mean.

The compiler knows the subtype of Card, but since you have a signed type, the 
base type is roughly symmetrical around zero. The operators take and return 
values of the base type, so the compiler assumes the expression may have any 
value of the base type.

What you have is roughly equivalent to

type Cards_Numbers'Base is range /implementation_defined/;
    -- H/W type that includes 0 .. 52
subtype Cards_Numbers is Cards_Numbers'Base range 0 .. 52;

type Cards'Base is new Cards_Numbers'Base;
subtype Cards is Cards'Base range 1 .. 52;

Note also that 52 / 13 + 1 = 5.

If you write what you mean, you would have

case Card is
when 1 .. 13 =>
    Put (Item => "Spades");
when 14 .. 26 =>
    Put (Item => "Hearts");
when 27 .. 39 =>
    Put (Item => "Diamonds");
when 40 .. 52 =>
    Put (Item => "Clubs");
end case;

which makes it easy to what the result is for any card, and since the subtype of 
the case expression is static, should compile.

>        type Sets_of_Card is array (Nombre_cartes range <>) of Cards;
>   type CARDS_SETS (Nb: Nombre_cartes := 0) is record
>           Set: Sets_of_Card (1..Nb) := INITIALIZATION (Nb);
>        end record;
> pack.nb =  5
> pack.set'last =  5
> faulty line:
> PACK := (pack.nb-1, Pack.Set(pack.set'First..Pack.Nb-1));
> issue:
> raised CONSTRAINT_ERROR : discriminant check failed
> 
> and why is this expression not rejected:
>           Pack := (pack.nb+1, pack.set & Card);
> while this one is rejected ?
> Pack := (pack.nb+1, pack.set & CARDS_SET'(1=> Card));
> a95cop1.adb:126:39: invalid operand types for operator "&"

Assuming Pack is of type Cards_Sets, then Pack.Set has type Sets_Of_Card and the 
right operand of "&" is explicitly stated to be Cards_Set (which we have not 
seen), and apparently you have not defined "&" for these two types.

> this works but overkill... -> Pack := (pack.nb+1, (pack.set with delta PACK.NB+1 => Card));

What are the declarations of Nombre_Cartes and Pack?

-- 
Jeff Carter
"Blessed is just about anyone with a vested interest in the status quo."
Monty Python's Life of Brian
73

Re: "unconstrained subtype in component declaration" vs "discriminant in constraint must appear alone"

[Simon Wright]

Stack Overflow has the concept of a minimal complete reproducible
example[1].

It's hard to make sense of your code, because it's not complete; there's
all sorts of missing context. Ideally, it'd be possible for us to copy
your example, paste it into a local file, and try compiling it
ourselves.

It can help to compile your code with -gnatl, to intersperse error
messages with the code.

[1] https://stackoverflow.com/help/minimal-reproducible-example

Re: "unconstrained subtype in component declaration" vs "discriminant in constraint must appear alone"

[Shark8]

On Tuesday, February 23, 2021 at 3:06:19 PM UTC-7, 0012... wrote:
> Please help figure out this: 
> 
> type CARDS is new cards_numbers range 1..52; 
> --> 
> 41:10 missing case values: -128 .. 0 
> 41:10 missing case values: 5 .. 127 
> 41:25 subtype of expression is not static, alternatives must cover base type 
> from --> 
> [card in CARDS, of course] 
> case (card / 13) +1 is 
> when 1 => put("Spades"); 
> when 2 =>put("Hearts"); 
> when 3 =>put("Spades"); 
> when 4 =>put("Clovers"); 
> end case; 

Hm, I would recommend using an enumeration here.
Type Suit is (Spades, Hearts, Clubs, Diamonds); -- Or whatever you have/terms you want.
Function Get_Suit( Card : Cards ) return Suit is
    ( Suit'Val( Natural(Card)/13 ) );

Then use:
Case Get_Suit(card) is
  When Diamonds => ...
  When Hearts => ...
  When Spades => ...
  When Clubs => ...
End case;

> 
> how can the compiler not know that CARD is limited from 1 to 52, including 0 for the base type (type Cards_numbers is range 0..52) 
> 
> also what's wrong here: 
> Context => 
> type Sets_of_Card is array (Nombre_cartes range <>) of Cards;
> type CARDS_SETS (Nb: Nombre_cartes := 0) is record 
> Set: Sets_of_Card (1..Nb) := INITIALIZATION (Nb); 
> end record;
> pack.nb = 5 
> pack.set'last = 5 
> faulty line: 
> PACK := (pack.nb-1, Pack.Set(pack.set'First..Pack.Nb-1)); 
> issue: 
> raised CONSTRAINT_ERROR : discriminant check failed 
If you have something like PACK : CARD_SETS(7):= [...], then you cannot have a CARD_SETS(4) assigned to it.
Likewise, if you have a PACK : CARD_SETS := (Nb => 3, [proper-set-of-cards]), you cannot assign a (Nb => 2, [proper-set-of-cards]) to it, because to do so would be to alter the discriminant.

Now, one thing that you may not be cognizant of is that Sets_of_Cards is a full deck* of cards, so CARDS_SET(3) is three decks of cards.
* -- But this isn't quite true, you could set the full range of the array to a single value, say 4.

A bit of advice: Ada is really good at describing the problem-space using the type-system, so don't try to force the problem-space into some other domain.
There is nothing wrong with saying
Type Suit is (Hearts, Clubs, Diamonds, Spades);
Type Color is (Red, Black);
Function Is_Red(Item : Suit) return Boolean is ( Color'Val(Suit'Pos(Item) mod 2) );
Type Rank is ('1','2','3','4','5','6','7','8','9','0','J','Q','K','A'); -- Or numbers, card-ranking is kinda "squishy".
Type Card is record
  My_Suit : Suit;
  My_Rank : Rank;
end type;
Function "<"(Left, Right: Card) return Boolean is --Ranking mechanism.
--...

> and why is this expression not rejected: 
> Pack := (pack.nb+1, pack.set & Card); 
> while this one is rejected ? 
I believe it's because you're trying to re-set the discriminant; without a suitable example it's hard to tell though.

> Pack := (pack.nb+1, pack.set & CARDS_SET'(1=> Card)); 
> a95cop1.adb:126:39: invalid operand types for operator "&" 
> this works but overkill... -> Pack := (pack.nb+1, (pack.set with delta PACK.NB+1 => Card));
Yeah, here you're straight-up trying to overwrite the discriminant.

Re: "unconstrained subtype in component declaration" vs "discriminant in constraint must appear alone"

[Mehdi Saada]

Okay, point by point.
type Cards_number is range 0..52;
sorry lingering French

> type CARDS is new cards_numbers range 1..52;
> when 1 => put("Spades");
> when 2 => put("Hearts");
> when 3 => put("diamonds");
> when 4 => put("clubs");
> end case;

I didn't know half the terms in English. Nor that it was called a "suit"... I read novels but simple terms like this, nope..

> type Cards_Numbers'Base is range /implementation_defined/;
> type Cards'Base is new Cards_Numbers'Base;
I didn't get the meaning of 'Base before. ok.

> Note also that 52 / 13 + 1 = 5.
> If you write what you mean, you would have
Yes... I prefered being looking in the mirror and seeing a smartass with a math expression, to get myself ridiculous here, writing it wrong.
Ignoring this, could the compiler see that the expression has a limited number of possible results ? or a side tool ?

Never make it complicated and mathematics when it can be static and plain. Ok.
Morale: I have trouble not choosing names in a sorely confusing ðæµning way, even with care, đ↓¢ĸ, ßħ→ŧ !

> Yeah, here you're straight-up trying to overwrite the discriminant.
But I'm assigning a record aggregate to a mutable type object (so with a default disciminant).
So why does it matter if the component's subtype is constrained (here by the discriminant, but whatever) ?
It's the very point of mutable objects, to cope with these assignments... or What am I missing ?
That's the last issue remaining.

Re: "unconstrained subtype in component declaration" vs "discriminant in constraint must appear alone"

[AdaMagica]

0012...@gmail.com schrieb am Donnerstag, 25. Februar 2021 um 01:13:32 UTC+1:
> But I'm assigning a record aggregate to a mutable type object (so with a default disciminant). 
> So why does it matter if the component's subtype is constrained (here by the discriminant, but whatever) ? 
> It's the very point of mutable objects, to cope with these assignments... or What am I missing ? 
> That's the last issue remaining.

First a word to your attitude.

You ask us a favour to look at your code. That's OK and you're welcome.
But: You ask us to do some work for you. Then may we not expect that you do your work before?

What is your work?

Provide a complete compilable reproducer.
Write it in a consitent and readable style.

Is this expectation on our side really too much?

> type Sets_of_Card is array (Nombre_cartes range <>) of Cards;
> type CARDS_SETS (Nb: Nombre_cartes := 0) is record
> Set: Sets_of_Card (1..Nb) := INITIALIZATION (Nb);
> end record;

> PACK := (pack.nb-1, Pack.Set(pack.set'First..Pack.Nb-1));

This line by itself is not the problem IF Pack really is mutable.

declare
  Pack: Cards_Set := ...;  -- mutable object (no discriminant given in declaration)
begin
  PACK := (pack.nb-1, Pack.Set(pack.set'First..Pack.Nb-1));  -- this is OK, no Constraint_Error
end;

declare
  Pack: Cards_Set (52) := ...;  -- immutalbe object (discriminant given in declaration)
begin
  PACK := (pack.nb-1, Pack.Set(pack.set'First..Pack.Nb-1));  -- Constraint_Error (discriminant check)
end;

Re: "unconstrained subtype in component declaration" vs "discriminant in constraint must appear alone"

[Mehdi Saada]

Mystery resolved:
I did show the type definition but the instanciation matters and had a constraint. Pack: CARDS_SETS(5); Making it unmutable. Once declared with an aggregate it's fine.
...Now I'll systematically show compilable exemples of both package and test programs.
Thank you to put up with my idiocy.

Re: "unconstrained subtype in component declaration" vs "discriminant in constraint must appear alone"

[Mehdi Saada]

Errata no aggregate it's private so a constructor subroutine is needed anyway.