CVS difference for ai05s/ai05-0183-1.txt
--- ai05s/ai05-0183-1.txt 2010/11/19 01:46:39 1.14
+++ ai05s/ai05-0183-1.txt 2010/11/19 05:36:23 1.15
@@ -2944,3 +2944,431 @@
things into it that I think are pretty stable (don't want to redo work).
****************************************************************
+
+From: Robert Dewar
+Sent: Thursday, November 18, 2010 6:29 AM
+
+...
+> The syntax *is* in the RM already, just look at draft 10 or later. :-)
+
+Well, not really, because the only "RM" for Ada is the Ada 2005 standard.
+Yes, there is a draft RM, and of course I am perfectly aware of what it
+says now (that's why I refer to the status quo :-))
+
+> http://www.ada-auth.org/standards/ada12.html
+>
+> Of course, everything in the draft RM is subject to change. But I've
+> only put things into it that I think are pretty stable (don't want to redo
+> work).
+
+Well sure, but the discussion of this particular aspect of aspects is still
+quite active, so your judgment of it as "pretty stable" is open to question.
+
+I am simply supporting your view that this should be regarded as a pretty
+stable feature, not subject to "redoing work" :-)
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, November 16, 2010 8:23 AM
+
+[Editor's note: This was split off of a thread that is in AI05-0235-1.]
+
+> BTW, it seems that we really want formal by-reference parameters to be
+> a new object that happens to share memory with the old object. Besides
+> this accessibility rule (where claiming that dynamic accessibility is
+> a view property is unappealing), we also had similar issues with the
+> values of representation aspects like 'Size and 'Alignment. We surely
+> don't want to have to pass those along with parameters just so we can
+> report them accurately. (I recall we decided that wasn't necessary
+> with some phony
+> hand-waving.) I wouldn't be surprised if this keeps coming up until we
+> finally give in and change the definition...
+
+Perhaps, but there are several cases where things like Alignment, Size,
+accessibility level, constantness, vary according to the view. Note that a
+dereference of an access value gives a view of the designated object. If there
+are several different (general) access values of different types that designate
+the same object, the views they give could vary quite dramatically, but clearly
+there is only one object.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, November 16, 2010 3:43 PM
+
+That seems to make a major muddle out of the entire idea of aspects. Either they
+have a well-defined model (that they belong to the entity, not the view), or we
+have to create a new model (that I do not understand at all), or they are just
+anything that Tucker wants (which is not the way to define a programming
+language!).
+
+In the first case, either Tucker is wrong here, or these things are just not
+aspects (because they don't meet the model of aspects). Neither of these match
+up with the existing language, so we have to reject this.
+
+But that means we have no model of aspects other than type aspects. We
+supposedly allow aspects for other than types to vary by view, yet there is
+nothing explaining how that works. We don't even know what constitutes different
+views. (Arguably, we could apply the ASIS definition of views that makes every
+usage name a different view - thus there are no requirements at all on such
+aspects). That effectively means that anything depending on aspects of entities
+other than types is implementation-defined. Perhaps that is OK for
+representation aspects (although I doubt it - it means that all of the ACATS
+tests on such aspects should be withdrawn, because they are testing things that
+are not requirements).
+
+It also means that all of the justification that I have made to Robert and
+others about the design of aspect clauses is bullshit. The truth is that they
+ought to be allowed on renames and anything else that creates a view; since they
+can be different for views at least in some cases, I don't see any reason to
+arbitrarily prevent that.
+
+When I asked this question about parameter passing, I was told that I was wrong
+and that no definition is needed. Maybe that is OK for representation aspects
+(although I strongly disagree), but it is not acceptable for any other aspect.
+Meaning that Bob will have to make sure that *every* aspect as wording
+describing how it works for views. That seems like a nightmare to me.
+
+What I would prefer is that the language was very clear that aspects are
+per-entity, not per-view, except perhaps in a set of specifically defined cases.
+So if you want parameters and dereferences to be able to give the "wrong" answer
+for object aspects, there should be explicit text allowing those exceptions.
+
+If we don't have some sort of rule like this, then we have descended completely
+into anarchy. And effectively, all aspects are completely
+implementation-defined, because there is no requirement ever that they have a
+particular value. That's madness.
+
+****************************************************************
+
+From: Edmond Schonberg
+Sent: Tuesday, November 16, 2010 3:53 PM
+
+> What I would prefer is that the language was very clear that aspects
+> are per-entity, not per-view, except perhaps in a set of specifically
+> defined cases. So if you want parameters and dereferences to be able
+> to give the "wrong" answer for object aspects, there should be
+> explicit text allowing those exceptions.
+
+I fully agree with Randy. Aspects are per-entity, not per-view. I don't see the
+usefulness of "allowing" some aspects to depend on the view. Tuck's example that
+the alignment of a designated object might depend on the dereference that
+produces it can't possibly hold: how do you generate code for this?
+
+****************************************************************
+
+From: Bob Duff
+Sent: Tuesday, November 16, 2010 4:27 PM
+
+Well, GNAT seems to manage. ;-)
+
+% cat align.adb
+cat align.adb
+with Text_IO; use Text_IO;
+procedure Align is
+
+ procedure P (X : String) is
+ begin
+ Put_Line (X'Alignment'Img);
+ end P;
+
+ S : String := "Hello, world.";
+ for S'Alignment use 2**8;
+
+begin
+ Put_Line (S'Alignment'Img);
+ P(S);
+end Align;
+% gnatmake -f align.adb
+gnatmake -f align.adb
+gcc -c align.adb
+gnatbind -x align.ali
+gnatlink align.ali
+% ./align
+./align
+ 256
+ 1
+%
+
+I didn't look at the generated code, but I'd guess it's just "move 256 into EAX"
+and "move 1 into EAX" (or whatever).
+
+Note that it's implementation defined whether or not X is a view of S!
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, November 16, 2010 4:27 PM
+
+Here is an example:
+
+ X : aliased Integer
+ with Alignment => 1024;
+
+ type Int_Ptr is access all Integer;
+ Y : Int_Ptr := X'Access;
+
+ pragma Assert(Y.all'Alignment = Integer'Alignment);
+ pragma Assert(Y.all'Alignment /= X'Alignment);
+
+I don't see this as a big deal.
+
+The original discussion was about accessibility level, in any case.
+
+****************************************************************
+
+From: Edmond Schonberg
+Sent: Tuesday, November 16, 2010 5:01 PM
+
+> Well, GNAT seems to manage. ;-)
+
+Not sure what this proves. Tuck's example involved two different access types
+with the same designated type. Here there is just an alignment clause, not two
+different contradictory aspects. This is the quote that worries Randy and me:
+
+Perhaps, but there are several cases where things like Alignment, Size,
+accessibility level, constantness, vary according to the view. Note that a
+dereference of an access value gives a view of the designated object. If there
+are several different (general) access values of different types that designate
+the same object, the views they give could vary quite dramatically, but clearly
+there is only one object.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, November 16, 2010 5:13 PM
+
+...
+> Perhaps, but there are several cases where things like Alignment,
+> Size, accessibility level, constantness, vary according to the view.
+> Note that a dereference of an access value gives a view of the
+> designated object. If there are several different
+> (general) access values of different types that designate the same
+> object, the views they give could vary quite dramatically, but clearly
+> there is only one object.
+
+Note that in this list, "constantness" is definitely not an aspect. We were
+originally discussing whether "accessibility level" works like an aspect, but
+there is no reason to assume it is one (which was my mistake). So neither of
+those really bear on the discussion.
+
+Size and Alignment surely are aspects. And we've discussed this before (in terms
+of parameters); we don't want to require the aspects to be required to be the
+same, because otherwise it would be necessary to pass them with all parameters
+just in case someone queried them. That would be silly.
+
+The problem is that the answer wasn't to explain when the aspects can depend on
+the view, but rather to say that they *always* depend on the view and then never
+say anything more. That means that you can *never* depend on an aspect other
+than a type aspect. That way lies madness. I should never have taken the "don't
+care" answer in the first place, but I could see that there would never be a
+strong definition for the case of representation aspects of objects. But now we
+have a much more general mechanism; we cannot leave it to individual
+implementers to do something useful - else we might as well not bother at all
+standardizing any of this beyond the syntax. (I get the feeling that Robert is
+in this camp.)
+
+****************************************************************
+
+From: Bob Duff
+Sent: Tuesday, November 16, 2010 5:20 PM
+
+> Not sure what this proves.
+
+It proves that, as Tuck said, "things...vary according to the view".
+Whether that means the sky is falling, as Randy and Chicken Little might like to
+imply, I'm not so sure. ;-)
+
+>...This is the quote that worries Randy and me:
+
+Can you explain what the worry is? Is it a worry about RM wording, or something
+more substantial? I mean, X.all and Y.all can be the same object, yet the
+accessibility level depends on their (possibly different) access types. Should I
+worry about that?
+
+****************************************************************
+
+From: Edmond Schonberg
+Sent: Tuesday, November 16, 2010 5:26 PM
+
+> The problem is that the answer wasn't to explain when the aspects can
+> depend on the view, but rather to say that they *always* depend on the
+> view and then never say anything more. That means that you can *never*
+> depend on an aspect other than a type aspect.
+
+Hopefully pre, post, and package aspects are equally trustworthy! we are just
+speaking about aspects of objects.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, November 16, 2010 5:50 PM
+
+...
+> > The problem is that the answer wasn't to explain when the aspects
+> > can depend on the view, but rather to say that they *always* depend
+> > on the view and then never say anything more. That means that you
+> > can *never* depend on an aspect other than a type aspect.
+>
+> Hopefully pre, post, and package aspects are equally trustworthy! we
+> are just speaking about aspects of objects.
+
+I would hope that they are trustworthy, but the current definition of aspects
+only has a special case defining that they are not view-dependent for types.
+(13.1(11/2)). There is no such rule for subprograms, objects, packages, or any
+other entities. That is what I'm concerned about.
+
+Bob Duff says:
+
+> It proves that, as Tuck said, "things...vary according to the view".
+> Whether that means the sky is falling, as Randy and Chicken Little
+> might like to imply, I'm not so sure. ;-)
+
+Being compared to Chicken Little, even with a smiley, is really nasty.
+
+My concern is simply that in the absense of some idea what an aspect is,
+particularly when views are involved, means that everything we've done so far is
+done without any clear idea of what we're doing. Everything I've done related to
+aspects has assumed that they are not view specific; if that premise is false,
+we need to revisit virtually every decision that has been made, because most of
+them depend heavily on that premise. (The obvious example is omitting
+aspect_clauses from renames.)
+
+Moreover, without a blanket rule defining how aspects work, every individual
+aspect has to provide that information. That means that aspects like Pre and
+Post need at least a sentence saying "This aspect is the same for every view of
+the associated subprogram." And aspects that are not like that need to explain
+what the rules are when views are involved. Otherwise, it is completely
+impossible to write an ACATS test or any other portable code using an aspect.
+
+The examples that both you and Tucker have shown that 'Alignment can be anything
+for an object, even when the value is specified for the object. There is no
+justification for the existing ACATS tests on object 'Alignment in that
+environment. As I've said, perhaps that is OK for representation aspects of
+objects (which are rather implementation-defined in any case), but that is
+simply not acceptable for something like Pre.
+
+If you think this is the "sky falling" as opposed to a real concern, then fine,
+but then we really have nothing to talk about. And I better brush up my Java
+skills, because I won't be doing Ada anymore.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Tuesday, November 16, 2010 6:35 PM
+
+> Being compared to Chicken Little, even with a smiley, is really nasty.
+
+I apologize! I really didn't mean it as a nasty insult -- just poking a little
+fun at you for what seemed to me like slightly over-the-top rhetoric (hence the
+smiley!).
+
+I am sorry.
+
+I do think you have a real, legitimate concern about the wording, and we can
+address it.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, November 16, 2010 10:19 PM
+
+I suspect Bob and I don't really understand
+the issue. Things like Size and Alignment
+have been part of Ada for a long time.
+Adding aspect specifications doesn't change much of anything about them, except
+for the syntax used to specify them.
+
+Objects are probably the only really special case, since they are clearly
+run-time entities, and we have many ways of referring to the same object. If
+you specify an aspect of an object, then at places where that aspect
+specification is visible and you are referring to the object via its declared
+name (as opposed to by some other name like a formal by-ref parameter or an
+access-value dereference), then an attribute reference corresponding to that
+aspect will presumably report the specified value.
+
+On the other hand, when referring to an object via a formal by-ref parameter, or
+via an access value dereference, then the attribute reference can end up
+returning a different value. It is presumably "conservative" for some
+appropriate definition of "conservative." That is, if you ask for the alignment
+of a formal parameter, it might in fact be more aligned. If you ask for the
+size, it might in fact have some extra padding at the end that nobody ever looks
+at. If you ask for the accessibility, it might in fact be longer-lived than it
+appears via the formal parameter.
+
+None of this is new with aspect specifications, so I am a bit surprised that
+there is any controversy and that this is a hot topic for discussion. It would
+probably help Bob and me if there were an example of an actual problem created
+by these long-standing characteristics of object representational aspects, or
+what makes this a bigger problem now that we have generalized aspect
+specifications.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, November 17, 2010 9:24 PM
+
+I've covered this several times already (especially in my last message to Bob),
+but one more time:
+
+(1) You might have the above model in your head, but there is nothing in the
+ Standard that codifies any of it. The standard really only defines aspects
+ as entity-specific vs. view-specific for types. For all other kinds of
+ entities, there is nothing much said about entity vs. view.
+
+(2) If we're going to generalize aspects as much as we are going to, we need to
+ define these things carefully. For instance, your statement that "objects
+ probably are the only special case" is not true vis-a-vis the standard
+ wording. If we (for instance) want preconditions to be entity-specific
+ rather than view specific, then we need wording to that effect somewhere.
+
+(3) Without some definition for other kinds of aspects (other than types), it is
+ impossible to write any portable code (or any ACATS tests). That's because
+ there is no definition for which views the specified value of an aspect has
+ to be returned. The model you give above would be fine, but there is no
+ normative justification for it in the Standard.
+
+(4) If indeed objects are the only special case, then the best way to do this is
+ simply by saying so: "Unless otherwise specified, aspects are the same for
+ all views of an entity." And then following that by an appropriate exception
+ for objects: "For representation aspects of objects, views of an object for
+ which the specification of an aspect are visible have the aspect as
+ specified; other views may have an implementation-defined value of the
+ aspect." Or something like that.
+
+(5) I don't view representation aspects of objects to be that big of a deal, as
+ their values are implementation-defined anyway. Only ACATS tests really care
+ about using them portably. But other kinds of aspects and aspects for other
+ kinds of entities need to be dealt with. We surely do not want whether a
+ package is Pure to depend on the view of the package, for example.
+
+(6) But note that I opened an AI (AI05-0083-1) specifically to address this
+ question definitively for representation aspects of objects. I wanted the
+ question answered then, but I only got a "ramification" that contains little
+ real guidance (just some vaguely worded AARM notes). So I do not view this
+ as a "new" issue, but rather one that has been festering for a long time. I
+ only went along with the Ramification because of the implementation-defined
+ nature of representation aspects means that not that much useful can be
+ assumed about them anyway. But I still would much prefer real wording to
+ explain when it is and is not allowed for the aspects to differ from those
+ specified for an entity.
+
+(7) Finally, pretty much all of the decisions that we have made about syntax,
+ rules, etc. about aspect_clauses have been made assuming that aspects are
+ entity-specific rather than view-specific (surely in my case, and judging
+ for Ed's reaction, I'm not the only one). Since that is wrong, I am no
+ longer certain that we have gotten the right answers in all cases (the
+ obvious example being whether to support the clauses on renames). I think it
+ is important the we revisit all of the decisions with a new model in mind
+ (even if that model is that aspects only differ for objects, we still need
+ to think carefully about renames of objects). It's quite possible that not
+ much needs to be changed, but I no longer have any confidence in my previous
+ thinking on the topic.
+
+I hope this clarifies my position here. Perhaps I put my initial fears too
+strongly, but I cannot abide with leaving this all undefined, or assuming that
+the answers determined using an incorrect model of aspects are correct.
+
+****************************************************************
+
Questions? Ask the ACAA Technical Agent