Newsgroups: comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!rochester!cornellcs!newsstand.cit.cornell.edu!portc01.blue.aol.com!news-res.gsl.net!news.gsl.net!news-peer.gsl.net!news.gsl.net!usenet.eel.ufl.edu!spool.mu.edu!howland.erols.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: <DxwHvB.1nI.0.macbeth@cogsci.ed.ac.uk>
Organization: HCRC, University of Edinburgh
References: <DxGrGL.ED.0.macbeth@cogsci.ed.ac.uk> <199609110907.a28920@ms3.maus.de>
Date: Tue, 17 Sep 1996 23:42:46 GMT
Lines: 77

In article <199609110907.a28920@ms3.maus.de> Georg_Bauer@ms3.maus.westfalen.de (Georg Bauer) writes:
>Hi!
>
>JD>How easy is it to use the :somename package after that?
>JD>[Hint: it depends on exactly how SORT works]
>
>Of course - if you use _destructive_ routines, it destructs the structure.
>Works as designed. That has nothing to do with memory-protection. If you
>intentionally hit the power-switch, the machine will go down, regardless of
>any memory protection scheme.

No kidding.  So what?

My point was that type checks, including the run-time checks on Lisp
machines, don't prevent me from messing things up in the way I
described.  Then, on a Lisp machine, all I have is the Lisp.  If I
mess it up, I have to try to fix it, or I have to reboot or something
similarly "heavy".  With an ordinary OS, I can quit Lisp and start it
again while everything else continues to work.  Moreover, my other
Lisp processes continue to work.  (Yes, I often run > 1 Lisp at once.)
Since they don't share memory, messing up a package in one doesn't
mess it up in the others.

>The point is, you can't access the memory and bypass the typechecking of
>the hardware - like you can do easily in assembler for example. Lisp
>doesn't have a notion of a pointer, but more of a reference - it's a
>reference to a location in memory (that can be changed, of course), but
>that always carries a typetag with it. So you can only access the location
>in appropriate ways - and sort is a appropriate way to access a list (and
>if it is defined as being destructive, it will sort it in-place).

But that's *why* the type check doesn't stop me from messing
things up in the way I described.  That's why I picked SORT
for my example rather than something that would be stopped
by type checks.

>JD>Now, when I mess things up in certain ways, I like being able to
>JD>kill Lisp and start over w/o rebooting my machine
>
>No problem with Symbolics or Interlisp-D. In Interlisp-D for example I have
>several ways. One is the undo, ok, that has some limitations. Then there is
>the possibiliy to do a (logout t) and drop all changes and revert to the
>last saved state. Under Symbolics I can do my experiments in a
>incrementally world and just drop the last incremental part. Or on both
>systems I can use the versioning facilities (Interlisp-D only on the Xerox
>machines and only for files).

Undo is great when it works.  Reverting to the last saved state is 
too much like rebooting and gets me involved with saved states,
which I'd rather avoid.

>JD>the reasons I prefer the standard OS approach.  (Yes, I know
>JD>I could probably patch up the :somename package in various ways.)
>
>No need to patch up the package, under normal conditions.

How else am I supposed to fix the package-use-list?

>   And of course: if
>you do a rm -r -f on a unix machine while logged in as root, you surely
>will mess up the system a bit, too. If the user breaks the machine it will
>be broken. Nothing special about that - happens on all systems.

Come on.  That's a _terrible_ argument.  I shouldn't care about
getting rid of a problem because some other problems remain?
Your logic here escapes me, I must say.

And we've been here before:

>JD>So what?  Surely you don't believe that imperfect implies useless.
>
>No. But it's a bit funny to allow your favored OS the imperfectness, but
>don't allow it the lisp-machines.

I allow it; I just don't _prefer_ it.

-- jd
