System.Address'Size - not a static integer expression?

System.Address'Size - not a static integer expression?

[Vadim Godunko]

Hello,

I some type like this:

1  with System;
2
3  package A is
4
5     type T is private;
6
7  private
8
9     type T is record
10       P : System.Address := System.Null_Address;
11    end record;
12    for T'Size use System.Address'Size;
13
14 end A;

GNAT compiler report:
a.ads:12:33: static integer expression required here

Is this a compiler bug?

Thanks,
Vadim Godunko.

Re: System.Address'Size - not a static integer expression?

[Robert Dewar]

vgodunko@vipmail.ru (Vadim Godunko) wrote in message news:<665e587a.0203060957.3682edf7@posting.google.com>...
> Hello,
> GNAT compiler report:
> a.ads:12:33: static integer expression required here
> 
> Is this a compiler bug?

No, it is a correct diagnostic, this is not a static
expression.

Re: System.Address'Size - not a static integer expression?

[Wes Groleau]

> > a.ads:12:33: static integer expression required here
> >
> > Is this a compiler bug?
> 
> No, it is a correct diagnostic, this is not a static
> expression.

Vadim, I had the same misunderstanding at one time,
so perhaps I can clarify:

The 'Size attribute, even though "static" in nature
much of the time is officially defined as non-static
in the RM, and therefore not allowed where a "static"
value is required.

In other words, compilers are required to pretend
that they don't know the value of 'Size at compile
time.  Sometimes the value is known, sometimes not,
so it's simpler to pretend it's always unknown.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: System.Address'Size - not a static integer expression?

[FGD]

Wes Groleau <wesgroleau@despammed.com> wrote in message news:<3C877185.1CF93423@despammed.com>...
> > > a.ads:12:33: static integer expression required here
> > >
> > > Is this a compiler bug?
> > 
> > No, it is a correct diagnostic, this is not a static
> > expression.
> 
> Vadim, I had the same misunderstanding at one time,
> so perhaps I can clarify:
> 
> The 'Size attribute, even though "static" in nature
> much of the time is officially defined as non-static
> in the RM, and therefore not allowed where a "static"
> value is required.
> 
> In other words, compilers are required to pretend
> that they don't know the value of 'Size at compile
> time.  Sometimes the value is known, sometimes not,
> so it's simpler to pretend it's always unknown.


I've wondered about this in the past, I can't remember any "official"
justification for this. Why does the RM say it's not static? It
requires static expression when defining it. Only unconstrained types
can have non-static 'Size. (Am I missing something?) Maybe it's a
language simplification, but a very inconvenient one...

-- Frank

Re: System.Address'Size - not a static integer expression?

[Larry Kilgallen]

In article <7f1fa3aa.0203081034.12a7bd11@posting.google.com>, presbeis@look.ca (FGD) writes:

> I've wondered about this in the past, I can't remember any "official"
> justification for this. Why does the RM say it's not static?

Typically the RM does not explain "why".  If anything explains "why" it
would more likely be the Rationale or the Annotated RM (for implementors).

Re: System.Address'Size - not a static integer expression?

[Wes Groleau]

> I've wondered about this in the past, I can't remember any "official"
> justification for this. Why does the RM say it's not static? It
> requires static expression when defining it. Only unconstrained types
> can have non-static 'Size. (Am I missing something?) Maybe it's a

There's the justification:  'Size is sometimes non-static,
and requiring a compiler to distinguish when imposes too much
complexity.  Allowing a compiler to distinguish when would
lead to too much non-portability.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: System.Address'Size - not a static integer expression?

[Robert Dewar]

Wes Groleau <wesgroleau@despammed.com> wrote in message news:<3C891463.C4C09795@despammed.com>...
> 
> There's the justification:  'Size is sometimes 
> non-static, and requiring a compiler to distinguish when 
> imposes too much complexity.

No, this is quite wrong (and there is quite a bit of
misinformation in this thread).

First, it is not correct that 'Size is always non-static.
As is quite clear from RM 4.9

    7  an attribute_reference that denotes a scalar value, 
       and whose prefix denotes a static scalar subtype;

any application of 'Size to a static scalar subtype is
indeed static.

So, how come size of other types is never static. It does
NOT have to do with distinguishing constant and dynamic
cases -- that's trivial and has to be done anyway.

What is important to realize is that laying out composite
types is non-trivial, highly target dependent, and likely
to be done by the target back end of a compiler. It would
be a pain if this processing had to be done early on in the
front end.

Re: System.Address'Size - not a static integer expression?

[Wes Groleau]

> > There's the justification:  'Size is sometimes
> > non-static, and requiring a compiler to distinguish when
> > imposes too much complexity.
> 
> No, this is quite wrong (and there is quite a bit of
> misinformation in this thread).
> 
> First, it is not correct that 'Size is always non-static.
> As is quite clear from RM 4.9

