Version 1.8 of ais/ai-00366.txt

!topic Generic formal access types in Pure packages
!reference 10.2.1(16)
!from Adam Beneschan 11-27-02
!discussion


Is it the intent of 10.2.1(16) that a Pure package cannot declare a
nested generic with a generic formal access type?

Specifically, I believe the RM makes these two package declarations
illegal:

-- (1)
package pak1 is
   pragma Pure;
   generic
      type T1 is private;
      type T2 is access all T1;
   package genpack is
      procedure proc (x : in T2);
   end genpack;
end pak1;

-- (2)
package pak1 is
   pragma Pure;
   generic
      type T1 is private;
      type T2 is access all T1;
   procedure proc (x : in T2);
end pak1;

10.2.1(16) says, "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".  Both of these packages contain declarations of named
access types named T2.  I can't find anything in the RM that would
make declarations of generic formal types *not* fall under this rule;
the declaration of a generic formal type is clearly a "declaration",
and from everything I can tell, a generic formal type is a "type".
(In case (2), although the type declaration is within a
generic_subprogram_declaration, I don't think this is the same thing
as being "within a ... generic subprogram".)

However, my impression (which may be off base) is that the rule is
intended to prevent Pure packages from declaring new access types, and
a generic formal type doesn't fit this description.  So should
10.2.1(16) be amended to exclude generic formal access types?

By the way, GNAT accepts both of the above examples.

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

From: Christoph Grein
Sent: Wednesday, November 27, 2002  11:48 PM

Also Rational Apex 3.2.0b accepts them.

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

From: Pascal Leroy
Sent: Thursday, November 28, 2002   3:12 AM

I think that the two examples should be legal, and that the wording in
10.2.1(16) is lousy.  It would probably be good to fix it, although I would see
this as a low priority issue.

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

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 I. Eachus
Sent: Friday, February 6, 2004  5:39 PM

Robert Dewar wrote:

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

I argee with Robert Dewar.  That's what the "No. Feature Creep." in the
message was saying.  But the edited message as RBKD answered it is not
how it looked to me.  (It may just have been where the line breaks fell...)

To be clear, I thought I was seconding Robert Dewar's suggestion, and
noting that any support for other types in Standard could be pushed to
child packages if a vendor wanted to include such support.

I was also serious that in Ada 0Y we should at least require
Long_Integer and Long_Float.  Implementors who actually have only one
base integer or floating point type could just put in a renames. There
is little or no hardship for implementors there.  But I am writing more
and more code that uses Long_Float by default.  I've never had to modify
any of it to compile on a system that didn't support Long_Float, even
though such a modification is also trivial.  If everyone is supporting
Long_Float, why don't we say so?

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

From: Randy Brukardt
Sent: Friday, February 6, 2004  5:40 PM

Robert Dewar said:

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

I totally agree about the string-only stuff. I've been making do with a
single logger procedure, after all.

But the spec. you provided don't allow output to files. That won't do.
Virtually all of the programs I work on these days either run unattended
(web server, spam filter) or are GUI programs. In neither case, can you use
Standard_Output (the unattended programs because there is no screen, and the
logging is a permanent function used for debugging of production errors; the
GUI programs because having a standard output window on the screen can
interfere with the behavior that you are trying to debug -- or it is
unreadable, because it is underneath the program's windows).

So I think the package needs Open, Create, Close, and Delete. (But not
necessarily Name or Form or Reset, as those tend to make the implementation
harder). And I'd leave out Set_Output; it complicates things when you have
files and you certainly can work around not having it.

But the other operations are just about right.

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

From: Robert Dewar
Sent: Friday, February 6, 2004  5:44 PM

I agree that Long_Float should be unconditionally supported.

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

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.

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

From: Robert Dewar
Sent: Friday, February 6, 2004  4:12 PM

Randy Brukardt wrote:
> 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.

An exceedingly odd claim. Any real Ada compiler must depend on
proprietary tool chains to be any use at all in my view. Anyway
for sure this is off topic. I must say I agree with Bob Duff's view
here that pragma Import Ada must work as he expects.

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

Yes, both are reasonable, both should work

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

That's an artifact of your peculiar linking approach. The Ada design
clearly anticipates a conventional approach to linking.

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

Well as I say, I think you have chosen a model that makes it very
hard for you to do Import/Export correctly.

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

I don't buy this claim. I think your implementation (linking) approach
is fundamentally flawed, and the difficulties you are having with
Import/Export (Ada) are just a symptom of this.

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

I don't see any basis for upset. I suspect that virtually all Ada 95
compilers do Import/Export Ada the way Bob expects it to work, and in
fact it is a handy way of avoiding certain elaboration problems (very
low level and junky, but sometimes you need that).

Quite a few of the DEC tests use this capability, so ACT was actually
contractually obligated to get this working (of course it worked out
of the box, if you use a standard linking approach, it will).

I think the approach Randy describes is suitable for Ada 83, but not
for Ada 95. That is, I agree with him that it seems very hard to make
this approach work properly.

Perhaps we should indeed discuss this in the ARG, and decide what is
and what is not supposed to work in this regard.

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

From: Randy Brukardt
Sent: Friday, February 6, 2004  5:28 PM

Robert Dewar wrote:

> Randy Brukardt wrote:
> > 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.
>
> An exceedingly odd claim. Any real Ada compiler must depend on
> proprietary tool chains to be any use at all in my view.

Why? It wasn't necessary for CP/M and MS-DOS, it isn't necessary for Windows
(you can access all of Win32 and any DLL without using any Microsoft or
other tool), and it certainly isn't necessary for bare machines. The only
place that I'm familiar with that it *is* necessary is on Unix/Linux
systems - and I consider that a design fault in those systems. (It is
actually possible to build a full Ada compiler on Intel ABI machines without
using any stuff from any Unix - our SCO compiler did exactly that - but I
wouldn't do it again because too much stuff is implemented in the C
libraries rathe in the Kernel.)

Indeed, I don't see any Microsoft tools used in the Windows version of GNAT.
You can use it out of the box to make programs for Windows without getting
anything else. So what proprietary tools do you need?

...
> > 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.)
>
> I don't buy this claim. I think your implementation (linking) approach
> is fundamentally flawed, and the difficulties you are having with
> Import/Export (Ada) are just a symptom of this.

