Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!rutgers!sri-unix!quintus!pds From: pds@quintus.UUCP (Peter Schachte) Newsgroups: comp.lang.lisp Subject: Re: lisp environments summary Message-ID: <445@cresswell.quintus.UUCP> Date: Tue, 8-Dec-87 15:04:48 EST Article-I.D.: cresswel.445 Posted: Tue Dec 8 15:04:48 1987 Date-Received: Sun, 13-Dec-87 06:44:33 EST References: <613@umbc3.UMD.EDU> <325@siemens.UUCP> <323@spar.SPAR.SLB.COM> Organization: Quintus Computer Systems, Mountain View, CA Lines: 65 Keywords: Interlisp, Editing, Files Summary: Interlisp's problems are not essential problems with incore development In article <323@spar.SPAR.SLB.COM>, malcolm@spar.SPAR.SLB.COM (Malcolm Slaney) writes: > In article <325@siemens.UUCP> steve@siemens.UUCP (Steve Clark) writes: > > You edit your functions > > in Lisp, and when you want to save them you write them out to files. > Perhaps this works well for pure Xerox users but I spent last week porting > some software that already runs on Symbolics and Suns to a Xerox machine > and found it didn't work. > > The most fundamental problem is that our code has a number of #+ and #- > constructs to fix shortcomings/differences in the different versions of lisp. > If we read the definining file into the Interlisp environment we lost all > but the conditionals that were appropiate for the Xerox machine. This really This is indeed currently a problem with Interlisp. However, it is not an essential problem with developing code incore and writing files out periodically. The problem here is that there are some constructs (eg comments, read macros) that drop part of your file on the floor. In an incore system, any information you loose on loading is gone forever. Unfortunately, CommonLisp does not accomodate incore development very well, because it encourages dropping things on the floor. An incore system could define versions of defined lisp primitive constructs (comments, read macros) that would hold on to the necessary information so it could be written out later. Unfortunately, nothing can be done about user-defined read macros that throw away information. This is a flaw in CommonLisp. It could be fixed by giving users officially endorsed facilities for throwing away text and structures that give the environment an oportunity to keep it from being lost altogether. The issue of incore vs. file-based code development is addressed in "Programming in an Interactive Environment: The LISP Experience" by Erik Sandewall in _Interactive_Programming_Environments by Barstow, Shrobe, and Sandewall. The debate between Sandewall and Richard Stallman at the end of the chapter is particularly interesting. I do find incore development particularly comfortable. A good structure editor can make coding much easier than I have ever found text-based editing. The information quickly available to an incore development system (e.g., the arguments required by a given function you wrote months ago, the fields of a data structure you defined, etc.) make development that much easier. Another place a structure editor wins is in the manipulation of structures. Yes, text editors can provide facilities for paren-matching, and even moving over s-expressions. But I have yet to see a text editor that will allow me to delete, move, or copy an s-expression by simply pointing to it (anywhere in it) with my mouse. It is hard to overstate the power of this simple facility. Its power lies in its simplicity. Nonbelievers should spend an hour or two using Xerox's new SEdit structure editor. Compare ease of use and ease of learning for entering and editing Lisp code to EMACS, and I think there will be many converts. As it stands now, SEdit has several shortcomings, many of which COULD be fixed. > I was > told that there were no text editors available in the Interlisp environment. Not true. The Interlisp-D library includes TEdit, a WYSIWYG document editor, which can be used as a text editor. Granted, it is as convenient or efficient as a convential text editor, but it IS there and it DOES work. -- -Peter Schachte pds@quintus.uucp ...!sun!quintus!pds