Let's begin SchemeOS
Mon, 23 Mar 1998 01:45:41 +0100 (CET)
>>: 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*))
> 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,
* 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."