From: David Bakhash
Subject: printing/reading CLOS objects in streams
Date: 
Message-ID: <cxjemngokhe.fsf@engc.bu.edu>
Hi,

Is there an implementation-independent way to read/write CLOS objects, 
in the same way we can do so with STRUCTS, once the DEFSTRUCT has been 
defined.  In other words, when we write a defstruct, that struct is
defined, and the Lisp reader then knows how to read instances from
streams (i.e. the printed versions).  So what about CLOS?

dave

From: Barry Margolin
Subject: Re: printing/reading CLOS objects in streams
Date: 
Message-ID: <vSFA2.61$Uu.1564@burlma1-snr2>
In article <···············@engc.bu.edu>, David Bakhash  <·····@bu.edu> wrote:
>Is there an implementation-independent way to read/write CLOS objects, 
>in the same way we can do so with STRUCTS, once the DEFSTRUCT has been 
>defined.  In other words, when we write a defstruct, that struct is
>defined, and the Lisp reader then knows how to read instances from
>streams (i.e. the printed versions).  So what about CLOS?

No, CLOS doesn't have this built-in.  The default printed representation
for CLOS objects isn't readable.  You can define your own printed
representation for your classes by defining PRINT-OBJECT methods, perhaps
interacting with readtable changes that you also define to make it
readable.

I think the Lisp repository includes a package that defines a general
facility for writing and reading most data types, including CLOS
instances.  I think it's called something like save-objects.lisp.

-- 
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
From: Kent M Pitman
Subject: Re: printing/reading CLOS objects in streams
Date: 
Message-ID: <sfwaey4hcqu.fsf@world.std.com>
Barry Margolin <······@bbnplanet.com> writes:

> In article <···············@engc.bu.edu>, David Bakhash  <·····@bu.edu> wrote:
> >Is there an implementation-independent way to read/write CLOS objects, 
>
> No, CLOS doesn't have this built-in.

As an aside to this, what plagues me more in practice is that I spend
a lot of my time with defstructs trying to turn off this read/write
thing that defstructs do.  I find exposing the object's internals 
rarely helps me and mostly just clutters my visual field when I'm
developing.  Nearly every struct I write these days has
 (:print-function (lambda (object stream depth)
                    (declare (ignore depth))
                    (print-unreadable-object (object stream
                                              :type t
                                              :identity t))))
in it.  Alas.  I do so wish we'd named that function.  I suppose
I should do so somewhere early in every system I write for as many
times as I recite it from memory.

To be clear, I think read/write has a place.  But it only works where
it works.

And that's not to say that it's not useful to be able to apply
the trick to CLOS things once in a while. It might be.  But mostly
I think it's not the right thing--at least not indiscriminately
just printing out every slot without knowing for each slot that
it's the right thing.

In fact, just to be provocative, I'll come right out and risk looking
ignorant by asking: does anyone have an example of a case where they
want to print out the contents of the slot and they don't know the
names of the slot and yet they are sure that the object will in fact
be correctly re-read (not just syntactically but semantically) in
spite of not knowing? I don't see how they could... but maybe I'm
just confused.
From: Kent M Pitman
Subject: Re: printing/reading CLOS objects in streams
Date: 
Message-ID: <sfw90dohcm5.fsf@world.std.com>
Barry Margolin <······@bbnplanet.com> writes:

> I think the Lisp repository includes a package that defines a general
> facility for writing and reading most data types, including CLOS
> instances.  I think it's called something like save-objects.lisp.

This can also be done with the meta-object protocol, btw.
(Maybe that's even what the package you're referring to uses.)
Not that the MOP is part of ANSI CL.  But it's still pretty
widely available.  Anwyay, I just wanted to mention the MOP for 
completeness.