[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Comments on the Preliminary Report

A) Special forms:

1)	In our system (MIT-Scheme) named lambdas can be obtained by
using the special form NAMED-LAMBDA with the following syntax:

(named-lambda <formals> <body>)

where <formals> is a pair whose car is the name and whose cdr is a
normal formal parameter specification for a lambda.  Thus


evaluates to a procedure internally named FOO, which accepts any
number of arguments which will be collected into a list named ALL.

	In the internals of the implementation all lambdas are named.
The special form LAMBDA is actually a macro which expands into
NAMED-LAMBDA with an unreadable name.  This syntax matches the syntax
we use for definitions of procedures, and the DEFINE macro expands
the implicit lambda into a NAMED-LAMBDA:


	Named lambda appears explicitely only rarely in our code.
I therefore feel that forcing all lambdas to be named by the
programmer is very inconvenient and not justified by need.

	I think that we should not modify the syntax for LAMBDA, and
optionally add the special form NAMED-LAMBDA with the syntax specified

2)	I don't like BEGIN myself and voted against it, but I don't
think BLOCK is a good name either.  The special form LET corresponds
more closely to a block in a block-structured language than BEGIN
does.  I would much rather use a name which indicates the
sequentiality and therefore the meaning of the special form, but BEGIN
was found to be the least unacceptable of the alternatives.

B) Procedures:

1)	The default name of a procedure should be meaningful and is
otherwise irrelevant.  I don't think that call/cc is a good default
name since it is not meaningful.  I agree that
call-with-current-continuation is very long, but anyone who is really
attached to any other name (I like catch, which is just as
inappropriate) can always define it to be the value of
call-with-current-continuation.  The names of special forms are
terribly important, however, since we have not agreed on a way for
defining new ones.

3)	While making the length procedure be generic may be
reasonable, I think we should not go the Common Lisp way and make
everything generic until we come up with an efficient and elegant way
for incrementally extending the domain of procedures.  The same
argument that would make length generic would make first (car) and
rest (cdr) generic, but this is too inefficient.  Choosing only some
data-structure functions to be generic and not others would be

C) Lexical matters:

	I disagree.  It is terribly confusing to have Length and
length functions that do different things.  Uninterned symbols or
strings can be used when case matters.  When implementing a Prolog in
Scheme, a new parser must be written.  This parser can easily avoid
the case-insensitivity of Scheme by not canonicalizing the case before
interning the symbols.
	An entirely different matter is which way case is
canonicalized.  I think that Scheme parsers should coerce to lowercase
before interning.