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.]