Let's hack some code

[Martin Cracauer]

Fare Rideau writes:
> >>: Richard Coleman <coleman@math.gatech.edu>
> >: Mike McDonald
> 
> >>How about CMU-CL (or) CLISP on top of the new Flux toolkit (due in May).
> >
> >   Both CMU-CL and CLISP are missing support for threads, which a
> > "LispOS" needs.

> First-class Continuations would of course trivialize threads,
> as well as being of great help to support the Schemists among LispOSers.
> If you fear about the power of duplicating continuations,
> you might require that they only be used in linear context,
> but I'm not convinced you gain much at that.

Hm, I can't claim to understand the full implications of adding
continuations to Common Lisp. For a good integration of stack group
into Common Lisp, see ECL.

But I'd say it isn't the right thing. First of all, processes/threads
good enough to implement an OS would need some some support. Priority
settings and control from outside to kill, stop etc the things are
needed.

Finally, I definitvly want OS-shedulable threads in the long term, so
that they may be distributed to several CPUs. The very least is that
the thread API doesn't prohibit this, which would be the case for a
continuation-oriented API.

While threads on top of continuations might be easy to do, it is
probably asier to add threads than continuations to an existing
implementation that doesn't have continuations.

> What about MIT-Scheme instead?
> Or RScheme? RScheme already has a persistent store and real-time GC!

Well, the choice between Common Lisp and Scheme (and Eulisp) is more
important that to be made on the base of available continuation-aware
implementations.
 
> > If I were to start such an undertaking, I'd start with ACL and Linux.
> ACL is not quite free, so we can't hack it into an OS.

We definitivly want to base on source-available software.

> Btw, anyone managed to get it running?

Run on Linux for me, almost on FreeBSD.

> it keeps dying during initialization, to me --
> Franz tells me to reinstall Linux )-8 .

probably right :-)

> > Strip everything else out of Linux, except maybe the networking stack [...]
> If we're going to strip something, Linux may not be the best idea.
> We'd better go with HURD, BSD, VSTa, or something finer-grained.
> Also, there's a lot to recycle from the Fox project at CMU --
> the only OS I know (besides the dead OSes of LispMs)
> written as a set of modules and functors
> in a higher-order functional language.

I'll send a seperate message later, but I think we are better off
using a well-tested full kernel like FreeBSD, NetBSD or Linux than
basing our stuff on a Unix-server-less Mach. The advance in
error-freeness, in overall quality, in number of knowledgeable people,
available drivers, memory and disk performance, networking features
etcetcetc is just too big.

And why strip it down? A FreeBSD kernel is small enough for today's
machines, there's nothing to gain from a smaller kernel.

Oneone thought about the GUI? I'd say the X window system (in Xfree
incarnation) is the only solution unless you want to stick with 4-bit
640x480. And we need the full Unix kernel to run the server.

If there's some Unix functionality you don't like, just don't use it,
but don't through it out. 

For example, this could apply to the signal mechanism. Use a kernel
you have source for (and people who understand the beast) and
implement the message mechanism you like between the kernel and you
Lisp process. Or put the Lisp into the kernel.

> >   Oh, before the some apps people could begin, they'd have to design
> > and build a windowing system.
> Well, there already exist window systems for CL,
> and a lots of non-standardized things in Scheme,
> all running on top of X.
> In a first time, we could just use a linux-based X server;
> for direct hardware support, we could move with something purely LISP
> by recycling code from DDX and GGI.

Could you explain what DDX and CGI should be? 

The only thing of help is something that gives us drivers for PCI
graphic cards. Either we run a Unix kernel to use XFree86 or we need
an interface in a Lisp-based kernel to use Win95/Windows NT drivers.

I discussed the latter with frieds for other purposes, but our
conclusion is that these Windows loosers don't keep their drivers to
driver functionality. They see to use standard Win32 calls quite
often, so our kernel needs those mechanism, too. This impressions
needs a reality check, though.

> > And probably a command loop, [...]
> I have gathered a few ideas for user interfaces in
> http://www.eleves.ens.fr:8080/home/rideau/Tunes/Interfaces/
> Of course, in a first time, we could use edwin, emacs,
> or whatever free Lisp interface exists at the time...

CLIM would be an option also. See http://www.cons.org/free-clim/ 

While CLIM is not easy to implement, it is more likely to be
implemented that most else, because it has a lot of people behind it. 

Also, CLIM defines quite a few bits that might be useful for a
commandline interface, too.

Martin
-- 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <cracauer@wavehh.hanse.de>
http://cracauer.cons.org
Fax +49 40 522 85 36