Issues of Persistence

[Fare Rideau]

>: Kelly Murray

> I kindly point out that not having pathnames *is* starting out simple!
>
Yup. Let's drop pathnames altogether,
and use first-class environments.
Access to Unixish filesystems is just done by giving an environment
interface to Unix directories.

BTW, there are semantical problems relative to interaction
between a persistent system and non-persistent ones...
What if I open unix file, stop the lisp system,
change the way unix mounts filesystems (or just move the file),
and continue with the lisp system?
* Should an exception be raised?
* Should the lisp system reopen a file? If so, which?
* Should the lisp system have completely copied the file in core
 beforehand?
* Should the user choose what to do? For each of those 2325025 open files?

> You can start writing programs in which everything is a persistent
> object by first starting writing programs in which everthing is an object.
> The persistent part can come later.
>
I disagree. The persistent part must come early on.
Persistence is a whole change in programming style.
IBM says that direct code size saves are 30%.
[I'd say that indirect saves through are much higher]

> One can "fake" persistent objects by making entire processes be
> persistent.
>
That's an *especially bad* idea in a system being developed:
it means that you suddenly cannot change the persistence infrastructure,
and will loose your whole session at the first bug
(do you intend to not write a single bug?).
In an OS *in development*, by definition,
I'll want to modify the calling conventions,
the way persistence is handled;
I may involuntarily introduce bugs in the way,
or make changes that will introduce incompatibility
with the previous dump file format.
Relying on (dump) is just not safely possible.

#f