Subject: SC22N2855 - Vote Summary on FCD 13211-2: Prolog Modules

From: William Rinehuls <[email-masked]>
Date: Tue, 8 Dec 1998 18:37:52 -0500 (EST)

_______________________ 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
N2855

TITLE:
Summary of Voting on Final CD Ballot for FCD 13211-2:  Information
technology - Programming languages - Prolog, Part 2: Modules

DATE ASSIGNED:
1998-12-08

SOURCE:
Secretariat, ISO/IEC JTC 1/SC22

BACKWARD POINTER
N/A

DOCUMENT TYPE:
Summary of Voting

PROJECT NUMBER:
JTC 1.22.22.02

STATUS:
WG17 is requested to prepare a Disposition of Comments Report and make a
recommendation on the further processing of the FCD.

ACTION IDENTIFIER:
FYI to SC22 Member Bodies; ACT to WG17

DUE DATE:
N/A

DISTRIBUTION:
Text

CROSS REFERENCE:
SC22 N2737

DISTRIBUTION FORM:
Def

Address reply to:
ISO/IEC JTC 1/SC22 Secretariat
William C. Rinehuls
8457 Rushing Creek Court
Springfield, VA 22153 USA
Telephone:  +1 (703) 912-9680
Fax:  +1 (703) 912-2973
email:  [email-masked]

__________________ end of title page; beginning of vote summary ______

                     SUMMARY OF VOTING ON

Letter Ballot Reference No:  SC22 N2737
Circulated by:               JTC 1/SC22
Circulation Date:            1998-07-23
Closing Date:                1998-12-07

SUBJECT:  Final CD Ballot for FCD 13211-2: Information technology -
Programming languages, Prolog, Part 2: Modules

----------------------------------------------------------------------
The following responses have been received on the subject of approval:

"P" Members supporting approval
       without comments                     10

"P" Members supporting approval
       with comments                         1

"P" Members not supporting approval          1

"P" Members abstaining                       5

"P" Members not voting                       5

"O" Members supporting approval
       without comments                      1

"O" Members abstaining                       1

Other JTC 1 Members supporting approval
       without comments                      1

-----------------------------------------------------------------------
Secretariat Action:

WG17 is requested to prepare a Disposition of Comments Report and make a
recommendation on the further processing of the FCD.

The comment accompanying the abstention vote from Denmark was:  "Due to
lack of Danish expertise."  The comment accompanying the abstention vote
from France was:  "Due to lack of resources."  The comment accompanying
the abstention vote from the Netherlands was:  "Due to lack of National
response."

The comments accompanying the negative vote from Germany and the comments
accompanying the affirmative vote from the U.S.A. are attached.

_________ end of overall summary; beginning of detailed summary ______

                 ISO/IEC JTC1/SC22  LETTER BALLOT SUMMARY

PROJECT NO:    JTC 1.22.22.02

SUBJECT:  Final CD Ballot for FCD 13211-2: Information Technology -
          Programming Languages - Prolog, Part 2: Modules
          
Reference Document No:  N2737           Ballot Document No:  N2737
Circulation Date:       1998-07-23      Closing Date:  1998-12-07
                                                              
Circulated To: SC22 P, O, L             Circulated By: Secretariat

                  SUMMARY OF VOTING AND COMMENTS RECEIVED

                     Approve  Disapprove Abstain Comments   Not Voting
'P' Members

Australia               (X)      ( )       ( )       ( )       ( )
Austria                 ( )      ( )       ( )       ( )       (X)
Belgium                 ( )      ( )       ( )       ( )       (X)
Brazil                  ( )      ( )       (X)       ( )       ( )    
Canada                  ( )      ( )       (X)       ( )       ( )
China                   (X)      ( )       ( )       ( )       ( )
Czech Republic          (X)      ( )       ( )       ( )       ( )
Denmark                 ( )      ( )       (X)       (X)       ( )
Egypt                   ( )      ( )       ( )       ( )       (X)
Finland                 (X)      ( )       ( )       ( )       ( )
France                  ( )      ( )       (X)       (X)       ( )
Germany                 ( )      (X)       ( )       (X)       ( )
Ireland                 (X)      ( )       ( )       ( )       ( )
Japan                   (X)      ( )       ( )       ( )       ( )
Netherlands             ( )      ( )       (X)       (X)       ( )
Norway                  (X)      ( )       ( )       ( )       ( )
Romania                 ( )      ( )       ( )       ( )       (X)
Russian Federation      (X)      ( )       ( )       ( )       ( )
Slovenia                ( )      ( )       ( )       ( )       (X)
UK                      (X)      ( )       ( )       ( )       ( )
Ukraine                 (X)      ( )       ( )       ( )       ( )
USA                     (X)      ( )       ( )       (X)       ( )

