🚀 go-pugleaf

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.

> ...
>>      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.

>> ...
>>      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!

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)!

>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.

----------------------------------------------------------------------
Markku Sakkinen (sakkinen@jytko.jyu.fi)
       SAKKINEN@FINJYU.bitnet (alternative network address)
Department of Computer Science and Information Systems
University of Jyvaskyla (a's with umlauts)
PL 35
SF-40351 Jyvaskyla (umlauts again)
Finland
----------------------------------------------------------------------