creation of lisp machine/lispOS

202 views
Skip to first unread message

Richard Coleman

unread,
Apr 20, 1997, 3:00:00 AM4/20/97
to

I hear many people on this group talk fondly about
the days of the lisp machine. About how flexible and
powerful they were. So now that machines have gotten
fast enough, why isn't anyone working on a LispOS.

It seems like all the pieces are there to use. Starting
with FreeBSD, or Linux (or maybe even the Hurd 0.2 when
it comes out) and a common Lisp implementation like CMU,
it seems you should have the pieces to start developing
a dedicated Lisp box.

I surprised there aren't any groups doing something like
this.

Richard Coleman
col...@math.gatech.edu

Kelly Murray

unread,
Apr 21, 1997, 3:00:00 AM4/21/97
to

I put out a call for such a thing on usenet a couple years ago,
when I was working at the University of Florida.
I was amazed how fanatical, and hard-working, the Linux community
could be about a clone of 25-year old technology.
Imagine what such an effort put towards a Lisp-based system could be!?

While many came forward to offer their assistance,
there were not enough that I felt the job was doable, or the user-base
would be large enough, for me to personally commit the effort needed
to build such a system.
It looked to me like lot of the Lisp community had become
"Burned out, broke, and bitter".

What I did was start a company building X-terminals,
with my long-term plan being to "sneak in" a Lisp machine running
in the terminal in which applications could send down high-level
Lisp source to run locally on a diskless (or disk-cache-only) client machine.
Hmm, kinda sounds like JAVA or a Web Terminal doesn't it?
Oh well, no capitol to carry it through.

In the current state of the world, Lisp under Linux is the obvious
way to go as a "Lisp Machine". Franz has now made it's Lisp available
for free on this platform (ACL comes up and runs in only 3mb,
and I've even run it on one of my 8mb 386 machines (Kudos Duane!)

I believe Lisp has a lot of potential in the form
of Web applications executed from the Server side.
While it isn't a requirement, or necessarily even a goal,
it is viable today that an entire machine can be dedicated to running
a Web application(s) and the machine(s) could be Lisp-only.


-Kelly Murray k...@franz.com http://www.franz.com
..working to keep the faith alive

P.S.

I'll note that I've used many Lisp implementations
from a primitive CDC "batch" implementation, to Symbolics 3600 and beyond,
studied many of them, and been directly involved with a few implementations,
but primarily, implemented a shared-memory parallel Common Lisp
almost entirely myself, which was ported to 4 different parallel processor machines
(i386, sparc, NS32, 88K).
Of course, now I work at Franz, in which my current effort, in conjuction with
the other highly talented people here, will end any "Lisp is too big" or
"startup is too slow" objections.


Andreas Eder

unread,
Apr 21, 1997, 3:00:00 AM4/21/97
to

Yes, why don't we build a LispOS on Intel Hardware?
It may not be the best for the purpopse, but it is widely
available. See how LINUX spread around.
I would wholeheartedly support such an endeavour!

Andreas Eder NetWorker (ReliantUnix)
SNI AG Phone: +49-89-636-42549
OEC HES XP 2 Fax: +49-89-636-40601
D-81739 Munich, Germany

EMail: mailto:Andrea...@mch.sni
for public access: http://www.sni.de/public/mr/nsr/nsr_en.htm
for SNI personnel only: http://athen.mch.sni.de/networker/welcome.htm

---
Is "Windows for Dummies" another case of "this sentence no verb?"

Richard Coleman

unread,
Apr 21, 1997, 3:00:00 AM4/21/97
to

Andreas Eder <a...@laphroig.mch.sni.de> writes:
> Yes, why don't we build a LispOS on Intel Hardware?
> It may not be the best for the purpopse, but it is widely
> available. See how LINUX spread around.
> I would wholeheartedly support such an endeavour!

In order for a project like this to get started and
succeed, the important thing is to not get overly
ambitious. Start with something like Linux and CMU CL
and achieve some small goals. Then build on the success.

What do people think would be a good starting point?
What would we try to achieve with such a machine?

The place to start is have someone create a mailing list
and discuss this.

Richard Coleman
col...@math.gatech.edu

Moribund

unread,
Apr 21, 1997, 3:00:00 AM4/21/97
to


Richard Coleman <col...@math.gatech.edu> wrote in article
<rc4td0l...@redwood.skiles.gatech.edu>...

Linux is a good start...ditto on CMU CL....

Some goals? Figure out a standard configuration -- something that will be
available (almost automatically) on all future PCs. Keep them generic
enough so that platform really doesn't play a role (such as XX megs of ram,
XXX megs of HD space, blah, blah, blah...). This will ensure that you are
able to put together 68K machines as well as x86.
From there, work towards a specific implementation on one platform
(writing as much code in lisp as possible), then move it to another (68K,
Alpha, etc). Eventually, you would get to a 100% lisp box (which come with
installed web servers, development tools, etc -- all written in lisp).
This would provide me with another wonderful excuse to install Linux on a
spare box and use it for development....
I'm all for a mailing list, and if my provider let me create one, I would
do so in a heartbeat.

Damo

Hannes Haug

unread,
Apr 21, 1997, 3:00:00 AM4/21/97
to

Hi

Richard Coleman <col...@math.gatech.edu> writes:

> It seems like all the pieces are there to use. Starting
> with FreeBSD, or Linux (or maybe even the Hurd 0.2 when
> it comes out) and a common Lisp implementation like CMU,
> it seems you should have the pieces to start developing
> a dedicated Lisp box.

The University of Utah's OS Toolkit is perhaps better.
Olin Shivers uses it for his "ML-Machine":
http://www.ai.mit.edu/projects/express/
http://www.cs.utah.edu/projects/flux/oskit/html/testimonials.html

-hh

Martin Cracauer

unread,
Apr 21, 1997, 3:00:00 AM4/21/97
to

Richard Coleman <col...@math.gatech.edu> writes:

>I hear many people on this group talk fondly about
>the days of the lisp machine. About how flexible and
>powerful they were. So now that machines have gotten
>fast enough, why isn't anyone working on a LispOS.

>It seems like all the pieces are there to use. Starting


>with FreeBSD, or Linux (or maybe even the Hurd 0.2 when
>it comes out) and a common Lisp implementation like CMU,
>it seems you should have the pieces to start developing
>a dedicated Lisp box.

To be useful, be need some kind of working environment that goes
bejond manipulating the system itself.

This starts with tools to navigate on their systems, look around, move
things (usually files) etc.

Windows people use their explorer to manipulate the file system and
things like word and excel as applications to produce something.

Unix people have their shell, the file manipulating 2-characters
commands and do "real" things they use expensive commercial apps,
SGML or TeX, all kinds of networking tools.

With current Lisp systems we have emacs/hemlock diredit mode for file
system work. This even wasn't enough for symbolics, they did their
command processor (for a good reason, I think). Not to speak of real
applications for (free) Lisp systems.

Currently, we should build such a systemn quite easily by integrating
CMUCL in the FreeBSD kernel, using their process management to
manipulate Lisp threads, probably a weekend of work :-)

But currently, people would even have something to explore the file
system with. Scsh isn't an answer, it is oriented towards writing
scripts, not poking around.

If we start to use normal Unix tools besides Lisp for such things, we
don't gain much. The point about a pure Lisp machine would be that you
don't need to learn or to use a command language such the Unix shell
and its basic tools or don't have to use a non-extensible,
time-consuming thing like Windows explorer.