'O' Members Voting

Korea Republic          (X)      ( )       ( )       ( )       ( )
Portugal                ( )      ( )       (X)       ( )       ( )

Other JTC 1 Members Voting

Kenya                   (X)      ( )       ( )       ( )       ( )

_________ end of detail summary; beginning of USA Comments _________

From:  Matthew Deane ([email-masked])

SUBJECT:  US vote on ISO/IEC FCD 13211-2

The US National Body votes to APPROVE WITH COMMENTS.

Please see the comments below.

The US National Body votes to approve ISO/IEC FCD 13211-2: Information
Technology - Prolog - Part 2: Modules with comments:

The US considers that the ability of a Prolog program to introspect itself
is an important property of the language.  Requiring all of the
conventions listed in 7.5.3 inhibits this.

We favor a minimalist approach in which only the first conversion 7.5.2.1
takes place.  The compromise of 7.5.3 is thus acceptable to us.

___________ end of USA Comments; beginning of Germany Comments ______
 
From: BADENMUELLER <[email-masked]>

DIN-votes on document FCD 13211-2 with "NO WITH COMMENTS".

Comments on Final Committee Draft ISO/IEC 13211-2
=================================================

The document ends with
" Provisional End of German Comments "

General
=======

These Comments consist of two parts:

Pt. A: General statements on questionable basic concepts of the Draft:
the still-to-solve contradiction between the one- vs two-qualifier 
appproach. These are compatible with, but extend the German Comments 
on the former ISO/IEC 13211-2 Prolog Committee Draft. 
Pt. B: Editorial and technical comments on the Draft as it is. These are
NEW and are marked alternating as:

E editorial
T technical
R rationale

Due to time restriction we couldn't complete our comments.
These shall be completed until 6th Jan. 99. The remainder will extend (not
modify) the current Comments and will be sent to WG17 experts and X3J17
directly on Jan. 6th.

A	General Statements
==========================
In spite of many improvements and agreements, this Draft has not yet
solved the principal problems in the approach on context dependent
effects and the predicate qualification. Therefore Germany  will vote with
NO, as long as these contradictions aren't resolved. They significantly
damage the overall quality of the standard. Even if a majority of the
world's Prolog implementations would currently follow this approach (what
is not the case), a suchlike concept must not be standardized. 
these are: 

problem a): 
one qualificator and thereby context dependent calling and lookup
context vs: separate, unique qualificators for calling and lookup context

problem b): 
meta qualification at argument places in procedure signatures respectively
predications/activators vs: qualification outside a predication for lookup
and call, acting on all meta arguments of meta procedures. The Draft makes
interpretation of module qualification at argument places ambiguous.
Moreover it is too permissive with consequences not to preview by
potential programmers.

problem c):
negligence of most other context dependent effects by this concentration
on argument lists, especially in term i/o.

problem d):
The high complexity of the requirements.
The resulting modules standard must become by far simpler than the current
one. Especially clause 7.5 is not understandable for us; it containts a
lot of inconsistencies and non-defined terms. We guess that implementers
and users hardly could understand such a semantics description. This
should be corrected and improved significantly. Germany will try to
contribute to a better definition of term-to-clause and clause-to-term
stuff under module conditions. 
We can't also agree on the current Draft if there is not a model
interpreter which realizes the basic mechanisms of the Draft. It has
proven, that standards which had not at least an accompanying model
implementation before formal completion, had later no practical influence
on the world's implementations.
We ask the other P-members what is better?
- short-term completion of the current, complex, unsatisfying standard,
which will then hardly be implemented?
- medium term completion of a compact, agreeable standard with more
chances to influence current implementations.

B Editorial, syntactic and semantic comments
============================================

3 Definitions

General (E):
The alphabetic ordered entries of the concepts are still in disorder.
Sometimes they start with the main concept (our preference), sometimes
with the amending concept. We propose uniqueness: Always start with the
main concept. In especially important cases there may be an entry
starting with the amended concept, but this shall only be a hint to 
the main entry.

