Feature Request: Extending enumerators and hierarchies

[EganSolo]

Hi Thaddy,

Thank you for the example you gave. It will help clarify my intent a bit.
Let me reproduce it here, then I'll show how extension would work:

Code: Pascal  [Select][+][-]

1. Type
2.   myenum = (one, two, three);
3.   theirenum = (four, five, six);
4.  

Here is how Extension would work:

Code: Pascal  [Select][+][-]

1. Type
2.  myenum   = (zero,one, two, three); //added zero to keep the ordinal mapping simple.
3.  theirenum = (four five six) extends myenum;
4.  

Since the compiler knows theirenum to be an extension of myenum, it would assign the ordinals 4, 5, 6 to its elements. There would be no confusion. Extension is not an anonymous union. It carries metadata that instructs the compiler to insert a pointer in the enumerated values of theirenum, pointing to the enumerated values of myenum. As I mentioned earlier, it functions similarly to inheritance.

I hope this addresses your concerns. The mechanism for resolving and accessing the values is already in the compiler. In fact, if Pascal was fully orthogonal, then the enumerated type would have been defined as follows:

Code: Pascal  [Select][+][-]

1. Type
2.   myenum   = Enumeration[one,two,three];
3.   theirenum= Enumeration(myenum)[four,five,six];
4.  

This notation is for illustration purposes and shows quite clearly that treating the enumerated types with the same techniques we already have for managing inheritance would work.

Code: Pascal  [Select][+][-]

1. const
2.   me: MyEnum = one;
3.   te : TheirEnum = one; //works also
4.   me2: MyEnum = five; //fails
5. var
6.   m : MyEnum;
7.   t   : TheirEnum;
8. begin
9.   t   := One;
10.   m := t; //fails for type mismatch
11.   t  := m; //succeeds
12.  m := mtenum(t); //succeeds at compile time but could still throw a run-time error
13. end.
14.  

[Thaddy]

So, your new enum has different indices for the extension, changing their meaning, and that makes it, I am afraid, worthless.
Furthermore, enums are compile-time constants. You can't change them into variables.

[EganSolo]

What's worthless about different constants? The ordinal association is maintained, and the enumerated values are still constants.

Could you please provide an example that would help me better understand your concern?

[Thaddy]

Apart from the assembler output for enums, which are read only:

Code: Pascal  [Select][+][-]

1. .section .rodata.n_RTTI_$P$ENUMS_$$_DAY,"aw"
2.         .balign 8
3. .globl  RTTI_$P$ENUMS_$$_DAY
4. RTTI_$P$ENUMS_$$_DAY:
5.         .byte   3,3
6.         .ascii  "day"
7.         .quad   0
8.         .byte   1
9.         .long   0,6
10.         .quad   0
11.         .byte   6
12.         .ascii  "monday"
13.         .byte   7
14.         .ascii  "tuesday"
15.         .byte   9
16.         .ascii  "wednesday"
17.         .byte   8
18.         .ascii  "thursday"
19.         .byte   6
20.         .ascii  "friday"
21.         .byte   8
22.         .ascii  "saturday"
23.         .byte   6
24.         .ascii  "sunday"
25.         .byte   5
26.         .ascii  "enums"
27.         .byte   0

Furthermore, an external library does not even export the enum names! only the ordinal values in a set.

I would like you to look at the example I gave for the switch.

Code: Pascal  [Select][+][-]

1. type
2.   my_engine = (off,slow,fast);  //constant values 0,1,2
3.   their_enginemod = (reverse, neutral, off);//constant values 0,1,2

How will my engine behave? The code relies on their constant index.....
So after the mod it is not off but goes in reverse....

Sets, on the other hand, do have a variable nature (although they can be declared as const) but indeed require that the full range is known.
The most important part about enums is that they are ordered and their order can not change. Their member ordinal value (index) is fixed and the compiler makes them compile-time constants.

Play with this:

Code: Pascal  [Select][+][-]

1. library enumlib;
2. type
3.   myenum = (what,would, be, my, index);
4.  
5.   function enumtest:myenum;
6.   begin
7.     enumtest := index;
8.   end;
9.  
10. exports
11.   enumtest;
12. end.

Code: Pascal  [Select][+][-]

1. program enums;
2. {$mode delphi}
3. {$linklib 'enumlib'}
4. type
5.   myenum = (what,would, be, my, index);  // must be known....
6.  
7. function enumtest:myenum; externaL;
8.  
9. begin
10.   writeln(enumtest);
11. end.

And tell me what happens?
Your main program needs to know the full enum to work as enum, now, doesn't it?
Otherwise you'll end up with

Code: Pascal  [Select][+][-]

1. program enums2;
2. {$mode delphi}{$linklib 'enumlib'}
3. function enumtest:integer; externaL;
4.  
5. begin
6.   writeln(enumtest);
7. end.

Still works without enum, gives the index(4) instead.
That is because an enum is an ordinal value.

I can't make it any clearer than this.

Bonus lib:

Code: Pascal  [Select][+][-]

1. library enumlib2;
2. type
3.   // can't export a type!
4.   myenum = (what, would, be, my, index);
5. var
6.   // can export a set! but enum type needs to be known at the other side
7.   enumset:set of myenum = [what,would, be, my, index];export name 'enumset';
8.  
9. exports
10.   enumset;
11. end.