The very least is a free CLIM implementation (see
http://www.cons.org/free-clim), to base some interactive command on
before everything ends up as emacs code (or a Common Lisp emacs clone,
for that matter) and innocent people are forced into the minibuffer.

Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin_...@wavehh.hanse.de http://cracauer.cons.org Fax.: +4940 5228536
"As far as I'm concerned, if something is so complicated that you can't ex-
plain it in 10 seconds, then it's probably not worth knowing anyway"- Calvin

Alexey Goldin

unread,
Apr 22, 1997, 3:00:00 AM4/22/97
to

d...@world.std.com (Jeff DelPapa) writes:
>
> I am going to disagree with the Linux and CMU as a starting point. I
> think taking a lisp core, and replacing the few services that it asks
> of the OS (so it runs standalone) is a better way to go. The
> important step is to make paging and GC two facets of the same code.
>
> Disks get faster much more slowly than the rest of the hardware does.
> (they have gotten a lot cheaper, and hold a lot more, but the average
> seek time took a decade to come down by a factor of 2). Yes, you can
> throw ram at the problem, but here is a place where clever wins over
> CPU horsepower. Build a GC that first checks to see if following a
> chain will result in a page fault, and if it will trigger a fault,
> sets it aside and looks at the next chain. Only when all of the ram
> resident stuff has been groveled over, and it still needs more space,
> will it go to stuff on the disk. For large problems a GC that avoids
> looking at things that triger a disk action, wins big.
>

OTOH beginning with Linux and replacing incrementally one kernel
service by another with Lisp code may be easier. The first step could
be to modify kernel and to teach swapper and GC to talk to each
other. Even Emacs would benefit from this. This also may get other
non-Lisp folks interested and there are a lot of them.

Bill Gooch

unread,
Apr 22, 1997, 3:00:00 AM4/22/97
to

Kelly Murray wrote:

> ....


> While many came forward to offer their assistance,
> there were not enough that I felt the job was doable, or the user-base
> would be large enough, for me to personally commit the effort needed
> to build such a system.
> It looked to me like lot of the Lisp community had become

> "Burned out, broke, and bitter"....

How about "busy earning a good income to support
my family."

Sounds to me like you're the bitter one. The thing
to recognize here is that the Great Jihad isn't about
Lisp itself, but about improving the technology of
software development. The answer isn't Lisp, or TCL,
nor any language, it's "keep innovating." Success
isn't a destination, it's a journey.

> ....


> Of course, now I work at Franz, in which my current effort, in conjuction with
> the other highly talented people here, will end any "Lisp is too big" or
> "startup is too slow" objections.

I certainly hope you're right. I'd love to have good,
interesting, *paying work* doing Lisp again. But it
does sound suspiciously like you're thinking that the
solution to Lisp's woes is a technological one - if so,
I'm afraid all your good work may be in vain. Lisp
technology has been way ahead of popular alternatives
for many years. Putting it further ahead by itself
won't secure the market.

~~~~~~~~~~~~~~~~~~~~~~
Bill Gooch goo...@flash.net

Richard Coleman

unread,
Apr 22, 1997, 3:00:00 AM4/22/97
to

> It would be easy to just adopt the Linux kernel (did I spell that
> right?) and add CMUCL, but I wonder if that might be a cop-out that
> could undermine any chance of being a myth-killer? Does WINE undermine
> the advanatages of Linux? I don't think so. However, I can't help
> wondering what kind of compromises we'd be making, i.e. how different
> would such an OS be from what we have _already_? What would we be
> accomplishing? The result might be a Lisp "distribution" of Linux, and
> that could be good, but is that _all_ we want?

This may not be _all_ we want, but it might be a good place to start.
There is a big danger in making plans that are too ambitious. It would
be better to start small and have some small successes. Basically a
minimal Linux distribution with built-in Lisp, and lots of nice
Lisp utilities pre-installed. This would be nice to have to get started.
Once that's done, more ambitious projects like tailoring the VM to
get better Lisp performance would have a greater chance of succeeding.

Richard Coleman
col...@math.gatech.edu

Henry Baker

unread,
Apr 22, 1997, 3:00:00 AM4/22/97
to

I think that this basic idea is a terrific one!

I would gently suggest the use of Scheme's continuations and
tail-recursions as a basis, rather than any threading built into
a Common Lisp environment. I think that you'll find it much more
elegant, much smaller, and much easier to implement.

Feel free to add many other Common Lispisms if you wish, but if you're
going down to the bare hardware and want to talk to devices, etc., you
will need some model of a process, and continuations are a heck of a
lot simpler than the stack groups of the old Lisp Machines.

Kelly Murray

unread,
Apr 22, 1997, 3:00:00 AM4/22/97
to

In article <335CB8...@flash.net>, Bill Gooch <goo...@flash.net> writes:
>> Kelly Murray wrote:
>>
>> > ....
>> > While many came forward to offer their assistance,
>> > there were not enough that I felt the job was doable, or the user-base
>> > would be large enough, for me to personally commit the effort needed
>> > to build such a system.
>> > It looked to me like lot of the Lisp community had become
>> > "Burned out, broke, and bitter"....
>>
>> How about "busy earning a good income to support
>> my family."

Me too, but I still haven't given up on the vision.

>>
>> Sounds to me like you're the bitter one.

Certainly on some days I am, it is hard not to be,
but I'm not a just a complainer. I've always been a do-er,
and I'll keep doing what it takes.

>>The thing to recognize here is that the Great Jihad isn't about
>> Lisp itself, but about improving the technology of
>> software development. The answer isn't Lisp, or TCL,
>> nor any language, it's "keep innovating." Success
>> isn't a destination, it's a journey.

But it IS about Lisp in the broader sense.
How can one innovate without taking chances
and trying something different?
..and going beyond "busy earning a good income"?

>>
>> > ....
>> > Of course, now I work at Franz, in which my current effort, in conjuction with
>> > the other highly talented people here, will end any "Lisp is too big" or
>> > "startup is too slow" objections.
>>
>> I certainly hope you're right. I'd love to have good,
>> interesting, *paying work* doing Lisp again. But it
>> does sound suspiciously like you're thinking that the
>> solution to Lisp's woes is a technological one - if so,
>> I'm afraid all your good work may be in vain. Lisp
>> technology has been way ahead of popular alternatives
>> for many years. Putting it further ahead by itself
>> won't secure the market.

Put your suspicions to rest.
It is not Lisp *technology* that needs innovation,
but the application of that technology.

A new Lisp machine itself would be useless.
But give that machine a purpose that creates enourmous value,
and you've got something the world just might notice.
As I've said, in my view that purpose is a platform
for a WEB server. I have lots to say about it,
but in short, the people interacting on the Internet don't care one aota
what system or language is on the other end of the wire.
And therefore, all the old interoperability constraints
with the non-lisp world are gone, history. Think about that.


-kelly murray (speaking for myself)

Rodrigo Ventura

unread,
Apr 22, 1997, 3:00:00 AM4/22/97
to

>>>>> "Andreas" == Andreas Eder <a...@laphroig.mch.sni.de> writes:

Andreas> Yes, why don't we build a LispOS on Intel Hardware? It
Andreas> may not be the best for the purpopse, but it is widely
Andreas> available. See how LINUX spread around. I would
Andreas> wholeheartedly support such an endeavour!

Hi there. I loved your idea. I've been thinking about that a
while ago. Here in the AIMS Labs in my University (ISR/IST, Lisbon)
there is an old Lisp Machine (Unisys) and still have all software and
documentation. I've tried it a couple of times and the environment
seemed quite mature to the time, although it's very different from the
current X/windows/mac paradigm. But at that time it had networking
(ethernet), SCSI disks, graphics, mouse, multitasking, paging, etc.

But I'd like to know if there is already a mailling list. If
not I could create one. I'm really entusiastic about the
idea. Starting with the linux kernel and replacing the /sbin/init with
a LISP interpreter/VM/compiler/whatever. We could replace the usual
UNIX shell/environment with a layer of LISP. Still the windowing
system must be X11R6 fully compilant. We could use exactly the same
server and replace the clients for CLX+whatever. Mixing LISP code and
C-based traditional apps is even a greater idea.

PLEASE, keep in touch.

Regards,


Cyber Surfer

unread,
Apr 22, 1997, 3:00:00 AM4/22/97
to

With a mighty <m3u3l01...@laphroig.mch.sni.de>,
a...@laphroig.mch.sni.de uttered these wise words...

> Yes, why don't we build a LispOS on Intel Hardware?

> It may not be the best for the purpopse, but it is widely


> available. See how LINUX spread around.

I've sometimes wondered about this. It might be better to do this than
to merely work from within an existing OS community, as there are more
programmers not using Lisp, making our efforts a minority.

Working with an non-Lisp OS also makes it necessary to compromise.
Whether this is a good thing or not may be debatable, as some people
argue that compromise is a good thing. Perhaps a better word would be
progamatism.

At least, by creating and using a Lisp OS, we could see how well Lisp
can perform without any of the compromises (distinct from pragmatism)
imposed on us by C/C++ programmers. I know this has been done with
Lisp machines, but if they're only available to people with loads of
money, then it proves nothing except what can be done when you throw
enough money at a problem.

How much does Linux cost? A good quality LispOS available for the
_same_ machines would be a powerful myth-killer. By "good quality" I
mean something efficient and easy to use, but if your definition means
something different, that's fine with me. All that's necessary for a
LispOS to be a myth-killer is that it should do useful things and be
available to anyone who wants it.

We know that Lisp machines can do useful things, but who can use them?
We also know that Linux machines can do useful things, but who can use
them? Technically, anyone with the right hardware can use Linux, so
Linux people have made sure that Linux is available for popular and,
in general, _cheap_ machines. If we were to create a LispOS, then we
should also make it run on popular and cheap machines.

It would be easy to just adopt the Linux kernel (did I spell that
right?) and add CMUCL, but I wonder if that might be a cop-out that
could undermine any chance of being a myth-killer? Does WINE undermine
the advanatages of Linux? I don't think so. However, I can't help
wondering what kind of compromises we'd be making, i.e. how different
would such an OS be from what we have _already_? What would we be
accomplishing? The result might be a Lisp "distribution" of Linux, and
that could be good, but is that _all_ we want?

There should also be a lot of other reasons for creating a LispOS,
besides myth-killing. I'm only emphasising myth-killing because this
is one of things that Linux does, for Unix. Lisp could use little of
this, too, as some of us have noticed.

> I would wholeheartedly support such an endeavour!

So would I.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Programmer and Information Broker | London, UK
Please note: my email address is gubbish.

Arun Welch

unread,
Apr 22, 1997, 3:00:00 AM4/22/97
to

Andreas Eder <a...@laphroig.mch.sni.de> writes:
> Yes, why don't we build a LispOS on Intel Hardware?
> It may not be the best for the purpopse, but it is widely
> available. See how LINUX spread around.
> I would wholeheartedly support such an endeavour!

Well, once possible starting point would be to contact Venue and see
if they'll release the sources to Medley to you for a Linux port. Given
that the virtual machine has already been ported to most other Unixes
out there it shouldn't be *too* hard to port :-). There, you're done.

...arun

Mike McDonald

unread,
Apr 22, 1997, 3:00:00 AM4/22/97
to

In article <5jet1p$7b8$1...@sparky.franz.com>,
k...@math.ufl.edu (Kelly Murray) writes:

> I put out a call for such a thing on usenet a couple years ago,
> when I was working at the University of Florida.
> I was amazed how fanatical, and hard-working, the Linux community
> could be about a clone of 25-year old technology.
> Imagine what such an effort put towards a Lisp-based system could be!?
>

> While many came forward to offer their assistance,
> there were not enough that I felt the job was doable, or the user-base
> would be large enough, for me to personally commit the effort needed
> to build such a system.
> It looked to me like lot of the Lisp community had become
> "Burned out, broke, and bitter".

I well remember that thread. Unfortunately, I was one of the prime naysayers
at the time and I guess it's my turn again. (Don't get me wrong, I'd love to
have a PC "LispM". I just think people aren't realisticly looking at the size
of the task.)

