PRINT-OBJECT for built-in classes

Daniel Kochmański daniel at turtleware.eu
Sat Aug 29 09:50:47 UTC 2015


If I understand correctly 22.2.1.4 states, that current
*print-pprint-dispatch* tables takes precedence over "user-defined
print-object methods because the current pprint dispatch table is
consulted first" – that's if *print-pretty* is T.

If *print-pretty* is nil, then description of PRINT-OBJECT (22.4.11)
states:

"Users may write methods for print-object for their own classes if they
do not wish to inherit an implementation-dependent method."

what might be a hint, that users can't write methods for print-object
for classes which are not "their own".

Regards,
Daniel

Edi Weitz writes:

> The following "works" in three different CL implementations I tried
> while in three others the way complex numbers are printed doesn't
> change.
>
> ? (defmethod print-object ((obj complex) stream)
>      (format stream "#< ~A + ~A * I >"
>                 (realpart obj) (imagpart obj)))
> #<STANDARD-METHOD PRINT-OBJECT (COMPLEX T)>
> ? #c(1 1)
> #< 1 + 1 * I >
>
> My understanding of 22.1.2 of the standard is that each Lisp MUST have
> a PRINT-OBJECT method for complex numbers.  The question then is
> whether I'm allowed to redefine it like above (I think I am) and/or
> whether an implementation is allowed to accept this redefinition
> without a warning but then to ignore it (which, as I said, is what
> happens in three respectable Lisps).
>
> Thanks,
> Edi.
>
> [Note: There's no point in talking me out of this as I don't actually
> want to do it anyway.  It's just an example and I'm only interested in
> what exactly is governed by the standard.  Complex numbers are also
> just an example.  I'm interested in PRINT-OBJECT for built-in classes
> in general.]

-- 
Daniel Kochmański | Poznań, Poland
;; aka jackdaniel

"Be the change that you wish to see in the world." - Mahatma Gandhi



More information about the pro mailing list