The debate about heavy or light-weight saving sounds a lot like the debate
in traditional programming languages of how users should implement
persistent state.
Java comes with a serialization mechanism that allows the user to save
and load all objects reachable from a particular object root. It handles
cyclic data structures by replacing memory pointers with pointers to
object locations in a handle table. (see
http://www.javasoft.com/products/jdk/1.1/docs/guide/serialization/index.html)
Object databases, like PSE, provide caching and indirection facilities
that allow the "lazy" loading/saving/updating of object graphs. (Some
versions provide ACID transactions)
(see http://www.odi.com)
Relational databases forces the programmer to transalte data structures
into a relational format and then use JDBC to store/retrieve them.
(see http://www.javasoft.com/products/jdk/1.1/docs/guide/jdbc/index.html)
I realize that implementing these options is easier in languages that are
pointer or handle based rather than in languages that treat all objects as
literals, but if Haskell does not provide a way to use facilities like
these, it will not be able to compete in the space of professional
production quality languages.
-Alex-
___________________________________________________________________
S. Alexander Jacobson i2x Media
1-212-697-0184 voice 1-212-697-1427 fax
On Tue, 24 Feb 1998, Tony Davie wrote:
> Tim Barbour writes
>
> >>>>>> "Tony" == Tony Davie <[EMAIL PROTECTED]> writes:
> >
> > Tony> This has well know disadvantages. Simon has already pointed
> > Tony> out that it's not relocatable. It's also limited to the size
> > Tony> of virtual memory and takes up that amount of space even
> > Tony> though most of it may not be used. Loading a complete
> > Tony> persistent memory at once is overkill. You should load it's
> > Tony> objects lazily and only store away accessible stuff at
> > Tony> commit time.
> >
> >Relocation and address space are not such a problem on 64-bit
> >machines. Not having enough address space is really a disadvantage of
> >32-bit machines, not persistence.
> >
> >I was suggesting using memory-mapped files, using e.g. mmap. Such a
> >file is mapped instantly into the address space, but its contents are
> >paged in and out on demand. A mmapped file takes up disk space only
> >for the populated part of its address region, and does not take up
> >virtual memory. It takes up real memory only according to demand for
> >pages from the file, in much the same way as buffer blocks do on a
> >conventional file.
> >
> >Tim
> >--
> >
>
>
> A much more serious problem is that, in a persistent system, one may want
> to extend the persistent store by adding new objects to it and making use,
> in newly written programs, of the objects found there already. It's then
> very inconvenient to treat the store in one monolithic lump. And anyway
> didn't this start out about how to do I/O on binary data. Surely you don't
> want to output everything every time you output a single item, only those
> things reachable from it.
>
> Tony Davie, Computer Science, St.Andrews University, North Haugh, St.Andrews
> Scotland, KY16 9SS, Tel: +44 1334 463257, Fax: +44 1334
> 463278
> mailto:[EMAIL PROTECTED] Home: http://www.dcs.st-and.ac.uk/~ad/Home.html
> Handel Index and Chronology:
> http://bruichladdich.dcs.st-and.ac.uk/HandelWWW/HandelCat.html
> Limerick Archive:
> http://bruichladdich.dcs.st-and.ac.uk/LimericksDir/Limericks.html
>
> 'There is magic in the web' - Othello, Act 3, Scene 4
>
