bobc@tikal.UUCP (Bob Campbell) (11/01/86)
These comments are a little hurried, but I have been tring to get
around to making a reply for about 2 weeks, and just don't seem to
have much time available.
I do have several comments on the proposed changes from the Modula-2
Working Group of the British Standards Institution. I feel that some
of the direction of this group is wrong:
a. I feel that very effort should be made to leave the language
intact as it was defined by Dr. Wirth. In cases where changes
are questionable the Dr. Wirth's current design should be
used.
b. In cases where it is felt that the current language design
must be changed the scope of the changes should be limited to
make the change as small as possible, and to whenever possible
allow the currently running modula-2 programs to work with out
modification.
c. I feel that the Modula-2 Working Group should be exploring need
additions to the language which will make it more useful.
d. I feel that a standards group should allow for compiler
restrictions, and also define some preferred extensions.
Examples of preferred extension would be defining the workings
of passing open arrays of more then one dimension.
Now on to the messy blow by blow, and don't assume that I disagree on
all points, some of them I can support.
WG104: Allowing underscores in identifiers, I can't support this as a
required standard. While many systems do allow underscores some
systems (linkers) do not support underscores. At best I feel that
this should be a optional compiler feature. And people should not
expect all modula-2 compilers to support underscores.
WG007: Not supporting MaxInt, MinInt etc. This is fine, as my system
(ETHZ One Pass Compiler) does not support these anyway.
WG086: I don't see any reason for removing the octal notation for
character constants. While I admit that the CHR notation will
work in all cases, I don't feel that removing this feature gains
the language anything. In fact it will brake a lot of programs.
WG106: Strings. I feel that some work is needed on strings, but I
feel that it can all be done with a defined module supporting the
required string operations. Also I don't feel that requiring full
padding of the character strings should be required or expected.
I do feel that it might make a good optional feature to the
compiler but I don't see any value to it being required. (It will
make the programs run slower, and if you don't need it why should
I be required to have it.).
WG012: NIL as a reserved word, I see no problem with this as a
concept however it will be hard for me to implement.
WG099: Constant declarations, I agree with all of this except for the
item on "typename(ConstExpression)". I side with Dr. Wirth that
the "typename(Value)" construct should be deleted from the
language (or only supported via a special compiler switch for old
code).
WG088: Not all of the required supporting paper work for this is
present here so I can only give a qualified yes. All numeric
constants are "untyped" ie they exist in the type set which
consists of all types that the constant could be in. However Real
and Integers don't mix?
WG126: I see little (read no) reason for this, and as noted above I
can indorse this syntax.
WG015: Elements of constants can be constant expressions. This
sounds fine to me.
WG131: "implementation must provide SET OF CHAR", in no way can I
support this as a required feature. Providing full support for
large sets is excessive, and should be a preferred option but not
required. I fully intend to support large sets in my compiler
soon, but it will require much effort to work out the code to
generate for things like SetA := (SetA + SetB) / (SetC - SetA),
including allocation of the temporary variables.
WG034: BITSET must be imported from the system. I have not yet
made up my mind about this.
WG035: "N and W are to be exported from SYSTEM", what are N and W,
WG132: Only BITSET maps to a "WORD" other types of sets are
implementation specific. This seems reasonable.
WG089: About procedure types: I feel that NIL is a valid procedure
type, and that calling a procedure variable of value NIL is
undefined. I also agree that testing procedure variables for
equality and inequality should be allowed. I don't understand the
need for procedure constants.
WG041: Expressions will be evaluated from left to right. This is a
clear win.
WG073: the return values of procedures which are not of the simple type
or are POINTERS, can't be applied, dereferenced, selected or
indexed. This seems only reasonable to me.
WG074: I see no need for requiring sets of type BITSET be written as
BITSET{1..8}. I feel that this will be come a matter of style,
and is not worth breaking things that already exist to inforce
(except as a compiler option).
WG080: out-of-range errors, I agree as long as exception is defined
to be a system specific event.
WG050: The right hand side of an assignment is to be evaluated first.
This seems fair.
WG051: parameters are evaluated from left to right. I fully support
this.
WG056: an 'exception' happens with a case value is detected which is
not dealt with. I don't thing this should be required. I
don't like putting blank ELSE clauses on all of my case statements,
it I wanted a exception I would have put a "ELSE HALT" at the end.
WG003: Could you please post the document for this "PS 6.8.3.9".
WG061: The standard should note that some compilers may have
restriction on the types that can be returned from function
procedures.
WG113: The standard should note that "FORWARD" is a optional feature
of one pass compilers, and should state what the syntax of this
type of statement is.
WG114: VAR parameter types. This item is ok.
WG075: The documents supporting this are not present.
WG115: I can't support the removal of ORD, CHR, FLOAT, and TRUNC,
which also implies the removal of LONG, and SHORT. I feel that
Wirth's current definition of these functions and type casting is
more reasonable.
WG116: I feel that HIGH should work on any array type, and return the
highest index for that array type. The suggestion that MAX be
used for fixed sized arrays is not a workable solution.
WG118: I feel that MAX and MIN should take any numeric type and
return the value of the largest or smallest value of that type.
These types should include REAL, LONGREAL, and any enumerated
types.
WG119: I thought that SIZE only takes variables and TSIZE only takes
types. Wirth's current compiler (ETH One Pass 68000 compiler)
will take anything for SIZE, but TSIZE will only take types. It
sounds like TSIZE may be a old feature which is supported to keep
old programs from breaking.
WG120: I can't support the function CAST as it does what VAL does.
VAL should be left in the language intact and unchanged.
WG102: I also can't support this as it uses a language construct that
Wirth feels should no longer be supported. The using this
construct in a manor other then the original design will cause
extreme confusion.
WG121: Removal of VAL. Because of the above I can't support this.
WG122: Remove the two parameter form of DEC, and INC. I can't
support this as both forms of DEC, and INC are of great value.
WG085: Removal of NEW and DISPOSE, I support this with some
reservations, and NEW, and DISPOSE are cleaner then
ALLOCATE(x,SIZE(x)), as some one could do a ALLOCATE(x,2) or some
such thing.
WG069: I have no problems with this.
WG109: Definition Modules and Implementation module definition of
procedures must be exact. This should only be a suggested feature
as it is may be much too costly to implement.
WG084: I feel that Wirth's proposal ("Revision 2.1") should be
adopted with the following adjustment: definition modules which
contain a explicit export list will only export those symbols
explicitly listed in the that list. From my work with definition
modules, I feel that the export list is in many cases hard to
work with (ie a MacIntosh Interface module with over 140 symbols
exported and every symbol in the definition module is intended to
be exported.)
WG110: opaque types. I support this feature, but feel that may be
this a area where a extension could be created to allow support for
non pointer opaque types.
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!bobcnels@astrovax.UUCP (Nels Anderson) (11/06/86)
With regard to changes in Modula-2, I'd like to propose a couple of things that would make some sense from the point of view of a not- very-sophisticated programmer. If M2 is not intended to be used for scientific programming, then these comments should be ignored. If, on the other hand, it is to someday challenge FORTRAN as the language used by the many scientists who do program, a couple of additions would be handy: 1) an exponentiation operator (`**' in FORTRAN), and 2) double and single precision floating point types. I'm sure these two features are of little interest to those concerned with the more interesting and elegant aspects of programming, but most of the programming done by scientists is fairly mundane number crunching.