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=-1.9 required=3.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.5-pre1
Date: 17 Sep 93 03:50:30 GMT
From: cis.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!howland.
reston.ans.net!vixen.cso.uiuc.edu!sdd.hp.com!portal!cup.portal.com!R_Tim_Coslet
@ucbvax.Berkeley.EDU
Subject: Re: Don't we already have a 'Valid? (was Re: Unchecked_Conversi
Message-ID: <90771@cup.portal.com>
List-Id: <comp.lang.ada>

In article: <CDGJpK.798@inmet.camb.inmet.com>
	stt@spock.camb.inmet.com (Tucker Taft) wrote:
>In article <CDAooM.nEt@yktnews.watson.ibm.com> ncohen@watson.ibm.com writes:
>>Some clarifications: 
>
>>3. Like Robert Eachus (if I understand his post correctly), I believe
>>   that the best solution would have been an attribute like
>>
>>      target_subtype'Would_Be_Valid(source_object)
>>
>>   indicating without performing the unchecked conversion of
>>   source_object to target_subtype whether the bits of source_object are
>>   a valid representation of a value of target_subtype.  This provides a
>>   convenient way for the programmer to validate untrustworthy data
>>   without ever constructing invalid values.  (I'm sure there is a better
>>   name, but Would_Be_Valid conveys my intent.)
>[...]
>   2) Unchecked_Conversion takes a source *sub*type and a target subtype
>      as generic parameters.  That is critical because 
>      the particular subtypes specified can affect the actual number of
>      bits involved in the unchecked conversion.  By contrast,
>      the attribute-function approach is given a value, which does
>      not indicate unambiguously how many bits will be involved
>      in the conversion (which matters when converting between
>      bit arrays and scalars on a big-endian machine, for example).
>[...]
>An alternative to the attribute-function approach that would
>almost work would be a generic "Checked_Conversion" function, which would
>combine the conversion with a validity check.  However, since validity
>is not unambiguously defined for composite types (because of examples
>like the Stack above), Checked_Conversion would be limited to scalar
>types, which would make it pretty inconvenient.

What about a "Check_Validity" generic function that took Source and
Target generic parameters like "Unchecked_Conversion" and returned
"True" if a corresponding "Unchecked_Conversion" would have been valid?

Then the paremeter could always be a Valid value of the Source type
and be checked for validity if it had been bit wise converted to the
Target type.

                                        R. Tim Coslet

Usenet: R_Tim_Coslet@cup.portal.com
        technology, n.  domesticated natural phenomena