Conceptual programming means having programmers work directly with their models of how their .... notation that allows labeled control flow ares to over-.
A Conceptual
Programming Steven
Environment'f
P. Reiss
Department of Computer Science Brown University Providence~ RI 02912 August,
1986
ABSTRACT Conceptual programming means having programmers work directly with their models of how their system is put together. It means providing them with the means for designing, coding and maintaining systems on a computer using the pictures and text they normally use on paper. An environment for conceptual programming requires flexibility to support a wide range of languages and graphics to support languages based on pictures. The GARDEN system is a prototype conceptual programming environment t h a t uses an object-oriented framework to meet these requirements.
1. I n t r o d u c t i o n pulated. The total conceptual modei is the union of the s e p a r a t e languages.
One approach to automating the software development process is to allow programmers to work directly on the computer with their ideas of how a system should operate. Programmers should be able to design, code, debug and maintain their system using their own conceptual models. A conceptual programming environment is one t h a t allows the programmers to define and use their own concepts consistently throughout the software life-cycle.
Programmers work with a variety of conceptual languages in building the conceptual model of a system. Often they use some s t a n d a r d language t h a t fits both the system and their way of thinking. Here they mold their system to fit the framework imposed by the language. For example, when designing a dataoriented system programmers might use a data-flow design language t h a t they are familiar with, and build their model of how the system will operate with the corresponding notation. At other times, programmers modify a s t a n d a r d language slightly to fit the exact problem they are working on. They design their system using their modified language after having noted the differences between it and the s t a n d a r d one. For example, a data-flow design scheme might be modified to allow synchronization between actions to be specified explicitly. In more complex situations, the programmers might develop their own language to describe how some aspect of the system should work. Here they would first define this language and then would design the system using it, possibly modifying the definition of both the system and the languages the design progressed.
1.1. C o n c e p t u a l P r o g r a m m i n g People designing systems tend to form conceptual models of how their systems work. These conceptual models are built out of languages, some textual, some relational, some visual. These languages each express a subset of the relationships and computations t h a t comprise the system. Each language is restricted to a certain class of objects t h a t can be described or mani"~ This research was suppgrted in part by the Office of Naval Research and ~,he Defense Advanced Research Projects Agency under contract N00014-83-K-0146 and ARPA Order No. 4786, by NSF Grant SER80-04974, by a contract with International Business Machines, by • grant l:rom the AT&T Foundation, and by a grant from the Digital Equipment Corporation. Partial equipment support was provided by Apollo Computer, Inc.
Permission to copy without fee all or part of this material is granted provided that the copies are not made or distributed for direct commercial advantage, the ACM copyright notice and the title of the publication and its date appear, and notice is given that copying is by permission of the Association for Computing Machinery. To copy otherwise, or to republish, requires a fee and/or specific permission.
In today's programming environments, this design process is typically done off-llne. The programmers develop their designs on paper, blackboards, and nap-
225 © 1987 ACM 0270-5257/87/0300/0225500.75
Reviewed and recommended by:
Patricia Obemdorf and Leon Osterweil
kins using appropriate pictures and pseudo-code. Eventually, when they understand the system well enough, they code it up in a programming language that the computer understands. Then they do the debugging and maintenance of the system using this language. At the same time, theiR" understanding of the system is in terms of their original design, so they will be continually mapping between the programming language and their conceptual model during the debugging and maintenance phases. Moreover, the original design documentation is rarely updated to show any changes that have made.
S A V E + M O R E M O N E Y
the program should return the solution: A
V
E
M
0
R
N
Y
9
3
7
6
1
O
8
4
2
The design of the solution to this problem is first specified with a graphical data-flow notation introduced in the text. This notation provides two basic types of objects, actions and data, with links going from data to actions showing use and from actions to data showing assignments. Data objects can be either inputs, outputs or internal data. Actions can be either directly specified, or can be modules that ar, ~pecified using other data-flow diagrams. The data-flow design for Secret Sums is shown in figure 1.
There have been several systems that provide automated design languages. These typically take a standard design method such as SREM, 1 SADT, 2 data-flow or finite-state automata 3,4 and provide the tools that allow programmers to enter their designs directly in the computer. These systems have two principal drawbacks. First, they provide only a single, rigid language. This forces the programmers to map their conceptual models into that provided by the system. Secondly, these systems only provide a design language. The actual coding of the system is separate and not related to the automated design except through the programmer's brains.
A conceptual programming environment would support this initial design directly using this data-flow notation. If the data-flow notation is a s t a n d a r d one that had been previously defined, the programmer would draw his data-fiow diagram using a graphical editor. This editor would allow the programmer to conveniently define and a n n o t a t e new actions and data, to cut and paste, and to generally manipulate a rough design into one that looks and feels correct.
A few experimental systems have been developed to provide executable specifications.5,6 These provide a more formalized design language that has an underlying semantics and can be executed. In these systems, it, is possible for a prototype implementation of the system to be built eompletely in terms of the design. This is a definite improvement, but still suffers from the same problems. These still only provide a single design language and are thus not natural foR" a wide range of systems. Secondly, they are typically systems for prototyping and designing and assume that the actual system implementation will be done in a separated environment.
The second step in the design is to break the overall problera into modules. This could be done in the initial pass by creating appropriate modules. In a conceptual programming environment, it could also be done using the graphical editor to eut and paste portions of a single design into their modular components and to replace them with an appropriate module. The third step in the design is to specify the control flow between the actions. The original data-flow notation did not provide a means for specifying control flow. This would then be done by defining an extended notation that allows labeled control flow ares to overlay the data-flow diagram. Using this new design language and his original design, the programmer would specify the flow of control among the different actions.
A conceptual programming system goes beyond these. It allows the programmer to design using his own system model. It allows this design to be the program and thus to be exeeuted directly. It would offer the ability to define new design languages, and to intermix different languages. It would offer facilities both for prototyping and for turning a prototype into a practical system.
1.2.
S
The final step in the design is to provide implementations of the actions in the final design diagrams. Most of the actions are simple and code fragments can be easily written in a textual language. The task of seleetlng the next legal solution is more complex. In designing this, the programmer might resort to drawing a flowehart to represent the complex task of generating all permutations. This should again be done on the machine using the same or a similar graphical editor.
An Example
As an illustration of conceptual programming, we consider the Secret Sums problem that is used extensively as an example in Gilbert's book Software Design and Development. 7 This is the problem of finding an appropriate substitution of digits for letters in an addition problem, i.e. for the input problem:
226
The result of this design process would be a completely specified solution to the Secret Sums problem. A coneeptual programming environment would insure that the different notations were executable, both in their partially specified form with user intervention, and in their final form. Thus, the design that was done here would be a executable program.
1.3.2. G r a p h i c s Many of the languages used for designing programs and systems are inherently graphical. People often think using pictures. The concepts of a system that programmers have will often be graphical. Forcing them to work with a corresponding textual notation places a new mapping between their concepts and the computer language. To allow the programmer to work directly with his concepts, the environment must allow him to work with the pictures that represent these concepts. The environment must be built on a framework that allows the manipulation of pictures as well as text. It must provide graphical editors as well as textual editors. It must allow graphical documentation as well as textual documentation. It must produce graphical listings as well as textual listings. The environment must allow pictures to be used as a primary representation throughout the life-cycle of software development.
The programmer can then test and debug his design using his original graphical notations. If he has to make corrections to get the program to work, he makes the changes in the design. If the program is to later be extended to handle other similar problems such as subtraction, the changes would be done as modifications to the original design. Finally, if the programmer has to explain his solution, the design diagrams are available and are accurate as documentation.
1.3. R e q u i r e m e n t s for ming
Conceptual Program-
Just as pictures should be a valid syntax for programs in the environment, pictures should be used as a representation for data. Much of the concepts occurring in programming involve complex data struetm-es that are typically understood graphically. The environment should allow programmers to input, output, view and edit their data structures graphically.
This example highlights some of the important requirements t h a t a conceptual programming environment must satisfy. There are two principal requirements: consistent support for multiple languages and support for graphical languages.
1.3.1. Multiple Languages A conceptual programming system must allow the programmer to use a wide variety of different concepts. Each of these concepts must be available as its own programming language. The programmer should be able to draw data-flow diagrams or flowcharts or finite-state a u t o m a t a or communicating processes or even write Pascal-like code. These languages must be able t o coexist in a single framework so that different conceptualizations can be used in the design of different portions of the system. This allows the programmer to use the concept that is most appropriate to the problem at each instance.
2. GARDEN The GARDEN project at Brown University is an attempt to provide a conceptual programming envh-onment. GARDEN provides a framework that meets the requirements for conceptual progrannning. This framework is being tested in a prototype implementation of a programming environment, the GARDEN system, that is designed to support a variety of different programming metaphors. GARDEN is being developed as a vehicle for experimenting with conceptual programming. Our first objective with the prototype environment is to show that conceptual programming is possible by providing an environment that supports it and by having people use this environment to develop systems. A secondary objective is to test if conceptual programming can be practical. To this end, the GARDEN system is a programming environment designed to support moderatesized systems built by teams of programmers. A third objective is to determine a viable set of initial conceptual views. A set of five to ten different conceptual languages should be enough for most programmers most of the time.
The environment should provide a rich set of initial languages. These should include s t a n d a r d implementations of accepted design techniques for both large and small systems. This will allow many projects to be undertaken with a minimum of extra effort on the programmer's part. The environment should also allow the programmer to develop new languages to fit new conceptualizations. These may be modifications of existing languages or completely new ones. Thus the system must allow the definition of both the syntax and the semantics of these languages. The syntax is defines how the language looks and how the programmer can interact with it through the editors. The semantics defines what it means to evaluate the language. Defining an appropriate semantics for each language insures that the resultant designs are executable.
The GARDEN system demonstrates that it is possible to meet the requirements for conceptual programming. GARDEN is based on a generalized object-oriented programming model. Objects are used to provide control abstractions as well as data abstractions. This provides the capabilities for handling multiple
227
languages and for easily defining new languages. Objects are also used as the basis for a graphical display and editing system t h a t allows pictures to be used as a primary interfaee to programs and d a t a .
2.2. Support for m u l t i p l e l a n g u a g e s Defining a new conceptual language in GARDEN involves three basle steps: developing the type structure, defining the syntax of the language, and defining the semantics of the language.
2.1. An object-oriented f r a m e w o r k
The first step is to define a set of types to describe program objects in the new language. This requires t h a t the language designer understand and characterize the components of the language. A type should be created for each component. The type should have fields to contain both the structural information needed to describe the corresponding program structure and any state information needed for evaluating this object. The underlying inheritance mechanisms can be used for defining related types such as different kinds of statements.
Objects provide a n a t u r a l framework for conceptual programming. Object-oriented programming has been shown to be a viable approach to software engineering in systems such as Smalltalk. s It provides convenient mechanisms for defining d a t a abstractions and defining new d a t a types t h a t are minor modifications of old ones through inheritance. It uses a message-passing primitive t h a t allows new types to be easily inserted in old contexts. GARDEN takes this a p p r o a c h a step further and allows objects to represent programs. 9 This is convenient for defining control a b s t r a c t i o n s and hence different conceptual languages. It also provides a common framework for uniting these languages.
The type definitions for the augmented data-flow design language used for defining the Secret Sums solution in our example are shown in figure 2. The notation used here is that provided by G A R D E N for type definition. All the types are record types with definitions consisting of their type name followed by a list of fields within braces. The fields contain an optional name, a separator character, and then the field type. A colon (:) separator character denotes a n o r m M data field, i.e. an instance variable of the type. A star (*) separator denotes a super type of this type. The field types are either type names or a number-sign (#) followed by a type name denoting a sequence of objects of the type.
Objects are a natural language for describing graphical languages. The pictures t h a t represent d a t a structures or programming abstractions are structured. They are typically represented as hierarchical collections of objects. Each collection of objects is strongly related to the underlying set of objects t h a t would be used in GARDEN to represent a program or the d a t a . GARDEN permits a mapping to be defined from the GARDEN objects to an appropriate s t r u c t u r e d picture. The inverse mapping, from the picture to the underlying objects, can also be defined for editing. GARDEN differs from s t a n d a r d object-oriented programming environments by using objects to represent programs as well as data. S t a n d a r d object-oriented programming environments provide a s e p a r a t e programming language for manipulating objects or for defining the meaning of sending a message to an object. GARDEN evaluates objects directly. The evaluation strategy for an object depends on the type or class of the object and on the object itself. This strategy is definable within GARDEN. This allows an algebraic programming languages to be defined using objects corresponding to the different statements; data-flow languages to be defined with objects t h a t do data-flow when evaluated; or a u t o m a t a to be defined using objects t h a t simulate the actions of an automaton.
A program in this language consists of a package t h a t is a special instance of a module. A module consists of sets of input ports, output ports, nested modules, actions and d a t a blocks as well as arcs linking d a t a and actions and arcs specifying control flow. Each d a t a node represents a name object, either local to the module or global. D a t a nodes t h a t are imported or exported are named explicitly. Each action consists of an object to evaluate as its action and a set of action ports for different control flow possibilities. The super types Block, ControlLoc, Port, and A r c identify objects t h a t can be used as components of a module, targets for a control are, sources for a control arc, and arcs respectively. The second step in defining a conceptual language in GARDEN is to define the syntax of the language. F o r textual input, GARDEN provides two interchangeable notations. The first is a LISP-like notation where an object is defined by its type and its fields in parenthesis. For a type " D E M O { fieldl : Integer, field2 :String}", the expression (DEMO i "ABC") builds an object of type D E M O with fieldl containing i and field2 containing the string "ABC". The alternative notation allows the fields to be named. The expression {DEMO field2 = "ABC" f i e l d l = 1} would build a simi-
Since objects represent both programs and d a t a , GARDEN can provide a common framework for graphical viewing and editing. This framework is based on the type or class of the object. Mappings are defined based on the object type t h a t translate the object into a corresponding text string or picture. Different mappings can be defined for different situations. Related mappings can be defined to map editing of the result a n t views into changes in the underlying objects.
228
lar object. As an alternative to textual input, GARDEN allows defining objects interactively using a sequence of dialogue boxes. The language designer can control this graphical syntax by defining the fields t h a t should be requested from the user and by defining appropriate routines to set up the resultant object.
evaluate a action port. Evaluating such a port c a u s e s the evaluation of the block it is linked to through a control arc. This block can be another action of the same module, can be an input module port for a nested module, or can be an output module port for the current module. Evaluating a module port is similar to evaluating a action port except t h a t arguments are passed along.
For textual output GARDEN normally displays all the fields of each type. The language designer can identify fields t h a t should be omitted from this display, either all the time or when the object is being displayed as a component of another object. It is also possible to define another object to be displayed in place of this object or to write a separate display routine for the object.
This example-shows t h a t defining a new conceptual language is a simple task. Most languages can be completely defined in one or two days of work. In addition to the design language, we have defined an algorithmic language, several data-flow languages, a flowchart language, a finite-state a u t o m a t a language, and a communicating processes language, l° None of these has required more t h a n ten pages of GARDEN code for the complete definition.
In addition, a variety of graphical syntaxes can be defined. This is done by defining mappings for each of the types t h a t compose the language. Picture mappings for each type take an object of the type and yield the corresponding graphical structure. Editing mappings can be provided to translate user manipulations of the graphics into changes of the underlying d a t a structures. These mappings are described more fully in the next section.
2.3. S u p p o r t f o r g r a p h i c s GARDEN is useful for conceptual programming because the structured pictures associated with programs are easy to produce. This is done with templates t h a t illustrate how to draw the underlying objects based on their type. These facilities are provided by the CELO layout package and its associated editors, A P P L E and PEAR. 11
The third step in defining a .conceptual language is to define its semantics. The language developer must describe how the new language evaluates by describing how to evaluate an object built from the newly defined types. This is done by associating an evaluation function with the types. Sometimes an evaluation function is only defined for the top-level type, for example an automaton. In other cases, it is convenient to define the evaluation of an object of this type using the evaluation of its component objects as in a flowchart being defined as the appropriately ordered evaluation of its boxes. Here it is necessary to define the semantics for the component types.
GELO is meant to be a flexible and powerful interface for drawing pictures of d a t a structures, or, in GARDEN, structures representing programs and data. It provides a simple interface for designing the graphical representation for the structure. It provides facilities to layout arbitrarily complex structures without the need to program the layouts. The layouts drawn by GELO are based on a hierarchy of graphical objects t h a t are loosely related to the various components of the original d a t a structure. Currently three different flavors of objects are provided, a basic drawing block, a block t h a t supports tiled layout, and a block t h a t supports graph-based layout. Basic objects are using for displaying simple user d a t a , fields of more complex user d a t a , and constunts such as the name of the d a t a type. Tiled objects are used for displaying fixed composites and recursive structures. They consist of a rectangle split into a tiled regions, each of which contains another GELO object. A typical use of a tiling is to display a record structure as a set of fields. Layout objects are used for displaying more complex or variable structures. They consist of a rectangular region into which are placed both nodes and arcs. GELO uses heuristics to a u t o m a t i c a l l y layout tt, e resulting graph in a useful manner.
The semantic definitions for an object-defined language are generally simple. The data-flow design language semantics are given in figure 3. The notation used here is a Lisp-like notation provided by GARDEN for defining objects. Braces denote blocks with their own set of local variables. A backquote ( ' ) indicates a field name. The strategy used in this example is straightforward. A P a c k a g e object evaluates by first evaluating its arguments and binding them to the associated parameters. Then it evaluates the appropriate s t a r t action within the package passing it the given arguments. An A c t i o n object evaluates by first constructing a p a r a m e t e r list based on the d a t a arcs connected to the action, then evaluating its associated code with this p a r a m e t e r list. The arguments are constructed from the d a t a objects by sending each a P o r t V a l u e message. The associated code can be any type of object, i.e. another data-flow language, a textual program, a flowchart, etc. Within an action, it is possible to
Two editors are provided with GELO: A P P L E and PEAR. A P P L E is an editor for defining how a type is to be displayed. It allows the user to show by example how the type should be converted into GELO objects.
229
Each GARDEN type is converted into a top-level GELO object. Simple types are converted into data objects. Here the properties of the data object are specified. The text to be displayed can be a string, the value of the object itself, or the vMue of some field of the object. More complex types can be displayed as tiled objects. Here the user draws the tiling and defines what goes into each tiled rectangle. This can be a reeursive display of some field, a data object, or a layout object. Layout objects can be specified as the target of an object mapping or as a component of a tiling. In either case, the user can specify the objects that should be contained in the layout, and whether any of these should be portals placed at a fixed position on the edge.
a module and for connecting two components of a module with an arc. For inserting an object, it asks the user what type of object to add and then adds it to the appropriate field of the module. For connecting two component, it determines the propel" type of are to use and then adds this to the proper fields. The definitions for the data-flow design language allow the user to graphically enter and work with programs. The Secret Sums design is displayed graphically in figure 5. The picture at the top left shows the toplevel module. The half-ellipses are exported data; the simple box is the main loop action; the box with a space on top is the initial action; and the boxes with double sides are nested modules. The light ares represent data flow. The bold arcs represent control flow. Below the top-level module is the input module. The triangle on the left is the input port activated when the module is invoked from the top-level. The half-ellipses here represent imported data. On the right are similar representations of the symbol module, the compute module and the next module.
Samples of the APPLE graphical definitions for the types of the data-flow design language are shown in figure 4 using the type editor of GARDEN. The two pictures on the upper left show two different ways of displaying a module, the first when it is nested in another module and the second when it is the top-level display. Both are tilings with the tikes containing strings, fields and, for the second, a layout object. The picture on the bottom left shows how to display an action as a box in a module. The picture on the upper right illustrates the display of a data Mock in a module. Beneath this is an example of a specification for an are. Finally, the bottom-right picture shows how to display an in-port for a module.
3. O p e n P r o b l e m s The GARDEN system is only now becoming stable enough to attempt to develop small-scale example systems using the concepts of graphical programming. Our experiences to date are limited, with a core of about five users. The bulk of the work so far has been on the development of new visual languages and on using these to develop illustrative examples. We hope to gain further experience over the next several months and to experiment seriously with the practicality of eoneeptual programming.
PEAR is a strueture editor for displaying and creating user data structures based on their GELO r)ictures. PEAR uses GELO to display a pieture of the user data structure. For each GELO object it saves the source as a reference to the user's data structure. It then allows the user to edit the picture in a logieal manner. The user ean change the values associated with GELO data objects. He ean create new user objects and store their values in the eomponent fields of tiled objeets or as nodes or ares of layout objects. He can cut and paste within the context of the picture.
The current implementation is a prototype that exhibits several weaknesses, primarily in the graphical interfaces that are provided. The graphical displays are easy to specify, but do not always produce an aesthetically appealing result. The main problem is the lack of good layout heuristics that do not require human interaetion. We are working on developing new heuristics and on allowing the programmer to help specify picture layouts. The graphical editor t h a t GARDEN provides is a structured picture editor when the structure reflects the underlying objects. This is a somewhat restrictive form. Ideally we would like the programmer to have the fl'eedom to just draw his program and have the eomputer understand it. To this end we a r e working on graphical parsing algorithms and on alternative editor designs.
PEAR translates the user's editing operations into a smaller set of basic operations on the underlying strueture. A set operation involves changing the contents of some object to a user-specified value. An i n s e r t operation involves adding a node to a layout. An inaert arc operation involves adding an arc to a layout. A r e m o v e operation involves removing an are or a node from a layout. GARDEN provides an interface to PEAR that further defines these mappings. Each is translated into a Smalltalk-style message that is sent to the object being changed. Default implementations are provided for this message for most types. The user can change these definitions or refine them for his own types as needed to specify appropriate editing semantics. For t h e data-flow design language, the language definition included special definitions for inserting an object into
The system also has problems as an complete environment. The system currently evaluates by interpreting objects. Since languages are defined using objects, the interpreter for a new language is also being interpreted. This results in a performance bottleneek. We currently provide a primitive eompiler that gives about ten-fold improvement in speed for known objeets. This is a first step, but additional research must be done on
230
compiling conceptual programs into an efficiently executable representation.
References 1.
2.
3.
4.
5.
6.
R. Balzer, D. Dyer, M. Fehling, and S. Saunders, "Specification-based computing environments," Proc. 8th VLDB Conf., pp. 273-279 (September 1982). 7. Philip Gilbert, Software Design and Development, SRA, Inc. (1983). 8. Adele Goldberg and Dave Robson, Smalltalk-80: The language and its implementation, AddisonWesley (1983). 9. Steven P. Reiss, "An object-oriented framework for graphical programming," SIGPLAN Notices gl(10) pp. 49-57 (October 1986). 10. St,even P. Reiss, Erie J. Golin, and Robert V. Rubin, "Prototyping visual languages with the GARDEN system," Proc. IEEE Syrup. on Visual Languages, (June 1986). 11. Steven P. Reiss and Joseph N. Pato, "Displaying program and data structures," Proc 20th Hawaii Intl Conf Symstem Sciences, (January 1987).
Mark Alford, "SREM at the age of eight: The distributed computing design system.," IEEE Computer 18(4) pp. 36-46 (April 1985). Douglas T. Ross, "Applications and extensions of SADT," IEEE Computer 18(4)pp. 25-35 (April 1985). David Hard, "Statecharts: A visual approach to complex systems," Dept. of Applied Mathematics, Weizmann Institute of Science (1984). Robert J. K. Jacob, "A state transition diagram language for visual programming," 1EEE Computer 18(8) pp. 51-59 (August 1985). Pamela Zave and William Sehell, "The PAISley software tools: An environment for executable specifications," Proe. GTE Workshop on Software Engineering Environments for Programming-in-. the-Large (June 1985).
/
Figure 1: Gilbert's Data flow solution for Secret Sums
231
(TYPE_DEFINE (TYPEDEFINE (TYPEDEFINE (TYPE_DEFINE
"Block{}") "ControlLoc{}") "Port{*Name,msg:?,do:ControlLoc,port:Integer,subport:Integer}") "Action{*Block,*ControlLoc,"&
"name:Name, descrlption:String, eval:?,"& TYPE_DEFINE TYPE_DEFINE TYPE_DEFINE TYPE_DEFINE TYPE_DEFINE TYPE_DEFINE 'TYPE_DEFINE TYPE_DEFINE TYPE_DEFINE TYPE_DEFINE TYPE_DEFINE TYPE_DEFINE TYPE_DEFINE TYPE_DEFINE
"dataports:#Arc,actionports:#ActionPort}") "StartAction{*Action}") "ActionPort{*Port,action:Action}") "DataBlock{*Block,description:String}") "Data{*DataBlock,name*Name}") "LocalData{*DataBlock,name*Local}") "Arc{id:String}")
"DataUse{*Arc, from:DataBlock,to:Action}") "DataMod{*Arc, from:DataBlock,to:Action}") "DataSet{*Arc, from:Action,to:DataBlock}") "Control{*Arc, from:Port,to:ControlLoc}") "ModulePort{*Block,*Port,*ControlLoc,module:Module}") "ModuleInPort{*ModulePort}") "ModuleOutPort{*ModulePort}")
"Module{*Block,name:Name,description:String,"&
"imports:#DataBlock, exports:#DataBlock,"& "inacts:#ModuleInPort,outacts:#ModuleOutPort,"& "blocks:#Block, data_arcs:#Arc,control_arcs:#Arc}") (TYPE DEFINE "Package{*Module,params:#Name,start:StartAction}")
Figure 2: Type definitions for data-flow design lunguage.
232
(DV PACKACE_EVAL {* (SETQ p (EVAL up)) (SETQ args (LISTLOOP args EVAL LIST_ADD_END)) (EVALOK_FRAME p) (BIND ARCS args ('params p)) (EVAL ('start p) args)
*} ) (DE ACTION_EVAL {* (SETQ args (LISTLOOP ('dataports act) '{* LAMBDA (QUOTE ('PortValue x)) LIST_ADD_END args)) (EVALUATE_LIST ('eval act) args)
*} ) (DE ARC_VALUE_IN (NAME_VALUE (" from a) ) ) (DE ARC_VALUE_INOUT ('from a)) (DE ARC_VALUE_OUT ('to a)) (TYPE_CONSTANT DataUse "PortValue" ARC VALUE_IN True) (TYPE_CONSTANT DataMod "PortValue" ARC VALUE_INOUT True) (TYPE_CONSTANT DataSet "PortValue" ARC_VALUE_OUT True) (DE PORT EVAL (COND (NULL ('msg p)) (EVAL ('do p) Null) ELSE (EVAL ('do p) (LIST_NEW ('msg p))))) (DE MOD_PORT_EVAL (COND (NULL ('msg p)) (EVAL ('do p) args) ELSE (EVAL ('do p) (LIST_NEW ('msg p)))))
Figure 3: Semantic Definitions for Data-flow Language.
233
u ......
e e e s name : Name d e s c r i p t i o n : Strin G Imports : SDotoBIock
"string" I~EI
