From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,856114749978634c X-Google-Attributes: gid103376,public From: ncohen@watson.ibm.com (Norman H. Cohen) Subject: Re: Protected Types and Address Clauses Date: 1996/02/20 Message-ID: <4gcppr$10f5@watnews1.watson.ibm.com> X-Deja-AN: 140298995 distribution: world references: <4fqe6h$t0e@theopolis.orl.mmc.com> organization: IBM T.J. Watson Research Center reply-to: ncohen@watson.ibm.com newsgroups: comp.lang.ada Date: 1996-02-20T00:00:00+00:00 List-Id: In article <4fqe6h$t0e@theopolis.orl.mmc.com> rgilbert@unconfigured.xvnews.domain (Bob Gilbert) wrote: BG> protected Discretes is BG> procedure Write(Settings : in SETTING_LIST); BG> private BG> HW_Control : DISCRETE_HW_CONTROL; BG> for HW_Control use at 16#4000_0001#; BG> end Discretes; BG> BG> Our compiler complains about the address clause, claiming that BG> HW_Control is not visible. Looking at the language specification BG> I do see that address clauses are not included here. What is BG> the rationale for this omission? In article , eachus@spectre.mitre.org (Robert I. Eachus) responded: RIE> Seems to work the way I read it. The private part is a list of RIE> protected_element_declarations. A protected_element_declaration can RIE> be a protected_operation_declaration. A RIE> protected_operation_declaration can be a representation_clause. A RIE> representation_clause can be an attribute definition_clause, which can RIE> be FOR local_name'attribute USE expression. This just establishes that the syntax allows representation clauses in the private part of a protected definition. I agree with Robert's conclusion that the RM appears (despite the intent of its authors) to permit this address clause, but as the result of a more intricate exegesis. By J.7(2), for HW_Control use at 16#4000_0001#; is equivalent to for HW_Control'Address use 16#4000_0001#; 13.3(10) says that this attribute is defined if HW_Control denotes an object, program unit, or label. In fact, HW_Control does denote an object, because 3.3(12) states that a component of an object is an object. 9.4(12) states, "The elaboration of a single_protected_declaration also creates an object of an (anonymous) protected type," so Discretes is an object, and we can infer from the use of the syntactic term component_declaration, as well as from the statement in 9.4(17) that a protected object includes component values, that HW_Control is a component of that object. (3.8(9) states that a component_declaration in a record-type declaration declares a component of the record type; 9.4 ought to have had an analogous explicit statement that a component_declaration in a protected declaration declares a component of a protected type. However, despite the absence of an explicit statement, nobody will seriously question that this is the intent.) Tucker Taft wrote in article : STT> Because you are declaring a "single protected object" rather than STT> a protected *type* it would make sense to allow an address STT> clause here. However, single protected objects are considered STT> just a short-hand for declaring a protected type, and then STT> one instance thereof. Because of that equivalence, address STT> clauses aren't allowed for components of a protected type STT> or object. This would be equivalent to specifying the address STT> of a component of a record type, which of course doesn't make STT> sense presuming you will have multiple instances. However, the language of the RM does not reflect Tuck's intent. 9.4(12) states nothing about a single protected declaration being EQUIVALENT to a protected type declaration for an anonymous type FOLLOWED BY a declaration for an object of that type. It states that elaboration of the single protected declaration creates an anonymous type and "also creates" an object of that type, apparently simultaneously. RIE> I think you are looking at a (not very surprising) compiler bug. Or an RM bug. The ARG will have to decide whether or not this should be allowed. On the other hand, the content of the error message that Bob Gilbert reported, that HW_Control is not visible, is definitely wrong. The address clause occurs in the same declarative region as the declaration of HW_Control--the declarative region associated with the protected declaration--so it is directly visible there. RIE> As a workaround you might try defining HW_Control inside Write and any RIE> other operations you might add later. Or, as Tuck suggested, in the body of a package enclosing the protected declaration. -- Norman H. Cohen ncohen@watson.ibm.com