Re: Enumeration representation

Re: Enumeration representation

[Robert Dewar]

In article <37d9061a@news1.prserv.net>,
  "Matthew Heaney" <matthew_heaney@acm.org> wrote:
> The image of literal B is of course "B".  But I don't know
what 'Img will
> return if you also use pragma Discard_Names.

Well, you know what we do to answer such questions, we consult
the super-secret archives known as the GNAT documentation,
carefully hidden from sight by being included in every
copy of GNAT distributed :-) There we find:

  <<Pragma Discard_Names causes names of enumeration literals to
    be suppressed. In the presence of this pragma, the Image
    attribute provides the image of the Pos of the literal, and
    Value accepts Pos values>>

The exact effect is implementation defined, and choosing the
pos seems as reasonable as any other choice. Choosing the
representation would be definitely a bad idea, the point of
a enumeration representation clause is that it does NOT affect
the semantics of programs, ONLY the representation.

> GNAT seems to be displaying the value of T'Pos.

which, considering the above documentation, is what we expect!

> You want to underlying representation.  If so, you'll have use
> Unchecked_Conversion to convert the literal to an integer, and
then display
> that.
>
> An alternative is to use the GNAT-specific attribute 'Enum_Rep
(I think
> that's what it's called).


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Enumeration representation

[Robert Dewar]

In article <7rava6$kht@hobbes.crc.com>,
  "David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> wrote:
