[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Remaining questions & remarks (2)
1. BEGIN vs. SEQUENCE...
(a) leave things as they are (BEGIN essential with non-essential
synonym SEQUENCE),
(b) remove BEGIN and make SEQUENCE essential (noting in the Notes
section that BEGIN, like #!TRUE etc., should be supported by
those implementations which care about running code written in
the past year).
*****> (a). Fix the book so we can get rid of SEQUENCE.
2. <names of arithmetic comparators>
(a) leave things as they are
(b) flush the alternative names <? <=? >? >=? =?
*****> (b). MacScheme will continue to support the alternative names.
3. REC and NAMED-LAMBDA...
(a) Keep both
(b) Flush both
*****> (b).
4. SUBSTRING-MOVE-LEFT! and SUBSTRING-MOVE-RIGHT!...
*****> Flush them, but encourage Chris Hanson to publish his suite of
operations in a separate document.
5. <the possibility of parallel or interleaved argument evaluation>
*****> Drop the comment. (I use call-without-interrupts, but that
might not be so sweet on some multiprocessors.)
6. Number input exactness: two proposals have been advanced to decide whether
a number is exact or inexact if it has no #I or #E prefix and contains no
trailing #'s.
(a) Inexact if there are digits following a decimal point, or if
exponential notation is used. Otherwise exact. (This makes
exctness similar to "floatness" in CL.)
(b) A proposal which Will advanced, which I'm unable to locate right
now, so he'll have to re-send it.
I'll additionally advance another alternative, and you can make up more of
your own:
(c) Always exact. E.g. "1.2" is exact.
*****> (b). The proposal was that exponents be treated as shorthand, so
for example 1.2e3 would be treated as though it had been written 1200,
1.2000e3 would be treated as though it had been written 1200.0, and so
on; if, after getting rid of the exponent in this way, there are
digits following a decimal point, then assume inexact; otherwise
assume exact.
(a) is also ok. I think scientists and engineers would quickly
become exasperated by (c), however.
7. Must a port still be a port...after being closed?
*****> No, but we shouldn't make a big issue of whatever we decide.
8. Apparently there's no difference between ABS and MAGNITUDE. Should we
keep both? If so, should I change the presentation in any way?
*****> Flush MAGNITUDE. Talk about ABS where MAGNITUDE is now talked
about.
9. ANGLE is what Common Lisp calls PHASE; any interest in changing the
name? ...
*****> I don't care.
10. Two-argument arctangent (ATAN Y X) is unnecessary, since its effect
can be trivially achieved by (ANGLE (MAKE-RECTANGULAR X Y)). Do we
apply Occam's razor and remove it? If it's retained, then I'll just
document it as being the same as (ANGLE (MAKE-RECTANGULAR X Y)).
*****> PLEASE don't flush two-argument ATAN, because an implementation
that supports flonums but not complexnums is going to have a hard
time with (ANGLE (MAKE-RECTANGULAR X Y)).
11. ...Is anyone opposed to having an essential procedure PROCEDURE?...
*****> I very much want one. I agree with Dan that
(call-with-current-continuation (lambda (k) (procedure? k)))
must be true.
12. (if x 1) vs. (cond (x 1)) -- this is inconsistent...
(a) Change IF expressions so that they return the value of the
second form if the first form evaluates to [true].
(b) Change COND and CASE so that they return an unspecified value if
there is no ELSE clause.
*****> (a).
13. Many people would like to see the (define ((((a b) c) d) e) ...)
feature go away.
*****> Flush. MacScheme will continue to support it.
14. Status of LOAD not resolved. If, as I suggested, LOAD is only
to be syntactically valid at top level of a file, shouldn't it be
renamed to be INCLUDE ?
*****> LOAD should be syntactically valid only at the top level of a file.
I suppose it should be renamed to INCLUDE, but I don't want to.
LOAD seems a more appropriate name for something that will in fact
be used interactively, even though we don't talk about interactive
programming in the report.
15. Page breaks and tabs are mentioned in the report (actually I guess I
added them - sorry), but there are no #\PAGE or #\TAB characters...
*****> Please neutralize the places that mention tabs and page breaks.
Let's not get hung up about characters.
16. If page breaks are documented, should [they] terminate comments?
*****> I think so.
17. Bartley says: "the second sentence of the description of EQUAL? should
say that EQV? is used for all objects except pairs, vectors, and
strings." Forcing it to use EQV? seems kind of random to me. This
would of course make my notion of "apparent equivalence" useless,
destroying what I deluded myself into thinking was an elegant symmetry
between EQV? and EQUAL?; maybe it's a bogus idea anyhow. I
intentionally wanted to be silent on this point, allowing EQUAL? to
return true more often than EQV? perhaps, but I don't care that much.
*****> I think your "apparent equivalence" was a valiant effort on behalf
of a lost cause. I think Bartley's suggestion will simplify the
report and will make the language easier to understand and use.
-----
Presentation questions:
18. Several people have complained about Clinger's perhaps overly accurate
description of what happens when variables become bound. To be
accurate, we have to say that locations are created and the initial
value is stored in the location, but this doesn't sit well with the
desire to have Scheme sound like an almost-functional language.
What to do?
*****> Admit that Scheme isn't functional. Add a note to the effect that
in programs without side effects one can safely pretend that the
variables are bound directly to the arguments.
19. What should the dedication be? Sussman suggested the PDP-6, which was
the world's first Lisp machine, but some people didn't like this joke.
I have changed it to Christopher Strachey in the draft.
*****> The abstract from the RRRS was a better joke, because it said
something serious. A dedication to DEC PDP-6 Serial Number 2
could well offend the memory of the person to whom the Algol 60
Report was dedicated, so I think we'd better flush it. Do we
have to have a dedication? I'm not sure how many of us actually
met Christopher Strachey. I remember Alonzo Church from the 1982
Lisp Conference, and he might be better; maybe we could dedicate
the report to both. I believe that Church died a couple of years
ago, but I might be thinking of Haskell Curry instead. Dan? Mitch?
20. Is it OK to replace "Lazy ML" with "SASL"...
*****> Yes.
21. Should section numbers be zero-based?
*****> I've decided that zero-based numbering is perceived as cutesy.
I've found it helpful to have an unnumbered introductory section
at the beginning of a chapter, which I think of as section 0 of
that chapter, but I think it's best not to number it that way.
My apologies for setting the precedent in the RRRS.
22. Was Scheme the first programming language to have first-class lexical
closures? Can we say anything edifying along these lines?
*****> I don't think Scheme was the first. Scheme is unique not because
it was the first to have anything (except full continuations, and
even there it was anticipated by one of Reynolds's unimplemented
languages), but because it was nearly the first at many things
and succeeded in integrating those avant garde features.
23. I flushed the historical note "CATCH could be provided by a procedure"
sentence (again, because two or three people thought it was random and I
agreed), but some of you have complained about this. Why should this
bit of history be present, but not others that are at least as
important?
*****> Something needs to be said about the evolution of the special form
into a procedure having a different name. As the paragraph stands
in the 3 June draft, it makes no connection between the operators
mentioned in the paragraph and call-with-current-continuation. The
typical reader will wonder why the paragraph is there. The reason
that history is called for in this instance is that the concepts
are completely new to most readers, and they will need help to
appreciate their significance. Someday the rationale will be
unnecessary, but by then the R3RS will be a standard reference
cited by people who want to talk about the history of
continuations.
I favor adding a sentence such as "CALL-WITH-CURRENT-CONTINUATION
is equivalent in power to the 1975 CATCH, but is a procedure rather
than a special syntax."
24. CALL/CC was mentioned in a sentence in a rationale in the RRRS. I
flushed the reference because (a) a number of people find the name
CALL/CC quite distasteful and (b) it is inconsistent to mention here
that some scheme implementations provide an alternate name for this but
not also do so for LABELS, BLOCK, and a zillion other things.
*****> As someone who writes manuals for a mass audience, I find the name
CALL/CC quite distasteful. It was in the RRRS to placate those
who objected to the length of CALL-WITH-CURRENT-CONTINUATION.
This was a political compromise; I suggest we leave the RRRS
wording alone rather than try to achieve a new compromise.
25. How best to resolve the inconsistencies between terminology in text and
semantics? Namely: "I", "Ide", "identifier" in semantics vs. "variable"
in text; "Com", "command" in semantics vs. "statement" in text.
*****> In the abstract syntax, say "identifiers (variables)" and
"commands (statements)".
26. FORCE & DELAY are still problematic...
*****> I don't care.
27. Is 3.0.2 (description of procedure calls) a good place to take note that
() is not a valid procedure call?
*****> Ok with me.
28. In section 0.0, 2nd paragraph, before the terms "variable" and
"identifier" have been defined, it should say "variable" instead of
"identifier" to be consistent with the rest of the report. Is that OK?
*****> Yes. Dan points out that the semantics of "variable" is highly
variable, but we have an advantage over most authors in that people
can turn to the formal syntax and semantics if they want to know
what's really going on. Section 2.0 is a pretty good informal
description. I think people can deal with a few loaded terms
in an overview like section 0.0.
29. There are two nonterminals in the BNF that need names. Currently they
are called <formals> and <formalz> which was never intended to be a
serious suggestion (I put it there to see if anyone would actually read
the BNF!). Actually one or both of these can go away if NAMED-LAMBDA
and/or (DEFINE ((( ...) ...) ...) ...) go away. Can someone who likes
these things take a look at the BNF and suggest names for these?
*****> I hope NAMED-LAMBDA and the complicated DEFINE syntax depart from
the report, but even if they do we still have to deal with <formalz>
in the (DEFINE (FOO . X) ...) syntax; perhaps the possibilities
could be expanded in-line.
30. Someone wanted me to avoid discussion of immutable objects in the
discussion of operational equivalence in the 2nd paragraph before entry
for EQV? . I want to mention immutability there because I think it's
important to warn users that this might be the case, otherwise they can
easily end up writing unportable code.
*****> In my opinion, the paragraph in question is too little to deal
with the problem. It uses "immutable" without explaining what
it means; worse, it appears that the typical reader is supposed
to know as a matter of course that "mutation procedures" (whatever
they are) can't be applied to immutable objects. As to which
objects are immutable, all we have is the suggestion that objects
returned by literal expressions may be immutable.
I believe the paragraph at the end of 3.0.1 is sufficient. The
report is a definition, not a tutorial.
-----
DISPLAY writes characters like WRITE-CHAR does.
*****> I assume it's ok for an implementation that represents characters as
imaginary numbers to have (DISPLAY #\a) print "-97i"?
Peace, Will