bug#25295: Represent eieio objects using object-print in backtraces and edebug

[npostavs@users.sourceforge.net]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Actually, print.c is already setup to be (at least partially) reentrant
>> (for the case `printcharfun` is a function), so maybe making it fully
>> reentrant won't be too hard.  But we'd still want to provide some ad-hoc
>> prin1-like function which continues the print job rather than starting
>> a new nested one; this is needed e.g. if the custom printer wants to
>> print a value V but V has already been printed so it should be printed
>> as a reference #NN# to the previous one.
>
> Looking further at the code, maybe this isn't even needed, since the
> print-number-table can survive calls to print.  But that can get ugly
> when your printer code also want to call `print` for "unrelated"
> purposes (e.g. to print debug messages in a side buffer).
> And I'll stop thinking about interaction with concurrency.

Can we allow overriding printing of primitive types too?  I'm wanting
that for e.g., printing byte code functions in nicer ways.

Looking to Common Lisp for inspiration, there is generic function
print-object[1], and also *print-pprint-dispatch* (an alist of type
specifiers -> printer functions).

Cycle detection state seems to be packed in with STREAM, which is
convenient, although dispatching on STREAM becomes harder.

[1]: http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Body/stagenfun_print-object.html
[2]: http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Body/sec_22-2-1-4.html