Version 1.1 of acs/ac-00037.txt

Unformatted version of acs/ac-00037.txt version 1.1
Other versions for file acs/ac-00037.txt

!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
!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).

****************************************************************


Questions? Ask the ACAA Technical Agent