Fine. I want an all-Ada world as much as possible. I realize the current
state of the world makes that impractical most of the time. But I don't
believe for a minute that the standard insists on anything that would make
it impossible to have an all-Ada world. If we cannot at least strive for a
more perfect world

> > 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.
>
> I don't see any basis for upset. I suspect that virtually all Ada 95
> compilers do Import/Export Ada the way Bob expects it to work, and in
> fact it is a handy way of avoiding certain elaboration problems (very
> low level and junky, but sometimes you need that).

It is exceedingly bad practice to have dependencies within an Ada program
not documented in the context clause. I see absolutely no reason to
encourage that - even if, as a practical matter, you'll need to once in a
great while do something exceedingly bad. (In which case, you can use the
alternative toolchain set up for that purpose. Just don't ask us to validate
it - once you're depending on unknown external code, there is essentially
nothing we can do to insure correctness.) Any rep. clause pointing inside of
the Ada code itself is a terrible idea. [I know people do this as a
workaround for "in out" function parameters, for example, but I find that
horrific -- fix the root problem (using the wrong mode on the parameter),
don't stand on your head. And lobby to get the language fixed...]

> I think the approach Randy describes is suitable for Ada 83, but not
> for Ada 95. That is, I agree with him that it seems very hard to make
> this approach work properly.

In general, approaches that worked for Ada 83 were supposed to continue
working in Ada 95. We explicitly pointed out where we expected that *not* to
be true. I would consider anything in the standard that make requirements to
the contrary to fall under the Dewar rule "the standard never says anything
silly".

...
> Perhaps we should indeed discuss this in the ARG, and decide what is
> and what is not supposed to work in this regard.

I think that this would be a particularly bad use of the ARG's time. I can't
imagine anything good that would come out of such a discussion - any
conclusion is going to be considered very bad by someone, and I certainly
don't hear users complaining about this issue.

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

From: Robert Dewar
Sent: Friday, February 6, 2004  6:38 PM

Randy Brukardt wrote:

>>An exceedingly odd claim. Any real Ada compiler must depend on
>>proprietary tool chains to be any use at all in my view.
>
> Why? It wasn't necessary for CP/M and MS-DOS,

Most people would not consider those operating systems, and you
were talking about Ada 83, not Ada 95.

  it isn't necessary for Windows

You are arguing in a circular manner. You argue that the language
allows your approach, which then validates the approach, which you
then use to invalidate an important feature of the language (export
import Ada).

>>Perhaps we should indeed discuss this in the ARG, and decide what is
>>and what is not supposed to work in this regard.

> I think that this would be a particularly bad use of the ARG's time. I can't
> imagine anything good that would come out of such a discussion - any
> conclusion is going to be considered very bad by someone, and I certainly
> don't hear users complaining about this issue.

You might be right, I think the major complete language Ada 95 compilers
do in fact fully implement pragma import/export for Ada anyway.

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

From: Randy Brukardt
Sent: Friday, February 6, 2004  6:57 PM

Robert Dewar:
>   it isn't necessary for Windows
>
> You are arguing in a circular manner. You argue that the language
> allows your approach, which then validates the approach, which you
> then use to invalidate an important feature of the language (export
> import Ada).

Well, clearly the problem is the "important feature of the language".

I view Import/Export Ada to be something of no particular value that
naturally fell out of the other definitions (sort of like non-binary modular
types). It's for external interfacing to other Ada subsystems: a very rare
event. Some people have found a way to abuse this capability in order to
end-run Ada's protections.

> >>Perhaps we should indeed discuss this in the ARG, and decide what is
> >>and what is not supposed to work in this regard.
>
> > I think that this would be a particularly bad use of the ARG's time. I
can't
> > imagine anything good that would come out of such a discussion - any
> > conclusion is going to be considered very bad by someone, and I
certainly
> > don't hear users complaining about this issue.
>
> You might be right, I think the major complete language Ada 95 compilers
> do in fact fully implement pragma import/export for Ada anyway.

Certainly Janus/Ada does: but only if you use the alternative toolchain. And
we don't provide or support the external parts (i.e. the ones from
Microsoft) needed for that. And that's not a problem for customers: if
you're going to link C code, you need a C compiler anyway. But I don't want
to have to make Ada-only customers have to purchase full-blown development
systems from elsewhere, and I don't want our validations depending on tools
that we don't provide or support.

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

