CVS difference for ai05s/ai05-0023-1.txt

--- ai05s/ai05-0023-1.txt	2007/04/06 04:37:11	1.2
+++ ai05s/ai05-0023-1.txt	2007/04/11 00:57:09	1.3
@@ -725,3 +725,271 @@
 
 ****************************************************************
 
+From: Randy Brukardt
+Date: Thursday, April 5, 2007  11:35 PM
+
+A comment on AI05-0023/02:
+
+I'm not very happy with the required temporary in S'Read. S'Read should default
+to build-in-place; that was done, the horribly complex second permission for
+S'Input wouldn't be necessary. OTOH, it may be too hard to describe that;
+but essentially I would use the semantics you describe for the permission
+as the canonical ones, and then allow a temporary to be created and assigned
+instead. If that doesn't work, I think you need to say something in the
+description about why.
+
+I also don't like that you appear to be *requiring* a temporary to be built
+if the discriminants change. If the implementation can handle build-in-place
+with changed discriminants, it should be allowed to do so. We'd allow an
+assignment temporary to be removed in this case, why not here?
+[I'm also dubious about the early Constraint_Error, as that would make it hard
+to keep a stream in sync. It could be a security issue. But that I'll leave for
+another time.]
+
+I completely hate the description of the second implementation permission.
+I think it is important to recognize that it is OK to combine the two operations
+if both S'Read and S'Input are the default versions, but I don't think that much
+else needs to be said. If the canonical semantics was to not declare a temporary,
+you wouldn't need this at all. In any case, this is so complex, I have no idea at
+all if the controlled operations are paired properly (which is critical).
+
+Come to think of it, I can't imagine any reason it is needed, even with your
+current semantics. It's clearly the case that S'Input needs to create a temporary
+object, which is then passed to S'Read. S'Read has a permission to eliminate its
+temporary. Surely combining the operations is allowed! What more do you need?
+You certainly have to call Initialize at least once, and not call Finalize on
+the returned object. I could see describing the model you do in an AARM note,
+but since it says nothing at all normative (you can't tell the difference between
+it and a canonical call with S'Read eliminating its temporary with the first
+permission). [Later: I see, you failed to allow the temporary to be eliminated in
+all cases. I think you're over-specifying: clever implementers should be allowed
+to remove the S'Read temporary all the time.]
+
+Summary: This one needs more work.
+
+****************************************************************
+
+From: Stephen W. Baird
+Date: Friday, April 5, 2007  2:36 PM
+
+> I'm not very happy with the required temporary in S'Read. S'Read should
+> default to build-in-place; if that was done, the horribly complex second
+> permission for S'Input wouldn't be necessary. OTOH, it may be too hard to
+> describe that; but essentially I would use the semantics you describe for
+> the permission as the canonical ones, and then allow a temporary to be
+> created and assigned instead. If that doesn't work, I think you need to say
+> something in the description about why.
+
+I think that we have to have a temp. There are lots of good
+reasons that the only way to modify a discriminant is by assignment to the
+entire enclosing object. That means that in order to modify the discriminants
+of Item, we need a value of type T to assign to it. That means we need a 
+temp.
+
+There is an alternative to the model I described in the AI:
+read in discriminants, declare a temp constrained to those discriminants
+(this includes default initialization), assign the temp to Item, and then
+invoke Read for each of the non-discriminant components of Item. The difference
+is that we are invoking Read on the non-discriminant components of Item, not
+of the temp. In many common cases, it might be easier for a compiler to eliminate
+the temp if we do it this way.
+
+Do you think this approach would be better?
+
+> I also don't like that you appear to be *requiring* a temporary to be built
+> if the discriminants change. If the implementation can handle build-in-place
+> with changed discriminants, it should be allowed to do so. 
+
+As always, the implementation can change things around however it wants as
+long as the user can't tell the difference. You don't need any special
+permission for that. Can you give a specific example where you think that
+my proposal is too restrictive?
+
+> We'd allow an
+> assignment temporary to be removed in this case, why not here?
+> [I'm also dubious about the early Constraint_Error, as that would make it
+> hard to keep a stream in sync. It could be a security issue. But that I'll
+> leave for another time.]
+> 
+
+Keeping streams in sync in the face of exceptions is already
+something of a mess. I don't think this makes matters any worse.
+
+> I completely hate the description of the second implementation permission. I
+> think it is important to recognize that it is OK to combine the two
+> operations if both S'Read and S'Input are the default versions, but I don't
+> think that much else needs to be said. 
+
+If you think there is a simpler way to specify the semantics of
+combining the two operations, I'd like to hear about it.
+
+> If the canonical semantics was to not
+> declare a temporary, you wouldn't need this at all. 
+
+But those are the canonical semantics, for reasons described above.
+ 
+> In any case, this is so
+> complex, I have no idea at all if the controlled operations are paired
+> properly (which is critical).
+
+If an implementation ignores this permission, then it certainly doesn't
+cause problems. If it makes use of this permission, then that is
+supposed to mean that the Read/Input combination simply behaves
+as if the type lacked default discriminant values. If that case is not
+well-defined, then that is a problem outside of the scope of this AI.
+
+> Come to think of it, I can't imagine any reason it is needed, even with your
+> current semantics. It's clearly the case that S'Input needs to create a
+> temporary object, which is then passed to S'Read. S'Read has a permission to
+> eliminate its temporary. Surely combining the operations is allowed! What
+> more do you need? You certainly have to call Initialize at least once, and
+> not call Finalize on the returned object. I could see describing the model
+> you do in an AARM note, but since it says nothing at all normative (you
+> can't tell the difference between it and a canonical call with S'Read
+> eliminating its temporary with the first permission). [Later: I see, you
+> failed to allow the temporary to be eliminated in all cases. I think you're
+> over-specifying: clever implementers should be allowed to remove the S'Read
+> temporary all the time.]
+
+I'm confused. Are you saying that the implementation permissions I'm
+proposing do not grant the implementation any permissions that it
+didn't already have? Would it be helpful if I tried to construct an
+example to demonstrate that this is not the case?
+
+> Summary: This one needs more work.
+
+I remain unconvinced
+It sounds like we'll have some things to discuss at the meeting.
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Friday, April 5, 2007  3:19 PM
+
+...
+
+> There is an alternative to the model I described in the AI:
+> read in discriminants, declare a temp constrained to those discriminants
+> (this includes default initialization), assign the temp to Item, and then
+> invoke Read for each of the non-discriminant components of Item. The 
+> difference is that we are invoking Read on the non-discriminant components of Item, 
+> not of the temp. In many common cases, it might be easier for a compiler to 
+> eliminate the temp if we do it this way.
+> 
+> Do you think this approach would be better?
+
+Yes, slightly. (I'm not sure that there is any functional difference, however.)
+
+> > I also don't like that you appear to be *requiring* a temporary to be built
+> > if the discriminants change. If the implementation can handle build-in-place
+> > with changed discriminants, it should be allowed to do so. 
+> 
+> As always, the implementation can change things around however it wants as
+> long as the user can't tell the difference. You don't need any special
+> permission for that. Can you give a specific example where you think that
+> my proposal is too restrictive?
+
+If there are controlled parts, it is impossible use build-in-place to emulate
+the canonical semantics, because you have to call Initialize/Finalize on the
+temporary. And you can't do that on the item passed in (it already has values).
+So a temporary is required as there is no permission to remove it. Note that
+my concern is the cost of the calls to Initialize/Finalize, not really the
+cost of copying the temporary: but they can only be removed if the entire
+temporary is.
+
+> > We'd allow an assignment temporary to be removed in this case, why not here?
+> > [I'm also dubious about the early Constraint_Error, as that would make it
+> > hard to keep a stream in sync. It could be a security issue. But that I'll
+> > leave for another time.]
+> 
+> Keeping streams in sync in the face of exceptions is already
+> something of a mess. I don't think this makes matters any worse.
+
+Could be, I haven't tried to do it. Perhaps it doesn't make sense to try with the
+default composite attributes (as opposed to the user-defined ones I've generally used).
+
+...
+> > In any case, this is so
+> > complex, I have no idea at all if the controlled operations are paired
+> > properly (which is critical).
+> 
+> If an implementation ignores this permission, then it certainly doesn't
+> cause problems. If it makes use of this permission, then that is
+> supposed to mean that the Read/Input combination simply behaves
+> as if the type lacked default discriminant values. If that case is not
+> well-defined, then that is a problem outside of the scope of this AI.
+> 
+> > Come to think of it, I can't imagine any reason it is needed, even with your
+> > current semantics. It's clearly the case that S'Input needs to create a
+> > temporary object, which is then passed to S'Read. S'Read has a permission to
+> > eliminate its temporary. Surely combining the operations is allowed! What
+> > more do you need? You certainly have to call Initialize at least once, and
+> > not call Finalize on the returned object. I could see describing the model
+> > you do in an AARM note, but since it says nothing at all normative (you
+> > can't tell the difference between it and a canonical call with S'Read
+> > eliminating its temporary with the first permission). [Later: I see, you
+> > failed to allow the temporary to be eliminated in all cases. I think you're
+> > over-specifying: clever implementers should be allowed to remove the S'Read
+> > temporary all the time.]
+> 
+> I'm confused. Are you saying that the implementation permissions I'm
+> proposing do not grant the implementation any permissions that it
+> didn't already have? Would it be helpful if I tried to construct an
+> example to demonstrate that this is not the case?
+
+I don't get it. Where is the permission to eliminate the temporary if the
+discriminants change? I suppose you could claim that this is an assignment
+operation and that 7.6(21/2) applies. But in that case, you don't need any
+separate permission to eliminate the temporary here at all (and you surely
+need an AARM note to point out that the assignment permission applies). You
+still would need the permission to raise Constraint_Error early, of course,
+because it causes what is read to change (surely not covered by 7.6(21/2)).
+
+But the involvement of what is read (especially if something component's read
+raises an exception) suggests the whole permission ought to be here. In that case,
+it should always be acceptable to eliminate the temporary (and the 4 calls to
+Initialize/Finalize/Adjust/Finalize), whether or not the discriminants changes.
+7.6(21/2) has no such restrictions on applicability, and neither should this
+permission.
+
+So, either make this a *complete* permission, or use 7.6(21/2) to the maximum extent.
+Don't half-and-half, which begs the question of why you would mention some
+of the cases when you can eliminate the temporary and not all.
+
+> > Summary: This one needs more work.
+> 
+> I remain unconvinced
+> It sounds like we'll have some things to discuss at the meeting.
+
+I'd be stunned if we didn't. In the worst case, Pascal could give us a special tour
+of Paris :-), but I don't see that happening.
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Friday, April 5, 2007  3:19 PM
+
+At the risk of beating a dead horse, there was one question here I didn't answer...
+
+...
+> > I completely hate the description of the second implementation permission. I
+> > think it is important to recognize that it is OK to combine the two
+> > operations if both S'Read and S'Input are the default versions, but I don't
+> > think that much else needs to be said. 
+> 
+> If you think there is a simpler way to specify the semantics of
+> combining the two operations, I'd like to hear about it.
+
+Yes. The null string. :-)
+
+Presuming you meant to invoke 7.6(21/2) [and if you didn't, its effect needs to be
+added to the first permission], I cannot think of a single case where an
+implementation that generated S'Input and it's "call" to default S'Read together
+could not optimize the result. And where the heck does it say that a compiler
+has to generate a call just because the RM says it?
+
+You need to show an example where an appropriate optimization of S'Input
+would not be allowed without an additional permission. It needs to be in the
+discussion of the AI.
+
+****************************************************************