ISO/ IEC JTC1/SC22 N2095

Date: Mon, 8 Apr 1996 18:22:39 -0400 (EDT)
From: "william c. rinehuls" <rinehuls@access.digex.net>
To: SC22docs@dkuug.dk
Subject: SC22 N2095

ISO/IEC JTC 1/SC22
Programming languages, their environments and system software interfaces
Secretariat:  U.S.A.


ISO/IEC JTC 1/SC22

N2095

April 1996

TITLE:		Disposition of Comments Report on Second CD Ballot
		for CD 13815, Programming Languages, Their Environ-
		ments and System Software Interfaces - Programming
		Language Lisp


SOURCE:		Secretariat, ISO/IEC JTC 1/SC22



WORK ITEM:	JTC 1.22.23



STATUS:		N/A



CROSS REF.:   	SC22 N1976, N2080, N2096



DOCUMENT TYPE:	Disposition of Comments Report



ACTION:		To SC22 Member Bodies for information.

		Upon receipt of the final text from WG16, the DIS
		will be forwarded to JTC 1 for approval.




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


____________________________________________________________________________


ISO/IEC JTC1 SC22 WG16 N175

Disposition of Comments on Second CD 13816

--------------------------------------------------------------------

Response to Canada
------------------


(1)   The Editor has been instructed to make these additions:

                       form - a single syntactically valid unit of
                           program text capable of being prepared for
                           execution.

                       dynamic - having an effect that is determined
                           only through program execution and that
                           cannot, in general, be determined
                           statically.

                       dynamic variable - a variable whose associated
                           binding is determined by the most recently
                           executed active block that established it,
                           rather than statically by a lexical
                           apparent block according to the lexical
                           principle.

                       operator - the first element of a compound
                           form, which is either a reserved name that
                           identifies the form as a special form, or
                           the name of a macro, or a lambda
                           expression, or else an identifier in the
                           function namespace.

      In addition, for consistency, the Editor is directed to change
      "defined" to "established" in the middle of paragraph 2 of
      section 3.1 (on page 15).


(2)   The Editor has been directed to make the editorial changes to
      the type hierarchy diagrams which include moving the two type
      diagrams to a single textual point and merging them.  Our belief
      is that this will statisfy your underlying need, though in a
      different way.


(3)   The Editor has been instructed to make the editorial changes
      you request.


(4)   The Editor has been instructed to add a cross-reference to
      section 1.6, which explains this usage.


(5)   In response to your comment (1), the Editor has been instructed
      to add a definition of "form" which clarifies that expressions
      such as "(2 3 4)" are not forms because they are not program
      text, capable of being prepared for execution.

      The editor has also been instructed to change references to
      "form" in the middle of page 3 to "expression" where normal
      rules for program evaluation might or do not apply.


(6)   The Editor has been instructed to extend the list shown here to
      contain new names (suggested by France) which would make the
      list complete:

                       and block case case-using cond for or let* setq
                       with-error-output with-handler
                       with-open-input-file with-open-io-file
                       with-open-output-file with-standard-input
                       with-standard-output


(7)   Yes, a special operator may be implemented as a macro.  See
      section 4.3, paragraph 1, sentence 2 (on page 18).


(7)   No, this example is not correct.  Thank you for bringing it to
      our attention.  The Editor has been instructed to repair it.


(8)   The classes <basic-array> and <basic-vector> are abstract
      classes.  Your confusion on this matter probably stems from an
      improper understanding of the term "instance of" which intends
      to include the possibility of instances that are not direct
      instances.  See explanatory text on page 90, which we believe is
      very clear on this point.  See also definitions of "direct
      instance" and "instance" on pages 7-8.

      The Editor has been instructed to add the following definition
      for "abstract class":

                       abstract class - a class that by definition has
                           no direct instances.


(9)   This is a correct observation about the limitations of the
      language.  Support for such control of floating point output was
      discussed at previous meetings of WG16 but no acceptable
      proposal was advanced.


(10)   This is a correct observation; however, in most places it is
       not a problem because ISLisp has no bit manipulation
       operations.

       However, as a result of discussion on this matter, the Editor
       has been instructed to add a note in section 18.1 on page 102
       noting that both bit order and byte order are
       implementation-defined when doing byte-oriented binary I/O.


(11)   See our response to your comment (2).


WG16 thanks Canada for its comments.  We believe the specification has
been improved through actions taken in response.  We hope that Canada
will agree, and will find our responses satisfactory.


--------------------------------------------------------------------

Response to France
------------------


(FR-1)   The Editor has been instructed to add this definition:

                       condition - An object that represents a
                           situation that has been (or might be)
                           detected by a running program.


