* Re: Enumeration representation
1999-09-10 0:00 Alex
@ 1999-09-10 0:00 ` Ted Dennison
1999-09-10 0:00 ` Robert Dewar
1999-09-10 0:00 ` David C. Hoos, Sr.
` (3 subsequent siblings)
4 siblings, 1 reply; 37+ messages in thread
From: Ted Dennison @ 1999-09-10 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 37+ messages in thread* Re: Enumeration representation
1999-09-10 0:00 ` Ted Dennison
@ 1999-09-10 0:00 ` Robert Dewar
1999-09-13 0:00 ` Ted Dennison
0 siblings, 1 reply; 37+ messages in thread
From: Robert Dewar @ 1999-09-10 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 37+ messages in thread* Re: Enumeration representation
1999-09-10 0:00 ` Robert Dewar
@ 1999-09-13 0:00 ` Ted Dennison
0 siblings, 0 replies; 37+ messages in thread
From: Ted Dennison @ 1999-09-13 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Enumeration representation
1999-09-10 0:00 Alex
1999-09-10 0:00 ` Ted Dennison
@ 1999-09-10 0:00 ` David C. Hoos, Sr.
1999-09-10 0:00 ` Robert Dewar
1999-09-10 0:00 ` Keith Thompson
` (2 subsequent siblings)
4 siblings, 1 reply; 37+ messages in thread
From: David C. Hoos, Sr. @ 1999-09-10 0:00 UTC (permalink / raw)
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 ;)
^ permalink raw reply [flat|nested] 37+ messages in thread* Re: Enumeration representation
1999-09-10 0:00 ` David C. Hoos, Sr.
@ 1999-09-10 0:00 ` Robert Dewar
0 siblings, 0 replies; 37+ messages in thread
From: Robert Dewar @ 1999-09-10 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Enumeration representation
1999-09-10 0:00 Alex
1999-09-10 0:00 ` Ted Dennison
1999-09-10 0:00 ` David C. Hoos, Sr.
@ 1999-09-10 0:00 ` Keith Thompson
1999-09-11 0:00 ` Robert Dewar
1999-09-10 0:00 ` Matthew Heaney
1999-09-13 0:00 ` Alex
4 siblings, 1 reply; 37+ messages in thread
From: Keith Thompson @ 1999-09-10 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Enumeration representation
1999-09-10 0:00 ` Keith Thompson
@ 1999-09-11 0:00 ` Robert Dewar
1999-09-11 0:00 ` Keith Thompson
0 siblings, 1 reply; 37+ messages in thread
From: Robert Dewar @ 1999-09-11 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Enumeration representation
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
0 siblings, 2 replies; 37+ messages in thread
From: Keith Thompson @ 1999-09-11 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Enumeration representation
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 ` Robert Dewar
1 sibling, 1 reply; 37+ messages in thread
From: Bryce Bardin @ 1999-09-12 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Enumeration representation
1999-09-12 0:00 ` Bryce Bardin
@ 1999-09-13 0:00 ` Robert Dewar
1999-09-13 0:00 ` Keith Thompson
0 siblings, 1 reply; 37+ messages in thread
From: Robert Dewar @ 1999-09-13 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Enumeration representation
1999-09-13 0:00 ` Robert Dewar
@ 1999-09-13 0:00 ` Keith Thompson
0 siblings, 0 replies; 37+ messages in thread
From: Keith Thompson @ 1999-09-13 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Enumeration representation
1999-09-11 0:00 ` Keith Thompson
1999-09-12 0:00 ` Bryce Bardin
@ 1999-09-13 0:00 ` Robert Dewar
1999-09-12 0:00 ` Keith Thompson
1999-09-13 0:00 ` Robert A Duff
1 sibling, 2 replies; 37+ messages in thread
From: Robert Dewar @ 1999-09-13 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Enumeration representation
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 ` Robert A Duff
1 sibling, 1 reply; 37+ messages in thread
From: Keith Thompson @ 1999-09-12 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 37+ messages in thread* Re: Enumeration representation
1999-09-12 0:00 ` Keith Thompson
@ 1999-09-13 0:00 ` Robert Dewar
1999-09-13 0:00 ` Keith Thompson
1999-09-13 0:00 ` Ted Dennison
0 siblings, 2 replies; 37+ messages in thread
From: Robert Dewar @ 1999-09-13 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Enumeration representation
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
1 sibling, 1 reply; 37+ messages in thread
From: Keith Thompson @ 1999-09-13 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Enumeration representation
1999-09-13 0:00 ` Keith Thompson
@ 1999-09-14 0:00 ` Robert Dewar
0 siblings, 0 replies; 37+ messages in thread
From: Robert Dewar @ 1999-09-14 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Enumeration representation
1999-09-13 0:00 ` Robert Dewar
1999-09-13 0:00 ` Keith Thompson
@ 1999-09-13 0:00 ` Ted Dennison
1 sibling, 0 replies; 37+ messages in thread
From: Ted Dennison @ 1999-09-13 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Enumeration representation
1999-09-13 0:00 ` Robert Dewar
1999-09-12 0:00 ` Keith Thompson
@ 1999-09-13 0:00 ` Robert A Duff
1999-09-13 0:00 ` Robert Dewar
1 sibling, 1 reply; 37+ messages in thread
From: Robert A Duff @ 1999-09-13 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Enumeration representation
1999-09-13 0:00 ` Robert A Duff
@ 1999-09-13 0:00 ` Robert Dewar
0 siblings, 0 replies; 37+ messages in thread
From: Robert Dewar @ 1999-09-13 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Enumeration representation
1999-09-10 0:00 Alex
` (2 preceding siblings ...)
1999-09-10 0:00 ` Keith Thompson
@ 1999-09-10 0:00 ` Matthew Heaney
1999-09-10 0:00 ` Robert Dewar
1999-09-13 0:00 ` Alex
4 siblings, 1 reply; 37+ messages in thread
From: Matthew Heaney @ 1999-09-10 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 37+ messages in thread* Re: Enumeration representation
1999-09-10 0:00 ` Matthew Heaney
@ 1999-09-10 0:00 ` Robert Dewar
0 siblings, 0 replies; 37+ messages in thread
From: Robert Dewar @ 1999-09-10 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: Enumeration representation
1999-09-10 0:00 Alex
` (3 preceding siblings ...)
1999-09-10 0:00 ` Matthew Heaney
@ 1999-09-13 0:00 ` Alex
4 siblings, 0 replies; 37+ messages in thread
From: Alex @ 1999-09-13 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 37+ messages in thread