From rinehuls@access.digex.net Thu Apr 24 00:27:40 1997 Received: from access5.digex.net (qlrhmEbBUV1EY@access5.digex.net [205.197.245.196]) by dkuug.dk (8.6.12/8.6.12) with ESMTP id AAA18483 for ; Thu, 24 Apr 1997 00:27:36 +0200 Received: from localhost (rinehuls@localhost) by access5.digex.net (8.8.4/8.8.4) with SMTP id SAA05035 for ; Wed, 23 Apr 1997 18:27:34 -0400 (EDT) Date: Wed, 23 Apr 1997 18:27:34 -0400 (EDT) From: "william c. rinehuls" To: sc22docs@dkuug.dk Subject: SC22 N2457 - Comments Disposition on CD 10514-2 - Modula-2 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII _________________beginning of title page _________________________ ISO/IEC JTC 1/SC22 Programming languages, their environments and system software interfaces Secretariat: U.S.A. (ANSI) ISO/IEC JTC 1/SC22 N2457 April 1997 TITLE: Disposition of Comments Report on CD Ballot for CD 10514-2: Information technology - Programming languages, their environments and system software interfaces - Generics in Modula-2 SOURCE: Secretariat, ISO/IEC JTC 1/SC22 WORK ITEM: JTC 1.22.18.04 STATUS: Upon receipt of the final text, the Secretariat will forward it to ISO/IEC ITTF for DIS ballot. CROSS REFERENCE: SC22 N2219, N2353 DOCUMENT TYPE: Disposition of Comments Report ACTION: To SC22 Member Bodies for information. Address reply to: ISO/IEC JTC 1/SC22 Secretariat William C. Rinehuls 8457 Rushing Creek Court Springfield, VA 22153 USA Tel: +1 (703) 912-9680 Fax: +1 (703) 912-2973 email: rinehuls@access.digex.net __________________ end of title page; beginning of text ________________ ISO/IEC JTC1/SC22/WG13 D247 Disposition of Comments on CD 10514-2 (Generics in Modula-2) Status: This document represents the results of discussions at the 12th meeting of ISO/IEC JTC1/SC22/WG13 at Linz, March 17-18, 1997. Summary: The proposal on Generics in Modula-2 generated a number of comments during CD Ballot. The purpose of this paper is to allow WG13 to respond back to the National Bodies. Format: The comments of the National Bodies are given in alphabetical order. They have been interspersed with the Working Group's responses. Austria 1) Although the various examples are considered very valuable, in particular the "preprocessed" files could cause confusion. It should be made perfectly clear that these examples show only one particular way to implement genericity. One possible solution might be to move all the examples to an Annex that is clearly marked as "informative" rather than "normative". Response: The suggested approximate translations into Standard Modula-2 were included as a result of comments on the last round requesting such translations. The project editor is directed to remove all these translations into Standard Modula-2 to an Annex and there to affix a note to clarify this is only one way to achieve the desired result. 2) It does not seem to be entirely clear from the document whether "refining implementation modules" are really necessary. They appear to be containing only information already present in the corresponding "refining definition modules". If there is a rationale for having these (almost empty) modules, it should be contained in the document. Response: Refining implementation modules were included so as to maintain the Base Language method of requiring both definition and implementation parts of a separate library module. A generic separate definition module can be refined and client programs translated in the light of this refinement prior to the refining of the generic separate implementation module, and even (in the usual case of refining to a separate module) before the generic separate implementation module has been written. This is the behaviour that users of the Base Language would expect. In addition, if the generic separate definition module contains an opaque type, the refinement of the associated generic separate implementation module is of its declaration of the item. The type remains abstract with respect to clients, but this behaviour allows the type to be transparent to local refinements in case additional procedures need to be written in the surrounding environment. The project editor is directed to add appropriate notes to this effect in the document. 3) Several editorial comments will be sent to the editor in a separate message. Response: The project editor is directed to make the necessary corrections pointed out in such remarks. Germany (a) Section 6.1.2, Example 3 (p. 14): Explain the abbreviation "ADT" (= abstract data type) as the Standard does not contain a glossary. Response: The project editor is directed to expand the abbreviation. (b) Annex 3 (Changes to the Syntax of the Base Language): Add another section "local module declaration" which contains the changes to section C.2.10 of the Base Standard." Response: The project editor is directed to make the necessary addition. Netherlands -1- In the concrete syntax (in the document and in Annex 4) one finds a definition of "refining local module declaration". However, one cannot find a place where this definition has been used. In particular, it can not be derived from the syntax whether these refining local module declarations can be nested within local modules. From the aforementioned definition one may derive that nested "refining local module declarations" are not allowed. This is not in the spirit of Modula-2 and a note to that effect should be added. Response: The clause in question is self contained and serves as an elaboration of the definition in question. The project editor is directed to clarify this fact in the clause in question. Refining modules cannot contain anything else at the present time. This is noted in a subsequent paragraph, but the list of exclusions, though intended to be comprehensive, does not specifically mention local modules. The project editor is directed to add local modules to the specific list of items that cannot be contained in a refining module, both here and in the section on refining separate modules. -2- In the definition of "refining local module declaration" the term "generic separate module identifier" has been used. However, a definition of that term can not be found. Response: The project editor is directed to add the line generic separate module identifier = identifier ; at the appropriate point in the document. -3- It seems that the naming system suggested in Annex 5 cannot handle the derivation of multiple versions of generic modules (e.g. ListsSorted). Response: The project editor is directed to add a note to the effect that multiple refinements would undoubtedly be required each to have unique file names. -4- The CD allows having partially refined modules with parameterization both at the local module level and at the global level. There is no mentioning of the order in which refinement should be done. A note to that effect should be added, even if there is no order prescribed. Response: The project editor is directed to add a note to the effect that the order of refinement is the same as the order of initialization would be once the modules are refined. -5- Semantic note 5 in section 6.3 states that "If the implementation part of a generic separate module contains refining local module, that refining local module cannot refine from the same generic separate module in which it is contained". It is not clear whether this rule covers cross refinement and whether rules for that situation need to be added. Response: A chain of refinements must stop somewhere,so two generic implementation modules could also not contain refiners to each other. The project editor is directed to add to the above sentence "... contained--whether directly or indirectly. That is, circular refinement is not permitted. The translator is required to detect and correct this error." -6- There seems to be an inconsistency in naming: Whereas Generic definition modules (and implementation modules) have to be tagged GENERIC, even if they do not contain any generic construct (see the Counter example), program modules containing local refinements (e.g. MODULE StackClient) do not need to be tagged GENERIC. Response: There is no inconsistency because a program module cannot contain anything generic whatsoever. It can only contain refiners, and refining modules have no keyword tag to mark them as such. -7- (Editorial) This CD version of the document expands on the previous version by giving more examples, in particular giving possible results provided by a hypothetical preprocessor. This expansion however, has introduced non-ISO wording such as "can", "must", "approximate" etc.. It is suggested that (i) all examples (except for the most basic one) are moved into informative annexes. Response: See the response to a similar point raised by Austria. (ii) the document be checked for non-ISO wording. Response: With the assistance of other members of WG13, the project editor is directed to check the document and remove or alter any such wording. (iii) wording related to object orientation (like inheritance and instantiation) be changed. Response: The project editor has checked the document and found that neither word occurs. The word "instantiate" occurs only in 3.1.4 where it is explained that it will not in fact be used. The word "inherits" is found once in connection with the relationship between the protection expression of a generic module and that of its refinements. The project editor is directed to rephrase this sentence so as to use the word "acquires." -8- (Minor editorial) Section 6.3 Example 5: ............(as shown in example 5)....... should read: ............(as shown in example 4)....... .............One first create a ......... should read: .............One first creates a ......... Response: The project editor is directed to make editorial corrections as appropriate. USA Comment accompanying the "NO" vote from the USNB: 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 inappropriate. Response: As stated in the responses to comments on the Base Language, and also in response to an identical comment on a previous version of this proposal, WG13 believes the Base Language is not flawed. Thus, WG13 believes that it is appropriate to consider extensions to the Base Language. The current comment does not identify any specific new issues not already dealt with in the responses to comments on the Base Language and that require a new response. __________________ end of document SC22 N2457 ______________________