Things you want in a LispOS:
- Multiple tasks
- IPC
- device drivers
- windowing system
- file system(s) (probably three: iso9660, msdos, and "native" fs)
- utility apps (cat, more, ls, mail, news, tar, ...)

I can imagine two approaches to building a LispOS, write everything in Lisp
ala Genera or mix a foreign kernel with a Lisp core ala Linux/CMUCL. The former
would give you a "truer" LispOS but at a much bigger cost of implementation.
You'd need to write/find a lisp system to base it upon. Some of the key criteria
for selection would be support for multiple threads and native compilation.
CMUCL has the later but not the former. GCL has neither. CLisp sort of has the
later (counting byte codes). Since I don't know of any good basis to build
upon, we'd probably have to start from scratch, no small task. (I'll talk
about ACL in a minute!)

If you went the mixed mode way, you have a lot more choices for which lisp
implementation you used. You'd also get all of those utility apps for free.
But this approach defeats the whole advantage of a LispOS in the first place,
ie the tight coupling of the OS and all the "apps". This approach leads you
to where we're at today.

Now, if I were to attempt building a PC LispM, I think I would investigate
what is the minimal support ACL requires of Linux, ie what syscalls,
libraries, ... If there was a realitively small set, I'd attempt to build a
modified version of linux that only supported those minimal requirements.
(Think of Linux as the FEP.) You'd probably start out with the FS support and
networking support left in the Linux kernel. Over time, one could migrate
these into the lisp image. This approach would have an advantage in that apps
people could start writing the apps under the current configuration while the
kernel types were doing their magic. It has the disadvantage of being reliant
on the Franz limited license and no source code for the code system.