From: Robert Dewar
Sent: Friday, February 6, 2004  7:17 PM

Randy Brukardt wrote:

> Some people have found a way to abuse this capability in order to
> end-run Ada's protections.

Sounds like you are saying you don't like the feature. OK, everyone
has that privilege, but it is part of the language, and its ability
to bypass in a very deliberate way protections that are in the language
is useful, just as address overlays are useful. In any case, the
feature is there, it must be implemented whether you like it or not :-)

> Certainly Janus/Ada does: but only if you use the alternative toolchain. And
> we don't provide or support the external parts (i.e. the ones from
> Microsoft) needed for that.

OK that's fine.

> And that's not a problem for customers: if
> you're going to link C code, you need a C compiler anyway. But I don't want
> to have to make Ada-only customers have to purchase full-blown development
> systems from elsewhere, and I don't want our validations depending on tools
> that we don't provide or support.

Well to validate import/export, you need external compilers anyway,
so I don't know what you are talking about here. The ACATS tests
have non-Ada in them.

It seems perfectly fine to tell your users that to use pragma
Import/Export Ada they need the alternative toolchain.

I do think the ACATS tests should test Import/Export Ada, since
this is definitely a feature that is used, and I consider it an
important feature.

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

From: Randy Brukardt
Sent: Friday, February 6, 2004  7:55 PM

Robert Dewar:

> Sounds like you are saying you don't like the feature. OK, everyone
> has that privilege, but it is part of the language, and its ability
> to bypass in a very deliberate way protections that are in the language
> is useful, just as address overlays are useful.

Another mis-feature that ought to be restricted as much as possible. As with
Imports, the danger  is creating an overlay by accident. I'd prefer users
that have to put "pragma Warranty_Void();" on any address overlays before
they'd work. :-)

...
> Well to validate import/export, you need external compilers anyway,
> so I don't know what you are talking about here. The ACATS tests
> have non-Ada in them.

We used "special options" (which actually was a completely different set of
programs) for the Interface C tests. The reason was the need to link foreign
language code. That reason would not apply to Import/Export Ada.

> It seems perfectly fine to tell your users that to use pragma
> Import/Export Ada they need the alternative toolchain.
>
> I do think the ACATS tests should test Import/Export Ada, since
> this is definitely a feature that is used, and I consider it an
> important feature.

Well, given the budget of the ACAA, and the feeling of vendors, I doubt that
there is going to be many (if any) new ACATS tests on Ada other than those
steming from the Corrigendum and (soon) the Amendment. There are lots of
core rules (supposedly 30%, although I think the actual number of testable
ones is more like 10%) that matter to users (read-only access to protected
components from functions, for one example) that are untested - it's hard to
imagine how to choose what ought to be tested. Vendors don't want hundreds
of new tests.

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

From: Robert Dewar
Sent: Friday, February 6, 2004  3:40 PM

Making Text_IO preelaborated is far too big a change, it might result in
a need for a radical reimplementation. There is simply nothing to justify
such a huge change.

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

From: Pascal Leroy
Sent: Tuesday, March 16, 2004  7:30 AM

