## Alphabet

The lesson on synchronizing events described how events that are used in multiple automata exhibit synchronizing behavior. That is, if the event is used in multiple automata, they must all enable that event in order for a transition to be possible. If one of them can not perform the event, the event is disabled, and none of the automata can perform a transition for that event.

Whether an automaton participates in the synchronization for a certain event, is determined by its alphabet. The alphabet of an automaton is the collection of events over which it synchronizes.

### Default and implicit alphabets

By default, the alphabet of an automaton implicitly contains all the events that occur on the edges of the automaton. For instance, consider the following CIF specification (the producer/consumer example from the lesson on synchronizing events):

    automaton producer:
      event produce, provide;

      location producing:
        initial;
        edge produce goto idle;

      location idle:
        edge provide goto producing;
    end

    automaton consumer:
      event consume;

      location idle:
        initial;
        edge producer.provide goto consuming;

      location consuming:
        edge consume goto idle;
    end

The alphabet of the `producer` automaton contains the events `produce` and `provide`, as both occur on edges of that automaton. The alphabet of the `consumer` automaton contains the events `producer.produce` and `consume`.

### Explicit alphabet

It is possible to explicitly specify the alphabet of an automaton, as follows:

    event provide;

    automaton producer:
      event produce;

      alphabet produce, provide; // Alphabet explicitly specified.

      location producing:
        initial;
        edge produce goto idle;

      location idle:
        edge provide goto producing;
    end

The `alphabet` keyword is followed by the events that comprise the alphabet of the automaton, separated by commas. In this case, the alphabet contains the `produce` and `provide` events. Since this explicitly specified alphabet is exactly the same as the default alphabet, it could just as easily be omitted.

### Non-default alphabet

The alphabet is allowed to be empty, which can be explicitly specified as follows:

    alphabet; // Empty alphabet. Automaton doesn't synchronize over any events.

However, the alphabet of an automaton must at least contain the events that occur on the edges of an automaton. That is, it must at least contain the default alphabet.

It may however also contain additional events. Since there are no edges for those additional events, the automaton can never enable those events, and thus always disables them. If a single automaton disables an event, and since it must always participate if it has that event in its alphabet, this means that the event becomes globally disabled in the entire specification. Having such additional events in the alphabet leads to a warning, to inform about the potential undesired effects of globally disabling events in this manner.

### Implicit vs explicit

It should be clear that for most automata, the implicit default alphabet suffices. There are however reasons for explicitly specifying the default alphabet. For large automata, it can improve the readability, as the explicit alphabet makes it easy to determine the alphabet of the automaton, without having to look at all the edges.

The need to explicitly specifying a non-default alphabet rarely occurs. However, several tools generate CIF specifications with explicit alphabets.