M3.1. Background

The eden interpreter was designed and first developed by Y W (Edward) Yung in 1987. It has been extensively used in prototyping since. It was originally designed to work in a UNIX/C environment and to support windowing and graphical tools running under X windows. The most recent version of the interpreter is tkeden, as first developed in 1995 by Y P (Simon) Yung, and subsequently greatly revised and improved by Ashley Ward to enhance its useability and maintainability and to incorporate extensions by P-H (Patrick) Sun, Ben Carter, and Chris Brown.

The eden interpreter was originally developed with the evaluation of definitive notations in mind. It provides a useful "hybrid" programming tool that allows definitive and procedural paradigms to be combined. (It is essential to link definitive systems with procedural mechanisms, since most UNIX utilities and hardware devices are programmed using a procedural style.)

Many sample eden models can be found in ~empublic/projects. This lecture gives only a brief introduction to eden: The EDEN Handbook, by Edward Yung, has more details.  There is also a Quick Guide to eden compiled by Ashley Ward under the help menu for the tkeden interpreter.

M3.2. Overview of basic eden characteristics

The eden syntactic conventions and data types are similar to those in C. The basic programming constructs are C-like: the for, while, if and switch. The main types for variables are float, integer, string and list. Lists can be recursive and need not be homogeneous in type. Comments are enclosed in /* .... */ parentheses.

The eden interpreter is a powerful programming tool that has to be used in a disciplined way for best results. Many eden programs can be built from three abstract programming features: definitions, functions and actions:

will return details of the defining formulae and dependency status of the variable v.   In particular, the query displays a line of the form

v~>[...]

The eden interpreter allows the values of formula variables in definitive scripts to be undefined. There can still be technical problems in executing and interpreting scripts that include partially defined values, however, since triggering in eden depends upon the values of trigger variables being defined. In this connection, it can be useful to use the boolean expression v==@ to test for undefinedness of the variable v.
 

M3.3. Illustrative examples of eden use

1. eden can be used to implement a definitive notation (cf YPY thesis)

A definitive script in eden does not have a direct visualisation as a donald or scout script does. To interpret a donald script in eden, it is necessary to associate display actions with variables. Despite this, translation of a donald script into eden simplifies the interpretation of donald greatly, as all the maintenance of definitive variables is done automatically.  The use of eden to evaluate definitive notations combines definitions, functions and actions in a characteristic manner.

By way of simple illustration, consider the donald fragment (cf [M4]):

%donald
point p,q
line l
l = [p,q]
p = {150, 250}
q = p * 2

After translation, the donald variables p, q and l have the internal representations _p, _q and _l respectively in eden.
These representations can be interrogated thus:

%eden
?_l;
_l is line(_p, _q); /* current value of _l is [L,[C,150,250],[C,300,500]] */
_l ~> [P_l, _]; /* _l last changed by input */

?_p;
_p is cart(150, 250); /* current value of _p is [C,150,250] */
_p ~> [P_p, _, _l, _q]; /* _p last changed by input */

These are examples of eden definitions that make use of the predefined functions, line() and cart().   The specifications of these functions can also be accessed in eden:

?cart;
func cart {
        return [CART, $1, $2];          /* [ CART, X, Y ] */
}

where CART is an eden variable whose literal value is 'C'.  This can be confirmed by displaying the current value of _p:

writeln(_p);
[C, 150, 250]

The actions that maintain the visual representations of the point p and the line l are called P_p and P_l respectively.  The specification of the action P_l can be obtained:

?_P_l;
proc P_l: _l, A_l, DoNaLD {
        plot_line(DoNaLD, &_l, &A_l);
}
P_l ~> []; /* P_l last changed by input */

Note that one of the triggers to this action is the attribute list for the line l, as represented by the value of the eden variable A_l.  The default value of A_l is the empty string, but its value can be established as a dependency through redefinition in eden:

A_l is (_q[2] <200) ? "color=red": "color=blue";

The colour of the line l will then depend upon the horizontal position of the point q.

2. The jugs.e program (see [jugsBeynon1988, jugsPavelin2002])

The jugs.e program is an eden program developed to demonstrate the potential of eden as a means of portable specification. The eden program is based on an educational program used in schools that allows children to derive a specified integral target quantity of water by filling, emptying and pouring between 2 jugs of integral capacity. In our approach, the relationships between the significant quantities that define the display (the capacity and content of the jugs, the availability of the menu options, the target and status of the simulation) are specified using eden definitions. Any non-standard operators used are define in eden. Actions in eden are first used to keep the display up-to-date when key parameters are changed, and subsequently to specify the responses to menu selection.

