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