[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Kent Dybvig's Comments on Scheme
Re: Kent Dybvig's comments on the preliminary report on Scheme
I'd like to briefly add my "votes" on Kent's suggestions and bring up
some additional complexities in the issues he raised.
I prefer (REC name (LAMBDA args . body)) first, then MIT-style
NAMED-LAMBDA second. (I support both.) Will's discussion summarizes
my reasons quite well. We should NOT require all lambdas to be named.
IF without else part
I would not mind requiring WHEN in this case, making (IF a b)
syntactically incorrect. This allows better compile-time checking. I
use WHEN myself to make this distinction and find it useful. BTW, I do
NOT find UNLESS useful, since (WHEN (NOT ..)..) usually reads better.
BLOCK vs BEGIN vs LET()
As Will points out, the real question is whether the construct we have
in mind is a compound expression or an Algol-like block containing both
declarations and expressions to be evaluated. I prefer BEGIN for the
former and LET for the latter.
The problem is that Will suggests (paraphrasing someone else) that
(BEGIN ...) might be equivalent to (LET () ...). I have conflicting
thoughts on this. Pro: if they are the same, then I would vote to
remove BEGIN from the (essential) language as hopelessly redundant with
LET. Con: early papers by Steele and Sussman treat (BEGIN a b) as a
macro for ((LAMBDA (ignored-id) b) a), which is equivalent to
(LET ((ignored-id a)) b). Thus, BEGIN already is a scope-extending
This has the following practical consequence. What is the scope of FOO
in the following?
(define (f ...)
(define g ...)
(define foo ...))
I understand that MIT Scheme "promotes" both G and FOO directly under
F. This hack is needed for macros that expand into multiple DEFINEs
and thus must be "wrapped" in something to be spliced in correctly.
If we define BEGIN in terms of LET, then the scope of FOO will have to
be confined to the scope of the BEGIN.
What should we do? I vote that BEGIN indicate a compound expression,
contrary to early Steele&Sussman, and that LET() be used for
CASE expressions with single keys
We will accept single keys in CASE expressions. If ELSE is to be a
single key in the last clause, however, it will have to be enclosed in
parentheses to avoid being interpreted as "otherwise".
"CALL-WITH-CURRENT-CONTINUATION" is nonsense to the unititiated, too.
I will support both, but feel like it's silly to have the long name.
Must this be a procedure (e.g. a potential funarg) or can we treat it
as a special form?
What's the problem? Just call them "optional" as a group. What we've
been arguing is whether I have "true Scheme" if I have some kind of
representation for "real numbers" but don't support a certain set of
functions. This is irrational!! (sorry)
I strongly abhor Common LISP-style genericity. As Will says, "generic"
operations on numbers with multiple REPRESENTATIONS is one thing, but
trying to be generic across different kinds of things is something
I feel very strongly that symbols, as processed by the reader, should
NOT be case sensitive and that (EQ? 'a 'A) be true. STRING->SYMBOL
should preserve case, however, and (EQ? '|a| '|A|) should be false.
-- David Bartley (Bartley @ TI-CSL)