Reputation: 786
Somewhere I saw some personal notes from someone who was on the ANSI committee. I thought it was Kent Pitman, but a search of his site doesn't turn up anything. Neither does Google.
I'm interested in the background of the decision not to integrate the condition system with CLOS. CLtL2 speaks of it as a fait accompli, and I'm curious as to why it didn't happen.
Upvotes: 1
Views: 94
Reputation: 9252
The condition system was not integrated with CLOS because there were implementations with existing condition systems which were not CLOS-based (they were, in at least one case, flavors-based), because CLOS did not exist at all until pretty late in the standardisation process. Since a condition system has really deep roots in any implementation, requiring those implementations to rip out a great part of their guts in and replace them with some CLOS-based guts would have placed them – the very implementations which had gone out of their way to make sophisticated condition handling possible in the first place – at a huge disadvantage. Doing that would have been both stupid and would have derailed the standardisation process, since the representatives of those implementations would have been considerably antagonised by a decision like that. So the right decision was made.
It was also unclear at the time that CLOS could be made really performant on stock hardware (perhaps this is still unclear, but stock hardware is now so fast and we all happily live with implementations of other languages which are hugely slower than a good CLOS implementation can be so the problem no longer matters). CL was also considered really big (hard to remember when my fully-fledged hairy CL IDE containing the entire hyperspect and all its own documentation is 2/3 the size of my web browser), so people thought about subset implementations which might not contain CLOS but really needed to contain the condition system.
In particular it is worth looking at the CLHS issue (not part of the spec) CLOS-CONDITIONS-AGAIN, from which comes the following text:
The condition system should not be too tightly integrated into CLOS, for two reasons: Some implementations already have a native condition system that is not based on CLOS, and it should be possible to integrate the native conditions and the ANSI CL conditions. Some people would like to define an ANSI Common Lisp subset that does not contain CLOS but does contain conditions.
The problem areas are the use of DEFCLASS, MAKE-INSTANCE, and DEFMETHOD to define and create conditions, rather than using more abstract macros that conceal the implementation of conditions in terms of CLOS, and exposure of the implementation of condition slots as CLOS slots. If user code was written in a more abstract way, it could run in a subset language that did not contain CLOS.
This is not normative text but you can see what people were thinking.
Upvotes: 1