`unreadablep'

`unreadablep'

[Lars Ingebrigtsen]

Do we have any primitive that can be used to check whether an object is
printable or not?  Code like this (from savehist.el) makes me believe
"not":

		;; Print elements of VALUE one by one, carefully.
		(dolist (elt value)
		  (let ((start (point)))
		    (insert " ")
		    ;; Try to print and then to read an element.
		    (condition-case nil
			(progn
			  (prin1 elt (current-buffer))
			  (save-excursion
			    (goto-char start)
			    (read (current-buffer))))
		      (error
		       ;; If writing or reading gave an error, comment it out.
		       (goto-char start)
		       (insert "\n")
		       (while (not (eobp))
			 (insert ";;; ")
			 (forward-line 1))
		       (insert "\n")))
		    (goto-char (point-max))))

It would be nice to have such a function (i.e., that says whether it can
be read back after printing it).  The problem is, of course, complex
structures that require recursing (and then checking for loops), etc, so
you basically have to implement it the way printing is done if you want
it to be fast, I think?

Does anybody have any thoughts on this issue?

I wonder whether this could be efficiently implemented by, say, having
some kind of special value for PRINTCHARFUN for prin1, but I haven't
looked at the code yet.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: `unreadablep'

[Po Lu]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> It would be nice to have such a function (i.e., that says whether it can
> be read back after printing it).  The problem is, of course, complex
> structures that require recursing (and then checking for loops), etc, so
> you basically have to implement it the way printing is done if you want
> it to be fast, I think?

Yes, it would be very convenient indeed.

I think the best solution would be to allow `prin1' to optionally return
whether or not any unreadable objects were printed, instead of the
object itself.

Re: `unreadablep'

[Ihor Radchenko]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Do we have any primitive that can be used to check whether an object is
> printable or not?  Code like this (from savehist.el) makes me believe
> "not":
> ...
> Does anybody have any thoughts on this issue?

I can see a use of adding extra argument to prin1. If the argument is
set, prin1 errors when attempting to print unreadable object or
alternatively prints nil (or other symbol) instead of the unreadable
object.

Best,
Ihor

Re: `unreadablep'

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

> Yes, it would be very convenient indeed.
>
> I think the best solution would be to allow `prin1' to optionally return
> whether or not any unreadable objects were printed, instead of the
> object itself.

I was thinking that for efficiency (and ease of usage), nothing would be
printed.  That is, something like

(defun unreadablep (object)
  (condition-case nil
      (prin1 object 'error-on-unprintable)
    (:success t)
    (unprintable-error nil)))

and then prin1 would signal an error if it encounters an unprintable
object in the structure, but otherwise print nothing.

But I still haven't actually looked at the prin1 code, so I'm not sure
whether that would be messy or not.  😀 The advantage of using the prin1
code to do the checking (instead of implementing a separate function to
traverse the data itself) is that we'd be pretty sure that there aren't
any glitches between the prin1 implementation and the checker
implementation...

But having `prin1' return whether it printed something unreadable also
sounds attractive.  I guess it depends on the use case.  If you're
saying

(if (unprintable o)
    (insert ";; " (prin1 o (current-buffer)))
  (prin1 o (current-buffer)))

then you're traversing the data twice, which isn't efficient, so
inserting it first and then checking would be nice.  But if you're doing

(when (unprintable o)
  (error "Nope"))

then it'd be inconvenient for it to be printing anything.

And what about `prin1-to-string'?  It has to return the string...  Hm...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: `unreadablep'

[Po Lu]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> But having `prin1' return whether it printed something unreadable also
> sounds attractive.  I guess it depends on the use case.  If you're
> saying
>
> (if (unprintable o)
>     (insert ";; " (prin1 o (current-buffer)))
>   (prin1 o (current-buffer)))
>
> then you're traversing the data twice, which isn't efficient, so
> inserting it first and then checking would be nice.

Yes, my thoughts exactly.

Re: `unreadablep'

[Po Lu]

Ihor Radchenko <yantar92@gmail.com> writes:

> I can see a use of adding extra argument to prin1. If the argument is
> set, prin1 errors when attempting to print unreadable object or
> alternatively prints nil (or other symbol) instead of the unreadable
> object.

