Subject: SC22 N2384 - Vote Summary for CD 13211-2: Prolog Modules

From: "william c. rinehuls" <[email-masked]>
Date: Mon, 13 Jan 1997 17:18:43 -0500 (EST)

________________________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:  [email-masked]

___________________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 _____________________