Subject: SC22 N2457 - Comments Disposition on CD 10514-2 - Modula-2

From: "william c. rinehuls" <[email-masked]>
Date: Wed, 23 Apr 1997 18:27:34 -0400 (EDT)

_________________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:  [email-masked]

__________________ 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 ______________________