M3.4. Using eden

Where eden is being used in conjunction with donald and scout, the eden, scout and donald translators are normally accessed through tkeden. The tkeden environment has built-in features to support model development to be described later.  The cruise model illustrates many of the principal features of tkeden use, as discussed in the overview lecture.

It is sometimes convenient to use eden without visualisation, or in a pipeline. The interpreter ttyeden is suitable for such use. For pipeline use, a typical command line is:
 

cat filename.e -  |  ttyeden -n

The "-" is a UNIX feature, signifying that input will be taken from the standard input after filename.s has been read. The "-n" option for eden suppresses the eden prompt.

When using ttyeden, a common mode of eden program development involves editing a program in one window whilst executing eden in another. Extracts can then be tested by cutting-and-pasting from the editor window into the interpreter window. In the development process, it is often useful to be able to undo design actions. Scripts of definitions can easily be restored to their original form, simply by re-entering the original definitions. For this purpose, it's useful to keep old fragments of scripts, at least temporarily, by commenting them out rather than deleting them from the edited file. Another useful feature of eden is the include facility, whereby

The tkeden interpreter allows the kind of editing that has been described above to be performed in a specially designed environment. Eden definitions are entered through an input window. The eden script is automatically stored, and can be accessed and searched through opening an eden definition window. Within this window, a find command can be used to search for the occurrence of particular eden identifiers. Though the tkeden interpreter keeps the computational state up-to-date, the displayed definitions are only updated to take account of their latest revisions when the rebuild option is selected. This makes it convenient to carry out experimental redefinition that can subsequently be undone through cut-and-paste from the eden definition window to the input window. The tkeden environment incorporates commands for storing current definitions, displaying definitions of particular varieties (such as those entered initially, and those that are always present in the eden system), and for retrieving files of definitions. There is also a command history by means of which user input and, where appropriate, system error messages are recorded. Note that the response to writeln(v) and ?v requests is displayed in the window in which the tkeden interpreter is invoked. These general features of tkeden that apply to eden extend to scout and donald use. It should be borne in mind that in displaying the current definitions of variables, tkeden annotates definitions according to their origin, e.g. distinguishing between a redefinition input by the user, and one generated by a triggered action.

M3.5. Miscellaneous additional issues for eden

The eden interpreter is best suited to representing scripts of fixed length, where the variables are persistent. This is appropriate when a designer is incrementally constructing a large model by refining and extending a set of definitions. It isn't so appropriate for dealing with activities where the set of observations changes dynamically as transient processes / agents are created and destroyed. Some degree of dynamism can be achieved in scripts by using eden features that directly generate or manipulate scripts. These include:

- execute()
 
    cf specification of the integrators in the VCCS

- todo() (schedule for execution)
 
    cf clock in VCCS

- forget()

    discard a variable, subject to there being no variable dependent upon it

- `<string>`

    (turn string into variable name) cf digital watch

- &<var>

    (turn a variable name into an address)

- *<address>

    (return the value stored at an address)

Common points of concern

Experience has shown that eden is an exceptionally powerful programming tool. It is clear that the introduction of definitive scripts as an additional programming device in a procedural environment simplifies many programming tasks. But though eden can be a most effective tool, it can also be easily abused, and programming principles that might underlie eden are hard to identify. To understand what definitive scripts are good for, we need to be able to relate programming in eden to other paradigms, to seek a satisfactory abstract account of what eden programming entails and to identify what distinguishes between good and bad eden programs. These themes have motivated much research into alternative frameworks for developing definitive models, such as that supplied by the Abstract Definitive Machine (to be introduced later in the module).

As a general rule, good use of eden leads to models that are easily revised and extended. In a conventional programming language, it may be hard to make a significant distinction between alternative ways in which constructs are used to achieve a result. In contrast, the particular way in which eden constructs are used is very significant, and points to underlying principles for model and program development. This emphasis accords well with the idea that typical use of eden is associated with open-ended system development rather than the specification of precisely circumscribed behaviours. It is also reflected in the characteristics of the tkeden environment, where script management is a central concern.

The distinction between using actions and definitions is one illustration of why fastidious use of eden constructs is important. The fact that the definition "v is f(a,b,c)" can be interpreted as an assignment "v=f(a,b,c)" that is triggered by a, b and c might suggest that essentially eden is a rule-based paradigm. This is a misleading impression, since a major virtue of eden programming is that the use of definitions rather than actions imposes a discipline on execution of actions. For instance:

References

Y W Yung The EDEN Handbook