some examples:
procedure, accessible instead of accessible procedure.
	(accessible is a feature of procedures) 
module, defining instead of defining module.
	(defining is a feature of a special module, 
	not all others, wrt. a predicate)
argument, extended
procedure, exported
etc etc, some dozens cases.

but NOT

context, calling instead of calling context
		calling context is a concept.
		the context calls nothing.
		
General (E): re-export or reexport shall be written uniquely througout the
standard.
		
3.1 (E) Would a procedure be accessible, if it could be modified, but not
activated by full qualification? There shall stand an "and" instead of
the "or" in the 3rd line. Qualified activation is the striking condition
in any of these cases.

3.2 (C)
activation means execution of precisely one procedure by an activator. A
goal consists of one or more activators and so cannot be activated,
because its no procedure. A goal may be executed with respect to a
database. The executed goal or procedure vs. the activated procedure.
Of course an entire goal is also a procedure, namely the procedure "," or
";" applied to some subgoals, but using "activation" for "," and ";" is
misleading. 

3.4 (E)
See 3 General

3.5 (T)
The module in whose module body or module bodies a procedure is defined
explicitely and entirely. (E) module, defining.

3.7 (E) procedure, exported

3.8 (T) import:
..to make procedures exported or re-exported by another module

3.9 (T) import, selective:
..of only certain explicitly indicated procedures..
R: "named" is the wrong suggestion ! It's only an atom.
..exported or re-exported by another module.

3.18 (E) metavariable
A variable occuring as a meta-argument.

3.19 (T) module
...and to import or re-export procedures from other modules
R: re-export is no subclass of export.

3.20 (E) module body
..together with import and other directives local to that module body
R: import is not the only body directive

3.21 (E) module, calling
Better: A module, in whose context the procedure is activated.
Hint: A predication is not prepared for execution and thereby cannot be
executed or activated.

3.22 (E) module directive
.. A term D which defines resp. affects module text...
R: The module directive after all creates the module!

3.25 (E) module interface
.. which specify the name, the exported resp. re-exported procedures
and exported metapredicates of a module.

3.26 (E) module, importing
..imported, so extending its context to search for a procedure.

3.28 (E) module name qualification
1) better: module qualification
2)..the qualification of a meta-argument or an activator ...

3.29 (E) module, re-exporting
A module which performs re-export according 3.47.
R: the termini imports and exports are misleading. A user may believe
that he has explicitly to import and to export, to realize re-export. An
explicit definition so should refer to make visible, as 3.47, and make
available, as in 3.6. But this is not needed due to 3.47.

3.33 (E) preparation..
2nd line also: Prolog text or module text..

3.34 (E) procedure, accessible .. here main definition.

3.36 (E) process
... prepared Prolog text OR module text..

3.39 (E) argument, qualified
see proposal on 3.28 (...module qualified * predication)

3.39-3.46  (E)
entity, qualified instead of qualified entity, etc (see General)

3.47 (E)
to make procedures, exported or already re-exported by another module,
visible in the re-exporting module ..making them available for import or
further re-export by other modules from the re-exporting module.
Hint:irrespectively whether this module is an importing one!

3.48 (E) The re-exportation by a re-exporting module
of a selected subset of indicated procedures, exported or re-exported from
another module (see 7.2.2.3).

3.48a (T) (This shall be a new definition to enable successive re-export
of the same procedure.):

re-export, successive: The re-export of a procedure PI
which is defined and exported by a module M and re-exported by a module N,
or re-exported by module N from a module N1 which successively re-exports
procedure PI from module M.

3.49 (E)  ...without using module qualification.

3.50 (E)...The set of visible procedures of a module M including built-in
procedures and control constructs.
R: "accessible" and "without module name qualification" is a
contradiction.

5.5 (E) Documentation
...implementation defined and implementation specific feature AS specified
in this ... and ...
R: Pt 1 is wrong also. After all an implementation specific feature is NOT
specified in the standard! Only, what this means. (cf 3.92 of Pt 1)

6.1 (E) Module text 1st para
...(1) module directives, (2) module interface directives, (3) body
directives, and (4) clauses of user-defined procedures and other
directives.
R: directives as :-multifile are still allowed!

6.1 (E) Module text last para
..Clause 7.2.3 defines body directives that can appear only in A body of a
module
R1: we may have multiple bodies
R2: there are no "new" directives!

