-------------------------------------------------------------------- ISO/IEC JTC1 SC22 WG16 N174 Proposal of Disposition of Comments on Second CD 13816 -------------------------------------------------------------------- Response to Canada ------------------ CA-1 The Editor has been instructed to make these additions: form - a single syntactically valid unit of program text. 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). CA-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. CA-3 The Editor has been instructed to make the editorial changes you request. CA-4 The Editor has been instructed to add a cross-reference to section 1.6, which explains this usage. CA-5 In response to your comment CA-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. CA-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 CA-7 Yes, a special operator may be implemented as a macro. See section 4.3, paragraph 1, sentence 2 (on page 18). CA-7b No, this example is not correct. Thank you for bringing it to our attention. The Editor has been instructed to repair it. CA-8 The classes and 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. CA-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. CA-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. CA-11 See our response to your comment CA-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 Germany ------------------- GE-1 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. GE-2 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. GE-3 The Editor has been directed to correct these typos. GE-4 The Editor has been directed to remove the parenthetical text as you suggest. GE-5 The Editor has been directed to add "is" in the appropriate place as you suggest. GE-6 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 DIN for its comments. We believe the specification has been improved through actions taken in response. We hope that DIN 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 has been instructed to use your proposed class precedence list. 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 these 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 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 AFNOR for its comments. We believe the specification has been improved through actions taken in response. We hope that AFNOR will agree, and will find our responses satisfactory. -------------------------------------------------------------------- Additional small changes page 8, item 17, lowercase "inheritance" page 3, before sample header, change "were adopted" to "are used" -------------------------------------------------------------------- End of ISO/IEC JTC1 SC22 WG16 N174