In- and Out-of- core editors (was Re: Which one, Lisp or Scheme?)
Simon Brooke
Jeff Dalton wrote:
>
> > Essentially, therefore, the design of
> > this function assumes the editing of *text*, not *structure*.
>
> Um, no. Structure editors present code *as text* in pretty much the
> say described for (ed symbol): by pretty-printing.
>
> Since you know this is the case, why do you write as if it were not?
-- Guys, I am not the enemy. We are all on the same side --
In a text editor, any character is individually selectable and
individually changeable. In a structure editor, only complete structural
elements are selectable or changeable. How this is presented -- as
pretty-printed text, or as a three-dimensional graph hanging in space[1]
is irrelevent.
Structure editors may *show* structure as text (or they may not); but
they don't allow you to *manipulate* structure as text. To assert that
two things are alike because their surface representation is alike is to
miss the point entirely, in my opinion.
A system which interprets structure built from the same text but in an
environment separate to the working environment is also not editing
structure in-core; if I have a deep and complex knowledge representation
structure that I'm working on, it isn't necessarily the case that I've
written methods which will allow it to be saved to a file and later
reproduced by the reader. So if the structure creating functions messed
it up, I can either write other functions to get in there and fix it or
I can pull it into an in-core structure editor and fix it by hand. I
can't do that with an out-of-core editor, whether structure or text.
> Well, no. You're also saying that CL is hostile to structure editing,
> or something like that.
Yes, I am, and I believe this is fair criticism. The fact that a system
can be criticised in detail does not mean that it's a bad system; few
human artifacts are completely perfect. It's hostile to structure
editing because it doesn't have a *standard* way of making comments
available in-core. To have such a *standard* way (provided it didn't
have any deleterious side
effects) would involve no cost to people who like text editors, and
substantial benefit to people who like structure editors. So it would
represent an improvement (if, perhaps, an unimportant one)
Simon
[1] yes, it has been done -- for my paper on this, see the proceedings
of the Third Alvey Workshop on Explanation, 1986; my work on
two-dimensional graphical editors for knowledge structures has been
published in half a dozen papers, and, for that matter, I'm by no means
only one to have produced such things.
--
si...@intelligent.co.uk (Simon Brooke)
http://www.intelligent.co.uk/~simon
Morning had broken, and we had run out of gas for the welding torch.
Henry Baker
In article <32F7963E...@intelligent.co.uk>, Simon Brooke
<si...@intelligent.co.uk> wrote:
> -- Guys, I am not the enemy. We are all on the same side --
>
> In a text editor, any character is individually selectable and
> individually changeable. In a structure editor, only complete structural
> elements are selectable or changeable. How this is presented -- as
> pretty-printed text, or as a three-dimensional graph hanging in space[1]
> is irrelevent.
>
> Structure editors may *show* structure as text (or they may not); but
> they don't allow you to *manipulate* structure as text. To assert that
> two things are alike because their surface representation is alike is to
> miss the point entirely, in my opinion.
Actually, a student of mine once built what you would call a structure editor,
in that the internal representation was a tree-structure, but whose 'surface
structure' looked, and could be edited like, text. So there may not be such
a clean distinction.
Marco Antoniotti
This thread about in-core editors and so on strikes me as a little
"off". The ultimate structure editor for any Lisp (Elisp, Scheme or
Common Lisp) is Emacs. :)
Even VI has features that allow you to edit Lisp code in a convenient
manner.
--
Marco Antoniotti - Resistente Umano
===============================================================================
International Computer Science Institute | mar...@icsi.berkeley.edu
1947 Center STR, Suite 600 | tel. +1 (510) 643 9153
Berkeley, CA, 94704-1198, USA | +1 (510) 642 4274 x149
===============================================================================
...it is simplicity that is difficult to make.
...e` la semplicita` che e` difficile a farsi.
Bertholdt Brecht
Simon Brooke
In article <s08lo93...@crawdad.icsi.berkeley.edu>,
Marco Antoniotti <mar...@crawdad.icsi.berkeley.edu> writes:
>
> This thread about in-core editors and so on strikes me as a little
> "off". The ultimate structure editor for any Lisp (Elisp, Scheme or
> Common Lisp) is Emacs. :)
Look, that's silly. 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. 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.
This is like thinking that you can make useful changes to the airframe
of a jet aircraft by taking a hacksaw to an AIRFIX model.
Emacs is indeed a very fine _text_ editor for LISP (and for many other
things -- it's what I'm using now); but a structure editor it is not.
--
si...@intelligent.co.uk (Simon Brooke) http://www.intelligent.co.uk/~simon
Error 1109: There is no message for this error
Breanndan O Nuallain
si...@caleddon.intelligent.co.uk (Simon Brooke) writes:
> In article <s08lo93...@crawdad.icsi.berkeley.edu>,
> Marco Antoniotti <mar...@crawdad.icsi.berkeley.edu> writes:
> >
> > This thread about in-core editors and so on strikes me as a little
> > "off". The ultimate structure editor for any Lisp (Elisp, Scheme or
> > Common Lisp) is Emacs. :)
>
> Look, that's silly. Emacs cannot edit the structures in the core image
Wow! The ultimate flame-bait: starting a sentence with "Emacs cannot..."
Batten down the hatches.
Erik Naggum
* 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
Espen Vestre
Erik Naggum <er...@naggum.no> writes:
> 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.
Dig up a Xerox 1186 with XCL (or maybe you could get your hands
on a copy of Medley for your Sparc?) , try SEdit and see what you think.
I really liked it. (its predecessor, Dedit of Interlisp-D, was
a bit too strange to me)
--
Espen Vestre
Telenor Online AS
Barry Margolin
In article <5dcalk$l...@caleddon.intelligent.co.uk>,
Simon Brooke <si...@caleddon.intelligent.co.uk> wrote:
>Look, that's silly. 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).
Using inter-process communication and appropriate key bindings, this could
be done. Every edit you make would be transmitted immediately to the Lisp
system as appropriate structure modifications. I'm not saying it would be
*easy* (you'd have to rebind most of the basic editing keystrokes), just
possible.
--
Barry Margolin
BBN Corporation, Cambridge, MA
bar...@bbnplanet.com
(BBN customers, call (800) 632-7638 option 1 for support)
Bob Riemenschneider
In article <s08lo93...@crawdad.ICSI.Berkeley.EDU> Marco Antoniotti
<mar...@crawdad.icsi.berkeley.edu> writes:
> This thread about in-core editors and so on strikes me as a little
> "off". The ultimate structure editor for any Lisp (Elisp, Scheme or
> Common Lisp) is Emacs. :)
I'd agree that, overall, using Emacs is a win. But the Interlisp
structure editor did have some advantages. For instance, every once in
awhile, when you wound up in the debugger, it was nice to be able to do a
little surgery on the control structures of a function that you were in
and continue, rather than having to back up the stack to before the call
or figure out what value the function should have returned. And maybe the
fact that this style of editing encouraged you to look at programming as
modifying an image to make it do what you want rather than writing source
code -- e.g., you ended an Interlisp session by doing a SYSOUT,
effectively saving the image, not by saving the source code to be reloaded
later -- shouldn't be ignored. I think this encouraged a more
incremental, hackeresque view of the development process.
-- rar
Antonio Leitao
This thread reminds me of an old discussion between Richard Stallman
and Sandewall regarding the relative merits between structured editors
and text editors.
For all of us who don't remind or don't know what a structure editor
is, let's read the following paper:
@Article{Sandewall:1978:PIE,
author =3D "Erik Sandewall",
title =3D "Programming in an Interactive Environment: the ``{\sc
Lisp}'' Experience",
journal =3D "ACM Computing Surveys",
volume =3D "10",
number =3D "1",
pages =3D "35--71",
month =3D mar,
year =3D "1978",
coden =3D "CMSVAN",
ISSN =3D "0010-4892",
bibdate =3D "Wed Dec 18 07:42:17 MST 1996",
note =3D "See also
\cite{Stallman:1978:SFS,Sandewall:1978:SFS}.",
abstract =3D "LISP systems have been used for highly interactive
programming for more than a decade. During that time,
special properties of the LISP language (such as
program\slash data equivalence) have enabled a certain
style of interactive programming to develop,
characterized by powerful interactive support for the
programmer, nonstandard program structures, and
nonstandard program development methods. A summary is
given of the LISP style of interactive programming for
readers outside the LISP community, describes those
properties of LISP systems that were essential for the
development of this style, and discusses some current
and not yet resolved issues.",
acknowledgement =3D ack-nhfb,
classification =3D "723",
keywords =3D "computer programming",
}
Then, for a case against structure editors (and the previous article,
in particular), by the Master of text editors, Stallman himself, read
the following:
@Article{Stallman:1978:SFS,
author =3D "Richard M. Stallman",
title =3D "{Surveyor's Forum}: Structured Editing with a {Lisp}",
journal =3D "ACM Computing Surveys",
volume =3D "10",
number =3D "4",
pages =3D "505--507",
month =3D dec,
year =3D "1978",
coden =3D "CMSVAN",
ISSN =3D "0010-4892",
bibdate =3D "Mon Sep 19 20:29:44 1994",
note =3D "See \cite{Sandewall:1978:PIE,Sandewall:1978:SFS}.",
acknowledgement =3D ack-nhfb,
}
And finally, for a conclusion, read the reply to the reply of
Stallman:
@Article{Sandewall:1978:SFS,
author =3D "Erik Sandewall",
title =3D "{Surveyor's Forum}: Structured Editing with a {\sc
Lisp}",
journal =3D "ACM Computing Surveys",
volume =3D "10",
number =3D "4",
pages =3D "507--508",
month =3D dec,
year =3D "1978",
coden =3D "CMSVAN",
ISSN =3D "0010-4892",
bibdate =3D "Thu Sep 29 23:53:19 1994",
note =3D "See \cite{Sandewall:1978:PIE,Stallman:1978:SFS}.",
acknowledgement =3D ack-nhfb,
}
After this home-work, we can restart the discussion...
Ant=F3nio Leit=E3o.
Marco Antoniotti
r...@violet.csl.sri.com (Bob Riemenschneider) writes:
My original posting was obviously semi-provocatory. However, either
you have a very tight "structure editor" for in-core editing or you
must use what you have (in this case Emacs.)
AFAIK there are no good structure editors (i.e. with the same
"quality level" of Emacs) for Lisp out there. Since we are not
working on Xerox machines or derived stuff anymore, it seems to me
that the whole thread is moot. It is as simple as that.
Let me know if there are Interlisp-like strucutre editors that I can
use for Common Lisp (possibly CMUCL under Solaris/FREEbsd) and I will
give them a try.
But in this time and space, discussing of structure editors as a
"distinguishing" characteristics is like discussussing of the "sex of
angels". There are many other things that are way more sorely needed
in Lisp environments that alternative ways to edit an image.
Finally, the post that RAR just made makes a very good point.
Structure editors encourage a very hackerish (in the "bad" sense of
the word) way of programming. Since I am a person that is still
ticked off by the limitations of DEFPACKAGE :) I would definitively
favor a "text editor" over a "structure" one, just beacause of this
side-effect on programming style.
Cheers