Add a windowing system to all of these problems and I think you'll have
your hands full. (Who's going to write the lisp version of WINE?)

Mike McDonald
mik...@engr.sgi.com

Cyber Surfer

unread,
Apr 23, 1997, 3:00:00 AM4/23/97
to

With a mighty <rc67xfv...@redwood.skiles.gatech.edu>,
col...@math.gatech.edu uttered these wise words...

> This may not be _all_ we want, but it might be a good place to start.
> There is a big danger in making plans that are too ambitious. It would
> be better to start small and have some small successes. Basically a
> minimal Linux distribution with built-in Lisp, and lots of nice
> Lisp utilities pre-installed. This would be nice to have to get started.
> Once that's done, more ambitious projects like tailoring the VM to
> get better Lisp performance would have a greater chance of succeeding.

It would also allow us to leaverage all the hardware compatibility
work that's been done for Linux. I've thought about this a lot over
the last 6 months, and I like the idea. It could mean that it needn't
be Lisp-only, which should widen the interest.

Using Linux would also mean including a C compiler, but it could also
include X Windows, Tk, etc. That might not be bad, either. It would
mean that we could include Lisp to C compilers, STk, etc.

However, I think we should take care, and limit the list to Lisp, plus
a few a Lisp-like languages, a few functional languages,and very
little else. If we go too far, we'll have just another Linux, with a
stropng bias for Lisp and other high level languages. If we _don't_ do
this, we lose all the hardware compatibility work.

Christopher Oliver

unread,
Apr 23, 1997, 3:00:00 AM4/23/97
to

Bill Gooch (goo...@flash.net) wrote:
: The thing to recognize here is that the Great Jihad isn't

: about Lisp itself, but about improving the technology of
: software development. The answer isn't Lisp, or TCL,
: nor any language, it's "keep innovating."

How is it that I can't avoid thinking about the final bleak
chapter "Money Through Innovation Reconsidered" in Gabriel's
"Patterns of Software?"

"The second problem is in thinking that innovation causes
the world to improve for consumers...

"My thesis is simple: Invention, radical innovation, and great
leaps forward do not produce revenue commensurate with the req-
uired effort in the software industry, and invention usually
doesn't work in and industry."

--
Christopher Oliver Traverse Communications
Systems Coordinator 223 Grandview Pkwy, Suite 108
oliver@<DELETE>traverse.com Traverse City, Michigan, 49684
Hi. You have just entered the fourth dimension. Small isn't it?

William Paul Vrotney

unread,
Apr 23, 1997, 3:00:00 AM4/23/97
to

In article <1997Apr21.1...@wavehh.hanse.de> crac...@wavehh.hanse.de

(Martin Cracauer) writes:
>
> Richard Coleman <col...@math.gatech.edu> writes:
>
> >I hear many people on this group talk fondly about
> >the days of the lisp machine. About how flexible and
> >powerful they were. So now that machines have gotten
> >fast enough, why isn't anyone working on a LispOS.
>
> >It seems like all the pieces are there to use. Starting
> >with FreeBSD, or Linux (or maybe even the Hurd 0.2 when
> >it comes out) and a common Lisp implementation like CMU,
> >it seems you should have the pieces to start developing
> >a dedicated Lisp box.
>
> To be useful, be need some kind of working environment that goes
> bejond manipulating the system itself.
>
> This starts with tools to navigate on their systems, look around, move
> things (usually files) etc.
> ...

> But currently, people would even have something to explore the file
> system with. Scsh isn't an answer, it is oriented towards writing
> scripts, not poking around.
>

Around 1984 I was developing something called "Operating Objects". The
basic idea was to replace the standard file system with smaller objects with
unlimited attributes so that a more dynamic and explicit structure could be
represented on disk. The motivation was to attack the Unix flat file
database parsing bottleneck. The OS was Lisp based since Cons and
dynamically typed objects were integral to the OS. It appeared that there
could be a flexible and extensible functionality for traversing secondary
storage. I eventually gave up since I could not convince anyone of the
merit of the idea and it seemed the standard file system was now cast in
concrete.

This idea may be too far out for your LispOS, but now I am wondering if
anyone else has done any work along these lines since then. I still have my
notes from that project.

--

William P. Vrotney - vro...@netcom.com

Rainer Joswig

unread,
Apr 23, 1997, 3:00:00 AM4/23/97
to

In article <vrotneyE...@netcom.com>, vro...@netcom.com (William Paul
Vrotney) wrote:

> This idea may be too far out for your LispOS, but now I am wondering if
> anyone else has done any work along these lines since then. I still have my
> notes from that project.

Newton OS???

--
http://www.lavielle.com/~joswig/

David Hanley

unread,
Apr 23, 1997, 3:00:00 AM4/23/97
to

William Paul Vrotney wrote:
>
> Around 1984 I was developing something called "Operating Objects". The
> basic idea was to replace the standard file system with smaller objects with
> unlimited attributes so that a more dynamic and explicit structure could be
> represented on disk.
[snip]

> This idea may be too far out for your LispOS, but now I am wondering if
> anyone else has done any work along these lines since then. I still have my
> notes from that project.

If you look at the journal for the last POS( persistent object store )
conference, you will see seeral idead which are somewhat similar to
this.

The basic idea id not to use files, but to create data structures which
can be linked to some persistent space. Another
program run will access the data structure via the system in some
manner.

This idea is very powerful, and I'd like to see it realized. For
example, a 'file(a)' could have a pointer to data in another 'file', (b)
but this would be transparent to the user of a. Of course 'file' is the
wrong word here...

dave

Kelly Murray

unread,
Apr 23, 1997, 3:00:00 AM4/23/97
to

In article <vrotneyE...@netcom.com>, vro...@netcom.com (William Paul Vrotney) writes:
>> Around 1984 I was developing something called "Operating Objects". The
>> basic idea was to replace the standard file system with smaller objects with
>> ..

>> This idea may be too far out for your LispOS, but now I am wondering if

On the contrary, it sounds the same as my approach,
which is to have only an object system, where objects can be persistent.
A "gif file" doesn't exist, but a persistent graphics gif object does.

-Kelly Murray (speaking for myself


David Hanley

unread,
Apr 23, 1997, 3:00:00 AM4/23/97
to

I have a feeling people might react badly to this in light of pervious
discussiuons, but why not construct this lisp OS on the java VM? Then
you're not tied to any platform. You also get a windowing system,
filesystem abstraction, networking, system garbage collection, etc.

dave

Reginald Perry

unread,
Apr 23, 1997, 3:00:00 AM4/23/97
to

hba...@netcom.com (Henry Baker) writes:

> I think that this basic idea is a terrific one!
>
> I would gently suggest the use of Scheme's continuations and
> tail-recursions as a basis, rather than any threading built into
> a Common Lisp environment. I think that you'll find it much more
> elegant, much smaller, and much easier to implement.
>

I actually like this idea! It seems that people were looking at the
problem backwards as it were. While I agree that it would be nice to
be able to easily port key device drivers from Linux/BSD land, It
seems that some people were advocating building up from assembler to C
and then put Lisp on top of that. I would advocate that the way to
build is assembler to a scheme subset to Common Lisp.

Maybe this is implicitly known and so is not mentioned but the C
runtime is ingrained in the Unix kernel. This is why it seems to me
that its tricky to build other languages incompatible with C on top of
Unix. Blow the signal semantics and use exception semantics in the
kernel and make continuations and lambda dirt cheap. This would make
for a very interesting system.

-Reggie


Reginald Perry

unread,
Apr 23, 1997, 3:00:00 AM4/23/97
to

William Paul Vrotney

unread,
Apr 23, 1997, 3:00:00 AM4/23/97
to

In article <335E3B...@nospan.netright.com> David Hanley
<da...@nospan.netright.com> writes:

>
> William Paul Vrotney wrote:
> >
> > Around 1984 I was developing something called "Operating Objects". The
> > basic idea was to replace the standard file system with smaller objects with
> > unlimited attributes so that a more dynamic and explicit structure could be
> > represented on disk.
> [snip]
> > This idea may be too far out for your LispOS, but now I am wondering if
> > anyone else has done any work along these lines since then. I still have my
> > notes from that project.
>
> If you look at the journal for the last POS( persistent object store )
> conference, you will see seeral idead which are somewhat similar to
> this.
>
> The basic idea id not to use files, but to create data structures which
> can be linked to some persistent space. Another
> program run will access the data structure via the system in some
> manner.
>
> This idea is very powerful, and I'd like to see it realized. For
> example, a 'file(a)' could have a pointer to data in another 'file', (b)
> but this would be transparent to the user of a. Of course 'file' is the
> wrong word here...
>

Even though we are suggesting a sort of "fileless" operating system here the
term "file" still appears necessary. There is still the need for a file
data type if you will. There is still a need for the concept of an "untyped
block of bytes" with accessing constraints.

Georg Bauer

unread,
Apr 23, 1997, 3:00:00 AM4/23/97
to

Hi!

AW> Well, once possible starting point would be to contact Venue and see
AW> if they'll release the sources to Medley to you for a Linux port.

Actually I had a conversation with someone at Venue that did exactly that.
But then - the Medley-Version isn't that much stable. Too bad, it is just
so nice to have a portable 1186 ... but it crashes far to often (try to
compile Screamer or Series for example). Ok, I used the DOS-version ...

bye, Georg

Bill House

unread,
Apr 24, 1997, 3:00:00 AM4/24/97
to

David Hanley <da...@nospan.netright.com> wrote in article
<335E3B...@nospan.netright.com>...

>
> This idea is very powerful, and I'd like to see it realized. For
> example, a 'file(a)' could have a pointer to data in another 'file', (b)
> but this would be transparent to the user of a. Of course 'file' is the
> wrong word here...
>

Why not just support storing object closures? That's what our Lisp VM does.

Bill House
--
http://www.dazsi.com
Note: my e-mail address has been altered to
confuse the enemy. The views I express are
mine alone (unless you agree with me).


Lyman S. Taylor

unread,
Apr 24, 1997, 3:00:00 AM4/24/97
to

In article <335E3F...@nospan.netright.com>,


David Hanley <da...@nospam.netright.com> wrote:
>I have a feeling people might react badly to this in light of pervious
>discussiuons, but why not construct this lisp OS on the java VM?

^^^
Well if you're going to run the OS on top of a virtual machine anyway,
why not build it on top of Emacs or more accurrately elisp? ;-)

It is just as pervasive... if not more so.... than the Java VM. :-)

[ Java OS isn't written in 100% java. There are some things at the
low level "nitty gritty" layer that will not pass through
the JVM ]



>you're not tied to any platform. You also get a windowing system,
>filesystem abstraction, networking, system garbage collection, etc.

"filesystem abstraction" ... eehhhh???

