[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
planned changes to R3.95RS
I have agreed to delay the R4RS until after the P1178 meeting in
early July. Aside from formatting and the changes listed below,
I expect the R4RS to be identical to the R3.95RS. Please let me
know if any other changes are called for, or if any of the changes
listed below should not be made.
William Clinger
----------------------------------------------------------------
Here is a list of the changes that I plan to make to the R3.95RS
to obtain the R4RS. Changes that (in my opinion) do not change the
technical content are identified as an [Editorial change.].
Sections 2.1 (Identifiers), 2.3 (Other notations), and 7.1.1 (Lexical
structure). Add ... as a new peculiar identifier.
Section 4.2.5 (Delayed evaluation). [Editorial change.]
Change "complete description" to "more complete description".
Section 6.3 (Pairs and lists). Make list-ref and list-tail essential.
(We rejected this at Snowbird, but the editors of the IEEE draft
standard have requested that we reconsider.)
Section 6.5.1 (Numerical types). [Editorial change.]
Change the two occurrences of "while" to "although".
Section 6.5.4 (Syntax of numerical constants). [Editorial change.]
Replace the three opening sentences of the fourth paragraph by
In systems with inexact numbers of varying precisions it may be
useful to specify the precision of a constant.
For this purpose, numerical constants may be written
with an exponent marker that indicates the desired precision
of the inexact representation....
Section 6.5.5 (Numerical operations). [Editorial change.]
Add the following example to the description of round:
(round 7/2) ==> 4
Section 6.5.5 (Numerical operations). Change the equation for
inverse tangent from
$$\tan^{-1} z = -i \log ( (1 + i z) \sqrt{1/(1 + z^2)} )$$
to the new equation voted by X3J13 (Common Lisp):
$$\tan^{-1} z = (log (1 + i z) - log (1 - i z)) / (2 i)$$
This changes the branch cuts for atan, affecting programs
that call atan with imaginary arguments. The change has
no effect on the behavior of atan with real arguments.
Section 6.6 (Characters). Require that char->integer and
integer->char be one-to-one. (Note that this does not satisfy
the request by the authors of the IEEE draft standard; see below.)
Section 6.7 (Strings). The char-upper-case? procedure, which
I accidently deleted from this section, will be restored.
----------------------------------------------------------------
Here is a discussion of some requested changes that I do not plan
to make. The first few (starred) requests were made by Chris
Hanson, on behalf of the IEEE editors, in a recent message.
* We believe that `peek-char' is underspecified and request that the
specification be improved. [Does anyone remember the arguments? It's
possible that the added note in R3.95RS is sufficient -- cph]
I believe the arguments mostly had to do with the behavior of
peek-char on interactive ports, but some of the arguments may have
had to do with problems occasioned by multitasking. I believe the
note in R3.95RS clarifies the behavior of peek-char on interactive
ports, so that its behavior is as well-defined as that of read-char.
There is a legitimate question concerning the behavior of peek-char
in the presence of multitasking, to which there are two obvious
answers, but I don't believe the question is of enough practical
importance to delay the acceptance of peek-char while we try to
decide between them.
* We suggest that `integer->char' and `char->integer' should be
constrained more carefully. In particular, the order isomorphism
requirement seems excessively strong; perhaps a one-to-one map
requirement would be more appropriate.
>From the programmer's point of view, the order isomorphism is a
nice property, and I've never heard anyone complain that it would
be difficult or inefficient to implement on some system, so I don't
understand the argument for change. The main thing wrong with it
is that it appears to be legal for an implementation to make
(char->integer c) be 0 for all characters c, and to make
(integer->char 0) be #\a. I plan to fix this by requiring that they
be one-to-one, but that makes the requirement stronger, not weaker.
* We request deleting the "alphabetic" restriction on the domains of
`char-upper-case?' and `char-lower-case?' (extending these domains to
all characters), defining the procedures to return #F for
non-alphabetic characters.
This is already done in R3.95RS.
Someone suggested that the specification of delay and force be
tightened up in a certain, very specific way. I felt this would be
inconsistent with the rest of the deliberately loose specification
of promises.
Several people objected to the discussion of mutable and immutable
objects in section 3.5 (Storage model). These objections fell into
three groups. Some people just forgot the difference between "is an
error" and "signals an error". Others, perhaps confusing semantics
with implementation, objected on the grounds that no Scheme procedures
were provided to test or set what they perceived as a "mutability bit".
The third group objected in principle to read-only constants. I take
the third group seriously, but I am more convinced by the following
arguments in favor of read-only constants: (1) Scheme constants have
been read-only since the R3RS, and the burden of proof should lie with
those who advocate change; (2) constants are read-only in most
programming languages (exceptions include C and Smalltalk), and
most programmers seem to agree that side-effecting a constant is poor
style even if it is allowed; and (3) read-only constants are important
for some embedded systems, an application area for which Scheme seems
well-suited.
There still seems to be no consensus on another name for letrec.
Chris Hanson deserves great credit for developing a macro facility
along the lines envisioned at Snowbird, but the well-specified part
of it does not seem to be sufficiently powerful. I gather that the
system itself is adequately powerful, provided we accept that "the
implementation is the specification", but we certainly don't want to
accept that. I think we are very close to having a well-specified
system that does what we need, but I recommend that the R4RS not
include a macro facility because we're not quite there yet.