Why can't you create a out of order subtype?

Why can't you create a out of order subtype?

[brett_gengler]

I created a type whose order can not be rearranged and I want to create
a subtype of that type.  So,

type msg is ( msg_a, msg_b, msg_c, msg_d, msg_e);

subtype vowel_msg is msg (msg_a, msg_e); --wrong, but why?


Is it true that I can't define a a subtype that's not a ordered
subrange of a type?  My issue is that I want to enforce the subtype at
compile time instead of creating an array of booleans and doing a run
time check. (This is for an interface and I don't trust people to send
me the right types).

vowel_filter is array(msg) of Boolean := (msg_a => True, msg_e => True,
others => False);  --yuck.

Another option that I think is much, much worse then the boolean array
would be create an overloaded type...

type msg is ( msg_a, msg_b, msg_c, msg_d, msg_e);
type vowelmsg ( msg_a, msg_e);

But as you know, msg.msg_e = 4 and vowelmsg.msg_e = 1 so an unchecked
conversion is wrong on so many levels.

Am I screwed?  Should I just implement a boolean array and shut up
about it?

Re: Why can't you create a out of order subtype?

[Jeffrey Carter]

brett_gengler@yahoo.com wrote:

> I created a type whose order can not be rearranged and I want to create
> a subtype of that type.  So,
> 
> type msg is ( msg_a, msg_b, msg_c, msg_d, msg_e);
> 
> subtype vowel_msg is msg (msg_a, msg_e); --wrong, but why?

Ada only allows subrange subtypes of enumeration types. Sure, there are 
a lot of things it would be nice to be able to do, but the language only 
allows certain things.

> Is it true that I can't define a a subtype that's not a ordered
> subrange of a type?  My issue is that I want to enforce the subtype at
> compile time instead of creating an array of booleans and doing a run
> time check. (This is for an interface and I don't trust people to send
> me the right types).

It's true for elementary types.

> Another option that I think is much, much worse then the boolean array
> would be create an overloaded type...
> 
> type msg is ( msg_a, msg_b, msg_c, msg_d, msg_e);
> type vowelmsg ( msg_a, msg_e);
> 
> But as you know, msg.msg_e = 4 and vowelmsg.msg_e = 1 so an unchecked
> conversion is wrong on so many levels.

Yes, this may be worse, but you can at least get Unchecked_Conversion to 
work:

for Vowelmsg use (Msg_A => 0, Msg_E => 4);
for Vowelmsg'Size use Msg'Size;

This would still be a run-time check:

function To_Vowel is new Ada.Unchecked_Conversion
    (Source => Msg, Target => Vowelmsg);

It_Is_A_Vowel : constant Vowelmsg := To_Vowel (Any_Msg);

if It_Is_A_Vowel'Valid then -- It's a vowel!

-- 
Jeff Carter
"You cheesy lot of second-hand electric donkey-bottom biters."
Monty Python & the Holy Grail
14

Re: Why can't you create a out of order subtype?

[Marius Amado Alves]

> ...
>> Another option that I think is much, much worse then the boolean array
>> would be create an overloaded type...
>> type msg is ( msg_a, msg_b, msg_c, msg_d, msg_e);
>> type vowelmsg ( msg_a, msg_e);
>> But as you know, msg.msg_e = 4 and vowelmsg.msg_e = 1 so an unchecked
>> conversion is wrong on so many levels.
>
> Yes, this may be worse, but you can at least get Unchecked_Conversion 
> to work:
>
> for Vowelmsg use (Msg_A => 0, Msg_E => 4);
> for Vowelmsg'Size use Msg'Size;
>
> This would still be a run-time check:...

For run-time I find the "Value of Image" idiom a better one. It's 
readily available. No Unchecked_Conversion required.

declare
    M : Msg := Whatever;
    V : Vowelmsg;
begin
    V := Vowelmsg'Value (Msg'Image (M));
    -- if control reaches here then M is a vowel
exception
    when Constraint_Error => -- M is not a vowel
end;

Re: Why can't you create a out of order subtype?

[Pascal Obry]

Marius Amado Alves <amado.alves@netcabo.pt> writes:

> declare
>     M : Msg := Whatever;
>     V : Vowelmsg;
> begin
>     V := Vowelmsg'Value (Msg'Image (M));
>     -- if control reaches here then M is a vowel
> exception
>     when Constraint_Error => -- M is not a vowel
> end;

