Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!rutgers!sri-unix!hplabs!tektronix!uw-beaver!tikal!bobc From: bobc@tikal.UUCP Newsgroups: comp.lang.modula2 Subject: Re: Modula-2 standard Message-ID: <576@tikal.UUCP> Date: Wed, 10-Dec-86 19:57:57 EST Article-I.D.: tikal.576 Posted: Wed Dec 10 19:57:57 1986 Date-Received: Sun, 14-Dec-86 11:26:28 EST References: <424@brueer.ee.brunel.ac.uk> <4814@ism780c.uucp> Reply-To: bobc@tikal.UUCP (Bob Campbell) Distribution: world Organization: Teltone Corp., Kirkland, WA Lines: 107 Keywords: Modula-2 Successful? YES! There are several articles based on John Lancaster's (johnl@uk.ac.brunel.ee) article entitled "Modula-2 standard". I will not include any of the original text to reduce net traffic. John lists six problems he sees in Modula2 as it is currently defined. I feel that only one of these problems requires a "Language Change", and that most of them are requests for what I feel should be "Compiler Options" or a larger standard "SYSTEM" module. I don't feel that any of these problems will make the language be unsuccessful as even with out these features I find that the language is better then either "C" or "Pascal", and is still much smaller then Ada. In all cases I consider Compiler Options to be embedded in comment blocks such that the code can be ported to compiler which does not support the features with out rewritting large parts of the code. Problem 1. structured constants This would require a modification to the syntax of the language, if it is really greatly needed then perhaps it should be added to the language. If the BSI were really on their toes they might write a optional standard which could define the way that compilers which support this feature should do so. (And maybe John Lancaster should write it up and submit it to them). A optional compiler feature which might solve this problem is a method for the compiler (of definition modules) to indicate read only variables (this would allow a module to set up the "constant" variables and disallow other modules from modifing them this would also mean that they can't be passed by address except as may be as required in item 2). Problem 2 PVAR Is a code generation problem in which the programmer wishes to suggest to the compiler that the variable should be passed by value and will not be changed by the module. At times I have felt that the compiler should not allow the programmer to modify the values of "passed by value" parameters. I feel that the correct solution is for a optional compiler switch which can be used to indicate that the program wishes to have the compiler pass strings/structures by address and inforce the rule of not allowing the "value" parameters to be modified. Note that this "pass by address will not change" type of definition will have to be in the definition modules, but could be done with a compiler switch. Problem 3. User exception handling. I don't agree that any more support for this is needed then is already available. I feel that a "setjmp"/"longjmp", and a signal catching routine can be created that will be every bit as good as the ones used by "C". I also know that Wirth's implementations supply all the low level features required to do this (even if it does require writting a small routine in machine language). I have a almost complete version of coroutines for MacMETH (Macintosh compiler from ETH) which prove that low level things like this can be done if the correct "SYSTEM" module is provided by the compiler. Problem 4. BITSET size and syntax. I don't see where this does any good. What would appear to be needed is a compiler which defines how a set is to be represented in menory. Then these sets can be used for hardware device registers. I also beleive that the NILs are not needed as the programmer can create names like "PAD1", "PAD2" ... this can be done without any changes to the language as it is only a compiler implementation issue. Problem 4. PACKING OF RECORDS I feel that some form of compiler option could be created to allow the programmer to specify that a RECORD is to be packed in to the smallest space possible. I also feel that it should be done in a way that it is portable to the current compilers, this is why I prefer options of the form (*$PACK*) which would allow me to quickly detect routines which make use of special compiler features, and at the same time allow compilers which do not support the feature still compile the program (which small adjustments). This feature is not required, it is just a extra feature that allows the compiler to do some the of decoding for you (given that many processors now support bit fields it would be easier for the compiler to do it but this is not true for things like PDP-11s, 68000s etc). Problem 5. SHIFT, and SignExtend. These functions should I agree be included in the standard SYSTEM module (and in fact the compilers that I have used have supported them in some form either ASH, or SHIFT, and the function LONG to do sign extention of a short). Problem 6. Low-level escape path. I feel that this is a function of finding a good compiler. First the MacMETH compiler (also the generic 68K compiler, and I suppose the Lilth, and 32032 versions also) support inline machine language code, as well as allowing the definition of one word code procedures which get expanded in line to support Operating System Calls via TRAPs. In any case the low-level escape paths should be considered to be machine specific, but it would be nice if there was a standard syntax for insert code inline. (The current MacMETH compiler supports the psuedo function INLINE to do this). I also feel that the current implemenetations do not support linking to non-Modula-2 object files because of external restrictions on identifer lengths on some systems. I currently have a compiler which runs on a Macintosh, and can link to assembler code, and there are only a few small changes left to allow it to link to Pascal routines. Also the code from this compiler can be called from either assembler, "C", or "Pascal" with the only problem is that the init routines have to be called by the program (if for any reason someone would want to do this). Bob Campbell Teltone Corporation 18520 - 66th AVE NE P.O. Box 657 Seattle, WA 98155 Kirkland, WA 98033 {amc,dataio,fluke,hplsla,sunup,uw-beaver}!tikal!bobc