From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.7 required=5.0 tests=BAYES_00,INVALID_DATE, MSGID_SHORT,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!strath-cs!dcl-cs!aber-cs!rjg From: rjg@aber-cs.UUCP (Bob Gautier) Newsgroups: comp.lang.ada Subject: Re: Structured editors (was file naming) Message-ID: <2051@aber-cs.UUCP> Date: 10 Oct 90 16:40:24 GMT References: <12863@encore.Encore.COM> <2205@sparko.gwu.edu> Reply-To: rjg@uk.ac.aber.cs (Bob Gautier) Distribution: eunet,world Organization: UCW,Aberystwyth,WALES,UK List-Id: 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