COK2%UK.AC.DURHAM.MTS@AC.UK (Barry_Cornelius) (10/20/86)
Significant Changes to the Language Modula-2
M2WG-N94: Issue 2: 30th April 1986
Barry Cornelius
Department of Computer Science
University of Durham
Durham DH1 3LE United Kingdom
This paper gives a list of some of the changes being proposed by the
Modula-2 Working Group of the British Standards Institution. The list
mainly consists of changes that are likely to affect existing Modula-2
programs. The changes are provisional: formally, no decision has any
effect until ISO ballots on a draft proposal. However, please mail me
if you think that any of these changes are undesirable.
In this paper, the notation "PIM" is used to refer to the book
"Programming in Modula-2" by Niklaus Wirth. The Pascal Standard
(BS6192/ISO7185) is referred to by the notation "PS". The definitions
of the terms 'ordinal type' and 'exception' are given in the paper
"Type Conversions in Modula-2" [2].
The section numbers used in this paper correspond to those used in the
"Report on The Programming Language Modula-2" (as given in PIM).
3. Vocabulary and representation
WG104: It was agreed that underscores be permitted (as a 'break'
character) in an identifier subject to:
+ underscores are not permitted as the first or last
character of an identifier,
+ underscores are significant.
WG007: MaxInt, MinInt, etc., are to be dropped as MAX and MIN make
them redundant.
WG086: It was agreed to remove:
octalDigit $octalDigit "C"
from the language, since CHAR(^^^) can now be used in any
context in which ^^^C could be used - see WG099 in $5.
WG106: Two proposals on "strings" have been discussed in detail.
Briefly, these proposals are:
(i) assignment of a string constant of length f to a variable
of type ARRAY [0..t-1] OF CHAR is permitted if f<=t.
If f<t, each of the last (t-f) elements of the array
variable is assigned the value which is defined by the
constant StringTerminator in the module SYSTEM.
(ii) a new string data type is introduced.
It is possible that either or both of these proposals will be
accepted. The views of the Modula-2 community are to be
sought - see the paper "All About Strings" [3].
WG012: It was agreed to add NIL as a reserved word.
- 2 -
5. Constant declarations
WG099: It was agreed to take the definition of constant expression
given in a paper by Don Ward (M2WG-N52). Informally, this
definition is:
Each operand in a ConstExpression must be a constant.
A constant is:
+ a literal (either a number, a single
character or a string literal),
+ an identifier denoting a constant value
(either NIL, or from a CONST declaration, or
from an enumeration type),
+ a set denotation whose elements, if present,
are ConstExpressions,
+ a call of ABS, CAP or ODD with a parameter
which is a ConstExpression,
+ a call of SIZE, MIN or MAX,
+ a type conversion of the form:
typename(ConstExpression)
[see WG102 under VAL in $10.2].
WG088: Numeric literals and constant identifiers are of the types ZZ
and RR as defined in the paper "Expressions in Modula-2" [1].
Consequently, a literal which is potentially of type LONGCARD
does not have a different denotation from one which is
potentially of type CARDINAL. [Such literals are actually of
type ZZ.]
WG126: As a result of WG099, it is possible to specify explicitly the
type of a constant expression as illustrated by the following
example:
TYPE OneInTen = [ 1 .. 10 ] ;
CONST IntegerOne = INTEGER(1);
CardinalOne = CARDINAL(1);
OneInTenOne = OneInTen(1);
WG015: The element of a set literal must be a ConstExpression if the
set literal is a part of a ConstExpression. The element of a
set literal can be an Expression if the set literal is a part
of an Expression.
6.6. Set types
WG131: It was agreed that the Standard be worded so that an
implementation must provide SET OF CHAR.
WG034: It was agreed that if a program uses BITSET then BITSET must
be imported from SYSTEM. [See also WG074 in $8.2.]
WG035: It was agreed that the constants N and W are to be exported
from SYSTEM. However, more meaningful names are to be used.
WG132: It was agreed that a BITSET value maps onto the bits in one
word. It was also agreed that the underlying representation
of a value which is of a set type other than BITSET is not to
be defined.
- 3 -
6.8. Procedure types
WG089: It was agreed that:
+ NIL is compatible with an object which is of a procedure
type;
+ tests of (in)equality can be used between objects which
are of a procedure type;
+ there should be provision for procedure constants.
8. Expressions
WG041: It was agreed that operands of an expression will be evaluated
from left to right.
8.1. Operands
WG073: Although a function procedure may return a value which is of a
PROCEDURE, POINTER, RECORD or ARRAY type (see WG061 in $10),
it was agreed that these results cannot be "applied",
"dereferenced", "selected" or "indexed".
8.2. Operators
WG074: It was agreed that the type preceding a set expression is no
longer optional; so there is no longer a default to the type
BITSET. [See also WG034 in $6.6.]
8.2.1. Arithmetic operators
WG080: It was agreed that out-of-range errors that occur during
expression evaluation will yield an 'exception'. For example:
if there is a cardinal expression and its result is positive,
but an intermediate result is negative, then an 'exception'
will occur.
9.1. Assignments
WG050: It was agreed that the right hand side of an assignment is to
be evaluated before the left hand side.
9.2. Procedure calls
WG051: It was agreed that the parameters of a procedure call are to
be "evaluated" from left to right.
- 4 -
9.5. Case statements
WG056: There should be an explicit statement that it is an
'exception' if the selecting expression of a CASE statement is
not found as a label, and there is no ELSE clause. The
definition could be modelled on PS 6.8.3.5, with minor
modifications included for Modula-2's ELSE clause.
9.8. For statements
WG003: It was agreed that PS 6.8.3.9 would be used as a starting
point for the specification of FOR statements.
10. Procedure declarations
WG061: It was agreed that a function procedure may return a value of
any type. Wirth has said that the restriction on function
result types in PIM was an implementation restriction of his
compilers: the language itself has no restriction.
WG113: It was agreed that FORWARD is not to be made part of the
language.
10.1. Formal parameters
WG114: It was agreed that the types of a formal VAR-parameter and
that of its corresponding actual parameter must be identical
(i.e. not merely compatible). This rule may be relaxed when
the formal parameter is of type WORD or ADDRESS.
10.2. Standard procedures
ABS, CAP, and ODD
WG075: The agreed definitions for the above functions appear in the
paper "Expressions in Modula-2" [1].
ORD, CHR, FLOAT and TRUNC
WG115: The function procedures ORD, CHR, FLOAT and TRUNC are to be
removed from the language. Calls of these functions can be
replaced as follows:
ORD(value) can now be done by CARDINAL(value)
CHR(value) can now be done by CHAR(value)
FLOAT(value) can now be done by REAL(value)
TRUNC(value) can now be done by CARDINAL(value - 0.5)
For brief details of the use of a typename to coerce a value
into some other type, see WG102 under VAL in $10.2. For other
details, see the paper "Type Conversions in Modula-2" [2].
- 5 -
HIGH
WG116: It was agreed that the parameter to HIGH must be a variable
that is specified as an open array parameter. Thus, HIGH
always delivers a result of type CARDINAL. MAX applied to the
index type of an array can be used for an array which is not
an open array parameter.
WG117: It was agreed that when a multi-dimensional open array
parameter is passed to HIGH, HIGH delivers the high index
bound of the first dimension of the array.
MAX and MIN
WG118: It was agreed that the standard functions MIN and MAX take any
'ordinal type' as a parameter. They return the type's minimum
and maximum values. Consequently, if T is a subrange type,
then MIN(T) and MAX(T) yield the lower and upper bounds of the
subrange. Note that MIN and MAX cannot be applied to the type
REAL. However, there will be some other mechanism to deliver
the various characteristics of the type REAL.
SIZE and TSIZE
WG119: I believe that no firm decision was reached as to whether the
parameter passed to SIZE has to be a type or a variable or
either. Similarly, for TSIZE. However, it was agreed that
both SIZE and TSIZE should return 'storage units' where the
size of a storage unit depends on the implementation. It was
also agreed that BitsInAStorageUnit is a constant identifier
that is required to be exported from the module SYSTEM.
VAL
WG120: It was agreed that SYSTEM would contain a function procedure
called CAST which would do unchecked type transfers.
So, given:
VAR v1:t1; v2:t2;
the call of CAST in:
v2:= CAST(t2, v1);
would return the value v1 interpreted as if it were of
type t2. For full details, see the paper "Type Conversions in
Modula-2" [2].
WG102: It was agreed that:
typename(expression)
would be used for type conversions. [Such conversions are
"safe" - they are sometimes called "coercions".]
The restrictions on "typename" and the type of "expression"
are defined in the paper "Type Conversions in Modula-2" [2].
WG121: Because of the construct provided in WG102, it was agreed to
remove VAL from the language.
- 6 -
DEC and INC
WG122: It was agreed that:
+ the form of DEC with two parameters is removed from the
language;
+ the parameter to DEC and INC must be a value which is of
some 'ordinal type';
+ both DEC applied to the first value of a type and INC
applied to the last value of a type cause an 'exception'.
NEW and DISPOSE
WG085: It was agreed to adopt the position adopted by the 3rd edition
of PIM for NEW and DISPOSE, i.e., they are no longer part of
the standard Modula-2 environment. This is because the fact
that they magically led to calls of ALLOCATE and DEALLOCATE is
considered undesirable.
11. Modules
WG069: It was agreed to follow Wirth's latest ideas about the scope
of standard identifiers which are as follows:
The standard identifiers can be considered as being
defined in a universe. If an identifier is not found
within a program according to the scope rules, then that
universe is searched as a last resort. Note that this
allows any standard identifier to be redeclared as a
fresh identifier anywhere.
This is in some ways similar to Pascal. It is assumed that in
the above definition, the word "program" should read "module".
14. Compilation units
WG109: It was agreed that it is invalid to use the procedure heading:
PROCEDURE p(i:INTEGER);
in a definition module if the procedure is declared as:
PROCEDURE p(j:INTEGER);
in the implementation module: the same name has to be used for
the two occurrences of the formal parameter. This attempts to
ensure that the two formal parameter lists correctly
correspond, especially when there are two consecutive
parameters of the same type.
WG084: Wirth's proposal ("Revision 2.1") to discard the export list
of a definition module is not to be adopted: M2WG has agreed
to retain the original syntax and semantics, i.e., objects
which are to be exported from a definition module have to be
listed in an export list.
- 7 -
WG110: It was agreed that:
+ an opaque type must be declared as a pointer type in the
implementation module;
+ an object which is of an opaque type may not be
dereferenced in a client module.
It was also agreed that:
+ assignment between objects of an opaque type is legal
+ comparison for (in)equality is legal for objects of an
opaque type
within a client module (as well as in the implementation
module). Assignment is needed to be legal as it implicitly
takes place when a variable of an opaque type is passed as a
value parameter to a procedure within a client module.
REFERENCES
1. "Expressions in Modula-2", Brian Wichmann, "MODUS Quarterly"
Issue 3, pp. 35-42.
2. "Type Conversions in Modula-2", Brian Wichmann, "MODUS Quarterly"
Issue 6.
3. "All About Strings", Barry Cornelius, "MODUS Quarterly" Issue 6.
ELECTRONIC MAIL ADDRESSES
Any comments on these proposals can be sent to me at any of the
following electronic mail addresses:
Barry_Cornelius%mts.durham.ac.uk@UCL-CS.ARPA
Barry_Cornelius@uk.ac.durham.mts
bjc@uk.ac.nott.csXBR2D96D@DDATHD21.BITNET (Knobi der Rechnerschrat) (11/04/86)
Hallo,
here are my comments to the changes desribed in Barry's paper. I give comments
only for those topics were I especially agree or disagree. I take a neutral
position on all other items.
WG104: full agreement.
WG007: Why dropping them. OK, they are obsolete, but you have to change a lot
of existing software (see also my comments at the bottom of this).
WG106: (i) why not truncate if f > t?
(ii) keep the language simple !!!
WG131: full agreement.
WG035: full agreement (especially the remark about the names).
WG113: full agreement. (see also below)
WG115: same as WG007.
WG120: be carefull!! I like it, but is it really a good idea??
WG109: full agreement.
WG084: full agreement !!!!! (see also below)
------------------------------------------------------------------------------
Here are two comments on the whole standardization item:
1.) a few days ago there was a posting to Info-Modula-2 (I can't remember
the senders name) which stated that the standardization team should avoid
changing the definition of the language whenever it is possible.
--> The posting is rigth. My opinion on this is: Even if it is necessary
to change the language definition, try to avoid it. How can somebody
expect to introduce M2 as a clean and convenient way to implement software
if he changes the proposed rules to often.
2.) I would extend the scope of 1.) to the developers of M2 too. I hate the
idea that a nice language should be changed only to (for example) allow
one-pass compilation. In this case it is better to implement the new
feature under a new name (e.g M3).
-----------------------------------------------------------------------------
Here some questions:
1.) Is it true that coroutines have been droppen in PIM-3? Why? Is it
because they are a question of the implementation? In this case they are
pontentially allowed. Or is it because N.W. doesn't like the ideas of
coroutines any longer? Then see my comment 2.) above.
2.) What is the exact syntax of the FORWARD declaration? Is it the same
(***** self-zensored *****) thing as in PASCAL, or is there a better syntax
this time?
Regards
Martin Knoblauch <XBR2D96D@DDATHD21.BITNET>hinrichs@unc.UUCP (Klaus Hinrichs) (11/05/86)
The following proposals we find acceptable, though we don't have a strong opinion of most of them: WG104, WG007, WG086, WG012, WG099, WG132, WG089, WG041, WG074, WG080, WG050, WG051, WG056, WG003, WG061, WG114, WG115, WG116, WG120, WG102, WG121, WG122, WG109, WG110. The following proposals we explicitly welcome: WG088, WG126, WG015, WG131, WG034, WG075, WG117, WG069. The following proposals we find problematic or of dubious value: WG106, case (ii): We believe that this would be too big a change. Like it or not, Modula-2 is a spartan language, equipped only with minimum features. A UCSD-Pascal-like string type would be contrary to the general philosophy of the language. Proposal WG106, case (i) we agree with. A shorter name should be found for StringTerminator. EOS, end of string, is one possibility. WG035: What are "the constants N and W"? WG073: What's the use of returning pointers, when they cannot be de- referenced? If there is no way they can be used, returning them should not be allowed. the same holds for PROCEDURES, RECORDs and ARRAYs. WG113: Does that mean, the language should not allow one-pass compilation? Whether or not one-pass compilers are a good idea is probably a matter of taste, fact is that they will need the FORWARD construct. Excluding this from the language means, however, that it is impossible to keep certain programs portable. The standard should enhance portability of Modula-2 programs, not prevent it! WG118: Why should MIN and MAX not work for REALs? What is the "other mechanism to deliver the various characteristics of the type REAL"? WG119: SIZE should accept type parameters as well as variable parameters. There should be no TSIZE. WG085: The NEW and DISPOSE procedures do have the undesirable effect of producing side effects. However, they have one great advantage: they are safe. It is a bad idea to make the user responsible for something, the compiler can (and should) do. WG084: We prefer to have both possibilities. If an export list is given only the identifiers listed in the export list are exported. If the export list is omitted all identifiers defined in the definition module are automatically exported. WG110: We support these proposals. However we would like to point out the necessity of exporting constants of opaque types, at least a null value (e.g. "CONST Null = OpaqueType (NIL);") should be exportable. Ed Biagioni Gernot Heiser Klaus Hinrichs Peter Schorn seismo!mcnc!unc!biagioni biagioni@cs.unc.edu mcvax!cernvax!ethz!gridfile seismo!mcnc!unc!hinrichs hinrichs@cs.unc.edu seismo!mcnc!unc!schorn schorn@cs.unc.edu
paul@vixie.UUCP (Paul Vixie Esq) (11/07/86)
In article <163@unc.unc.UUCP> hinrichs@unc.UUCP (Klaus Hinrichs) writes: > > [...] Proposal WG106, case (i) we agree with. A shorter name should be >found for StringTerminator. EOS, end of string, is one possibility. Yes! >WG073: What's the use of returning pointers, when they cannot be de- >referenced? If there is no way they can be used, returning them should not be >allowed. Pointers can be dereferenced, but the pointer value returned from the function must be put into some variable somewhere first. Thus x := foo()^.bar; is not a valid expression, but z := foo(); x = z^.bar; is quite acceptable. >WG113: Does that mean, the language should not allow one-pass compilation? > [...] The standard should enhance portability of Modula-2 programs, not >prevent it! Agreed. Put FORWARD into the language. Wirth likes it. I like it. >WG119: SIZE should accept type parameters as well as variable parameters. >There should be no TSIZE. Oops, what about times when you have a variable and a type of the same name? They are in different namespaces, and are allowed to duplicate without collision. You need different syntax to refer to the different namespaces. >WG085: The NEW and DISPOSE procedures do have the undesirable effect of >producing side effects. However, they have one great advantage: they are >safe. It is a bad idea to make the user responsible for something, the >compiler can (and should) do. Safe from what? NEW causes an implicit ALLOCATE call, and DISPOSE causes an implicit DEALLOCATE. If you don't import these two functions from somewhere, your code won't compile. Leave the magic out! If there were a standard macro preprocessor for M2, people could do NEW and DISPOSE as implicit ALLOCATE and DEALLOC calls themselves... if you must have magic, make it more generally available and usable. >WG084: We prefer to have both possibilities. If an export list is given only >the identifiers listed in the export list are exported. If the export list is >omitted all identifiers defined in the definition module are automatically >exported. This could have surprising side effects. Defining part of a language as "if you don't mention this subject, I'm going to do all kinds of things without telling you" is very dangerous. If you want a way to "export all identifiers", find an EXplicit syntax for it... >Ed Biagioni seismo!mcnc!unc!biagioni biagioni@cs.unc.edu >Gernot Heiser mcvax!cernvax!ethz!gridfile >Klaus Hinrichs seismo!mcnc!unc!hinrichs hinrichs@cs.unc.edu >Peter Schorn seismo!mcnc!unc!schorn schorn@cs.unc.edu -- Paul A. Vixie arpa: paul@vixie.UUCP, nike!ptsfa!vixie!paul@seismo.CSS.GOV San Mateo, Calif uucp: {ptsfa,qantel,fortune,crash,winfree}!vixie!paul
c60a-2jm@tart12.BERKELEY.EDU (Adam J. Richter;260E;;) (11/09/86)
In article <191@vixie.UUCP> paul@vixie.UUCP (Paul Vixie Esq) writes: >In article <163@unc.unc.UUCP> hinrichs@unc.UUCP (Klaus Hinrichs) writes: >>WG119: SIZE should accept type parameters as well as variable parameters. >>There should be no TSIZE. > Oops, what about times when you have a variable and a type of the > same name? They are in different namespaces, and are allowed to > duplicate without collision. You need different syntax to refer > to the different namespaces. Nope. Names completely eclipse each other. If you have a type X that is eclipsed by a variable X, then TSIZE (X) would produce an error. -- Adam Adam J. Richter ...ucbvax!miro!richter 2504 College Avenue \ richter@miro.berkeley.edu Berkeley, CA 94704 >= May change soon (415)549-9672 /