pathnames

[Chris Bitmead uid]

>> Can you imagine how tedious this would be?
>
>[...]
>
>> Except that it wouldn't work, because you might have a pointer to cons
>> cell v4 which points to cons cell v2 which points to cons cell v8,
>> none of which are the latest version. Therefore every object reference
>> in your system would have to have two components... a pointer to the
>> container object and a version id. Are you sure you want to go down
>> the road of having a language where every reference is made of two
>> parts, and isn't really a direct reference, but is an indirect
>> reference through some container object?
>
>I sense a deep misunderstanding!
>
>We wouldn't individually name each and every cons cell, now, would we?
>There wouldn't be much point in /that/! We would only name objects
>that are high-enough level to warrant a unique name.

I don't know who even mentioned naming every cons cell. This is the
first I've heard of it. Perhaps you should re-read what I wrote.

>A "name" is a reference in the persistent "hierachy" of names that act
>like a filesystem. A "name" amy refer to a set of versions of an object.
>
>We name documents and pictures and applications. We don't name each and
>every cons cell :-)

Sure, but you're setting up a dichotomy between things that are named
and things that aren't. This artifical division you're suggesting
where objects which you give a name to, suddenly take on magical
properties, and objects which don't need a name lack magical
properties is asking for trouble.

The question remains of how you would sort out the mess of versions
and references.