Re: Extensible Enummerated types FW: When will next Ada revision be? (83, 95, ?)

["Nick Roberts" <nickroberts@callnetuk.com>]

Following the lead from another poster to this thread, my proposal (and I
think this is what the other poster intended) involves no tagging, but is
simply as follows. I believe this proposal would be doable and valuable.

Let's start with a normal enumeration type declaration, in unit PC_Keyboard:

   type Key_Value is (A_Key, B_Key, ..., Scroll_Lock);

My proposal is that you can make an 'enumeration extension declaration' in
any declarative region (AT_Keyboard, say) that has visibility of
PC_Keyboard.Key_Value, perhaps like this:

   type Key_Value is new PC_Keyboard.Key_Value with (F11, F12, ...);

Type AT_Keyboard.Key_Value would be in essence an ordinary enumerated type,
with all the values of PC_Keyboard.Key_Value plus the extra ones specified
(positionally appended). There would be no tag or special indexing. Any
representation clause could be applied to it (e.g. changing its size or
internal codes). It may need to be made a bigger size (by the compiler if
not explicitly) as a result of having more values.

One extra rule would be that if PC_Keyboard.Key_Value had an enumeration
representation clause (defining its internal codes), then the compiler would
demand that AT_Keyboard.Key_Value had one as well (which would have to be
comprehensive). I believe the rule (in RM95 13.4(6)) which forces the
internal codes to obey the predefined ordering relation should be removed
(the compiler would, again, have to use a lookup table if necessary, tough).

Some operations would be redefined or added.

Conversion from PC_Keyboard.Key_Value to AT_Keyboard.Key_Value would pose no
problems (a change of representation may require actual conversion, but this
is something Ada already supports).

Conversion the other way would also be supported, and would include a check
that the value being converted lay within the set of values defined for
PC_Keyboard.Key_Value (which would raise Constraint_Error if it failed).

There would be overloadings of the "in" operator which allowed a test for a
value of one type against a range of the other type, or any subtype thereof.

The other operations would all be exactly the same.

Plainly, this example declares some extra keys for an AT keyboard, implying
that an AT keyboard has at least all the same keys as a PC keyboard. It is
better than explicitly redefining all the many PC keys, since there is
clearly room for an error creeping in there. It's a better model against the
real world. It also simplifies the conversion from one type to another,
possibly eliminating another source of error. The implementation would be
exactly the same as if one had defined all the values for
AT_Keyboard.Key_Value explicitly, apart from the new and different
operations (whose implementations are straightforward), and the extra simple
rule. QED.

PS: Yes I realise that there's not going to be a revision so this kind of
idle speculation is pointless, and yes I realise people with nohing better
to do ;-) will have a field day picking it apart. Sigh.

--
Nick Roberts
http://www.AdaOS.org