From rinehuls@Radix.Net Wed Dec 9 00:39:15 1998 Received: from mail1.radix.net (mail1.radix.net [209.48.224.31]) by dkuug.dk (8.8.7/8.8.7) with ESMTP id AAA23954; Wed, 9 Dec 1998 00:39:05 +0100 (CET) (envelope-from rinehuls@Radix.Net) Received: from saltmine.radix.net (saltmine.radix.net [209.48.224.40]) by mail1.radix.net (8.9.1/8.9.1) with SMTP id SAA20293; Tue, 8 Dec 1998 18:39:03 -0500 (EST) Date: Tue, 8 Dec 1998 18:37:52 -0500 (EST) From: William Rinehuls Reply-To: William Rinehuls To: sc22docs@dkuug.dk cc: keld simonsen Subject: SC22N2855 - Vote Summary on 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 N2855 TITLE: Summary of Voting on Final CD Ballot for FCD 13211-2: Information technology - Programming languages - Prolog, Part 2: Modules DATE ASSIGNED: 1998-12-08 SOURCE: Secretariat, ISO/IEC JTC 1/SC22 BACKWARD POINTER N/A DOCUMENT TYPE: Summary of Voting PROJECT NUMBER: JTC 1.22.22.02 STATUS: WG17 is requested to prepare a Disposition of Comments Report and make a recommendation on the further processing of the FCD. ACTION IDENTIFIER: FYI to SC22 Member Bodies; ACT to WG17 DUE DATE: N/A DISTRIBUTION: Text CROSS REFERENCE: SC22 N2737 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 vote summary ______ SUMMARY OF VOTING ON Letter Ballot Reference No: SC22 N2737 Circulated by: JTC 1/SC22 Circulation Date: 1998-07-23 Closing Date: 1998-12-07 SUBJECT: Final CD Ballot for FCD 13211-2: Information technology - Programming languages, Prolog, Part 2: Modules ---------------------------------------------------------------------- The following responses have been received on the subject of approval: "P" Members supporting approval without comments 10 "P" Members supporting approval with comments 1 "P" Members not supporting approval 1 "P" Members abstaining 5 "P" Members not voting 5 "O" Members supporting approval without comments 1 "O" Members abstaining 1 Other JTC 1 Members supporting approval without comments 1 ----------------------------------------------------------------------- Secretariat Action: WG17 is requested to prepare a Disposition of Comments Report and make a recommendation on the further processing of the FCD. The comment accompanying the abstention vote from Denmark was: "Due to lack of Danish expertise." The comment accompanying the abstention vote from France was: "Due to lack of resources." The comment accompanying the abstention vote from the Netherlands was: "Due to lack of National response." The comments accompanying the negative vote from Germany and the comments accompanying the affirmative vote from the U.S.A. are attached. _________ end of overall summary; beginning of detailed summary ______ ISO/IEC JTC1/SC22 LETTER BALLOT SUMMARY PROJECT NO: JTC 1.22.22.02 SUBJECT: Final CD Ballot for FCD 13211-2: Information Technology - Programming Languages - Prolog, Part 2: Modules Reference Document No: N2737 Ballot Document No: N2737 Circulation Date: 1998-07-23 Closing Date: 1998-12-07 Circulated To: SC22 P, O, L Circulated By: Secretariat SUMMARY OF VOTING AND COMMENTS RECEIVED Approve Disapprove Abstain Comments Not Voting 'P' Members Australia (X) ( ) ( ) ( ) ( ) Austria ( ) ( ) ( ) ( ) (X) Belgium ( ) ( ) ( ) ( ) (X) Brazil ( ) ( ) (X) ( ) ( ) Canada ( ) ( ) (X) ( ) ( ) China (X) ( ) ( ) ( ) ( ) Czech Republic (X) ( ) ( ) ( ) ( ) Denmark ( ) ( ) (X) (X) ( ) Egypt ( ) ( ) ( ) ( ) (X) Finland (X) ( ) ( ) ( ) ( ) France ( ) ( ) (X) (X) ( ) Germany ( ) (X) ( ) (X) ( ) Ireland (X) ( ) ( ) ( ) ( ) Japan (X) ( ) ( ) ( ) ( ) Netherlands ( ) ( ) (X) (X) ( ) Norway (X) ( ) ( ) ( ) ( ) Romania ( ) ( ) ( ) ( ) (X) Russian Federation (X) ( ) ( ) ( ) ( ) Slovenia ( ) ( ) ( ) ( ) (X) UK (X) ( ) ( ) ( ) ( ) Ukraine (X) ( ) ( ) ( ) ( ) USA (X) ( ) ( ) (X) ( ) 'O' Members Voting Korea Republic (X) ( ) ( ) ( ) ( ) Portugal ( ) ( ) (X) ( ) ( ) Other JTC 1 Members Voting Kenya (X) ( ) ( ) ( ) ( ) _________ end of detail summary; beginning of USA Comments _________ From: Matthew Deane (mdeane@ANSI.org) SUBJECT: US vote on ISO/IEC FCD 13211-2 The US National Body votes to APPROVE WITH COMMENTS. Please see the comments below. The US National Body votes to approve ISO/IEC FCD 13211-2: Information Technology - Prolog - Part 2: Modules with comments: The US considers that the ability of a Prolog program to introspect itself is an important property of the language. Requiring all of the conventions listed in 7.5.3 inhibits this. We favor a minimalist approach in which only the first conversion 7.5.2.1 takes place. The compromise of 7.5.3 is thus acceptable to us. ___________ end of USA Comments; beginning of Germany Comments ______ From: BADENMUELLER DIN-votes on document FCD 13211-2 with "NO WITH COMMENTS". Comments on Final Committee Draft ISO/IEC 13211-2 ================================================= The document ends with " Provisional End of German Comments " General ======= These Comments consist of two parts: Pt. A: General statements on questionable basic concepts of the Draft: the still-to-solve contradiction between the one- vs two-qualifier appproach. These are compatible with, but extend the German Comments on the former ISO/IEC 13211-2 Prolog Committee Draft. Pt. B: Editorial and technical comments on the Draft as it is. These are NEW and are marked alternating as: E editorial T technical R rationale Due to time restriction we couldn't complete our comments. These shall be completed until 6th Jan. 99. The remainder will extend (not modify) the current Comments and will be sent to WG17 experts and X3J17 directly on Jan. 6th. A 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 to 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. B 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. General (E): re-export or reexport shall be written uniquely througout the standard. 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. 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. 3.4 (E) See 3 General 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 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. 3.18 (E) metavariable A variable occuring as a meta-argument. 3.19 (T) module ...and to import or re-export procedures from other modules R: re-export is no subclass of export. 3.20 (E) module body ..together with import and other directives local to that module body R: import is not the only body directive 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. 3.22 (E) module directive .. A term D which defines resp. affects module text... R: The module directive after all creates the module! 3.25 (E) module interface .. which specify the name, the exported resp. re-exported procedures and exported metapredicates of a module. 3.26 (E) module, importing ..imported, so extending its context to search for a procedure. 3.28 (E) module name qualification 1) better: module qualification 2)..the qualification of a meta-argument or an activator ... 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. 3.33 (E) preparation.. 2nd line also: Prolog text or module text.. 3.34 (E) procedure, accessible .. here main definition. 3.36 (E) process ... prepared Prolog text OR module text.. 3.39 (E) argument, qualified see proposal on 3.28 (...module qualified * predication) 3.39-3.46 (E) entity, qualified instead of qualified entity, etc (see General) 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! 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). 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. 3.49 (E) ...without using module qualification. 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. 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) 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! 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! 6.2.1 (T) Operators (trailing to 1st para) ..writeq/2, if none of these operator definitions has been changed before. 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) 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. 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"! 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. 7.2.2.2 (T) 1st para ...makes the procedures indicated by EL available for import or re-export by other modules. 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). 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) 7.2.2.3 (E) 2nd para. This sentence isn't clear. What is the procedure of a procedure? 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... 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 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. 7.2.2.5 (E) metapredicate/1: better: metapredicate(MI) where MI means Mode Indicators. It is not always a list and thereby misleading. 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. 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) 7.2.3.2 (T) Directive import/2, 2nd paragraph: ...shall be a procedure exported or re-exported successively by the module M. 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. 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. 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. 7.2.3.4 (E) 2nd para, 1st sentence: remove "implementation defined" 7.2.3.4 (E) 2nd para., after 2nd sentence. Remove the dot after module. 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.... 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... 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. 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 syntax_error, 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 previousy imported or re-exported procedure (These cases are handled with the next paragraph correctly). 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? 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! 7.3.1 (T) last para ..and all procedures imported resp. re-exported into M 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, current_op/3 read_term/2/3 read/1/2 write_term/2/3 write/1/2 writeq/1/2 char_conversion/, current_char_conversion/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. 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. 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,[])))! 7.4.3.2 (T) Examples erroneous: activators at the end of example: foo:p(3). succeeds, writing 3 bar:p(3). succeeds, writing 3 It isn't quite clear, why so much and complicated modules are needed for the simple activators? We would expect now very twisted activators. 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 ,sort_with_errors fails, writing... (R) Elsewhere sort is not known and thereby not callable. 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. 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... 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. 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. 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" 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. 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. 7.5.2.1 (E) a) 2) last line arguments if, if any, ... (omit one if) 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)? 7.5.2.1 (E) a) 3)1st/2nd line one of the control constructs one of the control constructs 7.5.2.1 (E) a) 4) 2nd line table 8 of ISO 13211-1 is table 9! 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) ? 7.5.2.1 (T) b) is a qualified Term M:(current_module(X),current_predicate(Y), write(X), write(Y),nl). possible at all? (which is M:','(current_predicate(X,Y),','(...)) 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? 7.5.2.2 (T) b) 2) What again with once/1 and +\/1 ? 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. 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. 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? 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? 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? 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. 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. 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 char_conversion and operator definitions currently hold? 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. 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. 7.7.2.1 (T) 1st para In the calling context of module CM catch(G,C,R) is true iff (1)... 7.8 (E) 1st para ...of proceduresS... ...Module:Goal (8.2.2) 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" 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. Provisional End of German Comments ________________ end of SC22 N2855 _________________________________