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=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,ca0cb7cf9847d846 X-Google-Attributes: gid103376,public From: stt@houdini.camb.inmet.com (Tucker Taft) Subject: Re: Membership test problem Date: 1996/10/07 Message-ID: #1/1 X-Deja-AN: 187334121 sender: news@inmet.camb.inmet.com (USENET news) x-nntp-posting-host: houdini.camb.inmet.com references: <1996Oct6.040427.23644@ocsystems.com> organization: Intermetrics, Inc. newsgroups: comp.lang.ada Date: 1996-10-07T00:00:00+00:00 List-Id: Joel VanLaven (jvl@ocsystems.com) wrote: : ... I already know a : number of rather easy solutions to my "problem" such as: : replace X in Tag1 with Tag1'class(X) in Tag1 or use an explicit tag check ala : X'tag = Tag1'tag. Thank you for the suggestions, but I fear I did not : express myself properly. I was confused by the rule because it seems to : interfere with the meaning of the test rather than help enforce it. The : rule not to do a tag check seems to me to simply be an optimization. The conceptual model is that an expression of a "specific" type does not have a "Tag" attribute (RM95 3.9(17-18); AARM 3.9(18.a)); a conversion to a class-wide type is required to make the Tag visible. This was carried over to membership testing, where an expression of a specific type is only tested against the constraints of the tested type; there is no consideration of the tag. Optimization concerns have nothing to do with it. Similarly, you can't convert an expression of a specific type directly to some extension of the type; you must first convert to its class-wide type to open up the possibility that it might actually "underneath" be an object of the extended type. Finally, when you call a dispatching operation, if the controlling operand(s) are of a specific type, then the underlying tag of those operands is irrelevant -- the call is statically bound based on the specific (compile-time) type of the operand(s). Hence, as long as you have an expression of a specific type, you are basically following Ada 83 rules, and tags are irrelevant. The only way you can reveal the underlying tag is to convert (explicitly or implicitly) to the class-wide type. This is a pretty important principle in the Ada 95 model. One side-effect of this model is that if there are no conversions to class-wide types anywhere, then tags need not be stored anywhere, even if you have type extensions. Again, this is not an optimization, rather part of the basic conceptual model distinguishing specific types from class-wide types. : ... This is : a case where an error might occur and be hidden from the programmer. It : caught me, I can't explain why it is the way it is, and I would either like : for it to be considered as a defect in the language, or for an explanation : of why I am wrong. What I want to do can be done other ways. According to : the LRM, what I did has no meaning whatsoever, X in tag is statically : evaluated to false. I don't understand that. I have lost your original example, so I don't know whether X was of specific type "tag". If it was, then "X in tag" is statically true (presuming tag doesn't have constrained discriminants). If X is not of specific type "tag", then the membership test is illegal, since the type of X neither covers nor is covered by "tag" (4.5.2(3)). Perhaps GNAT has a bug here, if it is allowing "X in tag" when X is of a specific type that is not the specific type "tag". : ... So, I think making it either illegal or giving a : warning would be in order. Again, I missed your original note, but it sounds like it might already be illegal, and GNAT just has a bug. : ... Note that if you "try this at home" on GNAT : 3.04a at least, it will incorrectly behave as I suggest :) Could you repost the original example if you reply to this? : Again, sorry for the confusion. : -- : -- Joel VanLaven -Tucker Taft stt@inmet.com http://www.inmet.com/~stt/ Intermetrics, Inc. Cambridge, MA USA