Why can't objects be static in Ada?

Why can't objects be static in Ada?

[Lucretia]

Someone sent in a pull request to my bindings and had to change a few constants to functions because objects can't be static. For an example:

   type Sizes is
      record
         Width  : Dimension;
         Height : Dimension;
      end record with
     Convention => C;

   Zero_Size : constant Sizes := (others => Natural_Dimension'First);

Why can't Zero_Size be compiled as static in this pre-elaborated package?

This seems to be a major flaw in Ada imo.

Luke.

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

[Mark Lorenzen]

On Thursday, April 11, 2019 at 2:40:40 PM UTC+2, Lucretia wrote:
> Someone sent in a pull request to my bindings and had to change a few constants to functions because objects can't be static. For an example:
> 
>    type Sizes is
>       record
>          Width  : Dimension;
>          Height : Dimension;
>       end record with
>      Convention => C;
> 
>    Zero_Size : constant Sizes := (others => Natural_Dimension'First);
> 
> Why can't Zero_Size be compiled as static in this pre-elaborated package?
> 
> This seems to be a major flaw in Ada imo.
> 
> Luke.

I don't think it's not an Ada flaw. From an Ada perspective the object is constant - irrespective if it's static (it's value is set at compile-time) or not.

I guess it's compiler-dependent. There are a number of cases where GNAT could be better at generating static objects. This is especially true for objects of a (discriminated) record type.

Try adding "Restrictions (No_Elaboration_Code)" to the spec and see if it forces GNAT into doing what you want to.

Regards,
Mark L

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

[Lucretia]

On Thursday, 11 April 2019 13:56:18 UTC+1, Mark Lorenzen  wrote:
> > Why can't Zero_Size be compiled as static in this pre-elaborated package?
> > 
> > This seems to be a major flaw in Ada imo.
> > 
> > Luke.
> 
> I don't think it's not an Ada flaw. From an Ada perspective the object is constant - irrespective if it's static (it's value is set at compile-time) or not.

Your double negative here makes this hard to understand.
 
> I guess it's compiler-dependent. There are a number of cases where GNAT could be better at generating static objects. This is especially true for objects of a (discriminated) record type.
> 
> Try adding "Restrictions (No_Elaboration_Code)" to the spec and see if it forces GNAT into doing what you want to.

Doesn't like that pragma in the context area or inside the package, inside gnat.adc it's fine, but I get the same error, i.e. non-static.

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

[Randy Brukardt]

"Lucretia" <laguest9000@googlemail.com> 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:

     Max : constant Integer := 10;

is an object, and it's static.

>For an example:
>
>   type Sizes is
>      record
>         Width  : Dimension;
>         Height : Dimension;
>      end record with
>     Convention => C;

This is a composite type. Only numeric types and strings (and the latter is 
a hack) can be static.

