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

Differences between 1.1 and version 1.2
Log of other versions for file ai12s/ai12-0181-1.txt

--- ai12s/ai12-0181-1.txt	2016/01/08 02:20:57	1.1
+++ ai12s/ai12-0181-1.txt	2016/01/09 01:22:42	1.2
@@ -1,4 +1,4 @@
-!standard 13.1(9/4)                                    16-01-07  AI12-0181-1/01
+!standard 13.1(9/4)                                    16-01-08  AI12-0181-1/02
 !standard 13.1(9.1/4)
 !standard 13.14(19)
 !class binding interpretation 16-01-07
@@ -51,8 +51,9 @@
 
 Add after 13.1(9.1/4):
 
-An aspect_specification that specifies a representation or operational aspect
-of an entity shall not freeze that entity.
+An expression or name that freezes an entity shall not occur within an
+aspect_specification that specifies a representation or operational aspect
+of that entity.
 
 AARM Ramification: Such an aspect cannot refer to the entity itself, directly
 or indirectly. For instance:
@@ -77,12 +78,12 @@
 AARM to not mark that paragraph as redundant (supposely we'd noticed it
 earlier, but the author wasn't able to find any reference to that).
 
-The problem with the 2000 fix is that it leaves 3/4 of the rules given in
+The problem with the 2002 fix is that it leaves 3/4 of the rules given in
 13.1, 1/2 of the rules given in 13.14, and nowhere are all of the rules. The
 author, after reading 13.1(9-9.1/4), mistakenly concluded that was all the
 rules there are in the Standard. The rule in 13.1(9.1/4) in particular caused
 that conclusion, as it is complete for operational aspects. If it was a problem
-for the author, It has to be harder for other readers, thus we add the
+for the author, it has to be harder for other readers, thus we add the
 missing rule in 13.1(9/4) and replace the redundant brackets on 13.14(19).
 
 !ASIS
@@ -333,6 +334,193 @@
 
 My preference is to actually fix this as was suggested several times at the
 start of the millennium.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, January 7, 2015  8:45 PM
+
+> ... My preference is to actually fix this as was suggested several 
+> times at the start of the millennium.
+
+I am a little unclear what exactly you are proposing.  I presume it is to 
+duplicate the currently *non* redundant part of 13.14 in 13.1, and then
+mark the 13.14 part as redundant.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, January 7, 2015  9:35 PM
+
+Yes. Specifically, modify 13.1(9/4) as marked:
+
+{A representation item that directly specifies an aspect of an entity shall
+appear before the entity is frozen (see 13.14). In addition, a}[A]
+representation item that directly specifies an aspect of a subtype or type
+shall appear after the type is completely defined (see 3.11.1)[, and before
+the subtype or type is frozen (see 13.14)].
+
+And then mark 13.14(19) as redundant, replacing the "The Proof" AARM note that
+explains why it is redundant.
+
+I still wonder about deferred constants, but I'm treating that as a question
+not asked for the moment.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, January 7, 2015  8:42 PM
+
+> Specifically:
+>
+> An aspect_specification that specifies a representation or operational 
+> aspect of an entity shall not freeze that entity.
+
+I find this wording potentially ambiguous.  I would prefer something like:
+
+    An aspect_specification that specifies a representation or
+    operational aspect of an entity shall not contain a construct
+    that causes freezing of the entity.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, January 7, 2015  9:47 PM
+
+I don't think that works. I originally had something like this:
+
+  An aspect_specification that specifies a representation or operational
+  aspect of an entity shall not cause freezing of that entity.
+
+but I didn't think this is right; "cause freezing" is something that happens
+to constructs, not entities. Such a construct then freezes some entities.
+13.14(9) says: "The following rules define which entities are frozen at the
+place where a construct causes freezing:" As such, I didn't want to use
+"causes" with "entity".
+
+The long form would probably be OK, though:
+
+  An aspect_specification that specifies a representation or operational
+  aspect of an entity shall not cause freezing of a construct that freezes
+  that entity.
+
+Better ideas welcome.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, January 7, 2015  11:19 PM
+
+> I don't think that works. I originally had something like this:
+>
+>    An aspect_specification that specifies a representation or 
+> operational aspect of an entity shall not cause freezing of that entity.
+>
+> but I didn't think this is right; "cause freezing" is something that 
+> happens to constructs, not entities. Such a construct then freezes some entities.
+> 13.14(9) says: "The following rules define which entities are frozen 
+> at the place where a construct causes freezing:" As such, I didn't 
+> want to use "causes" with "entity".
+
+I think you are misunderstanding the term "causes freezing."  You never freeze
+a construct, you only freeze an entity.  A given construct causes freezing only
+in some contexts, and we describe that by saying in this context this construct
+causes freezing.
+
+> The long form would probably be OK, though:
+>
+>    An aspect_specification that specifies a representation or 
+> operational aspect of an entity shall not cause freezing of a 
+> construct that freezes that entity.
+
+This is confused.  As indicated above, you don't freeze a construct; you freeze
+an entity.  The construct is the actor, the entity is the target of the
+freezing.  Certain contexts cause a construct to start freezing entities. The
+RM description is factored into under what circumstances constructs cause
+freezing, and which entities they freeze when that happens.  But it is still
+legitimate to combine these two by saying "this construct causes this entity
+to be frozen."
+
+> Better ideas welcome.
+
+See above.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, January 8, 2015 12:16 AM
+
+> I think you are misunderstanding the term "causes freezing."  
+> You never freeze a construct, you only freeze an entity.  A given 
+> construct causes freezing only in some contexts, and we describe that 
+> by saying in this context this construct causes freezing.
+
+It's pretty clear that "causes freezing" operates on constructs, not entities.
+We need to avoid using "causes" on entities (because that confuses a technical
+term with an informal English usage of a word), and that's all I was trying to
+do.
+
+> > The long form would probably be OK, though:
+> >
+> >    An aspect_specification that specifies a representation or 
+> > operational aspect of an entity shall not cause freezing of a 
+> > construct that freezes that entity.
+> 
+> This is confused.  As indicated above, you don't freeze a construct; 
+> you freeze an entity.
+
+No, but you "cause freezing" of a construct. Those are *different* terms, with
+different bulleted lists in 13.14.
+
+>   The construct is the actor, the entity is the target of the 
+> freezing.  Certain contexts cause a construct to
+> start freezing entities.   The RM description is factored into under 
+> what circumstances constructs cause freezing, and which entities they 
+> freeze when that happens.
+
+Totally agree with this.
+
+> But it is still
+> legitimate to combine these two by saying "this construct causes this 
+> entity to be frozen."
+
+But I don't agree with this. 13.14(9) keeps them separate. And that's pretty
+much the only way to make any sense; we really don't want to be talking about
+constructs at all.
+
+None of this would have bothered me if the wording in 13.14 had included
+aspect_specification as a construct that causes freezing or whatever, because
+then we wouldn't have to mention constructs that cause freezing at all. But
+as it is, we have to talk about that, and that makes it confusing because a
+construct that causes freezing results in some entity becoming frozen.
+
+> > Better ideas welcome.
+> 
+> See above.
+
+I don't agree that it is a better idea! Who the heck knows what a construct
+is anyway? And I'd rather get rid of the use of "causes" if we're not going
+to use it in its technical sense. 13.14(7.2/3) uses "within" and mentions
+expressions and names, and we don't really need to say anything about
+"causes":
+
+   An expression or name that freezes an entity shall not occur within an
+   aspect_specification that specifies a representation or operational
+   aspect of that entity.
+
+Using "within" required turning it around.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Friday, January 8, 2015  1:08 AM
+
+> ...     An expression or name that freezes an entity shall not occur within an
+> aspect_specification that specifies a representation or operational 
+> aspect of that entity.
+
+Well we aren't yet in agreement about the meaning of "causes freezing," but the
+above wording seems fine. ;-)
 
 ****************************************************************
 

Questions? Ask the ACAA Technical Agent