I said "sometimes" NOT "always"

>     7  an attribute_reference that denotes a scalar value,
>        and whose prefix denotes a static scalar subtype;
> 
> any application of 'Size to a static scalar subtype is
> indeed static.
> 
> So, how come size of other types is never static. It does
> NOT have to do with distinguishing constant and dynamic
> cases -- that's trivial and has to be done anyway.

I'll take your word for that, but the last time both Apex
and GNAT rejected a 'Size that I knew was static (in the
sense that it traced to a constant at compile time) I found
something in the RM that basically insisted that 
'Size is non-static.

Perhaps I'll have time to hunt that down again this week.
(Don't hold your breath)


-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: System.Address'Size - not a static integer expression?

[Robert Dewar]

Wes Groleau <wesgroleau@despammed.com> wrote in message news:<3CB1B473.CF6E93AD@despammed.com>...

> > > There's the justification:  'Size is sometimes
> > > non-static, and requiring a compiler to distinguish 
> > > when imposes too much complexity.

I assumed you meant by non-static here: not known at compile time
(otherwise the statement is nonsense, of COURSE an Ada compiler must
distinguish between static and
non-static expressions in the formal sense.

Also, you were replying to a message that said that 
Size was always non-static, and giving an (incorrect)
justification for this (incorrect) claim.

> I'll take your word for that, but the last time both Apex
> and GNAT rejected a 'Size that I knew was static (in the
> sense that it traced to a constant at compile time)

Please please do not misuse static in this way. An expression in Ada
is static if it meets the rules of
section 4.9. This is NOT the same as being able to
"trace to a constant at compile time". For example

    type r is record a : integer; end record;
    for r'size use 4;

Now of course we know at compile time that R'Size has
the value of 4, but please do NOT call it static, since
R'Size here is a non-static expression. Why? Because the
rules in 4.9 say that an attribute reference of this type
is static if an only if it applies to a static scalar
subtype (I quoted the rule in my previous post). 
    
> I found something in the RM that basically insisted that 
> 'Size is non-static.

Well since you are confused over what static means, I doubt
this memory is relevant. Once again, while it is true that
all static expressions have known-at-compile time values,
the converse is obviously false (known at compile time values are not
always static).

Why? Because it is obviously recursively undecidable whether a given
expression has a known at compile time
value (finding all such expressions requires being able
to prove all possible theorems which of course is not
possible). So the language had two choices:

 o Try to pin down a subset of known at compile time
   expressions and require all compilers to agree on
   this subset in cases where staticness of expressions
   has semantic significance (e.g. case tags).

 o Allow this set to be implementation defined, meaning
   that the legality (e.g. of case statements) would also
   be implementation defined.

Not hard to make a choice! Ada 83 and Ada 95 both chose the first
path, and that is what the rules in 4.9 are about (Ada 95 increased
the set of static expressions slightly).

So most certainly GNAT and Apex (and any other correct Ada compiler)
agree on what Size references are static and what
are not. If the prefix is a static scalar subtype, the size
reference is static, otherwise it is non-static. End of
story, and the fact that Wes can figure out that some particular
non-static case is in fact known at compile time
is not interesting or relevant.

In fact any decent Ada compiler will have internally a class of
expressions larger than static expressions which are recognized as
known at compile time.

Indeed I just did a significant enhancement to GNAT that
increases the number of such cases by doing value tracking.
Consider the following output from the latest development
version of GNAT Pro:

 1. procedure z is
 2.    x : integer;
 3.    y : integer range 3 .. 6;
 4. begin
 5.    x := 3;
 6.    x := x + 4;
 7.    y := x;
            |
 >>> warning: value not in range of subtype of         
     "Standard.Integer" defined at line 3
 >>> warning: "Constraint_Error" will be raised at run time
 8. end;


The warning comes from the fact that the expression x in
line 7, while most *certainly* not static, is in fact a
compile time known value (the value is 7), and the compiler can issue
a warning.


> 
> Perhaps I'll have time to hunt that down again this week.
> (Don't hold your breath)

Re: System.Address'Size - not a static integer expression?

[Wes Groleau]

> > I found something in the RM that basically insisted that
> > 'Size is non-static.
> 
> Well since you are confused over what static means, I doubt
> this memory is relevant. Once again, while it is true that

Static to me (before Ada 95) meant a value that you can determine
at compile time.  The RM apparently has a different meaning when
it disallowed 
   for xxx'size use ....   (A)
because 'size is not static

The screwed up C definition of static is off in some other planet.

What I was saying was that I tried to use  xxx'size somewhere
that only static values were allowed and it was rejected by both
GNAT and Apex.  At the time, I considered the expression I used
static because it COULD BE determined at compile time.  But
I DID find something in the RM that said 'Size cannot be used
where a static expression is required.

> all static expressions have known-at-compile time values,
> the converse is obviously false (known at compile time values are not
> always static).
> 
> Why? Because it is obviously recursively undecidable whether a given
> expression has a known at compile time
> value (finding all such expressions requires being able
> to prove all possible theorems which of course is not
> possible). So the language had two choices:
> 
>  o Try to pin down a subset of known at compile time
>    expressions and require all compilers to agree on
>    this subset in cases where staticness of expressions
>    has semantic significance (e.g. case tags).

My point exactly:  'Size is not in this subset, no matter
how easy it may be to determine the value.

> So most certainly GNAT and Apex (and any other correct Ada compiler)
> agree on what Size references are static and what
> are not. If the prefix is a static scalar subtype, the size
> reference is static, otherwise it is non-static. End of

So you are saying that it IS in this subset
if the prefix is a static scalar subtype?

First, this is circular, defining static (partially)
in terms that use the word static.

Second, I can no longer remember whether it was a static
scalar subtype, but I do remember (1) the rejection surprised
me after years of Ada experience and (2) the reference _I_
found for (A) above did not have the "static scalar subtype"
exception in it. It just plain said that 'Size is not static.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: System.Address'Size - not a static integer expression?

[Darren New]

Wes Groleau wrote:
> So you are saying that it IS in this subset
> if the prefix is a static scalar subtype?
> 
> First, this is circular, defining static (partially)
> in terms that use the word static.

It's not circular. It's recursive. There's no loop involved, because
every time you take the prefix of an expression, you get a shorter
expression, so eventually you wind up with a prefix that doesn't involve
'size.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
      Remember, drive defensively if you drink.

Re: System.Address'Size - not a static integer expression?

[Robert Dewar]

Wes Groleau <wesgroleau@despammed.com> wrote in message news:<3CB47947.466E0E81@despammed.com>...

> Static to me (before Ada 95) meant a value that you can 
> determine at compile time.  The RM apparently has a 
> different meaning when it disallowed 

>    for xxx'size use ....   (A)

> because 'size is not static

The term static is a technical term in both Ada 83 and Ada 95 that
refers to *subset* of expressions whose value an
be determined at compile time. Obviously the predicate "can
determine at compile time" is recursively undecidable, so
you can't really mean what you said above, and in any case
it is just wrong. There are plenty of expressions whose 
value can obviously be determined at compile time which
are definitely NOT static.

For example, if we write

    s,t : float := ...
    type f is new float range s .. t;

then the expression

    f'digits

is not static, even though it is obvious that has the same
value as float'digits, which *is* static. Why? Because attributes are
static only if applied to a static scalar
subtype, which f is obviously NOT (this rule is identical
in Ada 83 and Ada 95).

Could the rule have been written to allow this particular
expression? Sure, but the point is that the boundary is
going to be arbitrary anyway, so it is easier to have a 
simple set of rules, even if they do rule out some cases
which are obviously determinable at compile time.

> The screwed up C definition of static is off in some 
> other planet.

This comment is from left field, since the meaning of the
keyword static in C is something completely and radically
different that has nothing at all to do with the discussion at hand of
static expressions in Ada.
 
> What I was saying was that I tried to use  xxx'size 
> somewhere that only static values were allowed and it was 
> rejected by both GNAT and Apex.

Yes, because the expression was not static according to
the 4.9 rules (of either RM!)

> At the time, I considered the expression I used
> static because it COULD BE determined at compile time.

Fine, but that was a misunderstanding, static does NOT
mean "COULD BE determined at compile time.

> But I DID find something in the RM that said 'Size cannot 
> be used where a static expression is required.

No you didn't, because there is no such rule. The actual
rule is that 'Size is static if applied to a static scalar
subtype, and otherwise is not static. But you won't find
a rule in the RM that says that Size applied to a non-scalar type or a
non-static scalar type is non-static.
Why not? Because 4.9 is a list of rules for expressions
that *are* static. All expressions not listed in these
rules are implicitly non-static, without having to say so.
 
> My point exactly:  'Size is not in this subset, no matter
> how easy it may be to determine the value.

You keep saying this, but it's wrong. Some 'Size references
are static, Some are not, and the distinction is not whether they can
be determined at compile time, it is
whether the type involved is a non-static scalar type.
 
> So you are saying that it IS in this subset
> if the prefix is a static scalar subtype?

Yes :-) several times
 
> First, this is circular, defining static (partially)
> in terms that use the word static.

It is a perfectly sound recursive definition. There is no
problem here, and I don't see why you are suggesting there
might be. The definition of static scalar subtype is in
RM 4.9(26) and seems clear enough.

It is definitely the case that the definition of staticness
is recursive. For example a+b is a static expression if
a and b are static expressions. Nothing circular about that was of
defining things!

> Second, I can no longer remember whether it was a static
> scalar subtype, but I do remember (1) the rejection 
> surprised me after years of Ada experience

We can all be surprised by discovering something we did
not know, but that does not make it wrong :-)

