

The NNi approves document ISO/IEC JTC1/SC22/N2219 (CD ballot for CD
10514-2, Modula-2 Extensions for Systems Programming) with the following
comments:

-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.

-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.

-3-
It seems that the naming system suggested in annex 5 cannot handle the 
derivation of multiple versions of generic modules (eg ListsSorted). 

-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.

-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.

-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.

-7- (Editorial)
This CD version of the documents 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.

(ii) the document be checked for non-ISO wording.

(iii) wording related to object orientation (like inheritance and
instantiation) be changed.

-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 .........

_____________________ end of SC22 N2353 ____________________________