Subject: N2929 - Disposition of Comments Report for FCD 13211-2: Prolog Modules

From: William Rinehuls <[email-masked]>
Date: Mon, 17 May 1999 18:19:12 -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
N2929

TITLE:
Disposition of Comments Report for FCD 13211-2: information technology -
Programming languages, their environments and system software interfaces -
Prolog, Part 2: Modules

DATE ASSIGNED:
1999-05-17

SOURCE:
Secretariat, ISO/IEC JTC 1/SC22

BACKWARD POINTER:
N/A

DOCUMENT TYPE:
Disposition of Comments Report

PROJECT NUMBER:
JTC 1.22.22.02

STATUS:
N/A

ACTION IDENTIFIER:
FYI

DISTRIBUTION:
Text

CROSS REFERENCE:
N2855

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 report ___________________

                    DISPOSITION OF COMMENT REPORT
                      ISO/IEC FCD 13211-2 PROLOG
                       PROLOG: PART 2 - MODULES

INTRODUCTION.

An FCD (Final Committee Draft) for ISO/IEC 13211-2 (Prolog: Part 2 --
Modules) was published in May 1998, distributed to SC22 WG17 as N159  (and
as SC22 N2264), with a ballot to register it as a final committee draft.

The ballot was successful but some changes are desirable before the DIS
(Draft International Standard) is published. The full voting is below and
the submitted comments are appended together with a 'Disposition of
Comments' report whose contents was agreed at WG17's meeting in Chiswick.

0.1 SC22 Ballot result

SC22 BALLOT RESULT 

The result of the ballot is:

Member Bodies voting FOR WITHOUT COMMENT: 10 (Australia, China, Czech
Republic, Finland, Ireland, Japan, Norway, Russian Federation, UK,
Ukraine, USA).

Member Bodies voting FOR WITH COMMENT:  1 (USA).

Member Bodies voting AGAINST:  1 (Germany).

Member Bodies ABSTAINING:  5 (Denamrk -- "Due to lack of Danish
expertise", France -- "due to lack of resources", Netherlands -- "Due
to lack of National response").

Member Bodies  NOT VOTING:  5 (Austria, Belgium, Egypt, Romania,
Slovenia).

In addition, the following "O" (Observer) members voted:

Korea Republic: Approve without comment.
Portugal: Abstain.

Other JTC1 member voting:

Kenya: Approve without comment.

Contents

	1.1 Comments from USA
        
        1.2 Comments from Germany

----------------------------------------------------------

1. COMMENTS AND DRAFT RESPONSE.

1.1 Comments from USA.

Here are the comments of J17 (for ANSI).

J17 recommends a vote of YES on Final CD ballot for FCD 13211-2 with the
following comment.

J17 considers that the ability of a Prolog program to introspectively
examine it self is an important property of the language.  It is thus
highly desireable that an assertion of a clause asserta((X:-Y)),
followed by a call of clause(X,Z), should instantiate Z to something as
close to  Y as possible.

In the presence of module qualification performing all the
transformations listed in 7.5.3 inhibits this.  We favor a minimalist
approach in which only the first conversion, that of 7.5.2.1, takes
place.  The compromise of 7.5.3 is therefor acceptable to us.

1.2 Comments from Germany.

DIN votes "NO with Comments" on this Final Committee Draft.

(In a late vote Austria asked to register its agreement with the
comments of Germany.)

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

WG17: A flag "colon_sets_calling_context" will be introduced to enable
implementors to use an alternate mechanism for setting the context. 

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.

WG17: The ordering an cross referencing of the definitions will
be reviewed to take these comments into account. Context will
only be used in the sense "calling context".

General (E): re-export or reexport shall be written
uniquely througout the standard.  

WG17: Accepted. But following the usage: English re-export, 
Prolog reexport.

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.

WG17: Accepted.

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. 

WG17: This will be clarified.

3.4 (E)

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
WG17: This was agreed to.

3.8 (T) import:

..to make procedures exported or re-exported by another module
See 3 General

WG17: This will be clarified .

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

WG17: This will be clarified .

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.

WG17: Accepted.

3.18 (E) metavariable

A variable occuring as a meta-argument.

WG17: Accepted.

3.19 (T) module

...and to import or re-export procedures from other modules
R: re-export is no subclass of export.

WG17: This will be clarified.

3.20 (E) module body

..together with import and other directives local to 
that module body

R: import is not the only body directive

WG17: This will be clarified.

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.

WG17: Accepted.

3.22 (E) module directive

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

WG17: Rejected. This is consistent with Part 1.

3.25 (E) module interface

.. which specify the name, the exported resp. re-exported procedures
and exported metapredicates of a module.

WG17: Accepted.

3.26 (E) module, importing

..imported, so extending its context to search for a procedure.

WG17: This will be clarified.

3.28 (E) module name qualification

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

WG17: Rejected.

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.

WG17: This will be clarified

3.33 (E) preparation..

2nd line also: Prolog text or module text..

WG17: Accepted.

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

WG17: Accepted.

3.36 (E) process

... prepared Prolog text OR module text..

WG17: Accepted.

3.39 (E) argument, qualified

see proposal on 3.28 (...module qualified * predication)

WG17: Rejected.

3.39-3.46  (E)

entity, qualified instead of qualified entity, etc (see General)

WG17: Accepted.

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!

WG17: Accepted.

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

WG17: Accepted.

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.

WG17: This will be clarified.

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

WG17: This will be clarified

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.

WG17: This will be clarified

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)

