I guess you should replace (STREAM) with stream in your definition?

(defmethod PRINT-OBJECT ((x some-class) (s stream) ...)

2011-6-2821:27 Marco Antoniotti д


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
   exceptional situations.
See also:
  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. (identity, not type or class) 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.


Marco Antoniotti

All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
Sbcl-devel mailing list