IDEA — an incrementaldevelopment environmentfor Adaby C. Nicol, Prof. M. K. Crowe, M. E. Corr, J. W. Oramand D. G. Jenkins

This paper decribes an incrementalenvironment which has been developed tomeet the needs of developers andmaintainers of large Ada projects. Thisenvironment assists the user to develop validAda text while consulting other Adapackages and documents. It is built aroundan embedded syntax-directed editor whichcontrols text inspection, modification and,subsequently, re-compilation. In addition, thedata accumulated by a translator is availableduring editing to provide semantic assistanceon request.

1 Introduction

The Adat programming language has been designed withlarge embedded software engineering projects in mind. Thelanguage has 'strong typing', with a rich system of abstractdata types, and supports secure separate compilation andre-usable software modules via specification units, genericsand re-naming.

These features have resulted in Ada being used to greateffect in other, apparently distant areas such as specifica-tion development, where the compilation process can beused to check consistency in use and naming (Ref. 1). Forsimilar reasons, Ada is also useful for prototype develop-ment, where large parts of the project can be representedin a simplified form (stub).

The very features which made Ada useful in thesesituations also make it quite difficult to use. A programmerdeveloping a module that uses declarations from othermodules must frequently refer to the declarations ordefinitions of objects, types etc. declared in the importedspecifications (Ref. 2). This is tedious even if up-to-dateprinted versions are to hand, especially when the Ada

tAda is a trademark of the GS Government Ada Joint ProgramOffice.

194

features of over-loading, re-naming and default parametersall complicate the task of cross-reference.

This paper considers the general area of programdevelopment environments and introduces a new program-ming environment, IDEA. The development of IDEA hasresulted from a research project at Paisley College ofTechnology on developing an incremental Ada compiler,funded by the Alvey Directorate and the GK Science andEngineering Research Council.

The aspects of the environment dealt with in this paperare those that are of interest to project managers and pro-grammers.

2 Project environments and programming

Over the last ten years, the concept of the software environ-ment has been increasingly seen as distinct from that of theoperating system. While the operating system of a com-puter system is designed to be general purpose in nature,a software environment is a combination of softwareutilities that permits a system to be used to best effect fora particular purpose, such as software development.

Project support environments have been under discus-sion now for a number of years, and much attention hasfocused on the underlying database aspects of such en-vironments (Refs. 3 and 4). In parallel with this work, atten-tion in software engineering has concentrated on formalmethods for requirements analysis, specification anddesign of projects. Relative to these aspects, the productionof program code from a good design has been seen as alow-level task. This is understandable from the viewpoint ofrisk analysis, since once the project is complete the cost ofrepairing errors introduced during the coding phase is verymuch less than the cost of repairing errors made during thespecification phase.

For these reasons, the programming phase has beensomewhat neglected as an area where software tools shouldbe introduced. Another reason is that, where computer pro-cessing time is a chargeable resource, a sophisticated toolthat incorporates an editor is likely to be seen as moreexpensive to use than a simple text editor and compiler.But now much of this analysis needs re-examination.

Software Engineering Journal November 1987

First, the language features of Ada ensure that the com-piler does a lot of checking of correct usage acrossmodules. With standard 'batch' compilation, this checkingmust be done each time a source module is submitted forcompilation, even for parts of the program code that havenot changed. A system where the editor monitored theextent of the changes and only submitted that portion forre-compilation would save considerable time.

Secondly, the cost, measured either in days or in man-days, of altering the system is becoming more importantthan the cost of processor time. This is particularly truewith the increasing use of personal workstations, and alsowhere the use of programming languages at the earlierstages of a project (prototyping, requirements analysis,design) means that key staff are involved in a programmingactivity. In these circumstances, it becomes well worthwhile to invest in a software tool that provides compilationon-the-fly during editing, eliminating the time wasted insubmitting an erroneous program to the compiler.

Thirdly, one of the main motivations for softwareengineering is the 'high cost of maintenance', whichinvolves modifications to an existing project. At first sight,it might be thought that maintenance costs will be less ifbetter software engineering techniques are used. But a wellengineered software product will be more modifiable, andtherefore survive longer, so that a greater proportion of itslife cycle will consist of maintenance. During maintenance(Fig. 1), support staff are often faced with examining ormodifying unfamiliar parts of the project, and followinglengthy chains of cross-references between modules.

