Maps (or dictionaries) are ubiquitous data structures both in ordinary programming and in the theory of programming languages; we're going to need them in many places in the coming chapters. They also make a nice case study using ideas we've seen in previous chapters, including building data structures out of higher-order functions (from Basics and Poly) and the use of reflection to streamline proofs (from IndProp). We'll define two flavors of maps: total maps, which include a "default" element to be returned when a key being looked up doesn't exist, and partial maps, which instead return an option to indicate success or failure. The latter is defined in terms of the former, using None as the default element.

The Coq Standard Library

One small digression before we begin... Unlike the chapters we have seen so far, this one does not Require Import the chapter before it (nor, transitively, all the earlier chapters). Instead, in this chapter and from now, on we're going to import the definitions and theorems we need directly from Coq's standard library stuff. You should not notice much difference, though, because we've been careful to name our own definitions and theorems the same as their counterparts in the standard library, wherever they overlap.

Documentation for the standard library can be found at https://coq.inria.fr/library/. The Search command is a good way to look for theorems involving objects of specific types. See Lists for a reminder of how to use it. If you want to find out how or where a notation is defined, the Locate command is useful. For example, where is the natural addition operation defined in the standard library?

(There are several uses of the + notation, but only one for naturals.)

We'll see some more uses of Locate in the Imp chapter.

Identifiers

First, we need a type for the keys that we will use to index into our maps. In Lists.v we introduced a fresh type id for a similar purpose; here and for the rest of Software Foundations we will use the string type from Coq's standard library. To compare strings, we use the function eqb from the String module in the standard library.

We will often use a few basic properties of string equality...

Total Maps

Our main job in this chapter will be to build a definition of partial maps that is similar in behavior to the one we saw in the Lists chapter, plus accompanying lemmas about its behavior. This time around, though, we're going to use functions, rather than lists of key-value pairs, to build maps. The advantage of this representation is that it offers a more "extensional" view of maps: two maps that respond to queries in the same way will be represented as exactly the same function, rather than just as "equivalent" list structures. This, in turn, simplifies proofs that use maps. We build up to partial maps in two steps. First, we define a type of total maps that return a default value when we look up a key that is not present in the map.

Intuitively, a total map over an element type A is just a function that can be used to look up strings, yielding As. The function t_empty yields an empty total map, given a default element; this map always returns the default element when applied to any string.

More interesting is the map-updating function, which (as always) takes a map m, a key x, and a value v and returns a new map that takes x to v and takes every other key to whatever m does. The novelty here is that we achieve this effect by wrapping a new function around the old one.

This definition is a nice example of higher-order programming: t_update takes a function m and yields a new function fun x' ⇒ ... that behaves like the desired map. For example, we can build a map taking strings to bools, where "foo" and "bar" are mapped to true and every other key is mapped to false, like this:

Next, let's introduce some notations to facilitate working with maps. First, we use the following notation to represent an empty total map with a default value.

We next introduce a convenient notation for extending an existing map with a new binding.

The examplemap above can now be defined as follows:

This completes the definition of total maps. Note that we don't need to define a find operation on this representation of maps because it is just function application!

When we use maps in later chapters, we'll need several fundamental facts about how they behave. Even if you don't bother to work the following exercises, make sure you thoroughly understand the statements of the lemmas! (Some of the proofs require the functional extensionality axiom, which was discussed in the Logic chapter.)

Exercise: 1 star, standard, optional (t_apply_empty)

First, the empty map returns its default element for all keys:

Exercise: 2 stars, standard, optional (t_update_eq)

Next, if we update a map m at a key x with a new value v and then look up x in the map resulting from the update, we get back v:

Exercise: 2 stars, standard, optional (t_update_neq)

On the other hand, if we update a map m at a key x₁ and then look up a different key x₂ in the resulting map, we get the same result that m would have given:

Exercise: 2 stars, standard, optional (t_update_shadow)

If we update a map m at a key x with a value v₁ and then update again with the same key x and another value v₂, the resulting map behaves the same (gives the same result when applied to any key) as the simpler map obtained by performing just the second update on m:

Exercise: 2 stars, standard (t_update_same)

Given strings x₁ and x₂, we can use the tactic destruct (eqb_spec x₁ x₂) to simultaneously perform case analysis on the result of String.eqb x₁ x₂ and generate hypotheses about the equality (in the sense of =) of x₁ and x₂. With the example in chapter IndProp as a template, use String.eqb_spec to prove the following theorem, which states that if we update a map to assign key x the same value as it already has in m, then the result is equal to m:

Exercise: 3 stars, standard, especially useful (t_update_permute)

Similarly, use String.eqb_spec to prove one final property of the update function: If we update a map m at two distinct keys, it doesn't matter in which order we do the updates.

Partial maps

Lastly, we define partial maps on top of total maps. A partial map with elements of type A is simply a total map with elements of type option A and default element None.

We introduce a similar notation for partial maps:

We can also hide the last case when it is empty.

We now straightforwardly lift all of the basic lemmas about total maps to partial maps.

The update_eq lemma is used very often in proofs. Adding it to Coq's global "hint database" allows proof-automation tactics such as auto to find it.

One last thing: For partial maps, it's convenient to introduce a notion of map inclusion, stating that all the entries in one map are also present in another:

We can then show that map update preserves map inclusion -- that is:

This property is quite useful for reasoning about languages with variable binding -- e.g., the Simply Typed Lambda Calculus, which we will see in Programming Language Foundations, where maps are used to keep track of which program variables are defined in a given scope.