Path: utzoo!utgpu!water!watmath!clyde!ima!think!barmar
From: barmar@think.COM (Barry Margolin)
Newsgroups: comp.lang.lisp
Subject: Re: lisp environments summary
Message-ID: <13427@think.UUCP>
Date: 10 Dec 87 20:28:45 GMT
References: <1254@vaxb.calgary.UUCP> <339@siemens.UUCP>
Sender: usenet@think.UUCP
Reply-To: barmar@sauron.think.com.UUCP (Barry Margolin)
Organization: Thinking Machines Corporation, Cambridge, MA
Lines: 32

In article <339@siemens.UUCP> steve@siemens.UUCP (Steve Clark) writes:
>In article <1254@vaxb.calgary.UUCP> jameson@calgary.UUCP (Kevin Jameson) writes:
>>References: <613@umbc3.UMD.EDU> <325@siemens.UUCP>
>>Editing Lisp functions as text and then loading them into the environment
>>is also a method with many advantages.
>>
>>Stallman addresses this exact issue in Interactive Programming Environments
>>(Barstow/Shrobe/Sandewall, McGraw Hill 1984).
>> 7. It allows smooth changes to operational parts of the Lisp 
>7. I don't really understand this point.

I think this one assumes that the changes to structures and functions
are made as you type them.  This would make it difficult to edit
functions that are part of the Lisp terminal interface.  If you need
to make two changes to a function that is part of the keyboard driver,
in between those two changes the keyboard driver ceases to work and
you can't make the second change.  Even if changes are only reflected
in the environment when you finish editing a function, this means that
you can't make such changes if they require coordinated changes to
multiple functions.

This argues just as much against structure editing as it does against
the single-address-space style of Lisp Machines.  However, I find the
single-address-space style so much of a win that I think it is worth
the potential problems you can have.

---
Barry Margolin
Thinking Machines Corp.

barmar@think.com
seismo!think!barmar