6.2.1 (T) Operators (trailing to 1st para)
..writeq/2, if none of these operator definitions has been changed
before.

6.2.1 Notes 3 (T)

...it serves to determine the calling resp. lookup context. This question
is not trivial and the notation is misleading:

		M1				M2
					meta P
	predicate P 	predicate P
					   :
					   :
					call M1:P(Args).
					
In the following, "of" shall mean "in the visible database of"
Question: Does the call mean: call P of M2 in the context M1 (as 
described in the Note) or call P of M1 in context M2? It must be the
last, because which chance would remain, to call P of M1 from M2? But 
then Note 3 is wrong.
Note 3: ...it serves to determine the calling context...  contradicts to
7.1.1.3 ..if the principal functor is :/2...then lm(M,T) is the lookup
module.

Germany of course supports interpretation 7.1.1.3, possibly with
a different qualifier (to preserve historical implementations).

Again the prolog standardizers are caught in confusion obviously, due to
the sparse support by the  one qualifier model. 
Again is proven, that using two qualifiers is more simple, correct and
clear: M1::P@M2 calls P of M1 in M2, and M2::P@M1 calls P of M2 in M1,
and M1::P@M1 calls P of M1 in M1, wherever you are calling, e.g. in M3. 
You understand, why we so stick on two qualifiers!?
(We have used "::" as lookup context qualifier here, not to worry with
traditional ":"-s)

7.2 (E) Module text 2nd para
The heads of clauses in module text shall be implicitly module qualified
only by the module body (or lookup context) in which they appear.
R: context is used for calling so far, see 3.3.

7.2 (T) Module text 3nd para 2nd sentence
The second part of the sentence should be omitted. It refers to calling
contexts, which have nothing to do with lookup contexts, handled here.
Perhaps the first part should end as: ...do not require module
qualification for determining the lookup context. Moreover the second
halfsentence would be incomplete, because all the context dependent I/O
BIPS are missing. A write in one calling context may write differently
than in another calling context. We name this "context dependent
effects"!

7.2.0.1 (T) Before Note:
Then this Module Interface must exist (be prepared for execution)
in advance of the Prolog Text which incorporates the body of module user.

7.2.2.2 (T) 1st para
...makes the procedures indicated by EL available for import or re-export
by other modules.

7.2.2.2 (T) NOTES 1
Germany insists that the metapredicate designation automatically exports
the predicate. The metapredicate concept is useless if metapredicates
cannot be used in different calling contexts, i.e. in foreign modules. A
metapredicate call designating the lookup module of the metapredicate
(this is the other alternative) disables the applicability in a calling
context.  Additionally the Draft here doubles writing labour and
probability of mistakes (written in one, forgotten in other directive).

7.2.2.2 and 7.2.2.3  (E):
for uniqueness the PI-Exports should be named just PI in both 
7.2.2.2 and 7.2.2.3 paragraphs.
 PI = Predicate Indicators is better than EL (Export List)
 
7.2.2.3 (E) 2nd para.
This sentence isn't clear. What is the procedure of a procedure?

7.2.2.3 (T) 3rd para.
the non-selective re-export has been forgotten. PI Being a procedure of
module MM has been forgotten:
...No procedure...shall be the subject in MM of a re-export(N)(see
7.2.2.4) or a selective re-export(N, PI) from a module N distinct...

7.2.2.4 (T+E) 1st sentence:
...or a list of atoms denoting module names, specifies that...
...that the module M imports all the procedures exported or
re-exported by the modules NAMED by REM 

7.2.2.4 (E):
Extend and finish the  paragraph  after: .."available for import or
RE-EXPORT by other modules".  The rest, including the 2nd sentence, is
trash.

7.2.2.5 (E) metapredicate/1:
better: metapredicate(MI) where MI means Mode Indicators.
It is not always a list and thereby misleading.

7.2.2.5  (T) metapredicate/1

Topic: Metapredicate is not exported automatically in the Draft:

Demand: meta means export also at this place. 
A metapredicate shall be exported automatically, if it is designated
as such in the module interface. This is the only reason to hold it
in the interface. The interface is the interface to other modules,
which shall be agreed by a SWE team. If a predicate is designed
to be meta but not exported, it is misleading to bring it into
the interface because it doesn't contribute to the interface. 
If it is meta AND exported there is no reason for two definitions
(meta plus export) which burden both, progammer and parser. 

