Subject: Re: In- and Out-of- core editors (was Re: Which one, Lisp or Scheme?)
From: Erik Naggum <>
Date: 1997/02/06
Newsgroups: comp.lang.lisp
Message-ID: <>

* 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.

my other car is a cdr