>   Zero_Size : constant Sizes := (others => Natural_Dimension'First);
>
> Why can't Zero_Size be compiled as static in this pre-elaborated package?

Because composite types are never static. A compiler that treated it as 
"static" would be wrong. OTOH, that doesn't prevent a compiler from 
evaluating it at compile-time.

And the categorization pragmas are an area where the original scheme was a 
failure. The idea that the properties of every operation of a type can all 
have the same restrictions is maddening. Hopefully, the Global aspect will 
fix this. There's no good reason (outside of Annex E issues) for declaring 
any package preelaborated, unless you like fighting errors a lot. C.4 is a 
load of hooey, it's not actually implementable on the margins, and there's 
no reason for any compiler to generate more code than necessary. Ergo, 
you'll most likely get the same code whether or not you declare something 
Preelaborated, so why bother with all of the hassles?

> This seems to be a major flaw in Ada imo.

"Preelaborated packages" are a minor flaw of Ada, but you never have to use 
them. And if you don't, the rest of it is irrelevant. So I see no "major 
flaw".

That said, I would have preferred allowing the declaration of user-defined 
static types, because it is annoying to write representation clauses as it 
stands. (Since X'Size is only static for numeric types, it's nearly useless 
in representation aspects. Which makes them more complex than necessary. But 
at worst, that is an annoyance.) It was deemed too complicated for too 
little benefit this time around. Feel free to bring it up again if you still 
care and don't mind waiting another 5+ years.

                                            Randy.

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

[Lucretia]

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.

>      Max : constant Integer := 10;
> 
> is an object, and it's static.

I'm not talking about primitive types, I even pointed it out with an actual example. Oh look, there it is...
 
> >For an example:
> >
> >   type Sizes is
> >      record
> >         Width  : Dimension;
> >         Height : Dimension;
> >      end record with
> >     Convention => C;
> 
> This is a composite type. Only numeric types and strings (and the latter is 
> a hack) can be static.

I couldn't care less if it's composite, the language should dictate that something this simple with expressed initial values should be static.

> >   Zero_Size : constant Sizes := (others => Natural_Dimension'First);
> >
> > Why can't Zero_Size be compiled as static in this pre-elaborated package?
> 
> Because composite types are never static. A compiler that treated it as 
> "static" would be wrong. OTOH, that doesn't prevent a compiler from 
> evaluating it at compile-time.

Well, that's wrong and the language should allow composite types, if they can have initial values defined and when constant should be static. It's not hard tp grasp.
 
> And the categorization pragmas are an area where the original scheme was a 
> failure. The idea that the properties of every operation of a type can all 
> have the same restrictions is maddening. Hopefully, the Global aspect will 
> fix this. There's no good reason (outside of Annex E issues) for declaring 

I don't know what the global aspect is but I doubt it'll fix this issue.

> any package preelaborated, unless you like fighting errors a lot. C.4 is a 
> load of hooey, it's not actually implementable on the margins, and there's 
> no reason for any compiler to generate more code than necessary. Ergo, 
> you'll most likely get the same code whether or not you declare something 
> Preelaborated, so why bother with all of the hassles?
> 
> > This seems to be a major flaw in Ada imo.
> 
> "Preelaborated packages" are a minor flaw of Ada, but you never have to use 
> them. And if you don't, the rest of it is irrelevant. So I see no "major 
> flaw".

Wrong, if something can be compiled to be static so that there's no elaboration code, then that's a good thing, why execute anything at runtime if there's no need. Seems you are stuck in backward land where everything should be initialised with code, get a grip and drag your arse into the 21st century!

> That said, I would have preferred allowing the declaration of user-defined 
> static types, because it is annoying to write representation clauses as it 
> stands. (Since X'Size is only static for numeric types, it's nearly useless 
> in representation aspects. Which makes them more complex than necessary. But 
> at worst, that is an annoyance.) It was deemed too complicated for too 
> little benefit this time around. Feel free to bring it up again if you still 
> care and don't mind waiting another 5+ years.

Yeah well, I haven't got another 5+ years to waste waiting for you lot to catch up.

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

[Mark Lorenzen]

On Friday, April 12, 2019 at 12:49:07 AM UTC+2, Randy Brukardt wrote:
> 
> fix this. There's no good reason (outside of Annex E issues) for declaring 
> any package preelaborated, unless you like fighting errors a lot. C.4 is a 
> load of hooey, it's not actually implementable on the margins, and there's 
> no reason for any compiler to generate more code than necessary. Ergo, 
> you'll most likely get the same code whether or not you declare something 
> Preelaborated, so why bother with all of the hassles?

For certification purposes, I think there is a value in avoiding elaboration code.

http://docs.adacore.com/live/wave/gnat_ugx/html/gnat_ugx/gnat_ugx/support_for_certified_systems.html#avoiding-elaboration-code

I had the need to deal with it myself though.

Regards,
Mark L

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

[Dmitry A. Kazakov]

On 2019-04-12 03:56, Lucretia wrote:

> Wrong, if something can be compiled to be static so that there's no elaboration code, then that's a good thing, why execute anything at runtime if there's no need. Seems you are stuck in backward land where everything should be initialised with code, get a grip and drag your arse into the 21st century!

There is a difference between can and must.

Elaboration is a low-level implementation concept. The actual language 
flaw is that there is no way for the programmer to force operations 
compile-time, plus there is no user-defined constructors.

The language tries to work magic where there should be trivial 
programmer's work.

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

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

[Simon Wright]

Mark Lorenzen <mark.lorenzen@gmail.com> writes:

> On Friday, April 12, 2019 at 12:49:07 AM UTC+2, Randy Brukardt wrote:
>> 
>> fix this. There's no good reason (outside of Annex E issues) for
>> declaring any package preelaborated, unless you like fighting errors
>> a lot. C.4 is a load of hooey, it's not actually implementable on the
>> margins, and there's no reason for any compiler to generate more code
>> than necessary. Ergo, you'll most likely get the same code whether or
>> not you declare something Preelaborated, so why bother with all of
>> the hassles?
>
> For certification purposes, I think there is a value in avoiding
> elaboration code.
>
> http://docs.adacore.com/live/wave/gnat_ugx/html/gnat_ugx/gnat_ugx/support_for_certified_systems.html#avoiding-elaboration-code

This is the GNAT-specific No_Elaboration_Code restriction (and pragma
No_Elaboration_Code_All[1]) which I had to apply to the units involved
in setting up the MCU and arranging to run the compiler-generated
elaboration sequence.

[1]: This is a program unit pragma (there is also an equivalent aspect
of the same name) that establishes the restriction No_Elaboration_Code
for the current unit and any extended main source units (body and
subunits). It also has the effect of enforcing a transitive application
of this aspect, so that if any unit is implicitly or explicitly with’ed
by the current unit, it must also have the No_Elaboration_Code_All
aspect set. It may be applied to package or subprogram specs or their
generic versions.

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

[Randy Brukardt]

"Mark Lorenzen" <mark.lorenzen@gmail.com> wrote in message 
news:f572578d-1e73-4b20-b2be-e5b80a8d95b3@googlegroups.com...
> On Friday, April 12, 2019 at 12:49:07 AM UTC+2, Randy Brukardt wrote:
>>
>> fix this. There's no good reason (outside of Annex E issues) for 
>> declaring
>> any package preelaborated, unless you like fighting errors a lot. C.4 is 
>> a
>> load of hooey, it's not actually implementable on the margins, and 
>> there's
>> no reason for any compiler to generate more code than necessary. Ergo,
>> you'll most likely get the same code whether or not you declare something
>> Preelaborated, so why bother with all of the hassles?
>
> For certification purposes, I think there is a value in avoiding 
> elaboration code.
>
> http://docs.adacore.com/live/wave/gnat_ugx/html/gnat_ugx/gnat_ugx/support_for_certified_systems.html#avoiding-elaboration-code
>
> I had the need to deal with it myself though.

Surely there are lots of requirements that the language cannot deal with; 
anything having to do with the actual code generated belongs to the 
implementation and not to the language. A language standard can't say 
anything useful about the generated code, because of the need to work in a 
wide variety of environments.

                               Randy.

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

[Randy Brukardt]

"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.

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

[Lucretia]

On Friday, 12 April 2019 23:38:42 UTC+1, Randy Brukardt  wrote:
> "Lucretia" <> wrote in message 

> 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.

One issue is that the line on

https://github.com/Lucretia/sdlada/blob/master/src/sdl-video-palettes.ads#L105

Was "Default_Terminator => Null_Colour" before the pragma preelaborate.

The entire commit was https://github.com/Lucretia/sdlada/commit/8ee63fd60deeb95f14d9c2b0eeb49d5199bd6c91

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

[Jere]

On Thursday, April 11, 2019 at 8:40:40 AM UTC-4, Lucretia wrote:
> Someone sent in a pull request to my bindings and had to change a few constants to functions because objects can't be static. For an example:
> 
>    type Sizes is
>       record
>          Width  : Dimension;
>          Height : Dimension;
>       end record with
>      Convention => C;
> 
>    Zero_Size : constant Sizes := (others => Natural_Dimension'First);
> 
> Why can't Zero_Size be compiled as static in this pre-elaborated package?
> 
> This seems to be a major flaw in Ada imo.
> 
> Luke.

Out of curiosity, are you looking for something more akin to C++'s
constexpr [1][2] keyword?  Ada's static definition is kind of like that, 
but not as flexible or usable yet.  I'm hoping that at some point Ada 
does adjust the definition of static to be even more useful.  Most 
compiler's do make things that are static potentially
compile time, but I (think) I share your frustration in how limited
the definition actually covers, especially in places where it would
be obvious for the compiler to make that decision (well assuming the
language definition would allow it).  I think Ada202x is looking at
improving the breadth of situations for static functions (maybe someone
more versed can confirm this either way).

This is definitely one of the few outliers in my embedded code as
I work to move my old C++ embedded code into Ada designs.  It's really
frustrating to take such large hits on either performance (when dealing 
with small embedded boards) or better reusable design.  Granted it is 
just a few outliers and I can find workarounds, but the workarounds
occasionally can be more error prone and much more difficult to 
maintain.

[1]: https://www.geeksforgeeks.org/understanding-constexper-specifier-in-c/
[2]: https://en.cppreference.com/w/cpp/language/constexpr

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

[Lucretia]

On Saturday, 13 April 2019 14:07:13 UTC+1, Jere  wrote:
> On Thursday, April 11, 2019 at 8:40:40 AM UTC-4, Lucretia wrote:

> >    Zero_Size : constant Sizes := (others => Natural_Dimension'First);
> > 
> > Why can't Zero_Size be compiled as static in this pre-elaborated package?
> > 
> > This seems to be a major flaw in Ada imo.
> > 
> > Luke.
> 
> Out of curiosity, are you looking for something more akin to C++'s
> constexpr [1][2] keyword?  Ada's static definition is kind of like that, 

What I'm after is for the compiler to compile a constant, which as can be seen has it's components initialised from other constants, such that I can then pass the overall constant like Zero_Size, into a generic, in which the whole outer package is pre-elaborated.

> but not as flexible or usable yet.  I'm hoping that at some point Ada 
> does adjust the definition of static to be even more useful.  Most 

I can't believe, in 40 years, nobody has come up against this issue before.

I suppose maybe that constexpr function modifier would be helpful here too, but really the data should be considered static, as in, clearly defined at compile time.

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

[Keith Thompson]

Lucretia <laguest9000@googlemail.com> writes:
> Someone sent in a pull request to my bindings and had to change a few
> constants to functions because objects can't be static. For an
> example:
>
>    type Sizes is
>       record
>          Width  : Dimension;
>          Height : Dimension;
>       end record with
>      Convention => C;
>
>    Zero_Size : constant Sizes := (others => Natural_Dimension'First);
>
> Why can't Zero_Size be compiled as static in this pre-elaborated
> package?

What exactly do you mean by "static"?  That word has very different
meanings in C and Ada.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

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

[G. B.]

Lucretia <laguest9000@googlemail.com> wrote:
>  
> 
> I can't believe, in 40 years, nobody has come up against this issue before.

Dependence on static properties has been an Ada issue before, IIRC. A
result is present in the phrase “must statically match“. I don’t know
whether or not this suggests that compilers will elaborate at compile time.

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

[sbelmont700]

For anyone interested, here is a minimal reproduction of what (i think) is the OP's issue (the actual for the generic instantiation, not the constant itself).


package Static is
  pragma Preelaborate;

  generic
    type T is private;
    o : T;
  package GP is
  end GP;

  type T is
    record
      x,y : Positive;
    end record;

  o : constant T := (others => Positive'First);

  package p1 is new GP (T, O);                            --no
  package p2 is new GP (T, (others => Positive'First));   --yes

end Static;


gcc -c static.ads
static.ads:19:27: non-static constant in preelaborated unit
static.ads:19:27: static expression must have scalar or string type (RM 4.9(2))
gnatmake: "static.ads" compilation error


Needling to duplicate the declaration does seem needlessly irritating, but then again isn't everything with generics? ;-)

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

[Randy Brukardt]

<sbelmont700@gmail.com> wrote in message 
news:bc07b54c-0e86-4a40-931c-ca52d0295564@googlegroups.com...
> For anyone interested, here is a minimal reproduction of what (i think)
>is the OP's issue (the actual for the generic instantiation, not the 
>constant itself).
>
>
> package Static is
>  pragma Preelaborate;

I view this as self-inflicted, because there's no little value to pragma 
Preelaborate. As I previously noted, compilers will almost always generate 
the best possible elaboration code whether or not that pragma is applied. 
And regardless of C.4, not all preelaborated code can be done before load 
time, so it isn't providing a benefit in forcing that sort of code, either.

It's one of the ideas where Ada tried to accomplish something, but didn't 
quite succeed. Pure is like that as well, but at least it provides some 
benefits for Annex E code. Preelaborate doesn't even do that.

Especially when using GNAT and its static elaboration model (which 
eliminates elaboration checks from the equation -- that's the only benefit 
from using it in Janus/Ada).

                                                       Randy.

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

[Mark Lorenzen]

On Tuesday, April 16, 2019 at 3:40:45 AM UTC+2, Randy Brukardt wrote:
> >
> > package Static is
> >  pragma Preelaborate;
> 
> I view this as self-inflicted, because there's no little value to pragma 
> Preelaborate. As I previously noted, compilers will almost always generate 
> the best possible elaboration code whether or not that pragma is applied. 
> And regardless of C.4, not all preelaborated code can be done before load 
> time, so it isn't providing a benefit in forcing that sort of code, either.
> 
> It's one of the ideas where Ada tried to accomplish something, but didn't 
> quite succeed. Pure is like that as well, but at least it provides some 
> benefits for Annex E code. Preelaborate doesn't even do that.

How can it be ensured that a library written in Ada does not require any elaboration. Pragma Pure? I think that such libraries are "nice" but pragma Pure is too restrictive for that purpose. In such cases it would be good, if e.g. the OP's problem could be solved at compile time without any elaboration.

Regards,
Mark L

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

[Simon Wright]

Mark Lorenzen <mark.lorenzen@gmail.com> writes:

> On Tuesday, April 16, 2019 at 3:40:45 AM UTC+2, Randy Brukardt wrote:
>> >
>> > package Static is
>> >  pragma Preelaborate;
>> 
>> I view this as self-inflicted, because there's no little value to
>> pragma Preelaborate. As I previously noted, compilers will almost
>> always generate the best possible elaboration code whether or not
>> that pragma is applied.  And regardless of C.4, not all preelaborated
>> code can be done before load time, so it isn't providing a benefit in
>> forcing that sort of code, either.
>> 
>> It's one of the ideas where Ada tried to accomplish something, but
>> didn't quite succeed. Pure is like that as well, but at least it
>> provides some benefits for Annex E code. Preelaborate doesn't even do
>> that.
>
> How can it be ensured that a library written in Ada does not require
> any elaboration. Pragma Pure? I think that such libraries are "nice"
> but pragma Pure is too restrictive for that purpose. In such cases it
> would be good, if e.g. the OP's problem could be solved at compile
> time without any elaboration.

The GNAT pragma No_Elaboration_Code_All will do the trick (or fail if it
can't be done).

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

[Lucretia]

On Tuesday, 16 April 2019 01:09:00 UTC+1, sbelm...@gmail.com  wrote:
> For anyone interested, here is a minimal reproduction of what (i think) is the OP's issue (the actual for the generic instantiation, not the constant itself).
> 
 
Yes you are right.

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

[Lucretia]

On Tuesday, 16 April 2019 02:40:45 UTC+1, Randy Brukardt  wrote:

> I view this as self-inflicted, because there's no little value to pragma 
> Preelaborate. As I previously noted, compilers will almost always generate 

Nope, I didn't implement it, someone else did.

> the best possible elaboration code whether or not that pragma is applied. 
> And regardless of C.4, not all preelaborated code can be done before load 
> time, so it isn't providing a benefit in forcing that sort of code, either.
> 
> It's one of the ideas where Ada tried to accomplish something, but didn't 
> quite succeed. Pure is like that as well, but at least it provides some 
> benefits for Annex E code. Preelaborate doesn't even do that.

If it didn't succeed, why is it still part of the language? This is the typical attitude of the ARG refusing to deprecate old stuff.

 
Luke.

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

[Lucretia]

On Tuesday, 16 April 2019 13:11:36 UTC+1, Mark Lorenzen  wrote:

> How can it be ensured that a library written in Ada does not require any elaboration. Pragma Pure? I think that such libraries are "nice" but pragma Pure is too restrictive for that purpose. In such cases it would be good, if e.g. the OP's problem could be solved at compile time without any elaboration.

I don't think it can, going by this thread. I also think this is why Ada will fail in other environments, i.e. not security or safety critical stuff, but where performance is important.

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

[Niklas Holsti]

On 19-04-16 23:56 , Lucretia wrote:
> On Tuesday, 16 April 2019 13:11:36 UTC+1, Mark Lorenzen  wrote:
>
>> How can it be ensured that a library written in Ada does not
>> require any elaboration. Pragma Pure? I think that such libraries
>> are "nice" but pragma Pure is too restrictive for that purpose. In
>> such cases it would be good, if e.g. the OP's problem could be
>> solved at compile time without any elaboration.

Why are you so fixated on elaboration? Many non-Ada libraries require 
initialization calls. Moreover, I believe a C++ program can have 
compiler-generated initialization code similar to Ada elaboration code.

> I don't think it can, going by this thread. I also think this is why
> Ada will fail in other environments, i.e. not security or safety
> critical stuff, but where performance is important.

Performance is plenty important in many embedded real-time applications, 
where Ada works just fine.

Elaboration of library items consumes execution time only at the start 
of a program. Do you have some stringent start-up deadlines?

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

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

[Lucretia]

On Tuesday, 16 April 2019 22:07:24 UTC+1, Niklas Holsti  wrote:

> Why are you so fixated on elaboration? Many non-Ada libraries require 
> initialization calls. Moreover, I believe a C++ program can have 
> compiler-generated initialization code similar to Ada elaboration code.

Not everything needs it, the example in this thread shouldn't need it.
 
> > I don't think it can, going by this thread. I also think this is why
> > Ada will fail in other environments, i.e. not security or safety
> > critical stuff, but where performance is important.
> 
> Performance is plenty important in many embedded real-time applications, 
> where Ada works just fine.

Not every application is embedded, which is my point.
 
> Elaboration of library items consumes execution time only at the start 
> of a program. Do you have some stringent start-up deadlines?

Not exactly, but it would be nice to be able to know that something which shouldn't need elaboration, doesn't use elaboration. That's the point, you're missing.

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

[Niklas Holsti]

On 19-04-17 00:16 , Lucretia wrote:
> On Tuesday, 16 April 2019 22:07:24 UTC+1, Niklas Holsti  wrote:
>
>> Why are you so fixated on elaboration? Many non-Ada libraries
>> require initialization calls. Moreover, I believe a C++ program can
>> have compiler-generated initialization code similar to Ada
>> elaboration code.
>
> Not everything needs it, the example in this thread shouldn't need
> it.

So what? Why do you care?

>>> I don't think it can, going by this thread. I also think this is
>>> why Ada will fail in other environments, i.e. not security or
>>> safety critical stuff, but where performance is important.
>>
>> Performance is plenty important in many embedded real-time
>> applications, where Ada works just fine.
>
> Not every application is embedded, which is my point.

You have a problem only for non-embedded applications? Is that why 
start-up time is important, because your entire applications are 
frequently started up, run for a short time to do some single thing, and 
then stop?

>> Elaboration of library items consumes execution time only at the
>> start of a program. Do you have some stringent start-up deadlines?
>
> Not exactly, but it would be nice to be able to know that something
> which shouldn't need elaboration, doesn't use elaboration.

So the thing you want is a "nice to have" feature? And you claim that 
the lack of that feature means that Ada "will fail"? Not convincing to me.

Use the GNAT pragma No_Elaboration_Code, as others have suggested. If 
you feel strongly about this point, suggest to the ARG that this pragma 
should be standardized.

I have occasionally needed to write packages with guaranteed absence of 
elaboration code, when operations in those packages are called from the 
low-level start-up code, to perform some HW initialization before Ada 
elaboration. No_Elaboration_Code worked for me.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

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

[Randy Brukardt]

"Mark Lorenzen" <mark.lorenzen@gmail.com> wrote in message 
news:1127d366-d36c-4abf-8590-4b8c0e2b5446@googlegroups.com...
...
>How can it be ensured that a library written in Ada does not require any 
>elaboration.

Why would anyone care? You don't try to specify implementation techniques 
for for loops, why do it for elaboration?

Performance isn't likely to be an issue (the elaboration code, if any, only 
runs once). It would take a pretty contrived program to notice the cost. 
(And, in my experience, initializing memory slows down programs if there is 
a lot of memory involved, as all of the memory has to be paged in in that 
case.)

Some programs have outside requirements on the code (such as no heap 
allocation or the like), but those generally go beyond just elaboration and 
there are Restrictions for dealing with them.

Stuff like mapping to ROM or the like is going to be target-dependent in any 
case. And for such mapping, you're better off having less stuff that 
requires writability (as that requires RAM), and more ROM. That's one of the 
reasons that we ignore C.4 (since we had quite a few embedded 80186 
customers back in the day - smaller RAM and ROM requirements are a thing).

So, to me, preelaborate is not solving any problems other than getting rid 
of a few elaboration checks. And GNAT has found a much better way to do 
that. So, in particular, if you are using GNAT, preelaborate buys you little 
other than error messages.

                                                   Randy.

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

[Randy Brukardt]

"Lucretia" <laguest9000@googlemail.com> wrote in message 
news:eea7b282-3a5a-4274-adbf-81f8f6741e67@googlegroups.com...
> On Tuesday, 16 April 2019 02:40:45 UTC+1, Randy Brukardt  wrote:
>
>> I view this as self-inflicted, because there's no little value to pragma
>> Preelaborate. As I previously noted, compilers will almost always 
>> generate
>
> Nope, I didn't implement it, someone else did.
>
>> the best possible elaboration code whether or not that pragma is applied.
>> And regardless of C.4, not all preelaborated code can be done before load
>> time, so it isn't providing a benefit in forcing that sort of code, 
>> either.
>>
>> It's one of the ideas where Ada tried to accomplish something, but didn't
>> quite succeed. Pure is like that as well, but at least it provides some
>> benefits for Annex E code. Preelaborate doesn't even do that.
>
> If it didn't succeed, why is it still part of the language? This is the 
> typical attitude
>of the ARG refusing to deprecate old stuff.

Mostly, I think, because most of us don't care about it enough to go through 
the fight of making it Obsolescent. And that doesn't do anything for 
implementers, it just hides the feature in the back of the Standard.

We'd need a full redesign of Ada in order to get rid of this stuff, but I 
doubt there is sufficient interest (and I doubt the result would be 
something I'd like, anyway).

                                        Randy.

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

[Randy Brukardt]

"Lucretia" <laguest9000@googlemail.com> wrote in message 
news:ed1629d2-f6d9-4bc9-b929-01f910bfe4a8@googlegroups.com...
...
> Not exactly, but it would be nice to be able to know that something
>which shouldn't need elaboration, doesn't use elaboration. That's the 
>point,
>you're missing.

You're confusing the concept of elaboration with execution of explicit 
elaboration code.

Everything in Ada is elaborated at some point. If you look around the 
Standard, you'll see lots of statements like "The elaboration of <blah> has 
no effect.". <blah> is elaborated, but that elaboration does nothing.

And Ada compilers don't generate code to do elaboration unless they have to. 
So you're only talking about a small percentage of code, which is executed 
only once. It's the least likely thing to matter in a program.

In addition, using code rather than some sort of pre-initialization is 
typically smaller and can easily be mapped to ROM and uninitialized RAM in 
an embedded system. For most situations, it's preferable. Worrying about how 
memory is initialized is the height of premature optimization.

                                          Randy.

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

[sbelmont700]

I see this more as a deficiency in the generic model than in the elaboration model.  Consider that if the OP had just manually copy-and-pasted the generic code as a nested package (which is ostensibly what generics do) instead of using an instantiation, everything would have worked fine.

-sb

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

[Norman Worth]

Mark Lorenzen wrote:
> On Tuesday, April 16, 2019 at 3:40:45 AM UTC+2, Randy Brukardt wrote:
>>>
>>> package Static is
>>>   pragma Preelaborate;
>>
>> I view this as self-inflicted, because there's no little value to pragma
>> Preelaborate. As I previously noted, compilers will almost always generate
>> the best possible elaboration code whether or not that pragma is applied.
>> And regardless of C.4, not all preelaborated code can be done before load
>> time, so it isn't providing a benefit in forcing that sort of code, either.
>>
>> It's one of the ideas where Ada tried to accomplish something, but didn't
>> quite succeed. Pure is like that as well, but at least it provides some
>> benefits for Annex E code. Preelaborate doesn't even do that.
> 
> How can it be ensured that a library written in Ada does not require any elaboration. Pragma Pure? I think that such libraries are "nice" but pragma Pure is too restrictive for that purpose. In such cases it would be good, if e.g. the OP's problem could be solved at compile time without any elaboration.
> 
> Regards,
> Mark L
> 
Something that these pragmas do (perhaps the only thing) is to insure 
that the code you write meets the requirements of the pragma.  (Some 
compilers may not even ensure this.)

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

[Mark Lorenzen]

On Tuesday, April 16, 2019 at 11:07:24 PM UTC+2, Niklas Holsti wrote:
> On 19-04-16 23:56 , Lucretia wrote:
> > On Tuesday, 16 April 2019 13:11:36 UTC+1, Mark Lorenzen  wrote:
> >
> >> How can it be ensured that a library written in Ada does not
> >> require any elaboration. Pragma Pure? I think that such libraries
> >> are "nice" but pragma Pure is too restrictive for that purpose. In
> >> such cases it would be good, if e.g. the OP's problem could be
> >> solved at compile time without any elaboration.
> 
> Why are you so fixated on elaboration? Many non-Ada libraries require 
> initialization calls. Moreover, I believe a C++ program can have 
> compiler-generated initialization code similar to Ada elaboration code.
> 
> > I don't think it can, going by this thread. I also think this is why
> > Ada will fail in other environments, i.e. not security or safety
> > critical stuff, but where performance is important.
> 
> Performance is plenty important in many embedded real-time applications, 
> where Ada works just fine.
> 
> Elaboration of library items consumes execution time only at the start 
> of a program. Do you have some stringent start-up deadlines?
> 
> -- 
> Niklas Holsti
> Tidorum Ltd
> niklas holsti tidorum fi
>        .      @       .

Let's say I'm writing a static library in Ada that is to be used by a program written in C.

I can define a C-friendly API and export the API subprograms, but what happens if the library needs elaboration? Using GPRbuild I can define the library as a "standalone library" such that the binder generates the necessary initialization subprogram that performs elaboration. This is of course tool specific with the implications that this imposes.

Regards,
Mark L