From rinehuls@Radix.Net Tue May 18 00:19:11 1999 Received: from mail1.radix.net (mail1.radix.net [209.48.224.31]) by dkuug.dk (8.9.2/8.9.2) with ESMTP id AAA66161; Tue, 18 May 1999 00:19:10 +0200 (CEST) (envelope-from rinehuls@Radix.Net) Received: from saltmine.radix.net (saltmine.radix.net [209.48.224.40]) by mail1.radix.net (8.9.3/8.9.3) with SMTP id SAA14432; Mon, 17 May 1999 18:19:14 -0400 (EDT) Date: Mon, 17 May 1999 18:19:12 -0400 (EDT) From: William Rinehuls To: sc22docs@dkuug.dk cc: keld simonsen Subject: N2929 - Disposition of Comments Report for FCD 13211-2: 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 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: rinehuls@radix.net _______________ 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 __________________________