What's a POS??

Martin Cracauer cracauer@wavehh.hanse.de
Mon, 12 May 97 13:15:55 +0200

Harvey J. Stein writes:
> Martin Cracauer writes:
>  > The Lisp equivalent could look something like this
>  > 
>  >   (somecommand (file-information (glob "foo*.dat")))
>  > 
>  > where file-information puts out a struct that somecommand uses to do
>  > its work.
>  > 
>  > No, if `ls -l` were a long-running program, or if I would like to
>  > capture the state of the directory before I change somethings, I could
>  > do it like this
>  > 
>  >   ls -lg foo*.dat > somefile
>  > 
>  > and later, maybe weeks and reboot later
>  > 
>  >   somecommand < somefile
>  > 
>  > What would the Lisp POS equivalent look like? How would it be
>  > different from plain print/reading the struct?
> I'd presume the POS equivalent would be:
>    (setq somefile (file-info (glob "foo*.dat")))
> Later you could do
>    (somecommand somefile)
> When you wanted to do:
>    rm somefile
> You'd instead do
>    (unintern somefile)

This is the approach to make every object persistent. I don't think I
want that nor do I think it can be implemented efficiently, Unix
swapspace hacks or not. And I think it will make live quite hard to
acess data that is larger than the maximum address range of your Lisp
> The system itself would make sure that everything's committed to disk
> at an appropriate time.

That what I' afraid of ;-)

I feel the urgent need to get my hands (not eyes...) on some Lisp POS
systems. I don't have enough experience to judge over any approach and
I don't think I can get it by reading about it. Someone has an unused
copy of Statice for a Symbolics 36xx around?

Kelly has a big head-start here over most of us, no wonder he feels
uncomfortable sometimes. I can only repeat my request for posting of
more code examples so that people will be kicked out of their own

In no way I think your (Harvey) ideas of persistence are worthless
illusions. But I think they need to be discussed. The interface of
your approach is clear, there is none as long as you don't want to
transport objects to different Lisp worlds (what I want). But your
approach raises even more (efficient) implementation questions.

Martin Cracauer <cracauer@wavehh.hanse.de>
Fax +49 40 522 85 36