why "unconstrained subtype in component declaration" while said component given default value ?

why "unconstrained subtype in component declaration" while said component given default value ?

[Mehdi Saada]

Hello.
Why is this case not allowed ? Is there really an implementation issue here ? I doubt so. Why should it be any different from the non-issue of initializing variables of unconstrained subtypes vs declaring uninitialized variables of constrained subtypes ?
 type A (N: Positive) is record
      II : Integer;
      Chaine : String := Give_String(N);
   end record;

Also, there's something that would be really cool, and I'm curious why it could not be allowed: Why can't we provide a private constrained subtype, of an inconstrained private type ?

package III is
   type A (<>) is private;
   subtype B is A;  -- should be a constrained subtype
private
   function Donne_String (N : Positive) return String;
   type A (N: Positive) is record
      II : Integer;
      Chaine : String(1..N) := Give_String(N);
   end record;
end III;

Re: why "unconstrained subtype in component declaration" while said component given default value ?

[Jere]

On Saturday, May 26, 2018 at 5:03:23 PM UTC-4, Mehdi Saada wrote:
> Hello.
> Why is this case not allowed ? Is there really an implementation issue here ? I doubt so. Why should it be any different from the non-issue of initializing variables of unconstrained subtypes vs declaring uninitialized variables of constrained subtypes ?
>  type A (N: Positive) is record
>       II : Integer;
>       Chaine : String := Give_String(N);
>    end record;
> 

Consider for a second that you are the compiler and you need to 
allocate a variable:

My_Variable : A(10);

What size (in bytes) do you need to allocate for the variable?  Remember
that the function Give_String can be exceedingly complex or even a 
function from a shared library.  How do you at compile time determine
the size of that record type?

However you can do:

    type A(N : Positive) is record
        II      : Integer;
        Chaine  : String(1..N) := Get_String(N);
    end record;

Because now the compiler will know at compile time how long the string
is and thus how big to make the record.

Re: why "unconstrained subtype in component declaration" while said component given default value ?

[Mehdi Saada]

But isn't the situation the same in automatic variables, with arrays whose constraint is only known at run time ? Like this:
procedure Main is
   subtype Pos_Little is Positive range 1..56;
   package Num_Gen is new Ada.Numerics.Discrete_Random (Pos_Little);
   Gen : Num_Gen.Generator;
begin
   declare
      Arr : array (1..Num_Gen.Random(Gen)) of Positive;
   begin
      null;
   end;
end Main;
Yet this case is legal.

Re: why "unconstrained subtype in component declaration" while said component given default value ?

[Jere]

On Saturday, May 26, 2018 at 6:11:13 PM UTC-4, Mehdi Saada wrote:
> But isn't the situation the same in automatic variables, with arrays whose constraint is only known at run time ? Like this:
> procedure Main is
>    subtype Pos_Little is Positive range 1..56;
>    package Num_Gen is new Ada.Numerics.Discrete_Random (Pos_Little);
>    Gen : Num_Gen.Generator;
> begin
>    declare
>       Arr : array (1..Num_Gen.Random(Gen)) of Positive;
>    begin
>       null;
>    end;
> end Main;
> Yet this case is legal.

Record types need to support Representation Clauses, where as normal 
variables do not.

Re: why "unconstrained subtype in component declaration" while said component given default value ?

[Jere]

On Saturday, May 26, 2018 at 7:55:36 PM UTC-4, Jere wrote:
> On Saturday, May 26, 2018 at 6:11:13 PM UTC-4, Mehdi Saada wrote:
> > But isn't the situation the same in automatic variables, with arrays whose constraint is only known at run time ? Like this:
> > procedure Main is
> >    subtype Pos_Little is Positive range 1..56;
> >    package Num_Gen is new Ada.Numerics.Discrete_Random (Pos_Little);
> >    Gen : Num_Gen.Generator;
> > begin
> >    declare
> >       Arr : array (1..Num_Gen.Random(Gen)) of Positive;
> >    begin
> >       null;
> >    end;
> > end Main;
> > Yet this case is legal.
> 
> Record types need to support Representation Clauses, where as normal 
> variables do not.

Actually, since you can do the one Shark8 showed at runtime as well, I 
am not sure of the "why" anymore.  I'll have to think on it or perhaps
someone else will chime in.

Re: why "unconstrained subtype in component declaration" while said component given default value ?

[Mehdi Saada]

