!standard 5.4 (7) 02-05-28 AC95-00037/01 !class amendment 02-05-28 !status received no action 02-06-07 !subject Parenthesizing expression makes a difference !summary !appendix From: Adam Beneschan Sent: Tuesday, May 28, 2002 6:35 PM !topic Parenthesizing expression makes a difference !reference RM95-5.4(7-9) !from Adam Beneschan 05-28-02 !discussion It appears that in Ada 95, an attempt was made to make sure that X and (X) are not treated differently when the syntax requires an expression (as, for example, in 4.3.3(15)). This wasn't done for CASE statements. In this example, parentheses affect the legality of a CASE statement: subtype Sub is Integer range 1 .. 10; S : Sub; case S is when 5 => Do_Something_1; when 15 => Do_Something_2; -- ILLEGAL by 5.4(7) when others => Do_Something_3; end case; case (S) is when 5 => Do_Something_1; when 15 => Do_Something_2; -- LEGAL by 5.4(9) since (S) -- is not a "name" when others => Do_Something_3; end case; Is this difference intentional? (This example was inspired by ACATS test c54a13d.) **************************************************************** From: Robert Dewar Sent: Wednesday, June 5, 2002 8:33 PM ??Is this difference intentional? _ Yes! THis is well known, and is a natural consequence of the rules. I see no reason to argue at this stage for installing an odd non-orthogonal rule that would "fix" this "anomoly". **************************************************************** From: Pascal Leroy Sent: Thursday, June 6, 2002 1:37 AM This may be well known to Robert, but it came as a surprise to me, so I suppose it could surprise other naive users of the language. While this is certainly not of paramount importance, I find it distasteful when the rules exhibit this kind of anomalies, especially when the AARM makes it clear that this intent of the designers of the language was to eliminate them. I have always found it strange how parenthesized expressions are handled in the RM (and I realize that this goes back to the Ada 83 days). Instead of one section in chapter 4 detailing the semantics of these expressions, we have maybe two dozen places in the RM which say "... oh and by the way parenthesized_expressions too ...". One funny detail is that the dynamic semantics of parenthesized expressions is nowhere defined. But here, Adam points out a more annoying consequence of this situation. **************************************************************** From: Randy Brukardt Sent: Thursday, June 6, 2002 12:28 PM > This may be well known to Robert, but it came as a surprise to me, so I > suppose it could surprise other naive users of the language. Yes, when this came up at the last ARG meeting, several of us had to look it up. I recorded the event in the minutes as follows: "Why aren't parenthesized expressions considered inferable discriminants? Steve says this is to match the rules for case statements. This sends several ARG members scrambling to their RMs. Sure enough, a parenthesized case expression requires full coverage. The point is conceded." > While this is certainly not of paramount importance, I find it distasteful > when the rules exhibit this kind of anomalies, especially when the AARM > makes it clear that this intent of the designers of the language was to > eliminate them. > > I have always found it strange how parenthesized expressions are handled in > the RM (and I realize that this goes back to the Ada 83 days). Instead of > one section in chapter 4 detailing the semantics of these expressions, we > have maybe two dozen places in the RM which say "... oh and by the way > parenthesized_expressions too ...". One funny detail is that the dynamic > semantics of parenthesized expressions is nowhere defined. But here, Adam > points out a more annoying consequence of this situation. The problem is that fixing this (with a natural rule, not "odd" as Robert claims) is incompatible - existing legal programs become illegal. I can even imagine someone taking advantage of this to "turn off" completeness checking (so that bounded error cases can be detected). I doubt that sufficient value can be found to make such an incompatible change. Eliminating access subtypes for general access types would be easier to justify (because of the problems that supporting them cause elsewhere). But there is no "problem" in this case. **************************************************************** From: Robert Dewar Sent: Thursday, June 6, 2002 8:46 PM Well of course you can't use a natural rule, precisely *because* it would have this effect. I was saying that a rule that fixed this without causing the obviously unacceptable incompatibility would be odd -- and I think you agree. The point about deliberate use is an interesting one! **************************************************************** From: Randy Brukardt Sent: Friday, June 7, 2002 7:47 PM I guess I don't understand. Either you eliminate the anomaly (which is incompatible), or you leave things alone. If you keep compatibility, you are by definition keeping the anomaly, so you haven't fixed anything, so why change anything at all? Anyway, I think everyone agrees that we aren't going to make a change here, so we can leave the point moot. (Did I use "moot" correctly, Robert?) **************************************************************** From: Robert Dewar Sent: Friday, June 7, 2002 10:34 PM > I guess I don't understand. Either you eliminate the anomaly (which is > incompatible), or you leave things alone. If you keep compatibility, you are > by definition keeping the anomaly, so you haven't fixed anything, so why > change anything at all? The only acceptable change would be one that made otherwise illegal programs legal by treating (x) as equivalent to x in certain cases to achieve this goal. Such a change is certainly possible, and would be upwards compatible, but would be a kludge, and in my opinion, fixing something that is not broke anyway. **************************************************************** From: Robert Dewar Sent: Friday, June 7, 2002 10:35 PM > Anyway, I think everyone agrees that we aren't going to make a change here, > so we can leave the point moot. (Did I use "moot" correctly, Robert?) Yes, indeed, moot = undecidable, arguable (which is why I continued to argue about it :-) **************************************************************** From: Robert Dewar Sent: Thursday, June 6, 2002 8:47 PM Basically the point here is that it is the case statement itself which is anomolous in my view, since normally an expression always yields the base type and we have to specifically avoid this in this case, hence the special rule 7 If the expression is a name (including a type_conversion or a function_call) having a static and constrained nominal subtype, or is a qualified_expression whose subtype_mark denotes a static and constrained scalar subtype, then each non-others discrete_ choice shall cover only values in that subtype, and each value of that subtype shall be covered by some discrete_choice (either explicitly or by others). That's definitely an odd rule. I think it gets even odder if you try to fix this anomoly :-) **************************************************************** From: Pascal Leroy Sent: Thursday, June 6, 2002 3:41 PM I was not suggesting that we change this, I was just commenting on the sorry state of affair regarding parenthesized expressions. **************************************************************** From: Robert Dewar Sent: Thursday, June 6, 2002 9:19 PM I don't think this is so sorry. Does it worry people that you cannot write (a) := 3; The syntactic distinction between names and expressions seems perfectly reasonable to me. **************************************************************** From: Robert A. Duff Sent: Friday, June 7, 2002 7:37 AM > I don't think this is so sorry. Does it worry people that you cannot write > > (a) := 3; Yes. But not enough to advocate changing the language. ;-) > The syntactic distinction between names and expressions seems perfectly > reasonable to me. I think it adds complexity. It also limits functionality (in rare cases). **************************************************************** From: Robert Dewar Sent: Friday, June 7, 2002 11:06 PM OK, well that's quite an unusual view. For most people I think that allowing this form would seem very odd. Now of course A68 allows this, but there are no such thing as names in A68, only values (so assignment is for example an operator that operates on two values). **************************************************************** From: Pascal Leroy Sent: Saturday, June 8, 2002 2:55 AM Well, C allows it, and I occasionally find it useful to be able to parenthesize the lvalue when it is complicated (in particular, when it includes casts) to improve readability a bit. I guess I am as weird as Bob.. **************************************************************** From: Robert A Duff Sent: Monday, June 10, 2002 3:44 PM > OK, well that's quite an unusual view. For most people I think > that allowing this form would seem very odd. It's not that I particularly want to write (a) := 3; I just think that it would simplify the language to make the distinction between names and expressions (or objects and values, or l-values and r-values, or whatever you want to call it) in the type system, rather than in the syntax. As you say, Algol-86 does just that, which is nice, except that they made it rather error prone by conflating pointers and variables, and by allowing implicit dereferences (multiple of them on the same expression!). One annoyance in Ada is that you can qualify an expression by its type (T'(X)), but you can't qualify a name in that way. That kind of silly restriction wouldn't happen if there were no syntactic distinction between name and expression. > Now of course A68 allows this, but there are no such thing as names > in A68, only values (so assignment is for example an operator that > operates on two values). ****************************************************************