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. 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.

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 or by extracting the appropriate schematics, 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).

Important restrictions: when a wire icon is defined by code, this code should return a new copy at every call. When a wire icon is defined by a schematic, this schematic should not extract as a wire itself (unexpected behavior otherwise because the wire is not copied).

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. Within the parameter phase the evaluation order is: object p-expressions, object s-expressions, instance p-expressions, and finally instance s-expressions. The result phase consists in evaluating a rope found under the $CodeFor property or to fetch the schematic found under the $IconFor property.

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 cases are: declarations, affectations, properties (that end up on the resulting core), names, and loopholes.

It is recommended NOT to use variables which names start with &. Those variables have slightly different rules (e.g. they do not have to be declared). May be one day we will get rid of them?

Restriction: coreProps must only be set by Object satellite/expression, and coreInstProps must only be set by Instance satellite/expression. Non repetitive behavior will occur otherwise. For a very subtle reason, it took me 3 days to figure out this restriction.

Proposes several commands to change the way cells are extracted and to make them iconic. Refers to the on-line documentation in the menu itself.

The context variables on which the extraction of a cell depends can be set explicitly by the user. This allows to make extraction much faster, since equality of contexts can just be checked for the specified variables, and since much less objects will be extracted and much more will be shared. Nethertheless it is a dangerous feature, since no check is done when the list of parameters is explicitly set, or whenever the cell changes. The Parameter menu allows showing, setting and editing the list of parameters. A list of parameters just containing the pseudo-parameter "0" means no parameter at all.

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