> Record types need to support Representation Clauses, where as normal 
> variables do not.
That's quite an argument. But still...
>    type A (N: Positive) is record
>       II : Integer;
>       Chaine : String(1..N) := Give_String(N);
>    end record;
how can one define bit by bit the representation of A since N is not statically defined ? I've not used representation clauses yet, so it may be necessary to explain something obvious I might not see.
Well, anyway, many Ada programmers don't use representation clauses on a daily basis too ;-)

Re: why "unconstrained subtype in component declaration" while said component given default value ?

[Mehdi Saada]

> What's the use-case for this?
the use case is pretty limited if the subtype of Chaine has to be constrained. But it would have been practical if it wouldn't have to.
I was just thinking on the possibility of providing diverse constrained subtype of a unconstrained/undefined type, with different defaults values.
Of course using constructor functions is easier and works very well, so there's no issue... I was just pondering.

Re: why "unconstrained subtype in component declaration" while said component given default value ?

[Shark8]

On Saturday, May 26, 2018 at 6:29:11 PM UTC-6, Mehdi Saada wrote:
> > Record types need to support Representation Clauses, where as normal 
> > variables do not.
> That's quite an argument. But still...
> >    type A (N: Positive) is record
> >       II : Integer;
> >       Chaine : String(1..N) := Give_String(N);
> >    end record;
> how can one define bit by bit the representation of A since N is not statically defined?

It's not hard; in fact it's the standard way to deal with something like SSL's message-format. I don't remember the details of the actual records, but here's the concept:

Message Fields: Type, Length, Encryption, Text.

With Encryption;
Package Message is
  Type Message_Type is ( Internal, External, Loop, Heartbeat )
    with Size => 2; -- Whatever.
  
  Type Message( <> ) is private;
  -- Operations.
Private
    Package Enc renames Encryption;
    Type Message( Length : Positive; Style : Message_Type ) is record
     Text       : String(1..Length);
     Encryption : Enc.Method; -- Encryption method; say 6 bits.
    End record;
    
   For Message use record
    Style      at 0 range 0..2;
    Encryption at 0 range 3..8;
    Length     at 0 range 9..40;
   End Record;
End Message;

Or something like that; like I said, that's the general idea, not the specifics.
To read up on record representation clauses read this:
http://archive.adaic.com/standards/83lrm/html/lrm-13-04.html

Re: why "unconstrained subtype in component declaration" while said component given default value ?

[AdaMagica]

Am Sonntag, 27. Mai 2018 19:15:01 UTC+2 schrieb Shark8:
> On Saturday, May 26, 2018 at 6:29:11 PM UTC-6, Mehdi Saada wrote:
> > > Record types need to support Representation Clauses, where as normal 
> > > variables do not.
> > That's quite an argument. But still...
> > >    type A (N: Positive) is record
> > >       II : Integer;
> > >       Chaine : String(1..N) := Give_String(N);
> > >    end record;
> > how can one define bit by bit the representation of A since N is not statically defined?
> 
> It's not hard; in fact it's the standard way to deal with something like SSL's message-format. I don't remember the details of the actual records, but here's the concept:
> 
> Message Fields: Type, Length, Encryption, Text.
> 
> With Encryption;
> Package Message is
>   Type Message_Type is ( Internal, External, Loop, Heartbeat )
>     with Size => 2; -- Whatever.
>   
>   Type Message( <> ) is private;
>   -- Operations.
> Private
>     Package Enc renames Encryption;
>     Type Message( Length : Positive; Style : Message_Type ) is record
>      Text       : String(1..Length);
>      Encryption : Enc.Method; -- Encryption method; say 6 bits.
>     End record;
>     
>    For Message use record
>     Style      at 0 range 0..2;
>     Encryption at 0 range 3..8;
>     Length     at 0 range 9..40;
>    End Record;
> End Message;
> 
> Or something like that; like I said, that's the general idea, not the specifics.
> To read up on record representation clauses read this:
> http://archive.adaic.com/standards/83lrm/html/lrm-13-04.html

No, that doesn't work for a discriminated record like this. Rep clauses must be static. So you can only give rep specs for the static components; just omit the nonstatic one. The compiler will allocate it as the last one.

Re: why "unconstrained subtype in component declaration" while said component given default value ?

[Shark8]

