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

["Davis Herring" <herring@lanl.gov>]

>> I think the documentation for the (new) variable
>> `print-unreadable-function' may be sufficient, but I could add one.
>> I specifically don't want to catch all errors there, because any other
>> error ought to be noticed, not suppressed.
>
> If you bind print-unreadable-function to your own function (instead of
> just
> t), then the code will be easier to understand (and you'll be able to
> use whichever error you feel like, you can even use catch/throw if its
> more convenient).
>
> 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))

(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
readably, and if you can't, fail" is a reasonable thing to expect people
to want; "print this readably but do that instead if you can't" is also
reasonable, so support it we shall.

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?

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.