A quick note following the discussion of AI 366 at the last meeting:
imported objects should be excluded from the restrictions in 10.2.1(9),
as no initialization takes place for these objects (B.1(38)).  This
change would make it possible to write preelaborable units that
reference objects exported from the runtime system.  Not that any user
would want to do that, but implementers might want to do it, for
instance to implement some of the "Alan packages".

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

From: Robert Dewar
Sent: Saturday, March 20, 2004  7:54 PM

Well I am dubious about the idea of semantics that are useful
only for implementors, but if this is the case, implementors
can do anything they like anyway within the run time library,
since it does not have to be in Ada at all.

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

From: Robert A. Duff
Sent: Sunday, March 21, 2004  11:35 AM

True, but why force implementors to have (another?) special case in
their compilers, of the form "if we're compiling the run-time system
then ... else ... end if;"?

Anyway, I'm not sure I believe that the proposed rule is useful only for
implementors.  Pascal pointed out one usage (which is for implementors),
but the feature in question is harmless and natural, and therefore might
be useful for anybody.

The wording of 10.1.2(9) talks about a "default-initialized object",
so it seems pretty silly to forbid imported objects, since they
are not, in fact, initialized by default.

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

From: Erhard Ploedereder
Sent: Sunday, April 18, 2004  9:47 AM

Editorial on the minutes: 10.1.2(18) -> 10.2.1(18) twice, in the discussion
of AI-366.

More importantly...I have significant problems with Pascal's notion that
imported objects should be allowed in pure units. While they do not need
elaboration, they are accessible state. If they were allowed, I could write
a "pure" random-number generator by merely hiding the state behind the
import. The optimizing permissions of 10.2.1(18) would then allow an
implementation to always return the same initial number.

This does not make sense to me. State is state, imported or not. Am I wrong ?

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

From: Pascal Leroy
Sent: Sunday, April 18, 2004  9:58 AM

I was proposing (I think) of allowing them in *preelaborated* units.  There
are currently restrictions on what objects you can declare in a
preelaborated unit.  I was proposing to allow imported objects because they
have essentially no initialization.

I realize that the AI is currently only talking about *pure* units, but I
was thinking that, while you are in the vicinity, you might be willing to
fix another oddity regarding categorization.

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

From: Tucker Taft
Sent: Sunday, April 18, 2004  10:29 AM

Note that it is permissible to call Import'ed subprograms
in a pure unit, and I hope you don't decide to close
*that* loophole.  We use it frequently as a way to sneak
debugging I/O into pure units.  Obviously it is "caveat
emptor" and the compiler would be allowed to eliminate
calls on such imported subprograms if they satisfied the
requirements, so it is inherently non-portable.  But
that seems fine for this kind of back door.

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

From: Robert A. Duff
Sent: Sunday, April 18, 2004  10:45 AM

I agree with that.

However, I also have a more general comment: Even when one is not doing
evil deeds like the above, the philosophy of Import should always be
that the *programmer* is in charge of making sure the other-language
code obeys the rules.  We should never forbid Import just because you
*might* use it to bypass normal rules.

For example, I want to be able to call pure C functions from pragma Pure
packages.  Of course, if I lie about the purity, all bets are off.

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

From: Robert Dewar
Sent: Sunday, April 18, 2004  11:13 AM

Right, this is such a huge "loop hole" that no other
objections based on loop hole worries are serious :-)

Indeed it is this loop hole that makes it necessary
to have the IA that says that you can treat functions
in pure units as being pure when in fact you know
no such thing from the categorization itself.

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

From: Robert Dewar
Sent: Sunday, April 18, 2004  11:18 AM

> However, I also have a more general comment: Even when one is not doing
> evil deeds like the above, the philosophy of Import should always be
> that the *programmer* is in charge of making sure the other-language
> code obeys the rules.  We should never forbid Import just because you
> *might* use it to bypass normal rules.

I disagree, it is perfectly legitimate to "disobey" the rules. For
example, suppose you have a sqrt function which you want the compiler
to treat as pure, but you want to instrument it to see how often it
is called with an argument that is less than some number. It is just
fine to have the "pure" function call an imported function (which
can be in Ada in a non-pure unit) that increments a counter.

> For example, I want to be able to call pure C functions from pragma Pure
> packages.  Of course, if I lie about the purity, all bets are off.

No, not all bets. It is simply that the implementation permission
applies for deleting calls with identical arguments. No bets, and
nothing uncomfortable. Just a well defined consequence of designating
the unit as pure.

Now you might argue that the scenario I give above for square
root should be achievable without such subterfuge. Perhaps, but
the status quo is quite acceptable, and extending what is allowed
is quite reasonable.

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

From: Erhard Ploedereder
Sent: Wednesday, April 21, 2004  1:54 PM

To summarize what I have heard...