Why an extra argument, and not a variable, say,
`throw-printing-unreadably'?  There are many callers of prin1 that could
benefit from this.

Re: `unreadablep'

[Ihor Radchenko]

Po Lu <luangruo@yahoo.com> writes:

> Ihor Radchenko <yantar92@gmail.com> writes:
>
>> I can see a use of adding extra argument to prin1. If the argument is
>> set, prin1 errors when attempting to print unreadable object or
>> alternatively prints nil (or other symbol) instead of the unreadable
>> object.
>
> Why an extra argument, and not a variable, say,
> `throw-printing-unreadably'?  There are many callers of prin1 that could
> benefit from this.

Variable would indeed be better. Using variable is more consistent with
the existing behaviour. prin1 can already be controlled by variables
like print-level, print-circle, etc

Though the name should probably start with print-. Maybe something like
print-unreadable (t by default, nil will make prin1 throw an error, and
'replace to print the value of print-unreadable-as instead of unreadable
object).

Yet another option may be not printing anything when print-unreadable is
t and throwing an error when print-unreadable is 'error, but I am not
sure if that much customisation is too much.

Best,
Ihor

Re: `unreadablep'

[Ihor Radchenko]

Ihor Radchenko <yantar92@gmail.com> writes:

> Yet another option may be not printing anything when print-unreadable is
> t and throwing an error when print-unreadable is 'error, but I am not
> sure if that much customisation is too much.
* t -> nil

Re: `unreadablep'

[Po Lu]

Ihor Radchenko <yantar92@gmail.com> writes:

> Variable would indeed be better. Using variable is more consistent with
> the existing behaviour. prin1 can already be controlled by variables
> like print-level, print-circle, etc
>
> Though the name should probably start with print-. Maybe something like
> print-unreadable (t by default, nil will make prin1 throw an error, and
> 'replace to print the value of print-unreadable-as instead of unreadable
> object).
>
> Yet another option may be not printing anything when print-unreadable is
> t and throwing an error when print-unreadable is 'error, but I am not
> sure if that much customisation is too much.

How about `print-throw-if-printing-unreadably'?

Re: `unreadablep'

[Ihor Radchenko]

Po Lu <luangruo@yahoo.com> writes:

>> Variable would indeed be better. Using variable is more consistent with
>> the existing behaviour. prin1 can already be controlled by variables
>> like print-level, print-circle, etc
>>
>> Though the name should probably start with print-. Maybe something like
>> print-unreadable (t by default, nil will make prin1 throw an error, and
>> 'replace to print the value of print-unreadable-as instead of unreadable
>> object).
> ...
> How about `print-throw-if-printing-unreadably'?

I don't have strong opinion about print-unreadable vs.
print-throw-if-printing-unreadably, except that the latter feels too
long (which is not a big deal).

I am more interested in the ability to print nil (or something else)
instead of unreadable objects. My motivations is org-element-cache where
we cannot currently store buffer objects because they cannot be restored
from printed cache while not increasing the write time significantly (it
is bad enough as it is).

Best,
Ihor

Re: `unreadablep'

[Po Lu]

Ihor Radchenko <yantar92@gmail.com> writes:

> I don't have strong opinion about print-unreadable vs.
> print-throw-if-printing-unreadably, except that the latter feels too
> long (which is not a big deal).

> I am more interested in the ability to print nil (or something else)
> instead of unreadable objects. My motivations is org-element-cache where
> we cannot currently store buffer objects because they cannot be restored
> from printed cache while not increasing the write time significantly (it
> is bad enough as it is).

Maybe we could have a `print-unreadable-function' that accepts
`printcharfun' as an argument.  That would be very nice indeed.

Re: `unreadablep'

[Ihor Radchenko]

Po Lu <luangruo@yahoo.com> writes:
>> I am more interested in the ability to print nil (or something else)
>> instead of unreadable objects. My motivations is org-element-cache where
>> we cannot currently store buffer objects because they cannot be restored
>> from printed cache while not increasing the write time significantly (it
>> is bad enough as it is).
>
> Maybe we could have a `print-unreadable-function' that accepts
> `printcharfun' as an argument.  That would be very nice indeed.

