Search code examples
alloy

Are datatypes the enemy of abstraction?


Page 137 of the book Software Abstractions has these remarkable statements:

Integers are actually not very useful. If you think you need them, think again; there is often a more abstract description that matches the properties better. Just because integers appear in the problem domain does not mean that they should be modeled as such. To figure out whether integers are necessary, ask yourself what properties are actually relied upon. For example, a communication protocol that numbers its messages may rely only on the numbers being distinct; or it may rely on them increasing; or perhaps even being totally ordered. In none of these cases should integers be used.

Wow!

This is important. I want to deeply understand this.

To help me understand, I created two versions of the communication protocol.

The first version uses the Int datatype:

sig Message {
    number: Int
}

The second version does not:

sig Message {
    number: Number 
}    
sig Number {}

Is the second version more abstract? How is it more abstract? Is it more abstract because Number is not tied to a datatype? The first version is less abstract because it specifies a datatype (Int)?

Are datatypes the enemy of abstraction?


Solution

  • No, the second is no better. Suppose your messages aren't totally ordered, but are just partially ordered. Then the point is that rather than assigning an index to each message, you'd do better to make explicit the partial ordering on messages:

    sig Message {follows: set Message, ...}