Thus a good software environment for Ada developersand maintainers will provide help with the task of followingcross-module references. The programming environmentdescribed in this paper provides exactly this kind of seman-tic assistance.

At the same time, the necessity for other documentationto be consulted during such inspection and modification ofcode is likely to grow. The code will be spread over manyfiles, and documents giving an overview of the design ofvarious parts of the project will be needed, and the relation-ships between them must be kept up to date.

The environment should encourage, even if it does not

enforce, the consultation of a relevant fragment from thedocumentation while editing code. This implies both theuse of a multiple-window editor and the use of the sameediting environment for documents and program code. Italso suggests the use of machine-readable tags for assist-ing cross-references between documents.

Finally, if documents as well as code are being modified,software configuration management becomes doublyimportant, and it is not hard to imagine that future en-vironments could provide assistance in maintaining suchsuites of documents. These features have been extensivelystudied as part of this project (Ref. 5).

3 IDEA

IDEA (Fig. 2) provides an incremental development environ-ment for Ada projects, and aims to satisfy the needs outlinedin the previous sections (Ref. 6). A key step in developingthis environment was to combine the editor and compilerinto a single tool, integrated within the project environment.This combination supports structured editing of programtext, incremental compilation, error recovery and semanticassistance. Integration with the project environment supportsinteractive testing, document cross-checking and configura-tion management. This paper concentrates on the editor-compiler combination, since the incremental Ada compilerwithin IDEA is of independent interest.

The Ada compiler in IDEA combines an incrementalversion of the validated York University Ada Workbenchcompiler (Ref. 7) with the Emacs customisable editor (Ref.8). The incremental version of the York compiler wasproduced by modifying the routines of the syntax andsemantic phases so that they may be called separately to dealwith fragments of the Ada program, and to support re-synchronisation of the compiler phases during error recoveryor editing (Ref. 9).

3.1 The abstract syntax tree

Integration of the editor and compiler is achieved usingthe abstract syntax tree (AST) as a shared data structure.

The syntax tree is the compiler's internal representation

softwareperformance

report

designdocuments code

modules

system

updatedoc.

newsystem

softwareconfigurationmanagement

tofield

Fig. 1 Maintenance activities

Software Engineering Journal November 1987 195

filesdocuments

normalediting

otherbuffers

objectbuffer

assemblerlinker

debugger

Fig. 2 IDEA

of the program text. It is a hierarchical structure of nodes,each of which relates to a syntactic component in the sourceprogram (for example procedure, statement, conditionclause). The syntax tree is initially built during the syntaxphase, and has additional information inserted by subsequentphases. This information is stored as attributes at each node.

To support incremental compilation, some further infor-mation is added to nodes of the AST that are suitable forsynchronising the various phases of compilation with theeditor state. Thus there are editable, parsable, checkable andcodable nodes. In general these are increasingly restrictiveconditions, so that a codable node is also checkable etc.Machine-generated tables, derived from the description ofAST node types, allow the editor interface to interpret high-level commands such as node-next, node-up in terms ofmovements from one node of the AST to another, providenode-type descriptions such as 'representation-clause' or 'listof statement', and provide other information about nodetypes in the AST.

An editable node corresponds to a fragment of programtext, and the additional information stored with it is the filename, the start of the fragment relative to the start of itsparent, and its length. Syntax-directed cursor movementcommands allow the user to move from a node of the syn-tax tree to its eldest child, next or previous brother, or parentnode. Each move command moves the cursor to the begin-ning of the source text for the node moved to. Most editablenodes are also parsable. Mo further additional informationis required for a parsable node, except that a table of parsingroutines allows incremental re-parsing of any parsable node.

Checkable nodes correspond to a declarative region in anAda program. The additional information must enable thedictionary of declarations in scope to be updated during cur-sor movement. It therefore includes a queue of dictionarymodifications made during the previous semantic checkingof the node, each associated with a subordinate node in thesyntax tree. Using this information, IDEA can ensure thatthe correct semantics are available for giving semantic help

to the user, or for re-compiling a fragment of the programtext.

Codable nodes correspond to a region of an Ada programassociated with a portion of compiler output. Fully incre-mental code generation has not yet been implemented, soat present the only codable node is compilation-unit.

Further technical details of the IDEA implementation andthe issues involved can be found in Ref. 10.

3.2 Editing programs

A number of structured editors for programs have beenconstructed in recent years (see, for example, Refs. 11-15).Some editors use syntax-directed commands exclusivelyto enforce syntactic correctness, and some use templates.Many use pretty-printing techniques. In this project, a mixedapproach has been preferred, because:

