concept signature in category functional programming

This is an excerpt from Manning's book Grokking Functional Programming MEAP V11. Login to get full access to this book.

Calculating the score imperatively

public static int calculateScore(String word)  { #A
  int score = 0;
  for(char c : word.toCharArray()) {
    score++;
  }
  return score;
}

copy

Everything looks correct. We have a function that returns only one value and doesn’t mutate any existing values. However, it still uses an external value in order to compute its result. It uses scoreComparator which is defined outside the scope of the function. rankedWord’s signature doesn’t tell the whole story about what’s going on inside.

←

Remember when we discussed functions that lie? They lie when their signatures don’t tell the whole story about their body.

static int scoreWithBonusAndPenalty(String word) {
    int base = score(word);
    int bonus = word.contains(“c”) ? 5 : 0;   #A
    int penalty = word.contains(“s”) ? 7 : 0;
    return base + bonus - penalty;
}

copy

This is an excerpt from Manning's book Functional Programming in C#: How to write better C# code. Login to get full access to this book.

The types for the domain and codomain constitute a function’s interface, also called its type, or signature. You can think of this as a contract: a function signature declares that, given an element from the domain, it will yield an element from the codomain.^[3] This may sound pretty obvious, but you’ll see in chapter 3 that in reality, violations of the signature contract abound.

Figure 3.1. An honest function does exactly what the signature says.

Remember, a signature is a contract. The signature int → Risk says “Give me an int (any of the 2³² possible values for int) and I’ll return a Risk.” But the implementation doesn’t abide by its signature, throwing an ArgumentException for what it considers invalid input. (See figure 3.2.)

Figure 3.2. A dishonest function can have an outcome that isn’t accounted for in the signature.

These last two signatures are so expressive that you can make a good guess at the implementation, which is, of course, a desirable trait. When you write an API, you want it to be clear, and if the signature goes hand in hand with good naming in expressing the intent of the function, all the better.