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,c9f437cff8842e X-Google-Attributes: gid103376,public From: Keith Thompson Subject: Re: Enumeration representation Date: 1999/09/13 Message-ID: #1/1 X-Deja-AN: 524369210 Sender: kst@king.cts.com References: <37D8E3BC.175DB72C@newtech.it> <7rcceh$anh$1@nnrp1.deja.com> <37DB15A2.2CF36CC8@home.com> <7rhl1r$nc6$1@nnrp1.deja.com> X-Trace: nusku.cts.com 937208977 18331 198.68.168.21 (13 Sep 1999 07:49:37 GMT) Organization: CTS Network Services Newsgroups: comp.lang.ada X-Complaints-To: newsmaster@cts.com Date: 1999-09-13T00:00:00+00:00 List-Id: For those tuning in late, the original question was whether it's possible to use Unchecked_Conversion to convert an integer value to a sparse enumeration type, and then apply the 'Valid attribute to the result to determine whether it's a valid value of the type. (Actually, it's a bit more general than that.) A strict reading of the RM, specifically 13.9.1(12), says the call to Unchecked_Conversion is erroneous if the value is not valid for the enumeration type. AI95-00167/01 says that it's not erroneous, and that the result may be invalid, but not abnormal. Robert Dewar writes: > In article <37DB15A2.2CF36CC8@home.com>, > Bryce Bardin wrote: > > AI95-00167/01, which is proposed to be a binding interpretation, > > but is not yet written up in final form nor approved by either the > > ARG or WG9, as far as I know. > > > Right, but this part of the semantics is completely obvious > and completely non-controversial, so the intended intepretation > can be taken to be what is written up in this AI. Remember that > an AI is only an Ada intepretation, so it does not change the > RM. Thus it is less important than you think that something > should be formally stamped *unless* it is controversial. > > Everyone knows that Valid should operate in the obvious useful > way, the issue is exactly how to word this in a formal manner! I agree with the interpretation in the AI (after all, it was my suggestion), but apparently it wasn't entirely obvious to everyone on the ARG. At the April 1997 meeting in Henley, the ARG decided that "the only option is to confirm the language on this issue and to expect the user to do the sensible thing to avoid this problem". They suggested either using a case statement on an integer or wrapping the result in a record. At the November 1997 meeting in St. Louis, they reversed their decision. (See .) Also, a "binding interpretation" isn't really just an interpretation; it can contradict and override the wording of the RM itself, as this one does. An even clearer example of this is the Ada 83 AI that allowed implementations to raise Constraint_Error instead of Numeric_Error; another is the one that allowed type Character to have 256 values rather than 128. Now, in this particular case, all implementations probably already conform to the AI; it merely defines behavior in a case that was previously considered erroneous. The difference is that users can depend on the obvious behavior. (I once heard about a binding interpretation issued for the Algol 68 standard (or was it Algol 60?), that said something like, "In the language standard document, section FOO, paragraph BAR, the word 'is' shall be interpreted to mean 'is not'.") -- Keith Thompson (The_Other_Keith) kst@cts.com San Diego Supercomputer Center <*> "Oh my gosh! You are SO ahead of your time!" -- anon.