Improvements to the Cadence IDE

As a research prototype, Cadence is at present always in a state of development! Since last week, there have been some significant improvements to the interface that simplify the exploration of models:

• The Messages, History and Modules tabs have been separated from the DASM input window, and these aspects of the interface now appear to the right of the browser panel rather than below it.

• You can now right click on a node in the browser to bring up the definition of the corresponding observables in the DASM input window. The current value is also displayed in an auxiliary textbox. For 'is' and ':=' definitions both the definition and the current value are displayed. For an '=' definition, there is only a current value to be displayed.

• The environment in the DASM input window created by right clicking on a node as described can also be used to redefine the corresponding observable. For an 'is' definition, only the definition part can be edited, as this determines the current value. For an '=' definition, only the current value can be set. For an '=' definition, you can edit either the definition part, or set the current value. There is a drop down menu that allows you to switch between these different kinds of definition. To redefine an observable after changing its definition or value, you use the 'Save' button on the left, just above the input window.

• When you show the history you can double-click on any previous command to bring this into the Input Window. This is a most convenient way to modify the defnitions of observables experimentally.

---

Some additional points about Lab 2

---

The definitions that you cut-and-paste from the Lab 2 labsheet into the DASM input illustrate some key - and also some tricky - features of Cadence.

As an example of defining a context, see the definition:

@screen = (.widgets root children);

Note that here the . on the RHS refers to the global root context: the '.widgets root children' context is in effect the desktop area for the WGD environment. Note also that the round brackets () are very important - if they are omitted, you will find that the above definition has the same effect as

@screen = (.);

---

Note the very unusual precedence of operators in the arithmetic expression on the RHS of the definition:

@lift floor_pix is { 400 - (.floor * 100) + (.offsety) };

and in the boolean expression in

@lift atfloor is {
    .y < (.floor_pix + 2) and (.y > (.floor_pix -2))
};

The association of operators is strictly left-to-right. Note also that putting in extra brackets to make the expression more human readable may lead to parse errors!

---

Note the use of ".." in the body of the if-statement in this definition (but not in the condition):

@lift y := {
    if (.atfloor not) {
        ..y + (..direction * (..speed) * (@root itime))
    } else {
        ..y
    }
};

This has to do with the way in which the if-statement is a short-hand ('syntactic sugar') for a more explicit definition in which there is an if 'object' containing 'true' and 'false' components.

---

Note the way in which boolean expressions can be formulated using 'and', 'or' and 'not'. Note that 'not' should be used as a postfix operator. The use of these boolean operators is illustrated in the definitions of @lift atfloor and @lift y above.

---