Skip to content

Commit ca37a0e

Browse files
authored
Merge pull request #190 from hekmekk/refactor/totality-and-partial-function
Introduce 'function' section
2 parents 0ebee1d + c710c2e commit ca37a0e

File tree

1 file changed

+18
-18
lines changed

1 file changed

+18
-18
lines changed

readme.md

Lines changed: 18 additions & 18 deletions
Original file line numberDiff line numberDiff line change
@@ -60,7 +60,8 @@ __Table of Contents__
6060
* [Sum type](#sum-type)
6161
* [Product type](#product-type)
6262
* [Option](#option)
63-
* [Totality](#totality)
63+
* [Function](#function)
64+
* [Partial function](#partial-function)
6465
* [Functional Programming Libraries in JavaScript](#functional-programming-libraries-in-javascript)
6566

6667

@@ -908,21 +909,18 @@ getNestedPrice({item: {price: 9.99}}) // Some(9.99)
908909

909910
`Option` is also known as `Maybe`. `Some` is sometimes called `Just`. `None` is sometimes called `Nothing`.
910911

911-
## Totality
912-
### Total functions
913-
The total function is just like a function in math - it will always return a result of the expected type for expected inputs and will always terminate. The easiest example is `identity` function:
914-
```js
915-
// identity :: a -> a
916-
const identity = a => a
917-
```
918-
or `negate`:
912+
## Function
913+
A **function** `f :: A => B` is an expression - often called arrow or lambda expression - with **exactly one (immutable)** parameter of type `A` and **exactly one** return value of type `B`. That value depends entirely on the argument, making functions context-independant, or [referentially transparent](#referential-transparency). What is implied here is that a function must not produce any hidden [side effects](#side-effects) - a function is always [pure](#purity), by definition. These properties make functions pleasant to work with: they are entirely deterministic and therefore predictable. Functions enable working with code as data, abstracting over behaviour:
914+
919915
```js
920-
// negate :: Boolean -> Boolean
921-
const negate = value => !value
916+
// times2 :: Number -> Number
917+
const times2 = n => n * 2
918+
919+
[1, 2, 3].map(times2) // [2, 4, 6]
922920
```
923-
Such functions always meet the requirements, you just can't provide such arguments, which satisfy inputs but break outputs.
924-
### Partial functions
925-
It's a function which violates the requirements to be total - it may return an unexpected result with some inputs or it may never terminate. Partial functions add cognitive overhead, they are harder to reason about and they can lead to runtime errors. Some examples:
921+
922+
## Partial function
923+
A partial function is a [function](#function) which is not defined for all arguments - it might return an unexpected result or may never terminate. Partial functions add cognitive overhead, they are harder to reason about and can lead to runtime errors. Some examples:
926924
```js
927925
// example 1: sum of the list
928926
// sum :: [Number] -> Number
@@ -949,8 +947,10 @@ times(3)(console.log)
949947
times(-1)(console.log)
950948
// RangeError: Maximum call stack size exceeded
951949
```
952-
### Avoiding partial functions
953-
Partial functions are dangerous, you can sometimes get the expected result, sometimes the wrong result, and sometimes your function can't stop the calculations at all. The input of partial functions should be always checked, and it can be hard to track all edge cases through entire applications, the easiest way to deal with it it's just to convert all partial functions to the total. General advice can be the usage of `Option` type, providing default values for edge cases and checking function conditions to make them always terminate:
950+
951+
### Dealing with partial functions
952+
Partial functions are dangerous as they need to be treated with great caution. You might get an unexpected (wrong) result or run into runtime errors. Sometimes a partial function might not return at all. Being aware of and treating all these edge cases accordingly can become very tedious.
953+
Fortunately a partial function can be converted to a regular (or total) one. We can provide default values or use guards to deal with inputs for which the (previously) partial function is undefined. Utilizing the [`Option`](#Option) type, we can yield either `Some(value)` or `None` where we would otherwise have behaved unexpectedly:
954954
```js
955955
// example 1: sum of the list
956956
// we can provide default value so it will always return result
@@ -963,7 +963,7 @@ sqrt([]) // 0
963963
// change result to Option
964964
// first :: [A] -> Option A
965965
const first = a => a.length ? Some(a[0]) : None()
966-
first([[42]]).map(a => console.log(a)) // 42
966+
first([42]).map(a => console.log(a)) // 42
967967
first([]).map(a => console.log(a)) // console.log won't execute at all
968968
//our previous worst case
969969
first([[42]]).map(a => console.log(a[0])) // 42
@@ -983,7 +983,7 @@ times(3)(console.log)
983983
times(-1)(console.log)
984984
// won't execute anything
985985
```
986-
If you will change all your functions from partial to total, it can prevent you from having runtime exceptions, will make code easier to reason about and easier to maintain.
986+
Making your partial functions total ones, these kinds of runtime errors can be prevented. Always returning a value will also make for code that is both easier to maintain as well as to reason about.
987987

988988
## Functional Programming Libraries in JavaScript
989989

0 commit comments

Comments
 (0)