(FR-2)   The Editor has been instructed to use the tabular format you
         suggest.


(FR-3)   The Editor will add new item between items 2 & 3, page 13:

                       The class precedence list for <NULL> observes
                       the partial order <NULL>, <SYMBOL>, <LIST>,
                       <OBJECT>.

(FR-4)   The Editor has been instructed to add the operator names as
         you suggest.


(FR-5)   Rather than fix the problem as you suggest, the committee
         opted instead to direct the Editor to make this change: On
         page 3, in paragraph 2 after the sample heading add "in this
         notation" after the parenthetical text, clarifying that the
         underline notation is used only in headings.


(FR-6)   We directed the Editor to treat the problem as an editorial
         omission and restore ":boundp".

         Add to slot-opt:

                       :boundp  boundp-function-name

         Add to slot option descriptions:

                       - The :boundp slot option specifies that an
                         unqualified method with the parameter profile
                         ((x class-name)) is to be defined on the
                         generic function named boundp-function-name
                         to test wether the given slot has been given
                         a value.  The :boundp slot option may be
                         specified more than once for a given slot.


(FR-7)   The Editor has been instructed to make the suggested change.


(FR-8)   The Editor has been instructed to make the suggested change.


(FR-9)   The Editor has been instructed to make changes substantially
         like those you propose, as in:

                       ... with first argument y and second argument x.


(FR-10)   The Editor has been instructed to take the second of your
          two alternative suggestions, and also to repair various
          singular/plural errors in this sentence.


(FR-11)   The Editor has been instructed to make the suggested change.


(FR-12)   The Editor has been instructed to make the suggested change.


(FR-13)   Since comment (FR-2) was acted upon, there is no need for
          action here.


(FR-14)   The Editor has been instructed to remove "Example:", as you
          suggest.


(FR-15)   The Editor has been instructed to make the change you
          suggest, as well as to make a similar change to ERROR.


(FR-16)   The Editor has been instructed to add the missing NIL in the
          last example on this page.


(FR-17)   The Editor has been instructed to make the suggested change.


(FR-18)   The Editor has been instructed to make the first of your
          proposed suggestions.


(FR-19)   Because this error is not required to be handled and would
          not have portable behavior, WG16 has declined to accept this
          suggestion.


(FR-20)   Discussion of these examples revealed a belief that it would
          be difficult to make a reliable technical assesment of the
          correctness of these examples and with regret we agreed not
          to include them at this time.  We do believe examples are
          often useful and may wish to revisit this matter at a later
          time.  In the interim, we encourage the use of these and
          other examples as a focus for discussion in forums other
          than the specification itself.

          We also note at least one specific bug in the examples,
          which is that keywords (such as :x) are not defined to
          self-evaluate in CREATE forms.


WG16 thanks France for its comments.  We believe the specification has
been improved through actions taken in response.  We hope that France
will agree, and will find our responses satisfactory.


--------------------------------------------------------------------

Response to Germany
-------------------


(1.8.2)   In the case of the specific example you cite, we believe the
          error type "not-an-output-stream" (page 121) is already
          sufficient.

          More generally, discussion of your comment revealed some
          misunderstandings with the WG16 committee present at this
          meeting.  The Editor was directed to correct this confusion
          by rewriting section 1.8.2 as follows:

                       1.8.2 Pervasive Error Types

                       Most errors are described in detail in the
                       context in which they occur.  Some error types
                       are so pervasive that their detailed
                       descriptions are consolidated here rather than
                       repeated in full detail upon each occurence.

                       1. [...]  2. [...]  3. [...]

                       This list does not exhaust the space of error
                       types.  For a more complete list, see section
                       21.4.


(1.9)   After some discussion, and in some cases for reasons that
        differ from those you cited, it was agreed to direct the
        Editor to strike the offending paragraph as you suggest.


(2.2)   The Editor has been directed to correct these typos.


(2.2)   The Editor has been directed to remove the parenthetical text
        as you suggest.


(6.4)   The Editor has been directed to add "is" in the appropriate
        place as you suggest.


(7.2.1)   The Editor has been directed to make the wording consistent
          with wording used for DEFMACRO on page 60. (It is our belief
          that the requirement of textual precedence is intentional
          and that this would be an inappropriate time to revisit this
          restiction.)  The new text will read:

                       During preparation for execution, a DEFMETHOD"
                       form must be preceded by the DEFGENERIC form
                       for the generic function to be specialized.


WG16 thanks Germany for its comments.  We believe the specification
has been improved through actions taken in response.  We hope that
Germany will agree, and will find our responses satisfactory.


--------------------------------------------------------------------

End of ISO/IEC JTC1 SC22 WG16 N175