Each property mentioned in the production rules must be previously declared. A declaration section looks as follows:

section property_name
%description=('group' => text, ...);
$type="type";
$weight="x.y";
$temporary=value;
$synchronize{primary_property}=subroutine reference;
optional subroutines

The body of the section is evaluated as one piece of perl code, so all valid perl constructs can be used therein. The only exception is that it may not contain empty lines, since they would break the body into several sections.

%description
This list is not used by polymake itself, but is included into the documentation.
$type
Has currently a descriptive meaning too. It should contain a name of some basic type or a construction thereof (e.g. "list of cardinals").
However, one important type is distinguished by polymake: pseudo specifies a pseudo-target.
$weight
Specifies a penalty to be added to the rule chain weight if this property appears in the output list of at least one scheduled rule. How many times it appears in the whole chain does not matter, the weight is not multiplied. The weight format is the same as for the production rules.
Default is zero weight.
Currently only pseudo-target sections introduced to distinguish between competing rules (such as convex hull computation, geometry visualization, etc.) have assigned non-zero weights. They are the means of setting preferences for these rules.
$temporary
A non-zero value tells that the property is non-persistent. Default is zero.

Synchronization between properties

Properties of a polyhedron are considered mutually consistent as long as they are created new by the rules. As explained in the discussion about production rules, each property is created once, and never changes afterwards, even if several rules were executed later, which also could create it. There is an exception, however, caused by explicit usage of pseudo-targets. If a rule the psedo-target is assigned to is allowed to rewrite a property, which was earlier used to compute other properties, there can arise an inconsistence between them, if there can be more than one valid data representation of the rewritten property.

The most popular examples are VERTICES and FACETS: various convex hull computation algorithms may generate them in different order. But other properties, such as VERTICES_IN_FACETS, GRAPH, and so on, become invalid if the order of vertices or facets changes.

Such properties, being sensitive to a particular representation of another (primary) property, are called dependent. In the previous polymake versions, dependent properties were simply deleted as soon as the primary property was rewritten, and had to be created again when needed. Now this behavior is considered wasteful, so a new synchronization mechanism has been introduced, which comprises a couple of special subroutines defined within the declarations of concerned properties.

To express the dependence of a property on another one, a synchronization subroutine must be defined and a reference to it stored in %synchronize hash table under the key equal to the name of the primary property. The primary property should in turn define a sub diff: comparison subroutine for two representations of the property. The calling convention for these subroutines is as follows:

sub diff;
It gets two array references, the first pointing to the old version of a property and the second to the rewritten one. It should calculate the difference between them and return it in a scalar context. What this difference exactly is, is entirely up to the author of the property. E.g. for VERTICES it could be a permutation of row indices.
If the comparison subroutine detects that the two representations are incomparable, it should die with an appropriate message. In this case the synchronization becomes impossible, and all dependent properties will be deleted.
$synchronize{primary_property}=sub { ... }
It gets two arguments too. The first is an array reference pointing to the current value of the dependent property. The second is the return value of the comparison subroutine of the primary property. This subroutine should update (recompute, rearrange, whatsoever) the property and return its new value as an array reference.
It may also die, in which case the synchronization will be considered failed and the dependend property deleted.

Other optional subroutines

sub accept;
This subroutine is called each time polymake is going to create or rewrite the property, whether it reads it from the file, receives it from a client program, or obtains it from a production rule. The purpose of this subroutine can be a validity check or conversion to some well-defined canonical representation of the property.
The subroutine gets a single parameter: an array reference pointing to the data lines. It must return an array reference, too (possibly the same as input).
If this routine detects some errors in the data which it considers to be fatal, it may die with an appropriate diagnostic message.