Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site rtp47.UUCP
Path: utzoo!watmath!clyde!bonnie!akgua!mcnc!rti-sel!rtp47!throopw
From: throopw@rtp47.UUCP (Wayne Throop)
Newsgroups: net.lang.mod2
Subject: Re: large SETs desired
Message-ID: <212@rtp47.UUCP>
Date: Wed, 9-Oct-85 14:56:18 EDT
Article-I.D.: rtp47.212
Posted: Wed Oct  9 14:56:18 1985
Date-Received: Sat, 12-Oct-85 19:23:45 EDT
References: <43@noscvax.UUCP> <12107@rochester.UUCP>
Organization: Data General, RTP, NC
Lines: 58

> In the posting of the reference, the problem of supporting reasonably 
> large sets is considered.  A comment is also made as to BITSETs being
> a good starting point for that.  I want to add a few of my own opinions,
> in the hope of public scrutiny. 

Ditto.

> Sets are a Good Thing To Have only if you can manage to use them without
> undue hassle.

Agreed.  However, I think that you are a little pessimistic about what
constitutes "undue hassle" (for the compiler writer).

> Pascal first and the Modula2 provide powerful *paper* set
> types, that become much less useful thanks to not being supported beyond
> the width of a machine's word (just a few elements).

Your tack seems to be that supporting sets beyond a machine word is hard
for the compiler, and that sets should therefore be dropped.  I
disagree.  I don't find implementing multi-word sets to be any more
difficult than implementing, say, complex arithmetic.  FORTRAN has had
that for years, and nobody thinks of it as unreasonably hard to do.

> Doing Sets right in all their
> glory is hard.  In some broad sense, it is similar from doing strings right.
> Representations that are good for one application slow down another and 
> the decision is hard (or impossible) to make statically (at compile time).
> So it is almost sure that a good number of applications will end up requiring
> a different set implementation.

This is true.  But consider substituting "floating point numbers"
for "sets" in the above.  After all, most languages implement a single
format of floating point number (sometimes with a choice of mantissa
length).  Sometimes this just won't serve the needs of developers,
because they need an extended exponent range, or they need different
error-propogation behavior, or they need 16-bit floats for space
economy, or whatever.  I don't take this to mean that languages
shouldn't support floating point numbers.  Nor do I think the above
paragraph shows that sets should not be included in "primitive" language
features.

> Saying that
> *sets* are a good mechanism to handle *bits* is going backwards atrociously.

Also true.  However, I think that languages should support *both* sets
and bit strings as primitive notions.  Just because A can be implemented
using B is no reason for a language not to support A.  Some examples are
that characters can be implemented using integers and complex numbers
can be implemented using floats.  In neither case do I take this to be
an argument that characters or complex numbers should not be supported.

Similarly, I think that supporting arbitrary-length sets is a reasonable
thing for a language to do, and further that Modula "ought to have" done
it.

> Cesar Augusto  Quiroz Gonzalez   {allegra|seismo}!rochester!quiroz
-- 
Wayne Throop at Data General, RTP, NC
<the-known-world>!mcnc!rti-sel!rtp47!throopw