On Thu, Jan 30, 2003 at 10:30:33AM -0800, Wayne O. Cochran wrote: > My response way "bah" -- Lisp allows you to redefine > functions -- even the builtin ones (although this is > not generally a good idea). To be a language lawyer, > here is a quote from Steel's "Common Lisp," sec 5.3.1, p.85.
Steele's ``Common Lisp'' is not the specification for the language ANSI Common Lisp. The Common Lisp HyperSpec is perhaps the best reference online, and is supposed to differ from the ANS in only minor formatting issues. This section in particular: http://www.lispworks.com/reference/HyperSpec/Body/11_abab.htm > If one could not redefine the builtin functions then > one would have to keep mental track of the very large > set of functions, macros, etc... that are predefined > in Lisp. This is why packages are used. > Also, even if one could not redefine the builtin > functions, the problem should manifest itself > at definition time: > > * (defun max (a b) (if (> a b) a b)) > MAX > * #'max > #<Interpreted Function MAX {4801E451}> > > Everythings seems fine at this point. Shouldn't > I have at least been issued a warning of some sort?!? Yes, it could be desirable, and implementations such as Allegro will do so. Someone else posted some code that could achieve a similar effect in CMUCL, you may want to investigate that. I haven't run into the problem myself. > > You created an infinite regress. > > Assuming what I did was wrong, I am a little bit curious > as to how this manifested itself. I have a hard time > seeing how this could have triggered an "infinite regress." > Either my max or the system's max should have been invoked. > Can anyone explain how the system could have been > confused into issuing multiple recursive calls? With the assumption that functions such as CL:MAX cannot be redefined, it is possible for the compiler to make further assumptions with regards to the types of arguments and results of calls to said function. CL:MAX is a fairly heavily optimized function, and there are various transformations defined on it internally. It is likely that one of those broke when you redefined the function. In other words, it isn't as simple as ``[your] MAX or the system's MAX.'' The ``consequences are undefined'' so CMUCL's behavior is legal, though not necessarily friendly. The restrictions are in place to enable efficient implementation; indeed, CMUCL has very good number-crunching performance. -- ; Matthew Danish <[EMAIL PROTECTED]> ; OpenPGP public key: C24B6010 on keyring.debian.org ; Signed or encrypted mail welcome. ; "There is no dark side of the moon really; matter of fact, it's all dark."