7.2.2.5 (T) NOTE on metapredicate/1
Demand: meta means export also at this place.
NOTE: see Comment on 7.2.2.2 NOTES 1  (metapredicate exported
automatically)

7.2.3.2 (T) Directive import/2, 2nd paragraph:

...shall be a procedure exported or re-exported successively by the
module M.

7.2.3.2 (T) Directive import/2, 3rd paragraph:

...shall be the subject of an import directive import(N) (see 7.2.3.3) or
a selective import directive import(N, PI) from a module N distinct from
M, if this procedure has not been re-exported by successive re-export (see
3.48a) from M by N.

(R): a procedure PI which stems from M and has been re-exported by N1 and
then re-exported by N2 from N1 and so on, finally stems from M and so
mustn't lead to an indicator's clash.

7.2.3.2 (T) Directive import/2, last paragraph:
.. or a built-in predicate nor shall be defined explicitly in another body
of the importing module, already prepared for execution.

7.2.3.3 (T) NOTES 2,3,4,5 are standard requirements and shall not be
NOTES. Hint: take in mind the complex logics of successive re-exports of
the same procedure, as in 7.2.3.2. Don't forget the clash of an imported
procedure with a (possibly scattered) explicitly defined procedure with
same PI inside an, already prepared, different one of the bodies of the
importing module: It shall also be forbidden, if module body B1 of M1
imports a procedure P1/A1 explicitly, and module body B2 of M1 imports a 
different procedure P1/A1 from outside. The clash shall occur with the
second event, following preparation for execution.

7.2.3.4 (E) 2nd para, 1st sentence:
remove "implementation defined"

7.2.3.4 (E) 2nd para., after 2nd sentence.
Remove the dot after module.

7.2.3.4 (E) 2nd para, after 2nd sentence

.. of all the subsequent bodies of module M.... still unclear.
Proposal: ...of all the subsequent bodies of module M, starting with
the body prepared as next. The effect of directives op...flag/2, in
any body shall alter the current state and so accumulate during
the preparation....

7.2.4 (E) 2nd para, 1st sentence
remove full-stop after Clause. The entire sentence is horrible.
..A clause of a clause term shall be an unqualified term which is a 
clause term...

7.2.4 (E) 2nd para, 1st sentence
M:assertz(Clause) is no built-in predicate but an activator of
the BIP, seemingly in the (lookup vs calling?) context of M.

7.2.4 (T) 2nd para, 1st sentence
(8.4.2) "except that no error shall occur because Clause refers
to a static procedure"

This fragment is wrong and misleading. 
I guess the meaning, "during preparation for execution no such error
may occur", because an error is a runtime feature. Someone could
deduce, that no error occurs because the procedure is a static 
one, and an error would occur only with dynamic procedures.
During preparation for execution no error may occur at all, only
violations (of syntax resp. static semantics). At runtime, during
activation of I/O predicates,a syntax violation may lead to an error, 
which then is syntax_error, cf 7.12.2 (i).
But built-ins and control constructs are well static procedures, 
and extending them is of course a violation.

Attempt of a Formulation: ...shall satisfy the same constraints
as those required for an execution of the activator
M:assertz(Clause), with exception that only violations, but 
not errors are possible during preparation for execution.

The adequate violations are:
syntax violation
attempt to extend a built-in predicate or a control construct by 
	a clause
name clash with an previousy imported or re-exported procedure
(These cases are handled with the next paragraph correctly).
	
7.2.4 (E) 2nd para, 1st sentence vs. last sentence.
A clause Clause ..... 
shall be converted to a clause h:-t. Why to convert it, if it is
already a clause?

7.3  (E) last para
...where the module name of the qualified predicate indicator
DENOTES the defining module of the procedure.
Note: module qualification is not defined, module name qualification
means something different!

7.3.1 (T) last para
..and all procedures imported resp. re-exported into M

7.4 (E) Metapredicates

If the Metapredicate Built-ins are listed, then the Metapredicate
control constructs also should be listed at this place.
Which difference is, e.g. between once(:), \+(:), and call(:),
catch(:,*, :)? 

Moreover all the context dependent predicates are metapredicates also
and are missing:

op/3, current_op/3
read_term/2/3
read/1/2
write_term/2/3
write/1/2
writeq/1/2
char_conversion/, current_char_conversion/2

