Representation clause

Representation clause

[Anatoly Chernyshev]

**** Post for FREE via your newsreader at post.usenet.com ****

Hello again,

Now I wander about representation clause for enumerated types.
For example,
   type ATOM is (H, C, N, O);
   for  ATOM use (H=>1, C=>6, N=>7, O=>8);

How can I access these 'internal' numbers?
ATOM'POS yields 0, 1, 2, 3 respectively and I know no other relevant
attributes.

Thanks,
Anatoly



-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 *** Usenet.com - The #1 Usenet Newsgroup Service on The Planet! ***
                      http://www.usenet.com
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Re: Representation clause

[James Rogers]

 NOTES
Unchecked_Conversion may be used to query the internal codes 
used for an enumeration type. The attributes of the type, such as Succ, 
Pred, and Pos, are unaffected by the enumeration_representation_clause. 
For example, Pos always returns the position number, not the internal 
integer code that might have been specified in a 
enumeration_representation_clause. 

Jim Rogers
Colorado Springs, Colorado USA
Anatoly Chernyshev wrote:
> Now I wander about representation clause for enumerated types.
> For example,
>    type ATOM is (H, C, N, O);
>    for  ATOM use (H=>1, C=>6, N=>7, O=>8);
> 
> How can I access these 'internal' numbers?

Ada 0x: Re: Representation clause

[Martin Dowie]

Do I spot a possible language extension here?

How about a 'Underlying_Value attribute?

James Rogers <jimmaureenrogers@worldnet.att.net> wrote in message
news:3A95E095.75B2A248@worldnet.att.net...
> NOTES
> Unchecked_Conversion may be used to query the internal codes
> used for an enumeration type. The attributes of the type, such as Succ,
> Pred, and Pos, are unaffected by the enumeration_representation_clause.
> For example, Pos always returns the position number, not the internal
> integer code that might have been specified in a
> enumeration_representation_clause.
>
> Jim Rogers
> Colorado Springs, Colorado USA
> Anatoly Chernyshev wrote:
> > Now I wander about representation clause for enumerated types.
> > For example,
> >    type ATOM is (H, C, N, O);
> >    for  ATOM use (H=>1, C=>6, N=>7, O=>8);
> >
> > How can I access these 'internal' numbers?

Re: Ada 0x: Re: Representation clause

[Lutz Donnerhacke]

* Martin Dowie wrote:
>James Rogers <jimmaureenrogers@worldnet.att.net> quote the RM:
>> Unchecked_Conversion may be used to query the internal codes
>> used for an enumeration type. The attributes of the type, such as Succ,
>> Pred, and Pos, are unaffected by the enumeration_representation_clause.
>> For example, Pos always returns the position number, not the internal
>> integer code that might have been specified in a
>> enumeration_representation_clause.

>Do I spot a possible language extension here?
>How about a 'Underlying_Value attribute?

That would only syntactic shugar, why burden this into the language?

Re: Ada 0x: Re: Representation clause

[David C. Hoos, Sr.]

To me this is no more "syntactic sugar" than, say, some of the
features of Ada.Strings.Fixed, or of Ada.Interfaces.C.

I would suggest the attribute name 'Rep.  Its inverse should be
provided as well -- perhaps by overloading the 'Value
attribute.

"Lutz Donnerhacke" <lutz@iks-jena.de> wrote in message
news:slrn99c9ij.ju.lutz@taranis.iks-jena.de...
> * Martin Dowie wrote:
> >James Rogers <jimmaureenrogers@worldnet.att.net> quote the RM:
> >> Unchecked_Conversion may be used to query the internal codes
> >> used for an enumeration type. The attributes of the type, such as Succ,
> >> Pred, and Pos, are unaffected by the enumeration_representation_clause.
> >> For example, Pos always returns the position number, not the internal
> >> integer code that might have been specified in a
> >> enumeration_representation_clause.
>
> >Do I spot a possible language extension here?
> >How about a 'Underlying_Value attribute?
>
> That would only syntactic shugar, why burden this into the language?

Re: Representation clause

[Marc A. Criley]

