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

Re: good books on scheme?

   From: Brent Fulgham <brent.fulgham@xpsystems.com>
   Date: Tue, 6 Feb 2001 09:19:14 -0800 

   I think one final problem is that SICP makes the point that there
   are conflicting definitions of "closure".  Some of the books missing
   the term "closure" from the index might have used a different term
   so as not to confuse it with the "mathematical" definition, ...

That is a pretty good reason to leave "closure" out, but in the case
of at least one textbook -- the one I co-authored -- it isn't the
actual reason that motivated us.  I explained that in a privately
emailed reply a moment ago to "bogo."  Since this off-topic thread
seems to be be continuing with or without my provocation, I herewith
include it for the rest of you:

   Date: Tue, 6 Feb 2001 09:55:39 -0600
   From: Michael Bogomolny <bogo@bigfoot.com>
   From a teaching perspective, Concrete Abstractions (Hailperin, Kaiser,
   Knight; Brooks/Cole Publishing Company) and Simply Scheme (Harvey and
   Wright; MIT Press) are both good books. However, they both fail the
   "closure test". ...

Thanks for the endorsement.  I probably shouldn't take our failure on
the "closure test" as something to feel defensive about (after all, we
are in good company), but I thought I'd offer some perspective on
*why* we didn't include this vocabulary term.  Instead, we simply use

The reason is that "closure" only makes sense in a particular
historical context, where procedures had previously been left "open",
that is with free variables not associated with any particular
binding.  This was the case in various pre-Scheme Lisps, and lead to
what was known as the "funarg problem," short for "functional
argument", though it also was manifested when procedures were used in
other first-class ways than as arguments, for example, as return
values, where it was confusingly called the "upward funarg problem"
(by contrast to the "downward funarg problem," where the arg was
genuinely an arg).  The "funarg problem" is what logicians had been
calling "capture of free variables," which occurs in the lambda
calculus if you do plain substitution, without renaming, in place of
proper beta-reduction.

So anyhow, an evolutionary milestone in the development of the Lisp
family of languages was the realizations that procedures should be
"closed", that is, converted into a form where all the variables are
bound rather than free.  (The way this is normally done, as others
have written in this thread, is by associating the procedure text,
which still has free variables, with a binding environment that
provides the bindings.)

Because this was such a big deal in terms of the languages' evolution,
Lisp hackers took to using the word "closure" rather than just
"procedure" to emphasize that they were talking about this great new
lexically scoped kind of procedure.

As with so many words, it stuck, and people continued using it long
after the distinction it was making ceased to be relevant.  (When was
the last time you saw a procedure that hadn't been closed?)

I find this kind of anachronism endearing, just like I grinned a bit
when I recently caught myself calling my compilers textbook the "red
dragon book" -- a name that distinguishes it from the "green dragon
book," which has been extinct for a decade and a half.  But I would
never consciously teach a new student to say "red dragon book" rather
than just "dragon book."  And I would never consciously teach a new
student to say "closure" rather than just "procedure."

So that's the reason we left it out of our book -- it is a name that
makes a distinction no longer relevant, and which would require
historical context to explain that would distract from the main issues
at hand.  (Of course, the distinction may be relevant in other
contexts, like a programming languages course where you are learning
about how languages work, and how else they could work.  So in EOPL it
may make perfect sense.) -max