These predicates are not metapredicates in the sense of 7.4, but also
depend on the calling context. Therefore we have to define them here
and not to forget them. See the DIN Paper on context dependent effects
from 15th Apr 97.

7.4.2 (T) 2nd para
replace "goal" by "activator", because the call of metapredicates is
meant. The main functor of a goal may be "," or ";". 
(act1,act2;act3..) is a general goal, whereas an activator (or, if
not prepared, a predication) activates precisely one (meta-) procedure,
which is the single context dependent entity.
Replace "unqualified term" by "unqualified callable term". An unqualified
term may also be the number 10.

To be remembered:
A term is the most general syntactic class containing the subclass 
  callable-term.
a callable term we name a goal resp. a predication ( 1-procedure goal)
a prepared predication is an activator, which precisely activates  
1 procedure. The call resp. the state of the called, not yet refuted
procedure we name activation. The moment of call is the activation point.

7.4.2.1 (E) List processing of argument list

Make a note which states that the argument list is no list in the
sense of 6.3.5 (Pt 1). The argument list is not representable as
.(Arg1, .(Arg2, .(ArgN,[])))! 

7.4.3.2 (T) Examples erroneous:

activators at the end of example:
foo:p(3).
succeeds,
writing 3

bar:p(3).
succeeds,
writing 3

It isn't quite clear, why so much and complicated modules are needed 
for the simple activators? We would expect now very twisted activators.

7.4.3.3 (E) Example worrying:

Again: activators at the end of example.

a) add information on the calling module:

The goal:
sort([3,2,1], L).
should be inside a module mod1 importing resp. re-exporting  module 
   ,sort_with_errors 
fails, writing...
(R) Elsewhere sort is not known and thereby not callable.
   
b) make a NOTE on the variables _A resp _B, which are system internals and
of no significance for this example. It is also not natural,
that _A and _B occur in both written lines. _C and _D were better.

7.5 (E) 1st para
Double meaning of clause in the last two adjacent sentences, which is
misleading. Proposal last sentence: This paragraph defines how the...

7.5.1 (T) 1st para
..which is the head H of a clause with lookup module MM:
The DEFINING module MM is correct.  The lookup module is the space where 
a clause is looked up, but where (due to importing or re-exporting)
may exist no clauses at all.

7.5.1 (T) clause b)
the defining module MM is the module M of (M,T)

Remark: The defining module always defines all there entirely defined
procedures and their features, and not more. The lookup module is the 
module of certain visibility space, where the attention lies on
all visible predicates. We could e.g. imagine a lookup module as an interface
consisting from merely re-exports without body (in realistic cases). 
The calling context is the module where the conversion happens.

The question arises: When a clause term is converted to a clause, in
which defining module's body stands the clause? This question is not
answered by proclaiming a lookup module.

7.5.2 (E) Headline
Converting a term to an activated goal

7.5.2 (T) general
..converting for control constructs, for visibility
What means "to convert for something"

7.5.2 (T)
1) What is the defining module DM of a module M? Only a procedure may
have a defining module.

2) What is an activated goal? We guess, a term which shall be a goal if
prepared for execution. Would have to be defined. But, is the goal activated
immediately after preparation for execution? What if the second activator 
is a non-callable? We guess that the time distance between conversion point and
activation point should be implementation specific.

3) (a) What is a body BG with module qualifications? Where are the module
qualifications?  This concept is not defined.

4) (c) What are terms that denote metapredicates? Only an activator
   may activate a metapredicate. Then the predicate indicator
   of its predication must be that of the metapredicate.

7.5.2.1 (E) 1st para
again: what is a calling module M with defining module DM? There are
only defining modules of procedures.

7.5.2.1 (E) a) 2) last line
arguments if, if any, ... (omit one if)

7.5.2.1 (T) a) 2) general
What about once/1, +\/1 ?
Why aren't the arguments, if any, converted for control constructs
also, as in the following paragraph 3)?

7.5.2.1 (E) a) 3)1st/2nd line
one of the control constructs one of the control constructs

7.5.2.1 (E) a) 4) 2nd line
table 8 of ISO 13211-1 is table 9!

7.5.2.1 (T) a) 4) general
If FT is the predicate indicator of a metapredicate,
why haven't the arguments of T to be converted for control 
constructs as in 3) ?

7.5.2.1 (T) b) 
is a qualified Term M:(current_module(X),current_predicate(Y),
 write(X), write(Y),nl).
