From ...
From: Erik Naggum <erik@naggum.no>
Subject: Re: defun within let
Date: 1998/10/04
Message-ID: <3116498427831232@naggum.no>#1/1
X-Deja-AN: 397607048
References: <6v6l3c$d8j$1@news-2.news.gte.net>
mail-copies-to: never
Organization: Naggum Software; +47 8800 8879; http://www.naggum.no
Newsgroups: comp.lang.lisp

* rme@nightfly.apk.net (R. Matthew Emerson)
| now, i've certainly not read a great deal of lisp code in my time, but it
| seems that i rarely see anything like this, except in books.  is there
| some reason for this?

  I regard this as an optimization technique, not as normal coding style.
  accessing a special variable is generally more expensive than accessing a
  closure variable and this may matter in some circumstances.  sometimes,
  you have to perform a number of sanity checks on global variables because
  they may get nuked by the user or set to weird values.  in such cases,
  you can save yourself a lot of trouble by inhibiting direct access to the
  variable and performing the sanity checks in the setter function, knowing
  that there are no other ways to set the variable.

  normally, I regard this kind of "information hiding" to be anathema to a
  good software development environments because recompiling the closure
  or re-loading the file they are contained in irrevocably destroys the
  encapsulated information, so it should be employed only when you know
  that the closures are loaded only once, and I prefer that to be before
  dump time for the Lisp image.

  when implementing a new fully table-driven approach for international
  character sets in Allegro CL, I found, after heavy profiling, that so
  much time was wasted in accessors into the character set definition
  objects and special variables that it payed well to make a giant closure
  with all the functions accessing pre-accessed slots from the objects as
  closure variables, set by the sole setter function for the character set.
  since this is a fundamental framework that when changed (almost) requires
  re-dumping the Lisp image, anyway, I thought this was a reasonable cost
  to obtain the needed safety and speed.

  in other words, I think this approach is fine when the code is known not
  to be changed in the life-time of the application and no access to the
  encapsulated information will ever be needed, i.e., when the code is
  completely static.  this happens less often than one might think.

#:Erik