From: Marco A. <ma...@cs...> - 2011-07-08 18:43:51
|
On Jun 29, 2011, at 15:31 , Christophe Rhodes wrote: > Marco Antoniotti <ma...@cs...> writes: > >> Always in the specific case, since there is code in SBCL to test for >> the second argument to PRINT-OBJECT, such code should at a minimum >> test that the second argument is "fine". STREAM is fine. Testing for >> abuses on the identity of the object (i.e., tests like (eq s >> *standard-output*) ) are too much to test for, but it is those those >> that are the target of the caveat in the spec. Not the STREAM >> declaration. > > It is not "fine" in any circumstances, but for reasons that are perhaps > not directly spec-related. Your specialization might be OK from the > point of view of the spec -- I do not want to debate that -- but for a > change there is a non-spec reason for warning the user, regarding the > precomputation of methods in exceptional situations. Specifically, > while CLOS is in general a lazy system, in that it computes effective > methods on demand, there is one area where that doesn't work so well, > and that is the reporting of errors ("exceptional situations") to the > user: if the system is nearly out of resources, it is bad if the system > has to use resources to compile effective methods in order to print a > message to the user. > > So PRINT-OBJECT is special-cased. But that special-casing only works > when all the methods have only one dispatch argument -- i.e. when the > second is always specialized to T, and hence doesn't figure in > applicability calculations. If it does, then the special-casing fails, > and you're on your own: the eager computation of relevant effective > methods is no longer possible. (Well, of course it's possible with even > more heroic effort; I look forward to a world where such heroic effort > can be had at the beck-and-call of an angry e-mail) I see your point. But I still believe that - at least in this case - SBCL should be more lenient in issuing a style warning. >> In other words, I really believe that SBCL should be much more lenient >> in many cases where the spec interpretation is not so clear cut. > > Why do you actually want to specialize on STREAM? The standardized > methods don't, after all. All it can do is make your printing slower > and the overall system more fragile. It is not the case that triggered the style-warning but I know I have used in the past (code that depends on LW CAPI, so I did not compile it on SBCL) PRINT-OBJECT methods that specialized on FILE-STREAM to distinguish them from other kind of streams (most notably on LW COMM:SOCKET-STREAM). Cheers -- Marco |