possible at all? (which is M:','(current_predicate(X,Y),','(...))

7.5.2.1 (T) c) 2nd line
M seems to be the qualification of the qualified term. This is said
nowhere.
The resolution of the qualifications of the arguments (if any) of
the  qualified term T contradicts to 7.5.2.1 a) 3) .
If we follow 7.4.2.2 of this draft, then
every qualified subterm has to be resolved according to its own
local qualification, not to the qualification of the principal functor
of the callable term containing it as a subterm.
Or does the "great M" qualification following 3), override the 
"local M-s" qualifications?

7.5.2.2 (T) b) 2) 
What again with once/1 and +\/1 ?

7.5.3 (T) 1st line
"implementation defined" means that every implementation must describe
this feature, prepared in the standard, in its accompanying documentation.
We guess, that "implementation dependent" is the right case here.

7.5.4 (E) 1st para vs. a, b, c, d:

are the statements if....then  of a, b, c, d the condition for the 
conditional clause of the 1st para? Or are they conditionals and 
corresponding conditions by themselves?

Example: 
I can leave my home without umbrella:
a) if it isn't raining, then I need no rain coat.
b) if the wheather forecast promised sunshine, then my wife is happy.
c) if I have a rain coat, then I need no other jacket.
d) if I go by car, then I need gasoline.

7.5.4 (E) Note and
7.5.5 (T) Examples 1st para

What is a FULLY activated goal? An activated goal (3.2) has been
activated when it is called for execution. Is it then possible,
to call it PARTIALLY for execution?
Perhaps is meant a partially or fully converted term?

7.5.5 (T) Examples 2nd para

what makes foo to a calling, m to a defining module? Is it the
context?
What if... m1:myasserta(m2:myasserta(X):-baz(X)).. is activated?
myasserta/1 may be any context dependent predicate.

Is it then still clear, that m1 is the calling, m2 the defining module?

7.6.1 (T) definition of decorated subgoal

contextmodule: - an atom identifying the module in which 
WHAT subgoal is being called? The entire decorated subgoal?
The first activator of the decorated subgoal?

7.6.3 (T) general

Calling a procedure in a module system starts with two cases:
a) it is a "visibility call": all procedures defined, imported,
re-exported in the lookup module are visible without qualification.
But this visibility call is only a special call of a more general one:
b) The qualified call. Here the lookup module of the called procedure is
given explicitly. 
The visibility call should be handled as special case of the qualified
call, with lookup module = calling module. Then only the semantics of
the qualified call needs to be defined, and the visibility call refers
to it.  The qualified call must not be forgotten because is the basic and
thereby most important one.

7.6.4 (T) a) complexity contradiction
what if the processor finds 2 different procedures p
with same predicate indicators, searching through the complete database?
It has only to search through the visible database. Better is the
reverse approach: replace the (unqualified) search through a visible
database by a qualified search through the visible database, i.e.
unqualified visibility lookup is a special case of qualified 
lookup where the qualification is the calling context.

7.6.7 (T) 2nd para
What about the (term) input/output built-in predicates, where the calling
module directs which of the module specific char_conversion and operator 
definitions currently hold?

7.7.1.1 1st para
what iff G represents a goal which is true in one module and fails in 
another? Better: ..which is true in the calling context of module CM.
Or (more elegantly but less precisely): In the calling context of module 
CM, call(G) is true iff G represents a goal which is true.

7.7.1.1 (T)  NOTE
a note is no standard requirement. A processor may then be standard
conforming, if once/1 and \+/1 don't satisfy the NOTE's demand?
By the way, once/1 is not re-executable.

7.7.2.1 (T) 1st para
In the calling context of module CM catch(G,C,R) is true iff (1)...

7.8 (E) 1st para
...of proceduresS...
...Module:Goal (8.2.2) 

7.8  (E) last but one para
... - The module with name DefiningModule is the defining module (3.5 **)
if the procedure.
Hint **: 3.5 should only contain the hint to "module, defining"

8.2.2.1 (T) 3rd para: a:

Determines the lookup module MM of (M, Prototype)... is wrong.
There may be many lookup modules MM of Prototype (every one which
has imported/re-exported Prototype).
It should determine the defining module of (M, Prototype)
There is only one.

Provisional End of German Comments

________________ end of SC22 N2855 _________________________________