>  and (2) the reference _I_
> found for (A) above did not have the "static scalar
> subtype" exception in it. It just plain said that 'Size 
> is not static.

Well then this reference is (a) not in the RM, and (b) completely
wrong. Nothing too surprising about that. Perhaps you read this on CLA
:-) :-)

Re: System.Address'Size - not a static integer expression?

[Wes Groleau]

> > At the time, I considered the expression I used
> > static because it COULD BE determined at compile time.
> 
> Fine, but that was a misunderstanding, static does NOT
> mean "COULD BE determined at compile time.

In the Ada RM it doesn't.  But to a lot of people
(and formerly, to me) that's what it meant.

> > But I DID find something in the RM that said 'Size cannot
> > be used where a static expression is required.
> 
> No you didn't, because there is no such rule. The actual
> rule is that 'Size is static if applied to a static scalar
> subtype, and otherwise is not static. But you won't find
> a rule in the RM that says that Size applied to a non-scalar type or a
> non-static scalar type is non-static.

It wasn't in 4.9  For me to prove I'm right, I'd have to
find it again, which would be hard.  For you to prove I'm
wrong, you'd have to make me read every paragraph in the RM
and agree it isn't in there, which would be even harder.
So I think we should drop it.

> > So you are saying that it IS in this subset
> > if the prefix is a static scalar subtype?
> 
> Yes :-) several times

