Version 1.1 of acs/ac-00154.txt

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

!standard 8.5.1(6)          07-12-06 AC95-00154/01
!standard 8.5.4(7)
!class confirmation 07-12-06
!status received no action 07-12-06
!status received 07-11-27
!subject Historical question: why are constraints ignored in renamings?
!summary
!appendix

From: John Barnes
Sent: Tuesday, November 27, 2007  5:44 AM

One of my colleaugues in the BSI has raised a question about renaming. He
needs to refute someone who says that Ada is stupid.

I apologise if this is not proper Ada 2005 business.

But first let me recap the issue of default subprogram parameters because
that might be relevant.

In preliminary Ada, any default expression was evaluated when the subprogram
spec was elaborated. It was like that in the 1979 SigPlan notices and in the
July 1980 proposed standard

The first edition of my book (early 1982) says that as well.

There was a problem with matching spec and body if I recall correctly since
the value might be different when the body was elaborated. As a consequence
it was made dynamic and only evaluated when required. That was nice because
the default spirit in one of my examples could then be Gin in the week and
Vodka at weekends. This probably happened some time in 1982.

Thus by July 1982 (draft revised mil std 1815) the manual had changed to say
that the default expresion was evaluated when used. As it is now of course.

Now with regard to renaming. The issue is why are constraints given by the
renaming ignored and when did that happen? The 1979 preliminary Ada is
pretty vague but hints that the constraints are unchanged - it doesn't say
that new ones are ignored so perhaps it implies they have to match. The July
1980 proposd standard is much clearer and says that constraints must be the
same (and raises C_E if they are not). The July 1982 manual says that
constraints are unchanged by the renaming.

Similarly, the first edition of my book (early 1982) says "at the time of
elaboration of the renaming declaration any constraints must match". Whereas
the second edition is as now and says new ones are ignored.

The various rationales are unhelpful. And I can find no minutes of meetings
from that time.

Questions

Were the two issues related?  And why did we end up ignoring new
constraints? (I usually mutter something about well you can just do a quick
jump (into the ocean perhaps).)

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

From: Tucker Taft
Sent: Tuesday, November 27, 2007  7:29 AM

I had presumed that new constraints were ignored
because of the equivalence with generic formal
subprograms and formal IN OUT objects.  It would
be limiting to require the constraints to match
for such generic formals, and since they are
defined in terms of renaming, it would break
the equivalence if renaming required exact matching.

Here is another reason: before Ada 95, X'Base could
only be used as the prefix of an attribute reference.
In particular, it couldn't be used for the subtype
of a formal parameter.  However, the formal parameter
subtype for the predefined operators are generally
the base subtype, and if there is no way to state
that, then renaming of predefined operators would
not be possible.

Of course times have changed, and we might consider
tightening this up in the future.  I suppose one
step to that would be defining some kind of "restriction"
in the High-Integrity annex requiring that constraints
in renames must match.

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

From: John Goodenough
Sent: Tuesday, November 27, 2007  10:43 AM

Remarkably enough, I can answer this question. (Apparently it does pay
to keep documents in your office for 25 years!)

------

On June 1, 1982, Kit Lester of the Language Design Team wrote a comment
directly addressing why constraints are ignored in renaming:

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

This comment paraphrases a discussion at the November 1981 DR's meeting,
for those without access to the minutes (LSN.250, pages 6 and 7).  See
also comment #753 by George Romanski of Ada-Europe.

Many users will be shocked that explicit constraints on type marks
appearing in renaming declarations of objects or subprograms (or in
generic formal declarations defined in terms of renaming) will be
ignored.  Eg:

        subtype POSITIVE is INTEGER range 1 .. NATURAL'LAST
        POS : POSITIVE;
        subtype SMALL is INTEGER range -9 .. +9;
        SML : SMALL renames POS;  -- legal
          ...
        SML := 10;   -- not small, but ok; shock
        SML := -1;   -- small but raises CONSTRAINT_ERROR; shock

Various restrictions on the type mark have been considered, but
rejected:

(1)     The type mark must be unconstrained.  Rejected because the type
        might be invisible where the subtype is visible, and because
        it would preclude writing subtype marks implying the same
        constraint.

(2)     Requring the type mark be followed by 'BASE; this is saying what
        is meant, but

          - gives an attribute returning a type (whereas at present
            'BASE must be followed by another attribute, i.e., it
            modifies the following attribute rather than existing in
            its own right);

        and

          - requires radical syntax changes for renaming of subprograms
            with parameters or results, or an obscure restriction to
            achieve the same effect.

(3)     Demanding "equivalent constraints" requires new equivalence
        rules, including means for defining "sufficiently equal"
        floating point values resulting from different expressions.

The alternative of not ignoring explicit constraints is also
unacceptable; if the assignment SML := -1; in the above example did NOT
raise CONSTRAINT_ERROR then the variable POS would have a negative value
...

In summary: in the absence of an acceptable solution, the problem must
be accepted.

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

From: Tucker Taft
Sent: Tuesday, November 27, 2007  11:47 AM

Interesting.  It seems like all of the problems identified
now have reasonable solutions in Ada 95, so we could probably
shift toward requiring static matching of constraints.
As I suggested in my earlier note, providing a "Restriction"
in the High-Integrity Annex might be a good first step.

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

From: Robert A. Duff
Sent: Tuesday, November 27, 2007  1:32 PM

> Remarkably enough, I can answer this question. (Apparently it does pay
> to keep documents in your office for 25 years!)

Good to hear from you, John.  Thanks for keeping those docs for 25 years!

If you have machine-readable copies of these historical documents, I think it
would be a good service to the community if you could get Randy to put them up
on the web site.

> (1)     The type mark must be unconstrained.  Rejected because the type
>         might be invisible where the subtype is visible, ...

That part seems confused, to me.  The same confusion that caused the language
designers to make with_clauses intransitive.  And not to allow with_clauses on
private parts.

>...and because
>         it would preclude writing subtype marks implying the same
>         constraint.

Indeed.

>           - gives an attribute returning a type (whereas at present
>             'BASE must be followed by another attribute, i.e., it
>             modifies the following attribute rather than existing in
>             its own right);

Interesting that this rule was removed in Ada 95 (but we added a restriction on
'Base of composites).

>           - requires radical syntax changes for renaming of subprograms
>             with parameters or results, or an obscure restriction to
>             achieve the same effect.

I've no idea what that means -- I don't see any syntactic issues.

> (3)     Demanding "equivalent constraints" requires new equivalence
>         rules, including means for defining "sufficiently equal"
>         floating point values resulting from different expressions.

Interesting again -- we now have the concept of "static matching" on subtypes.
And it nicely sidesteps the floating point issue.  ;-)  Now that we have this
concept, the obvious rule is to require static matching, except that would be
incompatible.  Although as Tuck pointed out, it could be a Restriction.
It could also be a compiler warning.

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

From: Robert A. Duff
Sent: Tuesday, November 27, 2007  1:42 PM

> One of my colleaugues in the BSI has raised a question about renaming. He
> needs to refute someone who says that Ada is stupid.

Maybe "stupid" is overstating the case, but this ignoring of subtypes on
renamings is clearly a language design flaw, no matter what the original
reasoning was.  A relatively minor flaw.

Perhaps your colleague should admit that Ada is imperfect.  ;-)

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

From: John Goodenough
Sent: Tuesday, November 27, 2007  1:57 PM

> If you have machine-readable copies of these historical documents, I think it
> would be a good service to the community if you could get Randy to put them
> up on the web site.

My files are, unfortunately, just in hard copy at this point.

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


Questions? Ask the ACAA Technical Agent