CVS difference for ais/ai-00366.txt

--- ais/ai-00366.txt	2004/04/06 19:57:16	1.5
+++ ais/ai-00366.txt	2004/04/30 02:35:39	1.6
@@ -1263,3 +1263,380 @@
 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?
+
+****************************************************************
+