Lisp is historically less concerned with not exposing implementation details than more modern language traditions. The attitude is: the hacker might need it, throw it in! For example, the ability to compare pointers directly (rather than some expensive traverse-the-whole-datastructure comparison) makes it possible to implement hash-consing, a clever optimization technique.
(It's also no more of an abstraction leak than, say, Python's "is" operator.)
> Lisp is historically less concerned with not exposing implementation details than more modern language traditions.
This is a funny comment, because "refusing to leak abstractions" is the most famous reason for why Lisp never became broadly popular, in one of the most famous stories in all of computing: http://en.wikipedia.org/wiki/Worse_is_better
Worse is better is about much much more than exposing versus not exposing implementation details.
Exposing implementation details is also not quite the same thing as a leaky abstraction (although they can coincide). eqv? can be both, if you regard "cons" as an abstraction of a mathematical pair. OTOH, if you regard cons as allocating a mutable pair object, then it is neither.
Providing a function to trigger garbage collection is exposing an implementation detail, but not leaking abstraction.
It's harder to come up with examples of leaky abstractions that don't in some sense expose implementation details. I'm not sure they exist.
Lisp is historically less concerned with not exposing implementation details than more modern language traditions. The attitude is: the hacker might need it, throw it in! For example, the ability to compare pointers directly (rather than some expensive traverse-the-whole-datastructure comparison) makes it possible to implement hash-consing, a clever optimization technique.
(It's also no more of an abstraction leak than, say, Python's "is" operator.)