Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site noscvax.UUCP
Path: utzoo!linus!decvax!ittatc!dcdwest!sdcsvax!noscvax!broman
From: broman@noscvax.UUCP (Vincent P. Broman)
Newsgroups: net.lang.mod2
Subject: Re: large SETs desired
Message-ID: <64@noscvax.UUCP>
Date: Fri, 18-Oct-85 17:52:58 EDT
Article-I.D.: noscvax.64
Posted: Fri Oct 18 17:52:58 1985
Date-Received: Sun, 20-Oct-85 09:09:13 EDT
References: <43@noscvax.UUCP> <12107@rochester.UUCP> <212@rtp47.UUCP> <132@nbires.UUCP>
Organization: Naval Ocean Systems Center, San Diego
Lines: 32

> I'll also go along with the position that multi-word sets are not that hard
> to implement.  In a project using a language based on Pascal some years...
> 	- First, the basetype of a set was required to be evident from its
> 	  left context.  This was due in part to the simplistic analysis in
> 	
> 	- Second, set types were considered distinct if their basetypes
> 	  were distinct.  This avoids the problems associated with
> 	  performing set operations on sets with, say, disjoint basetypes
> 	  which are nonetheless subranges of the same parent type.  This is
> -- 
> Dick Dunn	{hao,ucbvax,allegra}!nbires!rcd		(303)444-5710 x3086
>    ...Simpler is better.


I suspect that the difficulties in Doing Strings Right, lie mainly in their
having dynamically varying lengths, and in the lack of typename for string
literals and expressions. Modula2 allows large SETs to be Done Right, in all
their glory, because SET literals and expressions have types and basetypes
easily known at compile time, as a result of Wirth's choice of syntax:
"settypename{elt,elt,...}" for any thing but a BITSET, ... a clear winner.

BTW, the intended domain of application for Modula2 seems to me to embrace
general-purpose programming of single-processor computers, including
systems work, numerics, CAD, etc. I think so because Lilith was designed to
run on M2 alone, no f77, C, or anything else as auxilliary.
A good implementation of Modula2 would give Ada a good run for its money
in generality of application, save the area of real-time programming only.

Vincent Broman   (619) 225-2365      MILNET: broman@nosc
Analysis Branch, code 632            UUCP: {ihnp4,decvax,akgua,dcdwest,
Naval Ocean Systems Center               allegra,ucbvax}!sdcsvax!noscvax!broman
San Diego, CA  92152                 ICBM: 32deg 42min N / 117deg 14min W