>
> Alex <busato@newtech.it> wrote in message
> news:37D8E3BC.175DB72C@newtech.it...
> > I've written the following example program for testing
enumeration
> > represetantion clause:
> >
> > with Ada.Text_IO; use Ada.Text_IO;
> >
> >
> > procedure MainEnum is
> >
> >       type Status is (a,b,c,d,e);
> >       pragma Discard_Names(Status);
> >
> >       for Status use
> >        ( a => 0,
> >          b => 20,
> >          c => 400,
> >          d => 800,
> >          e => 1600);
> >
> >        S : Status;
> > begin
> >       S := b;
> >       Put(" => " & S'img);
> > end MainEnum;
> >
> > I've compiled it with Gnat (the latest version)
> > the output of program is 1 but I was expecting another value
: 20.
> > Does  Gnat support this clause?
> I'm not sure to which clause you refer.
>
> > Did I use this clause badly?
> >
>
> About the discard_names pragma the LRM says C.5 (7):
> If the pragma applies to an enumeration type, then the
semantics
> of the Wide_Image and Wide_Value attributes are implementation
> defined for that type; the semantics of Image and Value are
still
> defined in terms of Wide_Image and Wide_Value. In addition,
the
> semantics of Text_IO.Enumeration_IO are implementation
defined.
> If the pragma applies to a tagged type, then the semantics of
the
> Tags.Expanded_Name function are implementation defined for
that
> type. If the pragma applies to an exception, then the
semantics
> of the Exceptions.Exception_Name function are implementation
> defined for that exception.
>
> The GNAT Reference Manual is not entirely correct in what it
> states about this pragma, in that it says it is ignored.  What
> really happens, is that the Image attribute returns instead
> of the image of the name, the image of the 'pos attribute.'

Well my copy of the reference manual does not say that, as I
quoted in my previous message. It is possible that versions of
the reference manual for old versions of GNAT are out of date ..
>
> To do what you want to do, you need an instance of
> Ada.Unchecked_Conversion, as demonstrated in this modification
> of your program:
>
> with Ada.Text_Io;
> use Ada.Text_Io;
> with Ada.Unchecked_Conversion;
> procedure MainEnum is
>
>    type Status is (a,b,c,d,e);
>    pragma Discard_Names(Status);
>
>    for Status use
>       ( a => 0,
>         b => 20,
>         c => 400,
>         d => 800,
>         e => 1600);
>    type Status_Rep is mod 2 ** Status'Size;
>
>    function Rep is new Ada.Unchecked_Conversion
>      (Source => Status,
>       Target => Status_rep);
>
> --   S : Status;
> begin
>    for S in Status'Range loop
>       Put("pos => " & S'img);
>       Put_Line ("; rep =>" & Rep(S)'Img);
>    end loop;
> end MainEnum;
>
> Abitavo a Milano dal 6/1963 al 11/1965, e il mio
> Italiano non e' quanto fluente come era allora ;)
>

Or, as noted in the previous post, 'Enum_Rep


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Enumeration representation

[Robert Dewar]

In article <7rb8c3$fql$1@nnrp1.deja.com>,
  Ted Dennison <dennison@telepath.com> wrote:
> In article <37D8E3BC.175DB72C@newtech.it>,
>   Alex <busato@newtech.it> wrote:
>
> >       type Status is (a,b,c,d,e);
> >       pragma Discard_Names(Status);
> >
> >       for Status use
> >        ( a => 0,
> >          b => 20,
> >          c => 400,
> >          d => 800,
> >          e => 1600);
> >
> >        S : Status;
> > begin
> >       S := b;
> >       Put(" => " & S'img);
> > end MainEnum;
> >
> > I've compiled it with Gnat (the latest version)
> > the output of program is 1 but I was expecting another value
: 20.
> > Does  Gnat support this clause?
>
> 'img is not defined in Ada. It's a Gnat attribute. The Gnat RM
I have
> says this should be equivalent to Status'image(S), in which
case I'd
> expect to see you get a "b".

Ted, you missed the Discard_Names!!!

>
> Generally I'd expect you to see that Status'image(S) = "b",
> Status'pos(S) = 1, and To_Integer(S) = 20 (where To_Integer is
an
> instatiation of unchecked_conversion between Status and
Integer).
>
> --
> T.E.D.
>
> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.
>


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Enumeration representation

[Keith Thompson]

Alex <busato@newtech.it> writes:
> I've written the following example program for testing enumeration
> represetantion clause:
[example deleted]

An enumeration representation clause is designed to change the
internal representation of an enumeration type *without* affecting the
visible semantics of the program.  Thus, the 'Pos, 'Val, 'Image,
'Value, 'Succ, 'Pred attributes, etc., operate as if the enumeration
representation clause weren't there.  The language doesn't define a
good way to get at the internal representation, though GNAT provides
an implementation-defined attribute for the purpose.  (The usual
advice is to use Unchecked_Conversion; the trick is determining what
integer type, if any, is the same size and signedness as your
enumeration type.)

Of course, if you write a value of an enumeration type to an external
interface (a file, a serial line, a call to another language,
whatever), you'll get the internal representation.  If you try to read
such a value from an external interface, it's very difficult to check
that you've gotten a valid value without invoking erroneous execution
(undefined behavior).

Basically, enumeration representation clauses are usually more trouble
than they're worth.  It's usually better to just declare a collection
of integer constants.  (Note: I said usually, not always.)

-- 
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.

Enumeration representation

[Alex]

I've written the following example program for testing enumeration
represetantion clause:

with Ada.Text_IO; use Ada.Text_IO;


procedure MainEnum is

      type Status is (a,b,c,d,e);
      pragma Discard_Names(Status);

      for Status use
       ( a => 0,
         b => 20,
         c => 400,
         d => 800,
         e => 1600);

       S : Status;
begin
      S := b;
      Put(" => " & S'img);
end MainEnum;

I've compiled it with Gnat (the latest version)
the output of program is 1 but I was expecting another value : 20.
Does  Gnat support this clause?
Did I use this clause badly?

Thank you very much,
by
Alessandro Busato
busato@newtech.it

Re: Enumeration representation

[David C. Hoos, Sr.]

Alex <busato@newtech.it> wrote in message
news:37D8E3BC.175DB72C@newtech.it...
> I've written the following example program for testing enumeration
> represetantion clause:
>
> with Ada.Text_IO; use Ada.Text_IO;
>
>
> procedure MainEnum is
>
>       type Status is (a,b,c,d,e);
>       pragma Discard_Names(Status);
>
>       for Status use
>        ( a => 0,
>          b => 20,
>          c => 400,
>          d => 800,
>          e => 1600);
>
>        S : Status;
> begin
>       S := b;
>       Put(" => " & S'img);
> end MainEnum;
>
> I've compiled it with Gnat (the latest version)
> the output of program is 1 but I was expecting another value : 20.
> Does  Gnat support this clause?
I'm not sure to which clause you refer.

> Did I use this clause badly?
>

About the discard_names pragma the LRM says C.5 (7):
If the pragma applies to an enumeration type, then the semantics
of the Wide_Image and Wide_Value attributes are implementation
defined for that type; the semantics of Image and Value are still
defined in terms of Wide_Image and Wide_Value. In addition, the
semantics of Text_IO.Enumeration_IO are implementation defined.
If the pragma applies to a tagged type, then the semantics of the
Tags.Expanded_Name function are implementation defined for that
type. If the pragma applies to an exception, then the semantics
of the Exceptions.Exception_Name function are implementation
defined for that exception.

The GNAT Reference Manual is not entirely correct in what it
states about this pragma, in that it says it is ignored.  What
really happens, is that the Image attribute returns instead
of the image of the name, the image of the 'pos attribute.

To do what you want to do, you need an instance of
Ada.Unchecked_Conversion, as demonstrated in this modification
of your program:

with Ada.Text_Io;
use Ada.Text_Io;
with Ada.Unchecked_Conversion;
procedure MainEnum is

   type Status is (a,b,c,d,e);
   pragma Discard_Names(Status);

   for Status use
      ( a => 0,
        b => 20,
        c => 400,
        d => 800,
        e => 1600);
   type Status_Rep is mod 2 ** Status'Size;

   function Rep is new Ada.Unchecked_Conversion
     (Source => Status,
      Target => Status_rep);

--   S : Status;
begin
   for S in Status'Range loop
      Put("pos => " & S'img);
      Put_Line ("; rep =>" & Rep(S)'Img);
   end loop;
end MainEnum;

Abitavo a Milano dal 6/1963 al 11/1965, e il mio
Italiano non e' quanto fluente come era allora ;)

Re: Enumeration representation

[Matthew Heaney]

In article <37D8E3BC.175DB72C@newtech.it> , Alex <busato@newtech.it>  wrote:

> I've written the following example program for testing enumeration
> represetantion clause:
>
> with Ada.Text_IO; use Ada.Text_IO;
>
>
> procedure MainEnum is
>
>       type Status is (a,b,c,d,e);
>       pragma Discard_Names(Status);

Why did you use Discard_Names?

>       for Status use
>        ( a => 0,
>          b => 20,
>          c => 400,
>          d => 800,
>          e => 1600);
>
>        S : Status;
> begin
>       S := b;
>       Put(" => " & S'img);

The image of literal B is of course "B".  But I don't know what 'Img will
return if you also use pragma Discard_Names.

> end MainEnum;
>
> I've compiled it with Gnat (the latest version)
> the output of program is 1 but I was expecting another value : 20.

GNAT seems to be displaying the value of T'Pos.

You want to underlying representation.  If so, you'll have use
Unchecked_Conversion to convert the literal to an integer, and then display
that.

An alternative is to use the GNAT-specific attribute 'Enum_Rep (I think
that's what it's called).

But if you really want to display 20, then why did you use an enumeration
type at all?  Why not do this:

  type Status_Type is range 0 .. 1600;

  A : constant Status_Type := 0;
  B : constant Status_Type := 20;     -- 20 or 200?
  C : constant Status_Type := 400;
  D : constant Status_Type := 800;
  E : constant Status_Type := 1600;

This is more or less equivalent to what you had using an enumeration type.
The difference is that Status_Type'Image (B) returns " 20", which is what
you wanted.


> Does  Gnat support this clause?

The pragma Discard_Names?  Look in Annex M of the GNAT User's Guide or
Reference Manual.

Why do you need that pragma anyway?  Do you have some storage restrictions?


> Did I use this clause badly?

I think so.  Give us some more specific information about what you're trying
to do.

> Thank you very much,

You're very welcome.

Matt

Re: Enumeration representation

[Ted Dennison]

In article <37D8E3BC.175DB72C@newtech.it>,
  Alex <busato@newtech.it> wrote:

>       type Status is (a,b,c,d,e);
>       pragma Discard_Names(Status);
>
>       for Status use
>        ( a => 0,
>          b => 20,
>          c => 400,
>          d => 800,
>          e => 1600);
>
>        S : Status;
> begin
>       S := b;
>       Put(" => " & S'img);
> end MainEnum;
>
> I've compiled it with Gnat (the latest version)
> the output of program is 1 but I was expecting another value : 20.
> Does  Gnat support this clause?

'img is not defined in Ada. It's a Gnat attribute. The Gnat RM I have
says this should be equivalent to Status'image(S), in which case I'd
expect to see you get a "b".

Generally I'd expect you to see that Status'image(S) = "b",
Status'pos(S) = 1, and To_Integer(S) = 20 (where To_Integer is an
instatiation of unchecked_conversion between Status and Integer).

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Enumeration representation

[Robert Dewar]

In article <yecn1uu9xy2.fsf@king.cts.com>,
  Keith Thompson <kst@cts.com> wrote:
  If you try to read
> such a value from an external interface, it's very difficult
> to check that you've gotten a valid value without invoking
> erroneous execution (undefined behavior).

No, it is quite easy, do an unchecked conversion of the value
into the enumeration variable, or just read the value in
directly with appropriate low level I/O, then do a 'Valid test.

And Keith, before you go rummaging around legalise in the RM,
be sure to read the relevant AI, whose purpose is basically
to say, yes of course the above works, whatever the RM says :-)


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Enumeration representation

[Keith Thompson]

Robert Dewar <robert_dewar@my-deja.com> writes:
> In article <yecn1uu9xy2.fsf@king.cts.com>,
>   Keith Thompson <kst@cts.com> wrote:
>   If you try to read
> > such a value from an external interface, it's very difficult
> > to check that you've gotten a valid value without invoking
> > erroneous execution (undefined behavior).
> 
> No, it is quite easy, do an unchecked conversion of the value
> into the enumeration variable, or just read the value in
> directly with appropriate low level I/O, then do a 'Valid test.
> 
> And Keith, before you go rummaging around legalise in the RM,
> be sure to read the relevant AI, whose purpose is basically
> to say, yes of course the above works, whatever the RM says :-)

Ok, I think you're right.

As I recall, a strict reading of the RM implies that the above obvious
approach invokes erroneous execution, though a conforming
implementation would have to be somewhat perverse to make it do
anything other than the obvious.  (I think you could avoid
erroneousness by wraping the enumeration variable in a record.)  Given
the AI (whose status I haven't followed lately), such an
implementation would have to be both perverse and non-conforming --
hopefully an unlikely combination.

Do you happen to remember the AI number?  I'm pretty sure it was based
on a comment I submitted.

I still think that enumeration representation clauses, as currently
defined, are more trouble than they're worth.  I personally spent a
great deal of time implementing them in TeleSoft's old Ada compiler --
and never used them outside a test program.  If the definition hadn't
gone to quite so much trouble to make them (nearly) invisible, they
might have been more useful -- for example, by providing predefined
attributes to convert between an enumeration value and its internal
representation.  Even an attribute that gives an integer type
guaranteed to be Unchecked_Conversion-compatible with a given
enumeration type would have helped, in a ugly sort of way.  (I'm
assuming such a type has to be of the same size and signedness as the
(internal representation of the) enumeration type.  Unless the
semantics of Unchecked_Conversion between discrete types of different
sizes are well-defined -- I've never been quite clear on that point.)

-- 
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.

Re: Enumeration representation

[Bryce Bardin]

Keith Thompson wrote:
> 
> Robert Dewar <robert_dewar@my-deja.com> writes:
> > In article <yecn1uu9xy2.fsf@king.cts.com>,
> >   Keith Thompson <kst@cts.com> wrote:
> >   If you try to read
> > > such a value from an external interface, it's very difficult
> > > to check that you've gotten a valid value without invoking
> > > erroneous execution (undefined behavior).
> >
> > No, it is quite easy, do an unchecked conversion of the value
> > into the enumeration variable, or just read the value in
> > directly with appropriate low level I/O, then do a 'Valid test.
> >
> > And Keith, before you go rummaging around legalise in the RM,
> > be sure to read the relevant AI, whose purpose is basically
> > to say, yes of course the above works, whatever the RM says :-)
> 
> Ok, I think you're right.
> 
> As I recall, a strict reading of the RM implies that the above obvious
> approach invokes erroneous execution, though a conforming
> implementation would have to be somewhat perverse to make it do
> anything other than the obvious.  (I think you could avoid
> erroneousness by wraping the enumeration variable in a record.)  Given
> the AI (whose status I haven't followed lately), such an
> implementation would have to be both perverse and non-conforming --
> hopefully an unlikely combination.
> 
> Do you happen to remember the AI number?  I'm pretty sure it was based
> on a comment I submitted.

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.

<snip>

Bryce Bardin

Re: Enumeration representation

[Keith Thompson]

Robert Dewar <robert_dewar@my-deja.com> writes:
> > Even an attribute that gives an integer type guaranteed to be
> > Unchecked_Conversion-compatible with a given enumeration type would
> > have helped, in a ugly sort of way. (I'm assuming such a type has to
> > be of the same size and signedness as the (internal representation
> > of the) enumeration type.
> 
> It's easy enough to define the type you need ...
> 
> > Unless the semantics of Unchecked_Conversion between discrete types
> > of different sizes are well-defined -- I've never been quite clear
> > on that point.)
> 
> No, the sizes should be the same, but this is easy enough to
> arrange. In GNAT everything is fine if sizes are different,
> you just get the equivalent of a type conversion without
> any checks, but not all compilers (and certainly not the RM)
> guarantee this.

Hmm.  Ok, suppose you have an enumeration type Foo.  It may or may not
have an enumeration representation clause; if it does, it may or may
not assign negative values to some of the literals.  How do you
declare an integer type that's guaranteed to be the same size and
signedness?

You could do something like this:

    type Equivalent_Type is range -2**Foo'Size .. 2**Foo'Size - 1;
    for Equivalent_Type'Size use Foo'Size;

but I'm not sure that's enough.  (I'm assuming 2's-complement; there
are ugly but portable ways to avoid that assumption.)  For example, it
doesn't distinguish between the following two cases:

    type Unsigned_Byte is (B0, B1, ..., B255);
    for Unsigned_Byte use (0, 1, ..., 255); -- a confirming rep clause
    for Unsigned_Byte'Size use 8;

and

    type Signed_Byte is (BM128, BM127, ..., BM1, B0, B1, ..., B127);
    for Signed_Byte use (-128, -127, ..., -1, 0, 1, ..., 127);
    for Signed_Byte'Size use 8;

If you could get at the internal representation, you could use

    type Equivalent_Type is range Foo'Enum_Rep(Foo'First) ..
                                  Foo'Enum_Rep(Foo'Last);
    for Equivalent_Type'Size use Foo'Size;

but of course the language doesn't provide that.

In real life, the programmer can usually make use of detailed
knowledge about any enumeration representation clause, but it would be
nice not to have to.

-- 
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.

Re: Enumeration representation

[Robert Dewar]

In article <yeczoyt2hxx.fsf@king.cts.com>,
  Keith Thompson <kst@cts.com> wrote:
> I still think that enumeration representation clauses, as
currently
> defined, are more trouble than they're worth.

I definitely agree, and they have a very nasty implementation
dependence, namely whether arrays with this index type have
holes or not (the RM does not specify).

 I personally spent a
> great deal of time implementing them in TeleSoft's old Ada
compiler --
> and never used them outside a test program.

Surprisingly they are often used, but I suspect that in many
cases where they are used, it would be fine to use a C style
enumeration, i.e. an integer type with a bunch of constant
definitions.

  If the definition hadn't
> gone to quite so much trouble to make them (nearly) invisible,
they
> might have been more useful -- for example, by providing
predefined
> attributes to convert between an enumeration value and its
internal
> representation.

Well it is easy enough to use unchecked conversion

  Even an attribute that gives an integer type
> guaranteed to be Unchecked_Conversion-compatible with a given
> enumeration type would have helped, in a ugly sort of way.
(I'm
> assuming such a type has to be of the same size and signedness
as the
> (internal representation of the) enumeration type.

It's easy enough to define the type you need ...

  Unless the
> semantics of Unchecked_Conversion between discrete types of
different
> sizes are well-defined -- I've never been quite clear on that
point.)

No, the sizes should be the same, but this is easy enough to
arrange. In GNAT everything is fine if sizes are different,
you just get the equivalent of a type conversion without
any checks, but not all compilers (and certainly not the RM)
guarantee this.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Enumeration representation

[Robert Dewar]

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!


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Enumeration representation

[Alex]

Thank you very much for your answers.
Ciao,
Alessandro

Alex wrote:

> I've written the following example program for testing enumeration
> represetantion clause:
>
> with Ada.Text_IO; use Ada.Text_IO;
>
> procedure MainEnum is
>
>       type Status is (a,b,c,d,e);
>       pragma Discard_Names(Status);
>
>       for Status use
>        ( a => 0,
>          b => 20,
>          c => 400,
>          d => 800,
>          e => 1600);
>
>        S : Status;
> begin
>       S := b;
>       Put(" => " & S'img);
> end MainEnum;
>
> I've compiled it with Gnat (the latest version)
> the output of program is 1 but I was expecting another value : 20.
> Does  Gnat support this clause?
> Did I use this clause badly?
>
> Thank you very much,
> by
> Alessandro Busato
> busato@newtech.it

Re: Enumeration representation

[Keith Thompson]

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.

Re: Enumeration representation

[Robert A Duff]

Robert Dewar <robert_dewar@my-deja.com> writes:

> In article <yeczoyt2hxx.fsf@king.cts.com>,
>   Keith Thompson <kst@cts.com> wrote:
> > I still think that enumeration representation clauses, as
> currently
> > defined, are more trouble than they're worth.
> 
> I definitely agree, and they have a very nasty implementation
> dependence, namely whether arrays with this index type have
> holes or not (the RM does not specify).

That's a general problem with high-level languages: If there's more than
one "reasonable" way to implement some feature, you can end up with
portability problems.  Formally, this is "just" an efficiency issue, so
the RM doesn't address it.  But it's such a huge efficiency issue that
it affects your design.  Similar examples: generics (whether code is
shared or not) and mutable records (whether they implicitly use the
heap).  It's not easy to write RM-style wording that requires one
particular implementation of these features, but it would certainly be
desirable if all compilers took the same approach.

Lower-level languages like C don't have this problem (at least not much)
-- for just about any feature of C, you can pretty much guess what the
compiler is going to do with it.

I agree that enum rep clauses are not worth the trouble -- they
shouldn't be in the language.

By the way, I think the Ada 83 Rationale had some words that made it
seem like the designers thought pragma Pack ought to control whether
arrays have holes or not.  That's not a very good solution, though,
and the RM gives no hint of it.

> Well it is easy enough to use unchecked conversion

Well, if the enumeration type is a generic formal...

- Bob
-- 
Change robert to bob to get my real email address.  Sorry.

Re: Enumeration representation

[Ted Dennison]

In article <7rbvna$25q$1@nnrp1.deja.com>,
  Robert Dewar <robert_dewar@my-deja.com> wrote:
> In article <7rb8c3$fql$1@nnrp1.deja.com>,
>   Ted Dennison <dennison@telepath.com> wrote:
> > In article <37D8E3BC.175DB72C@newtech.it>,
> > expect to see you get a "b".
>
> Ted, you missed the Discard_Names!!!

Well, shoot. So I did. I guess that's it for my lucrative carreer as
a Gnat Ada compiler. :-)

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Enumeration representation

[Robert Dewar]

In article <yechfkz8k1t.fsf@king.cts.com>,
  Keith Thompson <kst@cts.com> wrote:
> Hmm.  Ok, suppose you have an enumeration type Foo.  It may or
may not
> have an enumeration representation clause; if it does, it may
or may
> not assign negative values to some of the literals.  How do
you
> declare an integer type that's guaranteed to be the same size
and
> signedness?


You look and see whether it is signed!!!

If you insist on not knowing it is harder.

It is even harder if you insist on handcuffing yourself
and typing with your nose :-)

In a real situation, you know what type you are dealing with
and the section of code that has the enum type can export the
corresponding integral type and indeed the routine for doing
the conversion!



Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Enumeration representation

[Robert Dewar]

In article <wccso4jar3z.fsf@world.std.com>,
  Robert A Duff <bobduff@world.std.com> wrote:
> That's a general problem with high-level languages: If there's
more than
> one "reasonable" way to implement some feature, you can end up
with
> portability problems.  Formally, this is "just" an efficiency
issue, so
> the RM doesn't address it.  But it's such a huge efficiency
issue that
> it affects your design.

This is not just an efficiency problem, it is a functionality
issue, since it effects mapping of these arrays onto external
data. It is not comparable to some of your other examples in
this respect, and I think we just missed this one, and we
should have caught it ...


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Enumeration representation

[Ted Dennison]

In article <7rjn38$7e1$1@nnrp1.deja.com>,
  Robert Dewar <robert_dewar@my-deja.com> wrote:

> It is even harder if you insist on handcuffing yourself
> and typing with your nose :-)

I wonder if this is the voice of experience...

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Enumeration representation

[Keith Thompson]

Robert Dewar <robert_dewar@my-deja.com> writes:
> You look and see whether it is signed!!!
> 
> If you insist on not knowing it is harder.
> 
> It is even harder if you insist on handcuffing yourself
> and typing with your nose :-)
> 
> In a real situation, you know what type you are dealing with
> and the section of code that has the enum type can export the
> corresponding integral type and indeed the routine for doing
> the conversion!

What if the type is declared in code over which you have no control?
Yes, you can probably look at the source code, but it could change in
the next release.  For that matter, what if it's a generic formal
parameter?

If this feature had been better designed (IMHO), it would be possible
to get at the internal representation in a way that won't break if the
type or the representation is changed -- just recompile and it works.

I think we're all agreed on the proper solution: avoid enumeration
representation clauses whenever possible.

I gotta try that handcuff thing some time!

-- 
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.

Re: Enumeration representation

[Robert Dewar]

In article <yec7llus8yw.fsf@king.cts.com>,
  Keith Thompson <kst@cts.com> wrote:
> If this feature had been better designed (IMHO), it would be
possible
> to get at the internal representation in a way that won't
break if the
> type or the representation is changed -- just recompile and it
works.

Well it is not a matter of better design here, this issue was
specifically discussed in the design process, it was the general
conclusion that this is simply not a valuable enough feature
to be worth adding complexity to the language for.

That being said, you can see that GNAT disagrees to the extent
of adding the Enum_Rep attribute, which seems easy enough to
implement, and harmless ...



Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Enumeration representation

[Luke A. Guest]

Hi,

Am I correct in saying that enumerations don't necessarily begin at zero?
Is this implementation dependent?

Thanks,
Luke.

Re: Enumeration representation

[Stephen Leake]

"Luke A. Guest" <laguest@n_o_p_o_r_k_a_n_d_h_a_m.abyss2.demon.co.uk> writes:

> Hi,
> 
> Am I correct in saying that enumerations don't necessarily begin at zero?

Hmm. Say you have:

type Enum is (One, Two, Three);

Enum'first is One (one definition of "begin" :).

Enum'Pos (Enum'first) is 0 (RM 3.5.1 (7) - first position number)

However, none of that says what is stored in RAM. If you specify a
representation clause:

for Enum_Type use 
  (One => 1,
   Two => 2,
   Three => 3);

Then One will be stored as 1 in RAM. The above values for 'first and
'pos are not changed.

> Is this implementation dependent?

In the absence of a representation clause, the representation in RAM
is technically implementation dependent, but it's extremely
likely to be the same as the position number.

-- 
-- Stephe

Re: Enumeration representation

[Luke A. Guest]

On Thu, 01 Jan 2004 16:45:28 -0500, Stephen Leake wrote:

>> Is this implementation dependent?
> 
> In the absence of a representation clause, the representation in RAM
> is technically implementation dependent, but it's extremely
> likely to be the same as the position number.

Hmm, ok. Is there a representation clause that tells the compiler to start
at a particular value? I looked, but couldn't see it. Having to define
every enumeration twice could be a pain.

Thanks,
Luke.

Re: Enumeration representation

[tmoran]

> Having to define every enumeration twice could be a pain.
  You only need a rep clause if you want oddball values for the
representations, ie, you are dealing with communication with a
hardware device or another program and must adapt to its conventions.
If you are just using the enumeration internally you don't care
how the compiler represents it.

Re: Enumeration representation

[Stephen Leake]

"Luke A. Guest" <laguest@n_o_p_o_r_k_a_n_d_h_a_m.abyss2.demon.co.uk> writes:

> On Thu, 01 Jan 2004 16:45:28 -0500, Stephen Leake wrote:
> 
> >> Is this implementation dependent?
> > 
> > In the absence of a representation clause, the representation in RAM
> > is technically implementation dependent, but it's extremely
> > likely to be the same as the position number.
> 
> Hmm, ok. Is there a representation clause that tells the compiler to start
> at a particular value? 

No.

> I looked, but couldn't see it. Having to define every enumeration
> twice could be a pain.

You aren't "defining" them twice. You are defining them once, and
specifying the representation once.

Ada is verbose, in order to be very clear. Get used to it :).

