🚀 go-pugleaf

Pascal's set constructors are untyped, and there are cases where context iss
insufficient to determine at compile time the boundaries of a set.

Most implementations thus implement sets of some small, fixed, size (like 16,
32, 128, or 256 elements).  The UCSD implementations go to some pains to allow
dynamically sized sets up to 4096 elements (8-bit microcomputers can deal with
256 16-bit words without too much grief).

Modula-2's set constructors are typed, and therefore the size of the set is
always known at compile time.

Many implementations nonetheless implement sets as the word size of the
machine, because then it's easy to generate single machine instructions.  It
is not hard  to implement sets of effectively unbounded size; further, it is
usually more efficient, and certainly more readable and useful to have large
sets than to simulate this with the corresponding user code.

One can only hope that the eventual ISO standard will say something useful
about sets, like you can have at least as many elements as, say, MAXINT.  But
people who haven't implemented such tend to vote against inclusion of such
language, so don't count on it.

- Joel McCormack {ihnp4 decvax ucbvax allegra}!decwrl!joel
		 joel@decwrl.dec.com

	At present, _All_ (or almost all) Modula-2 compilers have _only_
16-element bitsets, because that is how Der Verehrter Herr Doktor Professor
wanted it, and enshrined it in the language definition.
	(Whenever he is challenged about one of the many inadequacies of the
language, he replies that given the point he wanted to prove and the resources
he has {slaves... errr, graduate students} at ETH, some choices had to be
made, and, besides, that is a mere matter of implementation which can be easily
handled in a separate module.)
	The latter is certainly true -- there are at least two commercially-
available 'longset' modules that I have seen, which overcome the 16-element
set problem -- both are for Logitech's MS-DOS Modula, but do have source
available, so should port directly to most other machines . . .

	The British Standards Institute Modula-2 Standardisation effort is
working on changing the language definition to open up sets to at least
include enough memebers to define SET OF CHAR.  Progress is being made at a
glacial pace on this . . .
-- 
Sam'l Bassett, Writer/Editor/Consultant -- ideas & opinions mine!
34 Oakland Ave., San Anselmo  CA  94960;  (415) 454-7282
UUCP:  {...known world...}!hplabs OR ptsfa OR lll-crg!well!samlb;
Compuserve:  71735,1776;  WU Easylink ESL 6284-3034;  MCI SBassett

In article <8709142056.AA10394@vulcan.dec.com> joel@DECWRL.DEC.COM writes:
>...
>Modula-2's set constructors are typed, and therefore the size of the set is
>always known at compile time.
>
>Many implementations nonetheless implement sets as the word size of the
>machine, because then it's easy to generate single machine instructions.  It
>...
>- Joel McCormack {ihnp4 decvax ucbvax allegra}!decwrl!joel
>		 joel@decwrl.dec.com

I was totally shocked to see how Wirth handled BITSET in the MODULA-2
definition.  He makes the effort in the language design to require
system dependent modules to identify themselves by containing imports
from SYSTEM.  Then, instead of BITSET being defined in SYSTEM we find
that it is a STANDARD type and its import is PERVASIVE!!??
Furthermore, a set with unspecified type has type BITSET.

A set is a perfectly abstract concept that has nothing to do with
machine structures.  Yes, it has to be implemented on a machine, but
it you go to the trouble to provide it at all it shouldn't have
artificial restrictions.  Also, if there is going to be a default
set type I think it makes much more sense to make it
	SET OF CHAR;

I am not condemning the language though.  I like MODULA-2 very much.
I even like case dependent identifiers (although, I'm not thrilled
with UPPERCASE KEYWORDS).  I always use the compiler option that
enforces use of the standard language.

Cheers,
Hal Chambers

>It
>is not hard  to implement sets of effectively unbounded size; further, it is
>usually more efficient, and certainly more readable and useful to have large
>sets than to simulate this with the corresponding user code.

Right! In addition to that you cannot use operators like +, -, /, *,
IN and { ... } on larger sets implemented as user data types, they are
*nonportable* and *inefficient*. Built-in Modula-2 sets are
syntactically much better than Pascal's sets. It is unfortunate that
they are so poorly implemented.

As existing Modula-2 compilers usually don't allow large sets, you
cannot even write a (portable) compiler that uses the method of
passing sets of stopping symbols as parameters to the parsing
procedures. This method is used for error recovery in many Pascal
compilers (written in Pascal).

And how about being able to say: VAR screen[8000H]: SET OF [0..768*512-1] ?

The potential applications of large sets are numerous.

>	The British Standards Institute Modula-2 Standardisation effort is
>working on changing the language definition to open up sets to at least
>include enough memebers to define SET OF CHAR.  Progress is being made at a
>glacial pace on this . . .

Sarcastically you could imagine the following reasoning behind this
decision:
"These one-word sets, aren't they a little too restricting? Let's
represent sets as the bits of an *array* of words."
"Yes, but let's not generalize too much: surely there must be some upper
limit on the size of this array. Shall we say *four* 32-bit words?"

The point is: because the size of the set is always known at compile
time, the size of this array can also be determined at compile time.
If you only use small sets that fit in one word, then you don't even
need an array: *no* runtime overhead.  Even indexing the array can be
efficient, on a 32-bit machine, divide the number of the bit to be
tested/included/excluded/etc. by 32, that is, shift the bits five
places to the right. And if you are accessing a constant member of the
set then you don't even have to do that, the compiler can figure out
the address of the word in which to look for the appropriate bit.

-----------------------------------------------------------------------
Johan Myreen			UUCP:     ...!mcvax!hutcs!jem
Bistervagen 6 B 416             Bitnet:   jem%hutcs.uucp@fingate.bitnet
SF-02150 Esbo, Finland          Internet: jem@hutcs.hut.fi