CVS difference for ai05s/ai05-0183-1.txt
--- ai05s/ai05-0183-1.txt 2010/12/15 00:10:58 1.16
+++ ai05s/ai05-0183-1.txt 2011/02/08 08:21:06 1.17
@@ -1685,6 +1685,1118 @@
****************************************************************
+From: Robert Dewar
+Sent: Monday, July 26, 2010 7:04 PM
+
+I assume the idea is that you have a big list of aspects that are allowed, and
+for each aspect it is clear what entities it applies to, what it does, and
+whether it needs no argument, a name argument, or an expression argument.
+
+Regarding the latter, we have the examples:
+
+ Atomic_Components
+
+and
+
+ Atomic => True
+
+Can you also say
+
+ Atomic => False
+
+that would be interesting to cancel atomicity in a derived type (not currently
+possible).
+
+Can you also say something like
+
+ Pack => False;
+
+again, interesting to be able to cancel packing, not currently possible.
+
+Does
+
+ Pack
+
+mean the same as
+
+ Pack => True
+
+Can you say
+
+ Atomic => Machine_64
+
+where Machine_64 is a static boolean constant? If so interesting way to
+parametrize things??
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Saturday, July 31, 2010 8:29 AM
+
+> I assume the idea is that you have a big list of aspects that are
+> allowed, and for each aspect it is clear what entities it applies to,
+> what it does, and whether it needs no argument, a name argument, or an
+> expression argument.
+
+Leaving out the expression is exactly equivalent to writing "=> True".
+Generally you can use this notation for any specifiable attribute, as well many
+of the representation pragmas. In addition, there are a few "aspects" that can
+only be specified using this syntax (e.g. "Pre" and "Post").
+
+> Regarding the latter, we have the examples:
+>
+> Atomic_Components
+>
+> and
+>
+> Atomic => True
+>
+> Can you also say
+>
+> Atomic => False
+>
+> that would be interesting to cancel atomicity in a derived type (not
+> currently possible).
+
+Interesting question. You are right that for aspects corresponding to pragmas,
+we may be giving a new capability without realizing it. We clearly have to be
+sure we really want that!
+
+> Can you also say something like
+>
+> Pack => False;
+>
+> again, interesting to be able to cancel packing, not currently
+> possible.
+
+Good point.
+
+>
+> Does
+>
+> Pack
+>
+> mean the same as
+>
+> Pack => True
+
+Yes, presuming the aspect name is "Pack." This is one pragma where the aspect
+name is specified in the manual to be something other than the pragma name
+("Packing" vs. "Pack"). That could be confusing, so the AI says something about
+wheter to always use the pragma name for aspect names. I forget what was the
+conclusion relative to the "Pack" pragma...
+
+> Can you say
+>
+> Atomic => Machine_64
+>
+> where Machine_64 is a static boolean constant? If so interesting way
+> to parametrize things??
+
+Yes, presumably any static expression of the right type, as in an attribute
+definition clause.
+
+****************************************************************
+
+From: Robert A Duff
+Sent: Saturday, July 31, 2010 5:30 PM
+
+> I forget what was the conclusion relative to the "Pack" pragma...
+
+I think we decided that the place(s) where the RM says "packing aspect" should
+be changed to "pack aspect". or "Pack aspect"?
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Sunday, August 1, 2010 6:24 AM
+
+> Yes, presuming the aspect name is "Pack." This is one pragma where
+> the aspect name is specified in the manual to be something other than
+> the pragma name ("Packing" vs. "Pack"). That could be confusing, so
+> the AI says something about wheter to always use the pragma name for
+> aspect names. I forget what was the conclusion relative to the "Pack"
+> pragma...
+
+Well I would implement Pack even if the official name were Packing (which could
+be a synonym), it would be plain confusing to have a different name from the
+pragma.
+
+>> Can you say
+>>
+>> Atomic => Machine_64
+>>
+>> where Machine_64 is a static boolean constant? If so interesting way
+>> to parametrize things??
+>
+> Yes, presumably any static expression of the right type, as in an
+> attribute definition clause.
+
+Sure but the boolean attributes are always done with pragmas now, which do NOT
+permit this kind of parametrization, so this seems like a new (and valuable)
+feature.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Sunday, August 1, 2010 6:45 AM
+
+> I think we decided that the place(s) where the RM says "packing
+> aspect" should be changed to "pack aspect".
+> or "Pack aspect"?
+
+Seems reasonable, the important point anyway is that the aspect be the same name
+as the pragma, anything else would be mega-confusing, no matter WHAT the RM says
+:-)
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Sunday, August 1, 2010 9:36 AM
+
+For a while we were trying to make "with Blah" sound natural, such as "with
+Atomicity" and "with Packing". But if you are concerned about the way it sounds,
+you could easily write "with Atomic => True" or "with Pack => True," so that
+concern seems misplaced in retrospect. So I think by the end we all agreed that
+we should do what is simplest, and make the aspect name match the pragma name in
+all cases.
+
+****************************************************************
+
+From: Steve Baird
+Sent: Monday, August 2, 2010 11:04 AM
+
+> Can you also say something like
+>
+> Pack => False;
+>
+> again, interesting to be able to cancel packing,
+
+When the RM says something like
+
+ A pragma Pack specifies the packing aspect of representation or
+ Unless otherwise specified, the name of the aspect of
+ representation specified by a representation pragma is
+ the name of the pragma.
+
+it gives no hint as to what "values" (I'm using this term very loosely here)
+might be specified using Aspect-specification syntax. For example, it does not
+say that Pack is Boolean-valued aspect for which values True or False might be
+specified.
+
+The AI says:
+ An aspect_mark identifies an aspect of the entity defined by the
+ associated declaration (the associated entity); the aspect denotes
+ an object, a value, an expression, a subprogram, or some other kind
+ of entity. If the aspect_mark identifies an aspect that denotes an
+ object, the aspect_definition shall be a name.
+ If the aspect_mark identifies a value or an expression, the
+ aspect_definition shall be an expression. The expected type for the
+ name or expression is the type of the identified aspect of the
+ associated entity.
+
+It seems to me that the "some other kind of entity" case might include, for
+example, pragma Pack. The aspect "value" could be more like a a restriction name
+for a Restriction pragma or a check name for a Suppress pragma.
+
+ > Can you say
+ >
+ > Atomic => Machine_64
+ >
+ > where Machine_64 is a static boolean constant?
+
+If it were specified that the "value or an expression" case (as opposed to the
+"some other kind of entity" case) applied to pragma Atomic, and that the
+specified value is of type Boolean, then it would make sense that an arbitrary
+static expression would be allowed. However, where is the wording for that? In
+particular, where is the wording that would disallow a non-static Boolean
+expression? Obviously a particular implementation might choose to reject such a
+construct, but this rule shouldn't be implementation-dependent, should it?
+
+This doesn't seem like a bad idea, but I think some new RM wording is needed to
+support this.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, August 3, 2010 11:46 AM
+
+It was certainly my expectation that
+pragmas like Pack, Atomic, Atomic_Components, etc. would all be considered to
+specify boolean-valued aspects. I agree that the RM needs to spell that out
+somewhere.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, August 3, 2010 4:16 PM
+
+In Valencia, we elected Bob Duff to write an AI to define all of the wording
+changes to individual aspects that will be needed. The intent we discussed was a
+blanket rules covering all specifiable aspects (which I think is already in
+AI-183), and then everything else will be worded explicitly. There is also
+supposed to be an annex similar to the pragma one that lists all specifiable
+aspects - Bob and I will need to work out the form of the individual entries for
+that (I will want to try to make it automatically generated similarly to the
+pragma and attribute annexes).
+
+P.S. Bob, see what happens when you don't come to a meeting? You get piles of
+new assignments! ;-)
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Friday, August 6, 2010 11:55 AM
+
+This is a small excerpt from the GNAT implementation:
+
+> -- We modify the RM grammar here, the RM grammar is:
+>
+> -- ASPECT_SPECIFICATION ::=
+> -- with ASPECT_MARK [=> ASPECT_DEFINITION] {.
+> -- ASPECT_MARK [=> ASPECT_DEFINITION] }
+>
+> -- ASPECT_MARK ::= aspect_IDENTIFIER['Class]
+>
+> -- ASPECT_DEFINITION ::= NAME | EXPRESSION
+>
+> -- That's inconvenient, since there is no non-terminal name for a single
+> -- entry in the list of aspects. So we use this grammar instead:
+>
+> -- ASPECT_SPECIFICATIONS ::=
+> -- with ASPECT_SPECIFICATION {, ASPECT_SPECIFICATION};
+>
+> -- ASPECT_SPECIFICATION =>
+> -- ASPECT_MARK [=> ASPECT_DEFINITION]
+>
+> -- ASPECT_MARK ::= aspect_IDENTIFIER['Class]
+>
+> -- ASPECT_DEFINITION ::= NAME | EXPRESSION
+
+We certainly find it useful to be able to talk about a single clause, which is
+why we made this change, I am surprised the same consideration does not apply to
+the RM description.
+
+No big deal certainly, since there is no requirement that we use exactly the RM
+grammar in the implementation. But worth a note to this list.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Saturday, August 7, 2010 5:36 PM
+
+Am I understanding right that you can only give one Pre or Post entry for a
+given subprogram?
+
+If so, I think that's a huge mistake,
+
+yes, sure you can join a bunch of conditions together with AND THEN, but this is
+a debugging mess if you have a huge conditional, and you don't know which part
+failed.
+
+In GNAT programmers can always use the Precondition and Postcondition pragmas
+(which are more flexible anyway, since you can give failure messages for each,
+and indeed multiple entries are allowed), but it seems unfortunate for the
+official version to be hobbled this way.
+
+If I misread the rules, ignore this!
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Saturday, August 7, 2010 8:02 PM
+
+> Am I understanding right that you can only give one Pre or Post entry
+> for a given subprogram?
+
+Only one each. They specify the "Pre" or "Post"
+aspect, so it seems inconsistent to allow that to be done more than once.
+Another problem is the confusion between when there are multiple specifications
+that apply, whether they are "or"ed or "and"ed. In the case of Pre'Class, they
+are "or"ed in when inherited. We could say that all the ones at the same
+"level" are "and"ed, but it just seemed easier to require the programmer to
+write "and" themselves.
+
+
+> If so, I think that's a huge mistake,
+>
+> yes, sure you can join a bunch of conditions together with AND THEN,
+> but this is a debugging mess if you have a huge conditional, and you
+> don't know which part failed.
+
+
+Debugging seems like something the implementation could help with. If the Pre
+is structured as a series of "and"ed boolean expressions, then it seems quite
+possible for the implementation to treat them exactly equivalently to separate
+precondition pragmas, if it feels that provides helpful information to the user.
+Effectively there would be separate source positions associated with each
+operand of "and" so that the exception-message could identify the first operand
+that evaluated to False.
+
+That would also be a useful feature for a normal "Assert" pragma. I often write
+them as a series of "and"ed conditions, and it would be nice if the
+implementation would identify the first operand that evaluated to False.
+
+> In GNAT programmers can always use the Precondition and Postcondition
+> pragmas (which are more flexible anyway, since you can give failure
+> messages for each, and indeed multiple entries are allowed), but it
+> seems unfortunate for the official version to be hobbled this way.
+>
+> If I misread the rules, ignore this!
+
+We thought about the issue, and concluded the confusion between "and" and "or"
+was a serious concern. I see your point about debugging, but I believe the
+implementation can help here without changing the language rules.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Sunday, August 8, 2010 6:00 PM
+
+When we discussed this within the ARG, we concluded that using Pre and Post for
+debugging ought to be discouraged, and thus having messages associated with them
+actually encouraged bad behavior.
+
+Debugging Pre and Post themselves is a different issue, but I think that is a
+general problem that needs to be solved more by tools (and perhaps by the
+implementation) than by the language. Making the semantics confusing (and how
+these things combine [only for inheritance] is completely confusing as it is) is
+not going to help anything. Besides, this is a problem with any complex
+conditional, and it makes sense to solve it for all conditionals, not just Pre
+and Post.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Sunday, August 8, 2010 10:51 PM
+
+> When we discussed this within the ARG, we concluded that using Pre and
+> Post for debugging ought to be discouraged, and thus having messages
+> associated with them actually encouraged bad behavior.
+
+If you have preconditions and post conditions, then sometimes they will fail. If
+they fail, you need to be able to find out how they are failing.
+
+> Debugging Pre and Post themselves is a different issue, but I think
+> that is a general problem that needs to be solved more by tools (and
+> perhaps by the
+> implementation) than by the language. Making the semantics confusing
+> (and how these things combine [only for inheritance] is completely
+> confusing as it is) is not going to help anything. Besides, this is a
+> problem with any complex conditional, and it makes sense to solve it
+> for all conditionals, not just Pre and Post.
+
+But complex conditionals are evil, and easily broken up in most cases, and most
+certainly SHOULD be broken up, but you are making this normal good programming
+practice impossible for preconditions and postconditions.
+
+I don't mind too much, obviously we are not going to change the semantics of the
+GNAT pragmas, so if the official version is less capable, that's no big deal for
+us!
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Sunday, August 8, 2010 10:55 PM
+
+> Debugging seems like something the implementation could help with. If
+> the Pre is structured as a series of "and"ed boolean expressions, then
+> it seems quite possible for the implementation to treat them exactly
+> equivalently to separate precondition pragmas, if it feels that
+> provides helpful information to the user. Effectively there would be
+> separate source positions associated with each operand of "and" so
+> that the exception-message could identify the first operand that
+> evaluated to False.
+
+Sure, but that's much too difficult to do in our context, so it won't happen.
+
+> That would also be a useful feature for a normal "Assert"
+> pragma. I often write them as a series of "and"ed conditions, and it
+> would be nice if the implementation would identify the first operand
+> that evaluated to False.
+
+I always prefer a series of separate assertions, I don't like complex
+conditionals ANYwhere in ANY code :-)
+
+...
+> We thought about the issue, and concluded the confusion between "and"
+> and "or" was a serious concern.
+> I see your point about debugging, but I believe the implementation can
+> help here without changing the language rules.
+
+I understand the reasoning, but I still don't like it, but as I noted in my
+preious message, I don't really care, since people can always use the GNAT
+pragmas which don't have this limitation instead.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Sunday, August 15, 2010 8:31 PM
+
+For the case of pre/post conditions etc, we definitely want to delay visibility
+analysis until the freeze point, but what about something like
+
+ type Int is new Integer
+ with Size => B'Size;
+
+We have three options. Robert initially argued in an internal discussion, that
+the simples was to treat this the same as
+
+ type Int is new Integer;
+ for Int'Size use B'Size;
+
+And in particular, does not like the visibility of B depending on the freeze
+point for Int, since programmers really don't know the details of where things
+get frozen.
+
+But Tuck argues that it is undesirable to cause what might be premature freezing
+of B. In the case of the rep clause, this can be solved by simply moving the rep
+clause later, but you don't have this option with the Aspect form.
+
+He suggests doing the visibility analysis right away, but deferring evaluation
+of the expression and consequent freezing to the freeze point for the entity
+(same kind of mechanism as for default parameter expressions).
+
+Robert is convinced by this argument, and agrees with this proposal, if everyone
+agrees the AI needs updating to reflect this.
+
+I have implemented this approach, as shown by the following test program:
+
+> 1. with Text_IO; use Text_IO;
+> 2. procedure AttrDelay is
+> 3. type S is new Integer range 1 .. 10;
+> 4.
+> 5. -- Size should be 8 at freeze point
+> 6. type R is new Integer range 1 .. 2
+> 7. with Size => S'Size;
+> 8.
+> 9. -- Pack should be effective (size 32)
+> 10. -- since S'Size = 8 at freeze point
+> 11. type R2 is array (0 .. 31) of Boolean
+> 12. with Pack => S'Size = 8;
+> 13.
+> 14. for S'Size use 8;
+> 15.
+> 16. begin
+> 17. Blk : declare
+> 18. -- Get S above, not S below (evaluation is
+> 19. -- delayed, but not visibility) so 8, not 32
+> 20. type R3 is new Integer range 1 .. 2
+> 21. with Size => S'Size;
+> 22. type S is new Integer;
+> 23. begin
+> 24. Put_Line (R'Size'Img);
+> 25. Put_Line (R2'Size'Img);
+> 26. Put_Line (Blk.R3'Size'Img);
+> 27. end Blk;
+> 28. end;
+
+This outputs:
+
+ 8
+ 32
+ 8
+
+If we didn't delay evaluation, the program would be illegal, since the aspect at
+line 7 would freeze S, and the rep clause on line 14 would be too late.
+
+If we delayed visibility analysis to the freeze point, the last line of output
+would be 32 rather than 8.
+
+I definitely think the compromise suggested by Tuck, and implemented above is
+the way to go!
+
+****************************************************************
+
+From: Robert A Duff
+Sent: Monday, August 16, 2010 8:28 AM
+
+> If we didn't delay evaluation, the program would be illegal, since the
+> aspect at line 7 would freeze S, and the rep clause on line
+> 14 would be too late.
+
+Undesirable, but not the end of the world. You can always use the old syntax
+for Size clauses.
+
+I'm not sure I fully understand the issue -- if we chose this, would it affect
+any of the new attributes (Pre, Post, Invariant, Predicate, ...)?
+
+> If we delayed visibility analysis to the freeze point, the last line
+> of output would be 32 rather than 8.
+
+That seems very bad. It would mean S'Size evaluates to different values at
+different places, if I understand correctly.
+
+> I definitely think the compromise suggested by Tuck, and implemented
+> above is the way to go!
+
+I think I agree with that.
+
+But there's another option to consider: Do we really need this new syntax for
+all the old attributes? I mean, we already have a way to specify Size and Pack
+and so on. What problem does this solve?
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, August 16, 2010 2:40 PM
+
+> > If we didn't delay evaluation, the program would be
+> illegal, since the
+> > aspect at line 7 would freeze S, and the rep clause on line
+> > 14 would be too late.
+>
+> Undesirable, but not the end of the world. You can always use the old
+> syntax for Size clauses.
+>
+> I'm not sure I fully understand the issue -- if we chose this, would
+> it affect any of the new attributes (Pre, Post, Invariant, Predicate,
+> ...)?
+
+Pre/Post delay *resolution* to the end of the declarative part, or something
+like that. Those are different rules, I think.
+
+> > If we delayed visibility analysis to the freeze point, the last line
+> > of output would be 32 rather than 8.
+>
+> That seems very bad. It would mean S'Size evaluates to different
+> values at different places, if I understand correctly.
+
+We discussed a problem somewhat like this in Valencia. "Freeze point" is a bad
+place to do anything (because it moves easily and programmers don't really know
+where it is); I think we had decided to make programs illegal if the resolution
+changes between the aspect clause and the end of the declarative part. (Or
+something like that.)
+
+> > I definitely think the compromise suggested by Tuck, and implemented
+> > above is the way to go!
+>
+> I think I agree with that.
+>
+> But there's another option to consider: Do we really need this new
+> syntax for all the old attributes? I mean, we already have a way to
+> specify Size and Pack and so on. What problem does this solve?
+
+The problem solved is applying an aspect to one of a set of overloaded entities.
+The current mechanisms make that impossible.
+
+For other things, it's just a unification. But it seems a valuable one to me,
+since it is much less likely be applied to the wrong entity or get the wrong
+value because of changes.
+
+The latter factor makes me wonder if we would be better off without a fancy rule
+for the "normal" case of specifying an attribute; leaving Robert's example
+illegal -- since, as Bob notes, you can always fall back to a regular size
+clause if you need something like that. It's not clear (it seems valuable to
+have some sort of delay rule so that aspect clauses can be used to provide
+stream attributes, the routines of which cannot possibly be declared at the
+point of the type declaration).
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, August 16, 2010 3:16 PM
+
+> I'm not sure I fully understand the issue -- if we chose this, would
+> it affect any of the new attributes (Pre, Post, Invariant, Predicate,
+> ...)?
+
+No, these are cases where the evaluation of the expression is not associated
+with the freeze point of the entity, but is delayed to much later, so in these
+cases, we do delay analysis of the expression to the freeze point to allow
+forward references (just as the pragmas do in GNAT now).
+
+...
+> But there's another option to consider: Do we really need this new
+> syntax for all the old attributes? I mean, we already have a way to
+> specify Size and Pack and so on. What problem does this solve?
+
+I think it's nice to have, don't use it if you don't like it.
+It's all implemented already, so the implementation is not a barrier, and it
+gives additional capabilities (cancelling and parametrizing attributes) that we
+do not have now.
+
+I see no reason to back pedal on this nice feature.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, August 16, 2010 3:25 PM
+
+> The latter factor makes me wonder if we would be better off without a
+> fancy rule for the "normal" case of specifying an attribute; leaving
+> Robert's example illegal -- since, as Bob notes, you can always fall
+> back to a regular size clause if you need something like that. It's
+> not clear (it seems valuable to have some sort of delay rule so that
+> aspect clauses can be used to provide stream attributes, the routines
+> of which cannot possibly be declared at the point of the type declaration).
+
+I like Tuck's suggestion. If you get things wrong, you get a clear message that
+some rep clause is too late, and GNAT will point out the freeze point involved
+precisely.
+
+I do think that you don't want the meaning to change with the freeze point. But
+it is OK if you get a rep item too late, you can just fiddle to fix it.
+
+The point is that we already have these expressions which are resolved early,
+but evaluated late (e.g. default expressions), and so this is familiar and easy
+to implement.
+
+> We discussed a problem somewhat like this in Valencia. "Freeze point"
+> is a bad place to do anything (because it moves easily and programmers
+> don't really know where it is); I think we had decided to make
+> programs illegal if the resolution changes between the aspect clause
+> and the end of the declarative part. (Or something like that.)
+
+UGHHHHH! That would be complicated to describe and a huge effort to implement
+for zero gain! Anything like this that tinkers with the visibility mechanism is
+diabolical!
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, August 16, 2010 3:54 PM
+
+Steve Baird showed examples where the value of the expression (and the entities
+involved) could depend on the freeze point. That would be a *massive*
+maintenance hazard, since freeze points change easily and often during
+maintenance (and it usually doesn't matter at all).
+
+The model that we were talking about is that the compiler would resolve the
+expression at both points, and if it gets a different answer at the two points,
+then the expression is illegal. There would be no "visibility changes" involved.
+You might be right that that will be complicated to explain in RM terms, but I
+don't think it will be hard to explain to users or difficult to implement.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, August 16, 2010 4:08 PM
+
+> Steve Baird showed examples where the value of the expression (and the
+> entities involved) could depend on the freeze point. That would be a
+> *massive* maintenance hazard, since freeze points change easily and
+> often during maintenance (and it usually doesn't matter at all).
+
+I an unconvinced, tempest in a teapot, almost always these expressions are
+simple and all three approaches would give the same result. I really think this
+is worrying about nonsense. The "*massive* maintenance hazard" phrase above is
+unreasonale hyperobole. Almost always the issue would be a too late rep clause.
+I know you can concoct examples. Indeed I had to concoct pretty peculiar
+examples to test, and furthermore I discovered that we have had a bug in
+handling attributes in default expressions that has gone unnoticed for 15 years
+(X'Size is evaluated prematurely at the preanalysis point and thus could give
+the wrong result).
+
+> The model that we were talking about is that the compiler would
+> resolve the expression at both points, and if it gets a different
+> answer at the two points, then the expression is illegal. There would
+> be no "visibility changes" involved. You might be right that that will
+> be complicated to explain in RM terms, but I don't think it will be
+> hard to explain to users or difficult to implement.
+
+it will be difficult to implement, I would not even think of doing this, even if
+it is required by the RM, any attempt to do double resolution like this would be
+a huge earthquake.
+
+I don't seriously object to the rule being in the RM, but I doubt we would ever
+implement it. Just not worth the effort IMO. It's always possible there is some
+clever way of doing this, but I sure don't see if right now.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, August 16, 2010 4:27 PM
+
+> it will be difficult to implement, I would not even think of doing
+> this, even if it is required by the RM, any attempt to do double
+> resolution like this would be a huge earthquake.
+
+Doesn't seem that difficult to me. For Janus/Ada, all that would be required
+would be to make a copy of the tree and give the copy to the expression
+resolver. You'd only do this if the first resolution was successful, so any
+errors that occurred on the second resolution would necessarily indicate
+differences and would therefore be real errors -- so no special machinery is
+needed to do the resolution. There would need to be a tree compare routine, but
+it's major job would be to check that the identifier symbol resolutions match
+(the rest of the tree would have to be identical, of course).
+
+Obviously, just because it seems easy in Janus/Ada doesn't mean anything about
+the effort in another implementation, but no one in Valencia indicated that this
+check would be a significant hardship in their compilers. (Of course, no one had
+thought about it that deeply.)
+
+> I don't seriously object to the rule being in the RM, but I doubt we
+> would ever implement it. Just not worth the effort IMO. It's always
+> possible there is some clever way of doing this, but I sure don't see
+> if right now.
+
+The above is how I would do it; it would be similar to the way we handle default
+expressions now (the difference being that we would be redoing the resolution
+phase rather than the legality check phase). But of course YMMV.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, August 16, 2010 4:38 PM
+
+I still think it is a case of worrying about zero probability events :-)
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, August 16, 2010 4:40 PM
+
+>> I don't seriously object to the rule being in the RM, but I doubt we
+>> would ever implement it. Just not worth the effort IMO. It's always
+>> possible there is some clever way of doing this, but I sure don't see
+>> if right now.
+>
+> The above is how I would do it; it would be similar to the way we
+> handle default expressions now (the difference being that we would be
+> redoing the resolution phase rather than the legality check phase). But of
+> course YMMV.
+
+In practice I would guess that the delay NEVER EVER will affect the value of the
+aspect expression. You may then ask, why do it? The answer is that the premature
+freezing could be a problem, e.g. for declarting primitive operations. The ARG's
+taste for complexity never ceases to amaze me :-) :-)
+
+****************************************************************
+
+From: Robert A Duff
+Sent: Monday, August 16, 2010 7:15 PM
+
+> > But there's another option to consider: Do we really need this new
+> > syntax for all the old attributes? I mean, we already have a way to
+> > specify Size and Pack and so on. What problem does this solve?
+>
+> The problem solved is applying an aspect to one of a set of overloaded
+> entities. The current mechanisms make that impossible.
+>
+> For other things, it's just a unification. But it seems a valuable one
+> to me, since it is much less likely be applied to the wrong entity or
+> get the wrong value because of changes.
+
+OK, those are strong arguments. I withdraw my suggestion of "another option to
+consider".
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, August 16, 2010 6:59 AM
+
+The AI has a list of declarations to which aspects may be attached.
+
+Not clear if there are standard aspects for all these declarations or not.
+
+Wouldn't it be easier to just list the standard aspects together with what
+declarations they apply to, then as implementation permission allow
+implementations to define implementation dependent aspects on whatever
+declarations they like
+
+(for instance in GNAT, the aspect
+
+ with Warnings => Off;
+
+applies to all entities)
+
+This may seem non-portable, but it is not more non-portable than allowing
+impl-defined aspects in the first place. After all an unrecognized aspect
+(unlike an unrecognized pragma) is an illegality (though we could reconsider
+that decision???)
+
+BTW, in GNAT we will introduce new pragmas for new aspects like Invariant in any
+case. The advantage of pragmas over aspects is that they can be retrofitted into
+earlier versions of Ada.
+
+****************************************************************
+
+From: Robert A Duff
+Sent: Monday, August 16, 2010 2:15 PM
+
+> Wouldn't it be easier to just list the standard aspects together with
+> what declarations they apply to, then as implementation permission
+> allow implementations to define implementation dependent aspects on
+> whatever declarations they like
+
+I don't see how this can work. It's not just a "list of declarations" -- it's a
+whole bunch of new syntax rules. I don't think we want to let implementations
+define their own syntax (in the standard-conforming mode).
+
+Or am I misunderstanding the idea?
+
+> (for instance in GNAT, the aspect
+>
+> with Warnings => Off;
+>
+> applies to all entities)
+
+Hmm. The AI says you can't have an aspect clause on a renaming_declaration.
+I think you can have pragma Warnings(Off) on a renaming...
+
+> This may seem non-portable, but it is not more non-portable than
+> allowing impl-defined aspects in the first place. After all an
+> unrecognized aspect (unlike an unrecognized pragma) is an illegality
+> (though we could reconsider that decision???)
+
+Unrecognized pragmas are legal. I guess you meant unrecognized attributes are
+illegal. But I don't see how to reconsider that -- the compiler needs to know
+the overload resultion rules for every attribute.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, August 16, 2010 2:46 PM
+
+> Unrecognized pragmas are legal. I guess you meant unrecognized
+> attributes are illegal. But I don't see how to reconsider that -- the
+> compiler needs to know the overload resultion rules for every
+> attribute.
+
+I think aspect clauses have the same problem: we need to know the expected type
+for the expression of the aspect clause.
+
+I suppose we might be able to say that the expression is not resolved at all in
+that case; but that seems like a good way to hide errors (which depends on what
+the compiler does with warnings, I guess). That is, if someone mistakenly
+writes:
+
+ when Invariant => Whatever,
+
+rather than
+
+ when Type_Invariant => Whatever,
+
+they could get a false sense of security as Whatever wouldn't be checked.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, August 16, 2010 3:19 PM
+
+> I don't see how this can work. It's not just a "list of declarations"
+> -- it's a whole bunch of new syntax rules. I don't think we want to
+> let implementations define their own syntax (in the standard-conforming mode).
+>
+> Or am I misunderstanding the idea?
+
+I would allow syntactically aspects after almost any declaration, whether
+implementations take advantage of them is up to them.
+
+>> (for instance in GNAT, the aspect
+>>
+>> with Warnings => Off;
+>>
+>> applies to all entities)
+>
+> Hmm. The AI says you can't have an aspect clause on a renaming_declaration.
+> I think you can have pragma Warnings(Off) on a renaming...
+
+Right, so why not allow
+
+ X : Integer renames Y with Warnings => Off;
+
+what's the harm?
+
+>> This may seem non-portable, but it is not more non-portable than
+>> allowing impl-defined aspects in the first place. After all an
+>> unrecognized aspect (unlike an unrecognized pragma) is an illegality
+>> (though we could reconsider that decision???)
+>
+> Unrecognized pragmas are legal. I guess you meant unrecognized
+> attributes are illegal. But I don't see how to reconsider that -- the
+> compiler needs to know the overload resultion rules for every
+> attribute.
+
+No, I meant *EXACTLY* what I said, unrecognized aspects are illegal, unlike
+unrecognized pragmas which are legal. Reread my sentence it is exactly what I
+meant to say! And it has nothing to do with attributes!
+
+My suggestion was possibly that compilers be allowed to ignore unrecognized
+aspects with a warning, like they do for pragmas.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, August 16, 2010 3:26 PM
+
+> I think aspect clauses have the same problem: we need to know the
+> expected type for the expression of the aspect clause.
+
+Not if you are ignoring it! It's the same as pragmas, if you ignore a pragma,
+you ignore the expressions
+
+> I suppose we might be able to say that the expression is not resolved
+> at all in that case; but that seems like a good way to hide errors
+> (which depends on what the compiler does with warnings, I guess). That
+> is, if someone mistakenly writes:
+>
+> when Invariant => Whatever,
+>
+> rather than
+>
+> when Type_Invariant => Whatever,
+>
+> they could get a false sense of security as Whatever wouldn't be checked.
+
+There would of course be a warning, same issue happens with pragmas now after
+all.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, August 16, 2010 4:04 PM
+
+...
+> > Hmm. The AI says you can't have an aspect clause on a renaming_declaration.
+> > I think you can have pragma Warnings(Off) on a renaming...
+>
+> Right, so why not allow
+>
+> X : Integer renames Y with Warnings => Off;
+>
+> what's the harm?
+
+The harm is that is completely destroys the model of aspects (and of
+renaming) in the language. All aspects have an important property that they are
+the same for all views of an entity. An important correllary is that aspects are
+not changed by renaming an entity.
+
+If you have some property that is different for different views, then is it not
+an aspect. (The language generally calls those things characteristics.) Ergo, it
+cannot be specified by an aspect clause.
+
+Warnings => Off is clearly not an aspect if it can apply to a rename.
+
+If we did allow an aspect clause on a renames, we would need to invent some sort
+of matching rules for aspects, since the language-defined aspects cannot be
+changed on a renames. That is an utter mess (and it is why while we allow
+aspects on generic formal parameters, there is a blanket rule disallowing the
+use of any aspects there unless they are explicitly allowed and define an
+appropriate matching rule).
+
+Now, obviously no one is going to go around and check if any
+implementation-defined things aren't formally aspects, but there is no reason
+for the language to encourage the abuse of aspects by implementations. So if you
+want to allow Warnings => Off as an aspect but not have it act like one, no one
+is going to stop you, but it is still not right.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, August 16, 2010 4:15 PM
+
+It's useful, and useful to users of GNAT trumps Randy's idea of "right" :-)
+
+Anyway, no big deal, for now, the GNAT aspects apply only to the official
+declarations, and actually, to be truthful, I have had enough of molesting the
+parser for these declarations, and don't really want to extend the use of
+aspects, so I withdraw the suggestion.
+
+I do think it's a pity that you can't have aspects on formal parameters of
+subprograms. Oh well.
+
+For interest here is the list of aspects implemented by GNAT (I did not do
+Pre/Post condition, invariant, predicate yet)
+
+ Ada_2005 -- GNAT
+ Ada_2012 -- GNAT
+ Address
+ Alignment
+ Atomic
+ Atomic_Components
+ Bit_Order
+ Component_Size
+ Discard_Names
+ External_Tag
+ Favor_Top_Level -- GNAT
+ Inline
+ Inline_Always -- GNAT
+ Invariant
+ Machine_Radix
+ No_Return
+ Object_Size -- GNAT
+ Pack
+ Persistent_BSS -- GNAT
+ Post
+ Pre
+ Predicate
+ Preelaborable_Initialization
+ Pure_Function -- GNAT
+ Shared -- GNAT
+ Size
+ Storage_Pool
+ Storage_Size
+ Stream_Size
+ Suppress
+ Suppress_Debug_Info -- GNAT
+ Unchecked_Union
+ Universal_Aliasing -- GNAT
+ Unmodified -- GNAT
+ Unreferenced -- GNAT
+ Unreferenced_Objects -- GNAT
+ Unsuppress
+ Value_Size -- GNAT
+ Volatile
+ Volatile_Components
+ Warnings -- GNAT
+
+This was the biggest AI to implement so far, LOTS of changes, but it seems to be
+all working now.
+
+I can easkly change to the model of immediate evaluation (I don't like it, but
+Randy and Bob seem favorably inclined). Or to the deffered visibility analysis
+that is in the AI (but that's horrible I think we can all agree).
+
+I am dubious about changing to the business of resolving twice to see if you get
+the same result, I don't see any easy way of doing that, but as I say, you never
+know, things that seem difficult have a way of proving easier after all.
+
+****************************************************************
+
+From: Robert A Duff
+Sent: Monday, August 16, 2010 7:20 PM
+
+> I would allow syntactically aspects after almost any declaration,
+> whether implementations take advantage of them is up to them.
+
+Seems reasonable.
+
+> Right, so why not allow
+>
+> X : Integer renames Y with Warnings => Off;
+>
+> what's the harm?
+
+No harm.
+
+> >> This may seem non-portable, but it is not more non-portable than
+> >> allowing impl-defined aspects in the first place. After all an
+> >> unrecognized aspect (unlike an unrecognized pragma) is an
+> >> illegality (though we could reconsider that decision???)
+> >
+> > Unrecognized pragmas are legal. I guess you meant unrecognized
+> > attributes are illegal. But I don't see how to reconsider that --
+> > the compiler needs to know the overload resultion rules for every
+> > attribute.
+>
+> No, I meant *EXACTLY* what I said, unrecognized aspects are illegal,
+> unlike unrecognized pragmas which are legal.
+> Reread my sentence it is exactly what I meant to say! And it has
+> nothing to do with attributes!
+
+Sorry for the noise! I must have misread "unlike" to be "like", or something.
+Now I understand.
+
+> My suggestion was possibly that compilers be allowed to ignore
+> unrecognized aspects with a warning, like they do for pragmas.
+
+Seems OK. No big deal -- any compiler can have warnings-as-errors mode, and/or
+errors-as-warnings mode.
+
+****************************************************************
+
From: Christoph Grein
Sent: Tuesday, September 28, 2010 2:33 AM
@@ -3373,3 +4485,7 @@
****************************************************************
+[Randy's note: Mail from August and September probably goes at line 2799
+in this file.]
+
+****************************************************************
Questions? Ask the ACAA Technical Agent