Re: Kent Dybvig's Comments on Scheme

[David Bartley <Bartley%ti-csl.csnet@csnet-relay.arpa>]

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.

Lambda Syntax

    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
    operation.

    This has the following practical consequence.  What is the scope of FOO
    in the following?

	(define (f ...)
	   (define g ...)
	   (begin
	      (define foo ...))
	   body)

    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
    Algol-style blocks.

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/CC

    "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?

Transcendental functions

    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)

Generic LENGTH

    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
    else.

Case-sensitive symbols

    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)
-------