-- 
-- Stephe

Re: Enumeration representation

[Robert A Duff]

"Luke A. Guest" <laguest@n_o_p_o_r_k_a_n_d_h_a_m.abyss2.demon.co.uk> writes:

> Am I correct in saying that enumerations don't necessarily begin at zero?
> Is this implementation dependent?

RM-13.4(8) *requires* the internal codes to be 0, 1, 2...
if no representation clause is given.
So there's never a need to say "for Enum_Type use (0, 1, 2, 3);" --
that's the default.  It is not implementation dependent.

And of course the position numbers always start at 0, no matter what
the representation is.

- Bob

Re: Enumeration representation

[Luke A. Guest]

On Thu, 01 Jan 2004 20:29:44 -0500, Stephen Leake wrote:

>> Hmm, ok. Is there a representation clause that tells the compiler to start
>> at a particular value? 
> 
> No.

Ok.
 
>> I looked, but couldn't see it. Having to define every enumeration
>> twice could be a pain.
> 
> You aren't "defining" them twice. You are defining them once, and
> specifying the representation once.

Ok, you know what I mean *Having to type (sometimes) twice*
 
> Ada is verbose, in order to be very clear. Get used to it :).

I am used to it. Like I said. I'm getting *back* into it ;-P

Luke.

Re: Enumeration representation

