To be honest, I think folks imagine the wrong things when looking at CLOS. They think it's Lisp foray into statically-typed OOP like C++. But it isn't. Lisp stays dynamically typed. The task you're proposing is nonsensical "in CLOS". It's just not Lisp-y :-)
I think this discussion has gotten fairly far from the main point by now. There's no real use trying to twist one language to achieve every feature of another.
This isn't a matter of this language or that language. Are you going to deliberately use a less efficient algorithm or a more convoluted design, just to please your language of choice? No idea about you, but, when a programming language doesn't let me express what I want, I don't force myself to want something else - I switch languages.
> To be honest, I think folks imagine the wrong things when looking at CLOS. They think it's Lisp foray into statically-typed OOP like C++. But it isn't. Lisp stays dynamically typed.
I never said CLOS is Lisp's take on static typing. I'm just offering an example of a use case for which CLOS isn't as powerful as other existing alternatives.
> The task you're proposing is nonsensical "in CLOS". It's just not Lisp-y :-)
This doesn't make sense. What I'm asking for is fundamental if you want generic programming to work: generic algorithms must be specializable for performance reasons, while still providing a uniform interface to users.
That would be fine with me, but...
> I don't think CLOS supports this use case, but the rest of Lisp certainly does.
How exactly? Manually branching on the type of an object is ugly and non-extensible, and thus the antithesis of good modular design. Or are you proposing creating a whole new object system, in parallel to CLOS, but which supports this one additional feature? My copy of AMOP suggests that the design of CLOS is intended to avoid this kind of scenario:
“The metaobject protocol approach (...) is based on the idea that one can and should "open languages up," allowing users to adjust the design and implementation to suit their particular needs.” (p. 1)
“Rather than supplying the user with a fixed, single point in the space of all language designs and implementations, we would instead support a region of possible designs within that overall space. (...) Users are free to move to whatever point in that region best matches their particular requirements.” (p. 5-6)
...but you can do it in Clojure, right? (honestly I don't know anything about Clojure). I guess some diehard old-school lispers don't consider Clojure lispy. Is there another way it isn't lispy? Certainly someone could come up with generic functions that dispatch on types, and then the problem would be trivial. The "filtered-functions" mentioned above, seems to have the machinery required.
If it's static like possible in some ways in C++, then Common Lisp won't support it, because it generally lacks a full featured compile-time static type system.
> could come up with generic functions that dispatch on types
But how would you know that a vector only contains ints between 100 and 200 or characters from A to Z? Either a) we can express that in the type system for compile time, we carry complex type annotations for runtime objects, or we do a check at runtime.
CLOS: Dynamic dispatch is possible, given extensions like predicate dispatch.
ftp://publications.ai.mit.edu/ai-publications/2001/AITR-2001-006.pdf