a) Imported Variables are to be allowed for Preelaborable/ated units.  (Makes sense.)
b) Imported subprograms are allowed in Pure units. (Sure. They are. No problem.)

I am not so sure what I heard about imported variables. The discussion got
railroaded to the unendangered species of imported subprograms.

I maintain that lying, as may be the case for b), should not be o.k. in the
presence of immediate and manifest evidence that "it ain't so" (and caveat
emptor in the absence of such evidence). Imported variables say "it ain't so"
to me and hence no pragma Pure, please, in their presence.

Silence implies consent :-)

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

From: Robert A. Duff
Sent: Wednesday, April 21, 2004  2:55 PM

Silence.

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

From: Tucker Taft
Sent: Wednesday, April 21, 2004  3:42 PM

I see no reason to allow library-level variables in
a pure package, imported or otherwise.

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

From: Pascal Leroy
Sent: Thursday, April 22, 2004  2:10 AM

That's exactly right.  I never asked for variables in pure units.

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

From: Randy Brukardt
Sent: Friday, April 23, 2004  9:04 PM

I had homework to pool implementers about making System Pure. In researching
that, I found that AI-126 (the old categorization AI) said that System was
not to be made Remote_Types because "...transportation of type Address
[between partitions] makes no sense." Pure packages are, of course, allowed
to be depended on in the interfaces of distributed programs. So making
System Pure would effectively make it a Remote_Types package, and allow the
transportation of System.Address.

I was just going to mention this in in the context of AI-362, but then I got
a response from Tucker: "...type Address is an access type (visibly it is a
private type). If we have the notion of a "pure" access type..." This set
off alarm bells!!

The entire clause E.2 (including subclauses) is written assuming that Pure
packages do not contain access types. A primary reason for having
Remote_Types packages appears to be so that we can apply a requirement for
user-defined Read and Write attributes to access types in the visible
specification of such packages. If we are allowing access types in Pure
units, we are essentially allowing the existence of access types that (a)
can be transported between partitions; and (b) are not necessarily set up to
provide such access.

I don't have any brilliant ideas of how to circumvent this problem. The best
I can come up with would be to require pragma Remote_Types on Pure packages
containing access types before they can be depended on in a distributed
system. But that makes a mess out of the hierarchy.

Considering that there is only one vendor supporting Annex E, it would be
aggravating to have to abandon AIs 362 and 366 because of Annex E
concerns -- but it would be unfair to that vendor and its users to simply
ignore Annex E.

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

From: Tucker Taft
Sent: Friday, April 23, 2004  9:41 PM

There seem two possible solutions:

1) Require that a Pure package containing an access type
    to *also* have a Remote_Types pragma applied to it if
    it is to be depended-on in a distributed program

or

2) Require that an access type declared in a Pure package
    satisfy the requirements of the Remote_Types pragma, namely
    that it include overridings of the Stream attributes.

Either would seem to solve the problem.  The latter solution
has the advantage of not requiring a change to annex E,
while the former has the advantage of preventing System from
being used in a distributed system, while still being Pure.

I have a slight preference for (1), because equating Pure with
"safe for use in distribution" has been a bit of a pain anyway.
This would establish the principle that Pure is only part of
the requirement.  The more important requirements are those
associated with Remote_Types.  So long as a Pure package has
no access types, then it automatically qualifies as Remote_Types.
Also, providing a bogus overriding of Address'Read/Address'Write
in package System just to satisfy Remote_Types requirements seems
a bit weird, and potentially misleading.

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

From: Robert I. Eachus
Sent: Saturday, April 24, 2004  12:20 AM

I have a strong preference for (3) Recognize that not all Pure packages
are appropriate for sharing between partitions, and fix the problem of
Pure being considered a categorization pragma in E.2.   This would
require that we go through the current Pure packages and decide which,
if any, categorization pragmas should be required for them.  Any other
fix results in the distributed annex tail wagging the real-time systems dog.

And yes, I know that some embedded systems are actually distributed
systems, I've worked on several such.  Even in that environment, Pure
has a lot more to do with elaboration and other real-time issues than
with distribution.  It just happens that most Pure units are in effect,
shared passive units as well.  I like the idea of making the operators
for Address pure.  But I agree that comparing Address values from
different partitions, even if they are running on the same hardware, is
nonsense.  (And no implementor should be required to do anything with
such a call.)  So System cannot be required to be shared passive, and
shouldn't even be a remote types package.  If we take this approach,
implementors can be allowed to apply a categorization pragma to System,
but it would be required to be Pure.

