Subject: Re: defun within let From: Erik Naggum <erik@naggum.no> Date: 1998/10/04 Newsgroups: comp.lang.lisp Message-ID: <3116498427831232@naggum.no> * 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