From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,a85c723067c60e9a X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-06-26 07:34:33 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!canoe.uoregon.edu!hammer.uoregon.edu!skates!not-for-mail From: Stephen Leake Newsgroups: comp.lang.ada Subject: Re: pragma Pure/Preelaborate - tools, practice? Date: 26 Jun 2001 10:32:28 -0400 Organization: NASA Goddard Space Flight Center Message-ID: References: <3B325B9E.483CAF25@ftw.rsc.raytheon.com> NNTP-Posting-Host: anarres.gsfc.nasa.gov Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: skates.gsfc.nasa.gov 993566949 19462 128.183.220.71 (26 Jun 2001 14:49:09 GMT) X-Complaints-To: dscoggin@cne-odin.gsfc.nasa.gov NNTP-Posting-Date: 26 Jun 2001 14:49:09 GMT User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.6 Xref: archiver1.google.com comp.lang.ada:9117 Date: 2001-06-26T14:49:09+00:00 List-Id: Wes Groleau 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