On Sunday, May 27, 2018 at 11:30:59 AM UTC-6, AdaMagica wrote:
> Am Sonntag, 27. Mai 2018 19:15:01 UTC+2 schrieb Shark8:
> > On Saturday, May 26, 2018 at 6:29:11 PM UTC-6, Mehdi Saada wrote:
> > > > Record types need to support Representation Clauses, where as normal 
> > > > variables do not.
> > > That's quite an argument. But still...
> > > >    type A (N: Positive) is record
> > > >       II : Integer;
> > > >       Chaine : String(1..N) := Give_String(N);
> > > >    end record;
> > > how can one define bit by bit the representation of A since N is not statically defined?
> > 
> > It's not hard; in fact it's the standard way to deal with something like SSL's message-format. I don't remember the details of the actual records, but here's the concept:
> > 
> > Message Fields: Type, Length, Encryption, Text.
> > 
> > With Encryption;
> > Package Message is
> >   Type Message_Type is ( Internal, External, Loop, Heartbeat )
> >     with Size => 2; -- Whatever.
> >   
> >   Type Message( <> ) is private;
> >   -- Operations.
> > Private
> >     Package Enc renames Encryption;
> >     Type Message( Length : Positive; Style : Message_Type ) is record
> >      Text       : String(1..Length);
> >      Encryption : Enc.Method; -- Encryption method; say 6 bits.
> >     End record;
> >     
> >    For Message use record
> >     Style      at 0 range 0..2;
> >     Encryption at 0 range 3..8;
> >     Length     at 0 range 9..40;
> >    End Record;
> > End Message;
> > 
> > Or something like that; like I said, that's the general idea, not the specifics.
> > To read up on record representation clauses read this:
> > http://archive.adaic.com/standards/83lrm/html/lrm-13-04.html
> 
> No, that doesn't work for a discriminated record like this. Rep clauses must be static. So you can only give rep specs for the static components; just omit the nonstatic one. The compiler will allocate it as the last one.

The representation clause *IS* static. Notice the location for Text is not given, just as you are saying.

Re: why "unconstrained subtype in component declaration" while said component given default value ?

[AdaMagica]

Am Sonntag, 27. Mai 2018 20:17:37 UTC+2 schrieb Shark8:
> The representation clause *IS* static. Notice the location for Text is not given, just as you are saying.

Ah, you're right, my fault, I just missed the Text component.

Re: why "unconstrained subtype in component declaration" while said component given default value ?

[Mehdi Saada]

>   type Unconstrained_Collection
>     (Maximum_Size : Positive) is new Abstract_Collection with private;

>   subtype Collection
>      is Unconstrained_Collection (Maximum_Size => Maximum_Size);

It's close, but I would like to hide publicly the discriminants. I would like:
one unconstrained subtype with (<>) which needs initialization, and one subtype who doesn't need it. In fact, I don't need necessarily subtypes:
I could have:
type A(<>) is private;
type B is private;
private
  type A( - discriminants with or without defaults -) is ...
  subtype B is A ( some values); -- not possible, I already complained about it.

I can already get what I want if B is made a derived type of A. No need for tagged types here.

Re: why "unconstrained subtype in component declaration" while said component given default value ?

[Jeffrey R. Carter]

On 05/26/2018 11:40 PM, Jere wrote:
> 
> Consider for a second that you are the compiler and you need to
> allocate a variable:
> 
> My_Variable : A(10);
> 
> What size (in bytes) do you need to allocate for the variable?  Remember
> that the function Give_String can be exceedingly complex or even a
> function from a shared library.  How do you at compile time determine
> the size of that record type?

There's more to it than that. Consider

type R (L : Positive) is record
    S : String (1 .. L);
end record;

V : R (L => Some_Function);

This is valid Ada, but the compiler cannot tell the size in bytes to allocate 
for V. However, the compiler can generate code to determine the size at run time.

In its most basic form, this concept is

type R is record
    S : String := Some_Function;
end record;

V : R;

which is not much different from the valid declaration

S : String := Some_Function;

so it seems to me that the invalid form could be allowed. The latter declaration 
was invalid in Ada 83; on more than one occasion I wrote

