Subject: Re: In- and Out-of- core editors (was Re: Which one, Lisp or Scheme?) From: Erik Naggum <erik@naggum.no> Date: 1997/02/06 Newsgroups: comp.lang.lisp Message-ID: <3064225496493947@naggum.no> * Simon Brooke | Emacs cannot edit the structures in the core image of another LISP system | (or if it can, I would be extremely interested to learn how). It can be | used to edit structures in the core image of emacs LISP, but I don't | (usually) program large systems in emacs LISP. hm. how can Emacs be used to edit structures in the core of Emacs? I think I know Emacs extremely well, but this is news to me. could you explain what you mean? | It can edit the structure implied in text written by another LISP system, | but at best what that is doing is editing a reconstruction of a copy | (interpreted by a different reader) of the structure. This process | depends for its effectiveness on the absolute reliability of two separate | print systems and two separate readers, for structures which I may not | yet have bothered thinking up a way of either printing or reading | accurately. I think you're doing an outstanding job in making this sound difficult, but I don't agree with the ways you explain the difficulties. first, I may not know what a "structure editor" is like if it so different from everything I know that you imply, so I think you may need to explain what you want a bit further. second, if system A has a reader and printer and system B is a text editor, then A will read and print, and B will edit. that's exactly one set of reader and printer, and it's in the same system. around 1982, I attended a seminar on syntex-sensitive editing in Pascal at the U of Oslo. editing the structure of the program was the Hot Thing back then, and various modes were shown as examples. I don't remember all of this in great detail, but my distinct impression was that you would have to use special functions to insert keywords, create templates for functions, blocks, etc. variables would be named by typing them in, but you could only do that in declarations -- later it was always a matter of selecting the right variable from a list of valid choices (it would be a menu today). movement was always in terms of the structure. about 10 years later, when I was working with SGML, we had smart people suggest that we use "structure editors" for SGML documents, since SGML is really _about_ structuring information. now, SGML has paired tags that surround (and identify) an element's contents, and all that their structure editor ever did differently from regular editors was to make it difficult to make an invalid SGML document even for the fraction of a second that it took to write something into it. making changes to the structure was very difficult, compounded by the rules in SGML that say that an element may have _required_ subelements. as we found in the Pascal editor case, the number of necessary functions for a structure editor is _very_ high. I think a "structure editor" means that at every point in time, the structure is valid and in principle, if not in practice, ready to be read back into the system. such a system _cannot_ represent information other than as valid structures. this may sound very sexy, but it has no place in an editor, in my view. I think the idea of a structure _inspector_ has lots of merit, however, and possibly one where I can change fields, but edit deep structures? no way. what I really want from an editing system is not the straitjacket that an invariant of syntactical validity maintained across every editing operation I make would be, but a means to learn, at will, that the changes I have made did not break such an invariant, and I don't want that to be the compiler. it is, however, exceedingly obvious to me that the _language_ I write in will have enormous consequences for the way this will work. in particular, the system should not need to parse from the start of the file (or cache the results of such an operation) to validate a small part in it. amazingly, you will find (I did, anyway) that the only type of languages that make structure editing on the textual representation possible are those that are fully bracketed, and the only type that makes it _easy_ enough to be worth doing is one that uses simple brackets such as parens, and not textual brackets like "begin"/"end". (the reason may not be obvious, but if you move one bracketed expression from one place to another, you will find that if you have specialized brackets, they need to change according to context, such as is the case in SGML.) once you _have_ a fully bracketed language with uniform, single-character brackets, you find that you don't _need_ a structure editor, because it is so trivial to move around in the structure, anyway. it's when you don't have such a syntax you need structure editors, and then they are incredibly difficult both to make and to use. now, perhaps I just don't work the way structure editors would demand that I work. perhaps it really is a good thing, but from that Pascal seminar and my considerable experience with the difficulties of changing structured information in SGML in meaningful ways, I don't think the human condition is consistent with structure editing. I believe that structure is a product, not a process. #\Erik -- my other car is a cdr