Re: [Sbcl-devel] Print-unreadable-object: spurious newline?

[Tony M. <to...@te...>]

> > For example, I was aiming for:
> > 
> >     #<TYPE-NAME ...
> >                 ...
> >                 ...>
> > 
> > but instead get:
> > 
> >     #<TYPE-NAME
> >       ...
> >       ...
> >       ...>

> I put it in because I find it convenient, [...]

When I found the newline code in PRINT-UNREADABLE-OBJECT, I also
thought that this could be a convenient formatting assumption in many
cases (e.g. #<POINT X Y>).

However, the data structures I'm debugging are recursive trees of
instances of different classes, and I'm finding the structure is
easier to read (like some Lisp forms, I suppose) when indented WRT the
instance type.

As things stand, I haven't found a way for this to work, whereas
without the additional newline the user can specify the behaviour she
wants (easily if, like myself last night, you care so little about
sanity that you use FORMAT in all it's g[l]ory: iteration, logical
blocks, conditional newlines et al all brought a new appreciation of
the word 'context' on observing the behaviour of #\@ and #\:).

> [...] but if I had realized the standard is fairly clear about the
> space [and nothing else] I wouldn't have done it. Now that the issue
> has been pointed out, I agree it's a good idea to remove it.

I initially thought that the spec could also be read as "at least
print a space", since it doesn't /forbid/ printing more characters,
but it does rather insist on how many spaces get printed between
identity and type data, so I think I prefer "/only/ print a space"
reading.

That said, whether the emitted space is conditional to the body being
present isn't specified, either, so I dunno.  You've all got much more
experience working with the spec than me, and God forbid I give Paul
Dietz any more ammo, so I'll go away and make a cup of tea.

-- 
Tony, nit-picker non-pareil