How much burden would this put on current users of Annex E?  Some
packages now declared Pure would need pragma Shared_Passive added.
Doing that for all current (non-system) packages currently used in a
distributed program should be fairly trivial.  Of course the implementor
of such a program could take advantage of the new orthogonality, but
that is not a upward compatibility issue.

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

From: Robert Dewar
Sent: Saturday, April 24, 2004  5:54 AM

In GNAT System is already Pure, as permitted by the RM. Are
there really Ada 95 compilers that do NOT take advantage
of this permission.

I find the arguments about addresses bogus. Addresses
are nothing to do with access types.

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

From: Robert Dewar
Sent: Saturday, April 24, 2004  6:00 AM

I must say I don't see any reason not to pass addresses between
partitions, addresses are simply private types with very limited
use if you think of uses that are clearly defined and portable.

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

From: Robert A. Duff
Sent: Saturday, April 24, 2004  7:55 AM

> I had homework to pool implementers about making System Pure. In researching
> that, I found that AI-126 (the old categorization AI) said that System was
> not to be made Remote_Types because "...transportation of type Address
> [between partitions] makes no sense."

Sounds like a bogus reason, to me.  Lots of things having to do with
Address "make no sense", but it's not our job to legislate against
them.  Forbidding useful stuff ("with System;" on a pragma-pure package)
in order to prevent useless stuff is not good language design.

Whether or not it makes sense to transport addresses across partitions
is entirely implementation dependent.  (It *could* make sense -- some
distributed systems have shared memory.)

Our compiler (SofCheck's AdaMagic) has pragma Pure in package System,
except in the Java-byte-code target.  And I know GNAT has a pragma-Pure
System.  This has not caused the sky to fall, so far.

So I'm in favor of requiring System to be Pure.  Why didn't we do that
in the first place?  The AARM doesn't say.

----------------

At first, I was confused by Randy's note -- I didn't notice the subject,
and I thought the issue was the above-mentioned Address issue.
Apparently Robert Dewar had the same confusion.  I eventually figured
out that the *main* issue is AI-366, which says that pragma-Pure
packages can contain access types.  That does seem like a problem, and I
agree with the solution suggested by both Randy and Tuck.  Randy said:

> The best
> I can come up with would be to require pragma Remote_Types on Pure packages
> containing access types before they can be depended on in a distributed
> system.

That's a kludge, but disconnecting Pure from Remote_Types (which is what
we should have done in the first place) is not upward compatible.

I don't like Tucker's other suggestion of requiring me to write useless
attribute subprograms in non-distributed programs.

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

From: Robert Dewar
Sent: Saturday, April 24, 2004  8:14 AM

> So I'm in favor of requiring System to be Pure.  Why didn't we do that
> in the first place?  The AARM doesn't say.

I 100% agree, and I agree with all Bob's reasoning here.

The great strength of Ada is that in normal usage it is safe (like Java,
an unlike C++) but there are escape hatches that allow you to do what
you want in specialized circumstances (unlike Java).

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

From: Robert I. Eachus
Sent: Saturday, April 24, 2004  11:57 AM

>Whether or not it makes sense to transport addresses across partitions
>is entirely implementation dependent.  (It *could* make sense -- some
>distributed systems have shared memory.)

Transporting addresses across partitions may make sense, and I am not
adverse to allowing it.  Requiring a lot of extra cruft in the final
compiled program to support it if the user has no intention of using
it?  THAT is a problem.  If I were implementing 'Read and 'Write for
Addresses on a system that supported virtual to physical address
conversions, I would expect that to be done either right by default, or
not at all so users who need the functionality can add it.  As I see it
that is the issue with transporting Address values across partitions.
(I could make a simliar argument for passing Address values between CPUs
without shared memory, but I hope no one would implement that by default.)

>>The best
>>I can come up with would be to require pragma Remote_Types on Pure packages
>>containing access types before they can be depended on in a distributed
>>system.
>
>That's a kludge, but disconnecting Pure from Remote_Types (which is what
>we should have done in the first place) is not upward compatible.

I agree that it is not purely upward compatible, but I just don't see
the incompatibility as justifying such a big wart.  IF we require
categorization pragmas on Pure units that are shared between partitions,
it should only affect user defined pure packages that are currently used
in distributed programs.  And the fix that can be done in a porting tool
is a simple text replacement.  Change "pragma Pure;" to "pragma Pure;
pragma Shared Passive;"

The advantage to fixing the problem right is more than making E.2 easier
to write.  Now it becomes natural to allow access types in pure
packages, and those not using the distributed annex immediately have
additional programming power.  If anyone that wants to use such a pure
unit in a distributed environment, he can use the correct categorization
pragma.  Much better for all concerned than saying that a pure package
is shared passive unless it declares an access type somewhere.  That
looks like a pretty nasty contract model violation.  What happens if
there is such a type in the private part?  What about pure packages that
depend on other pure packages that define an access type?

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

