again I stumbled upon this very useful, yet very, very annoying feature of SBCL.
I often write my PRINT-OBJECT methods as
(defmethod PRINT-OBJECT ((x some-class) (s (STREAM)) ...)
SBCL gives me the following STYLE-WARNING
Specializing on the second argument to PRINT-OBJECT has unportable
effects, and also interferes with precomputation of print functions for
The ANSI Standard, Function PRINT-OBJECT
In the specific case, while it is true that the spec states that methods should therefore not depend on the identity of this stream
, not type
) my definition is perfectly legitimate and should *not* raise a STYLE-WARNING. On top of that the warning issued extrapolates from the meaning of the spec (AFAIU, you cannot say that it has "unportable effects") and it mixes in efficiency concerns which, if extrapolated themselves, would bar us from using multiple dispatch tout-court.
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.
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.