Re: What would you like in Ada202X?

["Randy Brukardt" <randy@rrsoftware.com>]

"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
news:a0r0vkFb94U1@mid.individual.net...
> On 12-05-07 09:33 , ytomino wrote:
>> It's interesting.
>>
>> What would happen to 'Pos and 'Val ?
>
> They would work in the normal way for enumeration types, just as if the 
> parent type and the derived type were declared separately, without 
> derivation.
>
>>>   type Message_Kind1 is (Sign_On, Request, Reply, Sign_Off);
>>>   type Detailed_Message_Kind is new Message_Kind1 with (
>>>        Request =>  (Read, Write),
>>>        Reply   =>  (Data, Ack, Refused),
>>>        others  =>  <>);
>>
>> First, Message_Kind1'Pos (Sign_On) = 1, Request = 2, Reply = 3, Sign_Off 
>> = 4, of course.
>
> That should be 0, 1, 2, and 3. 'Pos starts from zero.
>
>> 1) To keep order, Detailed_Message_Kind'Pos (Read) = 2, Write = 2.5 
>> (float!)
>
> No, I would make the 'Pos values for Detailed_Message_Kind be the normal 
> ones for its list of literals: Detailed_Message_Kind'Pos for Sign_On is 0, 
> for Read it is 1, for Write it is 2, for Data it is 3, for Ack it is 4, 
> for Refused it is 5, and for Sign_Off it is 6.
>
> I don't see any reason to keep the same position number for the "same" 
> literal of Message_Kind1 and of Detailed_Message_Kind. Although the 
> literals have the same identifier, they are not the same value.

But the representation of an enumeration type is its position number, unless 
otherwise specified. That's an age-old Ada requirement (found in 13.4(8)). I 
suppose you could drop it, but then a complete replacement would have to be 
defined and that would be complex (and less than useful).

...
>> It seems difficult to realize keeping operator "<",">" and keeping
>> Message_Kind1'Pos (X) = Detailed_Message_Kind'Pos (X) at same time.
>
> The code for the relational operators "<" and ">" would use the 
> representation, not the position number. I suggested that values of the 
> derived type would be represented by some "parent" bits that represent a 
> value of the parent type, and some more "extension bits" to separate the 
> refining literals from each other. If these bits are packed in a word, 
> with the extension bits less significant than the parent bits, ordinary 
> integer comparison instructions can implement "<" and ">" for the derived 
> type. (This is just like lexicographic ordering.)

This makes no sense, since enumerations have well-defined representations, 
which can be specified by the user. And it provides no value that I can see, 
since a compiler is going to have to support conversions to/from these 
enumerations that have user-defined representations anyway. So the only way 
to do the conversions is is with a lookup table.

Moreover, I can't speak for other compilers, but Janus/Ada uses the position 
number for all operations; the only use of the representation is to 
read/store from memory. So the representation is completely irrelevant for 
implementing operations. (We wouldn't even need to enforce the 
representation ordering rules, but of course we do because they're required 
by the language.) We couldn't find any reasonable way to support operations 
like indexing and looping and still support arbitrary representations with 
missing values (holes if you will).

>> And it's unclear about representation of "array (Detailed_Message_Kind) 
>> of ...".

Arrays in Ada should not have holes, so the representation would surely not 
change.

> The array index would be the position number, as usual. The position 
> number can be computed from the representation with parent bits and 
> extension bits. To make this computation fast,

This isn't happening, because of the need to support user-specified 
representations. That's not "fast", and it's almost certain that 
implementations would use the same mechanism for this (why invent a third 
mechanism for something rarely used?).

...
>> However, I too want to use this extensible enum if you have a nice 
>> solution.
>
> Two votes in favour, interesting!

It seemed like a useful idea back in the day, but to be really useful, we 
need the equivalent of class-wide operations. I don't see how to do that if 
the position numbers are completely different between the various types. So 
I'm dubious, but we have a long time before any of this is going to be 
adopted, so perhaps improvements can be made.

                                    Randy.