"system garbage collection" ... chuckle. compared with the GC in
any commerical ( or serious) CL implementation
the GC of Java is a prehistoric.
Let alone the performance increases gained by
merging the virtual memory with GC in the
way it was done on the Symbolics lisp machines.
Go ahead and give the Java VM a large address
space to do GC on and watch the performance.


As far a ubiquitous windowing system goes CLIM serves that role, too.
[ Java's AWT isn't as a windowing system but a common abstraction
to N different variations of a "native" windowing system. ]
But perhaps CLIM is the "correct" solution.



--

Lyman S. Taylor "I'm a Doctor, not a doorstop... "
(ly...@cc.gatech.edu) The EMH Doctor in "Star Trek: First Contact".

Chris Bitmead uid(x22068)

unread,
Apr 24, 1997, 3:00:00 AM4/24/97
to

vro...@netcom.com (William Paul Vrotney) writes:

> Even though we are suggesting a sort of "fileless" operating system here the
> term "file" still appears necessary. There is still the need for a file
> data type if you will. There is still a need for the concept of an "untyped
> block of bytes" with accessing constraints.

In Lisp Machine nirvana, everything would be a typed object and
untyped blocks of bytes would be banished from the face of the earth.


Bill House

unread,
Apr 24, 1997, 3:00:00 AM4/24/97
to

Lyman S. Taylor <ly...@cc.gatech.edu> wrote in article
<5jmsa3$c...@pravda.cc.gatech.edu>...

>
>As far a ubiquitous windowing system goes CLIM serves that role, too.
>[ Java's AWT isn't as a windowing system but a common abstraction
>to N different variations of a "native" windowing system. ]
>But perhaps CLIM is the "correct" solution.
>
One thing that might be nice to borrow from Java is the peer component concept for
interfacing to external systems, like X, etc. We've got a C function interface from
within our VM, but an object-level interface is also needed.

Bill House

unread,
Apr 24, 1997, 3:00:00 AM4/24/97
to

David Hanley <da...@nospan.netright.com> wrote in article
<335E3F...@nospan.netright.com>...

>
> I have a feeling people might react badly to this in light of pervious
> discussiuons, but why not construct this lisp OS on the java VM? Then

> you're not tied to any platform. You also get a windowing system,
> filesystem abstraction, networking, system garbage collection, etc.
>
> dave
>
Well, for one thing, the bytecode VM architecture is outdated for modern hardware.

FWIW, our Lisp VM uses a 32-bit instruction set. This allows us to perform many
operations in a single VM instruction, rather than having to PUSH, PUSH, ADDI, MOV.
Performance is quite good, and without having to resort to JIT, although we are in the
process of adding native compilation.

What's wrong with Linux?

Chris Bitmead uid(x22068)

unread,
Apr 24, 1997, 3:00:00 AM4/24/97
to

Bill Gooch <goo...@flash.net> writes:

> Sounds to me like you're the bitter one. The thing


> to recognize here is that the Great Jihad isn't about
> Lisp itself, but about improving the technology of
> software development. The answer isn't Lisp, or TCL,

> nor any language, it's "keep innovating." Success
> isn't a destination, it's a journey.

But how can we move beyond lisp when nobody is interested in catching
up to lisp? Lisp was the second programming language devised. Now here
in 1997 Ousterhout is debating with himself whether we should be using
C++ or TCL. Is technology moving backwards?

So, until the world catches up with the innovations that were made 30
years ago we might as well keep fighting for Lisp, or whatever your
favourite language is.

As I write this I wait for C++ to link (a 2 hour wait). I've got
nothing to lose by fighting the Jihad, and I've got my sanity to gain.

Chris Bitmead uid(x22068)

unread,
Apr 24, 1997, 3:00:00 AM4/24/97
to

vro...@netcom.com (William Paul Vrotney) writes:

> Around 1984 I was developing something called "Operating Objects". The
> basic idea was to replace the standard file system with smaller objects with
> unlimited attributes so that a more dynamic and explicit structure could be

> represented on disk. The motivation was to attack the Unix flat file
> database parsing bottleneck. The OS was Lisp based since Cons and
> dynamically typed objects were integral to the OS. It appeared that there
> could be a flexible and extensible functionality for traversing secondary
> storage. I eventually gave up since I could not convince anyone of the
> merit of the idea and it seemed the standard file system was now cast in
> concrete.

It's very much about time that someone destroyed the myth that the
UNIX byte stream is the ultimate in file system technology. I've been
thinking along the same lines myself. What's needed is a standard
format for storing objects in files. Actually it's probably an object
database I want, except integrated with the OS, so that it is the
standard way of storing stuff. UNIX ascii files are much too
primitive, and are the source of endless headaches.

> This idea may be too far out for your LispOS, but now I am wondering if
> anyone else has done any work along these lines since then. I still have my
> notes from that project.
>
>
>

Holger Schauer

unread,
Apr 24, 1997, 3:00:00 AM4/24/97
to

>>"DH" == David Hanley schrieb am Wed, 23 Apr 1997 11:40:50 -0500:

DH> William Paul Vrotney wrote:
>> Around 1984 I was developing something called "Operating
>> Objects". The basic idea was to replace the standard file system
>> with smaller objects with unlimited attributes so that a more
>> dynamic and explicit structure could be represented on disk.

DH> [snip]


>> This idea may be too far out for your LispOS, but now I am
>> wondering if anyone else has done any work along these lines since
>> then. I still have my notes from that project.

DH> The basic idea id not to use files, but to create data
DH> structures which can be linked to some persistent space. Another
DH> program run will access the data structure via the system in some
DH> manner.

I think the BeOS supports something along these lines, and I would
like to have it everywhere, too. A report over BeOS, that I saw, said
that BeOS would allow to store e.g. an address only once on disk and
any other application using this address would see any changes made by
any app. This would greatly simplify things for e-Mail-programs,
word- or text-processors etc. Companies are probably not very
likely to support such an approach as it would inhibit major reasons
for doing so-called upgrades to newer versions (in which a new
propietary file-format is used). OTOH: who would want such programs in
a free environment ?-)

Holger

David Hanley

unread,
Apr 24, 1997, 3:00:00 AM4/24/97
to

Lyman S. Taylor wrote:
>
> In article <335E3F...@nospan.netright.com>,
> David Hanley <da...@nospam.netright.com> wrote:
> >I have a feeling people might react badly to this in light of pervious
> >discussiuons, but why not construct this lisp OS on the java VM?
> ^^^
> Well if you're going to run the OS on top of a virtual machine anyway,
> why not build it on top of Emacs or more accurrately elisp? ;-)
>
> It is just as pervasive... if not more so.... than the Java VM. :-)

I suppose that's possible, but I suspect that it's much more possible
to build acceptably performing applications in a java VM as opposed to
the elisp VM. Most java Vm's are going to JIT comple code to binary
executable objects, which elisp does not do. Elsip has some other
restrictions, such as depth of recusrsion stack, and the like..

>
> [ Java OS isn't written in 100% java. There are some things at the
> low level "nitty gritty" layer that will not pass through
> the JVM ]

Certianly. I think this is a fair approach. Most OS's written ic C,
for example, use some assembler subroutines. I don't think this means
that C is not good for writing operating systems, though some other
facts might. :)

>
> >you're not tied to any platform. You also get a windowing system,
> >filesystem abstraction, networking, system garbage collection, etc.
>

> "filesystem abstraction" ... eehhhh???

True. It is possible to write code that will interact with the
filesystem on widely divergent operating systems.

>
> "system garbage collection" ... chuckle. compared with the GC in
> any commerical ( or serious) CL implementation
> the GC of Java is a prehistoric.

On what are you basing that claim? What in the VM restricts java from
employing the same garabge collection technology? Have you benchmarked
the GC on all available systems, as opposed to all available lisp VM's?


> Let alone the performance increases gained by
> merging the virtual memory with GC in the
> way it was done on the Symbolics lisp machines.

Again, do any lisp syatems avaialbe now do this?

