!standard 10.2.1                                     03-12-14  AI95-00366/01
!class amendment 03-12-14
!status work item 03-12-14
!status received 03-12-14
!priority Medium
!difficulty Easy
!subject More liberal rule for Pure units

!summary

Pure units allow access-to-subprogram tyes and access-to-object types,
for which no storage pool is created.

!problem

In pure units access-to-subprogram types and access-to-object types,
for which no storage pool is created, are presently prohibited.
There is no technical reason for the restriction and many packages
that should be pure can not be declared pure.

!proposal

(see wording)

!wording

Replace 10.2.1(16)
A pure library_item is a preelaborable library_item that does not
contain the declaration of any variable or named access type, except
within a subprogram, generic subprogram, task unit, or protected unit.
by:
A pure library_item is a preelaborable library_item that does not
contain the declaration of any variable or named access-to-object
type, for which the Storage_Size has not been specified to be 0,
excepting declarations within a subprogram, generic subprogram, task
unit, or protected unit.

!discussion

Pure implies that a unit has no state. Access-to-object types are
associated with storage pools, which constitute state.  However,
access-to-subprogram types have no such implications. Hence they
should not be excluded. A corresponding correction of 10.2.1(16) would
read:
A pure library_item is a preelaborable library_item that does not
contain the declaration of any variable or named access-to-object type, except
within a subprogram, generic subprogram, task unit, or protected unit.

Beyond access-to-subprogram types, some packages have a need for an
access-to-object type, without a need for a storage pool for the
type, however.  Setting the Storage_size of the type to zero implies
that no storage pool (and hence no state) needs to be created.

The proposed !wording reflects these observations and removes the
restriction on the presence of such access types.

!example

--!corrigendum

!ACATS test

An ACATS test checking that such types are allowed in Pure units should be
constructed.

!appendix

From: Randy Brukardt
Sent: Tuesday, February 3, 2004  5:16 PM

In the context of AI-362, I was thinking about how to get any sort of
logging/debugging into a Preelaborated unit.

