Subject: Re: data hygiene [Re: Why is Scheme not a Lisp?] From: Erik Naggum <email@example.com> Date: Fri, 22 Mar 2002 11:07:44 GMT Newsgroups: comp.lang.lisp Message-ID: <firstname.lastname@example.org> * Duane Rettig | It's interesting, though, that the builting assoc function being | called is named *assq, which historically might imply :test #'eq | instead of the default :test #'eql. But (eql <whatever> <symbol>) is identical to (eq <whatever> <symbol>), so there is no point in using assoc with eql when you know that you search for something for which eql and eq are identical. I note that Allegro CL in all versions I have cared to look at, collapse eql to eq when the type of one of the operands is not of type number or character. | If you have supplied the list to it as a constant alist, it could have | implied that :test #'eq was good enough, since all of the keys are | symbols. I'm surprised, though, that it didn't just unroll the loop | inline. But perhaps it would have if you had compiled with higher | speed/safety ratio. Lispworks generally does not inline even car or cdr as I have seen it, either, while Allegro CL makes them a single instruction. (Good job!) | So it seems like your test isn't checking against the potential speed of | assoc vs getf, but only the current default speed of the implementation, | probably due to optimizations for the Gabriel Benchmarks. It is instructive to see the cost of benchmarks affect program design by almost "misrepresenting" the case for a particular design choice. /// -- In a fight against something, the fight has value, victory has none. In a fight for something, the fight is a loss, victory merely relief.