Let's begin SchemeOS

[Chris Bitmead]

Well I've decided I'm going to do some real work on a Scheme OS,
and I invite anybody with the same vision to help me. This is my
vision. If you like my vision, join me.

This is my project plan....

--Step 1--

As I've said before, I can't see enormous point in a Scheme OS
without a Persistent store replacing the file system. That is
where major, order of magnitude increases in productivity are
going to occur. This is where the superiority of the system will
make UNIX/Windows junkies sit up and take notice. It removes the
need for programs to continually convert everything from disk to
memory representation, but more importantly, it allows a user of
the system to easily write cute little Scheme scripts that do
incredibly powerful things. Whereas on UNIX you now need
sophisticated packages like procmail to say filter your mail,
instead with Scheme OS you would write a few little obvious
Scheme statements that could do the same thing. It is cute LITTLE
things like this which will make SchemeOS great. Little bits of
code that people will contribute that will solve big problems
through pure elegance.

It therefore follows, that STEP 1 for this Scheme OS, is to
design an initial object  model for the things in the operating
system. 

The design phase will answer questions like...

What sort of hierarchy will be in the persistent store?
What sort of object will store an email message?
What sort of object will store a text file?
How to store executable bits of code?
Should there be objects to represent versions?
What objects do we need to implement security?

An example of what comes out of this might be that we have mail
folders which are collections of mail objects. Mail objects might
consist of a FROM text member, a TO text member, a Subject text
member and a mail text member. I'll leave you to speculate on
what object methods the mail object and mail collection objects
might have.

The end result will be a huge object model. Even if the project
ends here, I think we will have left something useful for some
future effort to start from.

--Step 2--

But of course, we don't want it to stop there. Once the object
model is done, the basic object structure can be coded in Scheme
(Probably RScheme, since it already works with a persistent
store).

Once that's done, then a framework is in place, that lots of
people can come along and do little bits and pieces without being
overwhelmed. Like someone with a couple of hours to spare can
write some Scheme to convert a UNIX mail file into a Scheme mail
object in the persistent store.

I like the functional programming model, so the object model will
be designed to not conflict with the functional programming
paradigm as much as is reasonable.

The system shall be implemented on top of UNIX, for all the
reasons previously mentioned. Personally I shall be using Linux.
Therefore, the initial bits of code written will be done to hide
the UNIX view of the universe, and to instead provide a view of
things which is ideal to SchemeOS. Things like code to convert
UNIX mail files to SchemeOS mail objects. That way code built on
top will not be aware that underneath it all it is really UNIX
that is delivering email.

At some future time, some people may want to provide ways to
remove UNIX all together. That is too far in the future to
contemplate at this stage. What we need now is something that
proves the concept, rather than trying to re-invent everything
from the ground up. Lets get the basic object interfaces right,
and implement those interfaces in whatever way gets things
working fast.

--Step 3--

Once all the basic objects are in place and doing basic things.
To use the email example again... Once we have a email object
that delivers your mail (behind the scenes via UNIX), then basic
apps can start to evolve. Like UNIX history, these apps will
start off with basic apps, which will slowly evolve into more
sophisticated apps. UNIX started with the basic "mail" program,
which then evolved to elm, pine etc etc.

Unlike others, I'm not overly concerned about getting emacs
working. The reason is that current implementations of Emacs, are
very much devoted to the UNIX view of the universe. That is,
everything is a text file, and everything is stored in a UNIX
file system. That means porting emacs straight out is not
terribly useful. Eventually however, a good deal of Emacs may be
able to be ported to SchemeOS, albeit working quite a lot
differently. In any case, text files will be much less important
in Scheme OS, and therefore Emacs will be quite a lot less
important too, since it is primarily a text editing tool. Until
SchemeOS gets it's own text editor, we can use a UNIX editor, and
write a Scheme program to import the UNIX text file into a Scheme
text object. I've never used a Structure editor, so I don't know
how good they can be, but maybe SchemeOS might have very little
need indeed for text editors, if we decide a structure editor is
a better way to write Scheme.

--Step 4--

Once we have implemented enough of the system that we have proved
the concept to ourselves, only then we shall tackle the hard
technical issues. Issues like whether RScheme is the right scheme
to use, whether the persistent store we are using is good enough
for our purposes. Whether the thread model we choose will work
well with multiple users. Whether SchemeOS should be able to work
without UNIX. Whether we can get Lisp and Scheme to work
together. All these issues are too hard to tackle right at the
beginning. We need to have something now that is very clear in
it's goals, and very functional in what it gets done. People will
rise up later to tackle these things. Expert people who are
inspired by our vision, and skilled enough to implement it right.

-- What to do now--

I don't know if it appropriate to continue to use this mailing
list or not. Since isn't a lot else is going on, I would hope so
and presumably everyone else might find the discussion useful,
even if they ultimately intend to build a LispOS of some other
vision. If it is not considered appropriate to use this mailing
list some other host will need to be found.

The first step then is to put forward a list of objects that we
need to design. Objects to hold all the important sorts of data
that UNIX would store in text files, and objects to organise
those other objects.

Once we have that list of objects, we shall design interfaces.
Then we shall code the basic structure of the objects. Then we
shall implement them. Then we shall build apps that use them.

-- 
Chris Bitmead
http://www.ans.com.au/~chrisb
mailto:chrisb@ans.com.au