dana@gatech.CSNET (Dana Eckart) (06/24/86)
Attention!
There is a possible "bug" which may be in a great many Ada compilers.
An error may be flagged (at compiler time) when the instantiation of
a generic package which tries to match a formal private parameter to
an actual parameter that is a discriminated record is attempted. The
reason that I feel this IS supposed to be supported by the language is
the following from the Ada LRM (12.3.2 paragraphs 1 - 4):
A generic formal private type is matched by any type or
subtype (the actual subtype) that satisfies the following
conditions:
* If the formal type is not limited, the actual type must
not be a limited type. (If, on the other hand, the
formal type is limited, no such condition is imposed on
the corresponding actual type, which can be limited or
not limited.)
* If the formal type has a discriminant part, the actual
type must be a type with the same number of discriminants;
the type of a discriminant that appears at a given position
in the discriminant part of the actual type must be the
same as the position in the discriminant part of the formal
type; and the actual subtype must be unconstrained. (If,
on the other hand, the formal type has no discriminants, the
actual type is allowed to have discriminants.)
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Last sentence seems to indicate that the instantiation should be allowed.
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Furthermore, consider any occurrence of the name of the formal
type at a place where this name is used as an unconstrained subtype
indication. The actual subtype must not be an unconstrained array
type or an unconstrained type with discriminants, if any of these
occurrences is at a place where either a constraint or default
discriminants would be required for an array type or for a type
with discriminants (see 3.6.1 and 3.7.2).
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Last sentence seems to indicate that the instantiation should be allowed.
However, notice that this sentence is an implication with the conditional
part last. I have asked someone else's opinion of this and we feel that
implementors have probably over generalized this last statement, thus
causing the "bug" (or is it a feature? :-).
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
The same restriction
applies to occurrences of the name of a subtype of the formal type,
and to occurrences of the name of any type of subtype derived,
directly or indirectly, from the formal type.
The following is an easy example to test whether or not your compiler suffers
from this problem.
dotted line
-------------------------------------------------------------------------
package PERSON is
type GENDER is (MALE, FEMALE);
type PERSON (SEX : GENDER := MALE) is record
null;
end record;
end PERSON;
generic
type ELEMENT_TYPE is private;
package LIST is
type LIST is private;
private
type LIST_NODE;
type LIST is access LIST_NODE;
end LIST;
package body LIST is
type LIST_NODE is record
ITEM : ELEMENT_TYPE;
NEXT : LIST;
end record;
end LIST;
with PERSON, LIST;
use PERSON;
procedure TEST is
--
-- The problem should manifest itself by flagging an error
-- for the following statement.
--
package COMMUNITY is new LIST (PERSON.PERSON);
CITY : COMMUNITY.LIST;
begin
null;
end TEST;
pragma MAIN;
dotted line
-------------------------------------------------------------------------
I ask everyone to please try this example on their own compilers and to
send me mail concerning the results. I suppose the only information I
really need is:
(1) The compiler that was used (don't forget the version)
(2) Did it compile without complaint? (yes/no)
* If it did complain and it doesn't seem related to the issues
pointed out here, please include the errors flagged.
(3) If it compiled, did it generate any run-time errors? (yes/no)
* If so, which ones, and where were they raised.
(4) If you know of a test in the validation suite that is similar (or
that tests for the same type of thing) please let me know about it
and if possible send me the code (assuming it is small) and the
first version of the suite which used it.
(5) Finally, if you happen to think that I have misinterpreted the LRM
please tell me how I have misinterpreted it and why you think so.
When I feel that I have gotten most, if not all, of the results I will try
to summarize and report back to the net (hopefully within 2 weeks time).
I wish to thank everyone in advance for their help and cooperation.
If my understanding of the matter is correct, I think that this is a
very serious problem. Not only is it an excellent illustration of the
difficulty of adequate testing (e.g. the validation suite), but it also
points out the problem of reading and interpreting English statements
describing the semantics of a programming language.
j dana eckart
CSNet: dana @ GATech ARPA: dana%GATech.CSNet @ CSNet-Relay.ARPA
uucp: ...!{akgua,allegra,hplabs,ihnp4,linus,seismo,ulysses}!gatech!dana
--
j dana eckart
CSNet: dana @ GATech ARPA: dana%GATech.CSNet @ CSNet-Relay.ARPA
uucp: ...!{akgua,allegra,hplabs,ihnp4,linus,seismo,ulysses}!gatech!danaGOODENOUGH@USC-ISI.ARPA (John B. Goodenough) (06/25/86)
First, the ACVC team wants to hear about bugs in validated compilers. Your report is an excellent example. Example code that illustrates a purported problem is important. In addition, it is useful to know which ACVC version was used to validate the compiler you are using. Other people are encouraged to submit similar reports to ACVC at USC-ISIF.ARPA (the ISIF address is soon to change to ADA20.ISI.EDU). Now that the advertising is done with ... The problem you report falls in an interesting gray area -- the RM appears to say the instantiation is illegal, but the tests, as of version 1.8, require that the instantiation be accepted. First let's look at what the RM says. According to paragraph 12.3.2(4), the instantiation is illegal because of the LIST_NODE declaration: type LIST_NODE is record ITEM : ELEMENT_TYPE; NEXT : LIST; end record; The actual subtype in the instantiation is a type with discriminants, and the occurrence of ELEMENT_TYPE is indeed at a place where either a constraint or default discriminants would be required for an array type or for a type with discriminants. (To see this more clearly, suppose the actual parameter were STRING; the declaration of LIST_NODE would then clearly be illegal.) The wording of the RM makes no distinction for actual subtypes whose discriminants have defaults. So according to paragraph 12.3.2(4), the instantiation is indeed illegal. To put it mildly, you are probably dismayed to find your instantiation is indeed illegal. There was a similar reaction in January 1984 (actually even earlier) when Douglas Arndt and others at Textron's Bell Technical Operations discovered this problem. They submitted a very clear analysis of the negative consequences of this RM rule. In February, 1985, the Ada Language Maintenance Committee considered the issue and recommended a binding interpretation making such instantiations legal when the actual subtype is an unconstrained type with discriminants that have defaults. Under this recommended interpretation, your example is legal and must be accepted by validated compilers. The LMC recommendation was approved by WG9 (the group responsible for the soon-to-be-approved International Standard) in May 1985 and also by an informal group that was later to become the Ada Board. Based on these approvals, the validation tests were changed to enforce the approved "interpretation". Tests in the existing validation suite that were not consistent with this interpretation were withdrawn. The tests that enforce the approved interpretation were included in version 1.8 of the validation suite, which became effective June 1, 1986 (i.e., just this month). Implementations validated under versions 1.6 or 1.7 might also conform to this interpretation, but there were no tests requiring them to do so. The Language Maintenance Committee's analysis that addresses this issue is AI-00037, which can be found in file AI-00037-BI.WP in account <ADA-COMMENT> at USC-ISIF.ARPA. This commentary has been approved provisionally, meaning some wording changes were requested to improve the analysis and phrasing of the recommendation, but the intent of the commentary was approved. (If you are interested in seeing the commentary and don't have FTP access to ISIF, send a message to ADA-COMMENT at USC-ISIF.ARPA requesting that a copy be sent to you by electronic mail. You can also be notified automatically when commentaries on the language are updated, and copies of the commentaries can be sent to you electronically as well. You can request these services by sending a message to ADA-COMMENT.) John B. Goodenough Chair, Ada Language Maintenance Committee/Panel -------