dalamb@qucis.queensu.ca (David Lamb) (07/05/89)
Can anyone point me to references in the open literature that supplies
evidence one way or the other on the following question:
I've heard people claim that "structure editors" that provide only
editing operations corresponding to creating portions of an abstract
syntax tree are inferior in user-friendliness to "text editors" that
let people type the way they're used to, especially if the "text
editor" provides operations that let you fill in boilerplate when you
choose to do so. Is there any evidence, other than anecdotal, one way
or the other on this question?
I'm hoping to invest some of my research assistants' time this year in
extending my batch-style compilation tools to assist in building
interactive compiler-like programs, so would like to decide which
approach to take fairly soon.
David Alex Lamb
Department of Computing and Information Science
Queen's University
Kingston, Ontario, Canada K7L 3N6
(613) 545-6067
ARPA Internet: David.Lamb@cs.cmu.edu
dalamb@qucis.queensu.ca
uucp: ...!utzoo!utcsri!qucis!dalamb
[This used to be quite a hot topic of debate. Personally, I tend toward
the text approach, see "Z - the 95% program editor," by Steve Wood in the
proceedings of an ACM text processing conference about 1981. The arguments
in favor of the structure editors is that the editor always knows what's going
on, the program being edited is always syntactically correct except for leaf
nodes that haven't been filled in yet. The argument in favor of the text
approach is that there are a lot of operations that are easy to do as text
editing but hard as structure editing, e.g. changing (a-b)-c to a-(b-c), and
the cost of parsing on demand is low enough not to be a problem. I've seen
plenty of papers describing various kinds of editors, but none trying to
compare them. Has anyone else? -John]
--
Send compilers articles to compilers@ima.isc.com or, perhaps, Levine@YALE.EDU
Plausible paths are { decvax | harvard | yale | bbn}!ima
Please send responses to the originator of the message -- I cannot forward
mail accidentally sent back to compilers. Meta-mail to ima!compilers-requestbrad@looking.on.ca (Brad Templeton) (07/05/89)
I wrote the only structure editor to make a major venture in the commercial
market (Alice Pascal) and from that I learned a couple of things:
a) You have to mix structure and text. An incremental parser for
expressions is not too bad on the implementation side, and does
most of the basic problems.
b) A few simple transmog operators for the larger structures can
do the rest.
c) True incremental parsing is usually slow unless you really work
on it. Not ok for the PC style machines found in many labs.
d) Don't try a structure editor to the mass market. Stick to your
niche.
---
Brad Templeton, Looking Glass Software Ltd. -- Waterloo, Ontario 519/884-7473
[I looked at Alice Pascal when it came out, and although it did what it did
very well, somehow its improvements over conventional development editors
were never compelling enough to make me want to switch. Oh, well. -John]
--
Send compilers articles to compilers@ima.isc.com or, perhaps, Levine@YALE.EDU
Plausible paths are { decvax | harvard | yale | bbn}!ima
Please send responses to the originator of the message -- I cannot forward
mail accidentally sent back to compilers. Meta-mail to ima!compilers-requestfin@uf.msc.umn.edu (Craig Finseth) (07/06/89)
I did a pretty thorough review of the literature as of 1980 for my thesis and came to the (private) conclusion that there is no NON-anecdotal evidence in this area. Let me rephrase that somewhat. There are objective things to do, e.g., figure and count minimal keystrokes. However, there is no *objective* way of doing anything useful with that knowledge. (Suppose that I were to devise an editor command set based on a bit-level Huffman encoding of all common editing operations. Certainly a minimal keystroke count, but I would not want to use it.) Once you have gathered the objective data, it is time to add substantial quantities of human insight to the mix. Devising and understanding editor command sets is not an exact science. You may wish to rephrase your request to allow non-objective comments, but comments that at least have a general basis. --- Non-Objective Comments Follow ---- I will take the liberty of responding in a non-objective fashion. Ignore this if you like. I prefer general text editors (Emacs, in particular). There are two reasons for this: 1) The particular general text editor that I use is fairly non-modal (at least as non-modal as one can reasonably get given ASCII term interaction) (I turn off the language-specific modes). The structure editors that I reviewed were all fairly modal. I believe that non-modal interaction is to be preferred (c.f. Apple Computer Corp's "Human Interface Guidelines"). This is not to be interpreted as claiming that a structure editor *must* be modal, merely that I have not seen examples of a (reasonably) non-modal one. Show me an example and I may change my mind. 2) I use a text editor as a general text-manipulation device. It can be used to edit programs, documentation, things-to-do lists, mail (:-), as a small spreadsheet (I use a calcualator to do the math), as a directory editor, and so forth. Everything I learn when editing programs carries over perfectly to all other areas. If I had the best possible structure editor for programming (say, the C language), it would make programming easier. It would not, however, help me in any of the other areas and none of my learning would be transferable. I think transferable learning is good (c.f. all of the integrated environments (Macintosh, Windows, UNIX, X Windows, etc), both bad and good). Thus, even if someone was to show me an example of an extremely good structure editor, my reaction would probably be "that's nice, and it does a good job at X, but what about Y, Z, ...?" Craig A. Finseth fin@msc.umn.edu [CAF13] Minnesota Supercomputer Center, Inc. (612) 624-3375
pardo@june.cs.washington.edu (David Keppel) (07/07/89)
dalamb@qucis.queensu.ca (David Lamb) writes: >[Request for info: do structure editors make coding easier?] (This doesn't answer the request for references, it is merely thought fodder for everybody.) I've used the Cornell Program Synthesizer briefly and found it annoying because it `knew too much'. I find GNU emacs' modes more useful, but sometimes the editor still `knows too much'. An interesting counterpoint: our Smalltalk systems let you type stuff in in little pieces. All editing is done free-format, and is later formatted by the browser. Compilation generally takes place in units of a few to a few dozen lines. Thus, in Smalltalk I tend to write a function, statically debug it, write another function, statically debug it, and so on. ;-D on ( Intrinsic dysfunction ) Pardo -- pardo@cs.washington.edu {rutgers,cornell,ucsd,ubc-cs,tektronix}!uw-beaver!june!pardo
soh@shiva.trl.oz (kam hung soh) (05/29/90)
Can anyone give me any references for structure editors? There was a mailing list posting, but the posting has expired on my machine. Thanks ----------------------------------- Soh, Kam Hung Telecom Research Laboratories, P.O. Box 249, Clayton, Victoria 3168, Australia email: h.soh@trl.oz.au tel: +61 03 541 6403
skoenig@a.gp.cs.cmu.edu (Sven Koenig) (11/12/90)
I am trying to survey completed and on-going projects for building programming language source text editors (structure editors), both of the template approach variety (like Gandalf or the Cornell Program Synthesizer) and of the recognizer approach variety (i.e. based on incremental syntax analysis), and integrating them in a programming environment. At the same time I am trying to get an overview over methods for doing incremental syntax analysis and incremental semantic analysis. I would like to get an as complete overview as possible. Any pointers to the literature (in English or German) are greatly appreciated. Thanks, Sven (skoenig@cs.cmu.edu)