Xref: utzoo comp.lang.modula2:662 comp.lang.misc:1103
Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!decwrl!decvax!mcnc!xanth!kent
From: kent@xanth.cs.odu.edu (Kent Paul Dolan)
Newsgroups: comp.lang.modula2,comp.lang.misc
Subject: Re: From Modula to Oberon
Message-ID: <4291@xanth.cs.odu.edu>
Date: 28 Feb 88 21:17:21 GMT
References: <7161@sol.ARPA>
Reply-To: kent@xanth.UUCP (Kent Paul Dolan)
Organization: Old Dominion University, Norfolk Va.
Lines: 58
Keywords: maintainability
Summary: almost


Moderately enraged response; add salt!

The definition of Oberon looks, in the main, like a win, but somehow the
baby went out with the bathwater!

After a couple decades of using integers to encode concepts in FORTRAN
and many other tongues, enumerated types were a gift from the dieties
of programming; they rid the code of magic numbers, made it more
readable and maintainable, and lessened dramatically the chance of
coding errors.  Since the automatic import of a type and all its named
constants was already eliminated for Oberon, the explicit
qualification of imported objects should have removed any
implementation problems here.

That is, if module A defines enumerated type a with constants p and q,
and module B extends this to type b with additional constants r and s,
and module C extends b to type c with added constant names t and u,
surely in module C I can say:

	A.a.p
	A.a.q
	B.b.r
	B.b.s
	C.c.t, c.t or t
	C.c.u, c.u or u

without any ambiguities?  Where was the compelling need to eliminate
this very valuable feature?  Note that I assume here that we do NOT
allow renaming, so that B must make the definitions imported from A
visible to C, if C is to import them from B, and that this is exactly
textually equivalent to C importing them from A directly.

I really, really, really don't want to backslide to programs full of
anonymous small integers which are really not arithmetic integers at
all, but only cryptic encodings for logical problem space concepts
which should have names, and the C language #define alternative makes
me quite nauseous with all the #include conflicts that arise in trying
to use this facility.

Also, as another issue, if words, bitsets, and similar implementation
hardware explicit concepts leave the standard language, then in the
field of operating systems design, I would appreciate strengthening of
the definition of sets, in the ways most implementations of Modula-2
have chosen to extend the language.

Also, some language mechanism should (IMHO) be added to indicate that
a piece of storage should be extended to the next boundary for
convenient hardware access (i.e., if I define a set type of a size to
require 7 bits, I should be able to force instances of elements of its
powerset to extend to a multiple of the size of a character, short
integer, integer, long integer, or pointer for execution efficiency,
without being too bothered about just how big any of the latter items
are in this particular hardware.  I'm sure others would be just as
interested in the opposite facility, to pack the elements for storage
efficiency.

Kent, the (just an old coder, no language design expert) man from xanth.