From rinehuls@access.digex.net Fri Jun 21 23:04:21 1996 Received: from access2.digex.net (qlrhmEbBUV1EY@access2.digex.net [205.197.245.193]) by dkuug.dk (8.6.12/8.6.12) with ESMTP id XAA28914 for ; Fri, 21 Jun 1996 23:04:19 +0200 Received: from localhost (rinehuls@localhost) by access2.digex.net (8.6.12/8.6.12) with SMTP id RAA15955 ; for ; Fri, 21 Jun 1996 17:04:13 -0400 Date: Fri, 21 Jun 1996 17:04:12 -0400 (EDT) From: "william c. rinehuls" X-Sender: rinehuls@access2.digex.net To: sc22docs@dkuug.dk Subject: Document SC22 N2171 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Note: I never received this document from the SC22 reflector. It could have been that something went awry when it was transmitted. In the event that others of you may also have not received it, I am sending it again. Best wishes Bill Rinehuls ____________________________________________________________________________ ISO/IEC JTC 1/SC22 Programming languages, their environments and system software interfaces Secretariat: U.S.A. (ANSI) ISO/IEC JTC 1/SC22 N2171 June 1996 TITLE: Summary of Voting on CD Registration for: Modula-2 Extensions for Systems Programming SOURCE: Secretariat, ISO/IEC JTC 1/SC22 WORK ITEM: JTC 1.22.18.04 STATUS: N/A CROSS REFERENCE: SC22 N2069 DOCUMENT TYPE: Summary of Voting ACTION: The CD has been registered as CD 10514-2. To SC22 Member Bodies for information. To WG13 for preparation of a Disposition of Comments Report and a recommendation on the further processing of the document. Address reply to: ISO/IEC JTC 1/SC22 Secretariat William C. Rinehuls 8457 Rushing Creek Court Springfield, VA 22153 Tel: +1 (703) 912-9680 Fax: +1 (703) 912-2973 email: rinehuls@access.digex.net ___________________________________________________________________________ SUMMARY OF VOTINGON Letter Ballot Reference No: SC22 N2069 Circulated by: JTC 1/SC22 Circulation Date: 1996-02-14 Closing Date: 1996-05-30 SUBJECT: CD Registration for: Modula-2 Extensions for Systems Programming The following responses have been received on the subject of registration: "P" Members supporting registration without comment 9 "P" Members supporting registration with comment 2 "P" Members not supporting registration: 2 "P" Members abstaining: 4 "P" Members not voting: 4 Secretariat Action: The CD has been registered as CD 10514-2. The comment accompanying the affirmative vote from Austria was: "ON recommends to adopt none of the suggestions in Annex 3." This comment and the comments accompanying the negative vote from the United Kingdom and the USA, and the comments accompanying the affirmative vote from Germany have been forwarded to SC22/WG13 for preparation of a Disposition of Comments Report and a recommendation on the further processing of the CD. ____________________________________________________________________________ ISO/IEC JTC1/SC22 LETTER BALLOT SUMMARY PROJECT NO: JTC1.22.18.04 SUBJECT: CD Registration for: Modula-2 Extensions for Systems Programming Reference Document No: N2069 Ballot Document No: N2069 Circulation Date: 02-14-1996 Closing Date: 05-30-1996 Circulated To: SC22 P, L Circulated By: Secretariat SUMMARY OF VOTING AND COMMENTS RECEIVED Approve Disapprove Abstain Comments Not Voting 'P' Members Australia (X) ( ) ( ) ( ) ( ) Austria (X) ( ) ( ) (X) ( ) Belgium ( ) ( ) ( ) ( ) (X) Brazil (X) ( ) ( ) ( ) ( ) Canada (X) ( ) ( ) ( ) ( ) China ( ) ( ) ( ) ( ) (X) Czech Republic (X) ( ) ( ) ( ) ( ) Denmark ( ) ( ) (X) ( ) ( ) Egypt ( ) ( ) ( ) ( ) (X) Finland (X) ( ) ( ) ( ) ( ) France ( ) ( ) (X) ( ) ( ) Germany (X) ( ) ( ) ( ) ( ) Japan ( ) ( ) (X) (X) ( ) Netherlands (X) ( ) ( ) ( ) ( ) Romania ( ) ( ) ( ) ( ) (X) Slovenia (X) ( ) ( ) ( ) ( ) Sweden ( ) ( ) (X) ( ) ( ) Switzerland (X) ( ) ( ) ( ) ( ) UK ( ) (X) ( ) (X) ( ) Ukraine (X) ( ) ( ) ( ) ( ) USA ( ) (X) ( ) (X) ( ) 'O' Members Argentina ( ) ( ) ( ) ( ) ( ) Bulgaria ( ) ( ) ( ) ( ) ( ) Cuba ( ) ( ) ( ) ( ) ( ) Greece ( ) ( ) ( ) ( ) ( ) Hungary ( ) ( ) ( ) ( ) ( ) Iceland ( ) ( ) ( ) ( ) ( ) India ( ) ( ) ( ) ( ) ( ) Indonesia ( ) ( ) ( ) ( ) ( ) Italy ( ) ( ) ( ) ( ) ( ) Korea Rep (X) ( ) ( ) ( ) ( ) New Zealand ( ) ( ) ( ) ( ) ( ) Norway ( ) ( ) ( ) ( ) ( ) Poland ( ) ( ) ( ) ( ) ( ) Portugal ( ) ( ) ( ) ( ) ( ) Russian fed ( ) ( ) ( ) ( ) ( ) Singapore ( ) ( ) ( ) ( ) ( ) Thailand ( ) ( ) ( ) ( ) ( ) Turkey ( ) ( ) ( ) ( ) ( ) Yugoslavia ( ) ( ) ( ) ( ) ( ) __________________________________________________________________________ From: Kutschke@NI.DIN.DE Fri May 17 11:45:14 1996 Date: Fri, 17 May 1996 15:09:18 +0100 From: Kutschke@NI.DIN.DE To: rinehuls@access.digex.net cc: ni22@gmd.de Subject: German votings on several subjects Dear Bill: this is to inform you about the German vote on SC22 Documents. 3. WG13, CD Registration of SC22 N 2069, deadline 1996-05-30, Modula-2 Extensions for systems programming: We support this registration with following comments: (a) All changes to the Base Standard should be collected in an annex, e.g.: the keyword GENERIC, the changes caused by a "refining Local Module Declaration", etc. (b) For all examples listed, it should be shown how a possible transformation (result of "pre-compilation") into Standard ISO Modula-2 would look like. (c) A note should be added to clarify that the types used for module parameters are not necessarily limited to the types mentioned in the Base Standard. (E.g. an implementation that supports both Generics and OO-M2 is expected to permit classes, too, as module parameters.) (d) Regarding Annex 3, p.36, DIN recommends to adopt NONE of the suggested extensions. ___________________________________________________________________________ >From 100434.3031@CompuServe.COM Thu May 23 12:10:22 1996 Date: 23 May 96 05:06:23 EDT From: Jean Stride <100434.3031@CompuServe.COM> To: Mr W C Rinehuls 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 To: Bill Rinehuls (rinehuls@access.digex.net) 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 ________________