Hi Edi,

That certainly reads to me as though the intent is for print-object to be the decision point (at least in cases where *print-pretty* is false).

However, as far as I understand 11.1.2.1.2:

Except where explicitly allowed, the consequences are undefined if any of the following actions are performed on an external symbol of the COMMON-LISP package:
[...]
19. Defining a method for a standardized generic function which is applicable when all of the arguments are direct instances of standardized classes.

I think the much-feared "consequences are undefined" phrasing there means the implementation is free to act as though the method you defined is in fact defined, but completely ignore it when doing dispatch. (or reformat your hdd or make monkeys fly or whatever).

-Thomas

> From: edi@weitz.de
> Date: Sat, 29 Aug 2015 11:10:15 +0200
> To: pro@common-lisp.net
> Subject: PRINT-OBJECT for built-in classes
>
> 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.]
>