If that's true, both GNAT and Apex were wrong to reject
the code I was speaking of.  And I severely misinterpreted
the RM passage that seemed to justify the rejection.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: System.Address'Size - not a static integer expression?

[Robert Dewar]

Wes Groleau <wesgroleau@despammed.com> wrote in message news:<3CB74D37.973A4C19@despammed.com>...

> In the Ada RM it doesn't.  But to a lot of people
> (and formerly, to me) that's what it meant.

Only very casually, because, as I noted before "known at
compile time" is obviously a recursively undecidable
predicate, and if you think for a moment, you know that
no language feature could be based on a RU predicate.

> It wasn't in 4.9  For me to prove I'm right, I'd have to
> find it again, which would be hard.  For you to prove I'm
> wrong, you'd have to make me read every paragraph in the 
> RM and agree it isn't in there, which would be even 
> harder. So I think we should drop it.

Not with you leaving FUD on this issue. I know the RM well
in this area, and can assure you that you did not find what
you remember. Given your confusion on the meaning of static
I would say that you should hesitate to trust your memory
here. Once again, it is of COURSE the case that 'Size is
sometimes static, and sometimes non-static. There is no
statement in the RM that contradicts this, and if there
were such a statement, it would be an obvious (and very
visible mistake), so the fact that no one has pointed out
such a mistake in the ongoing review process should really
help to convince you that your memory is faulty here.

> > > So you are saying that it IS in this subset
> > > if the prefix is a static scalar subtype?
> > 
> > Yes :-) several times
> 
> If that's true, both GNAT and Apex were wrong to reject
> the code I was speaking of.  And I severely 
> misinterpreted the RM passage that seemed to justify the 
> rejection.

No, the type in question was not a static scalar subtype!
If you still don't understand this, reread the definition 
in 4.9.

Re: System.Address'Size - not a static integer expression?

[Robert Dewar]

Wes Groleau <wesgroleau@despammed.com> wrote in message news:<3CB74D37.973A4C19@despammed.com>...
> If that's true, both GNAT and Apex were wrong to reject
> the code I was speaking of. 

Just to clarify here: the type in question was a *RECORD*
type, surely you cannot think that *any* record type can
possibly qualify as a static *scalar* subtype :-)

GNAT and Apex were right to reject this, and I must say
I find this a very drawn out thread for a relatively simple
semantic issue.

Re: System.Address'Size - not a static integer expression?

[Wes Groleau]

> > If that's true, both GNAT and Apex were wrong to reject
> > the code I was speaking of.
> 
> Just to clarify here: the type in question was a *RECORD*
> type, surely you cannot think that *any* record type can
> possibly qualify as a static *scalar* subtype :-)

I do not recall ever posting that it was a record
type.  Just that it was rejected and that I found
(or my faulty memory says I found) something saying
'Size was non-static.  The same memory does not think
it was a record type.

'Size DOES return a scalar.  Therefore, if the prefix
is static and non-scalar, 4.9 (7) says 'Size on it is
static.  That does not prove no other paragraph says
otherwise.  You say no, and you are a generally reliable
source.  I do not have the time to look for proof that
my memory is not as faulty as you say.  For now, I have
no doubt or uncertainty, and certainly no fear.  So perhaps
FUD is the wrong term.  In any case I still think we should
it and _I_ am doing so.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: System.Address'Size - not a static integer expression?

[Randy Brukardt]

Wes Groleau wrote in message <3CBAEE01.D17C2DB0@despammed.com>...
>'Size DOES return a scalar.  Therefore, if the prefix
>is static and non-scalar, 4.9 (7) says 'Size on it is
>static. That does not prove no other paragraph says
>otherwise.  You say no, and you are a generally reliable
>source.

The only non-scalar subtype that can be static is a string subtype.
That's rare enough that it can be ignored. So, for practical purposes,
'Size is static only for prefixes of static scalar subtypes (which are
most scalar subtypes).

            Randy.

Re: System.Address'Size - not a static integer expression?

[Robert Dewar]

"Randy Brukardt" <randy@rrsoftware.com> wrote in message news:<ubmc5dgvl8toba@corp.supernews.com>...
 

> The only non-scalar subtype that can be static is a  
> string subtype. That's rare enough that it can be 
> ignored. So, for practical purposes, 'Size is static only 
> for prefixes of static scalar subtypes (which are
> most scalar subtypes).

Oh oh! Now the Ada experts *are* getting confused :-) :-)

Randy, 'Size of a static string subtype is NOT static.
Don't you get confused by Wes misreading of para 7, which
clearly only applies to static *scalar* subtypes.

What are the design principles here?

Basically we only want sizes to be static if the front end
can easily determine them and if they are generally target
independent (the generally here is qualified by the fact that of
course types like Integer are target dependent and
yet Integer'Size is static -- the point being that the dependence here
is not on the compilers treatment of data
layout, but rather on the details of the type declaration).

We definitely do NOT want 'Size applied to a static string
subtype to be static, since in general arrays and records are layed
out by the back end of a compiler in a target dependent manner.

Note that the fact that para 7 says "static scalar subtype"
and not "static subtype" is not an accident, it is very
deliberate :-)

A long and rather involved thread for a not too complex
point, but probably it has some useful byproducts. For sure
I hope no one reading this thread will confuse the technical term
static (expression/subtype etc) with the
informal notion of known-at-compile-time.

Second, it is instructive to see how important it is to read the RM
carefully, and to realize that the language
must be read being alert to the use of technical terms
that are elsewhere defined in the RM.

Re: System.Address'Size - not a static integer expression?

[Robert Dewar]

Wes Groleau <wesgroleau@despammed.com> wrote in message news:<3CBAEE01.D17C2DB0@despammed.com>...

> I do not recall ever posting that it was a record
> type.  Just that it was rejected and that I found
> (or my faulty memory says I found) something saying
> 'Size was non-static.  The same memory does not think
> it was a record type.

Well this thread was started by a note about a record type.
We really can't deal with Wes' vague memory that there was
a problem with a 'Size reference that he is sure APEX and
GNAT were wrong to reject, but he can't remember exactly
what it was :-)

> 'Size DOES return a scalar.  Therefore, if the prefix
> is static and non-scalar, 4.9 (7) says 'Size on it is
> static.

No, that's not what 4.9(7) says (let's have it again): 

    7  an attribute_reference that denotes a scalar value, 
       and whose prefix denotes a static scalar subtype;

I don't see why you have trouble reading this, it clearly
applies ONLY to static scalar subtypes, and thus does NOT
apply if the prefix denotes a static non-scalar subtype
(the only case of this is a static string subtype and indeed 'Size
applied to such a subtype is not static:

    1. package t is
    2.    subtype r is string (1 .. 10);
    3.    a : constant := r'size;
                           |
       >>> non-static expression used in number declaration
    4. end;

This diagostic from GNAT is indeed correct.

> That does not prove no other paragraph says
> otherwise.  You say no, and you are a generally reliable
> source.  I do not have the time to look for proof that
> my memory is not as faulty as you say.

Whether you have time or not is irrelevant, there is no
such proof, so you will just be wasting your time looking
for it. The principles behind this design are quite clear
so there are no surprised in the interpretation I am
clarifying here. What would be MOST surprising is if 
there *were* a statement corresponding to your memory,
since it is obviously evident that such a statement would
be in error, given the fundamental design criteria for
the language here.

> For now, I have
> no doubt or uncertainty, and certainly no fear.  So 
> perhaps FUD is the wrong term.

FUD is not what you feel, it is the impression that may
be created (gee Ada experts disagree on what the rules of
static expressoins are ...). Well they don't disagree, the
rules are clear and it is important for Ada programmers
to know and understand these rules :-)

