Tue, 29 Apr 1997 22:55:54 -0700
OK, here's my ideas on how we should proceed:
Here's a list of capabilites I'd like to see in a PC LispM:
1) User Interface
a) Windowing system
- use the X server for the drawing of bits and interfacing with
the gazillions of video cards
- implement a version of CLIM. This gives us presentation types
and a structure for implementing a command loop. Team up with
the free-clim people inorder to do this.
b) command line interface
- use the CLIM command tables to implement a lisp listener that
works on ascii streams, aka the console, serial lines, ...
- implement a history/editing system to support the lisp
c) user apps
- editor. initially, use whatever editor suits you. Long term,
implement an emacs style editor. We can either emulate elisp
inorder to "borrow" the [X]emacs code base or we could start
with hemlock (CMUCL's emacs editor), or build our own from
scratch. (I'd guess it turns out to be a combination of 1 and
- debugger. we need both an "inline" debugger and a window
based debugger. The inline one is what you'd normally fall
into when encountering an error (standard lisp debugger). The
window based one for more "intense" debugging. Maybe integrate
it with an "inspector". (With CLIM, inspectors are alot less
useful! Every printed representation of an object on the
screen is mouse sensitive, with one of the default actions
being describe this object. Of course, everything describe
prints out is mouse sensitive too. Walla, you can navigate
thru any object you want!)
- web browser. If we're going to support a fancy lisp based web
server, it sure would be nice to be able to test it out from a
fancy lisp based browser.
- mail reader. Hey, if you've kept up with the five hundred odd
messages in this list so far, you don't need convincing!
- news reader. For when we have spare time from implementing
this beast! :-)
- misc. utilities. tar, gzip, ...
a) Generic networking system
Symbolics had a neat way of describing network protocols into
two parts, a generic descriptor like file-transfer and then a
protocol specific tag, like ftp, or nfs. When a user typed in
a command like "Show Directory titian:/usr/people/mikemac",
Genera would lookup the type of host that Titian was (Unix),
then it would look to see what ways it knew how to do
file-transfer operations on Unix hosts. It then tried those
methods in a specific order, specified by the namespace object
for that host. As a user, this meant that I didn't have to
worry about how to get the files, that was the job of the
computer. These are the ones I think we need (maybe more!):
Oh, these should all be proxy/firewall aware whenever
- File-Transfer. NFS, ftp, rcp, ..
- Telnet. Telnet, supdup (anyone use that anymore?), ...
- Remote-exec. rsh, ...
b) daemons - lots and lots of them!
- SMTP (Simple Mail Transfer Protocol aka sendmail)
- HTTPD (Here you go Kelly!)
At this point, I think we'd have one neat machine. You'll notice
that I haven't said anything about Linux/Flux/BSD, file systems,
schedulers, ... that you'd expect from an OS. Nor what common lisp
to use! That comes all comes afterwards. All of this stuff should be
able to be implemented on just about any ole common lisp.
Now we can start doing the nifty stuff like persistant object
stores, networking stacks, OS mods/support, SMP support, .... This is
not meant to imply that if someone really wants to go do some of those
things now, that they can't. This is a volunteer effort afterall. You
can do what you want!
OK, I have my asbestos undies on. Flame away!!