[Luke A. Guest]

On Thu, 01 Jan 2004 21:46:56 -0500, Robert A Duff wrote:

> RM-13.4(8) *requires* the internal codes to be 0, 1, 2...
> if no representation clause is given.
> So there's never a need to say "for Enum_Type use (0, 1, 2, 3);" --
> that's the default.  It is not implementation dependent.
> 
> And of course the position numbers always start at 0, no matter what
> the representation is.

Ah thanks,
Luke.

Re: Enumeration representation

[Marin David Condic]

We used to slap that on Ada83 code just to be sure we got what we wanted 
(usually because it was being communicated externally in some way). I 
don't think we ever encountered a compiler where the representation was 
otherwise, but because the standard didn't dictate that it was so, we 
played safe. Now that we're using Ada95, it is (as you observe) from the 
Department Of Redundancy Department and completely unnecessary. However, 
Our tools still generate this kind of code and old programmer's habbits 
die hard. People still do it. I wonder if it causes any harm by way of 
inefficiency in some respect?

MDC


Robert A Duff wrote:
> 
> RM-13.4(8) *requires* the internal codes to be 0, 1, 2...
> if no representation clause is given.
> So there's never a need to say "for Enum_Type use (0, 1, 2, 3);" --
> that's the default.  It is not implementation dependent.
> 
> And of course the position numbers always start at 0, no matter what
> the representation is.
> 
> - Bob


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: Enumeration representation