Anatoly Chernyshev wrote:
> 
> Now I wander about representation clause for enumerated types.
> For example,
>    type ATOM is (H, C, N, O);
>    for  ATOM use (H=>1, C=>6, N=>7, O=>8);
> 
> How can I access these 'internal' numbers?
> ATOM'POS yields 0, 1, 2, 3 respectively and I know no other relevant
> attributes.
> 

If you're using GNAT and don't mind using a compiler-specific attribute,
GNAT supplies one called Enum_Rep that will extract values specified by
a representation clause.

with Text_IO; use Text_IO;

procedure Cer is

   type ATOM is (H, C, N, O);
   for  ATOM use (H=>1, C=>6, N=>7, O=>8);

begin
   Put_Line(Integer'Image(Atom'Enum_Rep(N)));
end Cer;

Ouputs: 7

Marc A. Criley
Senior Staff Engineer
Quadrus Corporation
www.quadruscorp.com

Re: Ada 0x: Re: Representation clause

[Florian Weimer]

"David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> writes:

> I would suggest the attribute name 'Rep.  Its inverse should be
> provided as well -- perhaps by overloading the 'Value
> attribute.

In this case, you should use both 'Image and 'Value, otherwise it's
quite confusing.

Re: Representation clause

[Des Walker]

Anatoly Chernyshev wrote:
> 
> **** Post for FREE via your newsreader at post.usenet.com ****
> 
> Hello again,
> 
> Now I wander about representation clause for enumerated types.
> For example,
>    type ATOM is (H, C, N, O);
>    for  ATOM use (H=>1, C=>6, N=>7, O=>8);
> 
> How can I access these 'internal' numbers?
> ATOM'POS yields 0, 1, 2, 3 respectively and I know no other relevant
> attributes.
> 
> Thanks,
> Anatoly
> 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>  *** Usenet.com - The #1 Usenet Newsgroup Service on The Planet! ***
>                       http://www.usenet.com
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Hi

GNAT provides the (non portable) 'Enum_Rep attribute.

	Des Walker
	Alenia-Marconi Systems

Re: Ada 0x: Re: Representation clause

[David C. Hoos, Sr.]

'Image returns a string, while 'Rep would return a universal integer, so
I don't see how my proposal would be confusing.

The overloaded 'Value always returns a value of the enumeration type,
regardless of whether the argument is a string or a universal integer.


"Florian Weimer" <fw@deneb.enyo.de> wrote in message
news:87hf1l1p15.fsf@deneb.enyo.de...
> "David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> writes:
>
> > I would suggest the attribute name 'Rep.  Its inverse should be
> > provided as well -- perhaps by overloading the 'Value
> > attribute.
>
> In this case, you should use both 'Image and 'Value, otherwise it's
> quite confusing.

Re: Ada 0x: Re: Representation clause

[Randy Brukardt]

Martin Dowie wrote in message <3a9621eb$1@pull.gecm.com>...
>Do I spot a possible language extension here?
>
>How about a 'Underlying_Value attribute?

This was discussed ad-nausum during the Ada 9x process and eventually
dropped as having insufficient value. Thus the note in the RM that
someone quoted.

            Randy Brukardt.

Re: Ada 0x: Re: Representation clause

[Florian Weimer]

"David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> writes:

> 'Image returns a string, while 'Rep would return a universal integer, so
> I don't see how my proposal would be confusing.

From a type-based point of few, I agree.

> The overloaded 'Value always returns a value of the enumeration type,
> regardless of whether the argument is a string or a universal integer.

'Image and 'Value are roughly inverse, and so would be 'Rep and Value.
I find this asymmetry confusing.

BTW: Your quoting style sucks, and I do read CLA, no need to send me
carbon copies of your replies, especially if they are not marked as
copies.

Re: Ada 0x: Re: Representation clause

[James Rogers]

I just sent the following article to AdaPower.com. It is my humble
attempt to provide a simple solution to the problems mentioned in this
thread without involving, or waiting for, a language revision effort.

The following article is intended for the section titled
"Source Code Packages for Reuse". I place it in the public domain.

I was inspired to provide this solution because of a discussion
concerning how to use the internal representation of an enumerated
type with a representation clause. Several contributors to the
discussion expressed dissatisfaction with the fact that the language
makes the use of the internal value so obtuse.

