First proposal: what should LispOS feel like?

[Martin Cracauer]

I think we don't have enough agreement here what we want to beast to
look like.

How should LispOS be different from FreeBSD/Linux/X11 or Windows?

How should LispOS be different from a decent Lisp development system
(say: Lispworks) running on a normal platform?

I'll start with my view and like others to comment or add their own
description. 

I turn on the machine. 

A Unix system asks me what kernel to boot, if I want to boot only the
basis services (single-user) and maybe I can make some driver settings
to make my kernel be able to find my hardware.

A MS-Windows system can be told to boot with just basic services.

The systems go on booting the OS kernel. On MS-Windows, it somehow
starts up hardcoded stuff with settings in mysterious data files. On
Unix, it will call init (which I can exchange with something own) and
init then decides (on the base of the former user parameters) whether
to run the startup script, which are usually ASCII files or some sort.

I want my new Lisp machine to ask me in advance for some things that
can't be changed once the Lisp is running (done using commandline
parameters on stock systems) and optionally to save these for further
repeat.

Then, if I told it to start up normally, it should run the startup
scripts. The startup scripts are actually Lisp code. As we all know,
Lisp code is also Lisp data. That makes it easy to generate and
manipulate these scripts and their data from different tools like GUI
administration tools and/or manipulate them by hand. The scripts could
be part of a saved world, a compiled file or an ASCII file.

Unix script's and config files are almost impossible to manipulate by
programs. Windows files are reasonable machinable, but only from
specialized tools. Also, since mess-ups are common, I definitively want
to be able to manipulate them directly, which requires a hexdump editor
on Windows. 

OK, the system boots into whatever normal state is defined. A typical
picture might be:
- all network interfaces has been brought up, including routes.
- it has started some network services like HTTP and mail servers
  (like Unix daemons)
- it prompts me for login on network ports (like Telnet does)
- it prompts me for login on the console

I want a X11 server to come up, maybe that should be done later.

When I log in, I expect these things to show up:
- A Lisp listener or some command line like Genera's Common Processor
  that messes with Lisp objects instead of Unix ASCII streams.
- An editor written in whatever Lisp dialect the machine runs, or at
  least understanding code in that language for customization and
  package programming.
- A meaningful Window management capability that is integrated with
  Lisp's needs. The most important feature is to support fastest
  selection of a given tool. That equivalent Genera's 'select'
  key. There should be one keystroke to get to the Listener, to the
  editor. The Window manager should be written in the platforms' Lisp
  dialect and probably be running in the same world as the editor and
  the listener.
- I want a real logic behind Lisp listeners and the connected Lisp
  worlds and threads. I want each thread in each world to have a
  reasonable mean of standard-io and where and when to call a
  graphical or a tty debugger.
- The browsing tools that make Lisp so nice should be as near to a
  keystroke or mouse gesture as possible.

And yes, I want several worlds. Maybe the whole stuff for my login
session should be *one* world (Listener, Editor, Window manager,
Browsers). But the background processes like HTTP servers should have
their own world that survives crashes of my login world and that
doesn't get messed up by manipulating my "front world" (nice term).

I didn't made my mind up about OO file store yet.


Conclusions:
- I want different User IDs with different permissions on Object like
  memory areas, files and port, whatever and I want different processes
  to be run under different UserIDs
- Therefore I want both: Lisp threads inside a world. And several
  worlds running in parallel, for different users or several for one
  user. 
- A Lisp inside the kernel is not necessary for me. I would make it
  much harder to support several world in parallel.

What to do:
- We need a Lisp Implementation that has good enough thread
  support. Of the free systems, that is only ECL, which has the same
  disadvantages like GCL/AKCL.
- A Lisp system that can communicate over Lisp worlds
  reasonable. CMUCL already does.
- We need a definition of startup scripts in Lisp.
- We need a way to call all that OS services. For each task, we need
  to decide to either call the commandline tool (like ifconfig(8)) or
  whatever systems calls are there to set up interfaces. That will
  be just a Lisp function with some args and the user will not notice
  which implementation is used.

So, this looks pretty much like a customized Unix system, doesn't it? 

I'd say no. It is a system that uses of Unix what it needs to and what
is useful in Unix. The free kernels are good and we need them, we
can't re-implement them, not to speak of drivers.

We take process management including user's permissions. We take
hardware drivers, we take virtual memory/paging. We take X11, a
sufficient decent networked GUI system (I don't speak X toolkit here)
with XFree's video card drivers.

We don't take the Unix commandline. We don't Unix scripts. We boot the
GUI into a consistent state optimized for Lisp work.

We through away insecure protocols and network daemons like
rsh/rlogin/rcp and use things like ssh (secure shell) instead. Yes,
there are some C/Unix tools to use. You probably want ssh's security
features and you probably don't want to re-implement it.

Then, we start the real stuff. We write a *working* Web browser, based
on a Free CLIM clone.

We implement interfaces to everything we can get hold of on The
Net. HTTP the least. Corba the next. Active-X/DCOM.

We use Lisp to explore these things. When we meet an interface of
whatever distributed OO system on the net, we have a browser at hand
that not only displays what one can do with objects of that interface,
but also allows use to create a test object dynamically, fire up
messages to it interactively, inspect the result. With editor
completion of message names. When our roommate looks over our
shoulder, he feels like in stone age reading the online interface
description in a pure text format and cut/pasting message names to his
static language source code prior to his compile/run/coredump cycle.

*Brakes*

What *really* to do:
--------------------

Most important: Speak up, tell me why my model doesn't fit what you
expect from such a project. Don't miss the opportunity to make a
complete idiot out of yourself by overlooking fatal drawbacks of your
dream worlds :-)

Decide which platform to use. We need a kernel. I'd like FreeBSD, but
maybe could live with Linux as well. If we live without an in-kernel
Lisp, it is within scope of an individual, to keep the other one
usable as a LispOS base (would need to adjust used Unix tools and
system calls). 

Decide which language to use. I think we have two options:
- Common Lisp and start with CMU's hemlock editor
- Guile/Scheme, so that we can expect to use native emacs integrated
  with our OS. Also, Guile approaches for different syntaxes might be
  a plus when other users want to use or system and will maybe result
  in a nice command language for interactive use.

I really really really hate any programming language implementation
that keeps me from removing any pointer indirection and type check I
don't want, but the prospect or having native emacs and all its
packages as part of LispOS is great. So great that I couldn't get the
Guile idea out of my head. One might have a CMUCL tightly integrated
to write speedy parts of applications then :-) Bigloo, Stalin or
Rscheme aren't bad, either.

Define what the Window manager should look like. The Window manager
should be programmed in the platform's Lisp dialect and live in the
same world as the rest of a login session. We have to define what it
should do, define an API.

Decide over a Lisp API for threads and processes, including the
std-I/O problem and debugger calling.

Start hacking. Actually, I'm more a putting-things-together man than a
real hacker that creates things from scratch. Maybe that is why my
proposal has actually quite few coding opportunities in it :-) 

Those hardcore coders of you, you could jump on the Free CLIM effort
(http://www.cons.org/free-clim/), that is the most efficient way to
help Lisp (*if* we choose a LispOS model that doesn't need Lisp
hacking, that is :-). Take this Expresswindows stuff we have and make
move it towards CLIM compatibility for the functionality is has.

Martin
-- 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <cracauer@cons.org> http://www.cons.org/cracauer
  cracauer@wavehh.hanse.de (batched, preferred for large mails)
  Tel.: (daytime) +4940 41478712 Fax.: (daytime) +4940 41478715
  Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536
  Paper: (private) Waldstrasse 200, 22846 Norderstedt, Germany