[armedbear-devel] The purpose of the writeToString() method (before we can rename it to printObject() or anything else)

[Erik Huelsmann]

Commenting on myself here:

On Sun, Jul 17, 2011 at 8:40 PM, Erik Huelsmann <ehuels at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/armedbear-devel/attachments/20110717/f59cf6d1/attachment.html>