Enumeration representation enhancement proposal

Enumeration representation enhancement proposal

[Wojtek Narczynski]

Hello,

Enumeration representation in their current form are not very useful,
because there is no treatment of invalid values. That's why constants, and
constant to enum mapping arrays are used so heavily in real interfacing
code.

Invalid external values are rather norm than exception, thus they deserve
'non-exceptional' treatment. The 'Valid attribute alleviates the problem,
but it is not very convenient, for example won't work in case statements,
it requires to have two different ways to log the value (valid and invalid).

Maybe this could be improved in Ada 2005? For example:


type Mix_Code is (Red, Green, Blue, Grey);

--  Modest proposal

for Mix_Code use (Red => 1, Green => 2, Blue => 3, Grey => others);

This should be relatively straightforward to implement, and would cover
most needs.

However...

--  Die-hard proposal

for Mix_Code use
  (Red => 1 | 10, Green => 11 .. 20, Blue => 21 .. 30 | 40, Grey => others);


An unambiguous mapping from the rep value to Ada enum would be required,
not the other direction.

Regards,
Wojtek

Re: Enumeration representation enhancement proposal

[Nick Roberts]

Wojtek Narczynski wrote:

> Enumeration representation in their current form are not very useful,
> because there is no treatment of invalid values. That's why constants,
> and constant to enum mapping arrays are used so heavily in real
> interfacing code.

I tentatively agree with this sentiment. However, I suspect that making
enumeration types more 'useful' could be difficult.

> Invalid external values are rather norm than exception, thus they
> deserve 'non-exceptional' treatment. The 'Valid attribute alleviates
> the problem, but it is not very convenient, for example won't work in
> case statements, it requires to have two different ways to log the
> value (valid and invalid).
> 
> Maybe this could be improved in Ada 2005? For example:
> 
> type Mix_Code is (Red, Green, Blue, Grey);
> 
> --  Modest proposal
> 
> for Mix_Code use (Red => 1, Green => 2, Blue => 3, Grey => others);
> 
> This should be relatively straightforward to implement, and would cover
> most needs.

The problem with this proposal it that (actual) values of the type would
no longer satisfy the ordering criteria (that a machine < or > test will
always have the same result as the corresponding canonical test).

> However...
> 
> --  Die-hard proposal
> 
> for Mix_Code use
>   (Red => 1 | 10, Green => 11 .. 20, Blue => 21 .. 30 | 40, Grey => others);
> 
> An unambiguous mapping from the rep value to Ada enum would be required,
> not the other direction.

This idea seems to stir up a hornet's nest of difficulties. I also suspect
that if the ordering property were still required, it wouldn't often be
useful in practice. I think I'd rather construct a type with explicit
operations to deal with this sort of situation; this approach does give
complete control over the translation between (actual) value and meaning.

But this is just my opinion!

Unfortunately, I believe it is now too late for any new proposals for
Ada 2005. I think there is just one more ARG meeting before they must put
their recommendation to WG9 (the committee of representatives of the
respective members of ISO delegated to deal with the Ada language). WG9
will vote on each amendment proposal, and they will (almost certainly)
reject any proposal that they feel has not been properly developed. (In
other words, crunch time.) I'm not quite sure about the schedule TBH.

-- 
Nick Roberts

Re: Enumeration representation enhancement proposal

[Wojtek Narczynski]

>> Maybe this could be improved in Ada 2005? For example:
>> 
>> type Mix_Code is (Red, Green, Blue, Grey);
>> 
>> --  Modest proposal
>> 
>> for Mix_Code use (Red => 1, Green => 2, Blue => 3, Grey => others);
>> 
>> This should be relatively straightforward to implement, and would cover
>> most needs.
> 
> The problem with this proposal it that (actual) values of the type would
> no longer satisfy the ordering criteria (that a machine < or > test will
> always have the same result as the corresponding canonical test).

I don't follow, could you provide a sample Ada code which would be
problematic?

Regards,
Wojtek

Re: Enumeration representation enhancement proposal

[Jacob Sparre Andersen]

Wojtek Narczynski wrote:

