🚀 go-pugleaf

In article <1992Nov11.102409.12183@jyu.fi>, sakkinen@jyu.fi (Markku Sakkinen) writes:
> In article <5897@balrog.ctron.com> smith@ctron.com writes:
> >In article <9211091022.A01745@MAIL.CASI.NASA.GOV>, thutt@MAIL.CASI.NASA.GOV (thutt) writes:
> >> ...
> >I wouldn't classify enumerations as "superfluous", their removal is a real
> >loss.  But I think the real reason they went was because they are so difficult
> >to type-extend.  Type-extension is Oberon's "thing", and it would be most
> >difficult to set up a mechanism wereby various enumerations were derived from
> >previously-defined enumerations, where certain identifiers are valid for all,
> >but not all identifiers are.
> 
> That has obviously been the main reason for eliminating enumerations.
> And even this rationale is very weak.  Only record types can be extended
> in Oberon, not atomic types nor arrays.

Extending atomic types or arrays is completely different from extending
records which usually represent abstractions. Records are sufficient
and the implementation of record extensions is straightforward and efficient.

The main problem is to assure extensibility of existing software. This
is done in Oberon by extending given abstractions to your problem which
allows your new data types to be processed by software written earlier.

In some cases enumeration types tend to prohibit extensibility if they
are exported. Nevertheless, it would be possible to include them
in Oberon in Modula-2 manner without great trouble.

Possible extensions of arrays and atomic types would like other
features (e.g. exceptions or whatever) make life more difficult: for
the language designer, the compiler constructor and, of course, the
programmer which would have to read a 600-pages Modula-Standard style
manual. Don't forget that Oberon still needs less than 20 pages of
language description.

As long as it is possible to formulate problems in a elegant manner in
Oberon we don't need to blow up the language. Try to view your libraries
itself as extensions of the language and you get all what you need:
extensible arithmetic data types, exceptions (which need coroutines
of course, but at least my implementation has them) or whatever.

Don't forget, Wirth's primary design goal was: "Make it as simple as
possible. But not simpler."

> >>      c) generic SET OF: Since there is no enumeration, what are you to make
> >>      a set from?  The SET type is now equivalent to the M-2 BITSET. It is of
> >>      an implementation dependant size (usually at least 32 bits).
> >
> >This was Wirth not going far enough.  Without enumerations, sets really have
> >little utility or expressiveness over bit-pushing operators like C's.  SETS
> >could have been axed in favor of a slight extension of the INTEGER type.
> 
> I don't agree, especially since C has not got bit arrays.
> But set types have always been sadly crippled in
> Wirth's languages:  Pascal implementers are not required to support
> even the the full CHAR type as the base type for SET OF CHAR,
> not to speak of true SET OF INTEGER.  Fully-fledged set types could often
> be useful abstractions in programming.

Wirth's aim was always to avoid putting algorithms into the language
which could be expressed by the language itself. Having a basic set type,
you are able to build up arbitrary set types which work efficiently.

> >>      e) DEFINITION & IMPLEMENTATION merged.  Exported identifiers are
> >>      marked with a *.  Read-only exported variables are marked with a -.
> >>      Let us hope they make a read-only VAR parameter, which would be
> >>      useful for exported procedures that take a VAR parm for efficiency.
> >>      The programmer using the procedure would be guaranteed that the
> >>      parameter is not modified!

VAR-parameters which are readonly for efficiency purposes doesn't make
much sense because this is a problem of code optimization. Requests
like this could be easily extended to the horrible register declarations
of C!

I agree with all people which prefer the separation of DEFINITION and
MODULE. The first version of Oberon as published in Software Practice
and Experience was still separated and I still prefer this version
in comparison to all later versions (with the exception of some
syntactical clean ups).

> I have read somewhere that the parameter modes were variable vs. constant
> in an early version of Pascal.  That would have been much better
> than the current by-value vs. by-reference distinction (which should be left
> as an implementation issue)!

The choice between by-value and by-reference as an implementation issue? 
Sounds not reasonable -- probably I've missed your point.

> >This was a really bad move.  Now you can't define the interface separately
> >and enforce it, and the "*" and "-" stuff is really kludgy, very atypical
> >of Wirth's work.  Even if you accept that merging the def and imp is good,
> >interface details like READONLY really deserve their own keywords.
> 
> Field-width denoters in the calls of the READ and WRITE quasi-procedures
> of Pascal spring to mind as a worse syntactic kludge, but it is
> nevertheless atypical.

I agree. Programs should be readable but not cryptical.

-- 
_______________________________________________________________________________

Andreas Borchert, University of Ulm, SAI, D-W-7900 Ulm, Germany
Internet: borchert@mathematik.uni-ulm.de