I don't think this is good style. The above code use exception for non
exceptional case. It uses exception as a if statement. Definitely something
to avoid.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Why can't you create a out of order subtype?

[Marius Amado Alves]

>> declare
>>     M : Msg := Whatever;
>>     V : Vowelmsg;
>> begin
>>     V := Vowelmsg'Value (Msg'Image (M));
>>     -- if control reaches here then M is a vowel
>> exception
>>     when Constraint_Error => -- M is not a vowel
>> end;
>
> I don't think this is good style. The above code use exception for non
> exceptional case. It uses exception as a if statement. Definitely 
> something
> to avoid.

No, not definitely. As you say it's a matter of style. This has come up 
before many times. It's the issue of using exceptions for logic in 
certain situations. There are two well established schools of thought 
on this. One says "no", the other says "yes". Obviously you belong to 
the former, and I to the latter. There are other respectful people of 
both schools other than you and I. At the "exceptional" workshop of 
Ada-Europe 2001 in Leuven this was very noticeable. Other situations 
where we the "yeses" find the use of exceptions for logic adequate 
include end of file detection. Also note that the idiom above is very 
similar to invalid data detection, where the use of exceptions is 
deemed adequate even in your school. Also note that the alternative 
idiom using Unchecked_Conversion hurts sensibilities in yet another 
school where the use of UC in this situation would be frowned upon. 
Also note that M failing to be a vowel can be considered exceptional = 
abnormal, a somewhat fuzzy notion. In sum, I neither agree or disagreed 
with you. To my eyes the exception idiom is acceptable here for all the 
stated reasons and more. But I accept the contrary view. Because there 
are fuzzy notions involved. My advice to the original poster is: just 
pick the idiom you 'feel' comfortable with, and carry on. Enrolment is 
gratis in either school :-)

Re: Why can't you create a out of order subtype?

[Wes Groleau]

Pascal Obry wrote:
> I don't think this is good style. The above code use exception for non
> exceptional case. It uses exception as a if statement. Definitely something
> to avoid.

When I was still in the industry, our Ada vendor
implemented Text_IO.End_of_File thusly:

    ...
    exception
       when End_Error => return True;
end End_Of_File;

REALLY irritating when you set the debugger to break on
exception in a program that reads lots of text files
and like a good boy checks for EOF before reading.

-- 
Wes Groleau

A pessimist says the glass is half empty.

An optimist says the glass is half full.

An engineer says somebody made the glass
        twice as big as it needed to be.

Re: Why can't you create a out of order subtype?

[Marius Amado Alves]

> When I was still in the industry, our Ada vendor
> implemented Text_IO.End_of_File thusly:
>
>    ...
>    exception
>       when End_Error => return True;
> end End_Of_File;

I'm curious about the "..." part. Was the exception ALWAYS raised?

Re: Why can't you create a out of order subtype?

[Wes Groleau]

Marius Amado Alves wrote:
>> When I was still in the industry, our Ada vendor
>> implemented Text_IO.End_of_File thusly:
>>
>>    ...
>>    exception
>>       when End_Error => return True;
>> end End_Of_File;
> 
> I'm curious about the "..." part. Was the exception ALWAYS raised?

No, only if you were at end of file.
The ... was an attempt to read from the file,
and if no exception, to put the file back in
its previous state.

The irony is that the purpose of calling the
function before reading is to avoid raising
an exception when you read.



-- 
Wes Groleau

Is it an on-line compliment to call someone a Net Wit ?

Re: Why can't you create a out of order subtype?

[Martin Dowie]

Marius Amado Alves wrote:
>> ...
>>
>>> Another option that I think is much, much worse then the boolean array
>>> would be create an overloaded type...
>>> type msg is ( msg_a, msg_b, msg_c, msg_d, msg_e);
>>> type vowelmsg ( msg_a, msg_e);
>>> But as you know, msg.msg_e = 4 and vowelmsg.msg_e = 1 so an unchecked
>>> conversion is wrong on so many levels.
>>
>>
>> Yes, this may be worse, but you can at least get Unchecked_Conversion 
>> to work:
>>
>> for Vowelmsg use (Msg_A => 0, Msg_E => 4);
>> for Vowelmsg'Size use Msg'Size;
>>
>> This would still be a run-time check:...
> 
> 
> For run-time I find the "Value of Image" idiom a better one. It's 
> readily available. No Unchecked_Conversion required.
> 
> declare
>    M : Msg := Whatever;
>    V : Vowelmsg;
> begin
>    V := Vowelmsg'Value (Msg'Image (M));
>    -- if control reaches here then M is a vowel
> exception
>    when Constraint_Error => -- M is not a vowel
> end;

