[armedbear-devel] The purpose of the writeToString() method (before we can rename it to printObject() or anything else)
Today I thought I'd address ticket #160. That ticket is about %OUTPUT-OBJECT (a primitive) checking the string returned for the non-readable "#<" marker. The problem is that it'll raise a PRINT-NOT-READABLE error on any output containing that marker, even if it's part the serialized presentation which *is* readable, like the uninterned symbol #:|#<32|. The solution I'm aiming at is to make every writeToString() method raise an error when it can't return a readable representation when a readable representation is requested. In preparation of this change I'm investigating the uses of writeToString(). There are 213 occurrences of the string ".writeToString()", many of which are related to the creation of error messages. It'd be particularly impractical to generate errors while creating an error message. On the other hand, there are also uses, such as the one by %OUTPUT-OBJECT which typically *should* obey those values and generate the PRINT-NOT-READABLE error accordingly. So, simply renaming writeToString() to printObject() is still an option. We can even make the printObject() functions check whether they are allowed to return unreadable output. However, it seems to me we additionally need a function which returns - optionally unreadable - output without generating errors. I'm thinking of a function which resets the variables to the values WITH-STANDARD-IO-SYNTAX except that it binds *PRINT-READABLY* to NIL. Maybe that function should be called printUnreadableObject() or something alike. I've also thought about renaming writeToString() to printObjectInternal() and creating a new printObject(boolean requireReadable) which does the required work if the argument is true. Hmm. I hope the above is something people want to comment on. At least I've tried to describe my findings so far. I'm interested to know what others think. Bye, Erik.
Commenting on myself here: On Sun, Jul 17, 2011 at 8:40 PM, Erik Huelsmann <ehuels@gmail.com> wrote:
Today I thought I'd address ticket #160. That ticket is about %OUTPUT-OBJECT (a primitive) checking the string returned for the non-readable "#<" marker. The problem is that it'll raise a PRINT-NOT-READABLE error on any output containing that marker, even if it's part the serialized presentation which *is* readable, like the uninterned symbol #:|#<32|.
The solution I'm aiming at is to make every writeToString() method raise an error when it can't return a readable representation when a readable representation is requested.
In preparation of this change I'm investigating the uses of writeToString(). There are 213 occurrences of the string ".writeToString()", many of which are related to the creation of error messages. It'd be particularly impractical to generate errors while creating an error message. On the other hand, there are also uses, such as the one by %OUTPUT-OBJECT which typically *should* obey those values and generate the PRINT-NOT-READABLE error accordingly.
So, simply renaming writeToString() to printObject() is still an option. We can even make the printObject() functions check whether they are allowed to return unreadable output. However, it seems to me we additionally need a function which returns - optionally unreadable - output without generating errors. I'm thinking of a function which resets the variables to the values WITH-STANDARD-IO-SYNTAX except that it binds *PRINT-READABLY* to NIL. Maybe that function should be called printUnreadableObject() or something alike. I've also thought about renaming writeToString() to printObjectInternal() and creating a new printObject(boolean requireReadable) which does the required work if the argument is true.
The line between printUnreadableObject() and toString() would be getting finer, since, presumably, the latter can't go about throwing lisp errors either. However, since .toString() is also called by IDEs during the debugging process, I'd assume it's not practical to start doing heavy Lisp evaluations to get the correct popup. So, my idea would be that .toString() would be a lightweight function producing output to help debugging where possible and printUnreadableObject() would much more heavy weight, producing output a Lisp user would expect. Hmm. I hope the above is something people want to comment on. At least I've
tried to describe my findings so far. I'm interested to know what others think.
That's to complete my memory dump :-) Bye, Erik.
participants (1)
-
Erik Huelsmann