• the same editor should be used for editing program textand other documents• the syntax of Ada is so large that there would be toomany templates to remember, and too many nodes in thesyntax tree to make syntax-controlled movement a con-venient way of scanning text• different people may wish to use a different style of pro-gram layout.

Thus in IDEA both text-oriented and syntax-oriented cursormovement commands are supported; the programmerretains control over program layout; templates are providedas a facility for entering text, but text corresponding to a syn-tactic construct can be entered or modified as text (Ref. 16).

When inspecting (browsing) an Ada file, the user maychoose between using syntax-directed cursor movementcommands or the text-oriented movement commands. Thesetwo modes are called syntax-move mode and textual-movemode. At any time, a single keystroke is all that is requiredto change between these modes.

196 Software Engineering Journal November 1987

In syntax-move mode, the normal Emacs cursor-movement commands are disabled, and instead there arecommands to move forward or backward to an adjacent syn-tactic construct at the present level in the syntax tree, upto the parent construct, or down to the first sub-construct.If the terminal has suitable arrow keys these are given thesenew meanings. During syntax-move mode, the compilerphases are kept synchronised with the cursor position, sothat the correct semantic help can be given. In addition, itis convenient to display the current node type in Emacsmode-line, as this helps the user to interpret the effect of thenext cursor movement.

In textual-move mode, the usual set of textual cursor move-ment commands are available, including moving forward orbackward by pages, string searching etc. When any com-mand requires it, the compiler is synchronised with thecurrent position, such as when the user asks for semantichelp.

No changes to the file are allowed during browsing.

3.3 Mode editing

The only way in which Ada text can be modified withinthis system is to perform a 'node edit'. This enables the userto change the source code corresponding to a particular nodein the syntax tree.

The user can enter node-edit mode at any point duringbrowsing of a file. From syntax-move mode, the current nodeis the one that will be edited. From textual mode, the useris allowed to select a suitable node enclosing the currentcursor position. During a node-edit, the cursor may not bemoved outside the scope of the node. In this way modifica-tion is limited to the area specified, thus further controllingthe editing process.

The user may make any textual modification within thescope of the node. Templates are provided to assist the con-struction and formatting of Ada constructs, but these are notprescriptive, and the user may delete or modify parts oftemplates in the same way as any other text. Then the com-piler is invoked on the node as modified, and, if there areno errors, re-compilation of the affected code is completed,and the system returns to the mode that existed before thenode-edit began.

In this way, IDEA minimises the amount of re-compilationdone when a source file is edited, by only re-compiling codeaffected by the node-edit. The scope of the node-edit isre-parsed, the smallest re-checkable node enclosing this isre-checked, and the smallest re-codable node enclosing thatis re-coded. This process is much faster than re-compilingthe whole program.

3.4 Error recovery

If incremental compilation takes place during editing, theuser can be called on to repair language errors interactivelybefore compilation continues. This is faster and more friendlythan allowing error messages to multiply, possibly with manyspurious messages resulting from attempts to recover fromearlier errors.

This aspect of incremental compilation has received atten-tion in only a few systems (Refs. 17 and 18).

IDEA's immediate error recovery mechanism allows theuser to repair syntax and semantic errors, individually, asthey are detected. If an error is detected, an appropriate er-ror message is displayed in a help window, and the cursoris placed on the offending code. However, the compilationis not aborted. Instead, the parser backtracks to the start ofthe current syntactic unit, and parses up to the cursor posi-tion that indicates the error; i.e. the parser re-synchronises

Software Engineering Journal November 1987

on the current cursor position.A syntax error must be corrected before the parser will

continue processing the rest of the text, and the editor buf-fer containing the erroneous text cannot be saved to disk.

During error recovery, the user is presented with the fullediting interface, in a special error-recovery mode. In thismode, any sequence of keystrokes that defines a commandcauses the parser to be re-entered, provided the cursor is inthe relevant buffer. For instance, a printing character definesan editor command, to insert the character in the buffer: thischaracter is also supplied to the lexical analyser, and theparser is suspended again when the next character isrequired.

If the user enters rubout, or a cursor movement command,the parser is re-synchronised on the new position. If the userconsults another document, or requests semantic help, theparser continues to wait in the background until the cursorreturns to the buffer that is being parsed. This interface isan improvement on the mechanism described in Ref. 9.

