Newsgroups: comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!bb3.andrew.cmu.edu!nntp.sei.cmu.edu!news.cis.ohio-state.edu!math.ohio-state.edu!cs.utexas.edu!nntp.primenet.com!cam-news-hub1.bbnplanet.com!cpk-news-feed2.bbnplanet.com!cpk-news-hub1.bbnplanet.com!newsfeed.internetmci.com!in3.uu.net!EU.net!usenet2.news.uk.psi.net!uknet!usenet1.news.uk.psi.net!uknet!uknet!newsfeed.ed.ac.uk!edcogsci!jeff
From: jeff@cogsci.ed.ac.uk (Jeff Dalton)
Subject: Re: Common LISP: The Next Generation
Message-ID: <DxGrGL.ED.0.macbeth@cogsci.ed.ac.uk>
Organization: HCRC, University of Edinburgh
References: <3050697124719056@arcana.naggum.no> <50hpv8$6vh@news.jf.intel.com> <joswig-0309962353020001@news.lavielle.com>
Date: Mon, 9 Sep 1996 11:48:20 GMT
Lines: 90

In article <joswig-0309962353020001@news.lavielle.com> joswig@lavielle.com (Rainer Joswig) writes:
>In article <50hpv8$6vh@news.jf.intel.com>, haertel@ichips.intel.com (Mike
>Haertel) wrote:
>
>> In article <3050697124719056@arcana.naggum.no>,
>> Some of us like the additional protection afforded by running
>> different programs in different address spaces.  While I'm sure
>> the historical Lisp machines were more robust than MS-DOS, they
>> were still a helluva lot easier for a beginner to hose than a
>> typical Unix.
>
>Well, these machines offer a lot "memory protection" at the
>lowest levels: object access is "secure". That is
>Lisp machines usually don't access memory as a sequence
>of bytes. Lispms have an idea about arrays, objects,
>numbers, strings, ... These are all real objects and
>not some faceless sequence of bits. So the Lisp processor
>checks access and modification of the data in memory (also
>checks array bounds, number overflow, ...).

Here's something I tried the other day:

  (values-list (sort (package-use-list (find-package :somename))))

How easy is it to use the :somename package after that?
[Hint: it depends on exactly how SORT works]

Treating all the objects involved as objects didn't stop me from
messing them up.  (Note to ML fans: nor would static typing have
helped.)

Now, when I mess things up in certain ways, I like being able to
kill Lisp and start over w/o rebooting my machine -- just one of
the reasons I prefer the standard OS approach.  (Yes, I know
I could probably patch up the :somename package in various ways.)

>Compare that to typical machines today. You need memory protection
>for processes, otherwise these stupid C software would overwrite
>arbitrary memory. Result: code duplication, ugly interprocess
>communication mechanisms, limited reuse, ...
>
>So protection of software via different **address** spaces is not really
>a such a topic on Lispms.

If I could get all the same benefits w/o separate address spaces _as
such_, that would be fine with me.  But that was not what Lisp
machines provided.

Lisp machines were wonderful things, in many ways.  I can see why
someone might prefer them to Unix and the like.  But I happen to
have a different preference.

>> I think what I'd really like would be some sort of checkpoint
>> and rollback feature.  So, if some definition doesn't work, there
>> should be a way to undo it as if it had never happened, up to
>> and including restoring the previous definition if any.

InterLisp undo?  But it had a number of problems, and D-machines
were very easy to mess up.

>> Protected OS's where all programs get their own address space
>> give you a crude way to do this: launch a new program.
>
>Unfortunately different programs share common resources even
>on memory protected Unix systems. Let some software have
>a bug resulting in a crash of your X-Windows server, guess
>how many of these other programs running on your display
>stay up and running? Zero? 

Almost all of them.  Indeed, many are running on a different
machine.

In any case, so what if there are one or two programs that can
mess everything up?  (OS kernel bugs will always be a problem,
for instance.)  Does that mean there's no benefit to keeping
it down to those one or two programs?

>Recently I have seen a machine
>(an IBM RS/6000) crashing because a corrupt file system. Guess
>how many processes stayed up? Zero? On of our SUNs currently
>has twice a months an TCP/IP error. Result: a reboot.
>Years ago there was an OS error on early SPARCstations.
>In a millisecond the monitor changed to complete black,
>and the machine went completely down. It was a bit weird.
>Ironically it was caused by large Lisp systems.

So what?  Surely you don't believe that imperfect implies useless.

-- jd

