pragma Pure/Preelaborate - tools, practice?

pragma Pure/Preelaborate - tools, practice?

[Wes Groleau]

I have seen advice that one use pragma Pure
where ever possible, Preelaborate next, etc.

In a way, this seems like bad advice to me.
If I find the need to use "access" in a package
body, then I have to change pragma Pure to
Preelaborate in the spec.  If I have to add
an initialization action to the body elaboration
(yes, there IS an alternative, but...)
then I have to remove Pure or Preelaborate
from the spec.

This in turn means I have to change EVERY
pure or preelaborate body or spec that directly
or indirectly depends on the one that had a
"real" change.  Even some specs that will still
compile may have to be changed because their
bodies are no longer compatible with the pragma.

So, putting in pragma Pure or preelaborate is
risking huge future maintenance actions, is it not?

BUT, supposing one decided to follow the advice.
Is there a tool (ASIS?) that can analyze a file
and everything it depends on (recursively) including
bodies (because whether a spec can be Pure depends
on its body) and tell whether it is potentially Pure?

"potentially" meaning everything it depends on could
legally be pure, even if the pragma isn't there.

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

Re: pragma Pure/Preelaborate - tools, practice?

[Colin Paul Gloster]

Wes asked in news:3B325B9E.483CAF25@ftw.rsc.raytheon.com :
"Is there a tool (ASIS?) that can analyze a file
and everything it depends on (recursively) including
bodies (because whether a spec can be Pure depends
on its body) and tell whether it is potentially Pure?"

You might ask GrammaTech if their Ada-ASSURED or
Ada-UTILITIES products will be of use to you.

GrammaTech, Inc.
317 North Aurora Street
Ithaca, NY 14850
U.S.A.
(607) 273-8752 [fax]

Re: pragma Pure/Preelaborate - tools, practice?

[Stephen Leake]

Wes Groleau <wwgrol@ftw.rsc.raytheon.com> writes:

> I have seen advice that one use pragma Pure
> where ever possible, Preelaborate next, etc.

I used this approach in Windex. I assumed it would result in more
efficient code, since many packages would be Preelaborated.

> In a way, this seems like bad advice to me. If I find the need to
> use "access" in a package body, then I have to change pragma Pure to
> Preelaborate in the spec. If I have to add an initialization action
> to the body elaboration (yes, there IS an alternative, but...) then
> I have to remove Pure or Preelaborate from the spec.

This was occasionally a problem. But with GNAT and Emacs, it was never
hard to find and fix the problems.

> This in turn means I have to change EVERY pure or preelaborate body
> or spec that directly or indirectly depends on the one that had a
> "real" change. Even some specs that will still compile may have to
> be changed because their bodies are no longer compatible with the
> pragma.
> 
> So, putting in pragma Pure or preelaborate is
> risking huge future maintenance actions, is it not?

On the other hand, it encourages stability. It gives more weight to
_not_ changing things unnecessarily. That can be a Good Thing.

> BUT, supposing one decided to follow the advice. Is there a tool
> (ASIS?) that can analyze a file and everything it depends on
> (recursively) including bodies (because whether a spec can be Pure
> depends on its body) and tell whether it is potentially Pure?
> 
> "potentially" meaning everything it depends on could
> legally be pure, even if the pragma isn't there.

For me, GNAT is the tool. Add the pragma Pure, run gnatmake, and see
what pops up.

Hmm. Perhaps you mean "starting with code that has _no_ elaboration
control pragmas, what packages can be declared Pure or Preelaborate".

My approach will eventually work for this, but it is tedious. I'd
start by putting in pragma Pure everywhere, and backing off as the
compiler complains.

You could write an ASIS tool to do the complete analysis at once, but
it would be a big job. I've not seen an actual tool for this.

-- 
-- Stephe