[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
sentiments
Date: Fri, 30 May 86 15:34:53 est
From: Dan Friedman
Sent-by: Kent Dybvig
... define was merely an alias for set! ...
This is how things were prior to the Brandeis meeting.
This is how things were AT INDIANA prior to the Brandeis meeting. At
Yale and MIT they somewhat different (although not as different as you
suppose) and had been since at least 1981. Your quest for elegance is
noble but please try not to equate your own version of Scheme with
Scheme.
As I recall the feeling at the Brandeis meeting most of us were
willing to go along with the idea of limiting the use of "define"
internally to the semantics of SI&CP. This was in the interest of
good feeling about not undermining their book. I hope everyone
understands that I do not want to undermine their book, although I
would like to see them rewrite it without internal defines.
However, when I went along with this view I had underestimated how
damaging this decision would be to the characterization of Scheme
being a simple language. I was expecting a "comment" in the report
that stated that "use of define within the text of a program would
be restricted to the use as given in SI&CP." Instead, the
definition of "lambda" got changed.
I don't understand. Is it really the case that S&ICP never ever uses
internal defines in the body of a lambda? I'll check. In any case, if
internal definitions exist at all, LAMBDA is the ONLY form that's
affected, after macro expansion.
Instead, begin must be added to the list of special forms.
Not true, and I'm don't understand why you think so. Note that I
clearly put BEGIN in the "derived expression types" section. I will
include the usual expansion of it in a future draft; I forgot to note
that this was on my list of things to do.
Instead the macro for "letrec" must be conscious of it by having the
body be "(let () <body>)" where it should be <body>.
I proposed flushing internal definitions in the body of a letrec for
exactly this reason. But I don't see this as increasing the complexity
of LETREC significantly, and I was wrong to draw attention to it. I'll
try to figure out how to make this smoother.
Instead define must be added to the list of special forms.
What do you mean? Definitions aren't even expressions!
Instead the semantics of "set!" are weakened so that
it is not possible to just get by with "set!" and ignore "define".
As has been explained innumerable times, there is no way to avoid this
and have a language which is at all coherent with T and MIT Scheme.
Note that in all programming languages of the Algol/Pascal/C variety it
is an error to assign to an undeclared variable. That MIT Scheme and T
(and thus RRRS Scheme) also have this property is not coincidence.
Instead we must do something "special" with "lambda",
"named-lambda", "let", "let*", and "letrec".
Certainly the report is muddled, and I must accept the blame for some of
this muddle. I introduced a lot of the nonsense you're complaining
about into this version of the report in a quest for accuracy. I agree
with your complaint that internal definitions are intrusive, and I'll do
what I can to remedy the situation.
We have taken a rather elegant language and made it elitest.
I don't understand this use of that term.
I wanted all of my students to be able to implement "Scheme" when
they walked out of my course, now that is no longer possible.
This is false. Internal defines are not essential. If by "Scheme" you
mean absolutely everything described in the report, I would expect that
internal definitions (which can be implemented with a very small amount
of code) would be the least of any implementor's worries. What about
number I/O?
It was a great beauty of
Scheme that the four mentioned special forms along with identifiers and
application were the only syntax. It was wonderful that a CPS interpreter
for Scheme was all that was necessary to come to grips with in order to
understand the run-time architecture of Scheme.
Why isn't this still true?
My argument with internal-define is not that it is good or bad, but
that the subtlety of its definition is unnecessary with judicious use
of letrec and letrec should be a trivial macro. What happened?
How do internal definitions make LETREC more complicated? The (LET ()
...) (which would otherwise be a (BEGIN ...)) is trivial compared to
the rest of what LETREC has to do, and doesn't even have to be there at
all if you're not implementing the full language.
I have never liked internal defines.
Thanks for telling me, I hadn't figured this out.
I thought they were harmless
until I saw what havoc they introduced to the Report. I am trying
desperately to convince everyone that we made a mistake and we should
do everything in our power before we go public on this Report to
wait until we impose internal defines on everyone.
I'll do what I can to fix the presentation; I can at least certainly
make internal definitions less intrusive than they were in the RRRS. I
hope that will be sufficient. Personally, I wouldn't mind removing
internal definitions from the language, although special treatment of
definitions at top level of a file (which is another story altogether)
must stay. If you can convince everyone, including Sussman and Abelson,
that internal definitions should be flushed, then I'll flush them. If
you must persue this, I suggest you talk to Sussman on the telephone
about this; he isn't reachable by electronic mail until June 20, I
think. I'll try to find his phone number at Princeton or HP or wherever
he is.
Why does this question arise at this moment? I am angered by the
untimeliness of this debate. Why didn't it come up when the idea of
printing the report in SIGPLAN was first mentioned? This part of the
language hasn't changed.
Jonathan