interactive language development for embedded ... - Semantic Scholar

Nordic Journal of Computing 6(1999), 36{55.

INTERACTIVE LANGUAGE DEVELOPMENT FOR EMBEDDED SYSTEMS ELIZABETH BJARNASON GO REL HEDIN KLAS NILSSONx Department of Computer Science, Lund University Box 118, S-22100 Lund Sweden fGorel.Hedinj [email protected]

Abstract. Domain-speci c languages form programming support leading to simpler and safer programs, which is highly desirable for programming embedded systems and manufacturing equipment. However, language design is non-trivial, and the required development eort is often too costly for industrial projects. To cope with this problem, we have implemented a highly interactive tool, APPLAB, for developing and experimenting with domain-speci c languages, and used it in the development of a programming environment for industrial robots. APPLAB supports the development of domain-speci c languages by providing a high-level speci cation formalism (reference attributed grammars), and by providing integrated language-based support for editing syntax, semantics and the application program. The tool was connected to an industrial robot and confronted with programming topics encountered in typical industrial applications. Experiences from our full-scale prototype, including the development of a robot programming language, shows that interactive language development is very bene cial for programming of embedded systems.

CR Classi cation: C.3, D.1.5, D.2.6, D.3.4 Key words: domain speci c languages, interactive tools, attribute grammars, embedded systems, industrial robots

1. Introduction Programming of embedded systems is a dicult task that can be aided by the use of domain-speci c languages (DSLs). Such languages can be designed to contain speci c language constructs which enclose what would otherwise be informal programming conventions, thus leading to simpler and safer programs. Designing a new language is an iterative process where language constructs are designed and tested in a prototypical fashion. In particular, DSLs may need to evolve rapidly due to new requirements that emerge as the domain  x

Now at Ericsson Mobile Communication; [email protected] This work was mainly carried out when at Dept. of Automatic Control, Lund University.

Received October 2, 1998; revised December 15, 1998; accepted January 27, 1999.

INTERACTIVE LANGUAGE DEVELOPMENT

37

develops. Compiler-compiler tools are useful when implementing a fully designed language, but while designing a new language, or changing a language, it is desirable to work in an environment that supports the language design process in an integrated and incremental way. We call such an environment a language laboratory. We have developed a language laboratory called APPLAB (APPlication language LABoratory) [3] and used it in the implementation of RAPID [2], a robot programming language. APPLAB has also been integrated with a robot system (an ABB Irb-6 industrial robot), and used as a front end to the system, allowing applications to be written, downloaded, and run directly from the APPLAB tool. This paper reports on our experience from using APPLAB for developing languages for embedded systems. As a result of this experience, we suggest enhancements to the language to better support the special needs for robot programming. We also identify additional tool support that would be useful in connection with developing DSLs, and how such functionality would t into a tool like APPLAB. The rest of this paper is organized as follows. Section 2 gives an overview of APPLAB. Section 3 describes a case study in which APPLAB is used for developing a robot programming language. Section 4 discusses language constructs for so called modal settings, a speci c need in robot programming, and proposes some enhancements to the RAPID language to better support these needs. Section 5 summarizes our experience with APPLAB and identi es interesting possible future development. Section 6 concludes the paper.

2. The APPLAB system The APPLAB system is a language laboratory supporting the interactive development of DSL speci cations and, at the same time, editing environments for the new DSLs. The editing environment supports language-based editing, including structure-oriented editing, incremental parsing, and semantic editing (explained later). The environment also supports static-semantic checking and code generation. All this functionality is speci ed by grammars for the DSL. The most distinguishing characteristic of the APPLAB system is that the language designer can switch freely between editing the language speci cation and editing a program in the (changing) new language. The eects of changing the language speci cation are immediately seen in the edited program without requiring the user to issue any special updating commands. For example, new language constructs can be added in the DSL speci cation and immediately be tried out in the DSL program editor. Similarly, the staticsemantic speci cation and the code generation speci cation can be changed and the eects can be immediately tried out on a sample program.

38

E. BJARNASON, G. HEDIN, K. NILSSON

2.1 Grammar interpretation The grammars are represented internally by abstract syntax trees (ASTs). To accomplish the tight integration between editing the speci cations and example programs, the internal tools in APPLAB either interpret the grammar ASTs directly, or they interpret other data structures generated from the grammar ASTs in order to obtain better eciency. In the latter case, the data structures are regenerated automatically when needed (e.g., when the program is edited after a series of grammar changes). This grammar interpretation [16] distinguishes APPLAB from traditional compiler-compiler systems such as Yacc [11], the Synthesizer Generator [21], and Eli [8], which are based on source code generation, i.e, where compilers and editors are built by compiling and linking source code generated from language speci cations. 2.2 APPLAB speci cations An important goal for APPLAB is that the speci cations should be easy to write. For this reason, the speci cation is centered around an abstract syntax rather than a parsing syntax. Static-semantic checking and code generation can be speci ed using an object-oriented attribute grammar formalism called reference attributed grammars [9]. This formalism diers from ordinary attribute grammars by allowing attributes to be references to other nodes in the syntax tree. Furthermore, nonterminals and productions are replaced by classes and syntax tree nodes are considered to be instances of these classes. The use of reference attributes allows name analysis to be speci ed in a much easier way than in normal attribute grammars, permitting references to connect for example use sites with declaration sites and to propagate attributes directly along these connections in a program. In particular, this is important when specifying object-oriented languages which have many dependencies which do not follow the syntactic tree structure, e.g. inheritance. Once de ned, these reference attributes can be used to propagate other kinds of information and be used to simplify the speci cation of for example code generation or other static analyses. 2.3 An example Fig. 1 shows a screen-dump from an APPLAB session. The DSL is a toy object-oriented language called picojava which contains the core object-oriented language constructs like classes, methods, inheritance, and reference variables. The rightmost window, PROGRAM, is a program editor on an example program in the developed DSL. The primary editing style is structureoriented editing, where the user can expand placeholders in the program by selecting language constructs from a menu of all syntactically legal constructs at the editing focus. The system also supports text editing by allowing any syntactic unit (corresponding to a subtree of the syntax tree) to be edited as text and subsequently parsed. A third editing possibility is semantic editing which provides the user with menus of identi ers, based on the

INTERACTIVE LANGUAGE DEVELOPMENT

39

: A grammar containing dierent semantic aspects and an example program.

Fig. 1

static semantics of the language. For example, menus may be de ned which present all the visible and type correct identi ers at the current editing focus. Semantic editing relieves the user of having to remember exactly what is declared in dierent parts of a program or speci cation, and the exact spelling of the declared identi ers. To the left in the gure, several grammar windows are shown:  The ABSTRACT grammar de nes the abstract context-free syntax for the language, using a BNF style AND/OR grammar.  The CONCRETE grammar de nes the concrete syntax, i.e., keywords and indentation information de ning the textual representation of an abstract syntax tree.  The PARSE grammar de nes additional rules necessary for parsing text into the abstract syntax trees described by the ABSTRACT grammar, for example, rules for operator precedence and associativity which resolve the ambiguities of the ABSTRACT grammar.  The OOSL grammars de ne object-oriented reference attributed grammars for various purposes: name analysis, type analysis, static-semantic checking of various language constructs, code generation, and speci cation of the semantic-editing menu.

40

E. BJARNASON, G. HEDIN, K. NILSSON

At any time, any of the grammar aspects may be edited and this will have an immediate eect on the PROGRAM window. For example, changing the concrete syntax of the assignment statement will cause the displayed text representation in the PROGRAM window to change accordingly. Adding a new language construct in the ABSTRACT and CONCRETE windows will automatically add the construct to the structure-editing menu in the PROGRAM window, and will make the parser recognize the new construct. Adding attributes and equations to perform a new check in one of the OOSL-Check windows will cause one more check to be carried out when performing static-semantic checking in the PROGRAM window. Changing the equations in the OOSL-CodeGeneration will cause other code to be generated when performing code generation in the PROGRAM window. This integrated support for changing grammars and experimenting with the resulting program editor allows very fast development and feedback during grammar design and development. 2.4 Implementation status APPLAB is implemented in Simula [22] and runs on SUN workstations. It is an "industrial prototype", i.e., it is has sucient functionality for evaluation and for use in real-sized case studies, but it is not suciently robust for production usage. The system is available free of charge for research and evaluation purposes. The largest case study done with APPLAB is the implementation of a robot programming language (212 production rules) which is discussed in more detail in Section 3. We have also performed a number of smaller case studies. In addition, all the formalisms for the dierent grammar aspects are themselves DSLs developed in APPLAB. 2.5 Related systems APPLAB is the result of further development of an earlier language laboratory which was part of the Mjlner/Orm environment [15, 17]. Other systems which aim at interactive support for language design include DOSE [6], Muir [24, 20], the ASF+SDF Meta Environment [12], TaLE [10], and PROGRES [5]. Of these, DOSE and Muir were research prototypes which are no longer available. A main dierence from the mentioned systems is APPLAB's semantics support based on object-oriented reference attributed grammars.

3. Robot case study APPLAB has been used in a number of case studies, the most extensive one being a case study for robot programming, where APPLAB was used to implement the robot programming language RAPID [2] and used as a front-end for operating an ABB Irb-6 industrial robot. The case study was carried out in cooperation with the Department of Automatic Control at Lund University, using information provided by ABB Robotics Products AB.

INTERACTIVE LANGUAGE DEVELOPMENT

41

The purpose of the case study was to explore the usefulness of interactive language-based tools for DSL development and programming in the context of robot programming, and in the course of doing so, to evaluate APPLAB and to identify desired extensions of APPLAB to further support DSL development. 3.1 Robot programming When programming industrial robots there are several dierent levels of programming involved [18]: the motion control level, the application-speci c level, and the end-user level. Fig. 2 illustrates these dierent levels. At the motion control level, the motion control software is implemented at the robot manufacturing company, and the interface is delivered together with the robot. At the application-speci c level, the application expert uses the motion control interface to implement an application-speci c package which specializes the robot for a speci c application, such as arc welding [1], spot welding, assembly, grinding, or gluing. At the moment this phase is most often done by the manufacturers themselves, since the design of the application packages requires detailed knowledge of the system design including the motion-control interface. The resulting specialized robot is delivered to a customer, or end-user, who wishes to use the robot to manufacture some product. Programming is then done at the end-user level, typically by using a dedicated robot programming language together with data from teach-in or CAD/CAM systems [4]. Welding application

Interface Welding package

Interface Motion control

End-user level (End-user programmer)

Application-specific level (Application expert)

Motion control level (Robot developer)

Fig. 2: Dierent levels of robot programming. \Welding" exempli es a standard, but demanding, robot application.

In order to simplify the programming between the dierent levels, a DSL could be introduced for each level. In this paper we mainly discuss DSLs and the usage of the APPLAB tool to implement the end-user level. For this purpose, we decided to use ABB's robot programming language RAPID [2] as a base for this case study. It is a Pascal-like language especially designed for robot programming. The fact that each robot vendor has

42

E. BJARNASON, G. HEDIN, K. NILSSON

designed their own robot language is often criticized by the rest of the software engineering community (reinvention of computer programming). New languages are, however, designed to better support the robot programmer in typical manufacturing situations. In fact, the variety of dierent robot programming languages shows the need for DSLs. In the ABB case, the special properties of the RAPID language and its run-time system include: Backward execution: A backward handler can be de ned for a block of motion statements, allowing the robot to move backwards along its programmed path. This is used during testing and tuning of a robot program. Interactive setting of execution point: During testing and on-line programming, the execution point can be moved interactively by the user, allowing statements to be executed in any order. This allows fast turnaround between editing and execution during testing and debugging. Placeholders: Non-de ned parts of a program can be represented by placeholders. The program is then syntactically correct but upon attempting to execute a placeholder, execution stops. Yet unde ned robot poses are also allowed in the language. During execution the user is prompted to de ne these robot poses via a teach-in procedure, in order to adopt to the actual position of a workpiece. Modules: Libraries or application features can be packaged as modules which can be dynamically loaded into memory when needed. Persistent variables: A variable declared as persistent (PERS) remains after a power failure. The robot can automatically resume execution and continue its task. Number variables: Floating point and integer values are declared as the same type (NUM). Their internal representation is of no interest to the robot user. An embedded interpreter, developed within ABB Robotics, for the RAPID language is delivered together with new ABB robots today. Note that interpretation, instead of compilation, is not a problem concerning execution speed (the mechanical robot is slower anyway), but the interpretation has to take place on the target computer to ensure timely operation. When developing a language such as RAPID, or when extending it for special application areas like welding or gluing, appropriate language-design tools are, of course, highly desirable. 3.2 Experimental setup The Irb-6 robot used in our setup has ve degrees of freedom, which means that there are ve motors moving the ve joints of the robot. On each motor there is a sensor for reading its angular position. The motion control software running on the target computer controls the robot by reading the

INTERACTIVE LANGUAGE DEVELOPMENT

43

sensors of the robot, computing the necessary control signals to achieve the desired actions of the robot, and sending these signals to the robot's actuator hardware. The existing motion control software of the robot laboratory and its interface was used, see [18] for further details. The Interface of the motion control system consists of a number of library routines written in C and Modula-2. These routines provide, for example, access to the current position of the robot, and control of the robot arm and the gripper. The target computer is a VME-based Motorola 68040 board with a network interface connected to Sun workstations which are used for software development and for running software tools such as APPLAB. It is highly desirable to be able to change and reload the robot program while the robot is working. This implies loading and binding the compiled application program to software already running in the target system, and also to deallocate the program when not used any more. This is dealt with in the embedded execution environment using a dynamic loading technique with cross compiled `plug-in' code pieces which are host controlled and managed over the network via a server in the embedded system [19]. 3.3 Implementing the end-user DSL in APPLAB

An extended and modi ed version of RAPID was implemented in APPLAB. Instead of implementing full interpretation (backwards and forwards) and binary code generation, we decided to take the short-cut to map RAPID to C code and to only support the sequential execution model. A standard C compiler can then be used to generate executable code for the hardware actually used. This approach was taken since we are interested in studying the language level, and not the details of the run-time system. The RAPID to C translation was conveniently done by using the attribute grammar support supplied by APPLAB. An OOSL aspect of the RAPID grammar was used to describe the mapping from RAPID to C. A code attribute and equations de ning this attribute were declared for each grammar rule. The C-translation of a RAPID program can then be generated by evaluating the code attribute of the root of the RAPID program tree. Fig. 3 shows how a MOVELIN-statement in RAPID is translated to C, using the embedded execution environment by accessing a MoveLinear-function. This is later executed by a call to a routine in the basic motion control system. A more complete example is shown in Fig. 4 which contains a snapshot of an APPLAB session. The code generation for the robot-speci c instructions move_linear and grip_on, is shown in the OOSL window. The PinTray window shows part of a RAPID program which gets pin by pin out of a tray and puts them at some goalPos. Part of the C code generated for the PinTray program is shown in the C-code window. The calls to NextInstruction are used to allow step-wise execution of the program currently running on the robot.

44

E. BJARNASON, G. HEDIN, K. NILSSON

RAPID grammar (OOSL)

RAPID program ... MOVELIN x; ...

void RapidProgram() ... MoveLinear(x); ... Generated C-code

move_linear: node C_lib_proc::= (a_C_exp: ref C_exp) { eq code := nl_indent& "MoveLinear("&a_C_Exp.code&")" };

MoveLinear(x): Trajec.CartGoto(x, 0.0, Trajec.EmptyProcedure, Trajec.EmptyCartProcedure, Trajec.EmptyJointProcedure, Trajec.EmptyStateProcedure); Call into motion control system

: An example of accessing motion control routines in an end-user program. The \Empty.." arguments supplied to the CartGoto function of the trajectory generator are dummies; these formal parameters are used for more advanced motions. Fig. 3

3.4 Execution of application programs In order to control robot-program execution from APPLAB, a menu containing the commands Load program, Run, Step and Stop was added. Upon issuing the Load program command APPLAB performs code generation for the current program, i.e., generates C code and compiles it. The crosscompiled code is then sent to the embedded execution environment along with a Load-signal. The application program is then dynamically linked and loaded into the memory of the target computer. When the end-user issues a Run or a Step command, the corresponding signal is sent by APPLAB to the interpreter of the embedded execution environment which launches the execution of the currently loaded program. 3.5 Debugging support for RAPID programs Debugging support for RAPID programs was achieved in APPLAB using a hook technique. As mentioned above, a call to NextInstruction is generated for each statement in the RAPID program. Each node in the AST for the RAPID program has a unique id number which is used as a parameter to the NextInstruction call. The NextInstruction procedure returns control to the interpreter which decides whether to continue executing or to stop. During step-wise execution, a step-signal is sent back to the invoking APPLAB session, including the AST id number used in the NextInstruction call. Upon receiving this signal, APPLAB locates the corresponding RAPID state-

INTERACTIVE LANGUAGE DEVELOPMENT

45

Fig. 4: A screen-shot from APPLAB showing the Rapid program PinTray and its corresponding C-code. The RAPID-to-C translation is de ned in the OOSL window.

ment and highlights it to indicate the current point of execution. Execution is resumed by the interpreter when the user issues a step or a run command which sends the corresponding signal to the interpreter.

4. Adapting the DSL for dierent applications The RAPID language is in itself a DSL for general robot programming, but when considering dierent kinds of applications, like gluing or welding, the problem domain is more narrow. Instead of general robot movements the user is concerned with application-speci c actions like, for example, turning the welding equipment on and o. In standard RAPID this is achieved by using a module (library) containing the application-speci c routines. The syntax of procedure calls in RAPID is such that they can be perceived as being part of the language (i.e., without parentheses). Even so, the problem remains of informal conventions for correct usage of the routines.

46

E. BJARNASON, G. HEDIN, K. NILSSON

4.1 The problem of modal settings The de nition of desired language extensions is a topic of its own, but one desired feature is to support the robot programmer concerning so called modal settings [18]. Examples include base coordinate systems, speed limits along programmed paths, or some application-speci c settings of external equipment. Such settings are typically made via procedure calls that set or restore some logical state of the system. Since the programmer explicitly has to restore the settings, this technique often gets hard to manage when robot programs grow in size and complexity. In particular, the modal settings are problematic within so called on-line programming when the programmer may edit and execute individual statements in any order, not necessarily in sequence. Before executing any statement in this way, the modal settings relevant for that statement must be set so that the settings of the equipment agree with the assumptions made in the program. In robot systems today, this is handled manually by the programmer, and when not correctly done the result may be unexpected (and sometimes dangerous) robot behavior. Without going into the details of industrial robot programming, let us illustrate how DSLs can help solve this type of problem. As an example, assume that we have a robot language in which we can express linear motions between de ned poses using a MOVELIN statement; a motion starts from the current pose of the robot arm and the robot hand is moved in a straight line to the pose de ned by the coordinate following the keyword MOVELIN. Then, as an attempt to handle the modal settings in a structured way, we want to extend the language in two ways:  Introduce the possibility to express motion coordinates relative to a local coordinate system which is called a frame [4]. In the robot programs we refer to the frame via the FRAME identi er. Programming a sequence of motions relative to a given frame should be supported. On-line programming of such motions requires the frame to be properly initialized to ensure that the motion speci cation really is relative to the frame. Otherwise, when the frame is moved due to a relocation of its corresponding work-piece, the robot motions will not be properly adjusted, and an unexpected robot motion (back to the old location of the work-piece) will occur. Note that it is maintenance of system state that is the problem, and not the use of local coordinates as such.  Dedicated support for arc-welding applications. This is related to the previous item in that we need a DSL extension in terms of a `local welding scope', or block, i.e., the system should ensure that welding is started and stopped properly when such a block of the robot program is entered and exited. This application-speci c block has been named ARCWELD. An ARCWELD statement accepts welding parameters (such as voltages, currents, wire feed etc.) de ning how to perform welding within its scope. Fig. 5 shows an example of the use of both the FRAME and ARCWELD constructs. The modal coordinate settings automatically hold within the FRAME block,

INTERACTIVE LANGUAGE DEVELOPMENT

MOVELIN home; FRAME base_plate MOVELIN start_pose; ARCWELD \I:=10 \U:=60 MOVELIN mid_pose; MOVELIN end_pose; END; END; MOVELIN clean;

47

! Coordinate system implicitly set ! startweld(10,60) implicitly called

! stopweld implicitly called ! Coordinate system implicitly reset

Fig. 5: Proper management of modal settings can be ensured by implementing special language constructs which deal with the settings.

and similarly, the modal settings for arc-welding hold within the ARCWELD block which is nested within the FRAME block. During teach-in or debugging the user may explicitly move the execution point by entering or exiting blocks and moving the execution point to an arbitrary position within a block. The system can then automatically set and reset the corresponding modal settings so that the state of the equipment agrees with the program assumptions, and statements can be executed safely [18]. The original RAPID language does not include special language constructs for modal settings. It only provides a xed set of intermediate frames which can be used as optional arguments to procedures and motion statements, but these frames are data and not supported by the language. In the APPLAB implementation of RAPID, it was, however, easy to add the new language constructs, and to experiment with dierent variants of them. The FRAME construct is a general purpose modal setting construct, and would be possible to include in a newer version of RAPID. ARCWELD is, however, speci c to arc-welding applications, and should therefore not be part of the base language. For other applications and equipment, other modal settings would be relevant, and all future modal setting constructs cannot be foreseen. In an environment like APPLAB, it is easy to experiment with new modal setting constructs by adding them directly to the language. Note that, in a production setting, one needs to be able to separate between the de nition of the base (general-purpose) robot language and application-speci c additions. We will now discuss two possible solutions to this, and their consequences for APPLAB. 4.2 Solution 1: multi-layered grammars One solution for separating the base language from the language extensions is to provide support in APPLAB for multi-layered grammars. In this approach, library code can be associated with library-speci c language constructs which are added to the base language and which make use of the library code for their implementation. For example, a library for arc welding

48

E. BJARNASON, G. HEDIN, K. NILSSON

might include functions for welding and also provide language constructs for structured access to the library functions, as for the ARCWELD discussed above. The implementation of the ARCWELD construct may use functions in the library like startweld and stopweld as indicated in Fig. 6. The approach is comparable to macros, where one would de ne ARCWELD as a macro expanding into calls to the library functions. The dierence is that multilayered grammars allow full syntactic and semantic checking of applications using the library-speci c language constructs. An implementation sketch of multi-layered grammars based on ideas from higher-ordered attribute grammars [23] is given in [3]. End-user program programmed in

Extended language

Welding Application

Application library

language constructs for welding (ARCWELD...)

invokes programmed in

startweld... stopweld...

imports

Base language RAPID base language

Language specifications

Source code

: The architecture of a multi-layered grammar.

Fig. 6

4.3 Solution 2: procedure inheritance Another solution for separating the base language from application-speci c extensions is to use a more powerful base language which provides abstraction mechanisms allowing the application-speci c constructs to be expressed directly in the base language. For example, the modal settings discussed above could be expressed directly by making use of procedure inheritance as provided in BETA [13]. Procedure inheritance allows abstract procedures to be expressed which can be specialized, either in the form of a sub-procedure, or in the form of an inline procedure specialization, i.e., a call to an anonymous sub-procedure written in line. (The latter is called "singular item" in BETA.) An INNER construct in the body of an abstract procedure is used to specify where the code of the specialization is to be executed. Consider the example in Fig. 7, where FRAME and ARCWELD have been de ned using an extension of RAPID that supports procedure inheritance (in RAPID syntax). RAPID has here been extended with an INNER construct.

INTERACTIVE LANGUAGE DEVELOPMENT

PROC ARCWELD( \num I, \num U) ! Define welding scope startweld(I,U); INNER; stopweld; ENDPROC

49

PROC FRAME( CoordSystem base ) ! Def. scope of local frame VAR CoordSystem oldBase; oldBase := currCoordSystem; setCoordSystem base; INNER; setCoordSystem oldBase; ENDPROC

: De nition of ARCWELD and FRAME as abstract procedures.

Fig. 7

In the ARCWELD procedure, INNER is used to encapsulate any specialization of ARCWELD with calls to startweld and stopweld which turns the welding equipment on and o in a correct way. The FRAME procedure sets the coordinate system to the value given as a parameter, and after executing possible specialization code it resets the original coordinate system. This de nition of FRAME and ARCWELD allows programs like the one in Fig. 5 to be written, without having to extend the base language. With this implementation, the FRAME and ARCWELD blocks in Fig. 5 are inline procedure specializations of the corresponding abstract procedures de ned in Fig. 7. The speci cation of code generation for inline procedure specializations is straight-forward using the reference attributed grammars of APPLAB. In the grammar fragment shown in Fig. 8, a procedure declaration (ProcDecl) contains two synthesized attributes, preInnerCode for the code occurring before the INNER statement, and postInnerCode for the code occurring after INNER. The statement for inline procedure specialization (SubProcStmt) has two components: a ProcName which is a procedure identi er with the synthesized reference attribute decl which denotes the appropriate ProcDecl, and a Block which is a block of statements to be executed in place of INNER. The code for SubProcStmt is simply the concatenation of preInnerCode, aBlock.code, and postInnerCode. This simple speci cation is possible due to the use of reference attributes like decl, making it possible to propagate the preInnerCode and postInnerCode attributes directly from the ProcDecl to the SubProcStmt. 4.4 Comparison of the solutions For the problem of modal settings, the procedure inheritance solution is the most attractive one since it allows the problem to be handled without extending the language. However, the exact design of the language constructs for procedure inheritance will require experimentation with the RAPID language, a task for which APPLAB is well suited. For example, procedure inheritance could be introduced as a construct speci cally aimed at supporting modal settings, or it could be introduced as a general language construct.

50

E. BJARNASON, G. HEDIN, K. NILSSON

: The speci cation of code generation for the inline procedure specialization.

Fig. 8

In the latter case, the system must somehow be able to distinguish between abstract procedures corresponding to modal settings and other abstract procedures in order to decide which code needs to be executed when execution points are moved during teach-in or debugging. Although the multi-layered grammars are not needed to solve the modal settings problem, this direction is relevant to pursue in order to provide a general language extension facility in the APPLAB environment. Building this kind of support would allow programs in extended languages to be checked and debugged directly in terms of the extended language (rather than in terms of the generated code as for macros). For both solutions, the APPLAB environment appears to provide a suitable platform for experimenting with the implementation of the required functionality.

5. Evaluation In the light of the robot case study, some of the features and possibilities provided by APPLAB will now be evaluated and discussed. 5.1 Grammar formalisms The formalisms used in APPLAB for abstract and concrete syntax are fairly traditional, whereas the object-oriented reference attributed grammar formalism used for static semantics and code generation is unique for APPLAB. The support for reference attributes is a recent but very important addition

INTERACTIVE LANGUAGE DEVELOPMENT

51

in APPLAB. The RAPID grammar was developed without reference attributes, i.e., using traditional attribute grammar speci cation style using complex "environment" attributes. This works reasonably for a procedural language like RAPID. However, for experimenting with language constructs for modal settings, using inline procedure specialization, there is a need for specifying inheritance. Using traditional attribute grammars, this would have been very cumbersome. However, using reference attributed grammars, the speci cation is compact and straight-forward. 5.2 Editing

The three ways of editing in APPLAB: structure editing, text editing, and semantic editing, are all relevant in the language design process and complement each other. Structure editing is traditionally regarded as an aid for novice programmers who are not familiar with the syntax of the particular language. In DSL development, when the syntax may be changed and extended frequently, the user is always more or less a novice on the syntax, and we have found structure editing very useful. As parts of the syntax becomes stable, the user can gradually switch to text editing if desired. In practice, a combination is often used. For editing the grammars, the situation is similar although the grammar formalisms are updated very infrequently. When a new user starts to use the APPLAB system, he/she is unfamiliar with the grammar formalisms and will mostly use structure editing. As the user becomes familiar with the formalisms, text editing is used to a greater degree. Semantic editing aids in keeping track of identi er names and types and is useful both for novices and experts, and becomes more useful as programs grow larger. In the language design situation, semantic editing is therefore most useful in editing the grammars to keep track of the names of language constructs and their attributes. For the programs expressed in the developed DSLs, semantic editing is more important during actual application programming than during language design. 5.3 Integrated grammar and program development

In the development of the RAPID implementation, the language speci cation was revised hundreds of times. Rather than specifying rst all of the syntax and then all of the code generation, the language was speci ed in small increments, trying out the changes immediately in the program editor. The tight integration between program and grammar development in APPLAB was very valuable in supporting this process and in being able to debug the speci cations. When the robot case study was carried out, our extended version of the RAPID language was not xed, and we were able to easily experiment with special language constructs for robot movements and modal settings.

52

E. BJARNASON, G. HEDIN, K. NILSSON

5.4 Version control

The tight integration between grammar and program development applies only to example programs within a grammar document. For separate program documents, APPLAB supplies version control (inherited from the Orm environment), keeping track of which grammar version was used to construct the program document. This allows newer experimental versions of the DSLs to be developed while existing programs continue to use an older stable version. When a newer stable version has been established, the user can decide whether a program should continue to use the old version of the grammar, or if it should be updated to conform to the newer version.This scheme was very valuable in order to make sure that existing programs did not become inconsistent due to language changes, and to allow the user to control when updates to newer DSL versions were made. The same version mechanism is used to bind grammar aspects to the correct version of their meta grammar de nitions. Thus, on a couple of occasions we actually updated the language description formalisms themselves (the meta grammars). The version mechanism then enabled us to update our DSL speci cations in an easy and controlled manner. The version system in APPLAB also supports parallel development of variants of documents. This can be very useful, for example, when two developers are working on dierent aspects of a grammar. However, because merging of variants is not yet supported, we could not make full use of this feature in our case study. For future releases of APPLAB we would like to include advanced ne-grained versioning and incremental merging as discussed in [14]. The support provided by the system to transform a program to adhere to a new grammar version is currently limited, but proved invaluable in handling the numerous small grammar changes. The current automatic transformation can handle simple changes like additions of components to language constructs. More general support for transformation would be desired, e.g. based on techniques like those described in [20] and [7]. Such improvements are necessary for a system like APPLAB to come into production use. 5.5 System integration support

The basis for integration of the APPLAB front end with the embedded system is the use of hooks in the generated code to be able to identify points in the generated code with points in the APPLAB program AST, thus providing traceability between the two representations. This was straight-forward to implement using the technique described in Section 3.5. The support for moving execution points will involve computation of what code to run in order to set the robot to a consistent initial state before continuing execution. Such computations are straight-forward to specify using the object-oriented reference attributed grammars.

INTERACTIVE LANGUAGE DEVELOPMENT

53

For testing purposes, APPLAB has been set up both as a master and a slave in dierent case studies. In the robot case study, APPLAB is the master, initiating actions in the robot. In another case study, APPLAB was set up as a slave process, answering remote procedure calls from a master process. In both these cases, the speci c communication was hand-coded for the case study in question. This should be generalized so that APPLAB can be integrated more easily with other systems. In particular, the menu used to control communication with the target system should be speci ed by a grammar aspect, rather than (as now) hand coded in the system.

6. Conclusions Our case study integrating APPLAB with an industrial robot shows how embedded systems can bene t from domain-speci c languages (DSLs) and from integrated language tools. The modal settings problem exempli es that speci c runtime requirements and application areas call for speci c language constructs that simplify the programming and result in safer programs and testing. Language design is a non-trivial task and the resources available to develop a DSL for a particular embedded system are often limited. APPLAB contributes in three ways to enable this kind of development with reasonable eort. First, the speci cation of a language and its semantics is made straight-forward by the use of reference attributed grammars. Second, the tight integration between editing the language speci cation and example programs gives a tight feedback loop, allowing incremental development of the language, supporting the experimentation needed to obtain suitable language constructs. Third, the interactive language-based editing supports the user in editing programs with a changing, and therefore unfamiliar, syntax and semantics. The APPLAB tool has proved to be suciently mature for development of industrially used languages for embedded systems. In particular, based on experience from our full-scale robot-programming prototype, we found that the speci cation formalisms, the editing support, and the tight integration between grammar and program editing are very bene cial for development of programming support for embedded systems.

Acknowledgements This work was supported by NUTEK, the Swedish National Board for Industrial and Technical Development. We thank the Dept. of Automatic Control, at our university, for access to their robot laboratory. The RAPID-to-C mapping was partly made by Mats Nyberg.

54

E. BJARNASON, G. HEDIN, K. NILSSON

References [1] ABB Flexible Automation. 1995. ArcWare User's Guide. Vasteras, Sweden, Art. No. 3HAB 0011-13. [2] ABB Flexible Automation. 1995. RAPID User's Guide. Vasteras, Sweden, Art. No. 3HAB 0002-24. [3] Bjarnason, E. 1997. Interactive Tool Support for Domain-Speci c Languages. Licentiate thesis, Department of Computer Science, Lund University, Sweden. [4] Craig, J. J. 1989. Introduction to robotics: mechanics and control, second edition. Addison-Wesley. [5] Engels, G., Lewerentz, C., Nagl, M., Schafer, W., and Schurr, A. 1992. Building Integrated Software Development Environments Part I: Tool Speci cation. ACM Transactions on Software Engineering and Methodology 1, 2 (Apr.), 135{167. [6] Feiler, P. H., Jalili, F., and Schlichter, J. H. 1986. An Interactive Prototyping Environment for Language Design. In Proceedings of the Nineteenth Annual Hawaii International Conference on System Sciences, Volume II. IEEE, 106{116. [7] Garlan, D., Krueger, C. W., and Lerner, B. Staudt. 1994. TransformGen: Automating the Maintenance of Structure-Oriented Environments. ACM TOPLAS 16, 3 (May), 727{774. [8] Gray, R. W., Heuring, V. P., Levi, S. P., Sloane, A. M., and Waite, W. M. 1992. Eli: A Complete Compiler Construction System. Communications of the ACM 35, 2 (Feb.), 121{131. [9] Hedin, Gorel. 1999. Reference Attributed Grammars. In Second Workshop of Attribute Grammars and their Applications, WAGA'99. INRIA rocquencourt, 153{172. [10] Jarnvall, E., Koskimies, K., and Niittymaki, M. 1995. Object-Oriented Language Engineering with TaLE. Object-Oriented Systems 2, 2, 77{98. [11] Johnson, S.C. 1979. Yacc: Yet Another Compiler Compiler. Unix Programmer's Manual, 7 edition. Bell Telephone Laboratories. [12] Klint, P. 1993. A Meta-Environment for Generating Programming Environments. ACM Transactions on Software Engineering and Methodology 2, 2 (Apr.), 176{201. [13] Madsen, O. L., Mo ller-Pedersen, B., and Nygaard, K. 1993. ObjectOriented Programming in the BETA Programming Language. Addison-Wesley. [14] Magnusson, B., Asklund, U., and Mino r, S. 1993. Fine-Grained Revision Control for Collaborative Software Development. In First ACM SIGSOFT Symposium on the Foundations of Software Engineering (FSE-1). SIGSOFT'93. [15] Magnusson, B., Hedin, G., and Mino r, S. 1990. An overview of the Mjlner/Orm environment. In Proceedings of the 2nd International Conference TOOLS (Technology of Object-Oriented Languages and Systems). Paris, 635{ 646. [16] Mino r, S. 1990. On Structure-Oriented Editing. PhD thesis, Department of Computer Science, Lund University, Sweden. [17] Mino r, S. and Magnusson, B. 1996. Using Mjlner/Orm as a Structure-Based Meta Environment. In Structure-Based Editors and Environments, Neal, L. and Swillus, G., Editors. Academic Press. [18] Nilsson, K. 1996. Industrial Robot Programming. PhD thesis, Department of Automatic Control, Lund University, Sweden. [19] Nilsson, K., Blomdell, A., and Laurin, O. 1998. Open Embedded Control. Real-Time Systems { The International Journal of Time Critical Computing 14, 3 (May), 325{343. [20] Nrmark, K. 1987. Transformations and Abstract Presentations in a Language Development Environment. PhD thesis, Computer Science Department, Aarhus University, Denmark.

INTERACTIVE LANGUAGE DEVELOPMENT

55

[21] Reps, T. and Teitelbaum, T. 1989. The Synthesizer Generator. A System for Constructing Language-Based Editors. Texts and Monographs in Computer Science. Springer-Verlag. [22] SIS. 1987. Data Processing { Programming languages { SIMULA. Number SS 63 61 14 (Swedish Standard), ISBN 91-7162-234-9. SIS Standardiseringsgrupp, Stockholm, Sweden. [23] Vogt, H. H., Swierstra, S. D., and Kuiper, M. F. 1989. Higher-Order Attribute Grammars. In Proceedings of the ACM SIGPLAN'89 Conference on Programming Language Design and Implementation, Number 24(7). ACM Sigplan Notices. [24] Winograd, T. A. 1987. Muir: A Tool for Language Design. Tech. Report STAN-CS-87-1159, Department of Computer Science, Stanford University.