[Oberon] Why no enumeration types?

Chris Burrows cfbsoftware at gmail.com
Wed Jul 28 01:48:48 CEST 2021

On Wed, Jul 28, 2021 at 8:06 AM Claudio Nieder <private at claudio.ch> wrote:
> Hi,
> > TYPE Colors = (red, green, blue);
> >
> > Later in this module you change the enumeration to:
> >
> > TYPE Colors = (red, green, yellow, blue);
> >
> > If you don't recompile all modules that import this module, what happens with this code?
> >
> > FOR i := MIN(Colors) TO MAX(Colors) DO ... END;
> >
> > VAR table: ARRAY Colors OF BOOLEAN;
> >
> > Your program will have unexpected behaviours or will simply crash. To solve this, you have to recompile all the clients.
> Similar problems if you declare three INTEGER red=0, green=1, blue=2 and
> then change them to yellow=2, blue=3

True - but a little bit more difficult to do accidentally methinks.

I was a huge fan of enumerated types in the 1970's when I started
working with Pascal and was very proud of my extensive use of them.
However, as time went on I found their typed quality to be more of a
hindrance than a help when working with real-world data. Sooner or
later I had to input / output the values, or access their ordinal
values, or there were oddball values that didn't neatly fit in the
sequence e.g. Ace or Joker in a suit of cards for instance. Also, I
often seemed to have the need to test the grey-area boundary values
Pred(MIN(settype)) and Succ(MAX(settype) without causing a runtime

The designers of the Delphi Language (i.e. Object Pascal++) apparently
have had similar experiences. This is their solution to overcome some
of these problems:


I would describe this solution as 'Make it as complex as possible and
then even more complicated' ;-)

However, for those who liked programming in Pascal and/or Modula-2 and
find Oberon too minimal for their liking I recommend they use Delphi
instead. IMHO it is still better than any C-inspired language.

Chris Burrows
CFB Software

More information about the Oberon mailing list