Do you imply that `print-unreadable-function' should return the new
value to be printed? If so, it is indeed more flexible. Passing the
unreadable value to the function would also be useful (e.g. we can print
buffer file name instead of buffer object).

Best,
Ihor

Re: `unreadablep'

[Po Lu]

Ihor Radchenko <yantar92@gmail.com> writes:

>> Maybe we could have a `print-unreadable-function' that accepts
>> `printcharfun' as an argument.  That would be very nice indeed.

> Do you imply that `print-unreadable-function' should return the new
> value to be printed? If so, it is indeed more flexible. Passing the
> unreadable value to the function would also be useful (e.g. we can print
> buffer file name instead of buffer object).

It would accept a function that is called to print characters, like the
`printcharfun' argument to prin1.

Re: `unreadablep'

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

>> But having `prin1' return whether it printed something unreadable also
>> sounds attractive.  I guess it depends on the use case.  If you're
>> saying
>>
>> (if (unprintable o)
>>     (insert ";; " (prin1 o (current-buffer)))
>>   (prin1 o (current-buffer)))
>>
>> then you're traversing the data twice, which isn't efficient, so
>> inserting it first and then checking would be nice.
>
> Yes, my thoughts exactly.

And we could implement `readablep' (probably better without "un") as

(defun readablep (object)
  (prin1 object #'ignore 'return-readablep))

and not actually print anything (for the cases where it's more
convenient to call a predicate).

There's perhaps a slight performance issue -- if the unreadable object
is the first in a long list, we could have exited a lot sooner, but I'm
not sure that's really much of an issue in practice.  If it is, we could
perhaps change PRINTCHARFUN to take two arguments in this case, where
the second is EVERYTHING-IS-READABLE-SO-FAR, and then PRINTCHARFUN could
throw an error if it wishes...

Or, as has been suggested, add a new print-* variable to have the same
effect -- it'd fit in with the current design (of having a bunch of
print-* variables).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: `unreadablep'

[Po Lu]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> There's perhaps a slight performance issue -- if the unreadable object
> is the first in a long list, we could have exited a lot sooner, but I'm
> not sure that's really much of an issue in practice.  If it is, we could
> perhaps change PRINTCHARFUN to take two arguments in this case, where
> the second is EVERYTHING-IS-READABLE-SO-FAR, and then PRINTCHARFUN could
> throw an error if it wishes...
>
> Or, as has been suggested, add a new print-* variable to have the same
> effect -- it'd fit in with the current design (of having a bunch of
> print-* variables).

Yes, now I think the `print-unreadable-function' solution would be best;
we could just cause a non-local exit from within that function.

Re: `unreadablep'

[Ihor Radchenko]

Po Lu <luangruo@yahoo.com> writes:

>> Do you imply that `print-unreadable-function' should return the new
>> value to be printed? If so, it is indeed more flexible. Passing the
>> unreadable value to the function would also be useful (e.g. we can print
>> buffer file name instead of buffer object).
>
> It would accept a function that is called to print characters, like the
> `printcharfun' argument to prin1.