From: Erhard Ploedereder
Sent: Monday, May 17, 2004  5:20 PM

Context: I was asked to add words to AI-366 so that imported objects are
preelaborable.

Now I am confused. 99.9% of imported objects are preelaborable today, as far
as I can tell from the RM.  The only relevant sentence that I could find is
10.2.1(9) -- and I claim that almost all imported objects are not of a type
cited here:
---- << preelaborabe units may not include... >>
* The creation of a default-initialized object (including a component) of a
descendant of a private type, private extension, controlled type, task type,
or protected type with entry_declarations; similarly the evaluation of an
extension_aggregate with an ancestor subtype_mark denoting a subtype of such
a type.
----

o.k., our imported object could be "of a descendent of a private type", but
as far as the rest goes, really very very unlikely.

I propose to do nothing here.

If you feel different, please comment also on the re-write below:
------
* The creation of a default-initialized object (including a component) of a
descendant of a private type, private extension, controlled type, task type,
or protected type with entry_declarations, unless a pragma Import applies to
the object (see B.1); similarly the evaluation of an
extension_aggregate with an ancestor subtype_mark denoting a subtype of such
a type.
------

(Incidently: this is the only occurrence of the term "default-initialized"
 in the normative part of the RM; one more in a note of 3.8. Not exactly a
 well defined term :-) )

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

From: Gary Dismukes
Sent: Monday, May 17, 2004  7:16 PM

> If you feel different, please comment also on the re-write below:

I agree, there doesn't seem a need to change anything here, and
adding special treatment in 10.2.1(9) for imported objects doesn't
seem worthwhile.

Since Pascal raised this issue, I guess he'll need to speak up if he
thinks there's still an issue that needs to be addressed for imported
objects in preelaborated packages.

> (Incidently: this is the only occurrence of the term "default-initialized"
>  in the normative part of the RM; one more in a note of 3.8. Not exactly a
>  well defined term :-) )

Note that AI-161 modifies 10.2.1(9) so that it's framed in terms of
the new notion of types that have "preelaborable initialization".

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

From: Pascal Leroy
Sent: Tuesday, May 18, 2004  1:49 AM

> I propose to do nothing here.

Having proposed this change you won't be surprised to hear that I disagree.

> * The creation of a default-initialized object (including a component) of a
> descendant of a private type, private extension, controlled type, task type,
> or protected type with entry_declarations, unless a pragma Import applies to
> the object (see B.1); similarly the evaluation of an
> extension_aggregate with an ancestor subtype_mark denoting a subtype of such
> a type.

Sounds good to me.

> (Incidently: this is the only occurrence of the term "default-initialized"
>  in the normative part of the RM; one more in a note of 3.8. Not exactly a
> well defined term :-) )