That's very, very, very slow...

Cheers

-- Martin

Re: Why can't you create a out of order subtype?

[Marius Amado Alves]

>> declare
>>    M : Msg := Whatever;
>>    V : Vowelmsg;
>> begin
>>    V := Vowelmsg'Value (Msg'Image (M));
>>    -- if control reaches here then M is a vowel
>> exception
>>    when Constraint_Error => -- M is not a vowel
>> end;
>
> That's very, very, very slow...

No, it's only very, very slow :-)

If (and only if :-) that's too slow for the application then sure, use 
UC and 'Valid. And watch out for those uninitialized variables.

Re: Why can't you create a out of order subtype?

[Martin Dowie]

Marius Amado Alves wrote:
>>> declare
>>>    M : Msg := Whatever;
>>>    V : Vowelmsg;
>>> begin
>>>    V := Vowelmsg'Value (Msg'Image (M));
>>>    -- if control reaches here then M is a vowel
>>> exception
>>>    when Constraint_Error => -- M is not a vowel
>>> end;
>>
>>
>> That's very, very, very slow...
> 
> 
> No, it's only very, very slow :-)
> 
> If (and only if :-) that's too slow for the application then sure, use 
> UC and 'Valid. And watch out for those uninitialized variables.
> 

"pragma Normalize_Scalars;" :-)

Re: Why can't you create a out of order subtype?

[Robert A Duff]

Martin Dowie <martin.dowie@btopenworld.com> writes:

> Marius Amado Alves wrote:
> > For run-time I find the "Value of Image" idiom a better one. It's
> > readily available. No Unchecked_Conversion required.
> > declare
> >    M : Msg := Whatever;
> >    V : Vowelmsg;
> > begin
> >    V := Vowelmsg'Value (Msg'Image (M));
> >    -- if control reaches here then M is a vowel
> > exception
> >    when Constraint_Error => -- M is not a vowel
> > end;

If there are no further uses of V, then I think 11.6 allows the compiler
to eliminate the raising of Constraint_Error.  I don't much like
11.6...

> That's very, very, very slow...

True (if it works at all).  But you could use the "Value of Image" trick
to fill in a table that maps from one type to the other.  That would
work, and uses of the table would be pretty fast.

- Bob

Re: Why can't you create a out of order subtype?

[Marius Amado Alves]

On 3 Feb 2005, at 19:40, Robert A Duff wrote:

> Martin Dowie <martin.dowie@btopenworld.com> writes:
>
>> Marius Amado Alves wrote:
>>> For run-time I find the "Value of Image" idiom a better one. It's
>>> readily available. No Unchecked_Conversion required.
>>> declare
>>>    M : Msg := Whatever;
>>>    V : Vowelmsg;
>>> begin
>>>    V := Vowelmsg'Value (Msg'Image (M));
>>>    -- if control reaches here then M is a vowel
>>> exception
>>>    when Constraint_Error => -- M is not a vowel
>>> end;
>
> If there are no further uses of V, then I think 11.6 allows the 
> compiler
> to eliminate the raising of Constraint_Error.  I don't much like
> 11.6...
>
>> That's very, very, very slow...
>
> True (if it works at all).

Before I though you were complaining about the slowness of the Image 
(Value) operations (because there is probably parsing involved and 
string values on and off the stack) compared with unchecked conversion 
and 'Valid (which is very probably faster). Now I realise that you were 
probably complaining about the slowness of the exception handling 
mechanism. In that case, my experience with GNAT is that it is not that 
slow at all. I've made controlled experiments in the past. I think I 
reported them here.

Now, you made me take a look at 11.6 and yes, it seems if V is not used 
it can simply hold an undefined result and the exception not raised. 
But I bet you'll get a compiler warning. And rightly so, as unused 
variables are almost certainly a logic bug. It would in this case. 
Unless Vowelmsg were controlled and the logic put on Adjust or 
something. But then the compiler would consider V used, no?

