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=-0.5 required=3.0 tests=BAYES_05 autolearn=ham
	autolearn_force=no version=3.4.5-pre1
Date: 10 Sep 93 15:07:43 GMT
From: cis.ohio-state.edu!news.sei.cmu.edu!magnesium.club.cc.cmu.edu!honeydew.sr
v.cs.cmu.edu!das-news.harvard.edu!noc.near.net!inmet!spock!stt@ucbvax.Berkeley.
EDU  (Tucker Taft)
Subject: Re: Don't we already have a 'Valid? (was Re: Unchecked_Conversion...)
Message-ID: <CD58ov.Kw3@inmet.camb.inmet.com>
List-Id: <comp.lang.ada>

In article <26q196INNl1t@umbc4.umbc.edu> berman@umbc.edu (Mike Berman) writes:

> . . .
>The real question is why does the "type_mark" form of the "in" operator
>exist? Most people use "in" solely for checking ranges within a scalar
>type, but it is defined to operate on _any_ type. Since it can't be used
>to check the results of unchecked_conversions, then why is it defined
>for nonscalar types?
>
>And, as the subject line suggests, why not use the already-defined
>syntax for the "in" operator _instead_ of adding the 'Valid attribute?

The purpose of the "in" operation with a (sub)type_mark is to check 
whether a value of a given type satisfies the constraints associated
with a given subtype.  For a composite type, that comes
down to checking the discriminants or array bounds of the value.
For a scalar type, it is a range check.  For an access type,
it is a discriminant or array bound check on the object designated
by the access value.  Of course if the composite type doesn't
have discriminants or array bounds, then the membership test
will always return True.

The basic problem with using the membership test
to check validity is that Ada 83 allows compilers to assume that
all variables are properly initialized with a value that belongs
to their subtype, since the execution is erroneous anyway if that
assumption is not true.   

In Ada 9X, these situations are considered bounded 
errors instead of erroneous, meaning that the compiler can't
allow the use of an uninitialized variable to result in a wild jump 
or wild store into memory, but the compiler is allowed to raise Program_Error
or give the "wrong" answer.  For example, Ada 9X would still allow
a membership test to return True in such a case, since
that doesn't necessarily lead to unbounded errors.

The purpose of the 'Valid attribute is to check the contents
of an object without "officially" reading its value.  As soon
as you read the value of an uninitialized (or improperly
initialized) variable, you are in an bounded error condition,
and a "friendly" compiler should raise Program_Error before
you even get to invoking the "in" operation (aka membership test).

On the other hand, using the 'Valid attribute on an uninitialied
object is not an error of any sort, and is guaranteed to either
return True or False (it will never raise Program_Error), based
on the actual contents of the object, rather than on what the
optimizer might have assumed about the contents of the object
based on some declaration.

By the way, we considered trying to use the membership
test for this purpose, but the fact that the left operand
of a membership test is a *value* means that it is a bit
"late" to be asking whether it is a "valid" value.  We want
encourage compilers to catch invalid values as soon as possible.

>Mike Berman
>University of Maryland, Baltimore County     Fastrak Training, Inc.

S. Tucker Taft   stt@inmet.com
Ada 9X Mapping/Revision Team
Intermetrics, Inc.
Cambridge, MA  02138