Re: System.Address'Size - not a static integer expression?

[Wes Groleau]

> > 'Size DOES return a scalar.  Therefore, if the prefix
> > is static and non-scalar, 4.9 (7) says 'Size on it is
> > static.
> 
> No, that's not what 4.9(7) says (let's have it again):

You're right.  Typo.  Let me try again:

> > 'Size DOES return a scalar.  Therefore, if the prefix
> > is static and scalar, 4.9 (7) says 'Size on it is
> > static.

> Whether you have time or not is irrelevant, there is no
> such proof, so you will just be wasting your time looking
> for it. The principles behind this design are quite clear

I won't be wasting my time because I am confident
I saw what I saw.  Of course, I could be wrong (see below)
but I don't think so.  However, proving it (or trying to)
is not worth the trouble.  If I find it, we have an inconsistency
and we fix the RM.  If I'm don't find it, I still haven't proven
it doesn't exist.  Neither option has any effect on what a
compiler will or won't accept.

> clarifying here. What would be MOST surprising is if
> there *were* a statement corresponding to your memory,
> since it is obviously evident that such a statement would
> be in error, given the fundamental design criteria for

You would find it surprising if there were a statement
in error in the RM?  Weren't most of the statements in
the RM written by humans?

Isn't one of the reasons for Ada the fact that humans
commit errors?

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: System.Address'Size - not a static integer expression?

[Robert Dewar]

Wes Groleau <wesgroleau@despammed.com> wrote in message news:<3CBDBE76.F4FF3905@despammed.com>...

> You would find it surprising if there were a statement
> in error in the RM?  Weren't most of the statements in
> the RM written by humans?

I would be more than surprised, I would be astounded. It is
not an error that anyone would make who knew what was going
on, and it is an error that would be so obvious as to be
immediately caught (in particular, I looked very carefully
at everything that was said about Size). Furthermore, checking
every reference to Size in the RM yields nothing remotely like
your memory.

So here's the bottom line:

Robert, who helped write and review this manual is quite certain
there is no statement about this (furthermore Robert has never
been confused as to the meaning of static). Furthermore if there
were any such statement, it would be clearly and obviously wrong
to anyone understanding the meaning of static expression.

Wes insists on his memory, but cannot and/or will not provide
any evidence. Furthermore, he admits that he was seriously
confused about the meaning of static (my best guess is that
Wes saw something about the value of Size being dynamic, and
since at that time he thought that static was the opposite of
dynamic (it is not) he probably got confused :-)

Re: System.Address'Size - not a static integer expression?

[Wes Groleau]

> Wes insists on his memory, but cannot and/or will not provide
> any evidence. Furthermore, he admits that he was seriously
> confused about the meaning of static (my best guess is that

Not really.  I just assumed the common meaning of static
(non-chnging) used in most computer science classes--even
those that teach C which has a REALLY wierd special meaning.
So Ada ever-so-slightly redefines it for convenience.
Nothing wrong with that, but I didn't know way back then.

> Wes saw something about the value of Size being dynamic, and
> since at that time he thought that static was the opposite of
> dynamic (it is not) he probably got confused :-)

Now that is entirely possible.  They are not opposites
in the RM, but they are opposites in general use.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: System.Address'Size - not a static integer expression?

[Robert Dewar]

Wes Groleau <wesgroleau@despammed.com> wrote in message news:<3CC03241.883A6E33@despammed.com>...

> Now that is entirely possible.  They are not opposites
> in the RM, but they are opposites in general use.

Yes, but this general use is fuzzy, since as I pointed out
before, the notion of "known-at-compile-time" is recursively
undecidable. Furthermore, I am not aware of the
specific term static having been used in the context of
any previous language.

It's unusual for a language to give semantic significance
to this notion. In most languages, the compiler is free
to evaluate or not evaluate any expression at compile time
as it pleases.

This is also true in Ada, but a recognized *subset* of
compile time evaluable cases is identified as part of the
language. This allows many things to be checked at compile
time (e.g. completeness of case statements) without having
to limit the case tags to literal constants.

Inevitably, the class of static expressions identified in
the RM *must* be a subset of the expressions that can be
evaluated at compile time. This is not a recognition of
practical necessity, it is a mathematical theorem that can
easily be proved by analogy to the halting problem.

Of course a good Ada compiler will go well beyond this minimal subset
and evaluate many more expressions at compile time, but it is *NOT*
allowed to consider these
to be static in the formal sense.

Re: System.Address'Size - not a static integer expression?

[Robert Dewar]

