comp.lang.ada
 help / color / mirror / Atom feed
From: Keith Thompson <kst@cts.com>
Subject: Re: Enumeration representation
Date: 1999/09/13
Date: 1999-09-13T00:00:00+00:00	[thread overview]
Message-ID: <yecemg38d4f.fsf@king.cts.com> (raw)
In-Reply-To: 7rhl1r$nc6$1@nnrp1.deja.com

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 <robert_dewar@my-deja.com> writes:
> In article <37DB15A2.2CF36CC8@home.com>,
>   Bryce Bardin <bbardin@home.com> 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
<http://www.adaic.org/standards/95com/ada-issues/work/ai-00167.doc>.)

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  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
"Oh my gosh!  You are SO ahead of your time!" -- anon.




  reply	other threads:[~1999-09-13  0:00 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-09-10  0:00 Enumeration representation Alex
1999-09-10  0:00 ` David C. Hoos, Sr.
1999-09-10  0:00   ` Robert Dewar
1999-09-10  0:00 ` Matthew Heaney
1999-09-10  0:00   ` Robert Dewar
1999-09-10  0:00 ` Keith Thompson
1999-09-11  0:00   ` Robert Dewar
1999-09-11  0:00     ` Keith Thompson
1999-09-12  0:00       ` Bryce Bardin
1999-09-13  0:00         ` Robert Dewar
1999-09-13  0:00           ` Keith Thompson [this message]
1999-09-13  0:00       ` Robert Dewar
1999-09-12  0:00         ` Keith Thompson
1999-09-13  0:00           ` Robert Dewar
1999-09-13  0:00             ` Keith Thompson
1999-09-14  0:00               ` Robert Dewar
1999-09-13  0:00             ` Ted Dennison
1999-09-13  0:00         ` Robert A Duff
1999-09-13  0:00           ` Robert Dewar
1999-09-10  0:00 ` Ted Dennison
1999-09-10  0:00   ` Robert Dewar
1999-09-13  0:00     ` Ted Dennison
1999-09-13  0:00 ` Alex
  -- strict thread matches above, loose matches on Subject: below --
2004-01-01 20:44 Luke A. Guest
2004-01-01 21:45 ` Stephen Leake
2004-01-01 22:01   ` Luke A. Guest
2004-01-02  1:17     ` tmoran
2004-01-02  1:29     ` Stephen Leake
2004-01-02  3:10       ` Luke A. Guest
2004-01-02  2:46 ` Robert A Duff
2004-01-02  3:12   ` Luke A. Guest
2004-01-02 13:58   ` Marin David Condic
2004-01-02 21:39     ` Pat Rogers
2004-01-03 13:42       ` Marin David Condic
2004-01-03  1:53     ` Robert A Duff
2004-01-02 20:52   ` Randy Brukardt
2004-01-02 21:05     ` Luke A. Guest
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox