I guess you should replace (STREAM) with stream in your definition?
(defmethod PRINT-OBJECT ((x some-class) (s stream) ...)
在 2011-6-28，21:27， Marco Antoniotti 写道：
> Hi
>
> 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
>
> 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.
>
> Cheers
>
> --
> 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.
> http://p.sf.net/sfu/splunk-d2d-c2_______________________________________________
> Sbcl-devel mailing list
> Sbcl-devel@...
> https://lists.sourceforge.net/lists/listinfo/sbcl-devel

Hi
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
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.
Cheers
--
Marco Antoniotti

Community

Help

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

I agree to receive quotes, newsletters and other information from sourceforge.net and its partners regarding IT services and products. I understand that I can withdraw my consent at any time. Please refer to our Privacy Policy or Contact Us for more details