> Go ahead and give the Java VM a large address
> space to do GC on and watch the performance.
>

> As far a ubiquitous windowing system goes CLIM serves that role, too.
> [ Java's AWT isn't as a windowing system but a common abstraction
> to N different variations of a "native" windowing system. ]

So? Lisp is an abstraction over a number of different computer
instruction sets as well. Your point?

> But perhaps CLIM is the "correct" solution.

You may be able to implement CLIM on top of the AWT.

dave

David Hanley

unread,
Apr 24, 1997, 3:00:00 AM4/24/97
to

Bill House wrote:
>
> David Hanley <da...@nospan.netright.com> wrote in article
> <335E3F...@nospan.netright.com>...
> >

> > I have a feeling people might react badly to this in light of pervious

> > discussiuons, but why not construct this lisp OS on the java VM? Then


> > you're not tied to any platform. You also get a windowing system,
> > filesystem abstraction, networking, system garbage collection, etc.
> >

> > dave
> >
> Well, for one thing, the bytecode VM architecture is outdated for modern hardware.
>
> FWIW, our Lisp VM uses a 32-bit instruction set. This allows us to perform many
> operations in a single VM instruction, rather than having to PUSH, PUSH, ADDI, MOV.

A decent VM ( and there are some good ones out there ) will compile
that into one instruction anyways. The stack-based architecture was
adopted because it allows optimizations for a wide varitey of chips with
differentr number of regsters, etc.


>
> What's wrong with Linux?

Linux is fine. Linux is cool. I used linux on my home computer. It's
not practical to ship commercial applications in linux, however. Isn't
the goal here to make better tools widely avaialble?


dave

Marc Wachowitz

unread,
Apr 24, 1997, 3:00:00 AM4/24/97
to

David Hanley (da...@nospan.netright.com) wrote:
> I have a feeling people might react badly to this in light of pervious
> discussiuons, but why not construct this lisp OS on the java VM?

Though such an approach will be sufficient for some projects (see Kawa),
the JVM lacks too much for a highly efficient implementation of Lisp,
particularly if that's supposed to be _the_ implementation in (or rather
"of") the system. Some examples: No immediate values in polymorphic data
(most importantly, tagged pointers and fixnums), no reliable tail calling
across compilation units (merely allowed for some cases), no overflow
detection on primitive types, no call by value, no multiple inheritance
(interfaces just won't do it), no dispatch on multiple arguments.

It may be possible to construct a special implementation of a VM which
is compatible with the JVM specification, but would reliably recognize
some idiomatic code patterns [possibly with additional attributes] which
would improve the above cases, but depending on something which cannot
be realistically expected from any serious JVM makes the whole idea of
using the JVM as a standard system pointless. Merely getting the kind of
libraries coming with Java is hardly worth such serious trouble, IMO -
generating low-level C with some customization for problematic areas will
probably provide a much better benefit/cost ratio for most cases, if you
want reasonable portability _and_ efficiency. (Going far beyond C still
is much better where you can afford it.)

-- Marc Wachowitz <m...@ipx2.rz.uni-mannheim.de>

Bill House

unread,
Apr 24, 1997, 3:00:00 AM4/24/97
to

David Hanley <da...@nospan.netright.com> wrote in article
<335F70...@nospan.netright.com>...

>
> A decent VM ( and there are some good ones out there ) will compile
> that into one instruction anyways. The stack-based architecture was
> adopted because it allows optimizations for a wide varitey of chips with
> differentr number of regsters, etc.
>
Agreed. However, I'm not so sure that this makes the JVM a great choice for building a
modern, portable OS. I do like the virtual part, but I think it would be better to
target 32-bit processors. Also, there have been a number of points raised about the
efficiency of building a Lisp system on top of the JVM.

>
> Linux is fine. Linux is cool. I used linux on my home computer. It's
> not practical to ship commercial applications in linux, however. Isn't
> the goal here to make better tools widely avaialble?
>
I agree that the commercial potential of Linux is limited, but I also agreed with posts
that suggested it might be a decent start. Maybe it's not good enough.

I suppose we could take an existing 32-bit Lisp VM instruction set and then build an OS
to that. This would take quite a bit longer, but then the results would truly deserve
the moniker "LispOS". The advantage of this approach would be that anyone could
implement a LispOS VM for their platform and then all LispOS apps would be portable.
Actually, I like this idea better than Linux. <g>

Will Hartung

unread,
Apr 24, 1997, 3:00:00 AM4/24/97
to

Chris....@alcatel.com.au (Chris Bitmead uid(x22068)) writes:


>vro...@netcom.com (William Paul Vrotney) writes:

>> Even though we are suggesting a sort of "fileless" operating system here the
>> term "file" still appears necessary. There is still the need for a file
>> data type if you will. There is still a need for the concept of an "untyped
>> block of bytes" with accessing constraints.

>In Lisp Machine nirvana, everything would be a typed object and
>untyped blocks of bytes would be banished from the face of the earth.

Well, the system could have a type of "UNTYPED-BLOCK"... :-)

--
Will Hartung - Rancho Santa Margarita. It's a dry heat. vfr...@netcom.com
1990 VFR750 - VFR=Very Red "Ho, HaHa, Dodge, Parry, Spin, HA! THRUST!"
1993 Explorer - Cage? Hell, it's a prison. -D. Duck

Kendall G. Clark

unread,
Apr 24, 1997, 3:00:00 AM4/24/97
to

David Hanley <da...@nospan.netright.com> writes:

> > What's wrong with Linux?
>

> Linux is fine. Linux is cool. I used linux on my home computer. It's
> not practical to ship commercial applications in linux, however. Isn't
> the goal here to make better tools widely avaialble?

Dave,

Can you make your view about the impracticality of shipping commercial
applications "in" Linux? I'm not sure I know what you mean by shipping
commercial applications "in" Linux and, thus, I'm not sure how or
whether to agree or disagree with you.

Thanks,

Kendall G. Clark

Frank Brickle

unread,
Apr 24, 1997, 3:00:00 AM4/24/97
to

Bill House wrote:

> ...I think it would be better to
> target 32-bit processors...
^^^^^^

A slight aside...AFAIK there is *no* existing 64-bit Lisp
in any form. To my mind it would be a grievous mistake not
to provide for DEC Alphas and whatnot from the very beginning.

Larry Hunter

unread,
Apr 24, 1997, 3:00:00 AM4/24/97
to

Martin Cracauer opened a can of worms by suggesting

Starting with FreeBSD, or Linux (or maybe even the Hurd 0.2 when it comes
out) and a common Lisp implementation like CMU, it seems you should have
the pieces to start developing a dedicated Lisp box.

Vrotney wrote:

... replace the standard file system with smaller objects with unlimited


attributes so that a more dynamic and explicit structure could be
represented on disk.

Then Hanley wrote:

The basic idea id not to use files, but to create data structures which
can be linked to some persistent space. Another program run will access
the data structure via the system in some manner. This idea is very


powerful, and I'd like to see it realized.

I'd like to again point out that Heiko Kirschke's PLOB (Persistant Lisp
OBjects) system would be a good choice for this. Needs multiprocessing for
the LISP, so CMUCL won't work, but ACL for Linux might be doable. You'd
need to port the POSTORE stuff to linux (which would be a Good Thing).

Larry


--
Lawrence Hunter, PhD.
National Library of Medicine phone: +1 (301) 496-9303
Bldg. 38A, 9th fl, MS-54 fax: +1 (301) 496-0673
Bethesda. MD 20894 USA email: hun...@nlm.nih.gov

Warning: sending unsolicited email advertising to this address violates US
Code Title 47, Sec.227, incurring a liability of at least $500 per incident.

David Hanley

unread,
Apr 24, 1997, 3:00:00 AM4/24/97
to

Marc Wachowitz wrote:
>
> David Hanley (da...@nospan.netright.com) wrote:
> > I have a feeling people might react badly to this in light of pervious
> > discussiuons, but why not construct this lisp OS on the java VM?
>
> Though such an approach will be sufficient for some projects (see Kawa),
> the JVM lacks too much for a highly efficient implementation of Lisp,
> particularly if that's supposed to be _the_ implementation in (or rather
> "of") the system. Some examples: No immediate values in polymorphic data
> (most importantly, tagged pointers and fixnums),