Two additional commands allow the user to escape fromthe parser during error recovery. One is to revert the changedtext to its state before the node edit; the other is to abortthe parse, and continue the node-edit.

An error arising in the later phases of the compiler ishandled similarly except that in this case the user is returnedto the node-edit mode. The present implementation startsthis node-edit for the declarative region where the error wasdiscovered: this is appropriate if the user needs to add oralter a local declaration, but if the problem is that an identi-fier has been mis-spelled this strategy results in a wastefulenlargement of the region that requires re-compilation. Toavoid this, the old semantic information would need to bestored somewhere so that it can be reclaimed and theprevious node-edit environment restored (Ref. 10).

3.5 Semantic assistance

While increased compilation speed is a major advantagein any program development environment, it is not the onlyadvantage that an incremental compilation system canprovide. Further aid can be given in the form of semanticassistance. This allows the programmer to obtain informa-tion on the definitions of objects declared for use within theprogram.

Since an Ada program may be spread out over manymodules, it becomes increasingly difficult for the program-mer to retain an overall picture of the program, and to utilisethe various components therein, without frequently referringto many other files and documents. Semantic assistance isalso important in dealing with overloading and re-naming.The programmer may make reference to the use of someoverloaded object and immediately find out which of thevarious declarations is being applied. Alternatively, the usercould obtain information on all the overloading declarations.

This function can be readily provided since the informa-tion used by the incremental compiler to check semanticcorrectness is readily accessible. In traditional environments,reliable semantic assistance cannot be provided within theeditor, because the semantic information is inaccessiblyburied within the system compiler.

IDEA provides on-line semantic assistance. This enablesthe user to obtain information on any declared object whichhas meaning at the current cursor position.

Semantic assistance is available at any point duringbrowsing, node-editing or error recovery for an Ada sourcefile. The user may ask for the definition of a particular occur-rence of an identifier in context, or may ask for informationabout an identifier or pattern. In the first case any overloadinghas already been resolved by the compiler, and chains of

197

declarations, re-naming, sub-types and so on can be traversedby moving the cursor into the help window and requestinginformation on identifiers there.

In the latter case the list of visible objects is scanned fora match, starting with the most local objects. During cursormovement, the scope information is updated so that thisinformation is directly available from the data structures ofthe Ada compiler. Patterns can include wildcard charactersor sub-strings. The information provided in each case con-sists of the declaration of the object referred to.

3.6 Interactive testing

Incremental compilation can also be used in later stagesof software development as well. There are great oppor-tunities for rapid prototyping and debugging in an incremen-tal environment (Ref. 18), particularly, as is argued in Ref.19, if the environment supports dynamic compilation.

Upon making a modification to the program source, theprogrammer would immediately be able to execute therevised edition of the executable image, in the same manneras many interpreter-based development systems operate. Ifbeing used to cross-compile for a different machine, theincremental development system need not transmit the newversion of the object code, but instead only the changes pro-duced by the program-edit (Ref. 20).

This aspect represents a growth area in the continuingwork on IDEA. In the present implementation the facilitiesfor interactive testing do not improve on those available instandard Emacs packages.

3.7 Implementation and use of IDEA

IDEA is implemented on a DEC VAX 11/750 using theEmacs editor interface under GNIX 4.3 BSD.§ This hostsystem does not need to match the target system for whichthe Ada project is being developed, because the portabilityof Ada ensures that most, if not all, of the project can bedeveloped and tested on another host.

4 Conclusions

An incremental development environment for Ada has beendescribed, which assists the programmer to exploit the soft-ware engineering features of the Ada language in large-scaleprojects.

Three years ago, there was considerable scepticism thatincremental compilation is possible for Ada, and this pro-ject has broken new ground in this area. Most of the YorkAda compiler has been re-used in IDEA, incorporating it intoan extended version of the Emacs screen editor. The result-ing environment is usable on any UNIX 4.3 BSD system.

Since the editor and compiler are integrated into theenvironment, reliable semantic diagnostics and assistanceare provided, in contrast to syntax-directed editors, whichcan only assist with lexical and syntactic errors.

It is believed that use of this type of environment cansignificantly reduce the costs of the programming activityin a project, and that it will have a dramatic effect in themaintenance phase of Ada projects. It is hoped that quanti-fication of these benefits will be undertaken in the nearfuture.

