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