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

[Stefan Monnier]

> I guess this would require going into print.c and adding another branch
> under the Lisp_Vectorlike case statement of object_print.

That's right.

> Is this sort of C code allowed to call back up to the lisp object-print
> function? This is where I get lost...

The Elisp-level printer and the interaction between the C code and
the Elisp ill have to be worked out, indeed.

E.g. you probably won't want to have Elisp-level printer to just call
`format` or `prin1` since that does more than just print (it sets up
a printing destination, initializes the cycle-detection table, then
checks for cycles, ...).

This said, making `prin1` reentrant will probably be helpful.

One more thing: there have already been other desires/needs to tweak the
printing from Elisp.  E.g. to special case printing of objects that
can't be printed readably (e.g. buffers, markers, overlays, ...).


        Stefan


PS: One more thing; currently cl-structs and EIEIO objects are
represented as plain normal arrays (and they mostly use the same
representation now, where the first field contains a symbol whose
function cell contains `:quick-object-witness-check` and whose value
cell is the actual class object, which is a cl-struct that inherits
from cl--class).

It'd be good to instead provide a new kind of array just for
objects/records/structs (just like we have the `compiled-function` type
which is basically a normal array just with a different tag).
This would let us get rid of the "symbol with
a :quick-object-witness-check" indirection and would make it easier for
the print.c code to delegate to the Elisp-level printer since it
wouldn't need to know about the hackish representation choices of EIEIO
and cl-structs.