Wes Groleau <wesgroleau@despammed.com> wrote in message news:<3CC03241.883A6E33@despammed.com>...

> Not really.  I just assumed the common meaning of static
> (non-chnging) used in most computer science classes--even
> those that teach C which has a REALLY wierd special meaning.

Actually the meaning in C is quite simple, it refers to the allocation
mode, so a static variable in C is statically allocated as opposied to
dynamically allocated -- very standard terms of usage. I certainly find
the use of static in C more intuitive from a terminology point of view
than "OWN" in Algol-60.

Re: System.Address'Size - not a static integer expression?

[Darren New]

Robert Dewar wrote:
> Actually the meaning in C is quite simple, it refers to the allocation
> mode, so a static variable in C is statically allocated as opposied to
> dynamically allocated -- very standard terms of usage.

Errr, so "extern" is a special case of "static"?

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
   The 90/10 rule of toothpaste: the last 10% of 
         the tube lasts as long as the first 90%.

Re: System.Address'Size - not a static integer expression?

[Ole-Hjalmar Kristensen]

dewar@gnat.com (Robert Dewar) writes:

> Wes Groleau <wesgroleau@despammed.com> wrote in message news:<3CC03241.883A6E33@despammed.com>...
> 
> > Not really.  I just assumed the common meaning of static
> > (non-chnging) used in most computer science classes--even
> > those that teach C which has a REALLY wierd special meaning.
> 
> Actually the meaning in C is quite simple, it refers to the allocation
> mode, so a static variable in C is statically allocated as opposied to
> dynamically allocated -- very standard terms of usage. I certainly find
> the use of static in C more intuitive from a terminology point of view
> than "OWN" in Algol-60.

Close, but no cigar :-)
I suggest you look up the keyword 'static' in the C standard.

Re: System.Address'Size - not a static integer expression?

[Robert Dewar]

Ole-Hjalmar Kristensen <oleh@vlinux.voxelvision.no> wrote in message news:<7vlmbgks2a.fsf@vlinux.voxelvision.no>...
> dewar@gnat.com (Robert Dewar) writes:
> 
> > Wes Groleau <wesgroleau@despammed.com> wrote in message news:<3CC03241.883A6E33@despammed.com>...
> > 
> > > Not really.  I just assumed the common meaning of static
> > > (non-chnging) used in most computer science classes--even
> > > those that teach C which has a REALLY wierd special meaning.
> > 
> > Actually the meaning in C is quite simple, it refers to the allocation
> > mode, so a static variable in C is statically allocated as opposied to
> > dynamically allocated -- very standard terms of usage. I certainly find
> > the use of static in C more intuitive from a terminology point of view
> > than "OWN" in Algol-60.
> 
> Close, but no cigar :-)
> I suggest you look up the keyword 'static' in the C standard.

Of course I know what static means in C, I am explaining the underlying
intuition of why the word static comes to be used rather than alligator :-)

Re: System.Address'Size - not a static integer expression?

[Ole-Hjalmar Kristensen]

dewar@gnat.com (Robert Dewar) writes:

> Ole-Hjalmar Kristensen <oleh@vlinux.voxelvision.no> wrote in message news:<7vlmbgks2a.fsf@vlinux.voxelvision.no>...
> > dewar@gnat.com (Robert Dewar) writes:
> > 
> > > Wes Groleau <wesgroleau@despammed.com> wrote in message news:<3CC03241.883A6E33@despammed.com>...
> > > 
> > > > Not really.  I just assumed the common meaning of static
> > > > (non-chnging) used in most computer science classes--even
> > > > those that teach C which has a REALLY wierd special meaning.
> > > 
> > > Actually the meaning in C is quite simple, it refers to the allocation
> > > mode, so a static variable in C is statically allocated as opposied to
> > > dynamically allocated -- very standard terms of usage. I certainly find
> > > the use of static in C more intuitive from a terminology point of view
> > > than "OWN" in Algol-60.
> > 
> > Close, but no cigar :-)
> > I suggest you look up the keyword 'static' in the C standard.
> 
> Of course I know what static means in C, I am explaining the underlying
> intuition of why the word static comes to be used rather than alligator :-)

But that is precisely my point. For one of the meanings of 'static' in
C, it could just as well have been 'alligator'. I do not see the
connection between 'static' and 'not extern'. I believe the original
poster also was thinking of these two different, and in my opinion,
uncorrelated meanings.

Re: System.Address'Size - not a static integer expression?

[Robert Dewar]

Ole-Hjalmar Kristensen <oleh@vlinux.voxelvision.no> wrote in message news:<7vlmbgks2a.fsf@vlinux.voxelvision.no>...
> dewar@gnat.com (Robert Dewar) writes:
 
