neitzel@infbs.UUCP (Martin Neitzel) (06/24/89)
This is a context diff of the 3rd and the 4th edition of
"Programming in Modula-2".
*** pim3 Sat Jun 24 01:33:31 1989
--- pim4 Sat Jun 24 01:33:29 1989
***************
*** 96,103 ****
sequences of digits. If the number is followed by the letter B, it is
taken as an octal number; if it is followed by the letter H, it is
taken as a hexadecimal number; if it is followed by the letter C, it
! denotes the character with the given (octal) ordinal number (and is of
! type CHAR, see 6.1).
An integer i in the range 0 <= i <= MaxInt can be considered as either
of type INTEGER or CARDINAL; if it is in the range MaxInt < i <=
--- 96,103 ----
sequences of digits. If the number is followed by the letter B, it is
taken as an octal number; if it is followed by the letter H, it is
taken as a hexadecimal number; if it is followed by the letter C, it
! denotes the character with the given (octal) ordinal number and is of
! type CHAR (see 6.1), i.e. is a character constant.
An integer i in the range 0 <= i <= MaxInt can be considered as either
of type INTEGER or CARDINAL; if it is in the range MaxInt < i <=
***************
*** 131,137 ****
A string consisting of n characters is of type (see 6.4)
! ARRAY [0..n-1] OF CHAR
Examples:
"MODULA" "Don't worry!" 'codeword "Barbarossa"'
--- 131,137 ----
A string consisting of n characters is of type (see 6.4)
! ARRAY [0..n] OF CHAR
Examples:
"MODULA" "Don't worry!" 'codeword "Barbarossa"'
***************
*** 548,557 ****
8.2. Operators
The syntax of expressions specifies operator precedences according to
! four classes of operators. The operator NOT has the highest
! precedence, followed by the so-called multiplying operators, then the
! so-called adding operators, and finally, with lowest precedence, the
! relational operators. Sequences of operators of the same precedence
are executed from left to right.
$ expression = SimpleExpression [relation SimpleExpression].
--- 548,557 ----
8.2. Operators
The syntax of expressions specifies operator precedences according to
! four classes of operators. The operator NOT has the highest prcits
! execution, i.e. for the "returned" value. The (types of these) actual
! parameters must correspond to the formal parameters as specified in
! the procedure's declaration (see operators of the same precedence
are executed from left to right.
$ expression = SimpleExpression [relation SimpleExpression].
***************
*** 705,712 ****
`assignment compatible', if either they are compatible or both are
INTEGER or CARDINAL or subranges with base types INTEGER or CARDINAL.
! A string of length n1 can be assigned to a string variable of length
! n2 > n1.
In this case, the string value is extended with a null character (0C).
A string of length 1 is compatible with the type CHAR.
--- 705,712 ----
`assignment compatible', if either they are compatible or both are
INTEGER or CARDINAL or subranges with base types INTEGER or CARDINAL.
! A string of length n1 can be assigned to a array variable with n2 > n1
! elements of type CHAR.
In this case, the string value is extended with a null character (0C).
A string of length 1 is compatible with the type CHAR.
***************
*** 740,747 ****
actual parameter must be an expression. This expression is evaluated
prior to the procedure activation, and the resulting value is assigned
to the formal parameter which now constitutes a local variable. The
! types of corresponding actual and formal parameters must be identical
! in the case of variable parameters, or assignment compatible in the
case of value parameters.
$ ProcedureCall = designator [ActualParameters].
--- 740,747 ----
actual parameter must be an expression. This expression is evaluated
prior to the procedure activation, and the resulting value is assigned
to the formal parameter which now constitutes a local variable. The
! types of corresponding actual and formal parameters must be compitable
! in the case of variable parameters and assignment compatible in the
case of value parameters.
$ ProcedureCall = designator [ActualParameters].
***************
*** 1094,1100 ****
CHR(x) the character with ordinal number x. CHR(x) =
VAL(CHAR,x)
! FLOAT(x) x of type CARDINAL represented as a value of
type REAL.
HIGH(a) high index bound of array a.
--- 1094,1100 ----
CHR(x) the character with ordinal number x. CHR(x) =
VAL(CHAR,x)
! FLOAT(x) x of type INTEGER represented as a value of
type REAL.
HIGH(a) high index bound of array a.
***************
*** 1111,1121 ****
CARDINAL.
SIZE(T) the number of storage units required by a
! variable of type T, or the number of storage
! units required by the variable T.
TRUNC(x) real number x truncated to its integral part
! (of type CARDINAL).
VAL(T,x) the value with ordinal number x and with type
T. T is any enumeration type, or CHAR,
--- 1111,1120 ----
CARDINAL.
SIZE(T) the number of storage units required by a
! variable of type T.
TRUNC(x) real number x truncated to its integral part
! (of type INTEGER).
VAL(T,x) the value with ordinal number x and with type
T. T is any enumeration type, or CHAR,
***************
*** 1151,1156 ****
--- 1150,1156 ----
Objects local to a module are said to be at the same scope level as
the module. They can be considered as being local to the procedure
enclosing the module but residing within a more restricted scope.
+ The module identifier is repeated at the end of the declaration.
$ ModuleDeclaration =
$ MODULE ident [priority] ";" {import} [export] block ident.
***************
*** 1158,1164 ****
$ export = EXPORT [QUALIFIED] IdentList ";".
$ import = [FROM ident] IMPORT IdentList ";".
- The module identifier is repeated at the end of the declaration.
The statement sequence that constitutes the `module body' is executed
when the procedure to which the module is local is called. If several
modules are declared, then these bodies are executed in the sequence
--- 1158,1163 ----
***************
*** 1251,1257 ****
w = 16; (* word size*)
m = ntr DIV w;
! VAR i: CARDINAL;
free: ARRAY [0..m-1] OF BITSET;
PROCEDURE NewTrack(): INTEGER;
--- 1250,1256 ----
w = 16; (* word size*)
m = ntr DIV w;
! VAR i: INTEGER;
free: ARRAY [0..m-1] OF BITSET;
PROCEDURE NewTrack(): INTEGER;
***************
*** 1258,1264 ****
BEGIN
(*reserves a new track and yields its index as result,
if a free track is found, and -1 otherwise*)
! VAR i,j: CARDINAL; found: BOOLEAN;
BEGIN found := FALSE; i := m;
REPEAT DEC(i); j:=w;
REPEAT DEC(j);
--- 1257,1263 ----
BEGIN
(*reserves a new track and yields its index as result,
if a free track is found, and -1 otherwise*)
! VAR i,j: INTEGER; found: BOOLEAN;
BEGIN found := FALSE; i := m;
REPEAT DEC(i); j:=w;
REPEAT DEC(j);
***************
*** 1270,1276 ****
END
END NewTrack;
! PROCEDURE ReturnTrack (k: CARDINAL);
BEGIN (*assume 0<=k<ntr*)
INCL(free[k DIV w], k MOD w)
END ReturnTrack;
--- 1269,1275 ----
END
END NewTrack;
! PROCEDURE ReturnTrack (k: INTEGER);
BEGIN (*assume 0<=k<ntr*)
INCL(free[k DIV w], k MOD w)
END ReturnTrack;
***************
*** 1345,1354 ****
to any variable of type T. TSIZE is of an arithmetic type depending
on the implementation.
- Examples:
-
- ADR(lastused) TSIZE(Node)
-
Besides those exported from the pseudo-module SYSTEM, there are two other
facilities whose characteristics are system-dependent. The first is
the possibility to use a type identifier T as a name denoting the
--- 1344,1349 ----
***************
*** 1366,1371 ****
--- 1361,1367 ----
expression enclosed in brackets immediately following the identifier
in the variable declaration. The choice of an appropriate data type
is left to the programmer.
+ For examples, refer to 13.2.
***************
*** 1402,1408 ****
This call suspends the current process, assigns it to p1, and resumes
the process designated by p2. Evidently, p2 must have been assigned a
process by an earlier call to either NEWPROCESS or TRANSFER. Both
! procedures must be imported.
A program terminates, when control reaches the end of a procedure
which is the body of a process.
--- 1398,1404 ----
This call suspends the current process, assigns it to p1, and resumes
the process designated by p2. Evidently, p2 must have been assigned a
process by an earlier call to either NEWPROCESS or TRANSFER. Both
! procedures must be imported from the module SYSTEM.
A program terminates, when control reaches the end of a procedure
which is the body of a process.
***************
*** 1429,1436 ****
in addition causes the interrupt transfer occurring upon device
completion to assign the interrupted process to p2 and to resume the
device process p1. va is the interrupt vector address assigned to the
! device. The procedure IOTRANSFER must be imported, and should be
! considered as PDP-11 implementation-specific.
It is necessary that interrupts can be postponed (disabled) at certain
times, e.g. when variables common to the cooperating processes are
--- 1425,1432 ----
in addition causes the interrupt transfer occurring upon device
completion to assign the interrupted process to p2 and to resume the
device process p1. va is the interrupt vector address assigned to the
! device. The procedure IOTRANSFER must be imported from the module
! SYSTEM, and should be considered as PDP-11 implementation-specific.
It is necessary that interrupts can be postponed (disabled) at certain
times, e.g. when variables common to the cooperating processes are
***************
*** 1498,1504 ****
operating on operands of this type, and in particular operating on its
components, must be defined in the same implementation module which
hides the type's properties. Opaque export is restricted to
! pointers.
Assignment and test for equality are applicable to all opaque types.
As in local modules, the body of an implementation module acts as an
--- 1494,1500 ----
operating on operands of this type, and in particular operating on its
components, must be defined in the same implementation module which
hides the type's properties. Opaque export is restricted to
! pointers and to subranges of standard types.
Assignment and test for equality are applicable to all opaque types.
As in local modules, the body of an implementation module acts as anceriel@cs.vu.nl (Ceriel Jacobs) (06/26/89)
Some time ago (in March 1989), I posted the following list of inconsistencies in PIM-4: ... (start of list) For instance, there an inconsistency between paragraph 9.2 and paragraph 10.1. In paragraph 9.2, page 144, we read: ... The types of corresponding actual and formal parameters must be *compatible* in the case of variable parameters ... (emphasis mine) but in paragraph 10.1, page 149, we read: ... The type of each formal parameter is specified in the parameter list. In the case of variable parameters it must be *identical* with its corresponding actual parameter ... (again, emphasis mine) Also, in chapter 12 of the book, paragraph 12.1, page 52, on variable parameters, we read: ... The types of corresponding formal and actual parameters must be the same ... In paragraph 12 of the Report, page 153/154, we read: ... The type ADDRESS .... is compatible with all pointer types ... ... If a formal parameter is of type ADDRESS, the corresponding actual parameter may be of any pointer type, even if the formal parameter is a VAR parameter ... If the types of the corresponding actual and formal parameter only have to be compatible, the last sentence quoted is a useless remark. Apparently, the texts of the 2nd and the 3rd edition got mixed up a bit. This supposition is supported by the following quote, from paragraph 14, page 156: ... Opaque export is restricted to pointers and to subranges of standard types ... This was in the 2nd edition. The 3rd edition limits opaque export to pointers only. Some more support for this supposition is found in Appendix 1. It contains the syntax of Modula-2, as it appeared in the 2nd edition, not the 3rd! This obviously is a mistake, because this grammar does not correspond to the pieces of grammar quoted in the Report. Also, the syntax diagrams in Appendix 4 are those of the 3rd edition, and thus do not correspond to the syntax in Appendix 1. Another problem is caused by the preface to the 4th edition. On page 5, we read: ... the definition of the language has also undergone a few minor adaptations in the area of Standard Functions: FLOAT(i) and CHR(i) accept an argument of type INTEGER TRUNC(x), HIGH(a), ORD(ch), and SIZE(T) are of type INTEGER However, in paragraph 10.2 of the report, page 150, we read: ... ORD(x) ordinal number (of type CARDINAL) ... The text in the first 5 lines of paragraph 8.2, page 141, got mangled. I assume that the intention for variable parameters is, that the types of the corresponding formal and actual parameters must be identical, like in the 3rd edition. For opaque types, however, it is not clear to me whether the change back to the 2nd edition was intentional or accidental. ... (end of list) I also wrote a letter about this to Prof. Wirth. His reaction contained the following paragraph (copied verbatim): You are of course right in assuming that while editing parts of the 2nd edition slipped in. The types of VAR parameters must not only be compatible, but identical. Opaque type continue to be restricted to pointers. I am particularly dismayed that the Syntax (App. 2) is wrong; it should be replaced by that of the 3rd Edition. So, don't believe the 4th edition! -- Ceriel Jacobs, Dept. of Mathematics and Computer Science, Vrije Universiteit, De Boelelaan 1081, 1081 HV Amsterdam, The Netherlands Voice: +31 20 5485577 Email: ceriel@cs.vu.nl -- Ceriel Jacobs, Dept. of Mathematics and Computer Science, Vrije Universiteit, De Boelelaan 1081, 1081 HV Amsterdam, The Netherlands Voice: +31 20 5485577 Email: ceriel@cs.vu.nl