Fri, 27 Mar 1998 11:05:05 -0800 (PST)
>Subject: Lisp Machines
>From: Antonio Leitao <email@example.com>
>Date: 27 Mar 1998 17:26:24 +0000
>So, for a LispOS to be really useful, either it emulates some already
>popular OS, or it runs within some already popular OS.
>I suspect that for most Lisp purists, the first option is the best
>one, but unfortunately is also the most difficult one.
>But I think there are some advantages on the second option also. We
>actually have most of the work already done. We already have Allegro
>CL, or CMUCL or CLISP or RScheme or whatever Lisp implementation you
>prefer running on top of most operating systems.
Being somewhat pragmatic, I'm in favor of the second option. I
really don't want to have to wait for someone to write an X window
server in Lisp for MY video card before I can do anything. CL using
the native OS's windowing system (probably X to start with) is the
place where I think we should start. Once things progress and people
get experience, if someone comes up with an implementation of a
"better" windowing system, great. Then I'll switch. But in the
meantime, I want to be able to run those on Lisp apps in a window.
>All these implementations lack a lot of the functionality of a
>Lisp Machine but why don't we develop such functionality?
>I remember that Allegro CL had a package called Composer that could
>give us some of the feeling of a Lisp Machine. Of course, we have to
>pay for this, but can also develop a new one from scratch. If we want
>to have a Lisp Machine, why not start with one that runs within Linux,
>for example, and implement all the functionality that we need?
I think I'd prefer CLIM to Composer. It's more of an "open" standard
than Composer is. But by no means do I think CLIM is THE windowing
>I'm sure some of the participants in this mailing list will complain
>that this isn't a genuine LispOS.
If it walks like a duck and quacks like a duck, ...
>I still think this is a feasible task. Most probably, we would need
>to have access to the internals of the CommonLisp implementation
>(specially for the window debugger and inspector), so this excludes
>(in part only) a proprietary implementation such as Allegro CL or
>LispWorks. Maybe CMUCL would be a good starting point. I don't know
>enough about CMUCL to judge.
I think CMUCL would be the longer term base. In the meantime, use
either ACL or CMUCL. A lot of the stuff that needs to be written can
be done so in pure CL.
>But most of the functionality already exists, at least in a primitive
>form. If you take a look at the Emacs-Allegro interface that comes
>with Allegro CL, you will see a very primitive (and buggy)
>"window-debugger", but that's the idea. We just have to make it much
>more powerful. We would also need to convert Emacs to a truly
>CommonLisp implementation. This would need someone with deep
>knowledge of Emacs internals. All the Elisp packages would also need
>translation, but these are tasks that can be easily accomplished by
>other CommonLisp programmers like myself.
Have you looked into Hemlock? (comes with CMUCL.)
>If we could manage to implement this sort of Lisp Machine, then we
>could start thinking about was is bad in our implementation that could
>be better if we had the _right_ operating system.
>Maybe then, we can start thinking about the _right_ operating system.
>By then, we will know what we want and we will have the tools to