Ada compiler bug?!

[dana@gatech.CSNET (Dana Eckart)]

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!dana