I believe (but I didn't check) that this was clarified/discussed in the AI
that defines pragma Preelaborable_Initialization.

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

From: Erhard Ploedereder
Sent: Tuesday, May 18, 2004  6:45 AM

Pascal wrote wrt AI-366:
> Having proposed this change you won't be surprised to hear that I disagree.

Having looked now at the wording of AI-161 (and B.1(38), which states that
an imported object is not created -- under a "notwithstanding" rule),
all imported objects are preelaborable today and under AI-161.

We need not change anything. Hence, consider my "unless clause" for 10.2.1(9)
withdrawn from consideration.

It might be worth a Note or an AARM annotations to spell out this
ramification for imported objects. I leave that to the author of AI-161.

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

From: Tucker Taft
Sent: Thursday, May 27, 2004  6:43 PM

> Replace 10.2.1(18) with

> If a library unit is declared pure, then the implementation is
> permitted to omit a call on a library-level subprogram of the library
> unit if the results are not needed after the call.  In addition, the
> implementation may omit a call on such a function and simply reuse the
> results produced by an earlier call on the same function, provided
> that none of the parameters nor any object accessible via access
> values from the parameters are of a limited type, and the addresses
> and values of all by-reference actual parameters, the values of all
> by-copy-in actual parameters, and the values of all objects accessible
> via access values from the parameters, are the same as they were at
> the earlier call. This permission applies even if the subprogram
> produces other side effects when called.

The uses of the word "function" in the above paragraph should be
changed to "subprogram."

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

From: Randy Brukardt
Sent: Thursday, May 27, 2004  7:05 PM

The !discussion should say something about the reasons for revising 10.2.1(18).
Therefore, I added the following to the !discussion:

Allowing access types in Pure units means that the permission of 10.2.1(18)
needs to be revised. The intent of the permission is that calls can be omitted
only if it is safe (ignoring possible side-effects) because the parameters are
the same. When access types are included, it is necessary to include the
designated values in this check; otherwise, the designated values could be
changed and the call still omitted. For instance, we do not want to allow the
omission of calls on a Pure random number generator!

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

From: Erhard Ploedereder
Sent: Monday, August 30, 2004  5:53 PM


I tried fairly hard to figure out the right wording for AI-366 in accordance
with the minutes of the last meeting, where it was decided that we should
require Read/Write for private types in pure packages that are or include
access types, and to require same for the visible types if used in RCI
packages.

Rather than incorporating the results in the AI directly, I give you the
proposed wording separately for discussion at the next meeting. See my
comments why I did this.

Erhard

----------------------------

Add after the revised 10.2.1(16):

  If the full view of a private type declared in the visible part of the
  library unit is a non-remote access type (see E.2.2) or has a part that is of a
  non-remote access type, then that access type, or the type of some part
  that includes the access type subcomponent, shall have user-specified Read and Write
  attributes.

<<< Comments:
1. the "non-remote" part seems necessary, since remote type
   packages can be pure and for remote access types E.2.2(8) poses the
   requirement already on all access types, not just the private ones.
2. E.2.2(17/1) has me seriously worried, since the expanded rule for "pure"
   requires STORAGE_SIZE to be 0, but E.2.2 (17/1) says that the attributes
   are not defined at all for the interesting remote access types. Probably that
   para would need a change, too.
3. The terminology of E.2.2(8) - inherited by this rule and the one below -
   of talking about "views of types having a part that is of an access type"
   is particularly mysterious to me. Does "type X is access Integer" have a
   part that is of an access type ? I guess not, but in that case E.2.2
   does not require user-defined Read/Write attributes on remote access
   types. Interesting and surprising (to me).
   >>>


Change E.2.3(14.1) from

* it shall not be, nor shall its visible part contain, a subprogram
  (or access-to-subprogram) declaration whose profile has an access
  parameter, or a formal parameter of a limited type unless that
  limited type has user-specified Read and Write attributes;

to

* it shall not be, nor shall its visible part contain, a subprogram
  (or access-to-subprogram) declaration whose profile has an access
  parameter, or a formal parameter of a limited type unless that
  limited type has user-specified Read and Write attributes, or a
  formal parameter of a type that is a non-remote access type or
  has a part that is of a non-remote access type, unless that access
  type, or the type of some part that includes the access type
  subcomponent, has user-specified Read and Write attributes.

<<< Comments: I find these rules WAY TOO complicated; I don't fully
understand them myself and I am not sure by any degree that they are
correct and complete. Admittedly, the whole streaming area is not my
forte, so it may seem simpler to you. In any case, these wordings need
close scrutiny by better streaming experts.
>>>

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

From: Randy Brukardt
Sent: Monday, August 30, 2004  8:51 PM

> 3. The terminology of E.2.2(8) - inherited by this rule and the one
below -
>    of talking about "views of types having a part that is of an access
type"
>    is particularly mysterious to me. Does "type X is access Integer" have
a
>    part that is of an access type ? I guess not, but in that case E.2.2
>    does not require user-defined Read/Write attributes on remote access
>    types. Interesting and surprising (to me).
>    >>>

"Part" is of course a technical term, defined in 3.2(6) [I found this
definition by looking in the index, as Bob always used to say]. "Part"
includes the whole object or value as well as any subcomponents. If you
don't want to include the object itself, you say "subcomponent" (which was
not done here).

Therefore, it's obvious that "type C is access Integer" has a part that is
of an access type, and the rule applies.

...
>* it shall not be, nor shall its visible part contain, a subprogram
>  (or access-to-subprogram) declaration whose profile has an access
>  parameter, or a formal parameter of a limited type unless that
>  limited type has user-specified Read and Write attributes, or a
>  formal parameter of a type that is a non-remote access type or
>  has a part that is of a non-remote access type, unless that access
>  type, or the type of some part that includes the access type
>  subcomponent, has user-specified Read and Write attributes.

As noted above, the "that is a non-remote access type" is redundant, as it
is covered by "part". So the wording can be simplified to:

* it shall not be, nor shall its visible part contain, a subprogram
  (or access-to-subprogram) declaration whose profile has an access
  parameter, or a formal parameter of a limited type unless that
  limited type has user-specified Read and Write attributes, or a
  formal parameter of a type that has a part that is of a non-remote
  access type, unless the type of some part that includes the access
  type has user-specified Read and Write attributes.

I'm not going to claim that this is a lot more understandable, but less
wording is usually better...

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