# In the context of functional programming, what are 'total' functions and 'partial' functions?

I'm not finding via Google any explanation that my brain can grasp. Can someone explain this, and if possible, give an example of each using either pseudocode or C#?

The term 'total' function was introduced to me in the comments section of this question. The comment is:

when you work with total functions, you can compose them with other functions and use them in higher order functions without worrying about error results "not encoded in the type", i.e. exceptions. – Andres F.

I'm intrigued by this comment.

• I think this is not a real dupe. This question is about concepts on functional programming (see tag). The referred question is about algorithmic terminology. The wording of the other question is very different and only remotely connected to this one. OP could not have recognized his interest therein. It appears that one answer explains what a total function is, and another refers to total and partial functions without elaborating further. But the fact of having some overlapping elements in the answer is not sufficient IMO for making it a dupe. Commented Oct 29, 2016 at 22:37
• This has a community close on it, meaning the question author closed it as a duplicate. Yet there are four reopen votes? Madness!
– user22815
Commented Nov 4, 2016 at 19:21
• @Snowman The question author is not the only one who gets to decide :) Commented Nov 4, 2016 at 19:50

Here's a reasonable definition from the Haskell wiki:

A total function is a function that is defined for all possible values of its input. That is, it terminates and returns a value.

A partial function is a function that is not defined for all possible input values; in some cases instead of returning a value, it may never return at all (think infinite cycles), throw an exception (which usually states "this is undefined for this input value" or "unexpected input" or whatever) or simply crash the system.

A well-known example of a partial function is the integer division, `a divided by b`: it's not defined when `b` is zero!

Another example is `head`, the Haskell function that takes the first element of a list, which throws an error if the list is empty! Something like this:

``````head :: [a] -> a  // this is the signature
head (first : rest) = first
head _ = ... // This is an error! What is the first element of the empty list?
``````

Partial functions like `head` unfortunately exist in Haskell for historical reasons. Note it can be made total like this:

``````headMaybe :: [a] -> Maybe a
headMaybe (first : rest) = Just first
headMaybe _ = Nothing
``````

Then you can safely call `head []` (`[]` is the empty list) and it will return `Nothing` instead of throwing.

Note that when looking at the original `head`, I cannot know just by looking at its definition that it may throw an error in some cases; I need to look at its implementation instead! That's bad. Compare this with `headOption`: just by looking at its type I know it sometimes returns a `Just x` and sometimes a `Nothing`, and I don't have to examine the implementation.

• "Partial functions like head unfortunately exist in Haskell ": Why do you say "unfortunately"? What would be the alternative to `head` being partial? Commented Oct 28, 2016 at 21:49
• @Giorgio The alternative would be something like the `headMaybe` function suggested near the end of the answer. Unlike `head`, where the user needs to assume/assert the list is not empty, `headMaybe` returns a `Maybe` type. When you want to extract the actual value from the maybe type, you need to explicitly state what should be done if it's `Nothing`. This means you can't use the value at the head of the list without specifying what to do if the list was empty. Commented Oct 28, 2016 at 22:04
• I think partial functions have their place as a form of `assert`. In Rust, for example, the `Option` type(similar to Haskell's `Maybe`) has the `expect` method, which means - give me the value, and if it's empty this means the code is buggy and you should crash the program with this error message. Commented Oct 28, 2016 at 22:08
• @IdanArye Haskell's `Maybe` has a similar partial function `fromJust :: Maybe a -> a`. I think they must be used with extreme care, if at all. The problem is that while you may know what you're doing at the exact place where you invoke this, it "taints" the enclosing function as well: now it too may throw an error. And so on and on. Now every caller must either trap the error (which cannot be done in pure code) or accept it has become partial itself. Commented Oct 28, 2016 at 22:15
• That's why they should be treated as a form of `assert`. You don't ever want to catch and handle assertion errors - if an assertion error triggers it essentially means you have a bug in the code and the program's state is unstable. The only valid reasons to catch such errors is for logging/recording(write the error in a file, mail it to the developer, format it for HTTP response, display failure message in a test framework) or if you want to wrap it with a more meaningful error message. I see no merit in explicitly bubbling these errors up to `main`, where debuggers have no meaningful context. Commented Oct 28, 2016 at 23:23