I was confused by the name. `printcharfun' in prin1 can be a buffer, a
marker, etc. Doing the same for the `print-unreadable-function' makes it
tricky to implement. How does `print-unreadable-function' print into a
buffer or marker? It would be cumbersome to consider all such cases if
the user simply wants to print nil in place of unreadable objects.

If the `printcharfun' passed to `print-unreadable-function' is strictly
an ordinary function that does actual printing, I can see a problem with
circular objects. Consider something like
(#1=a #<unreadable> #2=b #1 #1 #2).
If the main print loop is not aware of what was printed by
`print-unreadable-function' and the function tries to print reference to
b, we may get incorrect object:
(#1=a b #2=b #1 #1 #2)
The object printed instead of unreadable value will break circular
structure.

Of course, the described problem will depend on the details of
implementation.

Best,
Ihor

Re: `unreadablep'

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

> Yes, now I think the `print-unreadable-function' solution would be best;
> we could just cause a non-local exit from within that function.

The PRINTCHARFUN just gets a single character at a time, doesn't it?  So
it's not at the correct level to determine whether something is
unreadable or not...

I wonder whether two new simple read-* variables would cover all the use
cases (without having to go through prin1 twice ever).

1) When you want to signal an error, but use the representation
otherwise:

(use-thing
  (let ((print-error-on-unreadable t))
    (condition-case nil
       (prin1-to-string object)
      (unreadable-error (user-error "can't use this")))))

This would signal an error as soon as prin1 sees something unprintable,
so it'd be fast.

2) When you always want to insert it, but tweak it (a la savehist):

(let ((print-return-readable t)
      (start (point)))
  (unless (prin1 object (current-buffer))
    (goto-char start)
    (insert ";; ")))

I think that should cover the use cases?

Perhaps this is over engineering, but it would be nice to implement
things like this efficiently.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: `unreadablep'

[Po Lu]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Po Lu <luangruo@yahoo.com> writes:
>
>> Yes, now I think the `print-unreadable-function' solution would be best;
>> we could just cause a non-local exit from within that function.

> The PRINTCHARFUN just gets a single character at a time, doesn't it?  So
> it's not at the correct level to determine whether something is
> unreadable or not...

The idea is that `print-unreadable-function' is called _with_ the object
and the printcharfun (and possibly some prin1 state, but I haven't
thought of the details yet) when prin1 encounters an unreadable object.

So if you want to error something when trying to print an unreadable
object, you can just set that to a function that throws.

Re: `unreadablep'

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

> The idea is that `print-unreadable-function' is called _with_ the object
> and the printcharfun (and possibly some prin1 state, but I haven't
> thought of the details yet) when prin1 encounters an unreadable object.
>
> So if you want to error something when trying to print an unreadable
> object, you can just set that to a function that throws.

Right...

Skimming print_object and friends, it seems like the vast majority of
the unprintable objects are in print_vectorlike, so I guess such a
change could be made (pretty much?) locally to that function...

So I think doing it that way should be pretty easy to implement, and
it's certainly general enough to be used in both of the cases I
sketched.  But the logic would have to be such that if
`print-unreadable-function' returns some special value, then printing
continues as normally (to implement the "just tell me if what was
printed is readable" case).

And calling out to Lisp in this case may be slower than the other
solution sketched.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: `unreadablep'

[Ihor Radchenko]

Po Lu <luangruo@yahoo.com> writes:

> The idea is that `print-unreadable-function' is called _with_ the object
> and the printcharfun (and possibly some prin1 state, but I haven't
> thought of the details yet) when prin1 encounters an unreadable object.

What about just calling with the object and then proceeding as usual
inside prin1, but using the return value of print-unreadable-function in
place of the old unreadable value?

Best,
Ihor

Re: `unreadablep'

[Po Lu]

Ihor Radchenko <yantar92@gmail.com> writes:

> What about just calling with the object and then proceeding as usual
> inside prin1, but using the return value of print-unreadable-function in
> place of the old unreadable value?

It wouldn't allow to differentiate unreadable values printed specially
from readable ones later at read time, but I see no harm in providing
that feature as well.

Re: `unreadablep'

[Po Lu]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Right...
>
> Skimming print_object and friends, it seems like the vast majority of
> the unprintable objects are in print_vectorlike, so I guess such a
> change could be made (pretty much?) locally to that function...

Don't we also have Lisp_Misc and friends?  (But I'm not sure Lisp_Misc
is ever supposed to be printed at all, and I don't see Lisp_Misc
anywhere, so perhaps my recollection is faulty.)

> So I think doing it that way should be pretty easy to implement, and
> it's certainly general enough to be used in both of the cases I
> sketched.  But the logic would have to be such that if
> `print-unreadable-function' returns some special value, then printing
> continues as normally (to implement the "just tell me if what was
> printed is readable" case).

We could have it return nil in that case.

> And calling out to Lisp in this case may be slower than the other
> solution sketched.

Unreadable objects are in general rare in printed objects, and a funcall
followed by a test against nil will not add any significant overhead to
prin1 either, so I wouldn't be worried about that.

Let's not optimize prematurely, especially with something like prin1 :)

Re: `unreadablep'

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

> Unreadable objects are in general rare in printed objects, and a funcall
> followed by a test against nil will not add any significant overhead to
> prin1 either, so I wouldn't be worried about that.

Yeah, that's true.

> Let's not optimize prematurely, especially with something like prin1 :)

Well, we do want prin1 to be fast.  😀

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: `unreadablep'

[Po Lu]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Well, we do want prin1 to be fast.  😀

It isn't the fastest as it is, but that's besides the point: avoiding a
completely optional call into Lisp because it "might be slow" is a
textbook case of putting the horse before the dog, so to speak.

Re: `unreadablep'

[Po Lu]

Po Lu <luangruo@yahoo.com> writes:

> It isn't the fastest as it is, but that's besides the point: avoiding a
> completely optional call into Lisp because it "might be slow" is a
> textbook case of putting the horse before the dog, so to speak.
                                                ^^^

Sorry, I meant to say "cart" here.  :P

Re: `unreadablep'

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

> It isn't the fastest as it is, but that's besides the point: avoiding a
> completely optional call into Lisp because it "might be slow" is a
> textbook case of putting the horse before the dog, so to speak.

Well, we're discussing several different ways to implement basically the
same functionality.  If one's slower than the other, that's an issue.

But I think your idea is good -- a way to customise the printing of
unprintable objects could be useful in general, and not just to
implement `readablep'.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: `unreadablep'

[Stefan Monnier]

> Do we have any primitive that can be used to check whether an object is
> printable or not?  Code like this (from savehist.el) makes me believe
> "not":

IIRC we discussed such a feature but it never got installed.

My memory suggests the plan was to add something like
a `print-unreadable-function` that gets called with the offending
object.  It could then print it any which way it wants, or signal an
error or ...


        Stefan

Re: `unreadablep'

[Steingold]

> * Lars Ingebrigtsen <ynefv@tahf.bet> [2021-12-15 08:49:58 +0100]:
>
> Do we have any primitive that can be used to check whether an object is
> printable or not?  Code like this (from savehist.el) makes me believe
> "not":
>
> 		;; Print elements of VALUE one by one, carefully.
> 		(dolist (elt value)
> 		  (let ((start (point)))
> 		    (insert " ")
> 		    ;; Try to print and then to read an element.
> 		    (condition-case nil
> 			(progn
> 			  (prin1 elt (current-buffer))
> 			  (save-excursion
> 			    (goto-char start)
> 			    (read (current-buffer))))
> 		      (error
> 		       ;; If writing or reading gave an error, comment it out.
> 		       (goto-char start)
> 		       (insert "\n")
> 		       (while (not (eobp))
> 			 (insert ";;; ")
> 			 (forward-line 1))
> 		       (insert "\n")))
> 		    (goto-char (point-max))))
>
> It would be nice to have such a function (i.e., that says whether it can
> be read back after printing it).  The problem is, of course, complex
> structures that require recursing (and then checking for loops), etc, so
> you basically have to implement it the way printing is done if you want
> it to be fast, I think?
>
> Does anybody have any thoughts on this issue?

I think the above code is _perfect_.
Why would one want to know in advance if the object is printable readably?
Only to decide how to print it, right?
Then the optimal approach is to _try_ to print readably and then take an
alternative/remedial action on failure.
This will usually save a structure traversal.

> I wonder whether this could be efficiently implemented by, say, having
> some kind of special value for PRINTCHARFUN for prin1, but I haven't
> looked at the code yet.

Yeah, we could create a "/dev/null"-type object and pass it to prin1.
However, this would still make the above approach better in most cases.

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.2022
http://childpsy.net http://calmchildstories.com http://steingoldpsychology.com
https://honestreporting.com https://iris.org.il https://ffii.org
DRM "access management" == prison "freedom management".

Re: `unreadablep'

[Qiantan Hong]

> On Dec 15, 2021, at 7:32 AM, Steingold <sds@gnu.org> wrote:
> 
>> * Lars Ingebrigtsen <ynefv@tahf.bet> [2021-12-15 08:49:58 +0100]:
>> 
>> Do we have any primitive that can be used to check whether an object is
>> printable or not?  Code like this (from savehist.el) makes me believe
>> "not":
>> 
>> 		;; Print elements of VALUE one by one, carefully.
>> 		(dolist (elt value)
>> 		  (let ((start (point)))
>> 		    (insert " ")
>> 		    ;; Try to print and then to read an element.
>> 		    (condition-case nil
>> 			(progn
>> 			  (prin1 elt (current-buffer))
>> 			  (save-excursion
>> 			    (goto-char start)
>> 			    (read (current-buffer))))
>> 		      (error
>> 		       ;; If writing or reading gave an error, comment it out.
>> 		       (goto-char start)
>> 		       (insert "\n")
>> 		       (while (not (eobp))
>> 			 (insert ";;; ")
>> 			 (forward-line 1))
>> 		       (insert "\n")))
>> 		    (goto-char (point-max))))
>> 
>> It would be nice to have such a function (i.e., that says whether it can
>> be read back after printing it).  The problem is, of course, complex
>> structures that require recursing (and then checking for loops), etc, so
>> you basically have to implement it the way printing is done if you want
>> it to be fast, I think?
>> 
>> Does anybody have any thoughts on this issue?
> 
> I think the above code is _perfect_.
> Why would one want to know in advance if the object is printable readably?
> Only to decide how to print it, right?
> Then the optimal approach is to _try_ to print readably and then take an
> alternative/remedial action on failure.
> This will usually save a structure traversal.
print already traverse it once, read traverse it twice.
If print support it natively we save in the best case one
half of the work.

Re: `unreadablep'

[Steingold]

> * Lars Ingebrigtsen <ynefv@tahf.bet> [2021-12-15 08:49:58 +0100]:
>
> Do we have any primitive that can be used to check whether an object is
> printable or not?  Code like this (from savehist.el) makes me believe
> "not":
>
> 		;; Print elements of VALUE one by one, carefully.
> 		(dolist (elt value)
> 		  (let ((start (point)))
> 		    (insert " ")
> 		    ;; Try to print and then to read an element.
> 		    (condition-case nil
> 			(progn
> 			  (prin1 elt (current-buffer))
> 			  (save-excursion
> 			    (goto-char start)
> 			    (read (current-buffer))))
> 		      (error
> 		       ;; If writing or reading gave an error, comment it out.
> 		       (goto-char start)
> 		       (insert "\n")
> 		       (while (not (eobp))
> 			 (insert ";;; ")
> 			 (forward-line 1))
> 		       (insert "\n")))
> 		    (goto-char (point-max))))

I think the above code would have been perfect, if

1. prin1 were replaced with something like `(write ... :readably t)`
   (http://clhs.lisp.se/Body/f_wr_pr.htm), _and_

2. there were no `read` after `prin1`

(BTW, the return value of `read` is ignored, to be "honest", it should
be compared to `elt` using `equal`)

> It would be nice to have such a function (i.e., that says whether it can
> be read back after printing it).  The problem is, of course, complex
> structures that require recursing (and then checking for loops), etc, so
> you basically have to implement it the way printing is done if you want
> it to be fast, I think?
>
> Does anybody have any thoughts on this issue?

Why would one want to know in advance if the object is printable readably?
Only to decide how to print it, right?
Then the optimal approach is to _try_ to print readably and then take an
alternative/remedial action on failure.
This will usually save a structure traversal.

Thus I would advocate for a `print-readably' variable that would emulate
the CL behavior <http://clhs.lisp.se/Body/v_pr_rda.htm>.

> I wonder whether this could be efficiently implemented by, say, having
> some kind of special value for PRINTCHARFUN for prin1, but I haven't
> looked at the code yet.

Yeah, we could create a "/dev/null"-type object and pass it to prin1.
However, this would still make the above approach better in most cases.

(My original reply was, apparently, sent just to Lars, and was incorrect)

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.2022
http://childpsy.net http://calmchildstories.com http://steingoldpsychology.com
https://www.memritv.org https://www.dhimmitude.org http://think-israel.org
When you are arguing with an idiot, your opponent is doing the same.

RE: [External] : Re: `unreadablep'

[Drew Adams]

> I was thinking that for efficiency (and ease of usage),
> nothing would be printed.  That is, something like
> 
> (defun unreadablep (object)
>   (condition-case nil
>       (prin1 object 'error-on-unprintable)
>     (:success t)
>     (unprintable-error nil)))

FWIW, I've always used this.

(defun bmkp-readable-p (value)
  "Return non-nil if VALUE is Lisp-readable if printed using `prin1'."
  (cond ((numberp value))
        ((symbolp value))
        ((and (stringp value)           ; String with no text properties.
              (if (fboundp 'equal-including-properties) ; Emacs 22+.
                  (equal-including-properties value (substring-no-properties value))
                (and (null (text-properties-at 0 value))
                     (= 0 (next-property-change 0 value))))))
        (t (with-temp-buffer
             (condition-case nil
                 (let ((print-readably  t)
                       (print-level     nil)
                       (print-circle    bmkp-propertize-bookmark-names-flag)
                       (print-gensym    bmkp-propertize-bookmark-names-flag))
                   (prin1 value (current-buffer))
                   (read (point-min-marker))
                   t)
               (error nil))))))         ; Could not print and read back.

Yes, it tries to print and then read back.
It would be great to have something better.

[And yes, "readable" is better than "unreadable",
as most tests will be (when (readablep X) ...).]

Re: `unreadablep'

[Philipp Stephani]

Am Mi., 15. Dez. 2021 um 09:16 Uhr schrieb Lars Ingebrigtsen <larsi@gnus.org>:
> It would be nice to have such a function (i.e., that says whether it can
> be read back after printing it).

Yes, this would be useful in many places where we need to serialize
Lisp objects (e.g. for the sandbox stuff).

>  The problem is, of course, complex
> structures that require recursing (and then checking for loops), etc, so
> you basically have to implement it the way printing is done if you want
> it to be fast, I think?

It's a DFS of a DAG, not quite rocket science. The difficulty is
rather in getting the details right (e.g. you can't allow symbols
interned in a non-default obarray because you wouldn't get the same
symbol back).

> I wonder whether this could be efficiently implemented by, say, having
> some kind of special value for PRINTCHARFUN for prin1, but I haven't
> looked at the code yet.

Maybe just introduce another C function `prin1-if-readable' or so that
errors out (with a specific error symbol so that callers can catch it)
if the object can't be printed in a readable way. That should also
bind the print variables correctly (e.g. bind print-level to nil) so
ensure that the result really represents an equivalent List object.
The new function would likely reuse the existing `print' machinery,
with the `escapeflag' parameter turned into a generic `flags' enum.
I guess it would make sense to also forbid some "exotic" objects
(circular objects, uninterned symbols) that rarely make sense to
serialize.

Re: `unreadablep'

[Lars Ingebrigtsen]

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

> My memory suggests the plan was to add something like
> a `print-unreadable-function` that gets called with the offending
> object.  It could then print it any which way it wants, or signal an
> error or ...

Then it seems like most everybody's who's weighed in is in favour of
that solution, but perhaps Eli has an opinion.  Eli?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: `unreadablep'

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org, Po Lu <luangruo@yahoo.com>, Eli Zaretskii
>  <eliz@gnu.org>
> Date: Thu, 16 Dec 2021 06:48:49 +0100
> 
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
> > My memory suggests the plan was to add something like
> > a `print-unreadable-function` that gets called with the offending
> > object.  It could then print it any which way it wants, or signal an
> > error or ...
> 
> Then it seems like most everybody's who's weighed in is in favour of
> that solution, but perhaps Eli has an opinion.  Eli?

It's fine by me, thanks.

Re: `unreadablep'

[Qiantan Hong]

>> My memory suggests the plan was to add something like
>> a `print-unreadable-function` that gets called with the offending
>> object.  It could then print it any which way it wants, or signal an
>> error or ...
> 
> Then it seems like most everybody's who's weighed in is in favour of
> that solution
Is it possible to also provide a companion function for read?
Namely, read-unreadable-function, that gets called when
encountering #<.

Re: `unreadablep'

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> Then it seems like most everybody's who's weighed in is in favour of
>> that solution, but perhaps Eli has an opinion.  Eli?
>
> It's fine by me, thanks.

OK; I'll open a bug report so track the work.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: `unreadablep'

[Lars Ingebrigtsen]

Qiantan Hong <qhong@mit.edu> writes:

> Is it possible to also provide a companion function for read?
> Namely, read-unreadable-function, that gets called when
> encountering #<.

Hm...  I almost thought we had that somewhere, but perhaps not?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no