4 ms·

Not sure that is the actual reason. (Also define worth it) Wirth had developed that original, but misguided (IMO) notion that the faster a compiler can compile

Not sure that is the actual reason. (Also define worth it) 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.

mananaysiempre 5y ago
I’m not sure this was the reasoning. None of the languages in the direct Algol heritage have any sort of parametric polymorphism, including for range bounds, so working with arrays (which were, at least in Pascal, the primary application of range types) was either constant and repetitive fighting with the compiler or unsafe escape hatches all the way. (Usually both.) I believed this was the primary motivation for the removal of ranges. (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.
tored 5y ago
If you read the paper, From Modula to Oberon by Wirth, I already linked in a pervious comment when answering the question about subranges, you can also find the reasoning behind the removal of enumerations. "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.3109&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.578...

mananaysiempre 5y ago

I’m not sure this was the reasoning. None of the languages in the direct Algol heritage have any sort of parametric polymorphism, including for range bounds, so working with arrays (which were, at least in Pascal, the primary application of range types) was either constant and repetitive fighting with the compiler or unsafe escape hatches all the way. (Usually both.) I believed this was the primary motivation for the removal of ranges. (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.

tored 5y ago

If you read the paper, From Modula to Oberon by Wirth, I already linked in a pervious comment when answering the question about subranges, you can also find the reasoning behind the removal of enumerations. "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.3109&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.578...