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