From: Jean Stride <[email-masked]>
Date: 23 May 96 05:06:23 EDT

N2069 CD Registration Ballot (Systems Programming extensions),

 Unless the following objection is resolved:
1) There is concern that this proposal ties generic types to modules 
rather than to types or classes. Modules begin to look like value-
based objects. This change from module philosophy is clearly 
demonstrated by the example of a counter. The Panel remains 
concerned that there should be a way to introduce generic types 
through types or classes in future work.
 
The following comments also pertain:
2) The proposal suggests that a generic module may be refined as a 
dynamic module. The Panel seeks confirmation that this is the 
intention.
 
3) The diagram in 6.1.7 Module Dependencies is believed to be 
erroneous and should be replaced by:
Generic Definition -> Generic Implementation -> local refinement
|		|
\/		\/
Refining Definition -> Refining Implementation
|
\/
Importer of (separate) refined module
 
4) The use of the word IMPORT to flag the use of a generic module 
name elsewhere in the module leads to confusion with genuine 
import. For example: M.F is legal as a reference to the imported entity 
F of the imported module M, but illegal if M refers to a generic 
module. Is the following module legal?
 
MODULE Main;
IMPORT Counter;
VAR Counter: INTEGER;
 
MODULE Counter1 = Counter;
END Counter1;
 
MODULE Counter2 = Counter;
END Counter2;
..
END Main.
 
The Panel recommend the omission of the word IMPORT for this 
purpose, or its replacement with some other keyword, and prefers 
omission.
 
5) The generic features as presented appear to provide many facilities 
that are provided equally well by the current object-oriented 
proposal (apart from having value based semantics for objects and a 
kind of multiple inheritance. The Panel is concerned at the overlap of 
facilities and that by providing facilities missing from the current 
object-oriented proposal this proposal might encourage a mixed 
programming style and obstruct the future evolution of the object-
oriented extensions.
 
6) Since a refinement of a generic module must not have a body the 
requirement to have an END clause is redundant. The Panel 
recommends that the END clause be omitted for such refinements (n 
a manner analogous to a FORWARD procedure.
 
7) The current proposal requires that the identifiers of parameters to 
a generic definition module match those of its corresponding generic 
implementation module. This is different from the rule for procedure 
parameter names between definition module and implementation 
module. The Panel asks the rationale for this new rule.
 
8) The Panel recommends that none of the suggestion in Annex 3 be 
adopted.
 
9) The Panel observes that a means of consistency checking is 
provided for constant parameters but not for types. The Panel 
deprecates this inconsistency of consistency checking.
 
_________________________________________________________________________
FROM:  MICHELLE MAAS <[email-masked]>
To:  Bill Rinehuls ([email-masked])

Subject:  FW: US Vote on SC22 N 2069

Bill,

Please consider this E-Mail message as the USNB response to document JTC
1/SC22 N2069 - CD Registration Ballot for: Modula-2 Extensions for Systems
Programming.

The USNB DISAPPROVES the CD Registration for the following reason:  As the
USNB has indicated in its earlier balloting on what is now ISO/IEC
10514-1, Programming Languages, Modula-2, the USNB believes that that
International Standard is badly flawed; accordingly, extensions to that
International Standard are inapprorpriate.

Best regards,
Michelle Maas
For the US P=member of JTC 1/SC22

_______________________________end of document N 2171 ________________