> Close, but no cigar :-)
> I suggest you look up the keyword 'static' in the C standard.

What I was referring to is the use of static for a local variable in
a function as in:

   int x () {
      int y;
      static int z;
      ...

z will be allocated statically, just like an OWN variable in Algol-60.
This is certainly a useful capability in some form (and indeed we often
see as an FAQ in CLA "is there an equivalent of static in Ada" [canonical
answer "yes, use package body variables" [this actually should be "no,
but you can use PB variables to get more or less the same effect -- the
Ada approach lacks the semantics of the Algol-60 OWN or the C static in
that the variable in question has a reach that is greater than the function,
whereas in C/A60, the variable has a scope that is greater, but the reach
is restricted.

I use scope here to talk about the lifetime of the variable, and reach to
refer to the places where it can be referenced.

Yes, I know that the keyword static in C has other uses by extension, which
indeed may be what Wes found confusing, but the above is the fundamental
motivation for the choice of the keyword static in my view.

Re: System.Address'Size - not a static integer expression?

[Ole-Hjalmar Kristensen]

dewar@gnat.com (Robert Dewar) writes:

> Ole-Hjalmar Kristensen <oleh@vlinux.voxelvision.no> wrote in message news:<7vlmbgks2a.fsf@vlinux.voxelvision.no>...
> > dewar@gnat.com (Robert Dewar) writes:
>  
> > Close, but no cigar :-)
> > I suggest you look up the keyword 'static' in the C standard.
> 
> What I was referring to is the use of static for a local variable in
> a function as in:
> 
>    int x () {
>       int y;
>       static int z;
>       ...
> 
> z will be allocated statically, just like an OWN variable in Algol-60.
> This is certainly a useful capability in some form (and indeed we often
> see as an FAQ in CLA "is there an equivalent of static in Ada" [canonical
> answer "yes, use package body variables" [this actually should be "no,
> but you can use PB variables to get more or less the same effect -- the
> Ada approach lacks the semantics of the Algol-60 OWN or the C static in
> that the variable in question has a reach that is greater than the function,
> whereas in C/A60, the variable has a scope that is greater, but the reach
> is restricted.
> 
> I use scope here to talk about the lifetime of the variable, and reach to
> refer to the places where it can be referenced.
> 
> Yes, I know that the keyword static in C has other uses by extension, which
> indeed may be what Wes found confusing, but the above is the fundamental
> motivation for the choice of the keyword static in my view.

Yes, certainly this must have been the original meaning. How they came
to re-use the keyword for 'not externally visible' I don't know.

Re: System.Address'Size - not a static integer expression?

[Jean-Pierre Rosen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 605 bytes --]


"Ole-Hjalmar Kristensen" <oleh@vlinux.voxelvision.no> a �crit dans le message news:
> Yes, certainly this must have been the original meaning. How they came
> to re-use the keyword for 'not externally visible' I don't know.
>
Presumabely to save the burden of a new key-word. Since a global variable is already "static" (in C sense), saying static again
would have not changed anything, so they reused the key-word to mean something else. Sigh....

--
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: System.Address'Size - not a static integer expression?

[Robert Dewar]

Ole-Hjalmar Kristensen <oleh@vlinux.voxelvision.no> wrote in message news:<7v8z7fltkz.fsf@vlinux.voxelvision.no>...
 
> Yes, certainly this must have been the original meaning. 
> How they came to re-use the keyword for 'not externally 
> visible' I don't know.

It's not so far-fetched. The analogy works like this. In
functions, static means something that has global scope
but whose reach is limited to the enclosing syntactic
construct.

Well that's exactly the same meaning when static is used
at the file level. The variable has global scope but the
reach is limited to the file.

Re: System.Address'Size - not a static integer expression?

[Nick Roberts]

On 6 Mar 2002 09:57:38 -0800, vgodunko@vipmail.ru (Vadim Godunko) strongly
typed:

>9     type T is record
>10       P : System.Address := System.Null_Address;
>11    end record;
>12    for T'Size use System.Address'Size;

Others will tell you GNAT is correct (this is not allowed).

Perhaps it might be helpful to analyse a little more deeply why you wrote
this code in the first place.

Presumably you wanted to say "I want this type to be the same size as
System.Address". This is apparently a fairly reasonable requirement, since
T only contains a System.Address.

However, think again. If the compiler really needs to put some extra
information into the record, then it needs it, and the 'for T'Size ...'
clause will simply cause the compilation to fail. If the compiler doesn't
need to put any extra information in, it won't!

So, in conclusion, I think that probably you never needed the
representation clause in the first place.

I think it might be fair to suggest that quite often the reason why someone
gets tangled up with a representation clause (or pragma) is because they
are using it inappropriately.

All the best,

-- 
Nick Roberts