From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.5-pre1 Date: 16 Jul 93 22:26:40 GMT From: dog.ee.lbl.gov!overload.lbl.gov!agate!howland.reston.ans.net!noc.near.net !inmet!spock!stt@ucbvax.Berkeley.EDU (Tucker Taft) Subject: Re: Forcing default representations Message-ID: List-Id: In article <9307131922.AA04017@eight-ball.boeing.com> crispen@eight-ball.boeing.com (crispen) writes: >OK, just what the hell does LRM 13.1(6) mean, anyway? > >"certain occurrences of its name imply that the representation of the >type must have been determined." > >Even the Annotated LRM is obscure on this point. "certain occurrences" >indeed! The "certain occurrences" are called "forcing occurrences" in Ada 83 parlance ("freezing points" in Ada 9X). These are points at which a representation is chosen by default if you haven't specified it explicitly. After a forcing occurrence of the name of an entity, it is *illegal* to give a representation clause for the entity. The most common forcing occurrence for a type is a declaration of an object of the type (or an object of a composite type that has a subcomponent of the type). Declaring subprograms or composite types are *not* forcing occurrences for their parameter or component types. For discrete types, using the type as an index type for an array type is a forcing occurrence. There are other more obscure forcing occurrences, but if you are lucky, you didn't run into one of those... >My goal here is to put as many of my rep specs as I possibly can in >a private part. . . . Although this seems like a noble goal, there are Ada gurus who would recommend against this strategy, since it means you have to worry about this silly "forcing occurrence" stuff. Particularly for scalar types, I would also recommend that the rep clauses follow the type declaration immediately. > . . . >The problem, though, is with this declaration: > > type Flight_Controls_Discrete_Outputs is ( > Flt_Control_System_Caution_Light, > LE_Flaps_Caution_Light [...] > > Flight_Controls_Discrete_Outputs_Size : constant := 8; > for Flight_Controls_Discrete_Outputs'size use > Flight_Controls_Discrete_Outputs_Size; > >If I define this above the private part, and before the declaration: > > type Flight_Controls_Discrete_Data_Pair is > record > Name : Flight_Controls_Discrete_Outputs; > State : Base_Types.Discrete_State; > end record; > >no problem. If I don't, and if I define it in the private part, then >I get the following error: > >/usr/people/crispen/generic/types/fc_if_types.a, line 372, char 5:error: RM 13 .1(6): type representation already determined by a forcing occurrence > >on all 3 of my Ada compilers (they're VADS, but of different vintages). Using a type in the definition of another type is *not* a forcing occurrence. Either all your compilers have the same bug, or you have a declaration of an object of type Flight_Controls_Discrete_Data_Pair (or some other forcing occurence for that type, or something that includes that type as a component). The real problem may be that the error message is not identifying the forcing occurrence that "forced" the representation of your type. It rather points at the rep-clause, but your problem is that you don't know where is the forcing occurrence. Remember that forcing occurrences are "recursive," in that they force the type, and all of the subcomponent types as well. > . . . >| Bob Crispen | Who will babysit the babysitters? | >| crispen@foxy.boeing.com +--------------------------------------+ Hope that helps... S. Tucker Taft Intermetrics, Inc. Cambridge, MA 02138