Re: Why can't you create a out of order subtype?

[Robert A Duff]

Marius Amado Alves <amado.alves@netcabo.pt> writes:

> On 3 Feb 2005, at 19:40, Robert A Duff wrote:
> 
> > Martin Dowie <martin.dowie@btopenworld.com> writes:
> >
> >> Marius Amado Alves wrote:
> >>> For run-time I find the "Value of Image" idiom a better one. It's
> >>> readily available. No Unchecked_Conversion required.
> >>> declare
> >>>    M : Msg := Whatever;
> >>>    V : Vowelmsg;
> >>> begin
> >>>    V := Vowelmsg'Value (Msg'Image (M));
> >>>    -- if control reaches here then M is a vowel
> >>> exception
> >>>    when Constraint_Error => -- M is not a vowel
> >>> end;
> >
> > If there are no further uses of V, then I think 11.6 allows the
> > compiler
> > to eliminate the raising of Constraint_Error.  I don't much like
> > 11.6...
> >
> >> That's very, very, very slow...
> >
> > True (if it works at all).
> 
> Before I though you were complaining about the slowness of the Image
> (Value) operations (because there is probably parsing involved and
> string values on and off the stack) compared with unchecked conversion
> and 'Valid (which is very probably faster).

Well, I wasn't the one who originally complained.  When I wrote "True"
above, I was thinking of the cost of Image and Value operations (string
manipulation), which is probably much more than the precalculated-table
method I mentioned earlier.  I don't much like the U_C method here (too
kludgy), so I don't care much about its speed.

As you (or somebody) pointed out, whether Image/Value are "too slow"
depends on the program.

>... Now I realise that you were
> probably complaining about the slowness of the exception handling
> mechanism.

Well, that's an issue if there are a lot of vowels.  The speed of
Image/Value is an issue in any case.

>... In that case, my experience with GNAT is that it is not that
> slow at all. I've made controlled experiments in the past. I think I
> reported them here.

Well, whether "not that slow at all" is "too slow" depends on the
program.  ;-)  I'm pretty sure raising an exception is a lot slower than
the table lookup I suggested.  Note that my suggestion builds on yours
-- it just precalculates the Value-of-Image results.

Note that GNAT has two different exception handling methods, with wildly
different efficiency properties.  One has some overhead to enter the
handled region, and modest cost to do the "raise" (i.e. to find the
handler).  The other method has zero overhead to enter the handled
region, and *huge* cost to do the "raise".  I don't know which one you
were measuring.  I think the different methods are used on different
machines, and command-line switches can control it on some machines.

The huge-cost-for-raise is generally considered to be better, since most
programs are not like the above example -- they raise exceptions rarely.
But it's harder to implement, and impossible to implement portably.

On the other hand, if an exception is raised and handled in the same
procedure, it's pretty easy for the compiler to optimize the raise into
a single jump instruction.  I don't know if any Ada compilers do that.

On the third hand, Image and Value are probably implemented as
out-of-line calls, so that optimization probably doesn't apply.

> Now, you made me take a look at 11.6 and yes, it seems if V is not used
> it can simply hold an undefined result and the exception not raised. But
> I bet you'll get a compiler warning. And rightly so, as unused variables
> are almost certainly a logic bug. It would in this case.

I'm not comforted by that warning.  The warning probably says "V is not
used".  So the programmer (not knowing about 11.6) thinks "that's right,
and it's OK in this case", and puts in a pragma Warnings(Off).  I doubt
if the warning says "...and by the way, the compiler is planning to
generate broken machine code, as allowed by 11.6".

The example you wrote above *should* work as you expected (before you
reread 11.6).  I think 11.6 is evil.  The rest of the manual says 'Image
and 'Value raise C_E in certain cases, and tells you how to write an
exception handler for that C_E.  Then 11.6 comes along and says, never
mind all that, the compiler can generate code that does otherwise.
Most Ada programmers don't understand 11.6.  Even the people who *wrote*
11.6 (mainly me and Tucker) don't really understand it!

>... Unless Vowelmsg
> were controlled and the logic put on Adjust or something. But then the
> compiler would consider V used, no?

I don't remember the exact rules for that.  There were rules in Ada 95
that said the compiler can eliminate nonlimited controlled variables,
along with their Initialize, Adjust, and Finalize, even if those have
important effects.  But there was an AI on that, and the rules changed.

