From rinehuls@access.digex.net Sun Aug 31 00:04:20 1997 Received: from access4.digex.net (qlrhmEbBUV1EY@access4.digex.net [205.197.245.195]) by dkuug.dk (8.6.12/8.6.12) with ESMTP id AAA05666 for ; Sun, 31 Aug 1997 00:03:56 +0200 Received: from localhost (rinehuls@localhost) by access4.digex.net (8.8.4/8.8.4) with SMTP id SAA15478 for ; Sat, 30 Aug 1997 18:03:40 -0400 (EDT) Date: Sat, 30 Aug 1997 18:03:40 -0400 (EDT) From: "william c. rinehuls" To: sc22docs@dkuug.dk Subject: SC22 N2578 - Disposition of Comments Report, Prolog Modules Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII ____________________ 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 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 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 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 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 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 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 ____________________________