## Anonymize names

This CIF to CIF transformation anonymizes the names of all named objects in the CIF specification.

Anonymization can be useful when the model is to be shared publicly, but contains confidential information. For instance, this can be useful when adding a confidential model to a bug report, when contributing it to model repositories, or when it is a part of a publication or thesis.

Only the names of named objects are anonymized. The resulting specification may still contain string literals, references to file names, etc, that are not anonymized by this transformation. It remains your own responsibility to decide whether or anonymizing names is sufficient to allow a model to be made public or not.

### Supported specifications

This transformation supports a subset of CIF specifications. The following restrictions apply:

- Automaton to string casts are not supported.

### Preprocessing

No preprocessing is currently performed by this CIF to CIF transformation.

### Implementation details

The new names of objects are based on a fixed prefix that depends on what kind of object it is, followed by a number. The following table indicates the prefixes that are used for the different kinds of objects:

Prefix | Kind of object
--- | ---
`alg` | Algebraic variable
`aparam` | Algebraic parameter of a component definition
`aut` | Automaton
`autdef` | Automaton definition
`const` | Constant
`cparam` | Component parameter of a component definition
`disc` | Discrete variable
`enum` | Enumeration
`eparam` | Event parameter of a component definition
`evt` | Event
`field` | Field of a tuple type
`fparam` | Parameter of a user-defined function
`func` | User-defined function
`fvar` | Variable in an internal user-defined function
`grp` | Group
`grpdef` | Group definition
`input` | Input variable
`inv` | State (exclusion) invariants and state/event exclusion invariants
`inst` | Component instantiation
`iparam` | Input parameter of a component definition
`lit` | Enumeration literal
`loc` | Location of an automaton
`lparam` | Location parameter of a component definition
`type` | Type declaration

For most kinds of objects, each unique object of that kind gets a unique number as postfix. For instance, consider a specification with algebraic variables and constants:

    group g:
      alg bool at = true;
      alg bool af = false;
      const bool ct = true;
      const bool cf = false;
    end

    alg bool at = true;
    alg bool af = false;
    const bool ct = true;
    const bool cf = false;

The result of anonymizing the names would be:

    group grp1:
      alg bool alg1 = true;
      alg bool alg2 = false;
      const bool const1 = true;
      const bool const2 = false;
    end

    alg bool alg3 = true;
    alg bool alg4 = false;
    const bool const3 = true;
    const bool const4 = false;

The four algrebraic variables each get a different number as postfix, as do the constants. This makes it easy to find a specific named object based on its name. But algebraic variables and constants are numbered independently.

For controllable and uncontrollable events, the new name is additionally prefixed with `c_` and `u_`, respectively. Events that are not controllable or uncontrollable don’t get an additional prefix.

Compatible enumerations have the same number of literals, and the same literal names in the same order. The new literal names for compatible enumerations will be identical, to ensure they remain compatible.

To ensure that compatible tuple types remain compatible, their field names are not numbered globally, but are instead based on their index within the tuple type. That is, for a tuple type `tuple(int nr; real weight)` the anonymized result is `tuple(int field1; real field2)`.

Objects without a name, such as nameless locations or nameless invariants, are not given a name.

### Renaming

Renaming is performed as explained in the previous section.

### Size considerations

The only change to the specification is that objects are renamed. The new names could be shorter or longer than the original names.

### Optimality

n/a

### Annotations

This transformation does not process or add any annotations. The names of annotations and annotation arguments are not anonymized. If the specification has a controller properties annotation, it is removed.