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
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.
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?"
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
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
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
>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
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.
> ....
> 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
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
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.
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)
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,
> 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.
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
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
> 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.
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?
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
> 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???
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
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
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
> 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
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.
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
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).
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".
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.
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?
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.
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.
>
>
>
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
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
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
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>
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>
>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
> > 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
> ...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.
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.
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>
> 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
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.
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.