An expression is a rope that contains a CEDAR expression and is attached to one of the other four objects. The attachment can be made in several ways: as a property on the ChipNDale object, as a satellite on the object, as a property on the ChipNDale instance, or as a satellite on the instance. It is convenient to call expressions attached in these various ways object p-expressions, object s-expressions, instance p-expressions, and instance s-expressions, respectively. Object and instance p-expressions are invisible since they are kept as ChipNDale properties, but s-expressions are visible since they are kept as satellites. Each expression is further a parameter expression or a result expression.

The purpose of having these categories will become clear once the evaluation mechanism is described, but briefly here is what they are for. Object expressions typically supply default values for parameters and the resulting Core, while instance expressions override these defaults and supply any additional parameters. S-expressions are useful when a designer wants the information to be always visible, while p-expressions come in handy when visible information would clutter up a design.

A wire is a set of connected ChipNDale comment rectangles that represent a Core wire. Two rectangles are connected if a corner from one of them touches or lies inside the other, or if the rectangles have the same name. A rectangle is named by assigning the appropriate ROPE to the SISYPH variable name. Since naming is a frequent operation, simply using the wire's name in place of the expression is also accepted.

By default a rectangle extracts as an atomic wire. However, by using an expression that assigns to the SISYPH variable wire, a rectangle can be made to produce a wire with any desired structure.

A schematic is a ChipNDale cell that expresses the structure of some electrical circuit in terms of simpler circuits. It is drawn using icons, wires, expressions, and perhaps other schematics.

The public wire of a schematic is defined by its interface geometry. This geometry consists of rectangles that either touch the cell's interestRect directly or are connected to directly touching rectangles by geometry or name. The interface geometry also determines where electrical connections may be made when a schematic is used directly within another schematic.

A cell icon is a ChipNDale cell that serves as a pictorial shorthand for a circuit schematic. Its purpose is to provide a graphical abstraction mechanism that allows a complicated schematic to be drawn simply. The schematic corresponding to an cell icon may be real, in which case the icon points to the appropriate ChipNDale cell, or it may be non-existent, in which case it points directly to a procedure that returns the Core for the fictitious schematic. In either case the cellType for an cell icon is specified by an expression that assigns to the SISYPH variable cI. This scheme trivially allows a schematic to have more than one icon.

A cell icon normally contains pictorial geometry and interface geometry. Pictorial geometry is window dressing as far as extraction is concerned—its only purpose is to make the looks of the icon meaningful to the reader. This geometry is identified to the extractor by marking instances with the null extraction property. Instances not marked with this property are significant for extraction. Of the significant instances, those rectangles that touch the icon's interestRect (or are connected to such rectangles by geometry or name) constitute interface geometry, just as for a schematic. This geometry defines the icon's drawnPublic and determines where electrical connections may be made to the icon when it is used. Once the Core for the icon has been computed by evaluating the result expression, a check is made to verify that the drawnPublic conforms to the result's public. The result's public and the drawnPublic must match in the sense that every wire of the drawnPublic must be named and exactly one wire of the result's public must have the same short name. The drawnPublic may be structured, but only the top level wires are considered for the matching. The algorithm can be expressed as follows:

An wire icon is a ChipNDale cell that serves as a pictorial shorthand for a Core wire. The result for a wire icon is specified by assigning to the SISYPH variable wI.

A wire icon normally contains pictorial geometry and interface geometry. Pictorial geometry is window dressing as far as extraction is concerned—its only purpose is to make the looks of the icon meaningful to the reader. This geometry is identified to the extractor by marking instances with the null extraction property. Instances not marked with this property are significant for extraction. Of the significant instances, those rectangles that touch the icon's interestRect (or are connected to such rectangles by geometry or name) constitute interface geometry. This geometry defines the icon's drawnWire and determines where electrical connections may be made to the icon when it is used. Once the Core for the icon has been computed by evaluating the result expression, a check is made to verify that the drawnWires conforms to the resultWire. The algorithm for matching is the same as for cell icons, apart for the second rule that is just to emit a warning if the resultWire is unnamed and does not match a drawn wire, and apart that cells where there is only a single drawn wire are handled specially (so that that wire can be un-named).

The environment in which evaluation proceeds consists of a SISYPH Context and an Interpreter Context. The SISYPH Context is simply a symbol table of <name> <value> pairs where each pair defines a SISYPH variable of arbitrary CEDAR type. The Interpreter Context contains definitions of all global frames and interface records currently loaded in the CEDAR world. During evaluation, names are first looked up in the SISYPH context, and if not found there are looked up in the Interpreter Context. If a name does not exist in either context then an error is signalled.

SISYPH uses a number of variables to hold key values such as the name of the entity being extracted, the design in which it lies, and the result to be returned by the extraction (a complete list appears in Appendix A). Since these variables are kept in the SISYPH context, and all SISYPH variables may be assigned to via expressions appearing in a schematic, a user has explicit control over extraction. The user may also use expressions to define new SISYPH variables. These variables can then be assigned to and used either during the extraction of the instance to which the expressions are bound or during the extraction of nested instances.

To get the semantics of extraction to mimic the semantics of procedure call, SISYPH contexts are maintained in a stack. Before an instance is extracted, the SISYPH context for the instance's parent is first copied into a new context and then pushed onto the context stack after initializing certain local variables to NIL. This allows the new context to inherit values from the parent's context and at the same time isolates variables in the parent's context from any changes that may occur when expressions attached to the current instance are evaluated. When the extraction of the current instance is complete, the parent's context is restored.

The evaluation of expressions proceeds in the parameter phase and the result phase, performed in that order. Expressions that assign to the SISYPH variables wire, wI, or cI are evaluated in the result phase while all other expressions are evaluated in the parameter phase. Within each phase the evaluation order is: object p-expressions, object s-expressions, instance p-expressions, and finally instance s-expressions.

This order has the effect of giving the highest precedence to assignments done via instance s-expressions, a lower precedence to those done via instance p-expressions, lower still to those done via object s-expressions, and the lowest to those done via object p-expressions. This order is desirable for two reasons. First, it makes visible expressions take precedence over invisible ones, bringing us closer to "what you see is what you get". Second, it makes it possible to tailor the extraction of a particular instance of an icon, regardless of how the object says it is to be extracted.

Expressions have been embellished with a certain amount of syntactic sugar to make the specification of certain common cases palatable. The two cases are: names, and properties that are to end up on the resulting core.

An expression <expr> with no embedded "←" or ":" is assumed to be a name. It is shorthand for the complete expression:

An expression of the form <pname>: <pvalue> with no embedded "←" is assumed to specify a Core property with name <pname> and value <pvalue>. It is shorthand for the complete expression:

The <space>-O commands are: Make Icon, Make Invisible to Extractor, and Extract Selected Object.

The expression commands share the satellites Menu accessible via <space>-L. There are three commands each for satellites, instance expressions, and object expressions.