Re: Enumeration representation enhancement proposal

[Jacob Sparre Andersen <sparre@nbi.dk>]

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