What's a POS??
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 <firstname.lastname@example.org>
Fax +49 40 522 85 36