From rinehuls@access.digex.net Tue Jan 14 03:04:42 1997 Received: from access1.digex.net (qlYBsVTekvXHY@access1.digex.net [205.197.245.192]) by dkuug.dk (8.6.12/8.6.12) with ESMTP id DAA14860 for ; Tue, 14 Jan 1997 03:04:38 +0100 Received: from localhost (rinehuls@localhost) by access1.digex.net (8.8.4/8.8.4) with SMTP id RAA26014; Mon, 13 Jan 1997 17:18:44 -0500 (EST) Date: Mon, 13 Jan 1997 17:18:43 -0500 (EST) From: "william c. rinehuls" Reply-To: "william c. rinehuls" To: sc22docs@dkuug.dk, roger scowen Subject: SC22 N2384 - Vote Summary for CD 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 N2384 January 1997 TITLE: Summary of Voting on CD 13211-2: Information technology - Programming languages, their environments and system software interfaces - Prolog - Part 2: Modules SOURCE: Secretariat, ISO/IEC JTC 1/SC22 WORK ITEM: JTC 1.22.22.02 STATUS: N/A CROSS REFERENCE: SC22 N2264 DOCUMENT TYPE: Summary of Voting ACTION: To SC22 Member Bodies for information. To WG17 for preparation of a Disposition of Comments Report and a recommendation on the further processing of the CD. Address reply to: ISO/IEC JTC 1/SC22 Secretariat William C. Rinehuls 8457 Rushing Creek Court Springfield, VA 22153 USA Tel: +1 (703) 912-9680 Fax: +1 (703) 912-2973 email: rinehuls@access.digex.net ___________________end of title page, beginning of summaries _____________ SUMMARY OF VOTING ON Letter Ballot Reference No: SC22 N2264 Circulated by: JTC 1/SC22 Circulation Date: 09-24-1996 Clsoing Date: 01-06-1997 SUBJECT: CD ballot for CD 13211-2: Information technology - Programming languages, their environments and system software interfaces - Prolog - Part 2: Modules The following responses have been received on the subject of approval: "P" Members supporting approval without comment: 16 "P" Members supporting approval with comment: 0 "P" Members not supporting approval: 2 "P" Members abstaining: 1 "P" Members not voting: 4 "O" Members supporting approval without comments: 1 Secretariat Action: The comment accompanying the abstention vote from France was: "Abstention due to lack of resources." The comments accompanying the negative votes from Germany and Sweden are attached. WG17 is requested to prepare a Disposition of Comments Report and make a recommendation on the further processing of the CD. __________________end of overall summary; beginning of detail summary ____ ISO/IEC JTC1/SC22 LETTER BALLOT SUMMARY PROJECT NO: JTC 1.22.22.02 SUBJECT: CD Ballot for: CD 13211-2: Information technology - Programming languages, their environments and system software interfaces - Prolog, Part 2: Modules Reference Document No: N2264 Ballot Document No: N2264 Circulation Date: 09-24-1996 Closing Date: 01-06-1997 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) ( ) ( ) ( ) ( ) Egypt ( ) ( ) ( ) ( ) (X) Finland (X) ( ) ( ) ( ) ( ) France ( ) ( ) (X) (X) ( ) Germany ( ) (X) ( ) (X) ( ) Ireland (X) ( ) ( ) ( ) ( ) Japan (X) ( ) ( ) ( ) ( ) Netherlands (X) ( ) ( ) ( ) ( ) Romania (X) ( ) ( ) ( ) ( ) Russian Federation (X) ( ) ( ) ( ) ( ) Slovenia (X) ( ) ( ) ( ) ( ) Sweden ( ) (X) ( ) (X) ( ) Switzerland (X) ( ) ( ) ( ) ( ) UK (X) ( ) ( ) ( ) ( ) Ukraine ( ) ( ) ( ) ( ) (X) USA (X) ( ) ( ) ( ) ( ) 'O' Members Argentina ( ) ( ) ( ) ( ) ( ) Bulgaria ( ) ( ) ( ) ( ) ( ) Cuba ( ) ( ) ( ) ( ) ( ) Greece ( ) ( ) ( ) ( ) ( ) Hungary ( ) ( ) ( ) ( ) ( ) Iceland ( ) ( ) ( ) ( ) ( ) India ( ) ( ) ( ) ( ) ( ) Indonesia ( ) ( ) ( ) ( ) ( ) Italy ( ) ( ) ( ) ( ) ( ) Korea Republic (X) ( ) ( ) ( ) ( ) New Zealand ( ) ( ) ( ) ( ) ( ) Norway ( ) ( ) ( ) ( ) ( ) Poland ( ) ( ) ( ) ( ) ( ) Portugal ( ) ( ) (X) ( ) ( ) Singapore ( ) ( ) ( ) ( ) ( ) Thailand ( ) ( ) ( ) ( ) ( ) Turkey ( ) ( ) ( ) ( ) ( ) Yugoslavia ( ) ( ) ( ) ( ) ( ) _______________end of detailed summary; beginning of Germany Comments ____ 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. The document ends with "End of German Comments". 1 Substantial Technical Comments ================================ 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 lots of unclean decisions and additional work for the implementers/manual writers (if any). General: DIN opposes continuously to use the ":" qualificator both for determining the lookup context and the calling context, depending on the syntactical context of the ":". It shall only determine the calling context. "@" should determine the calling context. 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). 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. 8.4.3.1 retracting of an imported procedure shall be forbidden strictly: This is an uncontrollable far reaching effect, especially together witth re-export. It is in contradiction to general rules of SWE. retracting and abolishing should only be possible in the defining module. To make retracting of imported procedures imp-def, invites (forces) suppliers to implement it. 2 Less substantial Technical Comments ===================================== 5.5 3rd line: implementation specific features are not specified in the cd or standard; only implementation defined features 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.) 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()". 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). 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. 7.2.3.5 2nd para, last sentence: loaded is the wrong word. (cf. 3.12) prepared is correct. 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. 7.2.3.5 Last para: either definite violation or imp-def. Not both. 7.2.3.6 Last para: double defined end_module/1 behavior. (cf 7.2.3.5) 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! 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. 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. 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"? 7.8 and 8.3.1.1 2nd para: "public procedure" is not defined. 3 Editorial Comments ==================== 3.34 At least misleading in comparison with 3.28: module name qualification. 3.36 2nd line: the fist argument 3.38 What is "retrieved"? Is the clause defined in the defining module or visible in the lookup module? 5.6.2 The definition is misleading. Iff a processor supports ... then a) the processor shall not require... and b) the processor shall define... 7.2.1 The last paragraph belongs to 7.2.2. 7.2.2 Append the last paragraph of 7.2.1 7.2.4.1 According 7.2.3.2, with EL for export list, rename MI with IL for import list. 7.4 Clauses, last para: The predicate indicator P/N of the PREDICATE of Clause... (a head has no predicate indicator). __________end of Germany comments; beginning of Sweden comments _______ 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-ins as detailed below. Detailed comments 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. 3.2 "calling context" is probably obsolete or redundant. 3.4 "defining module" and 3.38 "source module". Are these ever different? 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. Table 1: Must it really be copied from Part 1? 7.1.1.3: Change "complete" to "visible". Are both this and 3.13 needed? 7.1.1.5: Are both this and 3.17 needed? 7.3: The complete database is absolute and should not be defined wrt. a procedure p and a module M. Propose to remove the first sentence. 7.3.1: Change "complete database of M" to "complete database". 7.3.2: The words "The complete database for a predicate p called from foo" don't make sense. 7.3.2 Example - delete references to accessible predicates. 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 7.5.4.a: Non-compliant syntax for the comma functor (see above). 7.7.1: "A decorated subgoal DS" - DS is not used anywhere. 7.7.2 and Table 3: DS and ES are not used anywhere. 7.7.3b: "the complete database is searched in the module m for a procedure q with defining module m" is strange and opaque. 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 fas as I can tell. 7.7.4g: change "defining module" to "source module". 7.7.6a: a ")" is missing. 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 mention that setof/3, bagof/3, findall/3, clause/2, asserta/1, assertz/1 and retract/1 have meta-arguments? 7.7.8: call/1 is not the only control construct that takes meta arguments. once/1 and catch/3 must be similarly extended. 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 contextmodule 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. 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 associat ed 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). 8.4.2.1: The text is not symmetric with 8.4.1.1 Misc: Propose to change the declaration :- module_interface(M). to :- begin_interface(M). for better naming consistency (cf. begin_module/end_module). _____________________end of document SC22 N2384 _____________________