jcallen@Encore.COM (Jerry Callen) (10/04/90)
In article <11612@ganymede.inmos.co.uk> mph@inmos.co.uk (Mike Harrison) writes: >While I am on my 'hobby horse', I may as well say that I hate and detest >structured editors (for my own use) in that they force the user to adopt a >particular approach to ordering the input. I often find that I prefer to >input programs in an unstructured order (often arbitrarily copying 'chunks' >of code from other parts of the file or from other files). >I accept that structured editors may appeal to some (particularly to novices >or others unfamiliar with the the syntax of the language) but for the >'professional program' I believe that they just get in the way! Gee, I guess my 5 years of Ada runtime experience doesn't qualify me as a "professional program[mer]." Nuts! :-) Seriously, I find that I make far fewer errors if I get the "end if" in at the same time that I type the "if." This kind of automated assistance is a help, not a hindrance, at least to this one non-novice person. -- Jerry Callen jcallen@encore.com
mfeldman@seas.gwu.edu (Michael Feldman) (10/05/90)
In article <12863@encore.Encore.COM> jcallen@encore.Com (Jerry Callen) writes: > >Seriously, I find that I make far fewer errors if I get the "end if" >in at the same time that I type the "if." This kind of automated >assistance is a help, not a hindrance, at least to this one non-novice >person. > Automated _assistance_ is nice, but I want to be allowed to tell my assistant to buzz off if I wish. I don't wannabe a slave to it. See below. Maybe it would help this discussion thread (which I find very interesting) if we established some terminology (there is no standard terminology, so I'll use some ad hoc stuff I've seen): - by a "structure editor" we mean one which refuses to allow you to type an illegal statement or part of one; everything is parsed on the fly and the thing won't proceed till you get it right. The "Pascal Genie" from the CMU comp. sci. department is in this category; the Genie folks swear by it; - by a "template editor" we mean something which gives the _user_ the option to create a template for a given structure with a single keystroke. No parsing is done; it's really just a macro expansion. The Meridian ADI editor is in this category; actually, since this editor is just a version of emacs, we can include the various emacs "modes" in this bucket too. Assuming a compiler front end fast enough to find the _syntax_ (and lexical) errors very rapidly - and Ada compilers are approaching this speed now, I MUCH prefer the second type of editor. It's like so much else: I like neat toys but don't like being compelled to use them. If I choose to crank some garbage into my file - e.g. to create _purposely_ bad programs for classroom use - I don't want the editor to get in the way. If the editor is building a tree as it goes (like the Genie editor) it has no way to accommodate my garbage, so it beeps. On the other hand, a reasonably smart template editor (ADI is a primitive first cut) will give me the means to generate structures without a lot of keyboarding, and correct structures at that. Which Ada-oriented editors, in your experience out there, are in which category? Rational? DEC? Alsys (if it has one)? --------------------------------------------------------------------------- Prof. Michael Feldman Department of Electrical Engineering and Computer Science The George Washington University Washington, DC 20052 202-994-5253 mfeldman@seas.gwu.edu ---------------------------------------------------------------------------
rjg@aber-cs.UUCP (Bob Gautier) (10/10/90)
As a long standing advocate of structure editing, I felt inclined
to add my tuppence worth to this discussion. This (long!) article covers two
topics: 1) What is a structure editor? 2) An answer to those who
feel that they need to be allowed to generate invalid structures
from time to time.
Part I: What is a structure editor?
-----------------------------------
I would like to offer an alternative to Prof. Feldman's
definition of ``structure editor'', because I think he have missed a
very important property which I believe true structure editors possess:
structure editor: A tool for manipulating abstract structures by means
of interaction with graphical (i.e. diagrammatic or textual) representations
of those structures by means of an appropriate user interface.
A structure editor does not typically allow one to produce ``invalid''
structures, nor, when using a textual representation, does it necessarily
include the ability to *parse* text (since text is used only for
presentation to the user).
A structure editor will typically have very powerful ``template''
creation facilities, and some very powerful transformation commands.
Of course, my definition is very broad -- almost any interactive tool
for ``data entry'' fits the bill. In fact, even text editors, and
the tools which Prof. Feldman described as ``structure editors''
and ``template editors'' do too, but only if you consider them as
structure editors for _textual_ objects. Tools like the Pascal Genie
are in fact editors for Pascal program abstract syntax trees.
(The Genie happens to incorporate a parser, but that is just to
make its user interface friendlier to people who like to type a lot.)
In fact, I prefer to qualify the term ``structure editor'' with the
*type* of object to which the structure editor can be applied.
You see, you might have two tools, both of which can ostensibly be
used for editing Ada programs. But one might involve commands and
operations such as ``insert line'' and ``delete character'', whilst
the other might offer ``create package'', ``add procedure'',
``add parameter'' and so on. The first is a ``*text* structure editor'',
whilst the second is a ``*program* structure editor''.
The fact that the editor is defined on the *abstract* structure
(or object) being manipulated is the important thing; any textual
(or other) representation is secondary. This gives structure editors
some interesting properties:
1) They can be used with textual languages for which no parser
exists, or would be tricky to write -- one can make
font and indentation important, as well as upper/lower case,
for example.
2) They can be more extensible than other language processing tools,
because the overall grammar of the languages does not have
to be held within the capabilities of any parser -- it
can be made very easy for people to add new statements to
a language. (I'm taking a lot of space here already, so
I'll not attempt to convince you that this would be a good thing!)
3) They can be made to produce more than one representation for a given
abstract structure -- for example, an Ada structure might
be present both as text and as Booch or Buhr diagrams.
Moreover, the user might be able to manipulate the structure
via any of those representations.
4) They can offer very high-level operations very cheaply. For example,
we have a prototype Ada editor here which, when you need to
supply a type (for a parameter, variable, etc.), can give
you a menu of all the types that are in scope. Having an
abstract representation of the Ada is a great help here.
Doing this based on a textual representation would be
quite hard.
In particular, structure editors are very good at the ``single
keystroke'' template insertion that Prof. Feldman referred to as
a property of ``template editors''. But they go further in that
the ``template'' is usually part of the presentation of some structure,
and as such is not available for the user to edit (e.g. you can't
point at the keyword ``else'' and edit it as if it were text, no more
than you can edit the text in a pop-up menu.) Structure editors that
also incorporate parsers relax this, by providing ``textify'' and ``parse''
operations which convert a bit of a structure into text and back again.
Part II: Do we need to be able to build ``bad'' structures?
-----------------------------------------------------------
I feel that I should also pick up the point Prof. Feldman makes about
the need to deliberately create bad programs for classroom use.
The purpose of this is presumably to teach people about syntax or
semantic errors, so that they will either not make that kind of error,
or will learn the effect of that kind of error, in order to be able to
diagnose it.
By using a structure editor one completely avoids the possibility
of making a whole class of errors, so it is meaningless to talk about
those errors, or how to diagnose them -- it is a bit like trying
to teach people to use the right *colour* of words when they speak;
the concept just does not apply.
For example, you may have already met a commonly used structure editor,
the X11 bitmap tool, which allows one to generate bitmaps (the SUN
iconedit tool is similar). This tool provides a graphical interface
to an abstract object which is a two-dimensional array of bits.
The editor allows you to manipulate those bits in various ways,
and will eventually write a representation of that bitmap
out to a file as a fragment of C.
You cannot produce an invalid bitmap using these tools. If you wanted
to, you could use other tools to generate a picture of what it might
look like to produce an invalid bitmap (for example, a bit ``half on'')
but it wouldn't be useful because the tools just don't work like that.
Alternatively, you could show people the C output produced, and show the
kinds of errors that could occur there, but the tools don't make mistakes,
so that isn't helpful either.
The concepts of ``abstraction function'' or ``representation constraint'',
often used when talking about abstract data types, are also helpful in
realising why you shouldn't expect to be able to produce ``bad'' programs with
a structure editor. For example, all Ada programs have a textual
representation, but not all texts represent Ada programs. A structure
editor can ensure that you generate a text which represents an Ada program.
But if you want to produce a text which *doesn't* represent an Ada program
(and ``An Ada program with a syntax error'' is basically ``Not an Ada
program''), then you have to use the more general tool, the text editor.
Bob Gautier, UCW, Aberystwyth, UK
UUCP : {ENGLAND}!ukc!aber-cs!rjg JANET: rjg@uk.ac.aber.cs
PHONE: +44 970 622432
--
UUCP : {ENGLAND}!ukc!aber-cs!rjg JANET: rjg@uk.ac.aber.cs
PHONE: +44 970 622432