> >> Maybe this could be improved in Ada 2005? For example:
> >> 
> >> type Mix_Code is (Red, Green, Blue, Grey);
> >> 
> >> --  Modest proposal
> >> 
> >> for Mix_Code use (Red => 1, Green => 2, Blue => 3, Grey => others);
> >> 
> >> This should be relatively straightforward to implement, and would
> >> cover most needs.
> > 
> > The problem with this proposal it that (actual) values of the type
> > would no longer satisfy the ordering criteria (that a machine < or
> > > test will always have the same result as the corresponding
> > canonical test).
> 
> I don't follow, could you provide a sample Ada code which would be
> problematic?

  for Colours use (Red => 1, Green => 2, Blue => 4, Muddy => others);

  if Muddy < Blue then
     --  Do we ever get here?  Both 3 and 5 represents Muddy.  The one
     --  is smaller than 4 (which represents Blue), the other one
     --  isn't.  end if;
  end if;

Greetings,

Jacob
-- 
"Only Hogwarts students really need spellcheckers"
                                -- An anonymous RISKS reader

Re: Enumeration representation enhancement proposal

[Wojtek Narczynski]

Hello,

>> I don't follow, could you provide a sample Ada code which would be
>> problematic?
> 
>   for Colours use (Red => 1, Green => 2, Blue => 4, Muddy => others);
> 
>   if Muddy < Blue then
>      --  Do we ever get here?  Both 3 and 5 represents Muddy.  The one
>      --  is smaller than 4 (which represents Blue), the other one
>      --  isn't.  end if;
>   end if;

(I may be repeating myself, my previous reply somehow didn't make it to
the server...)

Clearly, representation has no impact on comparison. So we do not get
there, granted that such is the order of declaration in Ada.

The above code is not harder to compile than:

for Colours use (Red => 1, Green => 3, Blue => 2, Muddy => 4);

A, B : Colors;

if A < B then null; end if;

Here the result is also rather unrelated to the underlying rep values
order.

Also, a simple "cannonicalization" {take the least possible 'others'
value to the register (not memory)} makes the case with 'others' identical
to current situation.

Regards,
Wojtek

Re: Enumeration representation enhancement proposal

[Jacob Sparre Andersen]

Wojtek Narczynski wrote:

> >   for Colours use (Red => 1, Green => 2, Blue => 4, Muddy => others);
> > 
> >   if Muddy < Blue then
> >      --  Do we ever get here?  Both 3 and 5 represents Muddy.  The one
> >      --  is smaller than 4 (which represents Blue), the other one
> >      --  isn't.  end if;
> >   end if;
> 
> Clearly, representation has no impact on comparison.

Wrong.

> So we do not get there, granted that such is the order of
> declaration in Ada.
> 
> The above code is not harder to compile than:

procedure Enumeration_Representation is
   type Colours is (Red, Green, Blue, Muddy);
> for Colours use (Red => 1, Green => 3, Blue => 2, Muddy => 4);
> 
> A, B : Colors;
begin
> if A < B then null; end if;
end Enumeration_Representation;

Is not correct Ada.  The LRM clearly states (can't remember where,
though) that the order of the representation should be the same as
that of the original declaration of the enumeration.

> Here the result is also rather unrelated to the underlying rep
> values order.

Except that your code isn't valid Ada.

> Also, a simple "cannonicalization" {take the least possible 'others'
> value to the register (not memory)} makes the case with 'others'
> identical to current situation.

But computationally slower. - Which I suspect is the whole reason for
the order rule for enumeration representations.

Jacob
-- 
"[...] *transfer* a bit of salary from the person who writes
 a bug to the person that finds a bug..." -- Keith Ray

Re: Enumeration representation enhancement proposal

[Wojtek Narczynski]

Hello,

>> Clearly, representation has no impact on comparison.
> 
> Wrong.

> Is not correct Ada.  The LRM clearly states (can't remember where,
> though) that the order of the representation should be the same as
> that of the original declaration of the enumeration.

You are right, I am wrong. I suppose I've never run into this, because
I've used enum rep very rarely, because it is not very useful...

I don't have an idea on how to fix it well, then.

Thanks taking taking the time to explain me.

Regards,
Wojtek