I offer the following article as one possible solution for the
problem.

Jim Rogers
Colorado Springs, Colorado

jimmaureenrogers@worldnet.att.net

-------------------------------------------------------------------
Ada allows the definition of an Enumerated type to include a
representation clause. This clause is used to define the internal
representation of the values of the Enumerated type. A difficulty
arises when one wants to view, or convert to, that internal 
representation.

The 'POS attribute of an Enumerated type only corresponds to the
internal representation if the programmer has not explicitly used a
representation clause. Ada provides no attribute to convert from an
enumeration value to its internal representation. The only available
course of action is to use Ada.Unchecked_Conversion on the 
enumeration value. This is not difficult, or particularly error prone.

Errors can easily be encountered when trying to convert from what
is expected to be an internal representation to the corresponding
enumeration value. The following example may illustrate the problem.

type Colors is (red, orange, yellow, green);
for Colors use
  ( red    => 1,
    orange => 10,
    yellow => 100,
    green  => 1000);

Converting to the internal representation results in no errors.
It is possible that an attempt may be made to convert an integer,
not in the set of internal values, to one of the enumeration values.

If the following is attempted, Program_Error will be raised at run-time.

   function Convert is new Ada.Unchecked_Conversion(Source => Integer,
                    Target => Colors);

   Enum_Value : Colors := Convert(2);

The following generic package is designed to solve these problems
for all possible enumerated types.

-----------------------------------------------------------------------
-- This package provides a generic encapsulation of enumerated types
-- to allow simple conversion between the implementation value of an
-- enumerated type, and the corresponding enumeration value.
-----------------------------------------------------------------------

generic

   type Enum is (<>);

package Convert_Internal is

   function Internal_Representation(Item : enum) return Integer;

   function Value_Representation(Item : Integer) return Enum;

   Out_Of_Range_Error : Exception;

end Convert_Internal;



-----------------------------------------------------------------------
-- This package provides a generic encapsulation of enumerated types
-- to allow simple conversion between the implementation value of an
-- enumerated type, and the corresponding enumeration value.
-----------------------------------------------------------------------
with Ada.Unchecked_Conversion;
           
package body Convert_Internal is
           
   function Internal_Representation(Item : enum) return Integer is

      function convert is new Ada.Unchecked_Conversion(Source => Enum,
                                             Target => Integer);
   begin
      return convert(Item);
   end Internal_Representation;
   
   function Value_Representation(Item : Integer) return Enum
is              
                 
      function convert is new Ada.Unchecked_Conversion(Source =>
Integer,
                                             Target =>
Enum);                 
      Is_Valid : Boolean := False;
   begin
      for enum_val in Enum'Range loop
         Is_Valid := Internal_Representation(enum_val) = Item;
         exit when Is_Valid;
      end loop;
      if Is_Valid then
         return convert(Item);
      else
         raise Out_Of_Range_Error;
      end if;
   end Value_Representation;
   
end Convert_Internal;

Re: Ada 0x: Re: Representation clause

[Florian Weimer]

James Rogers <jimmaureenrogers@worldnet.att.net> writes:

> If the following is attempted, Program_Error will be raised at run-time.
> 
>    function Convert is new Ada.Unchecked_Conversion(Source => Integer,
>                     Target => Colors);
> 
>    Enum_Value : Colors := Convert(2);

Eh, could you provide a RM reference which supports your claim?  I
don't think you can rely on a Program_Error exception in such cases.
Constraint_Error might be raised as well, or no exception at all.

Re: Representation clause

[David C. Hoos, Sr.]

Given Randy Brukardt's comment that adding an enumeration representation
attribute
"was discussed ad-nausum during the Ada 9x process and eventually dropped as
having
insufficient value," I submit the following code for a complete generic
package (along
with a simple test program for it), implementing conversions both ways:

-- Begin submitted source code --
generic
  type Enum is (<>);
  type Reps is range <>;
package Enum_Reps is

   function Value (X                        : Reps;
                   Raise_Exception_On_Error : Boolean        := False)
     return Enum;

   function Rep (X : Enum) return Reps;

end Enum_Reps;

