Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!mcvax!ace!konijn From: konijn@ace.nl (Erik van Konijnenburg) Newsgroups: comp.lang.modula2 Subject: Re: Number of elements in a set Message-ID: <440@ace.nl> Date: Tue, 22-Sep-87 05:52:30 EDT Article-I.D.: ace.440 Posted: Tue Sep 22 05:52:30 1987 Date-Received: Fri, 25-Sep-87 06:17:00 EDT References: <8709192023.AA27593@jade.berkeley.edu> Sender: news@ace.UUCP Organization: ACE Associated Computer Experts bv, Amsterdam Lines: 124 In article <8709192023.AA27593@jade.berkeley.edu>, jem@hutcs.hut.fi writes: > 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. Yep. But, as you say, your code won't be very portable, since now you not only depend on the accepted size of the set, but also on its implementation (that it is implemented as a bitmap, and assumptions about which set element is which pixel). Our VAX and mc68020 compilers allow 524288 elements in a set value, the amount that can be moved by an efficient copy loop, so your screen would fit with room to spare, but you are still being forced to accept an arbitrary limit. The only inherent limit to the size of a Modula-2 set is that the base type must be representable. Because the set size is known at compile time, this should not be a performance issue except for _very_ large sets as complex code will only need to be generated for those specific cases. Part of the task of a standardisation committee is to define a standard that can be accepted by a majority of users (that is, implementors as well as programmers). If this involves the inclusion of minimal requirements for values of data types, these really must be _minimal_. Current Modula-2 practice is based on Wirth's "Programming in Modula-2" which states that the maximal set size is a _small_ constant determined by the implementation, usually the computer's word size, or a small multiple thereof (ed. 2 page 147, ed. 3 page 150). In view of this, and assuming that it should be specified in the standard at all, a minimum set size of 128 or 256 might be a reasonable requirement (though _any_ value will lead to endless discussion). These values are still arbitrary, but arguably make _some_ sense because of current character set sizes (though what about Japanese?), and can be implemented on any(?) machine. Requiring an implementation to support a set size determined by the value of MAX(INTEGER), as was suggested, can hardly be called minimal. Defining the minimum in terms of CHAR, as was also suggested, would probably not be a good choice either, as CHAR itself is implementation dependent. If a minimum set size is indeed felt to be necessary perhaps it should be something along the lines of "A minimal conforming implementation will support set values of at least (some number, e.g. 256) elements, however, it is recommended that such an implementation support SET OF CHAR". Compilers that are intended for serious work will of course have to set their own limits (and given the growth in screen sizes, we may have to increase ours pretty soon :-). By the way, what about the minimum size of ARRAY types ... (don't answer that!) --------- Erik van Konijnenburg, , ...!mcvax!ace!konijn, ACE Associated Computer Experts bv, Amsterdam, the Netherlands The article really stops here. You had the signature already. Don't forget about the 'n' key. F.y.i. this is a brief summary of an article that appeared in comp.newprod. Subject: announcing the ACE Modula-2 compiler - strict adherence to the language, the only extension is the inter- face to C-compatible subroutines such as from the Unix system- call library. - accepts edition 2 and edition 3, including NEWPROCESS, TRANSFER and IOTRANSFER. - high reliability, through a proprietary validation suite as well as through the BSI validation suite for which ACE is a beta-test site. - easy reconfiguration, allowing most runtime support routines to be redeclared. - good run-time checking: falling out of functions, NIL pointer dereferencing, missing defaults in case statements, range errors, uninitialised variables etc., are all checked. - amongst others, a Unix interface module and Wirth's I/O modules are available as Modula-2 source. - comprehensive documentation including all implementation defined decisions and how to interface to Unix and standalone systems. - a global optimiser that performs constant folding, expression reduction, size-conversion elimination and common sub-expression and loop-invariant code detection and other optimisations. - a register allocation optimiser - a peep-hole optimiser - IEEE floating point - Motorola 68020 code generation - Motorola 68881 support - generation of COFF or a.out images - mixing of code from different languages - available native on 68K and VAX Bsd and cross for 68K on VAX Bsd, VAX VMS and Gould