Let's begin SchemeOS

[Fare Rideau]

>>: Paul Prescod
>: Chris Bitmead

>> The problem is not that Unix has a filesystem,
>> but that software usually stores information in that filesystem
>> in random, incompatible file formats with no natural mapping
>> to memory objects.

"Natural mapping to memory objects" sounds wrong to me
(at least in the context of a "standard encoding"),
but maybe that's just because I'm interested
in heterogeneous distributed systems,
and also because I think that memory and disk have
different enough space/time constraints,
so that they require altogether different encodings
if performance means anything.

>>[Follows example of lisp script to access a SEXP encoded /etc/passwd.lsp]

> If you do the above, then I guess you have an object file system,
> albeit one that is
>
> a) inefficient - presumably the .lsp files are ascii text
> b) not at all transparent. Every load and store has to be
> explicit, which kinda defeats the purpose. Say goodbye to all
> that elegance.
> c) Not very practical - you can't have object references that
> cross the boundary between one file and another file. This is a
> big killer.
> d) Not convenient. You would have to decide on some arbitrary
> break down on how much  to store in one  file.
>
And you forget, which is most important:
e) not consistent with respect to concurrent access and/or power failures.
 A *major* advantage of a system-managed object-based persistent store
 is that you no longer have to emulate complicated unenforcable
 locking mechanisms (or forget them and be suffer someday).
 These are transparently managed by the meta-object protocol,
 and from the user point of view, modifying the /etc/passwd
 will be an atomic transaction (or part of a larger transaction).

> (set! *user-list* (filter (lambda (x) (member (name x) *bad-guys*))
> 			  *user-list*))
>
> Even just this one example shows the amount of unnecessary crud
> that can be gotten rid of.

Also, a system-managed object store has a great advantage,
that makes possible lots of things just unimaginable with a filesystem:
f) since there is no need for a low-level standard representation,
 data can be made of high-level objects instead,
 and new fields/annotations can be dynamically added to them,
 so that the user "list" can be a high-level extensible knowledge base
 instead of a mere clumsy statically-defined ground-level database.
g) Another advantage of the absence of low-level standard representation
 is precisely that the actual representation might be dynamically selected
 by the system for maximal space/size performance
 depending on the intended use
 instead of having to comply to a stubborn static compromise
 between space, size, and human readability.

Note that these last two points are about
high-level standards allowing metaprogramming and reflection,
as opposed to low-level standards tying you down to one implementation
with static definitions.

I agree with the rest of Chris' remarks
(as well as with most of what he posts here).

> I must ask you... Why would you want to muck around with a
> conventional UNIX file system at all given all its disadvantages?
> Just for backward compatibility perhaps?
As an aside, and even though I hate all this cruft,
I do think backward compatibility should be some of a concern,
be it only to transfer data to and from the LispOS,
until we can fully migrate all our data toward a trusted LispOS,

PS:
* I still think that there is room for several LispOS projects,
 and since we obviously can't agree on a unified project anyway,
 we can at least agree to disagree on what to do next:
 using Scheme, ANSI CL, or another dialect,
 basing implementation on RScheme or CMUCL,
 hosting on self (or Flux) or Linux/BSD,
 starting from the application or system side,
 storing objects with a filesystem or a persistent store.

* As for my personal opinion on what *I* am going to do,
 I have an article underway about what a Reflective Architecture is;
 but everyone should be doing what *one* thinks is best
 that one can contribute to.
 When some code eventually appears and gets to be used,
 the path to a unified projet might (or not) be clearer.

* As for getting code available, would it be possible
 that we, as a consortium of users, convince (with words and/or money)
 whoever still owns Lisp Machine code
 (Symbolics successors, Xerox, TI, HP, MIT, etc)
 to make it publically available?
 I am ready to participate financially in such an operation.
 Maybe the demise of Symbolics is an occasion to
 buy their assets for cheap!?
 Else, when will some/all of this code become public domain anyway?
 US Legal affairs are sure not *my* specialty...

## Faré | VN: Уng-Vû Bân   | Join the TUNES project!  http://www.tunes.org/ ##
## FR: François-René Rideau |    TUNES is a Useful, Not Expedient System     ##
## Reflection&Cybernethics  | Project for a Free Reflective Computing System ##
"I think sex is better than logic, but I can't prove it."