creation of lisp machine/lispOS
Richard Coleman
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
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
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
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
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
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
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
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
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
> 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
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
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
>>>>> "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
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
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.
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
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
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
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
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
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???
David Hanley
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.
> 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
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
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
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
William Paul Vrotney
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
> > represented on disk.
> [snip]
> > 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
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
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
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)
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
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.
>
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
>
> I have a feeling people might react badly to this in light of pervious
> you're not tied to any platform. You also get a windowing system,
> filesystem abstraction, networking, system garbage collection, etc.
>
>
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)
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)
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
>>"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
Lyman S. Taylor wrote:
>
> In article <335E3F...@nospan.netright.com>,
> David Hanley <da...@nospam.netright.com> wrote:
> >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
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
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
>
> 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.
>
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?
>
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
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
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
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
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
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
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
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
In article <s6ylo68...@aalh02.alcatel.com.au>
>
> > 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.
>
> 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
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
>>>>> "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
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
Frank Brickle <bri...@pobox.com> wrote in article <336017...@pobox.com>...
>
> A slight aside...AFAIK there is *no* existing 64-bit Lisp
> 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
>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
> 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
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
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
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
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
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
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
> 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:
Marc Wachowitz
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 sufficient to have their own somewhat isolated Lisp machine,
but from the feedback, I guess the primary interest of most is having
a decent Lisp environment - both for development and for delivery -
which can covers even very low-level stuff (but doesn't necessarily do
so). It doesn't seem like the existing divergence of interests is likely
to disappear easily any time soon, but the nature of the task (either
way) calls for a cooperation of as many good people as we can get. Yet,
we may be able to have our cake and eat it too.
My suggestion is to consider Richard P. Gabriel's paper on "How to Win
Big" (see e.g. http://www.naggum.no/worse-is-better.html), particularly
the third chapter. At a first glance it might sound as even contrary to
the idea of a "Lisp OS" after which the mailing list was named, but on
closer view, I think it's a realistic approach to get both: A reasonable
chance to be able to use Lisp for commercial purposes more often than
now, and a chance to implement as much of a system as one wants - and as
different a system as one wants - in Lisp.
For both, I think we need a Common Lisp (probably with some additional
support for other Lisp dialects [like continuations for Scheme], or even
quite different languages) with a very flexible interface to the lower
levels of the system (where one variant is that the lower levels will be
mostly written in Lisp itself, making the distinction between "levels" a
matter of conventions), and some high-level stuff which isn't standardized
yet. If we're going to either hack some (existing or even newly created)
Lisp implementation to provide this, we might as well do so with some care
to make interdependencies a little bit more explicit than good engineering
practice would demand anyway. This would probably include a (less formal)
reanimation of the appearently sleeping efforts to extend the range of
what's reasonably standard across existing implementations (travel back
into the past of the newsgroup comp.std.lisp).
-- Marc Wachowitz <m...@ipx2.rz.uni-mannheim.de>
Bill House
Gareth McCaughan <gj...@dpmms.cam.ac.uk> wrote in article
<864tcua...@g.pet.cam.ac.uk>...
>
> You mean (< bits 32). :-)
>
Alex Williams
Er, I think we call "untyped blocks of bytes" "strings".
--
[ Alexander Williams {tha...@alf.dec.com/zan...@photobooks.com} ]
[ Alexandrvs Vrai, Prefect 8,000,000th Experimental Strike Legion ]
[ BELLATORES INQVITI --- Restless Warriors ]
====================================================================
Erik Naggum
* David Hanley
| Plus, the market seems to be leading in a new direction..
this is a common misconception. the market does in fact not lead anything
or anywhere. the market _follows_ in the footsteps of designers, creators,
producers, and other trend setters. the market is also not a force, but a
momentum of the successful application of _creative_ forces. for some odd
reason, lots of people think the market is something more than a measuring
device on the activity of a large number of people. the market per se has
no will, no strength, no future, no direction, except insofar as those who
lead people to buy something continue to lead them to buy it in the future,
and are not successfully contested by other leaders to buy something else.
#\Erik
--
if we work harder, will obsolescence be farther ahead or closer?
Rainer Joswig
In article <5jqgoq$d...@tribune.usask.ca>, sr...@alfresco.usask.ca (P.
Srinivas) wrote:
Where do we find such a mailing list?
Nelson Rodriguez
:There is a discussion now taking place about the possibility
:of creating either a lispOS or large lisp/scheme based user
:environment. Currently it is just discussion, but there seems
:to be many people interested in the possibility.
:
:There is a mailing list for this discussion at
:
: lis...@math.gatech.edu
:
:To subscribe, send e-mail to
:
: lispos-...@math.gatech.edu
:
:with the subject: "subscribe e-mail-address"
:
:Richard Coleman
:col...@math.gatech.edu
Ulric Eriksson
In article <335F70...@nospan.netright.com>,
David Hanley <da...@nospam.netright.com> wrote:
>
>Bill House wrote:
>>
>> 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?
I don't understand what you mean. Commercial applications are
shipping "in Linux" today. Using Linux as a base for a Lisp
environment and improving it incrementally sounds like a
perfectly reasonable thing to do.
Write a New and Improved webserver in this, call it IntraWebWare 97
and put it in a colourful cardboard box.
Ulric Eriksson
--
I proactively leverage my synergies.
Ulric Eriksson
In article <3360E0...@nospan.netright.com>,
David Hanley <da...@nospam.netright.com> wrote:
>Kendall G. Clark wrote:
>>
>> 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.
>
> 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?
As this whole thread is about making a *new* Lisp OS, nobody is
using it today.
>
> 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?
The benefit would be that one could press the OS on a CD together
with the application. It would then be possible to use it to develop
applications and sell them to people who simply want to install
something on a PC to provide a service, but have no interest in
what OS is involved.
David Hanley
Erik Naggum wrote:
>
> * David Hanley
> | Plus, the market seems to be leading in a new direction..
>
> this is a common misconception. the market does in fact not lead anything
> or anywhere. the market _follows_ in the footsteps of designers, creators,
> producers, and other trend setters.
I completely disagree. The point you are missing is that these
designers,
creators, prodocers, etc, build what people want.
If company 'a' produces one billion coolWidgets, and no one wants them,
this will not define the market, as you suggest. The market will be
defined by
the organization that creates widgets people want and will use.
There's a software lesson in there. You can make what you think is
the coolest, most technically advanced software in existance. If no one
wants
it, you are irrelevant to the market.
> the market is also not a force, but a
> momentum of the successful application of _creative_ forces. for some odd
> reason, lots of people think the market is something more than a measuring
> device on the activity of a large number of people.
That's because it's a useful abstraction to think of it that way.
Abstractions are important for programming as well. For example, we
speak
of supply nd demand evening out to create a proce for some product. In
reality,
no such thing happens.. Nothing stops me from paying more if I choose,
and nothing stops the company from selling me the product for one cent.
In reality, there is a price I will probably pay based on supply and
demand.
> the market per se has
> no will, no strength, no future, no direction, except insofar as those who
> lead people to buy something continue to lead them to buy it in the future,
> and are not successfully contested by other leaders to buy something else.
You are still assuming that the suppliers create the market. In
reality,
most markets are driven by the consumers ( in a capitalist country ).
This doesn't
always happen, which is why governments like the US like to break up
monoplies
and trusts.
Chris Bitmead uid(x22068)
m...@ipx2.rz.uni-mannheim.de (Marc Wachowitz) writes:
> 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 sufficient to have their own somewhat isolated Lisp machine,
> but from the feedback, I guess the primary interest of most is having
> a decent Lisp environment - both for development and for delivery -
Well, maybe if it was designed right you could take or leave whatever
portion of the system you like.
> For both, I think we need a Common Lisp (probably with some additional
> support for other Lisp dialects [like continuations for Scheme], or even
> quite different languages) with a very flexible interface to the lower
> levels of the system (where one variant is that the lower levels will be
> mostly written in Lisp itself, making the distinction between "levels" a
> matter of conventions),
Personally I think if you're going build something which is basicly
not compatible with the rest of the Universe you might as well go the
whole hog and use the the most pure language (i.e. Scheme), and make
it a SchemeOS. Oops! Don't want to start a flame war. I'd be
reasonably happy as long as Scheme could be used as seamlessly as
lisp. Condidering the problems Guile have had I'm not sure that would
be easy.
Chris Bitmead uid(x22068)
hba...@netcom.com (Henry Baker) writes:
> 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.
Maybe the lisp community needs to come up with an ODMG object database
interface standard, like there is for Smalltalk, C++ and soon to be
Java.
Erik Naggum
* Chris Bitmead uid
| Personally I think if you're going build something which is basicly not
| compatible with the rest of the Universe you might as well go the whole
| SchemeOS. Oops! Don't want to start a flame war. I'd be reasonably
| happy as long as Scheme could be used as seamlessly as lisp. Condidering
| the problems Guile have had I'm not sure that would be easy.
there's something I don't understand about Scheme proponents. I recognize
that the language is smaller and (for some values of "elegant") is more
elegant than most, but if everything that people want to do is so "impure"
as not to make it into the standard, doesn't the overall result get much
_less_ elegant than if you decided to offer some practical, reasonable way
to do it?
after all, when a Scheme implementor has no "defstruct" in the language
specification, he's going to add his own, because they are necessary when
programming anything non-trivial and any programmer will look for them.
now, whatever he comes up with, it does _not_ meet the Scheme standard of
supreme elegance (otherwise it would have been in the language), so he will
instantiate the practical-vs-elegant argument every time he makes a design
decision for something that is obviously needed yet too ugly to make it
into the standard. I contend that this argument destroys the basis for the
argument for superior elegance, in fact contradicts it fundamentally: if X
number of very good people can't agree on one particular solutionbeing the
most elegant, what are the chances that somebody else, who is not among
them, will find it when it is needed, and much more of a hurry? what are
the chances that it will be vastly less elegant than any of the options
under consideration?
I, too, can look at R4RS and admire its clarity, its elegance, and its
succesfull minimalism, but when I look at Scheme programs that try to do
more than trivial tasks, or at Scheme systems that try to give people a
framework to work in, I get the "perl experience" -- heaps of ugly but
useful hacks to get some short-term job done. seems to me that the flip
side of the "only the most elegant are admitted" argument is that there is
no lower bound on the ugliness of what is _not_ admitted, yet necessary to
get there in practice, and so anything goes. with less stringent demands
on elegance for admittance, the standards might just be attainable for more
people. (I'm not talking about the great masses inflicted on C++/Perl, but
very good programmers who do have a job to do, too.)
maybe this is just my experience, but when I write in C, I think "it needs
to work sufficiently well" (I don't have time to make it always correct
unless I'm implementing fundamental library functions). when I write in
Lisp, "it needs to work correctly, but if it contains an interesting
problem, I want to find a good general solution". usually, I have the time
to find a good general solution to those interesting problems. from what I
see of Scheme code, I get the impression that Schemers still think "it
needs to work correctly", but that they are willing to reimplement basic
functionality all over the place in lots of different ways, mostly to tweak
some of the parameters that gave them the most minimalistic and locally
most elegant solution to their problem the last time they saw it.
in sum, I think Scheme the language is elegant and beautiful, but since so
little has been offered to me by those who crafted the elegance, I'm left
with a lot of random inelegance in practice. this is in fact why I don't
like Scheme.
Henry Baker
> after all, when a Scheme implementor has no "defstruct" in the language
> specification, he's going to add his own,
Scheme _does_ have defstructs. They're pronounced 'closures'.
Chris Bitmead uid(x22068)
Erik Naggum <er...@naggum.no> writes:
> * Chris Bitmead uid
> | Personally I think if you're going build something which is basicly not
> | compatible with the rest of the Universe you might as well go the whole
> | hog and use the the most pure language (i.e., Scheme), and make it a
> | SchemeOS. Oops! Don't want to start a flame war. I'd be reasonably
> | happy as long as Scheme could be used as seamlessly as lisp. Condidering
> | the problems Guile have had I'm not sure that would be easy.
>
> there's something I don't understand about Scheme proponents. I recognize
> that the language is smaller and (for some values of "elegant") is more
> elegant than most, but if everything that people want to do is so "impure"
> as not to make it into the standard, doesn't the overall result get much
> _less_ elegant than if you decided to offer some practical, reasonable way
> to do it?
>
> after all, when a Scheme implementor has no "defstruct" in the language
> specification, ....
The thing that I like about Scheme is that the *language* is smaller,
simpler and easier to understand. I consider the extent of the
standard libraries to be a different issue and one which is a problem
for Scheme. The purity of Scheme is NOT in the small amount of
standard functionality.
I would actually wouldn't mind if someone added all of common lisp's
library definitions to the Scheme standard, as long as the core
central language retained its purity and simplicity.
Erik Naggum
* Erik Naggum
| the market does in fact not lead anything or anywhere. the market
| _follows_ in the footsteps of designers, creators, producers, and other
| trend setters.
* David Hanley
| I completely disagree. The point you are missing is that these
| designers, creators, prodocers, etc, build what people want.
this is another common misconception. what people "want" is a function of
what they learn is available. e.g., do Americans want three-ring binders,
and Europeans four-ring binders? or do they want binders and take whatever
number of holes they come with? or do they want something that can help
them organize their papers and take whatever is available? or do they
really want a less cluttered office and ease of storage and retrieval of
the information they receive? so, did people really _want_ three-ring
binders, or is that just what they could buy?
the problem is, what people _want_ is so far removed from the market and so
abstract that it takes designers, creators, producers and trend setters to
_give_ it concrete shape. they transform your want of a good night's sleep
into a want of a waterbed, for instance. they transform your combined
wants of status and a means of transportation into a want of a particular
model of a car, and a _renewed_ want of a car every so often to maintain
that "status" thing.
designers, creators, producers, etc, do not build what people want, they
_give_ people something _concrete_ to want, to afford, to buy, that they
wouldn't want, wouldn't fund, wouldn't wish to buy until _after_ it had
been created. the difference between a producer and a consumer is that the
producer is able to produce what the consumer will consume but is himself
unable to produce, for lack of time, intelligence, fantasy, economic means,
whatever.
if you wish to sell something, you'd better understand that you can't give
people what they _want_ in the market today, because what they want today
is what they can already _get_. you have to discover what they _really_
want, and find some way to give that physical shape.
look at Microsoft. nobody in their right mind would want their buggy shit.
what Microshit users want is something entirely separate from the products.
Microshit is _not_ user-friendly, but it is marketed as user-friendly, and
then other software products, far more user-friendly, are made to look as
if they missed the whole point about what "user-friendly" _is_, namely to
look cool in nice colors while you're crashing and destroying the disk,
importing a virus from a disk, or letting Word destroy your day's work.
it's often been pointed out that consumers don't want quality, they only
want the _immediate_ needs satisfied. that's why we have other people to
look out for product quality for them, specifically lawyers who are able to
run a company into the ground for not being "responsible" enough towards
people who were perfectly content to buy the crap sight unseen.
| If company 'a' produces one billion coolWidgets, and no one wants them,
| this will not define the market, as you suggest.
that is not what I suggest, David. and I haven't missed your point at all;
your point is just plain irrelevant. your examples are so far removed from
reality I can't begin to argue against them. the very idea that you
actually _believe_ that somebody is suggesting that company A produce a
billion widgets when nobody wants them is so foreign to me that I also
don't know where to _start_ getting you straight. in fact, it is so
mind-bogglingly irrational to suggest such a thing that I wonder how you
could invent the argument in the first place.
the difference between what people want and what they will buy is what the
salesman can offer. a good salesman can sell people more than they wanted
when they started. a good salesman can sell people something _different_
from what they thought they wanted. the whole purpose of advertising is to
_change_ what you want to buy and when. if you were right, that producers
make what consumers want, why would you need multi-billion-dollar
industries to create advertisements for products to people who already
wanted them?
however, it's also part of The Big Advertising Lie to give people the
impression that they give the same people what they want. "no, it's not a
clever ploy to let a fool and his money part", they tell the fools, and
then the fools part with their money even sooner than without the lie.
if you want to succeed in business, _don't_ give people what they want.
give them the impression that they _really_ want what you can offer,
because only the smart, the hip, the cool, the best, the brightest, etc,
want what you can sell. to win in the market, study advertising, then hire
the cheapest people to produce it that you can find, while you set out a
rumor that you hire only the best. (I mean, who _doesn't_ hire the best
among whoever applies for their openings?)
| You are still assuming that the suppliers create the market. In reality,
| most markets are driven by the consumers ( in a capitalist country ).
| This doesn't always happen, which is why governments like the US like to
| break up monoplies and trusts.
interesting view. when did the U.S. Government break up Microsoft?
Marc Wachowitz
David Hanley <da...@nospan.netright.com> wrote:
> > No immediate values in polymorphic data
> > (most importantly, tagged pointers and fixnums),
>
> True, but most CPU's don't have that either.
What I mean is the ability to use pointers such that some bit patterns can
be recognized and used by the system as immediate values. On most system,
you can easily allocate objects on 4-byte (or even better 8-byte) boundaries,
and thus use the lower bits of pointers as type tags for immedates (and
possibly also for the object referenced by the pointer, though that's not as
important as immediate fixnums).
> > no reliable tail calling
> > across compilation units (merely allowed for some cases),
>
> Is this important, however?
As far as I'm concerned, yes. If you want to conform to R4R-Scheme, you
need tail calls (though you could get away without separate compilation,
but even if your users would tolerate that, compiling everything as one big
procedure isn't possible in the JVM due to some size limitations, and you'll
lose anyway).
> > no overflow
> > detection on primitive types,
>
> This is an issue, but not an imposible one.
I'm not talking about "impossible", but about poor performance in a JVM
implementation (unlikely to be optimized beyond typical Java usage). All
integer operations where the compiler cannot statically prove that the
operands _and_ the result will be fixnum does need this. It must be cheap
in the non-overflow case and still reasonably efficient for bignums (and
preferably not cause much code bloat).
> > no call by value,
>
> What do you mean, in this context? The java VM is always call by
> value.
Only for pointers and primitive types, not for composite objects (records
or whatever you'd like to call them). Many cases with a variable number of
arguments and/or return values shouldn't need heap allocation.
> > no multiple inheritance
> > (interfaces just won't do it),
>
> How is this important for lisp compilation?
It would help with implementing CLOS efficiently.
> > 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.
Yes, but typical processors provide much better support for this than the
limitations of the JVM with required static checking for Java's type system,
and without much facilities for address manipulation, clever code layout, and
storing data in the code.
> The right ay is to perform optimizations on lisp code
> which make it fit well in the VM.
This will work to a degree for complete programs of limited complexity,
but beyond that, you simply need to do some thing efficiently at run time.
Being able to do so is part of what makes Lisp so expressive. Have you
ever looked at sophisticated code using the power of CLOS? If you can
optimize this statically (and with decent compilation times), fine, but
in many cases, I doubt it. (In case my doubts are wrong, I'd like to
read something about your optimizer, and I'm sure many researchers will
be interested, too ;-)
-- Marc Wachowitz <m...@ipx2.rz.uni-mannheim.de>
David Hanley
Erik Naggum wrote:
>
> * Erik Naggum
> | the market does in fact not lead anything or anywhere. the market
> | _follows_ in the footsteps of designers, creators, producers, and other
> | trend setters.
>
> * David Hanley
> | I completely disagree. The point you are missing is that these
> | designers, creators, prodocers, etc, build what people want.
>
> this is another common misconception. what people "want" is a function of
> what they learn is available. e.g., do Americans want three-ring binders,
> and Europeans four-ring binders? or do they want binders and take whatever
> number of holes they come with? or do they want something that can help
> them organize their papers and take whatever is available? or do they
> really want a less cluttered office and ease of storage and retrieval of
> the information they receive? so, did people really _want_ three-ring
> binders, or is that just what they could buy?
Once again, you fail to understand the issue. People wanted something
to
keep their papers together, so binders were created. Binders didn't
come along,
and provoke people to say, "Gosh, I need to keep papers together!"--that
just
not how the creative process works.
Necessity is the mother of invention, not the other way around.
If people wanted six-ring binders they would be available.
>
> the problem is, what people _want_ is so far removed from the market and so
> abstract that it takes designers, creators, producers and trend setters to
> _give_ it concrete shape. they transform your want of a good night's sleep
> into a want of a waterbed, for instance.
Obviously. But it's consumer, not producer driven.
> they transform your combined
> wants of status and a means of transportation into a want of a particular
> model of a car, and a _renewed_ want of a car every so often to maintain
> that "status" thing.
Or the 'got to get to X without breakign down thing'
>
> designers, creators, producers, etc, do not build what people want, they
> _give_ people something _concrete_ to want, to afford, to buy, that they
> wouldn't want, wouldn't fund, wouldn't wish to buy until _after_ it had
> been created.
Very silly, and wrong. I want to buy a lot of things that don't
exist. Say, a claudia schiffer clone. Gee, how could I want something
no one
is actively producing? I must be an anomly, huh?
If a producer comesout with something no one wants it will fail.
Simply making a product does nothing if the consumer didn't want it.
In the real world, market research is done early in the concept phase,
at least for sonsumer products. Technical products are a little
different, but
are, one again, consumer driven.
> if you wish to sell something, you'd better understand that you can't give
> people what they _want_ in the market today, because what they want today
> is what they can already _get_. you have to discover what they _really_
> want, and find some way to give that physical shape.
Nope. The correct way is to identify what they want, but can't
get, and give it to them.
>
> look at Microsoft. nobody in their right mind would want their buggy shit.
> what Microshit users want is something entirely separate from the products.
> Microshit is _not_ user-friendly, but it is marketed as user-friendly, and
> then other software products, far more user-friendly, are made to look as
> if they missed the whole point about what "user-friendly" _is_, namely to
> look cool in nice colors while you're crashing and destroying the disk,
> importing a virus from a disk, or letting Word destroy your day's work.
Wrong. People want integrated and easy-to-install software. It didn't
exist. Microsoft gave it to them. They bought it. Users don't
understamd technical
issues, so 'buggy' didn't even figure into the picture.
I've worked with users many, many times, and had them ask 'can you make
the software do _this_'-- something new and unique, that they hadn't
seen before. If
I give them waht they want, I get money.
>
> it's often been pointed out that consumers don't want quality, they only
> want the _immediate_ needs satisfied.
Possibly, but irrelevant to the discussion. In the software
field, quality is always assumed to improve in the next release, users
beleive this, and accept buggy software.
If users had to pick between otherwise equielent buggy-and non-buggy
software, they'll choose the non-buggy one, of course. But features and
finish are important too.
Once again--giving users what they want!
> that's why we have other people to
> look out for product quality for them, specifically lawyers who are able to
> run a company into the ground for not being "responsible" enough towards
> people who were perfectly content to buy the crap sight unseen.
Or not buy it again. This is usually what happens.
>
> | If company 'a' produces one billion coolWidgets, and no one wants them,
> | this will not define the market, as you suggest.
>
> that is not what I suggest, David. and I haven't missed your point at all;
> your point is just plain irrelevant. your examples are so far removed from
> reality I can't begin to argue against them. the very idea that you
> actually _believe_ that somebody is suggesting that company A produce a
> billion widgets when nobody wants them is so foreign to me that I also
> don't know where to _start_ getting you straight. in fact, it is so
> mind-bogglingly irrational to suggest such a thing that I wonder how you
> could invent the argument in the first place.
I don't know how to respond--either my points are going over your head,
or you are so bad at expressing yourself, your point is completely
obscured.
>
> the difference between what people want and what they will buy is what the
> salesman can offer. a good salesman can sell people more than they wanted
> when they started. a good salesman can sell people something _different_
> from what they thought they wanted. the whole purpose of advertising is to
> _change_ what you want to buy and when. if you were right, that producers
> make what consumers want, why would you need multi-billion-dollar
> industries to create advertisements for products to people who already
> wanted them?
Because there are competing products which are quite similar. Products
with which we all ned and have no choice are not advertised. Somewhat
like
electricity where I live, or tap water.
> if you want to succeed in business, _don't_ give people what they want.
Odd. I had the impression I was already doing that.. Oh well.
> | You are still assuming that the suppliers create the market. In reality,
> | most markets are driven by the consumers ( in a capitalist country ).
> | This doesn't always happen, which is why governments like the US like to
> | break up monoplies and trusts.
>
> interesting view.
And correct.
> when did the U.S. Government break up Microsoft?
Microsoft is not a monopoly.
Kelly Murray
>> > the market per se has
>> > no will, no strength, no future, no direction, except insofar as those who
>> > lead people to buy something continue to lead them to buy it in the future,
>> > and are not successfully contested by other leaders to buy something else.
>>
Right. A market is controlled by the customers who are doing the buying.
However, what underlies their buying is WHY they are buying.
The customers have problems they must to solve.
A supplier can't change the customers problems,
but they are the ones who create the solutions.
It is a complex "system" or "food chain" as we like to say
-- using specific solutions can creates new problems,
which suppliers offer solutions for, etc, etc,
and the world keeps on going around...
The biggest impact is coming up with solutions to the basic problems,
and not just solving the little ones high up in the food chain.
That is very difficult, since there is the huge "weight" of solutions
that solves many of the known problems with the existing basic solution.
-Kelly Murray k...@franz.com
Rainer Joswig
> * Erik Naggum
> | the market does in fact not lead anything or anywhere. the market
> | _follows_ in the footsteps of designers, creators, producers, and other
> | trend setters.
>
> * David Hanley
> | I completely disagree. The point you are missing is that these
> | designers, creators, prodocers, etc, build what people want.
>
> this is another common misconception. what people "want" is a function of
> what they learn is available. e.g., do Americans want three-ring binders,
> and Europeans four-ring binders?
But you have to admit that four-ring binders simply are much easier
to use and easier to maintain!
Mike McDonald
In article <joswig-ya0231800...@news.lavielle.com>,
jos...@lavielle.com (Rainer Joswig) writes:
> In article <30714921...@naggum.no>, Erik Naggum <er...@naggum.no> wrote:
>> this is another common misconception. what people "want" is a function of
>> what they learn is available. e.g., do Americans want three-ring binders,
>> and Europeans four-ring binders?
>
> But you have to admit that four-ring binders simply are much easier
> to use and easier to maintain!
Ha! That redundant ring costs money to manufacture and increases the chances
of bent or broken rings! The ideal binder would have only two rings or one big
clamp. :-)
Mike McDonald
mik...@engr.sgi.com
Jon Buller
David Hanley wrote:
> Erik Naggum wrote:
> > this is another common misconception. what people "want" is a function of
> > what they learn is available. e.g., do Americans want three-ring binders,
> > and Europeans four-ring binders? or do they want binders and take whatever
> > number of holes they come with? or do they want something that can help
> > them organize their papers and take whatever is available? or do they
> > really want a less cluttered office and ease of storage and retrieval of
> > the information they receive? so, did people really _want_ three-ring
> > binders, or is that just what they could buy?
>
> Once again, you fail to understand the issue. People wanted something
> to
> keep their papers together, so binders were created. Binders didn't
> come along,
> and provoke people to say, "Gosh, I need to keep papers together!"--that
> just
> not how the creative process works.
>
> Necessity is the mother of invention, not the other way around.
>
> If people wanted six-ring binders they would be available.
Yes, this is often the case. I need/want something to...
and someone else makes it for me. However, the reverse
also happens. Take a look at those Post-It Notes(tm). A
guy at 3M invented them, and thought they were handy and
cool. Nobody outside of 3M did though, until 3M literally
gave large quantities away. At that point, people had them
laying around and used them. THEN they realized they couldn't
live without them and started buying like crazy.
Xerox had the same problem with copiers. Nobody wanted to
buy them, so instead of selling the machines, Xerox rented
them out by per-page usage. Companies would not have to pay
a cent if the machine went unused. Most companies spent more
in a month or two of rental than they would have spent buying
the stupid things outright. However, these companies didn't
believe the need was present, and didn't want to risk the
money that they would have much of a use for it in the future.
In these cases, having a supply created the demand. I never
believed this when my economics prof. tried to explain it.
The demand creates the supply was easy for me to grasp, but
there was never any good explaination or example for the supply
creates the demand scenario, "just take my word for it..." I
didn't have much faith in "those kinds of fields" to start with,
being the CS/EE type, and that kind of response didn't help.
I wish she had used an example like this one to explain it.)
Erik Naggum
* David Hanley
| Once again, you fail to understand the issue. People wanted something to
| keep their papers together, so binders were created. Binders didn't come
| along, and provoke people to say, "Gosh, I need to keep papers
| together!"--that just not how the creative process works.
sigh. you don't understand what I'm saying, and consistently argue against
some exceptionally silly points that _nobody_ has _ever_ made. it is
obivously a religion to you to believe in "consumer power", so there's no
point in demonstrating the silliness of what you believe others are saying
nor in pointing out that once you get past those silly beliefs, your own
arguments boil down to exactly nothing.
Bill House
David Hanley <da...@nospan.netright.com> wrote in article
<3368E3...@nospan.netright.com>...
>
>[snip a bunch of tit for tat]
>
> Once again, you fail to understand the issue. People wanted something
> to keep their papers together, so binders were created. Binders didn't
> come along, and provoke people to say, "Gosh, I need to keep papers together!"--that
> just not how the creative process works.
>
Geez, guys...
How about this -- there are (at least) two dynamics to this issue, and both are valid
at different times, under different circumstances.
Nobody knew they wanted phonographs, but as soon as Edison invented and marketed them,
eveyone had to have one. This is the invention-driven dynamic that Erik speaks of.
OTOH, once people knew about phonographs, they started wanting improvements -- better
sound, better looks, more ergonomic designs, less inconvenient media... Finally, we end
up with the CD. This is the consumer-driven dynamic that David sees.
Both are valid. In fact, they tend to be related (as in my examples).
As to how this might relate to the thread topic, well, I guess someone is saying that
Lisp is not in demand, so it's not worth pursuing. That's silly (IMO). Most people have
never used the language, so they don't really know if they want it or not.
David Thornley
In article <01bc56c1$a6af1460$03d3c9d0@wjh_dell_133.dazsi.com>,
Bill House <bho...@dazsi.nospam.com> wrote:
>David Hanley <da...@nospan.netright.com> wrote in article
><3368E3...@nospan.netright.com>...
>>
>>[snip a bunch of tit for tat]
>>
>> to keep their papers together, so binders were created. Binders didn't
>> come along, and provoke people to say, "Gosh, I need to keep papers together!"--that
>> just not how the creative process works.
>>
>
>How about this -- there are (at least) two dynamics to this issue, and both are valid
>at different times, under different circumstances.
>
important than others. I think Erik is generally in the right on
this one.
>Nobody knew they wanted phonographs, but as soon as Edison invented and marketed them,
>eveyone had to have one. This is the invention-driven dynamic that Erik speaks of.
>
Yup.
>OTOH, once people knew about phonographs, they started wanting improvements -- better
>sound, better looks, more ergonomic designs, less inconvenient media... Finally, we end
>up with the CD. This is the consumer-driven dynamic that David sees.
>
However, in the marketplace, there's a difference between a vague
consumer want and economic demand. People wanted better phonographs,
true. Most of them went no further than that. They wanted something
better than wax cylinders, better sound, something that would look better,
etc. What happened is that inventors and manufacturers produced things
to supply that demand.
No consumer group came along and thought, "Gee, with modern technology
you could encode sound information digitally on little disks with teensy-
weensy holes". What happened is that some enterprising people figured
it out and started making some. The advantages to the consumer were
considerable and obvious, and in not too long a time they almost
completely destroyed a very large and mature industry.
Partly, of course, because they only destroyed part of it. The record
companies had to switch their physical product, gradually, but not
their other activities.
The consumer-driven dynamic is very vague and often unpredictable.
If you can identify something consumers want, and can supply it, you'll
win big. This is very, very rare. It does happen; no advertising
campaign was going to slow down CDs or electronic spreadsheets.
Nor is this a direct consequence of consumer demand.
Most economic activity, on the other hand, is directed at less explosive
thing. For example, I needed a car. I wanted it to carry three adults
and a toddler comfortably, and I wanted reliability. There's lots of
cars out there that satisfy those criteria, and I had no other strong
criteria. I had the choice of quite a few different sorts of car,
and made my decision by getting a pretty good deal. There's all sorts
of other ways it could have been made, and making sure I pick one way
or another is a multibillion dollar industry that supports some of the
neatest visual effects I've seen on TV.
>Both are valid. In fact, they tend to be related (as in my examples).
>
I agree with Erik, primarily, though. The choice of exactly what a
consumer buys has little to do with technical merit, and much more
with presentation.
>As to how this might relate to the thread topic, well, I guess someone is saying that
>Lisp is not in demand, so it's not worth pursuing. That's silly (IMO). Most people have
>never used the language, so they don't really know if they want it or not.
>
This is the problem. It is my opinion that, if college students were
required to do significant work in Lisp, that many of them would develop
a permanent desire to program in it. (Others may disagree.) On the
other hand, more procedural languages are pushed hard everywhere else,
and it's, frankly, easier to find said procedural languages. If
somebody programming a Mac asks "What programming system should I get?",
the answers "Metrowerks Codewarrior", "Get a real computer, kid", and
"Is Apple still in business?" are going to be far more popular than
"Macintosh Common Lisp". Further, unless the newbie is a student,
Codewarrior costs about $400 to give the same basic capabilities as
MCL's $1000 package. (Note that the 15-minute demo Digitool distributes
is not going to help much. Few people will realize Lisp's potential in
15-minute segments. I prefer Franz's policy with ACL Lite: don't
allow any sort of file compilation.)
Now, if I were running the world, Scheme would be pushed as a first
language rather than Basic, and Lisp would be pushed as a production
language instead of C++, and many other weird things would happen.
Until something like that happens, Lisp is going to have to survive
as a fringe language.
David Thornley
Dave Dyer
There are two big reasons why Symbolics and Genera failed, they both amount
to the same thing; that a small company, making hardware or software, can't
keep up with the entire rest of the industry.
That's why a "Lisp operating system" is a doomed idea. Lisp as a giant,
monolithic application is less seriously impaired, but suffers from the
same problem. Lisp as a well integrated part of an existing operating
system would be a fine idea; but the feature set of Lisp makes it intrinsicly
difficult to integrate that way.
--
My home page: http://www.andromeda.com/people/ddyer/home.html
Kelly Murray
In article <ddyer-02059...@192.0.2.1>, dd...@netcom.com (Dave Dyer) writes:
>>
>> There are two big reasons why Symbolics and Genera failed, they both amount
>> to the same thing; that a small company, making hardware or software, can't
>> keep up with the entire rest of the industry.
No, a small company can become a big one if they do things right.
Symbolics didn't do things right.
They failed to pursue market share and volume sales
and they didn't have any low-cost way to delivery the wonderful applications that
people created with their machines.
The world has changed a whole lot since then.
>>
>> That's why a "Lisp operating system" is a doomed idea. Lisp as a giant,
>> monolithic application is less seriously impaired, but suffers from the
>> same problem.
Which is what? A small companies LispOS or Lisp application can't keep up?
>> Lisp as a well integrated part of an existing operating
>> system would be a fine idea; but the feature set of Lisp makes it intrinsicly
>> difficult to integrate that way.
>>
Shall I assume then you are offering two choices,
1. continue the difficult job of integrating with existing OS
or 2. give up on Lisp
? Please clarify.
-Kelly Murray (speaking for myself)
Bill Gooch
Dave,
Full agreement. But, has anyone else heard the rumor
that Micro$haft is going to implement a 64-bit OS, with
correspondingly enlarged address space??? If it's true,
this could be a nice vehicle for (dare I say it) Open
Genera....
Dave Dyer wrote:
>
> There are two big reasons why Symbolics and Genera failed, they both amount
> to the same thing; that a small company, making hardware or software, can't
> keep up with the entire rest of the industry.
>
> That's why a "Lisp operating system" is a doomed idea. Lisp as a giant,
> monolithic application is less seriously impaired, but suffers from the
> same problem. Lisp as a well integrated part of an existing operating
> system would be a fine idea; but the feature set of Lisp makes it intrinsicly
> difficult to integrate that way.
--
Bill Gooch goo...@flash.net
David Hanley
Bill House wrote:
>
> Both are valid. In fact, they tend to be related (as in my examples).
This is true. What I am arguing agains is that needs can be created,
in feilds aside from entertainment and fashion.
> As to how this might relate to the thread topic, well, I guess someone is saying that
> Lisp is not in demand, so it's not worth pursuing. That's silly (IMO). Most people have
> never used the language, so they don't really know if they want it or not.
Not at all. What I'm saying is that there are some things in demand in
the computer world right now, among them, portability, distributed
computing, etc.
The ideas a lot of people have for the LISP OS, in my opinion, would
make
the lisp OS idea incompatible with current markety trends.
This sub-thread has a lot of similaraity to the 'why lisp failed'
thread.
Most of us agree that lisp is better than, say, C, for many application
domains.
Most of us recognize that C/C++ has been more sucessful, even in many of
these
domains.
What we disagree is why this is.
I argue that that the C/C++ people have been more sucessful at
identifying what
users ( programmers, really ) want and will use, then producing it.
If I understand the other side of the arguemnt ( erik, really ) he/they
are arguing that C/C++ has has better marketing which has convinced
programmers that C/C++ is what they want and need.
This has gone around in circles quite a bit, and doesn't seem to really
go anywhere.
I still stand by my original statement: The best possible thing that
could happen to the lisp community would be the creation of a lisp or
lisp-like system, with a good grapical designer, that compiled to java
bytecodes.
Right away, lisp people could begin making applets, and portable apps,
which are much in demand right now.
It might mar the technical purity of lisp--but so what?
dave
Dave Dyer
>
>No, a small company can become a big one if they do things right.
>Symbolics didn't do things right.
>They failed to pursue market share and volume sales and they didn't
>have any low-cost way to delivery the wonderful applications that
>people created with their machines.
>The world has changed a whole lot since then.
>
Symbolics spent about $100 million of investors money, in addition
to many millions that willing customers paid for their products at
prices that made accountants weep. (100K for a personal machine?)
It's possible to argue that they could have done better, but not that
they didn't try to develop a delivery strategy that would have enabled
them to break into a more mass-market set of economics.
Lisp's market handicap was, and is, that it just isn't feasable to
use lisp to develop a small application for delivery to endusers.
Lisp's developer handicap was, and is, that its interoperability with
the rest fo the world is poor.
Part of the problem is a self-perpetuating cycle - not enough users
means not enough base to spread the costs. The Symbolics/TI/LMI
lisp machine era was a heroic effort to break out of that cycle,
which failed. The experiment doesn't need to be repeated, at least
until someone repeals Moore's law, or some similar phase-change
in the industry opens another window of opportunity.
Chris Bitmead uid(x22068)
mik...@engr.sgi.com (Mike McDonald) writes:
> >> this is another common misconception. what people "want" is a function of
> >> what they learn is available. e.g., do Americans want three-ring binders,
> >> and Europeans four-ring binders?
> >
> > But you have to admit that four-ring binders simply are much easier
> > to use and easier to maintain!
>
> Ha! That redundant ring costs money to manufacture and increases the chances
> of bent or broken rings! The ideal binder would have only two rings or one big
> clamp. :-)
You're both wrong. Binders should be abandoned altogether in favour of
the paperless office.
Kelly Murray
>Lisp's market handicap was, and is, that it just isn't feasable to
>use lisp to develop a small application for delivery to endusers.
This is certainly true if the endusers have UNIX and not a LispM!
It is taken for granted today that everyone uses UNIX or DOS/MS-WINDOWS
Back in 1980, this wasn't the case. It turned out that way, but
history could have turned out different. In that case, one COULD
deliver a small application to a LispM enduser, which could be packaged
as a "defsystem" in a fasl file.
> which failed. The experiment doesn't need to be repeated, at least
> until someone repeals Moore's law, or some similar phase-change
> in the industry opens another window of opportunity.
Would you consider the explosion of the world wide web a phase-change?
Dave Dyer
>> which failed. The experiment doesn't need to be repeated, at least
>> until someone repeals Moore's law, or some similar phase-change
>> in the industry opens another window of opportunity.
>
>Would you consider the explosion of the world wide web a phase-change?
Yes, but not one which opens an opportunity for lisp - more of an
anti-opportunity. The web explosion favors communication and
interoperability among small components - not lisp's strengths.
Java does an excellent job of stealing those components of lisp
technology which are ripe for wider application: objects, memory
management, and error handling.
Kelly Murray
OK, I just disagree that the web is not a good opportunity for lisp.
Allow me to ask one final question:
Under what conditions or phase-change or whatever do you see
as being a good or ripe as an opportunity for Lisp?
-kelly edward murray (speaking for myself)
Jeff Barnett
In article <ddyer-02059...@192.0.2.1>, dd...@netcom.com (Dave Dyer) writes:
|> ... stuff deleted ... Lisp as a well integrated part of an existing
|> operating system would be a fine idea; but the feature set of Lisp
|> makes it intrinsicly difficult to integrate that way.
Hi Dave,
I think you might have two experience points in mind: (1) the
shove-it-in-the-ass-of-a-Sun Symbolics UX boards and (2) open
Genera for the Dec Alpha. These are two amazingly different
approaches that, I believe, are both painted by the brush above.
Do you think one approach is better/worse as far as the topic
of this thread?
Jeff Barnett
Bradford W. Miller
> >> which failed. The experiment doesn't need to be repeated, at least
> >> until someone repeals Moore's law, or some similar phase-change
> >> in the industry opens another window of opportunity.
> >
> >Would you consider the explosion of the world wide web a phase-change?
>
> Yes, but not one which opens an opportunity for lisp - more of an
> anti-opportunity. The web explosion favors communication and
> interoperability among small components - not lisp's strengths.
Why do components have to be small? If I have a web interface to my
software, it could be running on a CRAY, the web user is insulated from
this.
In all the web is a large equalizer, IMHO. It has distinct advantages for
software distribution as well, namely that there doesn't need to be any:
the software stays in house, and only the interface need be transmitted
(via the web). That also makes debugging a lot easier - you don't need to
worry about the customer environment, except for the presentation portion
of the application.
Dave Dyer
>Allow me to ask one final question:
>Under what conditions or phase-change or whatever do you see
>as being a good or ripe as an opportunity for Lisp?
>
It's hard to guess, but how about this one: Moore's law remains
in force for another 20 years, making computation so cheap and
plentiful that the only significant consideration is the algorithm
to be implemented (ie; NP-Hard is still hard). Simultaneously,
advances in AI have led to development of significantly useful
intellegent agents.
(and the moon is discovered to be made of Green cheese, at about the
same improbability level, at least in the 20 year time frame)
Dave Dyer
>
>I think you might have two experience points in mind: (1) the
>shove-it-in-the-ass-of-a-Sun Symbolics UX boards and (2) open
>Genera for the Dec Alpha. These are two amazingly different
>approaches that, I believe, are both painted by the brush above.
>Do you think one approach is better/worse as far as the topic
>of this thread?
>
>Jeff Barnett
The coprocessor approach, both UX and Macivory, are good models
because they "render unto ceasar" the tasks which they
are good at, and at least in principle allow you to use the tools
of choice on the platform. "Peaceful coexistance" is a good
model for how they worked - not really integrated into the
environment, but at least available simultaneously. Once you
peacefully coexist, you can at least start thinking about active
cooperation.
Open genera is a bad model, because if your alpha is running
open genera, it's no longer an alpha for any other practical
purpose. Lisp is stuck implementing windows, disk, networking
and all those other things, and you can't run your favorite
alpha applications.
Joerg Hoehle
Hi Marcus,
Marcus Daniels (mar...@sayre.sysc.pdx.edu) wrote:
: CLISP has a configuraton that uses wide pointers (and works with DEC Alphas).
: Surely there are others..
Does it have fixnums that are 60 or 56 bits long there, unlike the
CLISP -DWIDE versions on 32 bit processors that uses 32 bits for data
and 32 bits for type (of which 24 are wasted)?
Jo"rg Ho"hle.
Joerg....@gmd.de