pathnames

[Chris Bitmead uid(x22068)]

>I think that having a commit API would then make the two-level storage
>nature of those objects that just happened to be in the user-level
>"namespace" have to be dealt with differently, all of a sudden - they'd
>have to be committed and all that.

Ok, I can see that your idea might at least be a useful
option. Perhaps even a good default for hacking around at the command
prompt, but I'd have to think about that. Most applications would want
to have an explicit (commit) though at one strategically positioned
point, which doesn't break the illusion too much.

>EG, the user-level repl loop is in fact a persistent object (maybe
>called "/bin/sh", as a subtle irony :-), so everything inside it has
>a home to go to when the system is powered down, but only the actual
>environment object is registered as persistent, since it includes
>everything else. It would have modification dates and all that, and
>a user-level type. It's real type would be "executing environment
>with a continuation", but it's user-level type could be "Command
>line application".

Yeah, but that means that there is only one object in the whole system
which complies with your API - "/bin/sh". Everything else just happens
to be attached. So what's the point?

>> Versions? Well also don't forget that nice Lisp code is very
>> functional, and not everything will have a clear correspondance to a
>> version.
>
>It's nice for document management, 

Sure, document managment is a good use for it. But different apps will
want to access versions differently. Documents probably want to be
accessed by date. Program source by the release number. etc.

And with documents, sometimes a document might consist of a number of
different chapters in different "files". You probably don't want to
version the individual bits and pieces because you've then lost track
of how the whole document looked at any one point in time. (Anyone
using source code control is familiar with this problem). What you
want to do is version the whole "directory" (collection), and not
bother versioning the bits and pieces. The versions of the bits and
pieces just fall into line by versioning the collection.

Basicly versioning is very application specific.

>and the user-level POS is a very
>stateful thing rather than functional.

No, this is not true. The POS should be very functional just like all
Lisp. The POS can't be completely functional because state must be
saved. But the state changes should be at a high level as
possible. 

Take the example of a document with several chapters. You've probably
got in mind some Lisp function which changes a "Chapter" object and
saves it to the disk. Something clever in the background makes sure
the old version is saved somehow.

I've got in mind a function (chapter-edit) which takes a "Chapter" as
argument and returns a new Chapter object as a result. The old version
is not changed in true functional style. Another function (book-edit)
takes a "Book" object as argument, and then calls (chapter-edit) to
modify chapters. Instead of modifying the book object, (book-edit)
makes a new book with the all the latest versions of the chapters and
returns the new book object. The old version of the book object is
left as-is. (In functional style)

All this propogating of the problem upwards has to stop at some
point. Which point depends on how the user wants to view a logical
unit of work. Probably it would stop at the book level.

>> But there wouldn't be a separate version for each cons cell, or each
>> piece of email. The new version folder would simply point to the old
>> email. (A nice space saving over UNIX!) In fact there will be a
>> relatively small number number of objects in the system which need
>> versioning.
>
>Agreed... so let the default be "no versioning", but make a special
>"commit" API where persistent objects can give the OS a hint that
>they're in a good state for a checkpoint right now. The OS can store
>the list of versions as the "oldest version", then a list of
>sets of differences from that.
>When it decides to trim off some old versions, it updates the
>"oldest version" with them, then drops them.

So how does the OS know which objects you want versioned? 

What do you hope to gain by having a One True Versioning Algorithm?

>> Unlike a UNIX fs where every file has it's own inode which points to
>> separate disk blocks and every file has at least one disk block
>> attached to it, OOFS is much more efficient, like an OODB. In most
>> cases, all the objects in a collection (or directory if you must use
>> that term), should be on the same disk block. Therefore it will be
>> much more efficient to access each object in OOFS than to even do an
>> "ls -l" under UNIX, let alone a "file *" under UNIX.
>
>Yes, but these user-level objects (which would map nicely to
>segments in an OOFS from what I hear) are typically going to be
>relatively large.

How do you figure that they're going to be large? In actual fact, they
will be extremely small. Take a document object for example. It would
probably be a small structure containing a description, a date, and a
pointer to the document itself. The actual document object consists of
only 3 slots. An appropriate display-summary method would only print
the description and date.