Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site rochester.UUCP
Path: utzoo!linus!decvax!ucbvax!ucdavis!lll-crg!seismo!rochester!quiroz
From: quiroz@rochester.UUCP (Cesar Quiroz)
Newsgroups: net.lang.mod2
Subject: Re: large SETs desired (followup)
Message-ID: <12265@rochester.UUCP>
Date: Thu, 10-Oct-85 22:33:11 EDT
Article-I.D.: rocheste.12265
Posted: Thu Oct 10 22:33:11 1985
Date-Received: Sat, 12-Oct-85 07:24:43 EDT
References: <43@noscvax.UUCP> <12107@rochester.UUCP> <1982@reed.UUCP>
Reply-To: quiroz@rochester.UUCP (Cesar Quiroz)
Distribution: net
Organization: U. of Rochester, CS Dept.
Lines: 53
Summary: M2 is a systems programming language.  No sieves here!

From article <1982@reed.UUCP> (bart@reed.UUCP (Bart Massey)):
> ...
>The other referenced poster says that he thinks set ops should be
>extrinsic to the language, and so should strings.
>
>I don't think I buy it for M2, for the simple reason of code legibility.
>For sets as a mathematical construct, like numeric expressions (another
>place where "a lot of tradeoffs are made"), OPERATORS, and not functions,
>are desirable as the atomic elements for manipulation of the object.  One
>of the reasons it isn't very much fun to write mathematical functions in
>LISP, but is in APL, is that an APL function is symbolically much like
>what you would write on paper, whereas LISP functions bear no obvious
>symbolic relation to the equation they represent.  And M2 of course does
>not allow you to define operators.  In Algol68 it might make
>sense to make sets extrinsic.
> ...
Absolutely.  I think there is agreement that most design decisions have to
take a side and leave something out in order to make the rest practical to
implement.  If one needs a language in order to deal with a particular domain,
it is best when that language presents the right level of abstraction (i.e.,
compiler-level support for the necessary entities as first-class objects).  So
you have numerically oriented languages that give you lots of power in terms of
accuracy control and plenty of pertinent types (say, complex numbers of various
precisions) and so on.  Similarly, if the language must deal mainly with text,
it is almost imperative that strings are fully supported (say, that you be able
to express the replacement of a substring with another of different length, with
all the surgery being hidden).

This agreed (so I hope), I must say I failed in my previous posting by not
making explicit the design domain I thought corresponded to M2.  My personal
impression comes from the first line of the Report: "Modula-2 grew out of a 
practical need for a general, efficiently implementable systems programming
language for minicomputers."  I think that those early motivations are better
served leaving sets out of the language in favor, say, of better handling of
bit strings.  (My reasons for believing this are documented in too much a
lengthy fashion in my previous article.) This doesn't prevent M2 from growing 
into a sound language for other types of applications, where first-order 
support for strings and sets would have to be deemed more pertinent.  Currently,
ICON and SETL are good exponents of how to deal with those domains.

The argument in favor of guaranteeing sets of at least N elements, for N 
a big number, is certainly a good compromise.  N<=32 is a total loser.  I'd
like to notice, also, that Bitsets in M2 are closer to a practical 
implementation of bit strings than Sets are to their intent.  Having to think
of "membership" when I mean "being on" is just the class of misuse that I
dislike in this aspect of the language.

-- 
Cesar Augusto  Quiroz Gonzalez

Department of Computer Science     {allegra|seismo}!rochester!quiroz
University of Rochester            or
Rochester,  NY 14627               quiroz@ROCHESTER