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.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,baa6871d466e5af9
X-Google-Attributes: gid103376,public
From: dewar@merv.cs.nyu.edu (Robert Dewar)
Subject: Re: AQ&S Guidance on pragma Elaborate_Body
Date: 1997/04/23
Message-ID: <dewar.861816859@merv>#1/1
X-Deja-AN: 237032309
References: <528878564wnr@diphi.demon.co.uk> <dewar.861414695@merv>
 <5jabeq$3ltk@info4.rus.uni-stuttgart.de> <5jfukp$lda@top.mitre.org>
Organization: New York University
Newsgroups: comp.lang.ada
Date: 1997-04-23T00:00:00+00:00
List-Id: <comp.lang.ada>



Michael says

<<You cannot modify the body of a PURE package to add in, for example,
  text_io, or any other non-pure package for debugging purposes at a later time,
  without busting the purity of everything that withs the PURE package. You
  also may not reuse a pure generic package in a way that introduces any memory,
  because of the rule that the compiler may optimize away repeated calls
  with the same arguments. Gnat in its current state (3.07 DOS) optimizes
  pure packages that implement limited private data structures better than
  impure packages. ROMable code should be PURE.
>>

I often find it quite annoying not being able to use Text_IO for debugging
purposes in a pure or preelaborable package. There are two ways around it.
One is to use GNAT.IO, which is at least preelaborable (maybe we should
cheat and call it pure, but it really isn't).

The other is to use the secret switch -gnatdu:

   --  du   Uncheck categorization pragmas. This debug switch causes the          
   --       categorization pragmas (Pure, Preelaborate etc) to be ignored         
   --       so that normal checks are not made (this is particularly useful       
   --       for adding temporary debugging code to units that have pragmas        
   --       that are inconsistent with the debugging code added.                  

well it is not *that* secret. it is one of the GNAT debugging switches
that are documented in debug.adb :-)

<<There are no disadvantages to marking elaborable packages as ELABORATE_BODY,
  and they should be so marked for both documentation and for compiler hinting.
>>

That is incorrect, you can certainly create cases of legitimate programs
where the use of Elaborate_Body will cause elaboration circularities. A
trivial example is two packages, each of whose bodies with's the others
spec, which is not that uncommon.

<<The goal should be that almost all of the non-thread-safe code should be
  marked ELABORATE_BODY, and almost all of the thread-safe code should be
  marked PREELABORATE or PURE.>>

I have no idea what Michael has in mind here. This has nothing at all to do
with thread safety. Elaboration and thread safety are entirely unrelated
issues. In particular, a common idiom is to complete the elaboration before
any tasks are started up.

Robert Dewar
Ada Core Technologies