WG17 This will be clarified. This is consistent with part 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!

WG17: Rejected. The text is correct as it stands.

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!   

WG17: This will be clarified

6.2.1 (T) Operators (trailing to 1st para)

..writeq/2, if none of these operator definitions has been 
changed before.

WG17: Follows part 1.

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)

WG17: This was discussed. The new flag "colon_sets_calling_context"
allows implementors to choose a method of setting the context that does
not overload colon.

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.

WG17: This will be clarified

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"!

WG17: This will be clarified.   

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.

WG17: This will be clarified
7.2.2.2 (T) 1st para

...makes the procedures indicated by EL available for import or
re-export by other modules.

WG17: Accepted.

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

WG17: Accepted.

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)

WG17: Accepted.

7.2.2.3 (E) 2nd para.

This sentence isn't clear. What is the procedure of a 
procedure?

WG17: This will be clarified

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

WG17: This will be clarified. A new subclause on procedure visibility
will be added for this purpose.

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 

WG17:   This  is not needed.

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.

WG17: This will be clarified.

7.2.2.5 (E) metapredicate/1:

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

WG17: Accepted. 

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. 

WG17 Accepted.

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)

See previous comment.

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

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

WG17: Accepted.

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.

WG17: This will be clarified.

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.

WG17: This will be clarified.

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.

WG17: The new section on visibility will replace these notes.

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

WG17: This will be clarified.

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

WG17: Accepted.

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

WG17: This will be clarified.

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

WG17: A clearer form of words will be found. The current wording
follows part 1.

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.

WG17: This will be clarified.

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 syntaxerror, 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 previously imported or re-exported procedure
(These cases are handled with the next paragraph correctly).

WG17:  This follows part 1, it will be clarified.
	
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?

WG17: Rejected. This follows Part 1, it will be clarified.

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!

WG17: Accepted.

7.3.1 (T) last para

..and all procedures imported resp. re-exported into M

WG17: Accepted.

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, currentop/3
readterm/2/3
read/1/2
writeterm/2/3
write/1/2
writeq/1/2
charconversion/, currentcharconversion/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.

WG17: This will be clarified. A subclause on context sensitive
predicates
will be inserted. 

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.

WG17: Accepted.

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,[])))! 

WG17: This will be clarified. 

7.4.3.2 (T) Examples erroneous:

activators at the end of example:

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

WG17: The examples will be adjusted to take into account the new flag
"colon_sets_calling_context".

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 
   ,sortwitherrors 
fails, writing...

(R) Elsewhere sort is not known and thereby not callable.

WG17: This will be clarified. 
    
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.

WG17: Accepted.

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

WG17: Rejected. This  follows ISO  standard usage.

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.

WG17: This will be clarified.

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.

WG17: This will be clarified.

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"

WG17: This clause on conversion will be clarified.

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.

WG17: This clause on conversion will be clarified.

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

WG17: All these will be clarified.

7.5.2.1 (E) a) 2) last line

arguments if, if any, ... (omit one if)

WG17: Accepted.

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)?

WG17: This note is unnecessary and will be removed.

7.5.2.1 (E) a) 3)1st/2nd line

one of the control constructs one of the control constructs

WG17: Accepted

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

WG17: Accepted.

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) ?

WG17 This will be clarified.
But note that we don't know that a meta argument will be
treated as a goal.

7.5.2.1 (T) b) 

is a qualified Term M:(currentmodule(X),currentpredicate(Y),
 write(X), write(Y),nl).
possible at all? (which is M:','(currentpredicate(X,Y),','(...))

WG17: This will be clarified.

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?

WG17: This will be clarified.

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

WG17: These are metapredicates.

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.

WG17: This will be clarified.

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.

WG17: This will be clarified.

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?

WG17: This will be clarified.

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?

WG17: This will be clarified, in relation to the new flag 
"colon_sets_calling_context".

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?

WG17: This will be clarified.

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.

WG17: This will be clarified.

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.

WG17: This comment is in error, only one such predicate can be found.

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 charconversion and
operator definitions currently hold?

WG17: Text concerning these will be added at this point.

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.

WG17: This will be clarified.

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.

WG17: This note is not required and will be omitted.

7.7.2.1 (T) 1st para

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

WG17: This will be clarified.

7.8 (E) 1st para

...of proceduresS...
...Module:Goal (8.2.2) 

WG17: Accepted.

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"

WG17: Accepted.

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.

WG17: This will be clarified.

_____________________ end of SC22 N2929 __________________________