JTC1/SC22
N2578
Date: Sat, 30 Aug 1997 18:03:40 -0400 (EDT)
From: "william c. rinehuls" <rinehuls@access.digex.net>
To: sc22docs@dkuug.dk
Subject: SC22 N2578 - Disposition of Comments Report, Prolog Modules
____________________ beginning of title page _________________________
ISO/IEC JTC 1/SC22
Programming langugages, their enviroments and system software interfaces
Secretariat: U.S.A. (ANSI)
ISO/IEC JTC 1/SC22
N2578
TITLE:
Disposition of Comments Report on CD Approval of CD 13211-2, Information
technology - Programming languages, their enviroments and system software
interfaces - Prolog, Part 2: Modules
DATE ASSIGNED:
1997-08-29
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
DUE DATE:
N/A
DISTRIBUTION:
Text
CROSS REFERENCE:
SC22 N2264, N2384
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: rinehuls@access.digex.net
____________________ end of title page; beginning of report ____________
ISO/IEC CD 13211-2 PROLOG -- DISPOSITION OF COMMENTS REPORT
--- PROLOG: PART 2 -- MODULES
INTRODUCTION
A CD (Committee Draft) for ISO/IEC 13211-2 (Prolog: Part 2 -- Modules)
was published in September 1996, distributed to SC22 WG17 as N151 (and
SC22 as N2264), with a ballot to register it as a Committee Draft.
The ballot was successful but changes are still required. The full
voting is below and the submitted comments are appended together with a
'Disposition of Comments` report whose content was agreed at WG17's
meeting in Schliersee (28-30 April 1997).
Clause 2 is an additional paper prepared by Germany which supported the
discussion in Schliersee.
WG17 agreed to allow extra time for e-mail discussion during
preparation of the `Final CD' in order to maximize the chance of
universal approval.
Roger Scowen (editor)
ISO/IEC JTC1 SC22 WG17 (Prolog) Convener,
9 Birchwood Grove, Hampton, Middlesex
United Kingdom ~~~ TW12 3DU
Telephone: +44 181 979 7429
E-Mail: rss@cise.npl.co.uk
Fax: +44 181 287 3810
13 August 1997
0.1 SC22 Ballot result
The result of the ballot is:
Member Bodies voting FOR without comment: 18 (Australia, Austria,
Brazil, Canada, China, Czech Republic, Denmark, Finland, Ireland,
Japan, Netherlands, Romania, Russian Federation, Slovenia, Switzerland,
UK, Ukraine, USA).
Member Bodies voting AGAINST: 2 (Germany, Sweden).
Member Bodies ABSTAINING: 1 (France -- "due to lack of resources").
0.2 Contents
1.1 --- Comments from Germany.
1.2 --- Comments from Sweden.
1.3 --- Comments from individuals --- Fergus Henderson, Richard O'Keefe,
Katsuhiko Nakamura, Mats Carlsson, Roger Scowen.
2 --- German comments on context dependent effects and module
qualification.
----------------------------------------------------------
1 COMMENTS AND DRAFT RESPONSE
1.1 Comments from Germany
DIN votes "NO With Comments" on this Committee Draft
for the following technical reasons.
The comments follow the section numbering of the Draft.
The comments are designated as
-- Substantial technical comments
-- Less Substantial technical comments
-- Editorial comments
There was still no time to check entirely the correctness of
clause 7.7, executing a goal, due to lack of resources.
1.1.1 Substantial technical comments
WG17 agreed to allow time for extra discussion before publishing the
`Final CD' in order to maximize the possibilities of resolving the
negative votes on the CD. The specific responses to the German
substantial comments are given below.
a) General: The overall quality of the draft is worse than earlier drafts.
This is reflected in the many editorial and less substantial technical
comments. Especially the many violation/implementation defined pairs
bring many unclean decisions and additional work for the
implementers/manual writers (if any).
WG17: This will be clarified. USA and other experts will proof-read
the next draft before publication.
b) General: DIN opposes continuously to use the ":" qualifier both
for determining the lookup context and the calling context, depending
on the syntactical context of the ":".
It shall only determine the lookup context; "@" should determine
the calling context.
WG17: Time has been allowed for extra discussion on this point.
c) 7.2.3.2 Last Sentence: Re-export of a predicate in the required manner
shall be forbidden.
Reason: After allowing multiple bodies which may import predicates
it is very unclean to export those
imports in the earlier prepared interface. The processor
would be forced to a very expensive bookkeeping. Also it is
impossible to rely on a clean set of interfaces (which is
a main reason for a module concept), if complex cross-relations
exist between bodies and interfaces in both directions (this effect
is enforced by multiple bodies which tend to hide these cross
relations).
WG17: This will be clarified. Much discussion took place, and
resolution A.3 favoured including ``a re-export directive in
the module interface, which imports and at the same time
re-exports the specified procedures of another module (cf WG17
N126)''. The issue will be considered further during preparation
for the final CD.
d) 7.2.3.6 NOTES 2 and following text.
The effects of op/3, char_conversion/2 and set_prolog_flag/2
are at least as important for a module concept, as meta arguments
and predicates, which will in the average be used less frequently
than module-bound operators or other meta effects. Therefore
it is incredible not to standardize these context sensitive
effects in a module concept standard. DIN promised to supply
here an adequate proposal, which we failed to deliver until today
due to problems in the Prolog scene which not only influenced DIN.
Nevertheless we will do this work and supply a proposal.
WG17: This will be clarified. Much discussion took place, and
resolutions A.4 and A.5 determined that ``at the beginning of
preparation for execution of a module (interface) of every module the
predefined operators, char conversions and prolog flags shall be in
effect'', and ``the operator definitions, char conversions and Prolog
flags of module bodies belonging to a given module shall accumulate
during preparation of subsequent bodies of that module''.
e) 8.4.3.1 Retracting an imported procedure shall be forbidden strictly:
This is an uncontrollable far-reaching effect, especially together
with re-export. It is in contradiction to general rules of
software engineering.
retracting and abolishing should only be possible in the defining
module. To make retracting imported procedures implementation defined
invites (forces) suppliers to implement it.
WG17: Accepted. Implicitly retracting a procedure from a foreign module
shall be forbidden. In the same way it shall be allowed to inspect a
dynamic predicate of a foreign (defining) module only if the the
defining module is explicitly specified. Inspecting a predicate of a
foreign defining module implicitly, i.e. without module qualification
shall be an error :
permission_error(access(foreign_procedure, Pred)).
This behaviour isn't changed by an import of the foreign procedure.
Take in respect the extension of the object types (see Part 1,
7.12.2.e) in Part 2 by the concept `foreign_procedure'.
1.1.2 Less substantial technical comments
a) 5.5 3rd line: implementation specific features are not specified
in the CD or Part 1, only implementation defined features.
WG17: Not accepted. Clause 5.4 of the CD is an adaptation of the
corresponding clause (5.5) in ISO/IEC 13211-1.
b) 7.2 Module text: 2nd sentence: A module consists of a module
interface and zero or more module bodies. Bodies and interface
may be physically separate.
(Note: body parts are not defined. According 7.2.2 zero or
more bodies.)
WG17: This will be clarified.
c) 7.2.3.1 3rd para: A feature must not be a violation and imp-def
at the same time. German proposal was (cf. earlier drafts):
either end_module (why a separate end_interface?) or an
immediately following new module-component is a legal end.
Otherwise it's a violation "missing end_module()".
WG17: Accepted.
d) 7.2.3.1 last para: again: either imp-def or violation. Secondly:
"loaded at one time" is incorrect. Correctly: prepared for
execution. Or still better: It is a violation if the module
already exists. (cf earlier German proposals).
WG17: This mistake will be corrected.
e) 7.2.3.4 end_interface:
Again: replace end_interface by end_module. It serves the
same reason.
2nd para: Again: a violation and imp-def must not be
at the same time. The violations shall be defined correctly.
WG17: Accepted. See 1.1.2(c).
f) 7.2.3.5 2nd para, last sentence: loaded is the wrong word. (cf. 3.12)
prepared is correct.
WG17: This mistake will be corrected.
g) 7.2.3.5 3rd para: Either end_module or begin of a new module component,
otherwise a violation. Imp-def is not correctly here.
WG17: Accepted. See 1.1.2(c).
h) 7.2.3.5 Last para: either definite violation or imp-def. Not both.
WG17: Accepted. See 1.1.2(c).
i) 7.2.3.6 Last para: double defined end_module/1 behaviour. (cf 7.2.3.5)
WG17: This mistake will be corrected.
j) 7.2.4.2 2nd para: Again: Not violation and impdef at the same time!
This is a wasting of the concept implementation defined. Such simple
and common violations shall be standardized uniquely!
WG17: Accepted. See 1.1.2(c).
k) 7.2.4.2 3rd para: The same. Because multifile is standardized, there
is no reason to leave behaviour implementation defined.
By the way: for every implementation defined requirement
in the standard all existing implementations have to supply
entries in their accompanying documentation. We guess that
this will be not accepted easily.
WG17: This will be clarified.
l) 7.2.4.2 Here is no provision what happens, if a procedure is imported
and another with same predicate indicator is defined in module
M. There is only one in 7.4, clauses, 2nd para. But both belong
together.
WG17: This will be clarified. For example, replacing the current
wording by: ``If a predicate with predicate indicator PI is visible
inside a module M then it is not allowed to make visible another
predicate with the same predicate indicator PI. Only one predicate
with given predicate indicator PI can be visible in a module M.'' If a
procedure with predicate indicator PI from the complete database (cf
7.3) is visible inside module M then no other procedure with the same
predicate indicator PI shall be made visible in the same module M.
m) 8.2.1.1 1st para: The term "existing module" is not longer
defined, but still used at this place. DIN proposes to reinvent
the concept "existing" as: the interface has been prepared
for execution successfully. Or should be meant "loaded module"?
WG17: Accepted. An existing module will be redefined as one whose
interface has been prepared for execution.
n) 7.8 and 8.3.1.1 2nd para: "public procedure" is not defined.
WG17: Not accepted. See Part 1, definition 3.142.
1.1.3 Editorial Comments
WG17: These mistakes will be corrected.
a) 3.34 At least misleading in comparison with 3.28: module name
qualification.
b) 3.36 2nd line: ``the first argument''.
c) 3.38 What is "retrieved"? Is the clause defined in the defining module
or visible in the lookup module?
d) 5.6.2 The definition is misleading. Iff a processor supports ...
then a) the processor shall not require... and
b) the processor shall define...
e) 7.2.1 The last paragraph belongs to 7.2.2.
f) 7.2.2 Append the last paragraph of 7.2.1
g) 7.2.4.1 According 7.2.3.2, with EL for export list, rename MI with
IL for import list.
h) 7.4 Clauses, last para:
The predicate indicator P/N of the PREDICATE of Clause...
(a head has no predicate indicator).
----------------------------------------------------------
1.2 Comments from Sweden
The Swedish comments on ISO/IEC CD 13211-2 (SC 22 N 2264)
Vote: Disapproval
The overall quality of the document is not up to committee draft
standards. There are too many unclear points and inconsistencies.
Furthermore, Sweden disagrees with the proposed treatment of the
database access and modification built-in predicates as detailed
below.
1.2.1 Detailed comments
a) 3.1 "accessible predicate". This looks like an obsolete definition,
now that the notion of accessibility has been removed from the draft
except in 5.6.1.2 and 3.42.
WG17: Not accepted. ``Accessible procedure'' is needed.
b) 3.2 "calling context" is probably obsolete or redundant.
WG17: Not accepted. See clause 7.6 of the draft.
c) 3.4 "defining module" and 3.38 "source module". Are these ever
different?
WG17: This will be clarified. `Defining module' and `source module'
are different. The wording `source module' will be improved and the
concept will be clarified.
d) 3.13 "lookup module" is probably obsolete or redundant. Does it serve
any purpose outside of Chapter 7? It is also defined in 7.1.1.3.
WG17: This will be clarified. "lookup module" is used in 7.5.1 and
other places. 7.1.1.3 will be deleted.
e) Table 1: Must it really be copied from Part 1?
WG17: Not accepted. WG17 considers it important to show the entire
default operator table, especially to compare the priority of the colon
operator with respect to all other default operators.
f) 7.1.1.3: Change "complete" to "visible". Are both this and 3.13 needed?
WG17: This will be clarified. See 1.2.1(d).
g) 7.1.1.5: Are both this and 3.17 needed?
WG17: This will be clarified. 3.17 will be clarified by the Project
Editor (assuming the agreement on existence of metapredicate mode
indicators).
h) 7.3: The complete database is absolute
and should not be defined with respect to a procedure p and a module M.
Propose to remove the first sentence.
WG17: This mistake will be corrected.
i) 7.3.1: Change "complete database of M" to "complete database".
WG17: This mistake will be corrected.
j) 7.3.2: The words "The complete database for a predicate p called
from foo" doesn't make sense.
WG17: This will be clarified.
k) 7.3.2 Example - delete references to accessible predicates.
WG17: Not accepted. The concept of accessible procedures is needed,
e.g. for the implementation specific hidden procedures.
l) Table 2 and 7.5.2.b: must the table really be copied from Part 1?
The comma functor is written in non-compliant syntax. It must be
written (',')/2.
WG17: This mistake will be corrected.
m) 7.5.4.a: Non-compliant syntax for the comma functor (see above).
See 1.2.1(l).
n) 7.7.1: "A decorated subgoal DS" - DS is not used anywhere.
WG17: Not accepted. It is copied from part 1. See table 3 where
newstack_T is an empty stack of elements of type T.
o) 7.7.2 and Table 3: DS and ES are not used anywhere.
See 1.2.1(n).
p) 7.7.3b: "the complete database is searched in the module m for a
procedure q with defining module m" is strange and opaque.
WG17: This mistake will be corrected. "in the module m" will be removed.
q) 7.7.3d: Doesn't it suffice to say that the search is carried out in the
visible database of the calling module mm?
Item (1), "mm is searched for a procedure p defined wholly in mm",
is strange; can a procedure be defined in more than one module?
There is no difference between items (2i) and (2ii) as far as I can
tell.
WG17: These mistakes will be corrected. Delete ``wholly''.
r) 7.7.4g: change "defining module" to "source module".
WG17: Not accepted. Defining module is correct. Source module will be
made precise or omitted.
s) 7.7.6a: a ")" is missing.
WG17: This mistake will be corrected.
t) 7.7.7: The distinction between the database access built-ins and other
built-ins that have meta arguments is artificial and unacceptable.
Propose to replace by: "For the built-ins that have meta arguments
i.e. predicate_property(:,*), setof(*,:,*), bagof(*,:,*),
findall(*,:,*), clause(:,*), asserta(:), assertz(:) and retract(:),
the current decorated subgoal has access to the lookup module contextmodule."
Is this the only place that mentions that setof/3, bagof/3,
findall/3, clause/2, asserta/1, assertz/1 and retract/1 have meta-arguments?
WG17: This will be clarified. This will be resolved in the larger
context of context dependent features.
u) 7.7.8: call/1 is not the only control construct that takes meta
arguments. once/1 and catch/3 must be similarly extended.
WG17: This mistake will be corrected. catch/3 will be included, but
remember that once/1 is a built-in predicate.
v) 8.3 Clause Retrieval. I would like to get rid of the references to
the lookup module, a notion which seems to require that the Prolog
processor somehow maintains the context module at runtime as part of
its internal state. Also, why is it "implementation defined as to
whether clauses of imported predicates are accessible to clause/2"? It
would be strange indeed to be able to call a dynamic predicate, but not
be able to use clause/2 on it. Whether imported predicates should be
modifiable by assert/1,
retract/1 or abolish/1 is another matter.
See 1.2.1(t).
w) 8.3.1, 8.4.1, 8.4.2, 8.4.3, 8.4.4: Propose to delete references to the
lookup module, and to allow the first argument to be module qualified.
Propose to borrow text from 8.2.2.1.a: "Extracts from Head the
associated lookup module M and the associated unqualified term T ...".
Propose to delete the following error/implementation defined cases, and
instead make them examples of correct usage:
clause(insects:legs(X), A).
animals:clause(elk(X), B).
clause(animals:elk(X), B).
asserta(mammals:elk(anna)).
retract(animals:dog).
See 1.2.1(t).
x) 8.4.2.1: The text is not symmetric with 8.4.1.1
WG17: This will be clarified. ``in a module M'' will be replaced by
``with lookup module M''.
y)
Misc: Propose to change the declaration
:- module_interface(M).
to
:- begin_interface(M).
for better naming consistency (cf. begin_module / end_module).
WG17: This will be clarified. See resolution A.2.
----------------------------------------------------------
1.3 Comments from individual experts
These comments were received by e-mail. I have edited them, and take
responsibility for any errors introduced.
1.3.1 Fergus Henderson <fjh@cs.mu.oz.au>
Date: Sat, 18 Jan 1997 04:51:56 +1100 (EST)
I didn't found time to review the Prolog modules CD draft. However, I
am quite worried by Germany and Sweden's comments, particularly the
comments regarding the draft's general technical quality, and Germany's
comment:
7.2.3.6 NOTES 2 and following text.
The effects of op/3, char_conversion/2 and set_prolog_flag/2
are at least as important for a module concept, as meta arguments
and predicates, which will in the average be used less frequently
than module-bound operators or other meta effects. Therefore
it is incredible not to standardize these context sensitive
effects in a module concept standard. DIN promised to supply
here an adequate proposal, which we failed to deliver until today
due to problems in the Prolog scene which not only influenced DIN.
Nevertheless we will do this work and supply a proposal.
I do regard it as essential to standardize the effects of op/3.
WG17: Accepted. See 1.1.1(d).
1.3.2 Richard A. O'Keefe <ok@cs.rmit.edu.au>
Date: Mon, 20 Jan 1997 14:41:56 +1100 (EST)
I studied the proposal in some detail, but due to the press of other
work did not have time to submit any comments. My comments would
have been:
a) The present draft desperately needs proof-reading.
WG17: Accepted.
b) The present draft is overspecific, preventing some useful practices.
WG17: Not accepted. It is not clear from your comment what you are proposing.
c) But on the whole, it is clearly on the right track.
d) I disagree with DIN about the desirability of having two module
operators.
See 1.1.1(b).
e) DIN are right about op/3.
However, a very simple scheme which will work very well is to introduce
the notion of a "read table", to rule that every module file starts
being processed using a read table named iso_prolog, that there is a
standard form
select_read_table(TableName, [Modifier,...]).
which affects only the current file plus any included files.
Details are available from me on request.
WG17: This was discussed by WG17 in Schliersee, Germany. See 1.1.1(d).
This is a desirable mechanism but will not be required.
f) Sweden are right about symmetry in names.
WG17: This was discussed by WG17 in Schliersee, Germany. See 1.2.1(y).
1.3.3 Katsuhiko Nakamura <nakamura @naklab.k.dendai.ac.jp>
Date: Thu, 14 Nov 96 11:57:04 JST
I have the following editorial, fundamental but rather trivial,
problems in CD13211-2 in preparing the DIS Ballot.
a) Where are the definitions for that each module shall
have one module interface and that the interface shall
be placed before its body?
WG17: This will be clarified.
b) Are the terms "public" and "private" in
7.8 Predicate properties defined anywhere? Is
it necessary that 3 Definitions contains these terms?
WG17: This will be clarified. See Part 1, definitions 3.135, 3.142.
c) The example in 8.1.1 is almost equivalent to that
in 7.6.1.1. Is it necessary to repeat the example?
WG17: This will be clarified.
1.3.4 Mats Carlsson <mc@csd.uu.se>
Date: Thu, 12 Dec 1996 15:18:29 +0100
The Swedish AG22 has circulated CD 13211-2 for review among its
Appropriate changes in the text will change our vote to approval.
1.3.5 Roger Scowen <rss@cise.npl.co.uk>
Date: April 1997
Some additional errors include:
WG17: These mistakes will be corrected.
a) 5.1 (and elsewhere) Replace all references to ``working draft''
to ``Committee Draft'' (and make further systematic changes for the
DIS and standard --- It is simple to achieve this with a suitable
\def).
WG17: This mistake will be corrected.
b) 6.1.1 Replace
module text = ;
by
m text = ;
so that `m text' has not just a single recursive definition.
WG17: This mistake will be corrected.
c) 6.1.1 Replace
m text = m component, m text ;
by
m text = module component, m text ;
to maintain consistency with clause 6.1.2.
WG17: This mistake will be corrected.
d) 7.1.1.1 Add a full stop at the end of the paragraph.
WG17: This mistake will be corrected.
e) 7.2.3.1 Delete the two paragraphs ``It is a violation ...''.
The standard should require the interface text to be bracketed and
leave undefined any relaxation permitted by an implementor.
Similar deletions are possible and advisable in 7.2.3.5, etc.
WG17: This mistake will be corrected.
f) 7.2.3.1 It is conventional in programming languages
for a structure to be bracketed by `begin_xxx' and `end_xxx'.
I therefore suggest that the notation be changed to
begin_interface and end_interface, or to
begin_module_interface and end_module_interface.
WG17: This was discussed by WG17 in Schliersee, Germany. See 1.2.1(y).
----------------------------------------------------------
2 GERMAN COMMENTS ON CONTEXT DEPENDENT EFFECTS AND MODULE QUALIFICATION
Micha Meier, Christian Pichler,
Klaus Daessler <Klaus.Daessler@mchp.siemens.de>
DIN NI22 AK17/Prolog -- 17th Apr 1997
NOTE -- This is an edited version of e-mail message
<199704180656.IAA07342@herkules.mchp.siemens.de>
2.1 Collection of Module Context dependent effects in ISO Prolog
2.1.1 Database manipulation
The built in procedures for DB Manipulation are context dependent.
It must be said, in which module context a procedure may be
-- extended: asserta/1 assertz/1
-- cut: retract/1
-- removed: abolish/1
2.1.2 Clause inspection
It is context dependent. It must be said, in which
module context a clause may be inspected:
clause/2
2.1.3 Call and all solutions
All call procedures are context dependent. Where (in which context)
shall a visible procedure be called and what will be the calling
context of (if any) called metapredicates themselves (which are
the argument of the call procedures)?
call/1
once/1
catch/3
\+/1
bagof/3
setof/3
findall/3
In the scope of the current Draft the calling context of a called
metapredicate must be the same as the calling context of the call
procedure. This is clearly a deficiency of the one-specializer-model.
2.1.4 Predicate properties
predicate_property/2 must know in which context it wishes to inspect
properties of a visible procedure
2.1.5 Operator definition and term-i/o
Operator definition is context dependent. Which conventions hold for
some module?
Solution:
2.1.5.1 Preparation of module parts for execution:
An operator definition comes in effect with its definition point and is
valid until it is erased or changed by another operator definition in
the same module part, or is valid until the end of the module part.
Alternative 1
If a second, third etc. module part of that module is prepared for
execution, the operator table of the module part, prepared immediately
before is in effect. The final operator table is that one, which is in
effect after the last part of this module has been prepared for
execution. That means that the order of preparation of the different
module parts influences all operator tables at the end of preparation
of every module part.
Alternative 2
For every part the same holds as for the first prepared module part.
Only the ISO 13211-1 definitions, modified by module-part-local
operator definitions hold. There is no interconnection between the
operator definitions of different module parts.
2.1.5.2 Validity of operator definitions at the start of execution
Note: the alternatives refer to 2.1.5.1
Alternative 1
The last, cumulative prepared operator table of the module prepared as
last one, is in effect.
Alternative 2
Only the operator table according ISO 13211-1 is in effect.
predicates:
op/3
current_op/3
2.1.5.3 Term Reading/Writing Predicates
According to the operator definitions holding in a module, read_term,
write_term and their derivatives are dependent on the module context.
read_term/2
read_term/3
read/1
read/2
write_term/2
write_term/3
write/1
write/2
writeq/1
writeq/2
2.1.6 Character Conversion: Proposal similar to op/3
Character conversion is context dependent. Which conventions hold for
some module? A character conversion shall be module specific. This is
especially important for natural language translation, e.g. from a
japanese module to an english one.
Our suggested solutions is below.
2.1.6.1 Preparation of module parts for execution:
A char_conversion comes in effect with its definition point and is
valid until the end of the module part. All character conversions
accumulate and constitute the final conversion table at the end of the
module part.
Alternative 1
If a second, third etc. module part of that module is prepared for
execution, the conversion table of the module part prepared immediately
before is in effect. The final conversion table is that one, which is in
effect after the last part of this module has been prepared for execution.
That means that the order of preparation of the different module parts
influencconversions tables at the end of preparation of every
module part.
Alternative 2
For every part the same holds as for the first prepared module part.
At begin of every module part the empty conversion table is in effect.
There is no interconnection between the character conversions
of different module parts.
2.1.6.2 Validity of character conversions at the start of execution
Only the empty conversion table according ISO 13211-1 is in effect.
2.2 Further handling of argument qualification
Ken Bowen proposes to omit Argument Qualification in the database and
clause inspection built-ins. Although built-ins and control are
different from user defined predicates at the first glance, it is
simpler to assume the same mechanisms for all context dependent
procedures, because the same mechanisms act in reality. Moreover the
properties of built-in procedures are simpler to deduce from the
metapredicate mechanism rather than defined separately in a redundant
way.
In the following we subsume once more the arguments against
argument qualification:
a) In all cases except metacall the argument qualification and the
predication qualification have the same effect.
Argument qualification is more cumbersome and error-prone.
b) As Mats Carlsson argumented, long qualification chains are created
which cannot be dropped away during call.
c) For context dependent text handling procedures write_term/2 and
read_term/2 and their derivatives argument qualification is useless,
especially you can't write out the ':' because it's handled
as context qualificator.
d) A qualified non-goal term suggests it may be an atom-based module
concept.
e) For database procedures it was already decided (cf Jonathans mail
from Jul. 3 1996) to remove the qualification of arguments.
2.3 Conclusion
It is very difficult for the users to decide when an argument
should be qualified and when the whole predication should be qualified.
We consequently propose to omit Argument Qualification at all.
_______________________ end of SC22 N2578 ____________________________