CVS difference for ai12s/ai12-0079-1.txt

Differences between 1.20 and version 1.21
Log of other versions for file ai12s/ai12-0079-1.txt

--- ai12s/ai12-0079-1.txt	2018/10/19 05:50:47	1.20
+++ ai12s/ai12-0079-1.txt	2018/11/13 05:47:38	1.21
@@ -3370,3 +3370,96 @@
 means using Ownership.
 
 **************************************************************
+
+From: Tucker Taft
+Sent: Friday, October 19, 2018  10:10 AM
+
+If parameter modes lie, it certainly makes it hard to know what is the net
+effect of making a call, especially if there are hidden pointers providing
+read/write access to the object being passed as an IN parameter.  Now that we
+allow "in out" for functions, why not own up to that and change the parameter
+mode for things like function Random?
+
+I suppose we could always assume the worst for objects of a limited private (or
+inherently limited) type, and perhaps that is the right answer.  Even an IN
+parameter of a limited private type must be assumed to be updated as a
+side-effect of any call.  Eventually we will want a way to be more explicit
+about what is referenced and what is modified, both to handle these weird lying
+parameter modes, and to be more precise as far as which components are updated
+(I suppose the "stable properties" might be of some help here for private
+types).
+
+So I suppose the bottom line for a subprogram with an IN parameter of a limited
+type, is that the parameter might be updated internally.  That means that doing
+two calls in parallel on a subprogram with IN parameters of a limited type will
+be considered a potential data race, unless we invent more annotations.
+
+And this means that the "transitivity" of read-only access from a composite
+object to its owning access components would not apply to objects of a limited
+type.  But I think it should definitely apply to composite types that are non
+limited, or else parameter modes are useless for the purposes of distinguishing
+read-only from read/write.
+
+**************************************************************
+
+From: Randy Brukardt
+Sent: Friday, October 19, 2018  4:26 PM
+
+> If parameter modes lie, it certainly makes it hard to know what is the
+> net effect of making a call, especially if there are hidden pointers
+> providing read/write access to the object being passed as an IN
+> parameter.  Now that we allow "in out"
+> for functions, why not own up to that and change the parameter mode
+> for things like function Random?
+
+Changing the mode breaks calls, because functions, aggregates, and literals
+cannot be passed to such things. (Functions usually being the most common.) Not
+sure if that would be a real problem for Random (it sure would make the
+implementation cheaper), but there is definitely a compatibility concern.
+
+> I suppose we could always assume the worst for objects of a limited
+> private (or inherently limited) type, and perhaps that is the right
+> answer.  Even an IN parameter of a limited private type must be
+> assumed to be updated as a side-effect of any call.  Eventually we
+> will want a way to be more explicit about what is referenced and what
+> is modified, both to handle these weird lying parameter modes, and to
+> be more precise as far as which components are updated (I suppose the
+> "stable properties" might be of some help here for private types).
+
+Yes, since a lot of people have structured their packages similarly to the Ada
+I/O designs, and those use "in" and "in out" for a vastly different meaning than
+"read-only" and "read-write".
+
+Claw would be a lost cause with such a rule, but that's probably irrelevant,
+since (A) Claw is already task-safe so long as the Claw objects are disjoint
+(and we use locking when there are internal conflicts between different
+objects); (B) no one is going to want to write windows in parallel loop anyway.
+(There aren't many windows with thousands of distinct visual elements!)
+
+> So I suppose the bottom line for a subprogram with an IN parameter of
+> a limited type, is that the parameter might be updated internally.
+> That means that doing two calls in parallel on a subprogram with IN
+> parameters of a limited type will be considered a potential data race,
+> unless we invent more annotations.
+
+Might want to do that (more annotations) in the future, but we're pretty much
+out of time now.
+
+Our Claw design considers any operation on a specific claw object as a data
+race, and we don't try to prevent data races (those are considered erroneous).
+The parameter mode is not considered, which is essentially the same as the rules
+for language-defined units in the intro to Annex A.
+
+> And this means that the "transitivity" of read-only access from a
+> composite object to its owning access components would not apply to
+> objects of a limited type.  But I think it should definitely apply to
+> composite types that are non limited, or else parameter modes are
+> useless for the purposes of distinguishing read-only from read/write.
+
+Sounds like a plan, but we still have to do something about the source of an
+owned pointer assignment being any object that is treated as constant by this
+rule (including everything that actually *is* constant). Since an owned pointer
+assignment is really a move, the source gets modified as well as the target. And
+we better not be modifying constants!
+
+**************************************************************

Questions? Ask the ACAA Technical Agent