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

[Eric Abrahamsen <eric@ericabrahamsen.net>]

On 01/03/17 13:21 PM, Stefan Monnier wrote:
>> 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.

If an Elisp-level printer is available to users and developers, I think
we'd have to assume they will throw any old thing in there, including
`format' and `prin1'. Would making `prin1' reentrant solve all of the
resulting problems?

> 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, ...).

That's good! But the previous issue would still need to be resolved.

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

I really wish I could help, but I've never written a line of C, and
in twenty minutes of looking through the sources earlier today, I
couldn't even find where the array types were defined.

It sounds like this would be Step One of solving the problem, but I
would not be able to do it without some substantial hand-holding.