CVS difference for ais/ai-00447.txt

Differences between 1.1 and version 1.2
Log of other versions for file ais/ai-00447.txt

--- ais/ai-00447.txt	2006/02/21 02:46:53	1.1
+++ ais/ai-00447.txt	2006/04/20 05:31:58	1.2
@@ -2440,337 +2440,7 @@
 requirement.  But this IA is intended to nudge implementers in the right
 direction.
 
-****************************************************************
-
-From: Robert Dewar
-Sent: Friday, February 17, 2006  7:04 AM
-
-Good, I had missed that. I agree IA is fine here (as I have commented
-in the past, IA is often stronger than a requirement, since it is to
-be interpreted informally -- to me all documentation requirements would
-be stronger if they were IA :-))
-
-****************************************************************
-
-From: Robert A. Duff
-Sent: Friday, February 17, 2006  7:10 AM
-
-> > Indeed. I actually think that there should be a rule that the
-> > compiled accept all confirming representation clauses, which
-> > is not necessarily the case.
->
-> There is actually an IA to that effect in Ada 2005, see 13.1(21.1).  Of
-> course, with dope and dynamic stuff and so on this cannot be a
-> requirement.  But this IA is intended to nudge implementers in the right
-> direction.
-
-21.1/2 {AI95-00291-02} A confirming representation item should be supported.
-
-This is not "mere" Implementation Advice.  It is "Recommended Level of
-Support", so the "should" becomes "shall" in the SP Annex.
-I wonder if that was the intent.  The AARM says:
-
-                         Wording Changes from Ada 95
-    ...
-    28.n/2 {AI95-00291-02} Added wording to define confirming representation
-          items, and to suggest that they should always be supported.
-
-This is not just a wording change, and does not merely "suggest".
-
-I don't understand the "with dope and dynamic stuff" part of your comment
-above (which echoes the sentiment in the AARM):
-
-    21.a.1/2 To be honest: A confirming representation item might not be
-          possible for some entities. For instance, consider an unconstrained
-          array. The size of such a type is implementation-defined, and might
-          not actually be a representable value, or might not be static.
-
-The way I read para 21.1 is: if you write a confirming representation clause
-(confirming some aspect of rep), then the compiler has to accept it.  It does
-not claim that there is a way to confirm every aspect of everything
-(e.g. sizes of non-static stuff).  You cannot, for example, specify that you
-want a twos complement little endian representation for an integer, even if
-that would be confirming.  So I don't see any dishonesty that the "To be
-honest" needs to address.
-
-****************************************************************
-
-From: Randy Brukardt
-Sent: Friday, February 17, 2006  2:07 PM
-
-> This is not just a wording change, and does not merely "suggest".
-
-This is a BI, so it wasn't documented as an extension. I've just finished
-going over the entire set of BIs and changing that (with a marker so it's
-possible to tell the difference between BI and Amendment extensions,
-incompatibilities, and the like), but I managed to miss this one. (It's
-likely that I missed others as well, feel free to point them out.)
-
-We felt that this was always the intent of Ada, it just wasn't written down.
-(I'm not aware of any compiler that would violate this rule - Janus/Ada
-doesn't implement all rep. items to the Recommended Level of Support, but it
-allows confirming ones on all of them.)
-
-...
-> The way I read para 21.1 is: if you write a confirming representation clause
-> (confirming some aspect of rep), then the compiler has to accept
-> it.  It does not claim that there is a way to confirm every aspect of
-> everything (e.g. sizes of non-static stuff).  You cannot, for example,
-> specify that you
-> want a twos complement little endian representation for an integer, even if
-> that would be confirming.  So I don't see any dishonesty that the "To be
-> honest" needs to address.
-
-That's one way to read it, but I thought there was enough possibility for
-confusion that it was worth reiterating it. It's easy to read it as meaning
-that there must be a way to write a confirming item (I read it that way
-every time, I agree your reading makes more sense, but I *still* read it the
-other way.) I suppose the AARM note could be classified as a Ramification or
-some such, but it still seems iffy to me.
-
-****************************************************************
-
-From: Robert Dewar
-Sent: Friday, February 17, 2006  1:44 PM
-
-> The way I read para 21.1 is: if you write a confirming representation clause
-> (confirming some aspect of rep), then the compiler has to accept it.  It does
-> not claim that there is a way to confirm every aspect of everything
-> (e.g. sizes of non-static stuff).  You cannot, for example, specify that you
-> want a twos complement little endian representation for an integer, even if
-> that would be confirming.  So I don't see any dishonesty that the "To be
-> honest" needs to address.
-
-Hmm, suppose my compiler is very clever, and figures out it can overlap
-two components of a record because they are never used at the same time,
-how do I confirm that.
-
-Suppose that my compiler has 'Size be some value, but does not follow
-the IA/requirements that come with this in the RM, then a confirming
-rep clause says too much.
-
-Suppose that my compiler by default allows two fields in the same
-byte to be accessed independently different tasks, because it
-figures this is safe, if I write an implicit rep clause, then I
-treat on the independence land mine.
-
-[this is fun!]
-
-Suppose a compiler figures out that it can store an object of type
-Integer in 8 bits, because no larger value is stored, can I really
-specify a size of 8 bits for the object?
-
-Suppose a compiler uses different representations for local and
-global objects, what's the 'Size of the type in that case? Whatever
-the answer, a confirming rep clause will mess things up.
-
-How can I confirm the layout of a record with dynamic fields, well
-perhaps pragma Pack might do it, can pragma Pack ever be considered
-to be a confirming rep clause (I think not).
-
-If I store biased types in some cases, do you really want me to be able
-to force it in all cases.
-
-Suppose I align a type in different ways in different cases. In this
-case 'Alignment will return the lowest value, but specifying this
-lowest value will force this value in all cases, is that confirming?
-
-This should have been IA, not a requirement, in my view.
-
-****************************************************************
-
-From: Randy Brukardt
-Sent: Friday, February 17, 2006  2:22 PM
-
-> This should have been IA, not a requirement, in my view.
-
-The requirement is as Bob described it: "*IF* you can write a confirming
-rep. item, then it shall be supported.". It's not a requirement to always be
-able to write a confirming rep. item.
-
-In most of your examples, you can't write a confirming rep. item (because
-there are multiple sizes, the size isn't known, the item has properties not
-described by a rep. item, etc.) So there is no problem, the requirement
-means nothing.
-
-In the rest, you are giving different semantics to items that don't have a
-rep. item to those that do. It was the sense of the ARG that having such
-constructs was in very bad taste. It was *precisely* the intent of the ARG
-to (implicitly) ban such things in an implementation that claims to follow
-the Recommended Level of Support. (I say that because we spent a lot of
-effort changing any rule in the Standard that even seemed to imply that
-could be the case.)
-
-So, I don't see that there is any problem with a requirement here.
-Implementers have a lot of leaway in defining the default representation, so
-it shouldn't be a problem to skirt the rule if necessary.
-
-P.S. See, Bob, why we need the To Be Honest?? :-)
-
-****************************************************************
-
-From: Robert Dewar
-Sent: Friday, February 17, 2006  2:29 PM
-
-> In most of your examples, you can't write a confirming rep. item (because
-> there are multiple sizes, the size isn't known, the item has properties not
-> described by a rep. item, etc.) So there is no problem, the requirement
-> means nothing.
-
-Actually in almost all the cases I gave, you *can* write a confirming rep
-item. It just does not confirm exactly.
-
-> In the rest, you are giving different semantics to items that don't have a
-> rep. item to those that do
-
-THe RM does this! If you don't have a rep clause, then you are guaranteed
-independence. But if you give a confirming rep clause you are no longer
-guaranteed independence. Has this changed in 2005? If so, what language
-changed this.
-
-****************************************************************
-
-From: Pascal Leroy
-Sent: Monday, February 20, 2006  2:17 AM
-
-This didn't change, and it was an oversight as far as I can tell.  It
-seems to me that we should have added "nonconfirming" to the last sentence
-of 9.10(1).  This can always be done later by an AI: it won't affect the
-code generated by compilers.
-
-****************************************************************
-
-From: Robert Dewar
-Sent: Monday, February 20, 2006  5:49 AM
-
-It definitely can affect the generated code.
-
-It immediately occurred to me, it would surprise me if there were
-not other similar consequences. This is a very delicate area.
-
-One problem for example: There is nothing now to stop a compiler
-from doing things quite differently for rep'ed and non-rep'ed
-stuff. Just because you think you have specified all the visible
-standard attributes does not mean you have specified enough.
-
-Also now you are giving real semantics to the notion of a confirming
-rep clause, and I don't see how that is possible. After all the
-compiler can change its defaults at any time. It seems really
-awkward in a formal requirements sense to talk about what the
-compiler *would have* done. Also how do you know you are confirming
-all the attributes. And how is this testable?
-
-This seems a quagmire to me, better to put this in implementation
-advice, where we do not have to worry about formal definition. In
-fact the whole business of confirming rep clauses would have been
-better as IA.
-
-****************************************************************
-
-From: Robert Dewar
-Sent: Monday, February 20, 2006  7:15 AM
-
-One really worrisome thing here. If you are going to start ascribing
-real semantics to confirming rep clauses, then the compiler has to be
-able to recognize confirming rep clauses. That's really hard. It would
-mean major new circuitry for us to figure this out, something like
-laying out the type with and without rep clauses to see if it came
-out the same - UGH!
-
-****************************************************************
-
-From: Pascal Leroy
-Sent: Monday, February 20, 2006  9:17 AM
-
-True, we'd have to do the same.
-
-On the other hand, doesn't it bother you that if I write:
-
-	type T is new String;
-	for T'Component_Size use 8;
-
-my program becomes mysteriously nonportable because of 9.10(1)?  This
-doesn't seem to be helpful to users...
-
-****************************************************************
-
-From: Robert Dewar
-Sent: Monday, February 20, 2006  10:35 AM
-
-Well it is not mysteriously nonportable, it is just that you
-can't count on independence for strings, something I have always
-known, and which is critical on some word addressed architectures
-like the old alpha.
-
-Standard.String is packed, so definitely any program expecting
-dependence is seriously non-portable! So your example is not
-a good one, T lacks independence before you even give a
-component size.
-
-If I do
-
-      type T is array (Positive) of Character;
-
-then on the old Alpha, you have to allocate 32-bits/character.
-
-If you say
-
-     for T'Component_Size use 8;
-
-then everything is fine, you get 8-bit characters but you
-lose independence.
-
-****************************************************************
-
-From: Randy Brukardt
-Sent: Monday, February 20, 2006  8:22 PM
-
-> This didn't change, and it was an oversight as far as I can tell.  It
-> seems to me that we should have added "nonconfirming" to the last sentence
-> of 9.10(1).  This can always be done later by an AI: it won't affect the
-> code generated by compilers.
-
-I agree. We spent a lot of time going thought Section 13 and eliminating any
-wording that implied any dependence on the existence of confirming rep.
-clauses. We didn't look anywhere else, probably because we bought the
-fiction that they don't affect semantics. :-) Anything that implies
-otherwise is a mistake, and it should be fixed ASAP. Sounds like a candidate
-for AI05-00001.
-
-****************************************************************
-
-From: Randy Brukardt
-Sent: Monday, February 20, 2006  8:36 PM
-
-> One really worrisome thing here. If you are going to start ascribing
-> real semantics to confirming rep clauses, then the compiler has to be
-> able to recognize confirming rep clauses. That's really hard. It would
-> mean major new circuitry for us to figure this out, something like
-> laying out the type with and without rep clauses to see if it came
-> out the same - UGH!
-
-It seems to me that you have this bass-ackwards.
-
-A confirming rep. clause has no semantics; it's what the compiler would have
-done anyway. (Independence is one of the things that the compiler has to "do
-anyway"). A non-confirming rep. clause *might* have semantics. But it's not
-necessary to apply semantics just because there is a rep. clause (you don't
-have go out of your way to make things not independent, for example). T'Size =
-16 might not be confirming, but it still is independent, for instance.
-
-A few days ago, you talked about "almost confirming" rep. clauses. Such a thing
-is not possible; either it is confirming, or it is not. If T'Size = 16, then
-for T'Size use 16; is confirming. Period. And whether or not the rep. clause is
-given is semantically neutral.
-
-If you need to know if a rep. clause is confirming, there is something wrong
-with your default representations. In a new compiler, you fix the defaults, you
-don't stand on your head. Now, I realize that compatibility reasons might mean
-that you need to stand on your head, but the cause of that is bad taste in
-existing choices. We wanted to strongly discourage those choices, and the
-harder you have to work to make them, the more successful we were. ;-)
-
-****************************************************************
+[This thread became AI05-0009-1, and the mail continues there. - Editor]
 
 From: Randy Brukardt
 Sent: Friday, February 17, 2006  2:36 PM

Questions? Ask the ACAA Technical Agent