The problem is that once a preelaborated unit has that pragma applied, you can
no longer with any I/O. Without I/O, you can't have any logging for faults in a
fielded system (if the system dies, it probably won't get to dump an in-memory
log, making it useless for field debugging - you probably can't run a debugger
on the target system - think about NASA's rovers...)

I realized that something that my spam filter's code does provides a solution
(assuming some up-front work):

  package Something is
    pragma Preelaborate (Something);
    type Logger_Access is access procedure (Text : in String);

    procedure Do_Something (....; Logger : Logger_Access := null);
  end Something;

Then, a call to Do_Something can include a logger, even if the logger couldn't
be withed by the Preelaborated unit:
    Do_Something (...., Logger => Ada.Text_IO.Put_Line'Access);

If you do this consistently, with each preelaborated routine passing the logger
on through any calls, you can pretty much log anything you need in a
preelaborated unit. At the cost of an extra parameter to everything, of course.
(You could use a global variable as well, but that's UGLY!)

That's OK for preelaborated units, since that is mainly about library-level
elaboration: which necessarily has been completed before any call can be made.

However, AI-366 proposes to allow access-to-subprogram and
access-to-object-with-empty-pool in pure units. This means that it would be
trivial to pass an impure function to a Pure function, and thus make the
results vary even if the parameters are the same (as per the permission of
10.2.1(18)):

     package Impure is
          pragma Pure (Impure);
          type Random_Access is function return Float;

          function Use_Random (Random : in Random_Access) return Natural;

     end Impure;

     A := Use_Random (Random'Access);
     B := Use_Random (Random'Access);

Clearly, the calls to Use_Random have the same values for a by-copy parameter,
but A and B are unlikely to have the same values. Yet the compiler can omit the
second call.

Indeed, this permission allows me to write a "Pure" random number generator:

    package Pure_Random is
         pragma Pure (Pure_Random);
         type Generator is private;
         type Generator_Access is access all Generator;
         for Generator_Access'Storage_Size use 0;

         function Random (Gen : in Generator_Access) return Float;
    end Pure_Random;

    Gen : aliased Pure_Random.Generator;

    A := Pure_Random.Random (Gen'Access);
    B := Pure_Random.Random (Gen'Access);

Clearly, the permission of 10.2.1(18) applies to these calls, and yet it
clearly must not!

So it appears that AI-366 is incomplete, in that it should address this issue
somehow.

We'd really rather not allow such functions as Pure -- but that's the current
state; we could vote this AI No Action, but that's hardly responsive to the
problem.

One possibility is to do as the GNAT Pure_Function pragma, which is to say that
pragma Pure is an assertion that any functions always return the (logically)
same results and have no significant side-effects (without checking those
assertions). In which case, we can leave the permission alone.

But others have suggested that the permission of 10.2.1(18) is flawed anywhy
(that discussion was filed in AI-290 about pragma Pure_Function). Perhaps the
permission can be 'patched up' by including the values of access-to-object
parameters, and excluding the permission if there are any access-to-subprogram
parameters. (That's probably a bit too strong, but I'd rather err on the side
of correctness rather than optimization...)

****************************************************************

From: Tucker Taft
Sent: Tuesday, February 3, 2004  8:08 PM

If we allow "pure" access types, then clearly the
values of the variables accessible via an access value
must be included in 10.2.1(18).  The variables accessible
via an access-to-subprogram value include any variables
visible to the designated subprogram.  The variables
accessible via an access-to-object value include the
designated object, and any variables that can be reached
from there via following access values.

****************************************************************

From: Pascal Leroy
Sent: Wednesday, February 4, 2004  7:12 AM

I don't see that there is anything new here.  You can do the same
currently if Random has an access parameter, because 10.2.1(16) only
talks about named access types.

I believe that the rules that 10.2.1(18) specifies for by-reference
types should also apply to access types,.

Actually I would be in favor of deleting 10.2.1(18) altogether, as it's
one of these rules (like 11.6) which effectively says "forget the rest
of this book, we don't really mean it".  But I guess that's a different
discussion.

****************************************************************

From: Tucker Taft
Sent: Wednesday, February 4, 2004  7:16 AM

Yes, that's a very different discussion ;-).

****************************************************************

From: Robert Dewar
Sent: Wednesday, February 4, 2004  7:36 AM

Remember that you can always do anything by doing raw import
rather than WITH.

It is really nothing to get worried about that this sort of
thing can be done.

Pure does NOT mean that a function is pure in the formal
sense, just that the compiler can make assumptions about
deleting identical calls, and deleting useless calls.

****************************************************************

From: Robert Dewar
Sent: Wednesday, February 4, 2004  7:41 AM

Pascal Leroy wrote:

> Actually I would be in favor of deleting 10.2.1(18) altogether, as it's
> one of these rules (like 11.6) which effectively says "forget the rest
> of this book, we don't really mean it".  But I guess that's a different
> discussion.

This would be an unacceptable change! The optimziation of pure functions
can be quite critical to efficiency in some applications, and certainly
other languages have this capability.

Of course removing it from the language would merely mean we had to
invent a new pragma for an implementation (actually GNAT already does
that with Pure_Function, which allows a function to be declared pure
for optimization purposes without the whole package being Pure --
which carries so much irrelevant baggage along with it.

Yes, you can worry from a theoretical point of view that 10.2.1(18)
in conjunction with nasty stuff, e.g. calling unknown foreign
language routines, can result in problems, but I don't think that's
a major issue in practice.

****************************************************************

From: Robert Dewar
Sent: Wednesday, February 4, 2004  7:50 AM

Randy Brukardt wrote:

> In the context of AI-362, I was thinking about how to get any sort of
> logging/debugging into a Preelaborated unit.
>
> The problem is that once a preelaborated unit has that pragma applied, you
> can no longer with any I/O. Without I/O, you can't have any logging for
> faults in a fielded system (if the system dies, it probably won't get to
> dump an in-memory log, making it useless for field debugging - you probably
> can't run a debugger on the target system - think about NASA's rovers...)

Well of course you can do I/O, you just can't use the (somewhat dubious
in any case) predefined Ada I/O packages. In GNAT, we provide GNAT.IO
which is a useful simple subset of Text_IO, and the documentation in
g-io.ads says:

--  A simple text I/O package that can be used for simple I/O functions
--  in user programs as required. This package is also preelaborated,
--  unlike Text_IO, and can thus be with'ed by preelaborated library
--  units.

The implementation is quite straightforward, using pragma Import
on standard C library functions.

****************************************************************

From: Robert A. Duff
Sent: Wednesday, February 4, 2004  8:32 AM

> The problem is that once a preelaborated unit has that pragma applied, you
> can no longer with any I/O.

I do debugging/tracing output in pragma-Pure and pragma-Preelab packages
all the time.  I have a debug package containing things like Put, and
Put is declared ``pragma Import(Ada, Put, "Impure_Put");''.  Impure_Put
does the dirty work -- it is not with'ed by the debug package.  The
debug package has pragma Pure, so can be used anywhere.

****************************************************************

From: Robert Dewar
Sent: Wednesday, February 4, 2004  8:48 AM

Pure seems wrong for that. If you have

    while not EOF loop ... end loop;

then the compiler can (and most likely will) pull the test for
EOF out of the loop. It is even OK in:

    put ("-----");
    put ("-----");

to eliminate the second call.

It seems conceptually wrong to have an I/O package be pure, though
of course it can be programmed and may be useful in practice. It
seems fine for an I/O package to be preelaborable.

****************************************************************

From: Robert A. Duff
Sent: Wednesday, February 4, 2004  9:22 AM

> It seems conceptually wrong to have an I/O package be pure, ...

Yes, it is.  I do it anyway, because in some cases it's useful for
debugging.  Of course, I have to keep in mind that the compiler can
transform the code in various ways that might affect the actual
printouts.

>...though
> of course it can be programmed and may be useful in practice.

Interestingly, my previous message just happened to be number 666 in my
mailbox -- maybe that's a sign of how evil that package is.  ;-)

****************************************************************

From: Randy Brukardt
Sent: Wednesday, February 4, 2004  9:49 PM

Robert Dewar said:
...
> Remember that you can always do anything by doing raw import
> rather than WITH.

Of course. But the design of Pure seems to imply that if you just write
straight Ada code, the optimizer won't do anything bad to you.

> It is really nothing to get worried about that this sort of
> thing can be done.
>
> Pure does NOT mean that a function is pure in the formal
> sense, just that the compiler can make assumptions about
> deleting identical calls, and deleting useless calls.

If this is the case, then there is no need for all of the restrictions on
Pure units. We should just make the restrictions the same as Preelaborate,
and say user-beware. (That doesn't seem very much in keeping with the Ada
philosophy to me, but this is a weird case.)

****************************************************************

From: Randy Brukardt
Sent: Wednesday, February 4, 2004  10:01 PM

Robert Dewar wrote:

...
> Well of course you can do I/O, you just can't use the (somewhat dubious
> in any case) predefined Ada I/O packages. In GNAT, we provide GNAT.IO
> which is a useful simple subset of Text_IO, and the documentation in
> g-io.ads says:

Well, I don't want to have to use implementation-defined stuff to make
logging (which will remain in the application for its entire lifetime) work.
That locks me into a specific compiler.

If this is so easy to implement, then it seems that we should look at
requiring some of the predefined IO to be preelaborated. Then there is no
more problem. At least one implementer has objected to doing that, which is
what led to the musings.

Bob said:

> I do debugging/tracing output in pragma-Pure and pragma-Preelab packages
> all the time.  I have a debug package containing things like Put, and
> Put is declared ``pragma Import(Ada, Put, "Impure_Put");''.  Impure_Put
> does the dirty work -- it is not with'ed by the debug package.  The
> debug package has pragma Pure, so can be used anywhere.

That's also not portable (although more so); most Janus/Ada compilers
standard mode is "no Import/Export". That allows "one button" program
creation (no bizarre system linkers needed); everything is in the Ada
program.

Of course, we support Import/Export in "clunky program creation mode", but I
use that only when access to actual foreign code is needed.

Pragma Import should be prohibited in Pure units anyway (I realize that
isn't going to happen, it would break too many existing kludges).

****************************************************************

From: Pascal Leroy
Sent: Thursday, February 5, 2004  3:49 AM

Randy replied to Robert:

> > Remember that you can always do anything by doing raw import rather
> > than WITH.
>
> Of course. But the design of Pure seems to imply that if you
> just write straight Ada code, the optimizer won't do anything
> bad to you.

I agree with Randy.  You can do all sorts of nasty things with low-level
programming and interfacing with other languages, but the rules in
10.2.1 seem to be designed so that the na‹ve programmer is not
unwittingly bitten by the permission of 10.2.1(18).  It just happens
that access types must be taken into account here.

****************************************************************

From: Robert Dewar
Sent: Thursday, February 5, 2004  4:14 AM

Randy Brukardt wrote:

> If this is so easy to implement, then it seems that we should look at
> requiring some of the predefined IO to be preelaborated. Then there is no
> more problem. At least one implementer has objected to doing that, which is
> what led to the musings.

How about a subset of Text_IO that removes a lot of the junk (e.g. page
marks, line counting etc), handles just strings and characters (can
always use 'Image) and is Preelaborable.

****************************************************************

From: Robert I. Eachus
Sent: Thursday, February 5, 2004  8:30 AM

> How about a subset of Text_IO that removes a lot of the junk (e.g. page
> marks, line counting etc), handles just strings and characters (can
> always use 'Image) and is Preelaborable.

Excellent idea.  Call it Simple_IO or something, include put for
Integer, Float, and possibly Duration, plus Long_ and Short_ variants if
supported by the compiler.  Hmmm.  No.  Feature creap. We could include
the Short_ and Long_ types in the spec, and in Ada 0Y we should probably
just bite the bullet and require that Short_Integer, Integer, and
Long_Integer be supported along with Short_Float, Float, and Long_Float
in standard.  (They can be renames for compilers that only support two
(or one) type)  But that is a different AI.

For Simple_IO. A better idea would be to have child generics for other
integer, real, enumeration types, and non-Latin1 character types.  Yes
that will require instantiation inside subprograms if you want to use
them in pre-elaboratable units.  But I don't see that as a significant
issue.

****************************************************************

From: Robert Dewar
Sent: Thursday, February 5, 2004  7:29 PM

Why burden it with all this junk. It is fine to use 'Image for numeric
stuff, have Simple_IO just do string stuff (have a look at GNAT.IO), or
better I will give the spec here. This has proved very useful:

--  A simple preelaborable subset of Text_IO capabilities

--  A simple text I/O package that can be used for simple I/O functions in
--  user programs as required. This package is also preelaborated, unlike
--  Text_IO, and can thus be with'ed by preelaborated library units.

--  Note that Data_Error is not raised by these subprograms for bad data.
--  If such checks are needed then the regular Text_IO package must be used.

package GNAT.IO is
pragma Preelaborate (IO);

    type File_Type is limited private;
    --  Specifies file to be used (the only possibilities are Standard_Output
    --  and Standard_Error). There is no Create or Open facility that would
    --  allow more general use of file names.

    function Standard_Output return File_Type;
    function Standard_Error  return File_Type;
    --  These functions are the only way to get File_Type values

    procedure Get (X : out Integer);
    procedure Get (C : out Character);
    procedure Get_Line (Item : out String; Last : out Natural);
    --  These routines always read from Standard_Input

    procedure Put (File : File_Type; X : Integer);
    procedure Put (X : Integer);
    --  Output integer to specified file, or to current output file, same
    --  output as if Ada.Text_IO.Integer_IO had been instantiated for Integer.

    procedure Put (File : File_Type; C : Character);
    procedure Put (C : Character);
    --  Output character to specified file, or to current output file

    procedure Put (File : File_Type; S : String);
    procedure Put (S : String);
    --  Output string to specified file, or to current output file

    procedure Put_Line (File : File_Type; S : String);
    procedure Put_Line (S : String);
    --  Output string followed by new line to specified file, or to
    --  current output file.

    procedure New_Line (File : File_Type; Spacing : Positive := 1);
    procedure New_Line (Spacing : Positive := 1);
    --  Output new line character to specified file, or to current output file

    procedure Set_Output (File : File_Type);
    --  Set current output file, default is Standard_Output if no call to
    --  Set_Output is made.

private
    type File_Type is (Stdout, Stderr);
    --  Stdout = Standard_Output, Stderr = Standard_Error

    pragma Inline (Standard_Error);
    pragma Inline (Standard_Output);

end GNAT.IO;

****************************************************************

From: Randy Brukardt
Sent: Thursday, February 5, 2004  6:29 PM

Robert Dewar wrote, replying to me:

> How about a subset of Text_IO that removes a lot of the junk (e.g. page
> marks, line counting etc), handles just strings and characters (can
> always use 'Image) and is Preelaborable.

I have no objection to that, although it seems like a tough sell to me (why
do we need yet another I/O library?).

My preference would be to make Text_IO and Stream_IO preelaborated (because
these have relatively simple dependence on the underlying system), leaving
the rest alone.

But I don't see that any library that allows file I/O (for logging) is going
to easily go around the objections of existing implementers. All of our I/O
is built on top of a single package (called System.Basic_IO), and if it is
too hard to make that preelaborated, it seems unlikely that it would be much
easier to implement a subset of it that is preelaborated. I believe that
this is a common implementation (Pascal indicated that Rational's is
organized the same way). And if you can make that preelaborated, making
Stream_IO and Text_IO preelaborated is pretty simple.

The only thing that causes trouble with making Text_IO preelaborated in
Janus/Ada is handling Current/Standard_Input/Output. While we could dispense
with redirection, we can hardly eliminate the concept of Standard_Output
from Simple_IO.

****************************************************************

From: Robert A. Duff
Sent: Thursday, February 5, 2004  8:24 AM

Randy said:

> Robert Dewar wrote:
> ...
> > Well of course you can do I/O, you just can't use the (somewhat dubious
> > in any case) predefined Ada I/O packages. In GNAT, we provide GNAT.IO
> > which is a useful simple subset of Text_IO, and the documentation in
> > g-io.ads says:
>
> Well, I don't want to have to use implementation-defined stuff to make
> logging (which will remain in the application for its entire lifetime) work.
> That locks me into a specific compiler.

Agreed.

> If this is so easy to implement, then it seems that we should look at
> requiring some of the predefined IO to be preelaborated. Then there is no
> more problem. At least one implementer has objected to doing that, which is
> what led to the musings.
>
> Bob said:
>
> > I do debugging/tracing output in pragma-Pure and pragma-Preelab packages
> > all the time.  I have a debug package containing things like Put, and
> > Put is declared ``pragma Import(Ada, Put, "Impure_Put");''.  Impure_Put
> > does the dirty work -- it is not with'ed by the debug package.  The
> > debug package has pragma Pure, so can be used anywhere.
>
> That's also not portable (although more so); ...

I think it *is* portable.  Convention "Ada" and the relevant pragmas are
not optional features of the language.  You don't need any special
linker options to get the impure part included -- just put a "with" of
the impure version of the package somewhere in the program.

By the way, although the semantics of my impure/pure cheat is somewhat
dubious, as Robert Dewar pointed out, in practise it's no worse than
what happens with an interactive debugger -- if the compiler has chosen
to stir the code around, the debugger gets confused and sometimes lies.
That's a pain, but getting a debugger to tell the truth about optimized
code is a rather difficult trick.  Pragma-Pure-related optimizations are
but one example.

Another standard trick is to use Import(Ada) to suppress default
initialization.  This is specified in RM-B.1(38), and mentioned in
AARM-13.3(12.c) and B.1(38.a).

>... most Janus/Ada compilers
> standard mode is "no Import/Export".

If you mean "pragma Import(Ada) is illegal in this mode, then you can
make that the *default* mode if you like, but I don't think you can call
it "standard". ;-)  If you're talking about extra linker options, then
fine -- but my ugly hack needs no extra linker options.

>... That allows "one button" program
> creation (no bizarre system linkers needed); everything is in the Ada
> program.
>
> Of course, we support Import/Export in "clunky program creation mode", but I
> use that only when access to actual foreign code is needed.
>
> Pragma Import should be prohibited in Pure units anyway (I realize that
> isn't going to happen, it would break too many existing kludges).

Over My Dead Body.  It would break *my* kludge!  (I'm sure I'm not the
only one who's thought of it.)

Anyway, it could be useful to import a pure C function into a
pragma-Pure package -- nothing wrong with that.  Of course, if the C
function is impure, you might get a surprise, but that's no different
than what happens if you get the parameter types and modes wrong.
In general, import is a programmer-beware feature, and we should not
place restrictions on it.  I say the same about machine code -- if your
machine has a "cosine" instruction, there's nothing wrong with using it
in a pragma-Pure place.

****************************************************************

From: Randy Brukardt
Sent: Thursday, February 5, 2004  7:34 PM

...
> > Bob said:
> >
> > > I do debugging/tracing output in pragma-Pure and pragma-Preelab packages
> > > all the time.  I have a debug package containing things like Put, and
> > > Put is declared ``pragma Import(Ada, Put, "Impure_Put");''. Impure_Put
> > > does the dirty work -- it is not with'ed by the debug package.  The
> > > debug package has pragma Pure, so can be used anywhere.
> >
> > That's also not portable (although more so); ...
>
> I think it *is* portable.  Convention "Ada" and the relevant pragmas are
> not optional features of the language.

I agree with that. But...

> You don't need any special
> linker options to get the impure part included -- just put a "with" of
> the impure version of the package somewhere in the program.

I don't agree with this. Not the inclusion part, but the notion that it
ought to work. You're declaring external code, and if your toolchain doesn't
support external code, then it isn't going to work even if all of the code
is actually in this program.

Keep in mind that I'm only interested (for the purposes of this discussion)
in what happens in an all-Ada program. Once you start bringing C and hardware
into the equation, all bets are off anyway.

...
> Another standard trick is to use Import(Ada) to suppress default
> initialization.  This is specified in RM-B.1(38), and mentioned in
> AARM-13.3(12.c) and B.1(38.a).

We support that, of course. I believe that there is special code to suppress
the linker symbol in such a case - if there wasn't, the program could never
link (because there is nothing that you are actually linking to).

But note that in this case you're not really using Import at all, because the
object still resides here, it's just not default initialized. (If you had the
object reside somewhere else, you couldn't use the feature in an all-Ada
program: how would you suppress default initialization at the location of
the actual object? Well, you'd have to apply Import again, and you'd have an
infinite regress.)

> >... most Janus/Ada compilers
> > standard mode is "no Import/Export".
>
> If you mean "pragma Import(Ada) is illegal in this mode, then you can
> make that the *default* mode if you like, but I don't think you can call
> it "standard". ;-)

No. You just can't link the program; it contains external references, and
the standard linker doesn't support external references.

> If you're talking about extra linker options, then
> fine -- but my ugly hack needs no extra linker options.

No again; you have to use a different toolchain. That's the problem.

Our compiler design is all-Ada top to bottom. The linker is of our own
design, and creates a executable directly (no other programs run). This is
the standard mode. That's not negotiable; we control the entire toolchain,
and that's a requirement if you're staking your business on it.

At a (much) later date, we added support for Import/Export. That was done
using a special linker that outputs the entire Ada program as one giant
system object file (complete with any Import/Export linker symbols), and
then is given to the system linker.

Now, the problem is you (Bob) are suggesting two uses for pragma Import:

    * To link to code somewhere else within the Ada program; and
    * To link to code external to the Ada program.

The fact that the convention is "Ada" doesn't really change this; you still
want to be to link to other, separate Ada (or assembler!) subsystems using
the system linker.

The problem is that there is no way to tell those apart; but they are using
*different* linkers. The "solution" is simply to assume that you are linking
to code external to the program (that works on internal code by accident);
but that implies that you are using the "secondary" toolchain. And it also
implies very substandard code (all imports call through thunks so that the
actual external reference occurs in only one place).

Even if, by some miracle, you could figure out which was which, it still
would be impossible, because the Ada linker does not use link names. It
simply uses address offsets, which of course change every time a change (or
even recompile with different switches) occurs to a spec. You can't put them
into "pragma Import" code because the only way to find out the right address
is to with the appropriate package -- which defeats the purpose of the
Import.

The beauty of Ada is that you *don't* have to depend on unreliable
code/tools from a whole bunch of unreliable vendors (just one unreliable Ada
vendor!) - you can do it *all* in Ada. Now, it obvious that sometimes you
need to access C, but (on Windows, at least) it's a lot rarer than people
make out. (I believe that you can run any Claw GUI program and almost any
Win32 program without any use of imported C code in the executable. Of
course, you're using the C code that makes up the Windows kernel - AdaOS
doesn't exist yet - but you need no Microsoft tools or code to create
running programs.)

We of course validated all of our compilers in the standard linker; we used
the alternate chain only on C interface programs. (With the exception of
Windows, for which the standard linker didn't exist when we validated.) I
would be *very* upset if that did not remain true.

****************************************************************