Re: What would you like in Ada202X?

[Niklas Holsti <niklas.holsti@tidorum.invalid>]

On 12-05-10 09:45 , ytomino wrote:
> On Tuesday, May 8, 2012 7:34:28 AM UTC+9, Niklas Holsti wrote:
>> 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.
>
> Oops.
>
>>
>>> 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.
>>
>> That is, Message_Kind1'(Sign_On) is not the same value as
>> Detailed_Message_Kind'(Sign_On), although the latter can be converted to
>> the former (and perhaps vice versa).
>>
>> Moreover, neither the parent type nor the derived type is a subtype
>> (subrange) of the other type, in the Ada sense.
>>
>>> 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.)
>>
>>> And it's unclear about representation of "array (Detailed_Message_Kind) of ...".
>>
>> 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, the compiler could use a
>> constant array "first_pos" that is indexed by the parent bits (that is,
>> by the parent enumerated type) and gives the position number of the
>> first derived-type literal that is refined from this parent-type value.
>> The position number of any value of the derived type is then computed as
>> first_pos(parent bits) + (extension bits).
>>
>> In the example, first_pos(Message_Kind1'(Sign_On)) would be 0, for
>> Request it would be 1, for Reply it would be 3, and for
>> Message_Kind1'(Sign_Off) it would be 6.
>>
>> The value Detailed_Message_Kind'(Ack) would be represented by the parent
>> bits 2#10#, representing Reply, and the extension bits 2#01#, to show
>> that Ack is the second literal refining Reply. The position number is
>> computed as first_pos(Reply) + 1 = 3 + 1 = 4.
>>
>> Each derived type needs its own "first_pos" array, of course.

Just to avoid focusing too much on an unimportant part of the proposal 
for "deepened" enumeration types, I want to repeat here that my 
suggestions for representing such types with "parent bits" and 
"extension bits" was meant as one possibility, that could perhaps 
explain how the types are meant to work, but it is not central to the 
proposal. "Deepened" enumeration types can use the normal represention 
with position number, for all I care.

> For myself check...
>
> type Message_Kind1 is (Sign_On, Request, Reply, Sign_Off);
>
> -- Sign_On = 0
> -- Request = 1
> -- Reply = 2
> -- Sign_Off = 3
>
> type Detailed_Message_Kind is new Message_Kind1 with (
>     Request =>   (Read, Write),
>     Reply   =>   (Data, Ack, Refused),
>     others  =>   <>);
>
> (when the offset is 4 bit)
> -- Sign_On  = 16#00#
> -- Read     = 16#10#
> -- Write    = 16#11#
> -- Data     = 16#20#
> -- Ack      = 16#21#
> -- Refused  = 16#22#
> -- Sign_Off = 16#30#

Yes, that is what I had in mind if we allocate 4 "parent bits" (more 
significant nybble) and 4 "extension bits" (less significant nybble).

> X'Pos = first_pos (X'Enum_Rep / 16) + (X'Enum_Rep mod 16)

Right.

>
> type More_Detailed_Message_Kind is new Detailed_Message_Kind with (
>     Write =>  (Overwrite, Append),
>     others =>  <>);
>
> -- Sign_On   = 16#000#
> -- Read      = 16#100#
> -- Overwrite = 16#110#
> -- Append    = 16#111#
> -- Data      = 16#200#
> -- Ack       = 16#210#
> -- Refused   = 16#220#
> -- Sign_Off  = 16#300#
>
> Y'Pos =
>     More_Detailed_Message_Kind'first_pos (
>        Detailed_Message_Kind'first_pos (Y'Enum_Rep / 256)
>        + (Y'Enum_Rep mod 256 / 16))
>     + (Y'Enum_Rep mod 16)

That looks right (but it's past midnight and my eyes are crossing a 
bit). You can define the 'Pos function recursively by walking up the 
derivation path.

> I feel that you do not need to change the existing representation rule.
> Because even if Message_Kind1 has the representation clause, it's unrelated to Detailed_Message_Kind.
> It's able to keep the existing rule of root enum-types.
> And the representation of Detailed_Message_Kind is new thing, such as your saying.

I agree. But as I said, the default representation is a secondary issue, 
and I don't think that we need to define a default representation.

> (I'm only interested, not a language lawyer. I'm sorry that I couldn't help you in this discussion.)

Thanks. It's an interesting discussion. It has tempted me to champion 
this proposal more strongly than I originally intended.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .