rep clause in generics

rep clause in generics

[Jonas Nygren]

I tried to write a small generic package that represents packed arrays of
some element type:

generic
   type Element_Type is private;
package Gen_Buffers is
   type Index_Type  is new Natural;
   type Buffer_Type is array(Index_Type range <>) of Element_Type;

   pragma Pack (Buffer_Type);
   for Buffer_Type'Component_Size use Element_Type'Size; -- line 9
end Gen_Buffers;

The compiler complained with:

   gen_buffers.ads:9:39: static integer expression required here

I thought that Element_Type'Size was a static integer expression. Am I or
the compiler in error?

/jonas

Re: rep clause in generics

[Stephen Leake]

Jonas Nygren wrote:
> 
> I tried to write a small generic package that represents packed arrays of
> some element type:
> 
> generic
>    type Element_Type is private;
> package Gen_Buffers is
>    type Index_Type  is new Natural;
>    type Buffer_Type is array(Index_Type range <>) of Element_Type;
> 
>    pragma Pack (Buffer_Type);
>    for Buffer_Type'Component_Size use Element_Type'Size; -- line 9
> end Gen_Buffers;
> 
> The compiler complained with:
> 
>    gen_buffers.ads:9:39: static integer expression required here
> 
> I thought that Element_Type'Size was a static integer expression. Am I or
> the compiler in error?

Sorry, but you are. Consider:

procedure Non_Static_Instantiation (Length : in Integer)
is
	type String_Index is 1 .. Length;
	subtype Fixed_String is String (String_Index);

	package Fixed_String_Buffers is new Gen_Buffers (Fixed_String);
begin
	...
end;

Element_Type'size is determined by a run-time parameter, so it is NOT
static.

	
> 
> /jonas

-- 
- Stephe

Re: rep clause in generics

[Robert A Duff]

In article <01bc3057$61a78db0$81946482@vkpc131>,
Jonas Nygren <ehsjony@ehs.ericsson.se> wrote:
>The compiler complained with:
>
>   gen_buffers.ads:9:39: static integer expression required here
>
>I thought that Element_Type'Size was a static integer expression. Am I or
>the compiler in error?

You are in error.  S'Size is static only if S is a static scalar
subtype.  Element_Size is neither scalar nor static.  (Generic formal
subtypes are never static.)  See 4.9.

It's sad that you can't do this, I admit.  But allowing it would be
complicated -- generic contract model problems rear their ugly heads.
(As a compiler writer, I find it annoying that 'Size is *ever* static --
it messes up one's compiler design.  You'd like to say 'Size is a
machine-dependent thing, and relegate it to the back end, or some such
late, machine-dependent, phase.  Unfortunately, its value is needed
during overload resolution: e.g.,

    P(Some_Array'First(S'Size mod 2));

Which P is called depends on the static value of S'Size!

)

- Bob

Re: rep clause in generics

[Robert Dewar]

Jonas asks

<<generic
   type Element_Type is private;
package Gen_Buffers is
   type Index_Type  is new Natural;
   type Buffer_Type is array(Index_Type range <>) of Element_Type;

   pragma Pack (Buffer_Type);
   for Buffer_Type'Component_Size use Element_Type'Size; -- line 9
end Gen_Buffers;

The compiler complained with:

   gen_buffers.ads:9:39: static integer expression required here

I thought that Element_Type'Size was a static integer expression. Am I or
the compiler in error?
>>

The compiler is correct, this is obviously NOT a static expression. Remember
a static expression is not an expression which seems to you to be something
that the compiler should be able to evaluate at compile time. There are very
specific rules, and this does not obey them.

So when you say to yourself "I thought that ... was a static expression",
you need to go to the set of rules, and see if they conform to your thought!
In this case they don't, you cannot find a rule that says that this 
expression is static. An expression is non-static unless there is a very
specific rule in the RM that says that it is static.

Re: rep clause in generics

[Robert Dewar]

Robert Duff said

<<(As a compiler writer, I find it annoying that 'Size is *ever* static --
it messes up one's compiler design.  You'd like to say 'Size is a
machine-dependent thing, and relegate it to the back end, or some such
late, machine-dependent, phase.  Unfortunately, its value is needed
during overload resolution: e.g.,>>

Interestingly, with GNAT, we have found that the rules about whether 'Size
is static or not are essentially perfect from the point of view of the
organization of tasks between our front and backend. The frontend has no
trouble knowing what Integer'Size is, but it would be hard for it to
know what Rec'Size was even for a record with a single integer field.
If such sizes were static, we would need a completely different design
which would entangle the front end and backend much more extensively.

But having sizes of simple scalar stuff be known to the front end is no
problem for us. (of course I can certainly see why it might cause toruble
in some other design, but given that all you need is a relatively small
table -- not a complex target dependent algorithm -- to know what the
sizes are of primitive data, i don't see it as a problem.

Re: rep clause in generics

[Robert Dewar]

iJonas said

<<Element_Type'size is determined by a run-time parameter, so it is NOT
static.
>>

That's not the correct way to reason. Whether an expression is static or
not is NOT a question of whether the value is determined at run time or
not. There are lots of examples of values that are known at compile time
but are not static expressions. The rules on static expressions are in
RM 4.9. An expression is static iff the rules in 4.9 say it is static. period.

Now in this case, there is no rule that says this expression is static, but
the reasoning is confusing (for example, by this reasoning, one would expect
that 'Size applied to a digits formal should be static, because certainly
the size is known at compile time, since it is fixed for any particular
instantiation).

But this reasoning is faulty, as 4.9 shows, since x'size is still non-static
for a formal digits type x, since there is no rule that says it is static.

Re: rep clause in generics

[Aaro Koskinen]

dewar@merv.cs.nyu.edu (Robert Dewar) wrote in comp.lang.ada:
> There are lots of examples of values that are known at compile time
> but are not static expressions. The rules on static expressions are
> in RM 4.9. An expression is static iff the rules in 4.9 say it is
> static. period.

Is a function that is actually an enumeration literal (i.e. renamed)
one of these examples? I did check RM, but still wouldn't agree with
GNAT on this one (which says it's non-static). Apparently I have
missed something...
-- 
aaro@iki.fi

Re: rep clause in generics

[Nick Roberts]

Robert Dewar <dewar@merv.cs.nyu.edu> wrote in article
<dewar.858351753@merv>...

> The compiler is correct, this is obviously NOT a static expression.
Remember
> a static expression is not an expression which seems to you to be
something
> that the compiler should be able to evaluate at compile time. There are
very
> specific rules, and this does not obey them.
> 
> So when you say to yourself "I thought that ... was a static expression",
> you need to go to the set of rules, and see if they conform to your
thought!
> In this case they don't, you cannot find a rule that says that this 
> expression is static. An expression is non-static unless there is a very
> specific rule in the RM that says that it is static.

A word of explanation...

The attributes of a type which is a formal generic parameter are not
defined in the standard as being static, and in some compilers may vary
during run-time, because of the different ways in which different compilers
may implement generics.

Whilst most compilers will generate new executable code for each generic
instantiation (thus making the generic parameters within each instance
effectively static), some compilers will not (simply generating one piece
of 'generic' code which is passed generic parameters as if they were
subprogram parameters). Some compilers offer a choice.

If the standard defined formal generic parameters as being static, the
second option would be impossible.

Hope this helps.