True, but most CPU's don't have that either. Based on this argument,
lispe implementors should twiddle their thumbs waiting for a lisp CPU to
appear.
Not practical.

no reliable tail calling
> across compilation units (merely allowed for some cases),

Is this important, however?

> no overflow
> detection on primitive types,

This is an issue, but not an imposible one.

> no call by value,

What do you mean, in this context? The java VM is always call by
value.

> no multiple inheritance
> (interfaces just won't do it),

How is this important for lisp compilation?

> no dispatch on multiple arguments.

Again, I don't know of any chip which supports this in hardware. You
have to simulate it in any case.

>
> It may be possible to construct a special implementation of a VM which
> is compatible with the JVM specification, but would reliably recognize
> some idiomatic code patterns [possibly with additional attributes] which
> would improve the above cases, but depending on something which cannot
> be realistically expected from any serious JVM makes the whole idea of
> using the JVM as a standard system pointless.

That would be doing it the wrong way, IMHO. The right ay is to perform
optimizations
on lisp code which make it fit well in the VM.

> Merely getting the kind of
> libraries coming with Java is hardly worth such serious trouble, IMO -

Well, I'm sure not seeing the 'serious trouble' but libraries are
important, along
with the other benefits I mentioned.

> generating low-level C with some customization for problematic areas will
> probably provide a much better benefit/cost ratio for most cases, if you
> want reasonable portability _and_ efficiency. (Going far beyond C still
> is much better where you can afford it.)

I suppose. But it seems this has been done before. Plus, the market
seems to be leading in a new direction..

>
> -- Marc Wachowitz <m...@ipx2.rz.uni-mannheim.de>

Heiko Kirschke

unread,
Apr 25, 1997, 3:00:00 AM4/25/97
to

vro...@netcom.com (William Paul Vrotney) writes:

> Even though we are suggesting a sort of "fileless" operating system here the
> term "file" still appears necessary. There is still the need for a file
> data type if you will. There is still a need for the concept of an "untyped
> block of bytes" with accessing constraints.

Let's call it namespace, just to bind an object to a name to identify
it. The term `file' is coined already to something like `a
unstructured block containing bytes'; interpretation of those bytes is
more or less hardcoded into the programs (or brains) accessing the
files. Replacing a filesystem by typed persistent objects would be a
fine thing.

Viele Gruesse, Heiko
--
Heiko Kirschke EMail: Heiko.K...@poet.de
POET Software GmbH Web: http://www.poet.de/
Fossredder 12 Tel: +49 40 60990-263
D-22359 Hamburg Fax: +49 40 60990-115

Heiko Kirschke

unread,
Apr 25, 1997, 3:00:00 AM4/25/97
to

Hi Larry,

Larry Hunter <hun...@work.csb> writes:

> I'd like to again point out that Heiko Kirschke's PLOB (Persistant Lisp
> OBjects) system would be a good choice for this. Needs multiprocessing for

I think so too ;-)

> the LISP, so CMUCL won't work, but ACL for Linux might be doable. You'd

Well, using multiprocessing is possible but not necessary for PLOB.

> need to port the POSTORE stuff to linux (which would be a Good Thing).

I've looked at the POSTORE code; there are some technical problems
porting the POSTORE to Linux (actually, I'd like to do so). The signal
handling on Linux is a little bit too vanilla to port the POSTORE
paging code.

William Paul Vrotney

unread,
Apr 25, 1997, 3:00:00 AM4/25/97
to

In article <s6ylo68...@aalh02.alcatel.com.au>

Chris....@alcatel.com.au (Chris Bitmead uid(x22068)) writes:
>
> vro...@netcom.com (William Paul Vrotney) writes:
>
> > Even though we are suggesting a sort of "fileless" operating system here the
> > term "file" still appears necessary. There is still the need for a file
> > data type if you will. There is still a need for the concept of an "untyped
> > block of bytes" with accessing constraints.
>
> In Lisp Machine nirvana, everything would be a typed object and
> untyped blocks of bytes would be banished from the face of the earth.
>

Yes that would be nirvana, but Buddha would say "Getting there is half the
fun". Keep in mind that in your new LispOS in the mean time you would need
to do things like down-load from some site

pictures.tar.gz

and expect some workable processing and representation of it.

Henry Baker

unread,
Apr 25, 1997, 3:00:00 AM4/25/97
to

In article <s6yn2qo...@aalh02.alcatel.com.au>,

Chris....@alcatel.com.au (Chris Bitmead uid(x22068)) wrote:

> It's very much about time that someone destroyed the myth that the
> UNIX byte stream is the ultimate in file system technology. I've been
> thinking along the same lines myself. What's needed is a standard
> format for storing objects in files. Actually it's probably an object
> database I want, except integrated with the OS, so that it is the
> standard way of storing stuff. UNIX ascii files are much too
> primitive, and are the source of endless headaches.

Amen! The problem has been to 1) come up with an agreeable alternative
(e.g., OODBMS?), and 2) make it 'efficient' enough that people will be
willing to use it.

1) I once implemented a trivial, but not particularly fast, persistent
'property list' system. Global properties of Lisp symbols were stored
in the file system, and the version in memory was merely a 'cache'. For
my particular purposes, I didn't need any locking mechanism, but any real
system must have some form of locking. Unfortunately, there were
restrictions on exactly what sorts of things could be stored in this
way.

Some Autolisp users do something similar to this, and what MacLisp users
used to call 'autoloading'.

Interlisp people will recognize this as a variant of their dumpfile (?)
stuff, wherein source code was edited 'in-core', and the whole mess was
saved to a file in ascii format a la APL workspaces.

If one did this right, one might be able to make believe that Lisp
atoms were truly persistent objects.

The Symbolics Statice system may have had some similarity to some of
this. I don't know the canonical reference to Statice. Is there something
on the net about this?

Marcus Daniels

unread,
Apr 25, 1997, 3:00:00 AM4/25/97
to

>>>>> "FB" == Frank Brickle <bri...@pobox.com> writes:

FB> A slight aside...AFAIK there is *no* existing 64-bit Lisp in any
FB> form. To my mind it would be a grievous mistake not to provide for
FB> DEC Alphas and whatnot from the very beginning.

CLISP has a configuraton that uses wide pointers (and works with DEC Alphas).
Surely there are others..

P. Srinivas

unread,
Apr 25, 1997, 3:00:00 AM4/25/97
to

Please post a copy of any article in this thread to
the newly created lispos mailing list also. There seems to be
more traffic on the newsgroup than on the mailing list.


Thanks

srini

Bill House

unread,
Apr 25, 1997, 3:00:00 AM4/25/97
to

Frank Brickle <bri...@pobox.com> wrote in article <336017...@pobox.com>...

>
> A slight aside...AFAIK there is *no* existing 64-bit Lisp
> in any form. To my mind it would be a grievous mistake not
> to provide for DEC Alphas and whatnot from the very beginning.
>
That's a very good point. My main issue was that I don't think we need to jump through
hoops to support (< 32 bits) machines. Do you think that a 32-bit instruction size
would seriously limit LispOS on 64-bit machines?

Kelly Murray

unread,
Apr 25, 1997, 3:00:00 AM4/25/97
to

>hba...@netcom.com (Henry Baker):

>>Chris....@alcatel.com.au (Chris Bitmead uid(x22068)) wrote:
>> format for storing objects in files. Actually it's probably an object
>> database I want, except integrated with the OS, so that it is the
>> standard way of storing stuff. UNIX ascii files are much too

>Amen! The problem has been to 1) come up with an agreeable alternative


>(e.g., OODBMS?), and 2) make it 'efficient' enough that people will be
>willing to use it.

>If one did this right, one might be able to make believe that Lisp


>atoms were truly persistent objects.