C : constant String := Some_Function;
S : String (C'range) := C;

to get around this restriction (and hoped the compiler would be smart enough to 
see that there were no other references to C, and not keep 2 copies of the value).

-- 
Jeff Carter
"Have you gone berserk? Can't you see that that man is a ni?"
Blazing Saddles
38

Re: why "unconstrained subtype in component declaration" while said component given default value ?

[Shark8]

On Saturday, May 26, 2018 at 3:03:23 PM UTC-6, Mehdi Saada wrote:
> Hello.
> Why is this case not allowed ? Is there really an implementation issue here ? I doubt so. Why should it be any different from the non-issue of initializing variables of unconstrained subtypes vs declaring uninitialized variables of constrained subtypes ?
>  type A (N: Positive) is record
>       II : Integer;
>       Chaine : String := Give_String(N);
>    end record;

It is allowed; try:
  type A (N: Positive) is record
       II : Integer;
       Chaine : String(1..N) := Give_String(N);
    end record;
(This assumes the output-size of Give-string is length N.)

> 
> Also, there's something that would be really cool, and I'm curious why it could not be allowed: Why can't we provide a private constrained subtype, of an inconstrained private type ?
> 
> package III is
>    type A (<>) is private;
>    subtype B is A;  -- should be a constrained subtype
> private
>    function Donne_String (N : Positive) return String;
>    type A (N: Positive) is record
>       II : Integer;
>       Chaine : String(1..N) := Give_String(N);
>    end record;
> end III;

What's the use-case for this?

Re: why "unconstrained subtype in component declaration" while said component given default value ?

[Simon Wright]

Mehdi Saada <00120260a@gmail.com> writes:

> Also, there's something that would be really cool, and I'm curious why
> it could not be allowed: Why can't we provide a private constrained
> subtype, of an inconstrained private type ?
>
> package III is
>    type A (<>) is private;
>    subtype B is A;  -- should be a constrained subtype
> private
>    function Donne_String (N : Positive) return String;
>    type A (N: Positive) is record
>       II : Integer;
>       Chaine : String(1..N) := Give_String(N);
>    end record;
> end III;

The Booch Components originally had the maximum length of a bounded
container fixed at generic instantiation, which is a very limiting
design. So as to avoid forcing all users to rework, I ended up with, for
example,

generic
   Maximum_Size : Positive;
package BC.Containers.Collections.Bounded is

   type Unconstrained_Collection
     (Maximum_Size : Positive) is new Abstract_Collection with private;

   subtype Collection
      is Unconstrained_Collection (Maximum_Size => Maximum_Size);

[...]

   function "=" (Left, Right : in Unconstrained_Collection) return Boolean;

[...]

   procedure Insert (C : in out Unconstrained_Collection; Elem : Item);
   --  Add the item to the front of the collection.

Re: why "unconstrained subtype in component declaration" while said component given default value ?

[Shark8]

On Sunday, May 27, 2018 at 1:07:08 AM UTC-6, Simon Wright wrote:
> 
> The Booch Components originally had the maximum length of a bounded
> container fixed at generic instantiation, which is a very limiting
> design.

I can see the merits for it though.
  Package Small_Stack is new Stack(Element => Integer, Maximum => 2**4);
  Package Large_Stack is new Stack(Element => Integer, Maximum => 2**10);

  LS : Large_Stack.Stack;
  SS : Small_Stack.Stack;

These /should/ be different and incompatible types 98% of the time; the times they shouldn't are usually some form of low-level work OR some form of generic-thinking in a dynamic environment... and the last one is solvable w/ tagged-type/interface versions.

Re: why "unconstrained subtype in component declaration" while said component given default value ?

[Mehdi Saada]

Thanks Simon and Jeffrey. You just gave both of my points some legitimacy.

Re: why "unconstrained subtype in component declaration" while said component given default value ?

[Randy Brukardt]

"Mehdi Saada" <00120260a@gmail.com> wrote in message 
news:a1c9fe86-bc14-48ee-bb64-24e40ae2b7e2@googlegroups.com...
> Thanks Simon and Jeffrey. You just gave both of my points some legitimacy.

Unfortunately, there would be major problems with access constraints 
(probably the worst idea overall in Ada 83, but we're obviously stuck with 
them). And access-to-specific-tagged works the same way.

There's also an issue of implementation complexity: most Ada compiler use 
fixed size allocation for all composite objects in order to avoid implicit 
heap use (not allowed by many safety-critical customers). It's not possible 
to graft in arbitrary dynamic components in that case (recall that with a 
stand-alone object that there can only be a single dynamic thing. How does 
such a compiler deal with:

    type Nasty is record
      A : String := Some_Funct (...);
      B : String := Some_Funct (...);
      C : String := Some_Funct (...);
   end record;

or worse:
    type Arr is (Positive range <>) of String;
    X : Arr := (1 .. Some_Other_Func(...) => Some_Funct (...));

The line has to be drawn somewhere for fixed allocations, and that was done 
at the stand-alone object boundary.

                                            Randy.