[Randy Brukardt]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
news:wcchdzf6p9b.fsf@shell01.TheWorld.com...
> "Luke A. Guest" <laguest@n_o_p_o_r_k_a_n_d_h_a_m.abyss2.demon.co.uk>
writes:
>
> > Am I correct in saying that enumerations don't necessarily begin at
zero?
> > Is this implementation dependent?
>
> RM-13.4(8) *requires* the internal codes to be 0, 1, 2...
> if no representation clause is given.
> So there's never a need to say "for Enum_Type use (0, 1, 2, 3);" --
> that's the default.  It is not implementation dependent.

Note that that is only true of Ada 95; Ada 83 didn't specify anything. So,
if you care and you have to be compatible with Ada 83, you do need to give
the rep. clause. (But that combination ought to be very rare.)

                 Randy.

Re: Enumeration representation

[Luke A. Guest]

On Fri, 02 Jan 2004 14:52:03 -0600, Randy Brukardt wrote:

>> RM-13.4(8) *requires* the internal codes to be 0, 1, 2...
>> if no representation clause is given.
>> So there's never a need to say "for Enum_Type use (0, 1, 2, 3);" --
>> that's the default.  It is not implementation dependent.
> 
> Note that that is only true of Ada 95; Ada 83 didn't specify anything. So,
> if you care and you have to be compatible with Ada 83, you do need to give
> the rep. clause. (But that combination ought to be very rare.)

