alex@umbc3.UMD.EDU (Alex S. Crain) (12/04/87)
Awile back I posted a request on what makes for a good envirnment. I half expected a flood of opinions because of the fierce discussion over 'tool oriented interfaces', etc, that was in progress. Unfortunately this group lacks the persistance of say, sports fans, and I guess people got bored and went back to work. The project started out simple enough, I'm a student for life, working as a freelance consultant (read unemployed :-)), I love lisp, and I recently aquired a small unix box real cheap (AT&T 3b1 on sale). I pulled KCL lisp down in a flash, along with emacs and misc. goodies, hooked it up and started on a SLR parser generator for school. The failings of lisp under emacs showed through immediately. The system is a good start, but is frustrating and slow to do real work under for reasons that I can't put my finger on. As I think that I can stay unemployed for at least another year, I decided to make this into a serious project, (probably reworking every class project to fit) and settled in for the long haul. Now the problem. Judging from the net discussions, Much remains to be done in the way of a workable lisp interface, at least running under UNIX. I gather that the Sun interface is real good BUT...and short of a symbolics or explorer full blown lis machine thats as good as it gets. Add the fact that the suggestions that I got were running from vague to obtuse and getting a grip on the problem is darn difficult for someone with only about 2yrs of lisp programming experiance, all of it on a vax or 3b1 (not enough sun exposer to really have an opinion). SO: The thought for the day... Every lisp system needs a DEBUGGER that WORKS. KCL comes with a debugger that is exactly i step up from worthless, in that you can dump the stack, but not the tags for the bindings. there are a batch of diff files for it that improve things alot, but now the error routines are sometimes inacurate...The general felling that i got was that a full source level debugger is what is desired, and someone suggested a way to back-step the program. this doesn't seem to hard except for recovering old values..I would be interested to know if anyone had implemented this anywhere. Multible chains. I like this, because it means distributing the system and I have limited heap space. But I'm not sure exactly what this means as far as local/global bindings. (perhaps something similar to UNIX fork(), with common bindings up to the fork, local after that?) File system interface. I don't care much for the system access functions available (not that there really are any) under CL, and Im not sure that the directory/file structure is the most natural way to do lisp storage. I have considered a hypertext type of system, binding functions and symbols with text comments, probably as an extension to the CL package facility. This would work well with a source level debugger too...But it needs lots of thought. The screen/keyboard/mouse relationship to programming. The current GNU/KCL combination works with several BUTS thrown in, I'm not sure why. It just seems like there is a better way, althought not an obvious one. What should the mouse DO exactly? the idea of writing a file and sending it to lisp seems wrong, I would want to write my functions and save them when i'm done (I think) One problem is screen size, im basically limited to 24x80 or my eyes burn out in 2 hours trying to read teensy little characters. how to put the most info on the screen has got me stumped. And I don't like the idea of running everything through the editor, lots of overhead in that. This goes on and on, but these are the fundamental problems. right now I'm looking for a starting point (after finals anyway), I figure to lay out a foundation play in january. If anyone has any ideas I would LOVE to hear them, I would also like to talk with anyone who likes to toss around implementation concepts. And of cource if anyone needs something to do for a year or too... :alex. alex@umbc3.umd.edu PS: The debugger enhancements are available from rascal.ics.utexas.edu and are well worth the installation, even if the are a bit unstable. .
steve@siemens.UUCP (Steve Clark) (12/07/87)
In article <613@umbc3.UMD.EDU> alex@umbc3.UMD.EDU (Alex S. Crain) writes: > > Awile back I posted a request on what makes for a good envirnment. > >Every lisp system needs a DEBUGGER that WORKS. KCL comes with a debugger that Yes, both a code debugger (print stack frames) and a data debugger (normally called an inspector), and of course you should be able to point at a datum in a stack frame and get an inspector on it, etc. >Multible chains. I like this, because it means distributing the system and I >have limited heap space. But I'm not sure exactly what this means as far as >local/global bindings. (perhaps something similar to UNIX fork(), with common >bindings up to the fork, local after that?) That sounds fine, doable, and workable. (Although I don't understand how heap space relates.) Interlisp-D does this for its multiple-process capability, although there is only one level at which new processes fork. >File system interface. [...] I have considered a hypertext type of system, [...] >the idea of writing a file and sending it to lisp seems wrong, <enter soapbox mode> The correct way to deal with files and storing your lisp code is essentially the way Interlisp does it. You edit your functions in Lisp, and when you want to save them you write them out to files. Furthermore, a file is treated as a database of definitions - function definitions, record definitions, data definitions, etc. etc., and the system keeps track of what you change and where it belongs and lets you know what files need to be rewritten. (This is the equivalent to Unix "make" for a system where you edit things "in core".) Unfortunately, CL has the wrong idea of files & editing somewhat wired into it. <end soapbox mode> You also made some remark about needing a Symbolics or an Explorer. If your interest is environment (rather than megamemory, megaspeed, or megabucks), you should consider the Xerox D-machines. They are vastly underrated. -Steve Clark, steve@siemens.com (or @siemens-rtl.com)
malcolm@spar.UUCP (12/07/87)
In article <325@siemens.UUCP> steve@siemens.UUCP (Steve Clark) writes: > The correct way to deal with files and storing your lisp code is > essentially the way Interlisp does it. 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 makes it hard to write code that must run on other machines. Our solution was to edit the files (using a nearby MAC) on the file server and then reread the files into Interlisp. Not a good solution. I was told that there were no text editors available in the Interlisp environment. Malcolm
steve@siemens.UUCP (Steve Clark) (12/08/87)
In article <323@spar.SPAR.SLB.COM> malcolm@spar.UUCP (Malcolm Slaney) writes: >In article <325@siemens.UUCP> steve@siemens.UUCP (Steve Clark) writes: >> The correct way to deal with files and storing your lisp code is >> essentially the way Interlisp does it. 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. [...] > Malcolm Good point. I maintain that the non-Interlisp systems are wrong, however. It is clearly more advanced to treat a file as a database of definitions of functions, data, structures, etc. than to treat it as a string of characters that might have been typed at the keyboard. However, since the rest of the world hasn't caught up yet, there are bound to be incompatibilities. Note: I don't claim the Interlisp system is perfect; far from it! Also, there IS a text editor in Interlisp-D: TEDIT. -Steve
fawcett@gort.rutgers.edu (Tom Fawcett) (12/08/87)
Posting-Front-End: GNU Emacs 18.47.23 of Wed Sep 2 1987 on gort.rutgers.edu (berkeley-unix)
In article <325@siemens.UUCP> steve@siemens.UUCP (Steve Clark) writes:
The correct way to deal with files and storing your lisp code is
essentially the way Interlisp does it.
Spoken as if opinion were fact.
You edit your functions
in Lisp, and when you want to save them you write them out to files.
Furthermore, a file is treated as a database of definitions - function
definitions, record definitions, data definitions, etc. etc., and the
system keeps track of what you change and where it belongs and lets you
know what files need to be rewritten. (This is the equivalent to Unix
"make" for a system where you edit things "in core".)
The Symbolics/Explorer/Common Lisp view of files also supports these things,
only in a different way. The D-machine way is to require that all changes
and manipulations of code be done through Interlisp (rather than in a text
editor), and in that way it is, as you say, like a database system for code.
The Symbolics/Explorer approach is to give you a powerful set of tools
linking the text editor to the lisp environment.
Unfortunately, CL has the wrong idea of files & editing somewhat wired
into it.
As I've said: different, not wrong. Speaking as someone who has worked with
both D-machines and Symbolics machines, there are very definite drawbacks to
the D-machine point of view. The problems come when you try to do anything
even slightly unusual. The D-machine facilities *require* that you do all
file/code manipulations through them; if you ever want to do something out
of the ordinary, you have quite a hassle, which is exacerbated because all
the utilities talk to one another. With the Symbolics/Explorer approach it
usually isn't as bad, because the system doesn't demand that you do all
operations in a fixed way.
I should point out that these differences are the result of different
fundamental philosophies. Xerox D-machines have a tradition (from
Interlisp-10) of being a complete lisp environment: everything you do should
be done from inside the Interlisp system. The Symbolics/Explorer/Common
Lisp systems come from an opposite tradition, of having a lisp environment
and several external tools, one of which is a text editor. Which you prefer
is simply a matter of choice. However, it seems that Common Lisp has
adopted the Symbolics/Explorer paradigm, so chances are that it will
eventually dominate.malcolm@spar.SPAR.SLB.COM (Malcolm Slaney) (12/08/87)
In article <323@spar.SPAR.SLB.COM> I wrote > >Our solution was to edit the files (using a nearby MAC) on the file server >and then reread the files into Interlisp. Not a good solution. I was >told that there were no text editors available in the Interlisp environment. Oops, both leo@neptune.CS.UCLA.EDU (Leonid V. Belyaev) and psuvax1!fritzson (Richard Fritzson) have corrected me. There is a text editor called TEdit available on the Xerox D machines. I haven't used it yet so I can't tell you anything about it. Malcolm
pds@quintus.UUCP (Peter Schachte) (12/08/87)
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
welch@tut.UUCP (12/09/87)
>Our solution was to edit the files (using a nearby MAC) on the file server >and then reread the files into Interlisp. Not a good solution. I was >told that there were no text editors available in the Interlisp environment. I'm afraid someone told you wrong. There's a very nice text editor available in the Interlisp environment, called Tedit (as opposed to Sedit or Dedit, the structure editors). ...arun ---------------------------------------------------------------------------- Arun Welch Lisp Systems Programmer, Lab for AI Research, Ohio State University welch@ohio-state.{CSNET,ARPA}
andy@rocky.STANFORD.EDU (Andy Freeman) (12/09/87)
In article <329@siemens.UUCP> steve@siemens.UUCP (Steve Clark) writes: >Good point. I maintain that the non-Interlisp systems are wrong, however. >It is clearly more advanced to treat a file as a database of definitions of >functions, data, structures, etc. than to treat it as a string of characters >that might have been typed at the keyboard. However, since the rest of the >world hasn't caught up yet, there are bound to be incompatibilities. The world will always have incompatibilities. Systems which can not manipulate "foreign" definitions are doomed to niches and eventually die, as has happened to InterLisp. -andy -- Andy Freeman UUCP: {arpa gateways, decwrl, sun, hplabs, rutgers}!sushi.stanford.edu!andy ARPA: andy@sushi.stanford.edu (415) 329-1718/723-3088 home/cubicle
ok@quintus.UUCP (Richard A. O'Keefe) (12/09/87)
Peter Schachte and I work at the same place, and some-times on the same
project. I have a Xerox Lisp Machine in my office. Love it. HATE the
file manager. If you are used to developing code with a text editor like
EMACS and then slurping it in, coming to grips with the file manager can
be very painful and very counter-intuitive.
I think it is worth pointing out that there are things that the
in-core/structure-editor approach cannot handle, and that is #+ stuff
where the code to be skipped on a particular system includes constructs
which that system cannot represent. For example,
(setq eps
#+(feature large-exponents-available) 1.0e-999
#-(feature large-exponents-available) 1.0e-38
)
This actually is an issue if you want to write numerical functions in Lisp,
where the tolerance to be used depends on the precision available. (There
are better ways to do this, the point is that this is a reasonable thing
to do and that it involves numbers which some Lisps can't represent.)
One problem with the old Interlisp way of doing things was that they
hadn't really taken the file-as-data-base idea sufficiently seriously,
and tried to represent the things saved in a file manager file as TEXT.
I have lost count of the number of times I have had a variable held in
a file manager file where the code has failed because an array or record
was written out as {TYPENAME}ADDRESS which then read back as a LITATOM.
Doing a proper job of the file-as-data-base idea means having a data base
which is not affected by current syntax tables or packages and where
the utility that writes stuff out checks that nothing is written which
cannot be read back.
Now that we have the Lyric release, Peter Schachte and I can compromise.
I can write files in Common Lisp syntax (on a SUN using an EMACS lookalike,
with the D-machine talking TCP/IP to the SUN, or on the D-machine with
TEDIT), test them on the D-machine, and then hand them over to him. He
can convert them to the file manager, and we're both happy.
Even so, I reckon that the D-machines with Xerox Common Lisp are a nice
environment.jameson@calgary.UUCP (Kevin Jameson) (12/09/87)
References: <613@umbc3.UMD.EDU> <325@siemens.UUCP>
The Interlisp method of editing functions in the lisp environment and
saving them at the discretion of the user is not the only approach.
Editing Lisp functions as text and then loading them into the environment
is also a method with many advantages. This method has been sucessfully
used by a long line of MIT editors and Lisp environments
(MacLisp, Lisp Machine, Eine, Zwei, Multics Emacs, and probably others
which I don't know about).
Stallman addresses this exact issue in Interactive Programming Environments
(Barstow/Shrobe/Sandewall, McGraw Hill 1984). He points out that the
two real issues are 'whether to edit text or list structure, and whether
to edit the program in the same environment in which it is tested'.
He makes several good points in favor of the text-based editing approach:
1. It allows user-specified indentation
2. Comments are easily stored and formatted as the user likes them.
3. Code need not be properly structured (ie, syntactically correct)
at all times. (This issues is an old one, and is one of the
problems with structured editors such as the CMU ALOE and Cornell
Synthesizers)
4. Balanced editing functions (eg. balance-parens-backward) can
operate on all manner of balanced objects, not just lisp
expressions. Other non-lisp-structure-oriented functions
are also available.
5. It supports extended syntax mechanisms (eg, the quote
facility) which normally destroy the one-to-one mapping
between internal and printed (eg. "(quote foo)") forms. In
the text-based editing approach, the user always deals
with his original representation (eg. 'foo).
6. It allows the editor to be used for other languages, not just
Lisp. (The generality of the Emacs approach is unmatched in
any other programming environment, to the best of my knowledge)
7. It allows smooth changes to operational parts of the Lisp
system itself. "One cannot introduce a bug one moment and fix
it the next without risking a crash." In contrast, changes
are not picked up in a text-based system until the user loads
the modified function.barmar@think.COM (Barry Margolin) (12/09/87)
In article <329@siemens.UUCP> steve@siemens.UUCP (Steve Clark) writes: > I maintain that the non-Interlisp systems are wrong, however. It >is clearly more advanced to treat a file as a database of definitions of >functions, data, structures, etc. than to treat it as a string of characters >that might have been typed at the keyboard. However, since the rest of the >world hasn't caught up yet, there are bound to be incompatibilities. It would not be appropriate for a general-purpose Lisp standard to require the Interlisp style of permanent storage of function definitions. This style requires that a function editor be built into the Lisp system, and this may not be feasible or desirable in all implementations and/or environments. While many Common Lisp implementations do include an editor, at least one notable one (Kyoto Common Lisp) would have a hard time doing so. I also wonder whether the Interlisp database is as powerful as the Common Lisp LOAD style. I'm not very familiar with Interlisp, so bear with me. A file to be loaded can contain other code besides definitions and declarations; it can contain immediate code to be executed. Thus, the file LOAD-EVERYTHING.LISP could contain: (load "first-thing") (load "second-thing") (load "third-thing") (load "last-thing") How is this done in Interlisp? If there is a way to do it, then what's the difference between that and LOAD? The main thing that Common Lisp is missing is an easy way to save out definitions that were defined interactively. Common Lisp was designed primarily by users of Maclisp and its descendents, and they presumed a programming style built around text-file-based editor, so they didn't include such a feature. (Some implementations (e.g. MIT-derived Lisp Machines) provide editor commands to insert interpreted definitions into editor buffers, but this is beyond the scope of Common Lisp to define.) How does Interlisp know which definitions are important to save? I certainly wouldn't want it saving everything, since I constantly create little temporary functions and variables while debugging. If the user has to save functions explicitly it seems like it would be hard to make sure you don't miss some. I'm sure these problems have been solved, since I doubt Interlisp would have survived so long without solutions, but I'm curious how. --- Barry Margolin Thinking Machines Corp. barmar@think.com seismo!think!barmar
steve@siemens.UUCP (Steve Clark) (12/09/87)
In article <653@gort.rutgers.edu> fawcett@gort.rutgers.edu (Tom Fawcett) writes: >In article <325@siemens.UUCP> I wrote: > > The correct way to deal with files and storing your lisp code is > essentially the way Interlisp does it. > >Spoken as if opinion were fact. Of course! MY opinions ARE fact! :-) > You edit your functions in Lisp, [...] > a file is treated as a database of definitions [...] > >The Symbolics/Explorer approach is to give you a powerful set of tools >linking the text editor to the lisp environment. > > Unfortunately, CL has the wrong idea of files & editing somewhat wired > into it. > >As I've said: different, not wrong. and a "good" assembly language gives you a powerful set of tools and features like data structures, looping macros, etc. Does that make "C" just different, not better? >The problems come when you try to do anything >even slightly unusual. The D-machine facilities *require* that you do all >file/code manipulations through them; if you ever want to do something out >of the ordinary, you have quite a hassle, which is exacerbated because all >the utilities talk to one another. The correct hassle is not the hassle of doing what you want in spite of the tools, but rather figuring out how to do it WITH the tools. I worked with Interlisp-D for 2-3 years before I stopped having occasional hassles figuring out how to do what I want WITH the tools. The documentation has improved, but I still hold this against Interlisp. >However, it seems that Common Lisp has >adopted the Symbolics/Explorer paradigm, so chances are that it will >eventually dominate. My problem is that Common Lisp did not have to adopt either paradigm. The designers simply forgot to allow the possibility of anything other than the old files-as-characters-from-the-keyboard paradigm. From: barmar@think.COM (Barry Margolin) )I also wonder whether the Interlisp database is as powerful as the )Common Lisp LOAD style. [...] it can contain immediate code to be executed. Interlisp can too. You can have forms to be executed at load time, or when you write the file, or to be saved on the history list; you can say other files need to be loaded. ) If there is a way to do it, then )what's the difference between that and LOAD? For example, you can tell the system to look at a file, but not actually load it. Then when you want to edit a function in that file, the system selectively loads just that function definition. I guess you can do approximately the same thing with some Emacs/CL environments, but it's just a lot less kludgey a concept. (I DO NOT claim that Interlisp is not kludgey - but a number of its concepts are much cleaner and more advanced than CL, and CL didn't need to preclude them.) )How does Interlisp know which definitions are important to save? It asks you where to put all of the new definitions. This is the most painless part of the system, too. You can name a file, you can say to put it near some other definition (i.e. on the same file), or you can say nowhere. )I constantly )create little temporary functions and variables while debugging. So you put those into a "junk" file. Then if your system crashes or you decide three weeks later you need the same debugging function, you can get it back - but it doesn't clutter anything up. )--- )Barry Margolin )Thinking Machines Corp. ) )barmar@think.com )seismo!think!barmar Steve Clark princeton!siemens!steve steve@siemens.com
welch@tut.cis.ohio-state.edu (Arun Welch) (12/10/87)
>From: barmar@think.COM (Barry Margolin) > >In article <329@siemens.UUCP> steve@siemens.UUCP (Steve Clark) writes: >> I maintain that the non-Interlisp systems are wrong, however. It >>is clearly more advanced to treat a file as a database of definitions of >>functions, data, structures, etc. than to treat it as a string of characters >>that might have been typed at the keyboard. However, since the rest of the >>world hasn't caught up yet, there are bound to be incompatibilities. > >It would not be appropriate for a general-purpose Lisp standard to >require the Interlisp style of permanent storage of function >definitions. This style requires that a function editor be built into >the Lisp system, and this may not be feasible or desirable in all >implementations and/or environments. While many Common Lisp >implementations do include an editor, at least one notable one (Kyoto >Common Lisp) would have a hard time doing so. > Well, yes and no. While a particular function editor can't possibly be built into a general-purpose Lisp standard, more hooks to one can be. Interlisp, in it's native mode, defines a tty-based structure editor, which is pretty powerful in it's own right. Most implementations of Interlisp have then added their own editors on top of the basic environment, for example Interlisp-10 used Emacs, Interlisp-D used Dedit, and now XAIE uses Sedit. Which editor you use is settable by a flag, but the basic effects of the editor remain the same across the board. >I also wonder whether the Interlisp database is as powerful as the >Common Lisp LOAD style. I'm not very familiar with Interlisp, so bear >with me. A file to be loaded can contain other code besides >definitions and declarations; it can contain immediate code to be >executed. Thus, the file LOAD-EVERYTHING.LISP could contain: > >(load "first-thing") >(load "second-thing") >(load "third-thing") >(load "last-thing") > >How is this done in Interlisp? If there is a way to do it, then >what's the difference between that and LOAD? To answer this question, I think it would be best if I start with a quick introduction on how the database works, for those out there who have never worked with an Interlisp system. Every file has a variable associated with it, called the COMS, which is the database. Thus, for the file FOO, there would exist a variable FOOCOMS, which defines what's contained in FOO, what operations to perform when loading foo, etc. Let's say that I want FOO to contain the function definition for the function BAR, the variable definition for the variable BAZ, which has the initial value 5, and for the file RALPH loaded before the file FOO is loaded, and also, for the screen background to be set to the blackshade after FOO is loaded. FOOCOMS would then look like this: ((FILES RALPH) (FNS BAR) (VARS (BAZ 5)) (P (CHANGEBACKGROUNDBORDER BLACKSHADE))) After making the file, if someone were to load the file into their system, it would load the file RALPH, defien the function BAR, and declare thevariable BAZ to have the value 5, and change the screen background to blackshade. It's quite possible that RALPH would do similiar things in its loadup too. A COMS can contain more than just these three sorts of things, like property lists, structure definitiions, etc., but I just thought this would be a good example. SO, to answer the question, there are three ways to have a LOAD-EVERYTHING behaviour. 1) Create a file, whose COMS consist of the database commands to load those files, 2) Have the COMS of the first file load the second through nth files 3) have each file load the next file when it's done loading itself. >How does Interlisp know which definitions are important to save? I >certainly wouldn't want it saving everything, since I constantly >create little temporary functions and variables while debugging. If >the user has to save functions explicitly it seems like it would be >hard to make sure you don't miss some. I'm sure these problems have >been solved, since I doubt Interlisp would have survived so long >without solutions, but I'm curious how. > The simplest way is to call the function (FILES?). This prints out a list of all the things in the system that haven't been written to a file yet, and prompts for files to put them in (You don't have to save things you don't want to, though) . If you've actually been keeping track of what you've defined, you can also insert them into a file without the help of FILES?. After the COMS have been set up, one calls the funciton MAKEFILE to write out the file to disk. If one want's one can call the function MAKEFILES which calls FILES? first, and then remakes all the files which contain changed definitions too. Its kind of unfortunate that the Interlisp philosophy and the Mac/Zeta-lisp philosophies are so different. There are a lot of neat things in Interlisp which will probably go the way of the Dodo, which will be a loss for the language. Interlisp vs. M/Zlisp discussions also tend to carry a fair amount of religion with them, leading to unconstructive interactions... ....arun ---------------------------------------------------------------------------- Arun Welch Lisp Systems Programmer, Lab for AI Research, Ohio State University welch@ohio-state.{CSNET,ARPA}
steve@siemens.UUCP (Steve Clark) (12/10/87)
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). > > 1. It allows user-specified indentation > 2. Comments are easily stored and formatted as the user likes them. > 3. Code need not be properly structured (ie, syntactically correct) > 4. Balanced editing functions (eg. balance-parens-backward) can > 5. It supports extended syntax mechanisms (eg, the quote > facility) which normally destroy the one-to-one mapping > 6. It allows the editor to be used for other languages, not just > 7. It allows smooth changes to operational parts of the Lisp 1. I hate having to do my own indentation, and when I don't have to, I never find the automatic indentation bad enough that I want to override it. 2. does not have to be a big problem - so a structure editor should handle several kinds of comments, and you pick the style you prefer for each one. 3. Especially in Lisp, I think this is a no-op. 4. These are useful in other languages because the other languages don't have structure editors of their own. 5. I agree with 5 100%! Except that my conclusion is to fix the structure editor, not abandon the approach. It CAN be done. 6. There are research structure editors out there that do different languages - I think this big win for Emacs will no longer be unique to Emacs. 7. I don't really understand this point. I think structure editors must have come a long way since 1984. I know the Interlisp-D structure editor has. Steve Clark, steve@siemens.com, princeton!siemens!steve
darrelj@sdcrdcf.UUCP (Darrel VanBuer) (12/11/87)
In article <13253@think.UUCP> barmar@sauron.UUCP (Barry Margolin) writes: >In article <329@siemens.UUCP> steve@siemens.UUCP (Steve Clark) writes: >> I maintain that the non-Interlisp systems are wrong, however. It >>is clearly more advanced to treat a file as a database of definitions of >>functions, data, structures, etc. than to treat it as a string of characters >I also wonder whether the Interlisp database is as powerful as the >Common Lisp LOAD style. I'm not very familiar with Interlisp, so bear >with me. A file to be loaded can contain other code besides >definitions and declarations; it can contain immediate code to be >executed. Thus, the file LOAD-EVERYTHING.LISP could contain: > >(load "first-thing") >(load "second-thing") >(load "third-thing") >(load "last-thing") >How is this done in Interlisp? If there is a way to do it, then >what's the difference between that and LOAD? Part of the interlisp file manager writes the "database of contents" to the file, then uses this database to direct writing the file. There are more than a dozen kinds of objects - functions, variables, declarations, property list entries, files ... (FILES "first-thing" "second-thing" ...) generates calls to LOAD (indirectly, because FILES is more like REQUIRE than LOAD, and takes a variety of keyword-like tags to control directory, source vs compiled, etc. The file which is written is actually full of forms which are evaluated for effect, just like common lisp (e.g. functions get written surrounded by DEFUN). The database aspect is primarily the existence of the contents variable (and for old Interlisp fns, a byte map to their location so that a SET-FILE-POSITION plus READ will get just one). "P" is a database command of last resort to do anything, as it is a list of expressions to be printed on the file, and thus evaluated on load. E.g. (P (LOAD "first-thing") (LOAD "second-thing") ...) >How does Interlisp know which definitions are important to save? I >certainly wouldn't want it saving everything, since I constantly >create little temporary functions and variables while debugging. If >the user has to save functions explicitly it seems like it would be >hard to make sure you don't miss some. I'm sure these problems have >been solved, since I doubt Interlisp would have survived so long >without solutions, but I'm curious how. When you want to update the files, you call a function CLEANUP, which first calls FILES? (or can call directly), then MAKEFILE (which writes, compiles and hardcopies the file subject to various control variables). FILES? has been "told" all the definitions you have made by little demons inside DEFUN et al, and will engage you in a dialog about each. The main options in the dialog are to a file or to nowhere. The editor also contains demons which tell CLEANUP which functions, etc have changes, allowing it to infer from the database of file contents which files NEED to be rewritten, etc. >--- >Barry Margolin >Thinking Machines Corp. > >barmar@think.com >seismo!think!barmar -- Darrel J. Van Buer, PhD; unisys; 2525 Colorado Ave; Santa Monica, CA 90406 (213)829-7511 x5449 KI6VY darrel@CAM.UNISYS.COM or ...{allegra,burdvax,cbosgd,hplabs,ihnp4,sdcsvax}!sdcrdcf!darrelj
barmar@think.COM (Barry Margolin) (12/11/87)
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
steve@siemens.UUCP (Steve Clark) (12/11/87)
In article <13427@think.UUCP> barmar@sauron.think.com.UUCP (Barry Margolin) writes: >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. > >This argues just as much against structure editing as it does against >the single-address-space style of Lisp Machines. It does not argue at all against structure editing. It is a point against editing the current function definition, as opposed to a copy. (Of course, the only languages I know of where a text editor could possibly edit the current function definition are Jovial and Basic.) In Interlisp it is easily possible to set yourself up with a little facility to edit copies of functions and install all the copies simultaneously. Steve Clark (maybe steve@siemens.com or princeton!siemens!steve, maybe not)
welch@tut.cis.ohio-state.edu (Arun Welch) (12/12/87)
> >In article <3044@tut.cis.ohio-state.edu> you write: >>Every file has a variable associated with it, called the COMS, which >>is the database. Thus, for the file FOO, there would exist a variable >>FOOCOMS, which defines what's contained in FOO, what operations to >>perform when loading foo, etc. Let's say that I want FOO to contain >>the function definition for the function BAR, the variable definition >>for the variable BAZ, which has the initial value 5, and for the file >>RALPH loaded before the file FOO is loaded, and also, for the screen >>background to be set to the blackshade after FOO is loaded. FOOCOMS >>would then look like this: >>((FILES RALPH) >> (FNS BAR) >> (VARS (BAZ 5)) >> (P (CHANGEBACKGROUNDBORDER BLACKSHADE))) > >I have one question about this: how does this stuff get into the >variable before the first time you refer to the file? There are a bunch of functions for manipulating the coms, like ADDTOFILE, DELFROMFILE a so on. When ADDTOFILE is called, the first thing it does is check and see if the variable exists, and if not, then it creates it. One can also directly edit the variable using the editor. > Are D-machine >file multi-forked, like Macintosh files, with one fork containing the >COMS related to the data in the other fork? Or is the COMS just a >header that Lisp files have, which is processed when the file is >incorporated into the environment? It's closer to the latter. The coms, being a variable, is defined in the file too. One of the things contained in the file is a statement of the sort (RPAQQ FOOCOMS ((FILES RALPH) (FNS BAR) (VARS (BAZ 5)) (P (CHANGEBACKGROUNDBORDER BLACKSHADE)))) [ RPAQQ is a function of two arguments, VAR and VALUE, that sets the top level binding of VAR to VALUE]. >Or is the COMS something like a >file property list, like Symbolics Lisp Machines implement? Files have property lists too, which define things like which compiler to use, what sort of reader environment to use, what base to use for numbers, etc. ...arun ---------------------------------------------------------------------------- Arun Welch Lisp Systems Programmer, Lab for AI Research, Ohio State University welch@ohio-state.{CSNET,ARPA} welch@red.rutgers.edu (a guest account, but mail gets to me eventually)
liberte@uiucdcsb.cs.uiuc.edu (12/17/87)
> ... > What I would like to have is a hybrid editor that maintains both the > structure of what you're editing and the text, and works really hard to > keep them in sync. > ... > -Peter Schachte > pds@quintus.uucp > ...!sun!quintus!pds TADA! (Thanks for the cue.) We have a hybrid editor that maintains both the structure of what you're editing and the text and almost never gets out of sync. It uses GNU Emacs as the front end and an incremental parser (Leif) to maintain the parse tree. As changes are made to the text, they are sent (via a change to Emacs) to the parser which keeps quiet until you ask for error status or request structure information. You can be editing multiple buffers each with a different language simultaneously. The language specification bundles loaded by the parser are generated from lex and yacc (actually bison) specifications (contributions greatly appreciated). There is no restriction on where you put white space or comments as long as you can specify them in the lex specification without start states or other context sensitivities (finite lookahead is OK). And it's free. We are in beta testing now. We are sending out tapes to a few people so mail if you are interested. Eventually we'll distribute it more widely. For now, it's called the SAGA GNU Emacs Leif editor, or Leif for short. We are also accepting research funds to continue this work. Daniel LaLiberte 217-333-7937 University of Illinois, Urbana-Champaign Department of Computer Science 1304 W Springfield Urbana, IL 61801 liberte@a.cs.uiuc.edu uiucdcs!liberte