[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Kent Dybvig's Comments on Scheme
BEGIN should certainly not add another contour. BEGIN is
equivalent to LET() if environments are not first class, but they are
in MIT Scheme. An incremental definition to the environment where the
subexpressions of the BEGIN expression are evaluated would have
different effects depending on whether a new contour was created or
not. I agree that BEGIN (for lack of a better name) should indicate a
compound expression and LET should be used for blocks.
Note that this is not contrary to all early Scheme papers
since in the Revised Report,
(BLOCK X Y) = ((LAMBDA (A B) (B)) X (LAMBDA () Y)).
X is evaluated in the environment where the BEGIN
expression appears, and Y is evaluated in an environment where no
bindings have been added. In a dialect without first-class
environments and without internal definitions, the environment where Y
is evaluated is the same as that where X is evaluated, thus no
contours have been added.
I think that there are only two valid reasons for adding
- They provide a convenient syntax for something which
could be expressed only considerably more clumsily without them.
Example: COND (as compared to nested IFs). These are usually macros
which expand into the clumsier form.
- They provide an extension to the language which requires
special handling by the interpreter or compiler. Their effect could
otherwise not be achieved. Example: QUOTE. These are the "TRUE"
I don't think that CALL-WITH-CURRENT-CONTINUATION falls in
either class, so there is no need to make it a special form. Besides,
a portable program would not be able to rename it since we have not
specified a way for adding syntactic extensions.
Allowing IF not to have an alternative sub-expression is
convenient because it is clear and eliminates the need for WHEN,
another special form. I don't like the proliferation of special forms
and would object strongly to requiring another one for this purpose.
I can't see that there is a difference between WHEN and IF in terms of
compile-time checking. IF with two subexpressions and IF with three
subexpressions can be treated as different beasts.
I agree with the remaining three points.
- Bill Rozas (JINX@MIT-MC)