"Enumeration types appear to be a simple enough feature to be uncontroversial. However, they defy extensibility over module boundaries. Either a facility to extend given enumeration types has to be introduced, or they have to be dropped. A reason in favour of the latter, radical solution was the observation that in a growing number of programs the indiscriminate use of enumerations(and subranges) had led to a type explosion that contributed not to program clarity but rather to verbosity. In connection with import and export, enumerations give rise to the exceptional rule that the import of a type identifier also causes the (automatic) import of all associated constant identifiers. This exceptional rule defies conceptual simplicity and causes unpleasant problems for the implementor."
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.578...
(Of course, it’s literally impossible to make polymorphic range bounds work completely, due to the undecidability of Peano arithmetic. The most convincing attempt I’ve seen that doesn’t just go full dependent types on you is ATS, and even that is not exactly the friendliest of environments.)
Another system whose evolution was explicitly guided by self-compilation speed is Chez Scheme, and it’s a fine one. Generally it seems to me that it’s a valid optimization principle, but not a global one: you can fall into an unfortunate local minimum if you start in the wrong place. ... Well, so what, it’s not like there are any infallible design principles in programming.
Wirth had developed that original, but misguided (IMO) notion that the faster a compiler can compile itself the better it is.
Consequently he has removed a lot from latest iterations of its languages/compilers
Pascal had an enum-like feature we could define an enumerated type.
Wirth removed it because... `CONST` should be enough for everyone.
Obviously it has simplified the compiler and increased the self-compilation speed. But I would not call that an improvement.