refactor: function - drastically shorten content

This commit is contained in:
Rea Sand 2018-11-11 13:47:22 +01:00
parent ccd128abb5
commit c23510813e

View file

@ -910,12 +910,7 @@ getNestedPrice({item: {price: 9.99}}) // Some(9.99)
`Option` is also known as `Maybe`. `Some` is sometimes called `Just`. `None` is sometimes called `Nothing`. `Option` is also known as `Maybe`. `Some` is sometimes called `Just`. `None` is sometimes called `Nothing`.
## Function ## Function
#### Definition 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:
A **function** is a special kind of language construct: often specified as an arrow or lambda expression - an anonymous or named block of code (the body) with optional parameters. It allows us to treat a piece of code as data and e.g. pass it to methods:
```js
button.onClick(e => console.log("the button has been clicked"))
```
```js ```js
// times2 :: Number -> Number // times2 :: Number -> Number
@ -924,15 +919,6 @@ const times2 = n => n * 2
[1, 2, 3].map(times2) // [2, 4, 6] [1, 2, 3].map(times2) // [2, 4, 6]
``` ```
#### Differentiation
Functional programming has its origins in mathematics and so do a lot of its terms. We hence need to differentiate between the concept of a function and its implementation as a language construct (as outlined above): In terms of set theory, a function `f: X -> Y` is an arrow between two sets `X` and `Y`. It maps *every* element in its *domain* `X` to an element in its *codomain* `Y` (note the use of singular here).
Translating this into the language of computer science, a function is an expression with **exactly one (immutable)** parameter and **exactly one** return value. That value depends entirely on the argument which makes functions context-independant. This property is called [referential transparency](#referential-transparency) which allows for [equational reasoning](#equational-reasoning). Its mathematical origin also necessitates the absence of hidden [side effects](#side-effects) - a function is always [pure](#purity), by definition. These features make functions (as defined by mathematics) so pleasant to work with: they are entirely deterministic and therefore predictable.
Contrast this with the definition above: none of the aforementioned constrains are baked into the language constructs we need to deal with. They have been sacrificed in part for pragmatism, convenience, and expressiveness - useful, powerful, and at times dangerous features of programming languages. This mismatch between the concept of a function and its concrete implementation must be accounted for by the programmer if she wants to benefit from the promises of functional programming.
## Partial function ## Partial function
A partial function is a function which may not be defined for all inputs - it might 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: A partial function is a function which may not be defined for all inputs - it might 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:
```js ```js