Hacker News Reader

Comment by Blackthorn | Hacker News Reader

I don't know what their own thoughts on it are, but I personally think it's poorly bolted on because it's not actually used by the rest of the spec. There's a massive proliferation of functions acting on data structures, and none of them are generic even if they do the same thing. Poorly bolted on indeed.

View on HN

CL's functionality is an amalgamation of the prior Lisps (thus "Common") which didn't have CLOS. But it was CLOS-ifying a variety of things by the time of the 1994 standard. You just don't see more because the immediate goal was a large degree of compatibility with those prior Lisps. If a second standard had developed a larger portion of the system would probably have been brought under CLOS.

This is a valid criticism. Many of the (possibly) non-generic functions in Common Lisp could be made generic. That they weren't was a bow to existing implementations of Lisp that wouldn't have supported it. The stakeholders engaging in the standardization process didn't want extensions that would be excessively (at the time) costly for them to implement, especially in a way that wouldn't have a large runtime performance impact.

The CL error system is built with CLOS. If you want to customize error handling you'll basically be writing CLOS.

But I agree about general data structures. Some of the sequence functions are generic but not enough of them. I presume this happened because circa 1990 generic dispatch was too slow to handle high speed data traversal. That's no longer true, and many libraries exist to "generify" more of Common Lisp.

...and that's the sort of critique I'm interested in and which should have been given initially.

Reply on news.ycombinator.com