Version 1.1 of acs/ac-00025.txt

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

!standard 3.04(23)          02-01-23 AC95-00025/01
!standard 7.03.01(06)
!class confirmation 02-01-15
!status received no action 02-01-15
!subject Visibility of derived operations from private part of parent
!summary
!appendix

!topic visibility of derived operations from private part of parent
!reference RM95-3.4(23), RM95-7.3.1(6)
!from Dan Eilers 02-01-15
!keywords derived, private, child
!discussion

package parent is
   type t is null record;
private
   function foo return t;
end parent;

package parent.child is
   type new_t is new t;
private
   x: new_t := foo;  -- legal?
end parent.child;


RM95-3.4(23) says "If a primitive subprogram of the parent type is
visible at the place of the derived_type_definition, then the
corresponding inherited subprogram is implicitly declared immediately
after the derived_type_definition.  Otherwise, the inherited subprogram
is implicitly declared later or not at all, as explained in 7.3.1.

RM95-7.3.1(6) says: "For a derived_type_definition, each inherited
primitive subprogram is implicitly declared at the earliest place, if
any, within the immediate scope of the type_declaration, but after the
type_declaration, where the corresponding declaration from the parent
is visible."

I would conclude from this that "foo" is an inherited primitive function
of the parent type, that is not made visible immediately after the
declaration of new_t, but is made visible in the private part of
parent.child, making the assignment legal.

Is this correct?  (GNAT rejects this program.)

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

From: Tucker Taft
Sent: Tuesday, January 15, 2002  9:00 PM

The program is legal.  I'm not sure this deserves
a message on ada-comment, however.  Wouldn't this
more properly go into the GNAT bug report list?

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

From: Dan Eilers
Sent: Wednesday, January 16, 2002 11:09 AM

In my judgment, this is not so much a compiler bug as
a gap in ACATS, since it appears to involve a visibility
rule that is completely untested, rather than a rule that
is infeasible to test due to some esoteric combination
of factors required to trigger the bug.

As such, I consider it of broader interest, either for
incorporation into some future version of ACATS, or in
the interim, for vendors who might want to add it to their
supplemental test suites.

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

From: Bob Duff
Sent: Wednesday, January 16, 2002  2:10 PM

I agree.  I'll bet Randy would add a test if you wrote one.

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

From: Robert Dewar
Sent: Friday, January 18, 2002  12:25 PM

(well I still have not managed to unsubscribe from this list, despite following
Randy's instructions exactly, but this sure encourages me to do so even more)

The idea that the ACATS tests can be 100% complete is naive. There are
hundreds, even thousands of bugs we know of in past versions of GNAT and
other Ada compilers that are not tested by ACATS. The mere fact that a bug
has been found, and could have been caught by the ACATS test is NOT a reason
to add another test, otherwise you will add a huge pile of junk tests.

Yes, occasionally there is a clear gap. But that's NOT a language issue,
and does not belong on the ada comment list, unless, as seems a popular
idea (and is why I am discontinuing following the list), you think that
the ada comment list should be a general let's-chat-about-Ada list.

I think it very important to have an official email address that records
official comments on the standard, to be handled in an official manner.
We definitely do not want to encourage it to be a general place to submit
compiler bug reports, with the understaqnding that every such comment has
to be formally replied to. That would  be shear nonsense.

Robert Dewar

Now, I wish someone would tell me (by private email) how to get off this list!

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

From: Randy Brukardt
Sent: Friday, January 18, 2002  3:46 PM

> I think it very important to have an official email address that records
> official comments on the standard, to be handled in an official manner.
> We definitely do not want to encourage it to be a general place to submit
> compiler bug reports, with the understaqnding that every such comment has
> to be formally replied to. That would  be shear nonsense.

Robert is right that this is not the place to submit compiler bug reports. A
question of the form "the standard says X, but compiler Y does Z" does not
belong here -- take that up with the vendor of the compiler. If many
compilers don't follow the standard, that might be appropriate to bring up
here -- if there is some real benefit to their behavior.

In general, this list is for questions about problems with the standard
(unclear areas, nonsense rules, and the like), proposals to amend the
standard, and technical discussion about the those postings. Our policy
doesn't allow me to police this beyond occasional appeals and the deletion
of wildly off-topic posts (mostly spam). So we rely on you, the posters to
keep dubious questions off the list.

Unlike Robert, I don't think we're anywhere near the point where the traffic
on this list is a problem (we average less than two messages per day). But
it would be bad policy to wait until postings got out of hand to remind
everyone of the purpose of this list.

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

From: Dan Eilers
Sent: Friday, January 18, 2002  5:45 PM

Randy wrote:
> ... A question of the form "the standard says X, but compiler Y does Z" does
> not belong here ...

I think it should be pointed out that no such restriction can be found
in the solicitations for email to ada-comment found in RM95 and in the
ARG procedures.  RM95 simply says:  "Informal comments on this International
Standard may be sent via e-mail to ada-comment...".  The ARG procedures
have similar unrestrictive wording.

In fact, one of the official duties of the ARG is "to promote uniform
implementation of the Ada standard".  This seems completely at odds with
an effort to discourage reports of language rules that are completely
untested by ACATS and non-uniformly implemented.

Robert frets that the ARG might be forced to officially respond to such
comments, but neither RM95 or the ARG procedures make any promise of a
response to email sent to ada-comment.  In fact, the ARG procedures
provide that the ARG will not deal with comments per se, only official
commentaries created at the discretion of the Editor.

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

From: Randy Brukardt
Sent: Friday, January 18, 2002  6:10 PM

> RM95 simply says:  "Informal comments on this International
> Standard may be sent via e-mail to ada-comment...".

Dan, it says "on this International Standard". In no way can a bug report
about the GNAT compiler be considered a comment on the language standard!

> In fact, one of the official duties of the ARG is "to promote uniform
> implementation of the Ada standard".  This seems completely at odds with
> an effort to discourage reports of language rules that are completely
> untested by ACATS and non-uniformly implemented.

There is a place for suggesting enhancements to the test suite -- the ACAA
public mailing list (acaa@ada-auth.org). It isn't necessary to clutter this
list with such requests.

The test suite fails to test 35% of the testable rules of the Ada 95
standard. This shouldn't be a major surprise to anyone; its obvious simply
by looking at the Coverage.Txt document that comes with the test suite. So
of course there are major holes in the suite. Pointing out which ones need
to be plugged is valuable -- but not here: use the list created for that
purpose.

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

From: Robert Dewar
Sent: Saturday, January 19, 2002  6:53 AM

<<Unlike Robert, I don't think we're anywhere near the point where the traffic
on this list is a problem (we average less than two messages per day). But
it would be bad policy to wait until postings got out of hand to remind
everyone of the purpose of this list.>>

Randy misses my point completely!

This has nothing to do with the volume of traffic on the list (I get well
over a thousand emails a day and this is a drop in the bucket). The problem
for me is that this is an official list for recording official comments
on problems with the standard. These comments should be carefiuly filed with
unique identifiers, and then the ARG should give a formal response. It is
not, or should not be, a chit chat list for discussion of language issues.
I have no objection to such a chit chat list in principle, indeed CLA
seems to serve that function fine. I don't care to participate in a mailing
list that has this emphasis (since I think a newsgroup which is easier to
read in a threaded manner and easier to ignore junk is better), but that
does not mean that I object to others participating in such a list.

The point is to me that it is essential for the Ada standardization process
that there be a formal way of submitting comments to the standard. I find
it a serious loss if this is not the case, and if this list is allowed to
become a chat list, it cannot satisfy that requirement.

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

Questions? Ask the ACAA Technical Agent