Exactly. If one did this right, as I am proposing,
Lisp atoms would TRULY be persistent objects, as well as everything else
that must be saved. However, if you think about how a library or module
system must be organized, the current CL package system is inadequate,
and symbols, as we know them today, might be replaced with something else.

If this persistent object system is integrated with the OS,
this really means LISP is integrated with the os, hence the LispOS idea.

-kelly murray (speaking for myself)


Ian Ross

unread,
Apr 25, 1997, 3:00:00 AM4/25/97
to

In article <vrotneyE...@netcom.com> vro...@netcom.com (William Paul Vrotney) writes:

> Yes that would be nirvana, but Buddha would say "Getting there is half the
> fun". Keep in mind that in your new LispOS in the mean time you would need
> to do things like down-load from some site
>
> pictures.tar.gz
>
> and expect some workable processing and representation of it.

Is this really such a good example? You can figure out from the file
contents what sort of thing it is - gzip puts a magic number in there,
as does tar, and most picture formats are easily recognisable.

Any object-based OS is obviously going to need some sort of way of
importing things from the unenlightened outside world, but most of the
time, you can work out what sort of objects files correspond to. This
is definitely true for most things people might download - HTML, DVI,
movies, sounds, PostScript, Java class files, and so on.

The point is, I think, that everyone knows you need some way to solve
the problem you raise, but most of the time, the OS will be able to do
it without user intervention. Sure, there will be cases where you
have some binary file for which there is no easy mapping to an object
type, so you will still need the old bag'o'bytes type, but it will be
the exception rather than the rule.

All of this could be quite neat, in the end:

- if you're composing a mail message, and drop an object into it, the
OS will know what MIME type to use for it;
- if you upload an object to an FTP site, the OS will know what a
sensible file name convention is to use for it;
- for your download example, you end up with a collection of
pictures, and don't need to worry about the details of how the
thing is represented (to be really cute, the file/object system
browser could represent 'compressed tar file' objects to the user
as folders of whatever the things in the archive are).

This is all starting to sound like a lot of fun.

Incidentally, a lot of people have spoken about Genera, which I
understand runs on the Symbolics machines. Can anyone give a short
description of it, and let us all know why it's so neat, and what
features of it should be carried over into any new LispOS?

Ian.

David Hanley

unread,
Apr 25, 1997, 3:00:00 AM4/25/97
to

Of course, though I suspect you're just being pedantic.
Very few businesses use linux, fewer still a linux modified to be
lisp-centric. The os idea sounds interesting, but who would use
applications written in it?

It possible of course, that you could produce binaries that would run
on non-lisp os's, but what would be the benefit of constructing a lisp
OS in this case?

dave

Frank Brickle

unread,
Apr 25, 1997, 3:00:00 AM4/25/97
to

Bill House wrote:

> ...Do you think that a 32-bit instruction size


> would seriously limit LispOS on 64-bit machines?

Not absolutely sure about the instruction sizes.
Certainly the 32 (-> 29) bit address space limitations
have limited usefulness on the existing 64-bit half-ports.
But the lack of natural, unboxed 64-bit data is proving to be
the biggest headache, for me, anyway.

Here's one reason among several: crypto. It may not be
everywhere now, but it will be; networked machines are
going to be doing a *lot* of chewing on 64-bit data blocks
before too very long.

Frank Brickle

unread,
Apr 25, 1997, 3:00:00 AM4/25/97
to

Marcus Daniels wrote:

> CLISP has a configuraton that uses wide pointers (and works with DEC Alphas).

That could very well be the case. There have been other ports to 64-bit
architectures, but not full ones.

> Surely there are others..

Not that I've been able to discover.

Gareth McCaughan

unread,
Apr 25, 1997, 3:00:00 AM4/25/97
to

Bill House wrote:

> That's a very good point. My main issue was that I don't think we
> need to jump through hoops to support (< 32 bits) machines.

You mean (< bits 32). :-)

--
Gareth McCaughan Dept. of Pure Mathematics & Mathematical Statistics,
gj...@dpmms.cam.ac.uk Cambridge University, England.

Christopher J. Vogt

unread,
Apr 25, 1997, 3:00:00 AM4/25/97
to

In article <rcu3l1z...@redwood.skiles.gatech.edu>, Richard Coleman
<col...@math.gatech.edu> wrote:

> I hear many people on this group talk fondly about
> the days of the lisp machine. About how flexible and
> powerful they were. So now that machines have gotten
> fast enough, why isn't anyone working on a LispOS.

I think that on the commercial side, the problem is money. You are not
going to get any VC to give you money for a LispM, no matter how fast you
talk, or how many 3 color graphs you have.

>
> It seems like all the pieces are there to use. Starting


> with FreeBSD, or Linux (or maybe even the Hurd 0.2 when
> it comes out) and a common Lisp implementation like CMU,
> it seems you should have the pieces to start developing
> a dedicated Lisp box.
>

> I surprised there aren't any groups doing something like
> this.
>
> Richard Coleman
> col...@math.gatech.edu

--
mailto:vo...@novia.net
Omaha, NE
http://www.novia.net/~vogt/

Christopher J. Vogt

unread,
Apr 25, 1997, 3:00:00 AM4/25/97
to

In article <NNYRNI.97A...@ubs1235.ny.ubs.com>,
nny...@ubs1235.ny.ubs.com (Ian Ross) wrote:
[...]

> Incidentally, a lot of people have spoken about Genera, which I
> understand runs on the Symbolics machines. Can anyone give a short
> description of it, and let us all know why it's so neat, and what
> features of it should be carried over into any new LispOS?

I believe that there is a version of Genera that runs on DEC Alphas.

What is so neat about Genera? That is hard to answer in a few short
sentences. I'm sure that if you get answers from 5 people you'll get 5
different answers (which is an answer in itself). I'll give it a shot.
Note that much of what makes Genera special has been duplicated elsewehre,
but nobody has all the pieces together in one place, and not much
improvement has been made, and Genera is 10 years old!

I love(d) Genera because:
Everything was integrated, it has a single address space that all
programs run in, the benefits of this are extensive, use your
imagination. This may well me the "one" statement that says it all.
Every tool you could possibly want to help develop code is present,
integrated, and easily customizeable. All the sources were available to
make this easier.
A mouse documentation line so you know what is going to happen when you
press the mouse, before you press the mouse.
Everything in a window is potentially mouseable, with appropriate
options available. If something is mouseable a box appears around it when
the mouse moves over it, and the mouse documentation line tells you what
the mouseing options are.
A great debugger featurefull debugger.
Networking, editing, mailing, and Multiprocessing.
Good support for application development, maintenance, and documentation.
Stable. In the six or seven years I worked under Genera, I could count
one one hand the number of times I was forced to reboot (I'm talking
released software, not counting bringing up new systems). Imagine, an
error occurs and it doesn't crash your system, or your program, you just
end up in a "break" and 9 times out of 10, you can figure out the problem,
fix it to get the program running again, send a bug report, and not even
break out in a sweat!
Hooks to modify the compiler if I found an optimization that wasn't
being made that I wanted to make.
Hooks to add/modify the microcode (which doesn't really apply in todays
RISC chip machines).

Gosh, this is all making me feel *VERY* nostalgic. I've used half a dozen
Lisp's since then, and as many OS's, and I still haven't found anything
that compares.

Rainer Joswig

unread,
Apr 26, 1997, 3:00:00 AM4/26/97
to

> Incidentally, a lot of people have spoken about Genera, which I
> understand runs on the Symbolics machines. Can anyone give a short
> description of it, and let us all know why it's so neat, and what
> features of it should be carried over into any new LispOS?

For the world according to 1985 (sigh) see:

http://www.lavielle.com/~joswig/symbolic-computing.html

--
http://www.lavielle.com/~joswig/

Marc Wachowitz

unread,
Apr 26, 1997, 3:00:00 AM4/26/97
to

While the idea to build (more or less) everything around Lisp has a
certain appeal, this will also very likely inhabit an even smaller
niche than Lisp already inhabits today. For some people around here,
it may be suffici