Re: Why can't objects be static in Ada?

["Randy Brukardt" <randy@rrsoftware.com>]

"Lucretia" <laguest9000@googlemail.com> wrote in message 
news:322de0e0-9b7c-478f-be70-4d0f88c74d6d@googlegroups.com...
On Thursday, 11 April 2019 23:49:07 UTC+1, Randy Brukardt  wrote:
> "Lucretia" <> wrote in message
> news:b411a770-5e86-4d5e-9e43-e52843be724d@googlegroups.com...
>> > Someone sent in a pull request to my bindings and had to change a few
>> >constants to functions because objects can't be static.
>>
>> This is nonsense:
>
>What bollocks.

Relax and take a deep breath. You're usually a sensible person here, and you 
ought to be able to handle being told you are confused.

...
>Wrong, if something can be compiled to be static so that there's no
>elaboration code, then that's a good thing, ...

This is my point, you're extremely confused about what "static" means in 
Ada. There's no such thing as "compiled as static", that's nonsense.

Let's start at the beginning. "Static" is a property of various kinds of 
entities (most importantly, expressions), primarily for the purposes of 
Legality Rules, but it also has requirements on accuracy, compile-time 
checks (which are wrong, BTW, but can't be fixed as some people are worried 
about the impression of going to more runtime checks in this case).

Static says nothing about the generated code, in large part because no 
programming language standard can say anything useful about generated code. 
A programming language standard describes a syntax and an abstract 
semantics, but implementations can use any method they want to implement 
those semantics.

We talk about issues like compile-time evaluation of things as 
implementation quality issues. They don't belong in a language definition, 
in part because there is a wide variation in uses of implementations and 
implementation quality is surely not "one-size-fits-all".

Another reason that we don't worry about implementation quality is that 
implementers surely don't make their implementation bad for no reason. We 
don't worry about implementers using recursive addition, or doing a 
rendezvous to implement multiplies, or generating lots of code when little 
would do, because no one is going to do that just to be contrary. Any 
limitations of an implementation are going to be there for good reasons 
(cost of development of course being a reason), and in any case, issues that 
cause problems for customers will disappear soon (or the customers will).

I think all Ada compilers do at least some nonstatic compile-time expression 
evaluation. Janus/Ada certainly does. What is done has nothing whatsoever to 
do with the Standard, and that wouldn't change if more words were added to 
the Standard. Actually, it might do *less* in such a case, because the 
Standard would prescribe a set of rules, and it would be too expensive to 
have a second implementation of those rules to handle the many things that 
they don't cover. So it could be actually harmful to some implementations to 
have such rules.

The Ada Standard does have a few pieces of nonsense that claim to constrain 
generated code (like C.4). But such wording has to be so imprecise that one 
can still pretty much ignore it and still meet the letter of the rules. 
That's not really helping anything. Hopefully, we're not adding more such 
stuff, as it cannot be tested with the ACATS or by any other portable 
method. So, for practical purposes it is ignorable anyway (much like 
documentation requirements).

As I discussed last time, there do exist cases where a more expansive 
definition of "static" in Ada would eliminate some annoyances. But that does 
not appear to have anything to do with your problem.

Since you never showed the code that was getting the error message, I don't 
know if the problem is one the language could help with or not. But there 
aren't many places in the language where "static" is required.

                                             Randy.