Re: What would you like in Ada202X?

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

On 12-05-08 03:48 , Randy Brukardt wrote:
> "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.

Maybe it wasn't clear, but anything I've said about the representation 
of the "deepened" derived enumeration types has been intended as an 
example of how it could be done, to help machine-oriented readers 
understand how the types work. I don't really care about the representation.

> That's an age-old Ada requirement (found in 13.4(8)).

So, "deepened" enumeration types are a new thing; new rules for new things.

> 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).

This is a side track, but I don't see any compelling reason (except 
compatibility) to define a standard default representation for 
enumeration types. There is no standard representation for Booleans, 
integer types, floats, records; why should enumeration types have one? 
(Is it a remnant of a C-style identification of enumerations with integers?)

Decades ago I liked to specify my own enumeration representations, but I 
would think three times before doing it today. It is only useful for 
unchecked conversions and I/O. If you use it for input, you have to mess 
about with 'Valid or exceptions. For output, there are always other 
important considerations like memory access width and byte ordering. I 
much prefer to use my own code or tables for converting between known 
external representations and unknown internal representations. This also 
avoids the rule about keeping the same order of the literals and the 
representation values.

> ...
>>> 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

I should have said "*could* be represented by...".

>> 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,

In current Ada, yes.

> which can be specified by the user.

Sure. I was giving an example of a possible default representation (if 
not by position number).

> 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.

That would be ok for me. The parent-bits/extension-bits representation 
is only an example of an alternative representation that makes the 
conversion from the derived type to the parent type fast (right-shift to 
discard the extension bits). (And it is analogous to the way tagged 
record types are extended by adding new components.)

> 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).

You could continue using this method for the "deepened" enumeration 
types, whatever representation you choose to use for them, or the user 
specifies for them.

The only new thing that the "deepened" enumeration type needs is a 
compiler-provided conversion to the parent type. The 
parent-bits/extension-bits representation would make that fast, but you 
could also use a simple table, indexed by the derived type (= position 
number), with elements of the parent type.

> ...  it's almost certain that
> implementations would use the same mechanism for this (why invent a third
> mechanism for something rarely used?).

Sure, implementations could do that. And it seems to me that supporting 
user-specified enumeration representations for "deepened" enumeration 
types would not require any new compiler mechanisms.

> It seemed like a useful idea back in the day,

I think that extending enumeration types by "deepening" is a different 
idea than the AI95-261 "widening" idea. Don't you think that they are 
logically different?

> but to be really useful, we
> need the equivalent of class-wide operations.

That is the main question: do we?

> I don't see how to do that if
> the position numbers are completely different between the various types.

I agree. It seems to me that adding class-wide operations would force to 
use some kind of tags, call by reference, and view conversions, and then 
it becomes so similar to tagged types that it is not worth it.

I think the idea of "deepened" enumeration types is worth pursuing only 
if it is useful without class-wide operations.

Another issue is that generic formal types of the "deepened" kind would 
be needed. I think that would be the next point to work on for this 
proposal.

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