But those rules never applied to *limited* controlled types.
I often use a limited controlled variable whose only purpose is
to cause Finalize to happen.  And the compiler is not allowed to
eliminate that Finalize.  But I believe GNAT warns that the thing
is unused in this case, so I have to sprinkle pragma Warnings(Off)
around the code.  (I compile with the "treat warnings as errors"
switch.)  I also compile with AdaMagic, and I think it doesn't warn in
this case.  That's a problem with relying on warnings -- there's no
universal agreement on what deserves a warning.

- Bob

Re: Why can't you create a out of order subtype?

[Martin Dowie]

Marius Amado Alves wrote:
>>> That's very, very, very slow...
>>
>>
>> True (if it works at all).
> 
> 
> Before I though you were complaining about the slowness of the Image 
> (Value) operations (because there is probably parsing involved and 
> string values on and off the stack) compared with unchecked conversion 
> and 'Valid (which is very probably faster). Now I realise that you were 
> probably complaining about the slowness of the exception handling 
> mechanism. In that case, my experience with GNAT is that it is not that 
> slow at all. I've made controlled experiments in the past. I think I 
> reported them here.

No, I was complaining about the 'Value/'Image calls. I didn't think it 
was worth re-hashing the ol' "exceptions are slow" argument! :-)

Cheers

-- Martin

Re: Why can't you create a out of order subtype?

[Georg Bauhaus]

brett_gengler@yahoo.com wrote:
> I created a type whose order can not be rearranged and I want to create
> a subtype of that type.  So,
> 
> type msg is ( msg_a, msg_b, msg_c, msg_d, msg_e);
> 
> subtype vowel_msg is msg (msg_a, msg_e); --wrong, but why?

Not sure whether the following can lead to no Boolean
array, but anyway :-)

   subtype Consonant_Msg is msg range msg_b .. msg_d;


-- Georg

Re: Why can't you create a out of order subtype?

[Robert A Duff]

brett_gengler@yahoo.com writes:

> I created a type whose order can not be rearranged and I want to create
> a subtype of that type.  So,
> 
> type msg is ( msg_a, msg_b, msg_c, msg_d, msg_e);
> 
> subtype vowel_msg is msg (msg_a, msg_e); --wrong, but why?

Because Jean Ichbiah said so.  ;-)

> Is it true that I can't define a a subtype that's not a ordered
> subrange of a type?

It's a reasonable thing to want, but Ada does not support it.

>...My issue is that I want to enforce the subtype at
> compile time instead of creating an array of booleans and doing a run
> time check.

But subtypes in Ada are checked at run time.  So if the language
supported what you want, it would still be a run-time check.
An implicit run-time check, as opposed to the explicit code
you mention below.  It has to be a run-time check, in the general
case.

There are some cases where these things can be checked at compile time,
and some compilers give warnings in those cases.  But compilers vary in
how smart they are about warnings, and the absence of warnings does not
imply an absence of errors in the code.

>... (This is for an interface and I don't trust people to send
> me the right types).
> 
> vowel_filter is array(msg) of Boolean := (msg_a => True, msg_e => True,
> others => False);  --yuck.

You can say (msg_a | msg_e => True, others => False),
which is a little bit more concise.  You can also decide whether
to Pack the array.

But "others" is usually evil.  If you add "msg_i" later, it will be
picked up by that others.  But if you spell out "msg_b|msg_c|msg_d" now,
then when you add msg_i, you'll get a compile-time error reminding you
to decide whether or not it's a vowel.

> Another option that I think is much, much worse then the boolean array
> would be create an overloaded type...
> 
> type msg is ( msg_a, msg_b, msg_c, msg_d, msg_e);
> type vowelmsg ( msg_a, msg_e);
> 
> But as you know, msg.msg_e = 4 and vowelmsg.msg_e = 1 so an unchecked
> conversion is wrong on so many levels.

I agree -- that's not a very good solution.

> Am I screwed?  Should I just implement a boolean array and shut up
> about it?

You should probably implement the boolean array.  But you don't have to
shut up about it.  ;-)

In this particular case, you can do:

    subtype Consonant_Msg is Msg range msg_b..msg_d;
    if blah not in Consonant_Msg then ...

but there's no general way to get arbitrary subtypes of an enumeration
type.

- Bob