Re: [Released] Re: 23.0.50; savehist save invalid syntax

[Stefan Monnier]

>> I think this special case of print-unreadable-function being bound to t is
>> rather unnecessary.

> It seemed to me that without that option, each package that used the
> feature would quickly end up writing the same function:

> (defun package-unreadable-function (obj)
>   "Signal that OBJ would be unreadable."
>   (error "%S can't be printed readably" obj))

That's OK.  We can even provide this function in subr.el so they can replace

     (let ((print-unreadable-function t))
with
     (let ((print-unreadable-function 'signal-print-unreadable-error))

[ But I do think that signalling `error' would be wrong: it needs to be more
  precise.  I'm sure you agree with me since that's already what t does
  right now in your code IIUC.  ]

> (This of course loses the specific error symbol.)  I know when I was
> testing it (before it supported t) I immediately felt silly writing a
> function that just redirected to `error'.  It seems to me that "print this

I'd personally write

   (let ((print-unreadable-function (lambda (obj) (signal 'the-error obj))))
or
   (let ((print-unreadable-function (lambda (obj) (throw 'the-error obj))))

and I don't feel silly about it at all.

> Of course, while thinking about this it occurs to me that while (4 5 ...)
> (produced with a finite `print-length' or `print-level') is actually
> readable, it certainly does not read as what was written.  Should this
> trigger the unreadable-handling as well?

I'd prefer that setting print-unreadable-function automatically overrides
any print-length or print-level limit.


        Stefan