Other planned future work includes the application ofknowledge-based methods to help systems, the extensionof the environment to interactive testing and debugging, andautomatic cross-referencing to design documents.

§UNIX is a trademark of AT&T Bell Laboratories.

198

5 Acknowledgment

It is a pleasure to acknowledge the helpful comments of staffat Paisley College of Technology, notably those of TonyShaw, in preparing this paper.

6 References

1 SAUMDERS, M. C, and DAWES, S. J.: The use of Ada as a designlanguage as it relates to JSP 188', Ada User, 1986, 7, (3), pp.3 2 - 3 8

2 BLOWER, M. I.: 'An efficient implementation of visibility in Ada',SIGPLAN Notices, 1984, 19, (6), p. 259

3 'Requirements for Ada programming support environments'.'Stoneman' Document, US Department of Defense, Feb. 1980

4 BOURGUIGNON, J. P. et al.\ PCTE: a basis for a Portable Com-mon Tool Environment'. Functional Specification, CEC ESPRITProgramme, Project 32, 1985

5 MACKAY, D.: Tools for software configuration management'.M.Phil. Thesis, Paisley College of Technology, Paisley, Scotland,1986

6 CROWE, M. K., NICOL, C, CORR, M. E., ORAM, J. W., andJENKINS, D.G.: 'A software development environment for Ada'.Proceedings of European Software Engineering Conference,Strasbourg, France, 1987

7 FIRTH, J., FORSYTH, C. H., TSAO, L, WALKER, K. S., andWAND, I.C.: 'Facts and figures about the York Ada compiler',Ada Letters, 1987, 7, (4), pp. 85-87

8 GOSLING, J. A.: 'Unix Emacs'. Carnegie-Mellon University, Pitts-burgh, PA, USA, 1982

9 CROWE, M. K., NICOL, C, HUGHES, M., and MACKAY, D.: Onconverting a compiler into an incremental compiler', SIGPLANNotices, 1985, 20, (10), pp. 14-23

10 NICOL, C, and CROWE, M. K.: 'An interactive error recoverymechanism'. Paisley College of Technology, Paisley, Scotland,July 1987

11 TEITELBAUM, T., and REPS, T.: The Cornell Program Syn-thesizer: a syntax-directed programming environment',Communications of ACM, 1981, 24, (9), pp. 564-574

12 LONGE, M. R.: The line-oriented approach', SIGPLANNotices, 1986, 21, (4), pp. 70-74

13 GOLDBERG, A.: The influence of an object-oriented languageon the programming environment'. Proceedings of ACM Com-puter Science Conference, Orlando, FL, USA, Feb. 1983, pp.35-44

14 COOPER, K. D., KENNEDY, K., and TORCZON, L: Editing andcompiling whole programs'. Proceedings of ACM SIGSOFT/SIG-PLAN Software Engineering Symposium on Practical SoftwareDevelopment Environments, SIGPLAN Notices, 1987,22, pp.92-102

15 ENGELS, G., NAGL, M., and SCHAEFER, W.: 'On the structureof structure-oriented editors for different applications'.Proceedings of ACM SIGSOFT/SIGPLAN Software EngineeringSymposium on Practical Software Development Environments,SIGPLAN Notices, 1987, 22, (1), pp. 190-198

16 NICOL, C, and CROWE, M. K.: Textual editing of Ada undersyntax-directed control'. Paisley College of Technology, Paisley,Scotland, June 1987 (Submitted to European Symposium OnProgramming 87)

17 De RIDDER, T.: 'Automatic generation of syntax directed screeneditors', EUUG Newsletter, 1984, 4, (2)

18 MEDINA-MORA, R., and FEILER, P.: 'An incremental program-ming environment', IEEE Transactions on Software Engineering,1981, SE-7 , pp. 472-482

19 CROWE, M. K.: 'Dynamic compilation in the Unix environment'.Paisley College of Technology, Paisley, Scotland, 1986 (Submit-ted to Software — Practice & Experience)

20 FRITZSON, P.: Towards a distributed programming environmentbased on incremental compilation'. Ph.D. Thesis, LinkopingUniversity, Sweden, April 1984

C. Nicol, Prof. M. K. Crowe, M. E. Corr, J. W. Oram and D. G. Jenkinsare with the Software Tools Research Group, Department of Com-puting Science, Paisley College of Technology, High Street, Paisley,Renfrewshire PA1 2BE, Scotland.

Software Engineering Journal November 1987