ISO/ IEC 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 ____________________________