with Ada.Exceptions;
with Ada.Unchecked_Conversion;
package body Enum_Reps is

   -- The following three declarations are an artifice to obtain the
   -- name of the instantiation, to use in exception messages.
   ID : exception;
   Id_Name : constant String :=
     Ada.Exceptions.Exception_Name (ID'Identity);
   Unit_Name : String renames ID_Name (1 .. ID_Name'Last - 3);

   ---------
   -- Rep --
   ---------

   function Rep (X : Enum) return Reps is
      function To_Rep is new Ada.Unchecked_Conversion
        (Source => Enum,
         Target => Reps);
   begin
      return To_Rep (X);
   end Rep;

   -----------
   -- Value --
   -----------

   function Value (X                        : Reps;
                   Raise_Exception_On_Error : Boolean        := False)
     return Enum is
      function To_Enum is new Ada.Unchecked_Conversion
        (Source => Reps,
         Target => Enum);
      Result : Enum := To_Enum (X);
   begin
      if Raise_Exception_On_Error and then not Result'Valid then
         Ada.Exceptions.Raise_Exception
           (E => Constraint_Error'Identity,
            Message => "Invalid representation:" &
            Reps'Image (X) &
            "; raised in " & Unit_Name & ".VALUE.");
      end if;
      return Result;
   end Value;

end Enum_Reps;

with Ada.Text_IO;
with Enum_Reps;
procedure Test_Enum_Reps is
   type Colors is (Red, Yellow, Green);
   for Colors use
      (Red    => 1,
       Yellow => 2,
       Green  => 4);
   -- The enumeration's 'Size attribute must be the same as that of
   -- the representation type, else a compile error will occur when
   -- instantiating the generic package.
   for Colors'Size use Integer'Size;

   package Color_Reps is new Enum_Reps
     (Enum => Colors,
      Reps => Integer);

   Color : Colors;

begin
   for C in Colors'Range loop
      Ada.Text_Io.Put_Line
        ("Representation of " & Colors'Image (C) &
         " is" & Integer'Image (Color_Reps.Rep (C)));
   end loop;

   Ada.Text_IO.New_Line;

   -- Test 'Valid attribute
   for I in 0 .. 5 loop
      Color := Color_Reps.Value (I);
      if Color'Valid then
         Ada.Text_IO.Put_Line
           ("Color represented by" & Integer'Image (I) &
            " is " & Colors'Image (Color));
      else
         Ada.Text_IO.Put_Line
           (Integer'Image (I) &
            " is an invalid Colors representation.");
      end if;
   end loop;

   -- Raise exception for invalid representation
   for I in 0 .. 5 loop
      Color := Color_Reps.Value (I, True);
      Ada.Text_IO.Put_Line
           ("Color represented by" & Integer'Image (I) &
            " is " & Colors'Image (Color));
   end loop;

end Test_Enum_Reps;

-- end submitted source code --

"Anatoly Chernyshev" <@http://www.adapower.net/~achernyshev> wrote in
message news:3a95c52f@post.usenet.com...
> **** Post for FREE via your newsreader at post.usenet.com ****
>
> Hello again,
>
> Now I wander about representation clause for enumerated types.
> For example,
>    type ATOM is (H, C, N, O);
>    for  ATOM use (H=>1, C=>6, N=>7, O=>8);
>
> How can I access these 'internal' numbers?
> ATOM'POS yields 0, 1, 2, 3 respectively and I know no other relevant
> attributes.
>
> Thanks,
> Anatoly
>
>
>
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>  *** Usenet.com - The #1 Usenet Newsgroup Service on The Planet! ***
>                       http://www.usenet.com
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Re: Representation clause

[Ken Garlington]

"David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> wrote in message
news:fEOl6.129219$Ch.23956265@newsrump.sjc.telocity.net...

:    -- The enumeration's 'Size attribute must be the same as that of
:    -- the representation type, else a compile error will occur when
:    -- instantiating the generic package.
:    for Colors'Size use Integer'Size;

By the way: on GNAT 3.13p, the following will generate a compiler _warning_,
but will compile:

   for Colors'Size use 3;

The  test program also ran successfully.

You may wish to modify the comments appropriately.

Re: Ada 0x: Re: Representation clause

[James Rogers]

My assertion that Program_Error will be raised is based upon the result
of tests using GNAT 3.13p. Note that my code does NOT rely on that or
any other exception being raised to run properly. It detects the
erroneous condition without causing any exception to be raised.

It does raise its own exception when an erroneous condition is
detected. 

I admit that I may have generalized the response too much based upon
testing with one compiler. On the other hand, my solution does not
rely on that generalization. I therefore feel that my solution is only
half bad :-).

Jim Rogers
Colorado Springs, Colorado 

Florian Weimer wrote:
> 
> James Rogers <jimmaureenrogers@worldnet.att.net> writes:
> 
> > If the following is attempted, Program_Error will be raised at run-time.
> >
> >    function Convert is new Ada.Unchecked_Conversion(Source => Integer,
> >                     Target => Colors);
> >
> >    Enum_Value : Colors := Convert(2);
> 
> Eh, could you provide a RM reference which supports your claim?  I
> don't think you can rely on a Program_Error exception in such cases.
> Constraint_Error might be raised as well, or no exception at all.

Re: Representation clause

[David C. Hoos, Sr.]

The fact that a given compiler may do reasonable things when the
sizes of the actual parameters of an instantiation of
Ada.Unchecked_Conversion are unequal, is not a property on
which I would like to depend.  However, since there is at least one
compiler for which my comment is not true, I have modified my
comment to read as follows:

   -- The enumeration's 'Size attribute must be the same as that of
   -- the representation type, else the effect is implementation-
   -- defined; in particular, the result can be abnormal (see
   -- RM95 13.9.1).

Now, of course, in the case of discontiguous representation, (the
case for the example code) the result can still be abnormal for the
Value function.  Accordingly, the package client may either test
the result with the 'Valid attribute, or opt to have an exception
raised.

"Ken Garlington" <Ken.Garlington@computer.org> wrote in message
news:FOPl6.864$Vz2.141381754@newssvr16.news.prodigy.com...
> "David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> wrote in message
> news:fEOl6.129219$Ch.23956265@newsrump.sjc.telocity.net...
>
> :    -- The enumeration's 'Size attribute must be the same as that of
> :    -- the representation type, else a compile error will occur when
> :    -- instantiating the generic package.
> :    for Colors'Size use Integer'Size;
>
> By the way: on GNAT 3.13p, the following will generate a compiler
_warning_,
> but will compile:
>
>    for Colors'Size use 3;
>
> The  test program also ran successfully.
>
> You may wish to modify the comments appropriately.
>
>

Re: Representation clause

[Ken Garlington]

"David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> wrote in message
news:CQdm6.136516$Ch.25230662@newsrump.sjc.telocity.net...

: The fact that a given compiler may do reasonable things when the
: sizes of the actual parameters of an instantiation of
: Ada.Unchecked_Conversion are unequal, is not a property on
: which I would like to depend.  However, since there is at least one
: compiler for which my comment is not true, I have modified my
: comment to read as follows:
:
:    -- The enumeration's 'Size attribute must be the same as that of
:    -- the representation type, else the effect is implementation-
:    -- defined; in particular, the result can be abnormal (see
:    -- RM95 13.9.1).

Certainly, you don't want to depend upon that behavior, and the comment is
better. I am curious about the interpretation of the ARM in one area,
however. 13.3:47 and 13.9:4 seems to guarantee that we can depend on 'Size
applied to the subtype being honored by the Unchecked_Conversion  *source*
parameter; are there any issues with the *target* object not being the same
'Size as its subtype? If the intent is to point out that there are
restrictions related to the underlying dependence on Unchecked_Conversion, a
reference to 13.9:5-11 would seem more appropriate. In fact, 13.9:9 might
imply that you could _never_ depend upon this working...

Re: Ada 0x: Re: Representation clause

[Randy Brukardt]

James Rogers wrote in message <3A97F419.6E2F075@worldnet.att.net>...
>My assertion that Program_Error will be raised is based upon the result
>of tests using GNAT 3.13p. Note that my code does NOT rely on that or
>any other exception being raised to run properly. It detects the
>erroneous condition without causing any exception to be raised.


Basing it on the RM, rather than a particular compiler, would be better.

>It does raise its own exception when an erroneous condition is
>detected.
>
>I admit that I may have generalized the response too much based upon
>testing with one compiler. On the other hand, my solution does not
>rely on that generalization. I therefore feel that my solution is only
>half bad :-).


Why didn't you use the 'Valid attribute for the check? Then you can can
avoid the erroneous behavior. (Your current code is erroneous if the
representation is out of range, and while it *probably* will work on all
Ada compilers, there is no guarentee of that.)

        Randy Brukardt.

Re: Ada 0x: Re: Representation clause

[James Rogers]

Randy Brukardt wrote:
> 
> James Rogers wrote in message <3A97F419.6E2F075@worldnet.att.net>...
> >My assertion that Program_Error will be raised is based upon the result
> >of tests using GNAT 3.13p. Note that my code does NOT rely on that or
> >any other exception being raised to run properly. It detects the
> >erroneous condition without causing any exception to be raised.
> 
> Basing it on the RM, rather than a particular compiler, would be better.

This is a curious statement. How does the RM solve this problem?
Section 13.9 discusses unchecked conversion issues. Section 13.9.1
states that use of Ada.Unchecked_Conversion can result in an
invalid representation. 13.9.1 states "It is erroneous to evaluate
a primary that is a name denoting an abnormal object, or to
evaluate a prefix that denotes an abnormal object.

If the representation of a scalar object does not represent a value
of the object's subtype, the object is said to have an invalid
representation. It is a bounded error to evaluate the value of
such an object. If the error is detected, either Constraint_Error or
Program_Error is raised. Otherwise, execution continues using the
invalid representation."

Note that the GNAT 3.13p action of raising Program_Error is fully
supported by this clause in the RM.

Also note that my code compeletly avoids the creation of invalid
data by checking the numeric value against all correct valid
internal representations for the enumerated type. This check is
done before converting the numeric value to the enumerated type.
If the numeric value is not in the set of valid internal 
representation values for the enumerated type, my code raises its
own exception "Out_Of_Range_Error". This is appropriate rather
than raising Constraint_Error or Program_Error because no invalid
representation is created. 

>
> >It does raise its own exception when an erroneous condition is
> >detected.
> >
> >I admit that I may have generalized the response too much based upon
> >testing with one compiler. On the other hand, my solution does not
> >rely on that generalization. I therefore feel that my solution is only
> >half bad :-).
> 
> Why didn't you use the 'Valid attribute for the check? Then you can can
> avoid the erroneous behavior. (Your current code is erroneous if the
> representation is out of range, and while it *probably* will work on all
> Ada compilers, there is no guarentee of that.)

Note that section 13.9 states that data can contain an invalid
representation. The code is only erroneous if one attempts to 
evaluate the data containing an invalid representation. The
program is not erroneous if an invalid representation never occurs.

I would have to create an invalid representation in order to perform
a 'Valid check. Why is this preferred over detecting an out of
range source for conversion, and raising an exception to avoid
an invalid representation? As has been demonstrated above, it is
possible for a compiler to detect the invalid representation and
raise either Constraint_Error of Program_Error. What is the value
of attempting to use the 'Valid attribute if the compiler will
raise an exception before the 'Valid attribute can be checked?

Jim Rogers
Colorado Springs, Colorado USA

Re: Ada 0x: Re: Representation clause

[James Rogers]

Randy Brukardt wrote:
> 
> Because checking 'Valid does NOT evaluate an invalid representation.
> (That is a subtle point.) And creating an invalid representation is
> neither a bounded error nor erroneous: it is only the action of
> EVALUATING an invalid representation that is an error.
> 
> Thus, creating a value with Unchecked_Conversion and IMMEDIATELY
> checking it with 'Valid is perfectly valid Ada code. And any compiler
> that raises an exception before doing so is incorrect (and I very much
> doubt you'd find one.)

Yes, that clearly leads to simpler code than my more heavy-handed
approach. I had missed the subtle point that 'Valid does not evaluate
the scalar variable. I was attempting to perform an eqivalent 
determination before converting the data to the scalar type.

Thanks for your patience.

Jim Rogers
Colorado Springs, Colorado USA