Re: good books on scheme?

To: plt-scheme@fast.cs.utah.edu

Subject: Re: good books on scheme?

From: Max Hailperin <max@gac.edu>

Date: Tue, 6 Feb 2001 11:27:09 -0600

In-reply-to: <EDFD2A95EE7DD31187350090279C676701683A96@thresher.corp.xpsystems.com>(brent.fulgham@xpsystems.com)

References: <EDFD2A95EE7DD31187350090279C676701683A96@thresher.corp.xpsystems.com>

Sender: owner-plt-scheme@fast.cs.utah.edu

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 "procedure". 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