Ok, thanks. I really won't need Ada83.

Luke.

Re: Enumeration representation

[Pat Rogers]

> However, Our tools still generate this kind
> of code and old programmer's habbits die hard. People still do it. I
> wonder if it causes any harm by way of inefficiency in some respect?

That depends upon the compiler recognizing it as a "confirming
representation clause", ie a special case that does not change
anything.  I would expect all of them do now; certainly the ones I
know do.

Still, I think it is bad form to put them in when no longer required,
just in case your compiler does not recognize that nothing is changed.
The resulting code generated can be really ugly (in terms of
performance).

--
Pat Rogers
Technical Editor, Ada Letters
progers@classwide.com

Re: Enumeration representation

[Robert A Duff]

Marin David Condic <nobody@noplace.com> writes:

>...I wonder if it causes any harm by way of
> inefficiency in some respect?

IMHO, it *should* not cause harm (to efficiency) to say "for Enum use
(0,1,2);".  The compiler's logic *should* be, "if the representation,
whether chosen by the user, or chosen by default, is the normal
efficient one, then generate efficient code".  However, I have seen
compilers that think, "if the representation is chosen by the user,
then generate all kinds of lookup tables, otherwise do the efficient
thing".  That's bad, because if the user asks for exactly what the
compiler would have chosen by default, you get different and less
efficient code.

- Bob

Re: Enumeration representation

[Marin David Condic]

Well, in the places where it is done in my project, it is typically 
there because someone wants to guarantee that the object(s) in question 
will be properly represented & understood on I/O. When the testing folks 
look at it with the monitor, there is info available to the monitor and 
the human tester to determine how to interpret the zeros and ones. The 
tools (and people) might one day be modified to understand that no rep 
clause means start counting from zero - but I won't hold my breath. ;-)

If the compiler can recognize it as a special case & not generate ugly 
code, maybe we're all right. I'd have to go get someone to check the 
compiler output - but at this time we're not pressed for CPU cycles, so 
it sort of falls into the category of "why bother"? (other than 
intellectual curiosity.)

MDC

Pat Rogers wrote:
> 
> Still, I think it is bad form to put them in when no longer required,
> just in case your compiler does not recognize that nothing is changed.
> The resulting code generated can be really ugly (in terms of
> performance).
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================