41 |
42 | `ap` is a function that can apply the function contents of one functor to the value contents of another. Say that 5 times fast.
43 |
44 | ```js
45 | Container.of(add(2)).ap(Container.of(3));
46 | // Container(5)
47 |
48 | // all together now
49 | Container.of(2).map(add).ap(Container.of(3));
50 | // Container(5)
51 | ```
52 |
53 | There we are, nice and neat. Good news for `Container(3)` as it's been set free from the jail of the nested monadic function. It's worth mentioning again that `add`, in this case, gets partially applied during the first `map` so this only works when `add` is curried.
54 |
55 | We can define `ap` like so:
56 |
57 | ```js
58 | Container.prototype.ap = function(other_container) {
59 | return other_container.map(this.__value);
60 | }
61 | ```
62 |
63 | Remember, `this.__value` will be a function and we'll be accepting another functor so we need only `map` it. And with that we have our interface definition:
64 |
65 |
66 | > An *applicative functor* is a pointed functor with an `ap` method
67 |
68 | Note the dependence on **pointed**. The pointed interface is crucial here as we'll see throughout the following examples.
69 |
70 | Now, I sense your skepticism (or perhaps confusion and horror), but keep an open mind; this `ap` character will prove useful. Before we get into it, let's explore a nice property.
71 |
72 | ```js
73 | F.of(x).map(f) == F.of(f).ap(F.of(x))
74 | ```
75 |
76 | In proper English, mapping `f` is equivalent to `ap`ing a functor of `f`. Or in properer English, we can place `x` into our container and `map(f)` OR we can lift both `f` and `x` into our container and `ap` them. This allows us to write in a left-to-right fashion:
77 |
78 | ```js
79 | Maybe.of(add).ap(Maybe.of(2)).ap(Maybe.of(3));
80 | // Maybe(5)
81 |
82 | Task.of(add).ap(Task.of(2)).ap(Task.of(3));
83 | // Task(5)
84 | ```
85 |
86 | One might even recognise the vague shape of a normal function call if viewed mid squint. We'll look at the pointfree version later in the chapter, but for now, this is the preferred way to write such code. Using `of`, each value gets transported to the magical land of containers, this parallel universe where each application can be async or null or what have you and `ap` will apply functions within this fantastical place. It's like building a ship in a bottle.
87 |
88 | Did you see there? We used `Task` in our example. This is a prime situation where applicative functors pull their weight. Let's look at a more in-depth example.
89 |
90 | ## Coordination Motivation
91 |
92 | Say we're building a travel site and we'd like to retrieve both a list of tourist destinations and local events. Each of these are separate, stand-alone api calls.
93 |
94 | ```js
95 | // Http.get :: String -> Task Error HTML
96 |
97 | var renderPage = curry(function(destinations, events) { /* render page */ });
98 |
99 | Task.of(renderPage).ap(Http.get('/destinations')).ap(Http.get('/events'))
100 | // Task("
202 |
203 | We haven't spoken much about derived functions. Seeing as all of these interfaces are built off of each other and obey a set of laws, we can define some weaker interfaces in terms of the stronger ones.
204 |
205 | For instance, we know that an applicative is first a functor, so if we have an applicative instance, surely we can define a functor for our type.
206 |
207 | This kind of perfect computational harmony is possible because we're working within a mathematical framework. Mozart couldn't have done better even if he had torrented ableton as a child.
208 |
209 | I mentioned earlier that `of/ap` is equivalent to `map`. We can use this knowledge to define `map` for free:
210 |
211 | ```js
212 | // map derived from of/ap
213 | X.prototype.map = function(f) {
214 | return this.constructor.of(f).ap(this);
215 | }
216 | ```
217 |
218 | Monads are at the top of the food chain, so to speak, so if we have `chain`, we get functor and applicative for free:
219 |
220 | ```js
221 | // map derived from chain
222 | X.prototype.map = function(f) {
223 | var m = this;
224 | return m.chain(function(a) {
225 | return m.constructor.of(f(a));
226 | });
227 | }
228 |
229 | // ap derived from chain/map
230 | X.prototype.ap = function(other) {
231 | return this.chain(function(f) {
232 | return other.map(f);
233 | });
234 | };
235 | ```
236 |
237 | If we can define a monad, we can define both the applicative and functor interfaces. This is quite remarkable as we get all of these can openers for free. We can even examine a type and automate this process.
238 |
239 | It should be pointed out that part of `ap`'s appeal is the ability to run things concurrently so defining it via `chain` is missing out on that optimization. Despite that, it's good to have an immediate working interface while one works out the best possible implementation.
240 |
241 | Why not just use monads and be done with it, you ask? It's good practice to work with the level of power you need, no more, no less. This keeps cognitive load to a minimum by ruling out possible functionality. For this reason, it's good to favor applicatives over monads.
242 |
243 | Monads have the unique ability to sequence computation, assign variables, and halt further execution all thanks to the downward nesting structure. When one sees applicatives in use, they needn't concern themselves with any of that business.
244 |
245 | Now, on to the legalities...
246 |
247 | # Laws
248 |
249 | Like the other mathematical constructs we've explored, applicative functors hold some useful properties for us to rely on in our daily code. First off, you should know that applicatives are "closed under composition", meaning `ap` will never change container types on us(yet another reason to favor over monads). That's not to say we cannot have multiple different effects - we can stack our types knowing that they will remain the same during the entirety of our application.
250 |
251 | To demonstrate:
252 |
253 | ```js
254 | var tOfM = compose(Task.of, Maybe.of);
255 |
256 | liftA2(liftA2(_.concat), tOfM('Rainy Days and Mondays'), tOfM(' always get me down'));
257 | // Task(Maybe('Rainy Days and Mondays always get me down'))
258 | ```
259 |
260 | See, no need to worry about different types getting in the mix.
261 |
262 | Time to look at our favorite categorical law: *identity*:
263 |
264 | ### Identity
265 |
266 | ```js
267 | // identity
268 | A.of(id).ap(v) == v
269 | ```
270 |
271 | Right, so applying `id` all from within a functor shouldn't alter the value in `v`. For example:
272 |
273 | ```js
274 | var v = Identity.of("Pillow Pets");
275 | Identity.of(id).ap(v) == v
276 | ```
277 | `Identity.of(id)` makes me chuckle at its futility. Anyway, what's interesting is that, as we've already established, `of/ap` is the same as `map` so this law follows directly from functor identity: `map(id) == id`.
278 |
279 | The beauty in using these laws is that, like a militant kindergarten gym coach, they force all of our interfaces to play well together.
280 |
281 | ### Homomorphism
282 |
283 | ```js
284 | // homomorphism
285 | A.of(f).ap(A.of(x)) == A.of(f(x))
286 | ```
287 |
288 | A *homomorphism* is just a structure preserving map. In fact, a functor is just a *homomorphism* between categories as it preserves the original category's structure under the mapping.
289 |
290 |
291 |
292 | We're really just stuffing our normal functions and values into a container and running the computation in there so it should come as no surprise that we will end up with the same result if we apply the whole thing inside the container (left side of the equation) or apply it outside, then place it in there (right side).
293 |
294 | A quick example:
295 |
296 | ```js
297 | Either.of(_.toUpper).ap(Either.of("oreos")) == Either.of(_.toUpper("oreos"))
298 | ```
299 |
300 | ### Interchange
301 |
302 | The *interchange* states that it doesn't matter if we choose to lift our function into the left or right side of `ap`.
303 |
304 | ```js
305 | // interchange
306 | v.ap(A.of(x)) == A.of(function(f) { return f(x) }).ap(v)
307 | ```
308 |
309 | Here is an example:
310 |
311 | ```js
312 | var v = Task.of(_.reverse);
313 | var x = 'Sparklehorse';
314 |
315 | v.ap(Task.of(x)) == Task.of(function(f) { return f(x) }).ap(v)
316 | ```
317 |
318 | ### Composition
319 |
320 | And finally composition which is just a way to check that our standard function composition holds when applying inside of containers.
321 |
322 | ```js
323 | // composition
324 | A.of(compose).ap(u).ap(v).ap(w) == u.ap(v.ap(w));
325 | ```
326 |
327 | ```js
328 | var u = IO.of(_.toUpper);
329 | var v = IO.of(_.concat("& beyond"));
330 | var w = IO.of("blood bath ");
331 |
332 | IO.of(_.compose).ap(u).ap(v).ap(w) == u.ap(v.ap(w))
333 | ```
334 |
335 | ## In Summary
336 |
337 | A good use case for applicatives is when one has multiple functor arguments. They give us the ability to apply functions to arguments all within the functor world. Though we could already do so with monads, we should prefer applicative functors when we aren't in need of monadic specific functionality.
338 |
339 | We're almost finished with container APIs. We've learned how to `map`, `chain`, and now `ap` functions. In the next chapter, we'll learn how to work better with multiple functors and disassemble them in a principled way.
340 |
341 | [Chapter 11: Traversable/Foldable Functors](ch11.md)
342 |
343 |
344 |
345 | ## Exercises
346 |
347 | ```js
348 | require('./support');
349 | var Task = require('data.task');
350 | var _ = require('ramda');
351 |
352 | // fib browser for test
353 | var localStorage = {};
354 |
355 |
356 |
357 | // Exercise 1
358 | // ==========
359 | // Write a function that adds two possibly null numbers together using Maybe and ap().
360 |
361 | // ex1 :: Number -> Number -> Maybe Number
362 | var ex1 = function(x, y) {
363 | // write me
364 | };
365 |
366 |
367 | // Exercise 2
368 | // ==========
369 | // Now write a function that takes 2 Maybe's and adds them. Use liftA2 instead of ap().
370 |
371 | // ex2 :: Maybe Number -> Maybe Number -> Maybe Number
372 | var ex2 = undefined;
373 |
374 |
375 |
376 | // Exercise 3
377 | // ==========
378 | // Run both getPost(n) and getComments(n) then render the page with both. (The n arg is arbitrary.)
379 | var makeComments = _.reduce(function(acc, c) { return acc+"
(http://www.mathsisfun.com/sets/function.html)
105 |
106 | 反之，下圖則展示了`非` function 的關係，因為輸入值的 `5` 指向了多個輸出：
107 |
108 | 
(http://www.mathsisfun.com/sets/function.html)
109 |
110 | Function 可以被描述為一個集合，這個集合中的的內容為（輸入，輸出）：`[(1,2), (3,6), (5,10)]`（看來這個 function 是將輸入加倍）。
111 |
112 | 或是一張表：
113 | | Input | Output |
|---|---|
| 1 | 2 |
| 2 | 4 |
| 3 | 6 |
118 |
119 |
120 | 如果輸入直接指名了輸出為何，那麼就不必實作細節了。因為 function 只是將輸入 mapping 至輸出，所以簡單的寫一個 object ，將 `[]` 代替 `()` 就能執行了。
121 |
122 | ```js
123 | var toLowerCase = {
124 | 'A': 'a',
125 | 'B': 'b',
126 | 'C': 'c',
127 | 'D': 'd',
128 | 'E': 'e',
129 | 'D': 'd',
130 | };
131 |
132 | toLowerCase['C'];
133 | //=> 'c'
134 |
135 | var isPrime = {
136 | 1: false,
137 | 2: true,
138 | 3: true,
139 | 4: false,
140 | 5: true,
141 | 6: false,
142 | };
143 |
144 | isPrime[3];
145 | //=> true
146 | ```
147 |
148 | 當然了，你可能需要計算而不是手動將這些東西寫出來，不過這樣說明了透過不同方式來思考 function。（你可能會想「要是 function 有多個參數呢？」。的確，這種情況表明了以數學方式思考的一些不便。我們可以暫時將他們打包進陣列中，或者把 `arguments` object 看成是輸入。當我們學習 `curry` 的概念後，你就知道如何直接為 function 在數學上的定義建立 model。）
149 |
150 | 戲劇性的事：Pure function *就是*數學上的 function，而且是 functional programming 的全部。使用這些 pure function 來進行程式設計會帶來大量的好處。讓我們來看看為何要不遺餘力的保留 function 純粹性的原因。
151 |
152 | ## 追求「Pure」的理由
153 |
154 | ### 可快取性（Cacheable）
155 |
156 | 首先，pure function 可以根據輸入來做快取。其中一種典型的方式就是透過 memoization。
157 |
158 | ```js
159 | var squareNumber = memoize(function(x) {
160 | return x * x;
161 | });
162 |
163 | squareNumber(4);
164 | //=> 16
165 |
166 | squareNumber(4); // 回傳輸入為 4 的快取結果
167 | //=> 16
168 |
169 | squareNumber(5);
170 | //=> 25
171 |
172 | squareNumber(5); // 回傳輸入為 5 的快取結果
173 | //=> 25
174 | ```
175 |
176 | 下方是一個簡單的實作，即便有很多更強大的版本可做選擇。
177 |
178 | ```js
179 | var memoize = function(f) {
180 | var cache = {};
181 |
182 | return function() {
183 | var arg_str = JSON.stringify(arguments);
184 | cache[arg_str] = cache[arg_str] || f.apply(f, arguments);
185 | return cache[arg_str];
186 | };
187 | };
188 | ```
189 |
190 | 值得注意的是可以透過延遲執行的方式將 impure 的 function 轉換為 pure function：
191 |
192 | ```js
193 | var pureHttpCall = memoize(function(url, params) {
194 | return function() {
195 | return $.getJSON(url, params);
196 | };
197 | });
198 | ```
199 |
200 | 這裡有趣的地方在於我們並沒有真正的發送 http 請求－只是回傳了一個 function，當呼叫它的時候才會發送請求。這個 function 之所以 pure 是因為它會根據相同的輸入回傳相同的輸出：給定了 `url` 及 `params` 後，它只會回傳同一個 http 請求的 function。
201 |
202 | 我們的 `memoize` function 執行起來沒有任何問題，雖然他快取的不是 http 請求的結果，而是產生的 function。
203 |
204 | 目前看來這種方式的意義不大，但我們很快會學習一些技巧來發掘它的用處。重點是我們可以快取任何一個 function，不管它們看起來多麽具有破壞性。
205 |
206 | ### 可移植性（Portable） / 本身即文件（Self-Documenting）
207 |
208 | Pure function 完全是自給自足的，它所需要的所有東西都能輕易取得。仔細想想⋯這種特性的好處為何呢？首先，function 的依賴會很明確，因此更易於觀察和理解－沒有偷偷摸摸的小動作。
209 |
210 | ```js
211 | //impure
212 | var signUp = function(attrs) {
213 | var user = saveUser(attrs);
214 | welcomeUser(user);
215 | };
216 |
217 | var saveUser = function(attrs) {
218 | var user = Db.save(attrs);
219 | ...
220 | };
221 |
222 | var welcomeUser = function(user) {
223 | Email(user, ...);
224 | ...
225 | };
226 |
227 | //pure
228 | var signUp = function(Db, Email, attrs) {
229 | return function() {
230 | var user = saveUser(Db, attrs);
231 | welcomeUser(Email, user);
232 | };
233 | };
234 |
235 | var saveUser = function(Db, attrs) {
236 | ...
237 | };
238 |
239 | var welcomeUser = function(Email, user) {
240 | ...
241 | };
242 | ```
243 |
244 | 這個例子說明了 pure function 對於依賴必須要誠實，這樣我們就能知道他的目的。從 `signUp` 就可以得知它會用到 `Db`、`Email` 即 `attrs`，這在最小程度上給了我們足夠的訊息。
245 |
246 | 往後我們會學習如何不透過這種延遲執行的方式讓一個 function 變為 pure function，不過這裡的重點是，對比 impure function，pure function 能夠提供更多的訊息，前者背後做了什麼事只有老天爺才知道。
247 |
248 | 此外要注意的是，我們透過強制「注入」依賴，或把他們當作參數傳遞，會讓我們的 app 變成更加靈活，因為資料庫或 mail client 等等都已經參數化了（別擔心，我們會有別種方式讓它不那麼單調乏味）。若要使用另一個 Db，我們只需要將他傳給 function 即可。若想在新的應用程式中使用這個可靠的 function，只要在那時將 `Db` 與 `Email` 傳遞進 function 就行了，相當容易。
249 |
250 | 在 JavaScript 設定中，可移植性代表可將 function serializing（序列化）並透過 socket 傳動。也可以表示程式碼能夠在所有的 app worker 中執行。總之，可移植性是一個相當強大的特性。
251 |
252 | Imperative programming 中「典型」的方式與過程都深深的根值在他們的環境中，透過狀態、依賴即有效作用（available effects）達成；Pure function 則與此相反，只要我們願意，可以在任何地方執行它。
253 |
254 | 你上一次將類別方法複製到新的 app 中是何時？我最喜歡的名言是 Erlang 的作者 Joe Armstrong 所說的一句話：「物件導向語言的問題在於，它們隨身攜帶那些癮式的環境。你只要一根香蕉，但卻得到一個拿著香蕉的大猩猩⋯以及整片叢林」。
255 |
256 | ### 可測試性（Testable）
257 |
258 | 下一點，pure function 讓測試更加的容易。我們不需 mock 一個「真實的」付款閘道，或每次測試前都要 setup，測試之後都要 assert 狀態。我們只需要給定一個輸入，在 assert 輸出即可。
259 |
260 | 事實上，我們會發現 functional 的社群正在開創一個新的測試工具，能夠幫助我們自動產生輸入並 assert 輸出。這超出了本書的範圍，不過我強烈建議你去試試 *Quickcheck*－一個為 pure functional 環境量身打造的測試工具。
261 |
262 | ### 合理性（Reasonable）
263 |
264 | 很多人相信使用 pure function 最大的好處就是*引用透明性（referential transparency）*。如果一段程式碼可以替換成它執行後所得到的結果，而且是在不改變整個程式行為的前提下替換的，那麼我們可以說這段程式碼是引用透明的。
265 |
266 | 由於 pure function 能夠根據相同的輸入回傳相同的輸出，所以它們就能夠保證總是回傳同一個結果，這也就保證了引用透明性。我們來看一個例子。
267 |
268 | ```js
269 |
270 | var Immutable = require('immutable');
271 |
272 | var decrementHP = function(player) {
273 | return player.set('hp', player.get('hp') - 1);
274 | };
275 |
276 | var isSameTeam = function(player1, player2) {
277 | return player1.get('team') === player2.get('team');
278 | };
279 |
280 | var punch = function(player, target) {
281 | return isSameTeam(player, target) ? target : decrementHP(target);
282 | };
283 |
284 | var jobe = Immutable.Map({
285 | name: 'Jobe',
286 | hp: 20,
287 | team: 'red',
288 | });
289 | var michael = Immutable.Map({
290 | name: 'Michael',
291 | hp: 20,
292 | team: 'green',
293 | });
294 |
295 | punch(jobe, michael);
296 | //=> Immutable.Map({name:'Michael', hp:19, team: 'green'})
297 | ```
298 |
299 | `decrementHP`、`isSameTeam` 及 `punch` 都是 pure function，所以是引用透明的。我們可以透過一種稱做為*等式推導（equational reasoning）*的技術來分析程式碼，這技術就是以「一對一」進行替換，有點像是在不考慮程式性執行的怪異行為的情況下，手動執行相關程式碼。我們借助引用透明性來解析這段程式碼。
300 |
301 | 首先我們將 `isSameTeam` function 替換。
302 |
303 | ```js
304 | var punch = function(player, target) {
305 | return player.get('team') === target.get('team') ? target : decrementHP(target);
306 | };
307 | ```
308 |
309 | 因為我們資料是 immutable，所以可以直接將 teams 替換成實際值。
310 |
311 | ```js
312 | var punch = function(player, target) {
313 | return 'red' === 'green' ? target : decrementHP(target);
314 | };
315 | ```
316 |
317 | 因為執行結果為 false，所以可以將整行 if 刪除。
318 |
319 | ```js
320 | var punch = function(player, target) {
321 | return decrementHP(target);
322 | };
323 |
324 | ```
325 |
326 | 如果我們替換 `decrementHP`，我們會發現在這個情況下，punch 變為一個讓 `hp` 遞減 1 的 function。
327 |
328 | ```js
329 | var punch = function(player, target) {
330 | return target.set('hp', target.get('hp') - 1);
331 | };
332 | ```
333 |
334 | 總之，等式推導所帶來分析程式碼能力對重構與理解程式碼非常重要。事實上，我們重構 flock of seagulls 程式使用的正是這種技巧：透過等式推導利用加與乘的特性。我們會使用這些技巧貫穿全書。
335 |
336 | ### 並行程式碼
337 |
338 | 最後，也是決定性的一點：我們可以並行執行任何 pure function，因為 pure function 根本不需要存取共享的記憶體，而且根據其定義，它也不會因副作用而進入競爭狀態（race condition）。
339 |
340 | 這在伺服器端 js 環境及使用 web worker 的瀏覽器中是相當容易實現的，因為他們使用的執行緒（thread）。不過出於對 impure function 複雜度的考慮，目前主流的觀點還是避免使用並行。
341 |
342 |
343 | ## 總結
344 |
345 | 我們已經瞭解了何為 pure function，也看到作為 functional programmer 的我們，為何深信它們是不同凡響的。從這裡開始，我們將盡力以 pure 的方式撰寫所有 function。對此我們需要一些額外的工具來達成這個目的，同時也盡量把 impure function 從 pure 程式碼中分離。
346 |
347 | 如果手邊沒有一些額外的工具，那麼撰寫 pure function 的程式就會有點費力。我們必須透過到處傳遞參數來操作資料，何況狀態是禁止使用的，更別說作用了。誰願意這樣自虐自己寫程式？所以讓我們來學習一個叫做 curry 的新工具。
348 |
349 | [第 4 章：Curry（柯里化）](ch4.md)
350 |
--------------------------------------------------------------------------------
/ch4.md:
--------------------------------------------------------------------------------
1 | # 第 4 章：Curry（柯里化）
2 |
3 | ## Curry 的重要性
4 | 我爸以前跟我說過，有些東西在你得到以前是可有可無的，但得到之後就不可或缺了。微波爐、智慧型手機皆是如此。老人在沒有網路時也過得很充實。對我來說，curry 也是這樣。
5 |
6 | Curry 的概念很簡單：你可以只透過部分的參數呼叫一個 function，它會回傳一個 function 去處理剩下的參數。
7 |
8 | 你可以一次性的呼叫 curry function，也可以每次只傳遞一個參數。
9 |
10 | ```js
11 | var add = function(x) {
12 | return function(y) {
13 | return x + y;
14 | };
15 | };
16 |
17 | var increment = add(1);
18 | var addTen = add(10);
19 |
20 | increment(2);
21 | // 3
22 |
23 | addTen(2);
24 | // 12
25 | ```
26 |
27 | 這裡我們建立了一個 `add` function，它接受一個參數並回傳一個新的 function。當呼叫它後，回傳的 function 會透過 closure（閉包）的方式儲存 `add` 第一個參數。一次透過兩個參數呼叫實在是有點繁複，幸虧我們可以使用一個名為 `curry` 的特殊 helper function 讓定義並呼叫這種 function 變得更容易。
28 |
29 | 讓我們建立一些 curry function 來享受一下。
30 |
31 | ```js
32 | var curry = require('lodash/curry');
33 |
34 | var match = curry(function(what, str) {
35 | return str.match(what);
36 | });
37 |
38 | var replace = curry(function(what, replacement, str) {
39 | return str.replace(what, replacement);
40 | });
41 |
42 | var filter = curry(function(f, ary) {
43 | return ary.filter(f);
44 | });
45 |
46 | var map = curry(function(f, ary) {
47 | return ary.map(f);
48 | });
49 | ```
50 |
51 | 上方程式碼所遵循的是一種簡單，但也重要的模式。這裡戰略性的將欲操作的資料（String，Array）作為最後一個參數傳入。當使用時就知道為何要這麼做了。
52 |
53 | ```js
54 | match(/\s+/g, 'hello world');
55 | // [ ' ' ]
56 |
57 | match(/\s+/g)('hello world');
58 | // [ ' ' ]
59 |
60 | var hasSpaces = match(/\s+/g);
61 | // function(x) { return x.match(/\s+/g) }
62 |
63 | hasSpaces('hello world');
64 | // [ ' ' ]
65 |
66 | hasSpaces('spaceless');
67 | // null
68 |
69 | filter(hasSpaces, ['tori_spelling', 'tori amos']);
70 | // ['tori amos']
71 |
72 | var findSpaces = filter(hasSpaces);
73 | // function(xs) { return xs.filter(function(x) { return x.match(/\s+/g) }) }
74 |
75 | findSpaces(['tori_spelling', 'tori amos']);
76 | // ['tori amos']
77 |
78 | var noVowels = replace(/[aeiouy]/ig);
79 | // function(replacement, x) { return x.replace(/[aeiouy]/ig, replacement) }
80 |
81 | var censored = noVowels("*");
82 | // function(x) { return x.replace(/[aeiouy]/ig, '*') }
83 |
84 | censored('Chocolate Rain');
85 | // 'Ch*c*l*t* R**n'
86 | ```
87 |
88 | 這裡示範的是一種「pre-load（預先載入）」的能力，透過傳遞一至兩個參數，就能得到一個記住這些參數的新 function。
89 |
90 | 我建議你透過 `npm install lodash` 安裝 lodash，複製上方的程式碼至 REPL 執行看看。你也可以在能使用 lodash 或 ramda 的瀏覽器環境中執行。
91 |
92 | ## 不只是雙關語 / 咖哩
93 |
94 | Curry 的用處非常廣泛。就像在 `hasSpaces`、`findSpaces` 及 `censored` 看到的，只需傳遞一些參數至 function，就能得到一個新的 function。
95 |
96 | 只要透過 `map` 封裝單一元素的 function，即可將它轉換成參數維陣列的 function：
97 |
98 | ```js
99 | var getChildren = function(x) {
100 | return x.childNodes;
101 | };
102 |
103 | var allTheChildren = map(getChildren);
104 | ```
105 |
106 | 只傳遞一部分參數至 function 通常稱做*部分應用（partial application）*，能夠大量減少樣板程式碼（boiler plate code）。考慮上方的 `allTheChildren` function 若使用 lodash 非 curry 的 `map` 來寫會如何（請注意參數的順序也不同）：
107 |
108 | ```js
109 | var allTheChildren = function(elements) {
110 | return _.map(elements, getChildren);
111 | };
112 | ```
113 |
114 | 一般來說我們不會定義直接操作陣列的 function，因為我們只需要行內呼叫 `map(getChildren)` 即可。此點也同樣適用於 `sort`、`filter` 及其他高階 function（Higher order function：一個 function 使用或者是回傳另一個 function）。
115 |
116 | 當我們討論 *pure function* 時，我們會說它接受一個輸入並對應一個輸出。Curry 所做的事也是如此：每傳遞一個參數就會回傳一個新的 function 處理剩餘的參數。這就是一個輸入對應一個輸出。
117 |
118 | 不論輸出是否為另一個 function，它也是 pure function。我們也接受一次傳遞多個參數，不過這樣也只是為了方便減少多餘的 `()`。
119 |
120 |
121 | ## 總結
122 |
123 | Curry 使用起來相當得心應手，每天使用它對我來說簡直是一種享受。它是一種必備的工具，讓 functional programming 不那麼繁冗。
124 |
125 | 透過簡單的傳遞一些參數，就能夠動態的建立實用的新 function，即便有多個參數，也保留了數學 function 的定義。
126 |
127 | 讓我們來介紹另一個必備工具 `compose（組合）`
128 |
129 | [第 5 章：透過 Compose 開發](ch5.md)
130 |
131 | ## 練習
132 |
133 | 在開始前先說明一下。我們預設會使用名為 [Ramda](http://ramdajs.com) 的 library 將 function 轉換為 curry function。或者你能使用由 lodash 撰寫與維護的 [lodash/fp](https://github.com/lodash/lodash/wiki/FP-Guide) 做到一樣的事。兩者都運作得相當好，你可以根據偏好做選擇。
134 |
135 | 你還能對自己的練習程式碼進行[unit test（單元測試）](https://github.com/DrBoolean/mostly-adequate-guide/tree/master/code/part1_exercises)，或者只將程式碼複製到 javascript REPL 執行看看。
136 |
137 | 練習的答案已經放在[本書的 repository](https://github.com/DrBoolean/mostly-adequate-guide/tree/master/code/part1_exercises/answers)。做本練習最佳方式就是透過[及時回饋環線（immediate feedback loop）](feedback_loop.md)。
138 |
139 | ```js
140 | var _ = require('ramda');
141 |
142 |
143 | // 練習 1
144 | //==============
145 | // 透過部分套用（partially applying）重構此 function 移除所有參數。
146 |
147 | var words = function(str) {
148 | return _.split(' ', str);
149 | };
150 |
151 | // 練習 1a
152 | //==============
153 | // 使用 map 建立一個新的 words fn，讓它可以操作字串的陣列。
154 |
155 | var sentences = undefined;
156 |
157 |
158 | // 練習 2
159 | //==============
160 | // 透過部分套用（partially applying）重構此 function 移除所有參數。
161 |
162 | var filterQs = function(xs) {
163 | return _.filter(function(x) {
164 | return match(/q/i, x);
165 | }, xs);
166 | };
167 |
168 |
169 | // 練習 3
170 | //==============
171 | // 使用 helper function _keepHighest 重構 max，讓它不需參考任何參數。
172 |
173 | // 不需更動：
174 | var _keepHighest = function(x, y) {
175 | return x >= y ? x : y;
176 | };
177 |
178 | // 重構這段：
179 | var max = function(xs) {
180 | return _.reduce(function(acc, x) {
181 | return _keepHighest(acc, x);
182 | }, -Infinity, xs);
183 | };
184 |
185 |
186 | // 加分題 1：
187 | // ============
188 | // 封裝陣列的 slice 讓它變為 functional 的 curry function。
189 | // //[1, 2, 3].slice(0, 2)
190 | var slice = undefined;
191 |
192 |
193 | // 加分題 2：
194 | // ============
195 | // 使用 slice 定義一個「take」function，讓它擷取字串從頭開始的的 n 個元素。此 function 必須為 curry function。
196 | // // 輸入「Something」且 n=4 時結果必須為「Some」
197 | var take = undefined;
198 | ```
199 |
--------------------------------------------------------------------------------
/ch5.md:
--------------------------------------------------------------------------------
1 | # 第 5 章：使用 Compose 開發
2 |
3 | ## Functional 飼養
4 |
5 | 這就是 `compose`：
6 |
7 | ```js
8 | var compose = function(f, g) {
9 | return function(x) {
10 | return f(g(x));
11 | };
12 | };
13 | ```
14 |
15 | `f` 和 `g` 都是 function，`x` 則是通過它們之間「管道」的值。
16 |
17 | Compose 感覺起來就像在飼養 function。你就是 function 的飼養員，選擇兩個有你喜歡特色的 function 並將它們組合，產生一個新的 function。使用起來如下：
18 |
19 | ```js
20 | var toUpperCase = function(x) {
21 | return x.toUpperCase();
22 | };
23 | var exclaim = function(x) {
24 | return x + '!';
25 | };
26 | var shout = compose(exclaim, toUpperCase);
27 |
28 | shout("send in the clowns");
29 | //=> "SEND IN THE CLOWNS!"
30 | ```
31 |
32 | 組合兩個 function 並回傳一個新的 function 是很容易理解的：組合某種類型（在本例中為 function）的兩個元素應該產生一個該類型的新元素。你將兩個樂高積木組合起來並不會得到林肯積木。所以這是有跡可循的，我們會在適當的時候探討這方面的一些底層理論。
33 |
34 | 在 `composer` 的定義中，`g` 會在 `f` 之前執行，而建立一個由右至左的資料流。這麼做的可讀性遠高於巢狀的 function 呼叫。若不用 composer，那麼會像以下這樣：
35 |
36 | ```js
37 | var shout = function(x) {
38 | return exclaim(toUpperCase(x));
39 | };
40 | ```
41 |
42 | 程式由右而左執行，而不是由內而外，我認為這可以稱之為「左傾（left direction）」。讓我們看看一個順序重要的例子：
43 |
44 | ```js
45 | var head = function(x) {
46 | return x[0];
47 | };
48 | var reverse = reduce(function(acc, x) {
49 | return [x].concat(acc);
50 | }, []);
51 | var last = compose(head, reverse);
52 |
53 | last(['jumpkick', 'roundhouse', 'uppercut']);
54 | //=> 'uppercut'
55 | ```
56 |
57 | `reverse` 會將列表反轉，`head` 則會取得列表的第一個元素。結果就得到了一個效率不高的 `last` function。這個組合中 function 的執行順序是顯而易見的。雖然我們可以定義一個由左而右的版本，但是由右而左更能反映出數學上的含義。沒錯，compose 的概念直接來自於數學課本。事實上，現在是時候看看所有 compose 都有的一個特性了。
58 |
59 | ```js
60 | // 結合律（associativity）
61 | var associative = compose(f, compose(g, h)) == compose(compose(f, g), h);
62 | // true
63 | ```
64 |
65 | Compose 有結合律的特性，意指不管你將哪兩個分為一組都不重要。所以，如果我們想將字串轉為大寫，可以這樣寫：
66 |
67 | ```js
68 | compose(toUpperCase, compose(head, reverse));
69 |
70 | // 或
71 | compose(compose(toUpperCase, head), reverse);
72 | ```
73 |
74 | 因為呼叫 `compose` 時的分組方式不重要，所以結果都會是相同的。因此，這也讓我們可以撰寫一個參數數量可變的 compose，用法如下：
75 |
76 | ```js
77 | // 在前面的例子中我們寫了兩個 compose，不過因為 compose 符合結合律，我們可以讓 compose 接受多個 function，並讓它自己決定如何分組。
78 | var lastUpper = compose(toUpperCase, head, reverse);
79 |
80 | lastUpper(['jumpkick', 'roundhouse', 'uppercut']);
81 | //=> 'UPPERCUT'
82 |
83 |
84 | var loudLastUpper = compose(exclaim, toUpperCase, head, reverse);
85 |
86 | loudLastUpper(['jumpkick', 'roundhouse', 'uppercut']);
87 | //=> 'UPPERCUT!'
88 | ```
89 |
90 | 運用結合律的屬性能夠為我們帶來強大的靈活性，及當結果相同時的所帶來的安心感。稍微複雜一點，參數數量可變的 compose 都已經包含在本書的提供的 library 中，你也可以在像是 [lodash][lodash-website]、[underscore][underscore-website] 及 [ramda][ramda-website] 的 library 中也可以找到它們。
91 |
92 | 結合率的一大好處是任何一個 function 的分組都可以被拆開，然後再以他們自己的 compose 方式封裝在一起。讓我們來重構前面的例子：
93 |
94 | ```js
95 | var loudLastUpper = compose(exclaim, toUpperCase, head, reverse);
96 |
97 | // 或
98 | var last = compose(head, reverse);
99 | var loudLastUpper = compose(exclaim, toUpperCase, last);
100 |
101 | // 或
102 | var last = compose(head, reverse);
103 | var angry = compose(exclaim, toUpperCase);
104 | var loudLastUpper = compose(angry, last);
105 |
106 | // 更多變種⋯
107 | ```
108 |
109 | 這沒有標準答案－我們只是以自己喜歡的方式玩樂高積木而已。一般來說，分組的最佳方式就是讓它可重用，像是 `last` 及 `angry`。如果熟悉的 Fowler 的《[Refactoring][refactoring-book]》這本書的話，你可能會知道這個過程稱之為「[extract method（抽出方法）][extract-method-refactor]」⋯只不過不需要擔心object的所有狀態。
110 |
111 | ## Pointfree
112 |
113 | Pointfree 模式指的是永遠不必說出你的資料。呃抱歉（譯註：此處原文是「Pointfree style means never having to say your data」，源自 1970 年的電影 Love Story 裡的一句著名台詞「Love means never having to say you're sorry」。緊接著作者又說了一句「Excuse me」，大概是一種幽默）。意思是指，function 不必提及要操作的資料是什麼樣的。First Class Function、curry 及 compose 協作起來非常有助於建立這種模式。
114 |
115 | ```js
116 | // 非 pointfree，因為我們提到資料：word
117 | var snakeCase = function(word) {
118 | return word.toLowerCase().replace(/\s+/ig, '_');
119 | };
120 |
121 | // pointfree
122 | var snakeCase = compose(replace(/\s+/ig, '_'), toLowerCase);
123 | ```
124 |
125 | 看到 `replace` 是如何被部分呼叫了嗎？這裡做的事情就是將資料傳遞至每個接收單一參數的 function。Curry 讓每個 function 都先接收資料，再操作資料，最後再將資料傳遞至下一個 function。另外要注意在 pointfree 的版本中，我們不需資料來建構 function，而在非 pointfree 的版本中，我們必須先擁有 `word` 才能進行其他操作。
126 |
127 | 讓我們看看另一個例子。
128 |
129 | ```js
130 | // 非 pointfree，因為我們提到資料：name
131 | var initials = function(name) {
132 | return name.split(' ').map(compose(toUpperCase, head)).join('. ');
133 | };
134 |
135 | // pointfree
136 | var initials = compose(join('. '), map(compose(toUpperCase, head)), split(' '));
137 |
138 | initials("hunter stockton thompson");
139 | // 'H. S. T'
140 | ```
141 |
142 | Pointfree 幫助我們移除不必要的命名，讓程式碼保持簡潔和通用。對 functional 的程式碼來說，pointfree 是個很好的試金石，因為它能告訴我們一個 function 是否為接受輸入回傳輸出的小 function。像是 compose 無法用於 while 迴圈上。不過請注意，pointfree 就像一把雙刃劍，有時會混淆視聽。並不是所有的 functional 程式碼都為 pointfree，不過這沒關係。可以使用他的時候就使用，不能使用的時候就用普通的 function。
143 |
144 | ## Debug
145 | Compose 常見的錯誤就是，在沒有第一次部分呼叫前，就 compose 像是 `map` 接受兩個參數的 function。
146 |
147 | ```js
148 | // 不正確－我們傳遞 array 給 angry，但不知道部分呼叫的 map 接收到什麼。
149 | var latin = compose(map, angry, reverse);
150 |
151 | latin(['frog', 'eyes']);
152 | // error
153 |
154 |
155 | // 正確－每個 function 都預期接受一個參數。
156 | var latin = compose(map(angry), reverse);
157 |
158 | latin(['frog', 'eyes']);
159 | // ['EYES!', 'FROG!'])
160 | ```
161 |
162 | 如果你在 debug compose 時遇到了問題，我們可以使用下面這個實用，但 impure 的 trace function 追蹤執行情況。
163 |
164 | ```js
165 | var trace = curry(function(tag, x) {
166 | console.log(tag, x);
167 | return x;
168 | });
169 |
170 | var dasherize = compose(join('-'), toLower, split(' '), replace(/\s{2,}/ig, ' '));
171 |
172 | dasherize('The world is a vampire');
173 | // TypeError: Cannot read property 'apply' of undefined
174 | ```
175 |
176 | 這裡出錯了，讓我們 `trace` 看看
177 |
178 | ```js
179 | var dasherize = compose(join('-'), toLower, trace('after split'), split(' '), replace(/\s{2,}/ig, ' '));
180 | // after split [ 'The', 'world', 'is', 'a', 'vampire' ]
181 | ```
182 |
183 | 啊！因為 `toLower` 執行於 array，我們需要透過 `map` 呼叫它。
184 |
185 | ```js
186 | var dasherize = compose(join('-'), map(toLower), split(' '), replace(/\s{2,}/ig, ' '));
187 |
188 | dasherize('The world is a vampire');
189 |
190 | // 'the-world-is-a-vampire'
191 | ```
192 |
193 | `trace` function 讓我們在某個特定的點觀察資料，以便進行 debug。像是 haskell 與 purescript 的語言為了方便開發，也都提供了相似的 function。
194 |
195 | Compose 會成為我們建構程式的工具，且幸運的是，他背後有個強大的理論做支撐。讓我們來研究一下這個理論。
196 |
197 |
198 | ## 範疇論
199 |
200 | 範疇論（category theory）是個數學的抽象分支，能夠形式化集合論（set theory）、類型論（type theory）、群論（group theory）及邏輯學（logic）等數學分支的一些概念。範疇學主要處理 object、態射（morphism）及轉化（transformation），而這些概念跟程式設計的關係非常密切。下圖是一些同樣概念分別在不同理論下的形式：
201 |
202 | 
203 |
204 | 抱歉，我沒有任何要嚇你的意思。我不假設你對這些概念瞭若指掌，我的重點只想讓你知道這裡有多少重複的內容，讓你知道為何範疇學要統一這些概念。
205 |
206 | 在範疇學中，有一個概念稱之為⋯範疇。有以下 component 的 collection 就構成一個範疇：
207 |
208 | * object 的 collection
209 | * 態射的 collection
210 | * 態射的組合
211 | * 一個名為 identity 獨特的態射
212 |
213 | 範疇學抽象到可以模擬任何事物，不過我們目前最關心的還是類型及 function，所以讓我們將範疇學運用到它們身上看看。
214 |
215 | **Object 的 collection**
216 | Object 就是資料類型。例如：``String``、``Boolean``、``Number`` 及 ``Object`` 等等。通常我們把資料類型作為所有可能值的一個集合（set）。像是 ``Boolean`` 就是 `[true, false]` 的集合，``Number`` 可以是所有實數的集合。把類型當作集合是有好處的，因為我們可以利用集合論處理類型。
217 |
218 |
219 | **態射的 collection**
220 | 態射會是標準的 pure function。
221 |
222 | **態射的組合**
223 | 你可以已經猜到了，這就是本章所介紹的新玩具－`compose`。我們已經討論過 `compose` function 是符合結合律，這並不是巧合，結合律是範疇學中對任何組合都適用的一個特性。
224 |
225 | 下圖展示了何為組合：
226 |
227 | 
228 | 
229 |
230 | 下方的程式碼是個具體的例子：
231 |
232 | ```js
233 | var g = function(x) {
234 | return x.length;
235 | };
236 | var f = function(x) {
237 | return x === 4;
238 | };
239 | var isFourLetterWord = compose(f, g);
240 | ```
241 |
242 | **一個名為 identity 獨特的態射**
243 | 讓我們來介紹一個名為 `id` 的實用 function。這個 function 只是接受隨便的輸入然後原封不動的還給你。如下：
244 |
245 | ```js
246 | var id = function(x) {
247 | return x;
248 | };
249 | ```
250 |
251 | 你可能想問「這到底哪裡有用了？」。我們會在之後的幾個章節擴增這個 function，暫時將它當作一個可以替代給定值的 function－一個假裝自己是資料的 function。
252 |
253 | `id` 與 compose 簡直是天作之合。下面這個特性對所有的 unary function（一元 function：只接受一個參數的 function）f 都成立：
254 |
255 | ```js
256 | // identity
257 | compose(id, f) == compose(f, id) == f;
258 | // true
259 | ```
260 |
261 | 嘿，這不就是實數的單一律（identity property）阿！如過這還不夠清楚明瞭，就慢慢理解它的無用性吧。我們很快會到處使用 `id`，但現在我們暫時將它當作是個替代給定值得 function 。這對於撰寫 pointfree 的程式碼相當有用。
262 |
263 | 好了，以上就是類型和 function 的範疇。如果這是你第一次聽說這些概念，我猜測你現在還有些不瞭解，不懂範疇為何及為何有用。沒關係，本書都會借助這些知識。至於現在，本章的本行中，你至少可以認為它向我們提供了有關 compose 的知識－例如結合律與單一律。
264 |
265 | 除了這些，還有哪些範疇呢？當然，我們可以定義一個向量圖，以結點為 object，邊為態射，以路徑連接為組合。我們可以定義一個實數為 object，`>=` 為態射（事實上任何偏序（partial order）及全序（total order）都可成為一個範疇）。範疇的總數是無上限的，但是要達到本書的目的，我們只需關心上方所定義的範疇即可。到目前我們已經瀏覽了一些表面的東西，接著必須進入下一章節了。
266 |
267 |
268 | ## 總結
269 | Compose 將我們的的 function 連結在一起，就像一條管線一樣。資料也會在我們的應用程式中流動－畢竟 pure function 就是輸入對輸出，所以打破這個鏈結就是不遵重輸出，會讓我們的應用程式一無是處。
270 |
271 | 我們認為 compose 是高於其他原則的設計模式，這是因為 compose 讓我們的程式簡單而可讀。範疇學會在應用程式架構、模擬副作用及保證正確性方面扮演重要的角色。
272 |
273 | 現在我們已經有足夠的知識去進行一些實際的練習了，讓我們來撰寫一個範例應用程式。
274 |
275 | [第 6 章：範例應用程式](ch6.md)
276 |
277 | ## 練習
278 |
279 | ```js
280 | var _ = require('ramda');
281 | var accounting = require('accounting');
282 |
283 | // 範例資料
284 | var CARS = [{
285 | name: 'Ferrari FF',
286 | horsepower: 660,
287 | dollar_value: 700000,
288 | in_stock: true,
289 | }, {
290 | name: 'Spyker C12 Zagato',
291 | horsepower: 650,
292 | dollar_value: 648000,
293 | in_stock: false,
294 | }, {
295 | name: 'Jaguar XKR-S',
296 | horsepower: 550,
297 | dollar_value: 132000,
298 | in_stock: false,
299 | }, {
300 | name: 'Audi R8',
301 | horsepower: 525,
302 | dollar_value: 114200,
303 | in_stock: false,
304 | }, {
305 | name: 'Aston Martin One-77',
306 | horsepower: 750,
307 | dollar_value: 1850000,
308 | in_stock: true,
309 | }, {
310 | name: 'Pagani Huayra',
311 | horsepower: 700,
312 | dollar_value: 1300000,
313 | in_stock: false,
314 | }];
315 |
316 | // 練習 1：
317 | // ============
318 | // 使用 _.compose() 重寫以下的 function。提示： _.prop() 是 curry function。
319 | var isLastInStock = function(cars) {
320 | var last_car = _.last(cars);
321 | return _.prop('in_stock', last_car);
322 | };
323 |
324 | // 練習 2：
325 | // ============
326 | // 使用 _.compose()、 _.prop() 及 _.head() 來取得第一筆 car 的 name。
327 | var nameOfFirstCar = undefined;
328 |
329 |
330 | // 練習 3：
331 | // ============
332 | // 使用 helper function _average 來重構 averageDollarValue 使之為 compose function。
333 | var _average = function(xs) {
334 | return _.reduce(_.add, 0, xs) / xs.length;
335 | }; // <- 不需改動
336 |
337 | var averageDollarValue = function(cars) {
338 | var dollar_values = _.map(function(c) {
339 | return c.dollar_value;
340 | }, cars);
341 | return _average(dollar_values);
342 | };
343 |
344 |
345 | // 練習 4：
346 | // ============
347 | // 使用 compose 撰寫一個 function：sanitizeNames()，回傳一個 car 的 name 為全小寫及底線連接的列表：例如：sanitizeNames([{name: 'Ferrari FF', horsepower: 660, dollar_value: 700000, in_stock: true}]) //=> ['ferrari_ff']。
348 |
349 | var _underscore = _.replace(/\W+/g, '_'); //<-- leave this alone and use to sanitize
350 |
351 | var sanitizeNames = undefined;
352 |
353 |
354 | // 加分題 1：
355 | // ============
356 | // 使用 compose 重構 availablePrices。
357 |
358 | var availablePrices = function(cars) {
359 | var available_cars = _.filter(_.prop('in_stock'), cars);
360 | return available_cars.map(function(x) {
361 | return accounting.formatMoney(x.dollar_value);
362 | }).join(', ');
363 | };
364 |
365 |
366 | // 加分題 2：
367 | // ============
368 | // 重構使它 pointfree。提示: 你可以使用 _.flip()。
369 |
370 | var fastestCar = function(cars) {
371 | var sorted = _.sortBy(function(car) {
372 | return car.horsepower;
373 | }, cars);
374 | var fastest = _.last(sorted);
375 | return fastest.name + ' is the fastest';
376 | };
377 | ```
378 |
379 | [lodash-website]: https://lodash.com/
380 | [underscore-website]: http://underscorejs.org/
381 | [ramda-website]: http://ramdajs.com/
382 | [refactoring-book]: http://martinfowler.com/books/refactoring.html
383 | [extract-method-refactor]: http://refactoring.com/catalog/extractMethod.html
384 |
--------------------------------------------------------------------------------
/ch6.md:
--------------------------------------------------------------------------------
1 | # 第 6 章：範例應用程式
2 |
3 | ## 宣告式開發
4 |
5 | 從本章節開始，我們要開始轉變我們的觀念了，我們會停止告訴電腦該要怎麼去工作，而是透過撰寫規範來得到我們要的結果。我相信透過這種方式與無時無刻去關心所有程式碼細節相比，這會讓你感到輕鬆許多。
6 |
7 | 不同於命令式，宣告式意指我們將撰寫一些表達式的程式，而不是一步一步指示。
8 |
9 | 像是 SQL，就沒有「先做這個，再做那個」的命令。它有一個表達式來指定我們想要從哪個資料庫使用資料，我們不確定是如何執行的，要看表達式本身。當資料庫更新和 SQL 引擎優化，我們不需要改變我們查詢的方式。這是因為有許多方式來解析我們規範的表達式並得到相同的結果。
10 |
11 | 對於一些人來說，包含我自己，第一次很難掌握這種宣告式的概念，所讓我們列出一些範例來感受一下。
12 |
13 | ```js
14 | // 命令式
15 | var makes = [];
16 | for (var i = 0; i < cars.length; i++) {
17 | makes.push(cars[i].make);
18 | }
19 |
20 |
21 | // 宣告式
22 | var makes = cars.map(function(car) { return car.make; });
23 | ```
24 |
25 | 命令式第一次必須先實例化陣列。在執行後面的程式碼之前，直譯器必須先評估這個語句，然後才迭代整個 cars 的清單，在顯式的迭代中，手動增加計數器並顯示零碎的資訊給我們實在是不怎麼好。
26 |
27 | `map` 版本是一個表達式。它對執行的順序沒有要求。在 map function 迭代並回傳的陣列集合，對於指定**做什麼**而不是**怎麼做**有很大的自由度。因此，它完全是一個宣告式的程式。
28 |
29 | 除了更簡潔明瞭外，map function 還可以進行優化，這樣我們的應用程式的程式碼就不需要改變了。
30 |
31 | 對那些認為「對啊，但是使用命令式迴圈比較快」的人，我建議你先去了解關於 JIT 優化的相關程式碼。這裡有一個[非常棒的影片](https://www.youtube.com/watch?v=65-RbBwZQdU)，或許可以有一些啟發。
32 |
33 | 這裡是另一個範例。
34 |
35 | ```js
36 | // 命令式
37 | var authenticate = function(form) {
38 | var user = toUser(form);
39 | return logIn(user);
40 | };
41 |
42 | // 宣告式
43 | var authenticate = compose(logIn, toUser);
44 | ```
45 |
46 | 雖然命令式的版本不是絕對錯誤的，但還是像存在那種一步一步的硬編碼方式。`compose` 表達式只是簡單的指出一個事實：驗證是 `toUser` 和 `logIn` 兩個行為的組合。再者，宣告式的程式支援更新程式碼，使我們的應用程式可以成為一個高級的規範。
47 |
48 | 因為宣告式的程式不指定執行順序，所以適合運用在平行計算。它與 pure function 一起解釋了 functional programming 對於平行計算的未來是一個很好的選擇 - 我們真的不需要做什麼就能實現平行化的系統。
49 |
50 | ## 一個 FP 的 flickr
51 |
52 | 我們使用宣告式和可組合的方式來建立一個應用程式範例。我們現在還是會使到一些 side effects，但我們會把 side effects 降到最低，讓他與 pure function 的部份分離開來。我們要建立一個瀏覽器的 widget，從 flickr 上取得圖片並顯示。讓我們從 app 的 scaffolding 開始。這裡是 html 部份：
53 |
54 |
55 | ```html
56 |
57 |
58 |
59 |
60 |
61 |
62 |
63 |
64 | ```
65 |
66 | 這裡是 flickr.js 的 skeleton：
67 |
68 | ```js
69 | requirejs.config({
70 | paths: {
71 | ramda: 'https://cdnjs.cloudflare.com/ajax/libs/ramda/0.13.0/ramda.min',
72 | jquery: 'https://ajax.googleapis.com/ajax/libs/jquery/2.1.1/jquery.min'
73 | },
74 | });
75 |
76 | require([
77 | 'ramda',
78 | 'jquery',
79 | ],
80 | function(_, $) {
81 | var trace = _.curry(function(tag, x) {
82 | console.log(tag, x);
83 | return x;
84 | });
85 | // app 在此處
86 | });
87 | ```
88 |
89 | 這裡我們使用了 [ramda](http://ramdajs.com) 而不是 lodash 或其他的 library。它包含了 `compose`、`curry` 等等。我以前使用過 requirejs，或許看起來有點矯枉過正，但為了保持一致性，在本書我們會一直使用它。另外，我已經將 `trace` function 寫好，讓我們可以方便的 debug。
90 |
91 | 有點離題了，言歸正傳，我們的 app 需要做以下這四件事情：
92 |
93 | 1. 對於我們特定的搜尋條件來建構一個 url
94 | 2. 讓 flickr api 呼叫
95 | 3. 將回傳的 json 結果轉換成 html 的圖片
96 | 4. 將圖片放置在螢幕上
97 |
98 | 如上面所述，有兩個 impure 的行為。你看到了嗎？就是從 flickr api 取得資料和在螢幕上放置圖片。我們先來定義這兩個動作，這樣就可以隔離他們。
99 |
100 | ```js
101 | var Impure = {
102 | getJSON: _.curry(function(callback, url) {
103 | $.getJSON(url, callback);
104 | }),
105 |
106 | setHtml: _.curry(function(sel, html) {
107 | $(sel).html(html);
108 | })
109 | };
110 | ```
111 |
112 | 這裡我們簡單的將 jQuery 的方法包裝成 curry，這有便於幫助參數位置的交換。我已經使用了 `Impure` 的命名空間，這樣我們就知道這些 function 不安全。在之後的範例，我們將會讓這兩個 function 變為 pure function。
113 |
114 | 接下來我們必須建構一個 url 來傳送我們的 `Impure.getJson` function。
115 |
116 | ```js
117 | var url = function(term) {
118 | return 'https://api.flickr.com/services/feeds/photos_public.gne?tags=' +
119 | term + '&format=json&jsoncallback=?';
120 | };
121 | ```
122 |
123 | 使用 monoids（我們在之後會學習到）或 combinator 可以使用一些奇技淫巧讓 `url` function 成為 `pointfree` function。但是為了可讀性，我們還是選擇以普通非 pointfree 的方式拼接字串。
124 |
125 | 讓我們撰寫一個 app function 來發送呼叫，並將內容顯示在螢幕上。
126 |
127 | ```js
128 | var app = _.compose(Impure.getJSON(trace('response')), url);
129 |
130 | app('cats');
131 | ```
132 |
133 | 這會呼叫 `url` function，然後將字串傳送給 `getJSON` function，在某些部份上已經應用到了 `trace`。載入 app 後，從 api 呼叫的 response 會顯示在 console 上。
134 |
135 | 
136 |
137 | 我們想要從 json 來建構圖片。看起来 src 都在 `items` 陣列中的每個 `media` 物件的 `m` 屬性上。
138 |
139 | 不管如何，如果要取得這些巢狀的屬性，我們可以從 ramda 中使用一個很棒的通用 getter function 叫做 `_.prop()`。不過為了讓你了解這個 function 做了些什麼，我們先自己實現一個 prop：
140 |
141 | ```js
142 | var prop = _.curry(function(property, object) {
143 | return object[property];
144 | });
145 | ```
146 |
147 | 這實際上有點傻，我們只是使用 `[]` 語法來存取物件的屬性。讓我們使用它來取得我們的 src：
148 |
149 | ```js
150 | var mediaUrl = _.compose(_.prop('m'), _.prop('media'));
151 |
152 | var srcs = _.compose(_.map(mediaUrl), _.prop('items'));
153 | ```
154 |
155 | 一旦得到 `items`，我們必須使用 `map` 來提取每個 media 的 url。這樣就會得到一個 src 的陣列。讓我們將它加到 app 上，並將圖片顯示在螢幕上。
156 |
157 | ```js
158 | var renderImages = _.compose(Impure.setHtml('body'), srcs);
159 | var app = _.compose(Impure.getJSON(renderImages), url);
160 | ```
161 |
162 | 這裡所做的只不過是建立了一個組合，這個组合會呼叫 `srcs` function，並把回傳结果設定為 body 的 html。我們也把 `trace` 替換成了 `renderImages`，現在我們除了 render 原始的 json，會將我們的 src 直接顯示在我們的 body。
163 |
164 | 我們最後一步是將這些 src 轉換成真正的圖片。在大型應用程式中，我們使用像是 Handlebars 或 React 這樣的 template／dom library。但是對於這個應用程式來說，我們只需要一個 img 標籤，所以只要使用 jQuery 就可以了。
165 |
166 | ```js
167 | var img = function(url) {
168 | return $('
185 |
186 | 這裡是完成後的程式碼：
187 | ```js
188 | requirejs.config({
189 | paths: {
190 | ramda: 'https://cdnjs.cloudflare.com/ajax/libs/ramda/0.13.0/ramda.min',
191 | jquery: 'https://ajax.googleapis.com/ajax/libs/jquery/2.1.1/jquery.min',
192 | },
193 | });
194 |
195 | require([
196 | 'ramda',
197 | 'jquery',
198 | ],
199 | function(_, $) {
200 | ////////////////////////////////////////////
201 | // Utils
202 |
203 | var Impure = {
204 | getJSON: _.curry(function(callback, url) {
205 | $.getJSON(url, callback);
206 | }),
207 |
208 | setHtml: _.curry(function(sel, html) {
209 | $(sel).html(html);
210 | }),
211 | };
212 |
213 | var img = function(url) {
214 | return $('
6 |
7 | We've seen how to write programs which pipe data through a series of pure functions. They are declarative specifications of behaviour. But what about control flow, error handling, asynchronous actions, state and, dare I say, effects?! In this chapter, we will discover the foundation upon which all of these helpful abstractions are built.
8 |
9 | First we will create a container. This container must hold any type of value; a ziplock that holds only tapioca pudding is rarely useful. It will be an object, but we will not give it properties and methods in the OO sense. No, we will treat it like a treasure chest - a special box that cradles our valuable data.
10 |
11 | ```js
12 | var Container = function(x) {
13 | this.__value = x;
14 | }
15 |
16 | Container.of = function(x) { return new Container(x); };
17 | ```
18 |
19 | Here is our first container. We've thoughtfully named it `Container`. We will use `Container.of` as a constructor which saves us from having to write that god awful `new` keyword all over the place. There's more to the `of` function than meets the eye, but for now, think of it as the proper way to place values into our container.
20 |
21 | Let's examine our brand new box...
22 |
23 | ```js
24 | Container.of(3);
25 | //=> Container(3)
26 |
27 |
28 | Container.of('hotdogs');
29 | //=> Container("hotdogs")
30 |
31 |
32 | Container.of(Container.of({
33 | name: 'yoda',
34 | }));
35 | //=> Container(Container({name: "yoda" }))
36 | ```
37 |
38 | If you are using node, you will see `{__value: x}` even though we've got ourselves a `Container(x)`. Chrome will output the type properly, but no matter; as long as we understand what a `Container` looks like, we'll be fine. In some environments you can overwrite the `inspect` method if you'd like, but we will not be so thorough. For this book, we will write the conceptual output as if we'd overwritten `inspect` as it's much more instructive than `{__value: x}` for pedagogical as well as aesthetic reasons.
39 |
40 | Let's make a few things clear before we move on:
41 |
42 | * `Container` is an object with one property. Lots of containers just hold one thing, though they aren't limited to one. We've arbitrarily named its property `__value`.
43 |
44 | * The `__value` cannot be one specific type or our `Container` would hardly live up to the name.
45 |
46 | * Once data goes into the `Container` it stays there. We *could* get it out by using `.__value`, but that would defeat the purpose.
47 |
48 | The reasons we're doing this will become clear as a mason jar, but for now, bear with me.
49 |
50 | ## My First Functor
51 |
52 | Once our value, whatever it may be, is in the container, we'll need a way to run functions on it.
53 |
54 | ```js
55 | // (a -> b) -> Container a -> Container b
56 | Container.prototype.map = function(f) {
57 | return Container.of(f(this.__value));
58 | }
59 | ```
60 |
61 | Why, it's just like Array's famous `map`, except we have `Container a` instead of `[a]`. And it works essentially the same way:
62 |
63 | ```js
64 | Container.of(2).map(function(two) {
65 | return two + 2;
66 | });
67 | //=> Container(4)
68 |
69 |
70 | Container.of("flamethrowers").map(function(s) {
71 | return s.toUpperCase();
72 | });
73 | //=> Container("FLAMETHROWERS")
74 |
75 |
76 | Container.of("bombs").map(_.concat(' away')).map(_.prop('length'));
77 | //=> Container(10)
78 | ```
79 |
80 | We can work with our value without ever having to leave the `Container`. This is a remarkable thing. Our value in the `Container` is handed to the `map` function so we can fuss with it and afterward, returned to its `Container` for safe keeping. As a result of never leaving the `Container`, we can continue to `map` away, running functions as we please. We can even change the type as we go along as demonstrated in the latter of the three examples.
81 |
82 | Wait a minute, if we keep calling `map`, it appears to be some sort of composition! What mathematical magic is at work here? Well chaps, we've just discovered *Functors*.
83 |
84 | > A Functor is a type that implements `map` and obeys some laws
85 |
86 | Yes, *Functor* is simply an interface with a contract. We could have just as easily named it *Mappable*, but now, where's the *fun* in that? Functors come from category theory and we'll look at the maths in detail toward the end of the chapter, but for now, let's work on intuition and practical uses for this bizarrely named interface.
87 |
88 | What reason could we possibly have for bottling up a value and using `map` to get at it? The answer reveals itself if we choose a better question: What do we gain from asking our container to apply functions for us? Well, abstraction of function application. When we `map` a function, we ask the container type to run it for us. This is a very powerful concept, indeed.
89 |
90 | ## Schrödinger's Maybe
91 |
92 | 
93 |
94 | `Container` is fairly boring. In fact, it is usually called `Identity` and has about the same impact as our `id` function(again there is a mathematical connection we'll look at when the time is right). However, there are other functors, that is, container-like types that have a proper `map` function, which can provide useful behaviour whilst mapping. Let's define one now.
95 |
96 | ```js
97 | var Maybe = function(x) {
98 | this.__value = x;
99 | };
100 |
101 | Maybe.of = function(x) {
102 | return new Maybe(x);
103 | };
104 |
105 | Maybe.prototype.isNothing = function() {
106 | return (this.__value === null || this.__value === undefined);
107 | };
108 |
109 | Maybe.prototype.map = function(f) {
110 | return this.isNothing() ? Maybe.of(null) : Maybe.of(f(this.__value));
111 | };
112 | ```
113 |
114 | Now, `Maybe` looks a lot like `Container` with one minor change: it will first check to see if it has a value before calling the supplied function. This has the effect of side stepping those pesky nulls as we `map`(Note that this implementation is simplified for teaching).
115 |
116 | ```js
117 | Maybe.of('Malkovich Malkovich').map(match(/a/ig));
118 | //=> Maybe(['a', 'a'])
119 |
120 | Maybe.of(null).map(match(/a/ig));
121 | //=> Maybe(null)
122 |
123 | Maybe.of({
124 | name: 'Boris',
125 | }).map(_.prop('age')).map(add(10));
126 | //=> Maybe(null)
127 |
128 | Maybe.of({
129 | name: 'Dinah',
130 | age: 14,
131 | }).map(_.prop('age')).map(add(10));
132 | //=> Maybe(24)
133 | ```
134 |
135 | Notice our app doesn't explode with errors as we map functions over our null values. This is because `Maybe` will take care to check for a value each and every time it applies a function.
136 |
137 | This dot syntax is perfectly fine and functional, but for reasons mentioned in Part 1, we'd like to maintain our pointfree style. As it happens, `map` is fully equipped to delegate to whatever functor it receives:
138 |
139 | ```js
140 | // map :: Functor f => (a -> b) -> f a -> f b
141 | var map = curry(function(f, any_functor_at_all) {
142 | return any_functor_at_all.map(f);
143 | });
144 | ```
145 |
146 | This is delightful as we can carry on with composition per usual and `map` will work as expected. This is the case with ramda's `map` as well. We'll use dot notation when it's instructive and the pointfree version when it's convenient. Did you notice that? I've sneakily introduced extra notation into our type signature. The `Functor f =>` tells us that `f` must be a Functor. Not that difficult, but I felt I should mention it.
147 |
148 | ## Use cases
149 |
150 | In the wild, we'll typically see `Maybe` used in functions which might fail to return a result.
151 |
152 | ```js
153 | // safeHead :: [a] -> Maybe(a)
154 | var safeHead = function(xs) {
155 | return Maybe.of(xs[0]);
156 | };
157 |
158 | var streetName = compose(map(_.prop('street')), safeHead, _.prop('addresses'));
159 |
160 | streetName({
161 | addresses: [],
162 | });
163 | // Maybe(null)
164 |
165 | streetName({
166 | addresses: [{
167 | street: 'Shady Ln.',
168 | number: 4201,
169 | }],
170 | });
171 | // Maybe("Shady Ln.")
172 | ```
173 |
174 | `safeHead` is like our normal `_.head`, but with added type safety. A curious thing happens when `Maybe` is introduced into our code; we are forced to deal with those sneaky `null` values. The `safeHead` function is honest and up front about its possible failure - there's really nothing to be ashamed of - and so it returns a `Maybe` to inform us of this matter. We are more than merely *informed*, however, because we are forced to `map` to get at the value we want since it is tucked away inside the `Maybe` object. Essentially, this is a `null` check enforced by the `safeHead` function itself. We can now sleep better at night knowing a `null` value won't rear its ugly, decapitated head when we least expect it. APIs like this will upgrade a flimsy application from paper and tacks to wood and nails. They will guarantee safer software.
175 |
176 |
177 | Sometimes a function might return a `Maybe(null)` explicitly to signal failure. For instance:
178 |
179 | ```js
180 | // withdraw :: Number -> Account -> Maybe(Account)
181 | var withdraw = curry(function(amount, account) {
182 | return account.balance >= amount ?
183 | Maybe.of({
184 | balance: account.balance - amount,
185 | }) :
186 | Maybe.of(null);
187 | });
188 |
189 | // finishTransaction :: Account -> String
190 | var finishTransaction = compose(remainingBalance, updateLedger); // <- these composed functions are hypothetical, not implemented here...
191 |
192 | // getTwenty :: Account -> Maybe(String)
193 | var getTwenty = compose(map(finishTransaction), withdraw(20));
194 |
195 |
196 | getTwenty({
197 | balance: 200.00,
198 | });
199 | // Maybe("Your balance is $180.00")
200 |
201 | getTwenty({
202 | balance: 10.00,
203 | });
204 | // Maybe(null)
205 | ```
206 |
207 | `withdraw` will tip its nose at us and return `Maybe(null)` if we're short on cash. This function also communicates its fickleness and leaves us no choice, but to `map` everything afterwards. The difference is that the `null` was intentional here. Instead of a `Maybe(String)`, we get the `Maybe(null)` back to signal failure and our application effectively halts in its tracks. This is important to note: if the `withdraw` fails, then `map` will sever the rest of our computation since it doesn't ever run the mapped functions, namely `finishTransaction`. This is precisely the intended behaviour as we'd prefer not to update our ledger or show a new balance if we hadn't successfully withdrawn funds.
208 |
209 | ## Releasing the value
210 |
211 | One thing people often miss is that there will always be an end of the line; some effecting function that sends JSON along, or prints to the screen, or alters our filesystem, or what have you. We cannot deliver the output with `return`, we must run some function or another to send it out into the world. We can phrase it like a Zen Buddhist koan: "If a program has no observable effect, does it even run?". Does it run correctly for its own satisfaction? I suspect it merely burns some cycles and goes back to sleep...
212 |
213 | Our application's job is to retrieve, transform, and carry that data along until it's time to say goodbye and the function which does so may be mapped, thus the value needn't leave the warm womb of its container. Indeed, a common error is to try to remove the value from our `Maybe` one way or another as if the possible value inside will suddenly materialize and all will be forgiven. We must understand it may be a branch of code where our value is not around to live up to its destiny. Our code, much like Schrödinger's cat, is in two states at once and should maintain that fact until the final function. This gives our code a linear flow despite the logical branching.
214 |
215 | There is, however, an escape hatch. If we would rather return a custom value and continue on, we can use a little helper called `maybe`.
216 |
217 | ```js
218 | // maybe :: b -> (a -> b) -> Maybe a -> b
219 | var maybe = curry(function(x, f, m) {
220 | return m.isNothing() ? x : f(m.__value);
221 | });
222 |
223 | // getTwenty :: Account -> String
224 | var getTwenty = compose(
225 | maybe("You're broke!", finishTransaction), withdraw(20)
226 | );
227 |
228 |
229 | getTwenty({
230 | balance: 200.00,
231 | });
232 | // "Your balance is $180.00"
233 |
234 | getTwenty({
235 | balance: 10.00,
236 | });
237 | // "You're broke!"
238 | ```
239 |
240 | We will now either return a static value (of the same type that `finishTransaction` returns) or continue on merrily finishing up the transaction sans `Maybe`. With `maybe`, we are witnessing the equivalent of an `if/else` statement whereas with `map`, the imperative analog would be: `if (x !== null) { return f(x) }`.
241 |
242 | The introduction of `Maybe` can cause some initial discomfort. Users of Swift and Scala will know what I mean as it's baked right into the core libraries under the guise of `Option(al)`. When pushed to deal with `null` checks all the time (and there are times we know with absolute certainty the value exists), most people can't help, but feel it's a tad laborious. However, with time, it will become second nature and you'll likely appreciate the safety. After all, most of the time it will prevent cut corners and save our hides.
243 |
244 | Writing unsafe software is like taking care to paint each egg with pastels before hurling it into traffic; like building a retirement home with materials warned against by three little pigs. It will do us well to put some safety into our functions and `Maybe` helps us do just that.
245 |
246 | I'd be remiss if I didn't mention that the "real" implementation will split `Maybe` into two types: one for something and the other for nothing. This allows us to obey parametricity in `map` so values like `null` and `undefined` can still be mapped over and the universal qualification of the value in a functor will be respected. You'll often see types like `Some(x) / None` or `Just(x) / Nothing` instead of a `Maybe` that does a `null` check on its value.
247 |
248 | ## Pure Error Handling
249 |
250 | 
251 |
252 | It may come as a shock, but `throw/catch` is not very pure. When an error is thrown, instead of returning an output value, we sound the alarms! The function attacks, spewing thousands of 0's and 1's like shields & spears in an electric battle against our intruding input. With our new friend `Either`, we can do better than to declare war on input, we can respond with a polite message. Let's take a look:
253 |
254 | ```js
255 | var Left = function(x) {
256 | this.__value = x;
257 | };
258 |
259 | Left.of = function(x) {
260 | return new Left(x);
261 | };
262 |
263 | Left.prototype.map = function(f) {
264 | return this;
265 | };
266 |
267 | var Right = function(x) {
268 | this.__value = x;
269 | };
270 |
271 | Right.of = function(x) {
272 | return new Right(x);
273 | };
274 |
275 | Right.prototype.map = function(f) {
276 | return Right.of(f(this.__value));
277 | }
278 | ```
279 |
280 | `Left` and `Right` are two subclasses of an abstract type we call `Either`. I've skipped the ceremony of creating the `Either` superclass as we won't ever use it, but it's good to be aware. Now then, there's nothing new here besides the two types. Let's see how they act:
281 |
282 | ```js
283 | Right.of('rain').map(function(str) {
284 | return 'b' + str;
285 | });
286 | // Right('brain')
287 |
288 | Left.of('rain').map(function(str) {
289 | return 'b' + str;
290 | });
291 | // Left('rain')
292 |
293 | Right.of({
294 | host: 'localhost',
295 | port: 80,
296 | }).map(_.prop('host'));
297 | // Right('localhost')
298 |
299 | Left.of('rolls eyes...').map(_.prop('host'));
300 | // Left('rolls eyes...')
301 | ```
302 |
303 | `Left` is the teenagery sort and ignores our request to `map` over it. `Right` will work just like `Container` (a.k.a Identity). The power comes from the ability to embed an error message within the `Left`.
304 |
305 | Suppose we have a function that might not succeed. How about we calculate an age from a birth date. We could use `Maybe(null)` to signal failure and branch our program, however, that doesn't tell us much. Perhaps, we'd like to know why it failed. Let's write this using `Either`.
306 |
307 | ```js
308 | var moment = require('moment');
309 |
310 | // getAge :: Date -> User -> Either(String, Number)
311 | var getAge = curry(function(now, user) {
312 | var birthdate = moment(user.birthdate, 'YYYY-MM-DD');
313 | if (!birthdate.isValid()) return Left.of('Birth date could not be parsed');
314 | return Right.of(now.diff(birthdate, 'years'));
315 | });
316 |
317 | getAge(moment(), {
318 | birthdate: '2005-12-12',
319 | });
320 | // Right(9)
321 |
322 | getAge(moment(), {
323 | birthdate: '20010704',
324 | });
325 | // Left('Birth date could not be parsed')
326 | ```
327 |
328 | Now, just like `Maybe(null)`, we are short circuiting our app when we return a `Left`. The difference, is now we have a clue as to why our program has derailed. Something to notice is that we return `Either(String, Number)`, which holds a `String` as its left value and a `Number` as its `Right`. This type signature is a bit informal as we haven't taken the time to define an actual `Either` superclass, however, we learn a lot from the type. It informs us that we're either getting an error message or the age back.
329 |
330 | ```js
331 | // fortune :: Number -> String
332 | var fortune = compose(concat('If you survive, you will be '), add(1));
333 |
334 | // zoltar :: User -> Either(String, _)
335 | var zoltar = compose(map(console.log), map(fortune), getAge(moment()));
336 |
337 | zoltar({
338 | birthdate: '2005-12-12',
339 | });
340 | // 'If you survive, you will be 10'
341 | // Right(undefined)
342 |
343 | zoltar({
344 | birthdate: 'balloons!',
345 | });
346 | // Left('Birth date could not be parsed')
347 | ```
348 |
349 | When the `birthdate` is valid, the program outputs its mystical fortune to the screen for us to behold. Otherwise, we are handed a `Left` with the error message plain as day though still tucked away in its container. That acts just as if we'd thrown an error, but in a calm, mild manner fashion as opposed to losing its temper and screaming like a child when something goes wrong.
350 |
351 | In this example, we are logically branching our control flow depending on the validity of the birth date, yet it reads as one linear motion from right to left rather than climbing through the curly braces of a conditional statement. Usually, we'd move the `console.log` out of our `zoltar` function and `map` it at the time of calling, but it's helpful to see how the `Right` branch differs. We use `_` in the right branch's type signature to indicate it's a value that should be ignored(In some browsers you have to use `console.log.bind(console)` to use it first class).
352 |
353 | I'd like to take this opportunity to point out something you may have missed: `fortune`, despite its use with `Either` in this example, is completely ignorant of any functors milling about. This was also the case with `finishTransaction` in the previous example. At the time of calling, a function can be surrounded by `map`, which transforms it from a non-functory function to a functory one, in informal terms. We call this process *lifting*. Functions tend to be better off working with normal data types rather than container types, then *lifted* into the right container as deemed necessary. This leads to simpler, more reusable functions that can be altered to work with any functor on demand.
354 |
355 | `Either` is great for casual errors like validation as well as more serious, stop the show errors like missing files or broken sockets. Try replacing some of the `Maybe` examples with `Either` to give better feedback.
356 |
357 | Now, I can't help, but feel I've done `Either` a disservice by introducing it as merely a container for error messages. It captures logical disjunction (a.k.a `||`) in a type. It also encodes the idea of a *Coproduct* from category theory, which won't be touched on in this book, but is well worth reading up on as there's properties to be exploited. It is the canonical sum type (or disjoint union of sets) because its amount of possible inhabitants is the sum of the two contained types(I know that's a bit hand wavy so here's a [great article](https://www.fpcomplete.com/school/to-infinity-and-beyond/pick-of-the-week/sum-types). There are many things `Either` can be, but as a functor, it is used for its error handling.
358 |
359 | Just like with `Maybe`, we have little `either`, which behaves similarly, but takes two functions instead of one and a static value. Each function should return the same type:
360 |
361 | ```js
362 | // either :: (a -> c) -> (b -> c) -> Either a b -> c
363 | var either = curry(function(f, g, e) {
364 | switch (e.constructor) {
365 | case Left:
366 | return f(e.__value);
367 | case Right:
368 | return g(e.__value);
369 | }
370 | });
371 |
372 | // zoltar :: User -> _
373 | var zoltar = compose(console.log, either(id, fortune), getAge(moment()));
374 |
375 | zoltar({
376 | birthdate: '2005-12-12',
377 | });
378 | // "If you survive, you will be 10"
379 | // undefined
380 |
381 | zoltar({
382 | birthdate: 'balloons!',
383 | });
384 | // "Birth date could not be parsed"
385 | // undefined
386 | ```
387 |
388 | Finally, a use for that mysterious `id` function. It simply parrots back the value in the `Left` to pass the error message to `console.log`. We've made our fortune telling app more robust by enforcing error handling from within `getAge`. We either slap the user with a hard truth like a high five from a palm reader or we carry on with our process. And with that, we're ready to move on to an entirely different type of functor.
389 |
390 | ## Old McDonald had Effects...
391 |
392 | 
393 |
394 | In our chapter about purity we saw a peculiar example of a pure function. This function contained a side-effect, but we dubbed it pure by wrapping its action in another function. Here's another example of this:
395 |
396 | ```js
397 | // getFromStorage :: String -> (_ -> String)
398 | var getFromStorage = function(key) {
399 | return function() {
400 | return localStorage[key];
401 | };
402 | };
403 | ```
404 |
405 | Had we not surrounded its guts in another function, `getFromStorage` would vary its output depending on external circumstance. With the sturdy wrapper in place, we will always get the same output per input: a function that, when called, will retrieve a particular item from `localStorage`. And just like that (maybe throw in a few Hail Mary's) we've cleared our conscience and all is forgiven.
406 |
407 | Except, this isn't particularly useful now is it. Like a collectible action figure in its original packaging, we can't actually play with it. If only there were a way to reach inside of the container and get at its contents... Enter `IO`.
408 |
409 | ```js
410 | var IO = function(f) {
411 | this.__value = f;
412 | };
413 |
414 | IO.of = function(x) {
415 | return new IO(function() {
416 | return x;
417 | });
418 | };
419 |
420 | IO.prototype.map = function(f) {
421 | return new IO(_.compose(f, this.__value));
422 | };
423 | ```
424 |
425 | `IO` differs from the previous functors in that the `__value` is always a function. We don't think of its `__value` as a function, however - that is an implementation detail and we best ignore it. What is happening is exactly what we saw with the `getFromStorage` example: `IO` delays the impure action by capturing it in a function wrapper. As such, we think of `IO` as containing the return value of the wrapped action and not the wrapper itself. This is apparent in the `of` function: we have an `IO(x)`, the `IO(function(){ return x })` is just necessary to avoid evaluation.
426 |
427 | Let's see it in use:
428 |
429 | ```js
430 | // io_window :: IO Window
431 | var io_window = new IO(function() {
432 | return window;
433 | });
434 |
435 | io_window.map(function(win) {
436 | return win.innerWidth;
437 | });
438 | // IO(1430)
439 |
440 | io_window.map(_.prop('location')).map(_.prop('href')).map(_.split('/'));
441 | // IO(["http:", "", "localhost:8000", "blog", "posts"])
442 |
443 |
444 | // $ :: String -> IO [DOM]
445 | var $ = function(selector) {
446 | return new IO(function() {
447 | return document.querySelectorAll(selector);
448 | });
449 | };
450 |
451 | $('#myDiv').map(head).map(function(div) {
452 | return div.innerHTML;
453 | });
454 | // IO('I am some inner html')
455 | ```
456 |
457 | Here, `io_window` is an actual `IO` that we can `map` over straight away, whereas `$` is a function that returns an `IO` after its called. I've written out the *conceptual* return values to better express the `IO`, though, in reality, it will always be `{ __value: [Function] }`. When we `map` over our `IO`, we stick that function at the end of a composition which, in turn, becomes the new `__value` and so on. Our mapped functions do not run, they get tacked on the end of a computation we're building up, function by function, like carefully placing dominoes that we don't dare tip over. The result is reminiscent of Gang of Four's command pattern or a queue.
458 |
459 | Take a moment to channel your functor intuition. If we see past the implementation details, we should feel right at home mapping over any container no matter its quirks or idiosyncrasies. We have the functor laws, which we will explore toward the end of the chapter, to thank for this pseudo-psychic power. At any rate, we can finally play with impure values without sacrificing our precious purity.
460 |
461 | Now, we've caged the beast, but we'll still have to set it free at some point. Mapping over our `IO` has built up a mighty impure computation and running it is surely going to disturb the peace. So where and when can we pull the trigger? Is it even possible to run our `IO` and still wear white at our wedding? The answer is yes, if we put the onus on the calling code. Our pure code, despite the nefarious plotting and scheming, maintains its innocence and it's the caller who gets burdened with the responsibility of actually running the effects. Let's see an example to make this concrete.
462 |
463 | ```js
464 |
465 | ////// Our pure library: lib/params.js ///////
466 |
467 | // url :: IO String
468 | var url = new IO(function() {
469 | return window.location.href;
470 | });
471 |
472 | // toPairs = String -> [[String]]
473 | var toPairs = compose(map(split('=')), split('&'));
474 |
475 | // params :: String -> [[String]]
476 | var params = compose(toPairs, last, split('?'));
477 |
478 | // findParam :: String -> IO Maybe [String]
479 | var findParam = function(key) {
480 | return map(compose(Maybe.of, filter(compose(eq(key), head)), params), url);
481 | };
482 |
483 | ////// Impure calling code: main.js ///////
484 |
485 | // run it by calling __value()!
486 | findParam("searchTerm").__value();
487 | // Maybe([['searchTerm', 'wafflehouse']])
488 | ```
489 |
490 | Our library keeps its hands clean by wrapping `url` in an `IO` and passing the buck to the caller. You might have also noticed that we have stacked our containers; it's perfectly reasonable to have a `IO(Maybe([x]))`, which is three functors deep(`Array` is most definitely a mappable container type) and exceptionally expressive.
491 |
492 | There's something that's been bothering me and we should rectify it immediately: `IO`'s `__value` isn't really its contained value, nor is it a private property as the underscore prefix suggests. It is the pin in the grenade and it is meant to be pulled by a caller in the most public of ways. Let's rename this property to `unsafePerformIO` to remind our users of its volatility.
493 |
494 | ```js
495 | var IO = function(f) {
496 | this.unsafePerformIO = f;
497 | };
498 |
499 | IO.prototype.map = function(f) {
500 | return new IO(_.compose(f, this.unsafePerformIO));
501 | };
502 | ```
503 |
504 | There, much better. Now our calling code becomes `findParam("searchTerm").unsafePerformIO()`, which is clear as day to users (and readers) of the application.
505 |
506 | `IO` will be a loyal companion, helping us tame those feral impure actions. Next, we'll see a type similar in spirit, but has a drastically different use case.
507 |
508 |
509 | ## Asynchronous Tasks
510 |
511 | Callbacks are the narrowing spiral staircase to hell. They are control flow as designed by M.C. Escher. With each nested callback squeezed in between the jungle gym of curly braces and parenthesis, they feel like limbo in an oubliette(how low can we go!). I'm getting claustrophobic chills just thinking about them. Not to worry, we have a much better way of dealing with asynchronous code and it starts with an "F".
512 |
513 | The internals are a bit too complicated to spill out all over the page here so we will use `Data.Task` (previously `Data.Future`) from Quildreen Motta's fantastic [Folktale](http://folktalejs.org/). Behold some example usage:
514 |
515 | ```js
516 | // Node readfile example:
517 | //=======================
518 |
519 | var fs = require('fs');
520 |
521 | // readFile :: String -> Task Error String
522 | var readFile = function(filename) {
523 | return new Task(function(reject, result) {
524 | fs.readFile(filename, 'utf-8', function(err, data) {
525 | err ? reject(err) : result(data);
526 | });
527 | });
528 | };
529 |
530 | readFile('metamorphosis').map(split('\n')).map(head);
531 | // Task("One morning, as Gregor Samsa was waking up from anxious dreams, he discovered that
532 | // in bed he had been changed into a monstrous verminous bug.")
533 |
534 |
535 | // jQuery getJSON example:
536 | //========================
537 |
538 | // getJSON :: String -> {} -> Task Error JSON
539 | var getJSON = curry(function(url, params) {
540 | return new Task(function(reject, result) {
541 | $.getJSON(url, params, result).fail(reject);
542 | });
543 | });
544 |
545 | getJSON('/video', {
546 | id: 10,
547 | }).map(_.prop('title'));
548 | // Task("Family Matters ep 15")
549 |
550 | // We can put normal, non futuristic values inside as well
551 | Task.of(3).map(function(three) {
552 | return three + 1,
553 | });
554 | // Task(4)
555 | ```
556 |
557 | The functions I'm calling `reject` and `result` are our error and success callbacks, respectively. As you can see, we simply `map` over the `Task` to work on the future value as if it was right there in our grasp. By now `map` should be old hat.
558 |
559 | If you're familiar with promises, you might recognize the function `map` as `then` with `Task` playing the role of our promise. Don't fret if you aren't familiar with promises, we won't be using them anyhow because they are not pure, but the analogy holds nonetheless.
560 |
561 | Like `IO`, `Task` will patiently wait for us to give it the green light before running. In fact, because it waits for our command, `IO` is effectively subsumed by `Task` for all things asynchronous; `readFile` and `getJSON` don't require an extra `IO` container to be pure. What's more, `Task` works in a similar fashion when we `map` over it: we're placing instructions for the future like a chore chart in a time capsule - an act of sophisticated technological procrastination.
562 |
563 | To run our `Task`, we must call the method `fork`. This works like `unsafePerformIO`, but as the name suggests, it will fork our process and evaluation continues on without blocking our thread. This can be implemented in numerous ways with threads and such, but here it acts as a normal async call would and the big wheel of the event loop keeps on turning. Let's look at `fork`:
564 |
565 | ```js
566 | // Pure application
567 | //=====================
568 | // blogTemplate :: String
569 |
570 | // blogPage :: Posts -> HTML
571 | var blogPage = Handlebars.compile(blogTemplate);
572 |
573 | // renderPage :: Posts -> HTML
574 | var renderPage = compose(blogPage, sortBy('date'));
575 |
576 | // blog :: Params -> Task Error HTML
577 | var blog = compose(map(renderPage), getJSON('/posts'));
578 |
579 |
580 | // Impure calling code
581 | //=====================
582 | blog({}).fork(
583 | function(error) {
584 | $("#error").html(error.message);
585 | },
586 | function(page) {
587 | $("#main").html(page);
588 | }
589 | );
590 |
591 | $('#spinner').show();
592 | ```
593 |
594 | Upon calling `fork`, the `Task` hurries off to find some posts and render the page. Meanwhile, we show a spinner since `fork` does not wait for a response. Finally, we will either display an error or render the page onto the screen depending if the `getJSON` call succeeded or not.
595 |
596 | Take a moment to consider how linear the control flow is here. We just read bottom to top, right to left even though the program will actually jump around a bit during execution. This makes reading and reasoning about our application simpler than having to bounce between callbacks and error handling blocks.
597 |
598 | Goodness, would you look at that, `Task` has also swallowed up `Either`! It must do so in order to handle futuristic failures since our normal control flow does not apply in the async world. This is all well and good as it provides sufficient and pure error handling out of the box.
599 |
600 | Even with `Task`, our `IO` and `Either` functors are not out of a job. Bear with me on a quick example that leans toward the more complex and hypothetical side, but is useful for illustrative purposes.
601 |
602 | ```js
603 | // Postgres.connect :: Url -> IO DbConnection
604 | // runQuery :: DbConnection -> ResultSet
605 | // readFile :: String -> Task Error String
606 |
607 | // Pure application
608 | //=====================
609 |
610 | // dbUrl :: Config -> Either Error Url
611 | var dbUrl = function(c) {
612 | return (c.uname && c.pass && c.host && c.db)
613 | ? Right.of('db:pg://'+c.uname+':'+c.pass+'@'+c.host+'5432/'+c.db)
614 | : Left.of(Error('Invalid config!'));
615 | }
616 |
617 | // connectDb :: Config -> Either Error (IO DbConnection)
618 | var connectDb = compose(map(Postgres.connect), dbUrl);
619 |
620 | // getConfig :: Filename -> Task Error (Either Error (IO DbConnection))
621 | var getConfig = compose(map(compose(connectDb, JSON.parse)), readFile);
622 |
623 |
624 | // Impure calling code
625 | //=====================
626 | getConfig('db.json').fork(
627 | logErr('couldn\'t read file'), either(console.log, map(runQuery))
628 | );
629 | ```
630 |
631 | In this example, we still make use of `Either` and `IO` from within the success branch of `readFile`. `Task` takes care of the impurities of reading a file asynchronously, but we still deal with validating the config with `Either` and wrangling the db connection with `IO`. So you see, we're still in business for all things synchronous.
632 |
633 | I could go on, but that's all there is to it. Simple as `map`.
634 |
635 | In practice, you'll likely have multiple asynchronous tasks in one workflow and we haven't yet acquired the full container APIs to tackle this scenario. Not to worry, we'll look at monads and such soon, but first, we must examine the maths that make this all possible.
636 |
637 |
638 | ## A Spot of Theory
639 |
640 | As mentioned before, functors come from category theory and satisfy a few laws. Let's first explore these useful properties.
641 |
642 | ```js
643 | // identity
644 | map(id) === id;
645 |
646 | // composition
647 | compose(map(f), map(g)) === map(compose(f, g));
648 | ```
649 |
650 | The *identity* law is simple, but important. These laws are runnable bits of code so we can try them on our own functors to validate their legitimacy.
651 |
652 | ```js
653 | var idLaw1 = map(id);
654 | var idLaw2 = id;
655 |
656 | idLaw1(Container.of(2));
657 | //=> Container(2)
658 |
659 | idLaw2(Container.of(2));
660 | //=> Container(2)
661 | ```
662 |
663 | You see, they are equal. Next let's look at composition.
664 |
665 | ```js
666 | var compLaw1 = compose(map(concat(' world')), map(concat(' cruel')));
667 | var compLaw2 = map(compose(concat(' world'), concat(' cruel')));
668 |
669 | compLaw1(Container.of('Goodbye'));
670 | //=> Container(' world cruelGoodbye')
671 |
672 | compLaw2(Container.of('Goodbye'));
673 | //=> Container(' world cruelGoodbye')
674 | ```
675 |
676 | In category theory, functors take the objects and morphisms of a category and map them to a different category. By definition, this new category must have an identity and the ability to compose morphisms, but we needn't check because the aforementioned laws ensure these are preserved.
677 |
678 | Perhaps our definition of a category is still a bit fuzzy. You can think of a category as a network of objects with morphisms that connect them. So a functor would map the one category to the other without breaking the network. If an object `a` is in our source category `C`, when we map it to category `D` with functor `F`, we refer to that object as `F a` (If you put it together what does that spell?!). Perhaps, it's better to look at a diagram:
679 |
680 | 
681 |
682 | For instance, `Maybe` maps our category of types and functions to a category where each object may not exist and each morphism has a `null` check. We accomplish this in code by surrounding each function with `map` and each type with our functor. We know that each of our normal types and functions will continue to compose in this new world. Technically, each functor in our code maps to a sub category of types and functions which makes all functors a particular brand called endofunctors, but for our purposes, we'll think of it as a different category.
683 |
684 | We can also visualize the mapping of a morphism and its corresponding objects with this diagram:
685 |
686 | 
687 |
688 | In addition to visualizing the mapped morphism from one category to another under the functor `F`, we see that the diagram commutes, which is to say, if you follow the arrows each route produces the same result. The different routes means different behavior, but we always end at the same type. This formalism gives us principled ways to reason about our code - we can boldly apply formulas without having to parse and examine each individual scenario. Let's take a concrete example.
689 |
690 | ```js
691 | // topRoute :: String -> Maybe String
692 | var topRoute = compose(Maybe.of, reverse);
693 |
694 | // bottomRoute :: String -> Maybe String
695 | var bottomRoute = compose(map(reverse), Maybe.of);
696 |
697 |
698 | topRoute('hi');
699 | // Maybe('ih')
700 |
701 | bottomRoute('hi');
702 | // Maybe('ih')
703 | ```
704 |
705 | Or visually:
706 |
707 | 
708 |
709 | We can instantly see and refactor code based on properties held by all functors.
710 |
711 | Functors can stack:
712 |
713 | ```js
714 | var nested = Task.of([Right.of('pillows'), Left.of('no sleep for you')]);
715 |
716 | map(map(map(toUpperCase)), nested);
717 | // Task([Right('PILLOWS'), Left('no sleep for you')])
718 | ```
719 |
720 | What we have here with `nested` is a future array of elements that might be errors. We `map` to peel back each layer and run our function on the elements. We see no callbacks, if/else's, or for loops; just an explicit context. We do, however, have to `map(map(map(f)))`. We can instead compose functors. You heard me correctly:
721 |
722 | ```js
723 | var Compose = function(f_g_x) {
724 | this.getCompose = f_g_x;
725 | };
726 |
727 | Compose.prototype.map = function(f) {
728 | return new Compose(map(map(f), this.getCompose));
729 | };
730 |
731 | var tmd = Task.of(Maybe.of('Rock over London'));
732 |
733 | var ctmd = new Compose(tmd);
734 |
735 | map(concat(', rock on, Chicago'), ctmd);
736 | // Compose(Task(Maybe('Rock over London, rock on, Chicago')))
737 |
738 | ctmd.getCompose;
739 | // Task(Maybe('Rock over London, rock on, Chicago'))
740 | ```
741 |
742 | There, one `map`. Functor composition is associative and earlier, we defined `Container`, which is actually called the `Identity` functor. If we have identity and associative composition we have a category. This particular category has categories as objects and functors as morphisms, which is enough to make one's brain perspire. We won't delve too far into this, but it's nice to appreciate the architectural implications or even just the simple abstract beauty in the pattern.
743 |
744 |
745 | ## In Summary
746 |
747 | We've seen a few different functors, but there are infinitely many. Some notable omissions are iterable data structures like trees, lists, maps, pairs, you name it. eventstreams and observables are both functors. Others can be for encapsulation or even just type modelling. Functors are all around us and we'll use them extensively throughout the book.
748 |
749 | What about calling a function with multiple functor arguments? How about working with an order sequence of impure or async actions? We haven't yet acquired the full tool set for working in this boxed up world. Next, we'll cut right to the chase and look at monads.
750 |
751 | [Chapter 9: Monadic Onions](ch9.md)
752 |
753 | ## Exercises
754 |
755 | ```js
756 | require('../../support');
757 | var Task = require('data.task');
758 | var _ = require('ramda');
759 |
760 | // Exercise 1
761 | // ==========
762 | // Use _.add(x,y) and _.map(f,x) to make a function that increments a value
763 | // inside a functor.
764 |
765 | var ex1 = undefined;
766 |
767 |
768 |
769 | // Exercise 2
770 | // ==========
771 | // Use _.head to get the first element of the list.
772 | var xs = Identity.of(['do', 'ray', 'me', 'fa', 'so', 'la', 'ti', 'do']);
773 |
774 | var ex2 = undefined;
775 |
776 |
777 |
778 | // Exercise 3
779 | // ==========
780 | // Use safeProp and _.head to find the first initial of the user.
781 | var safeProp = _.curry(function(x, o) {
782 | return Maybe.of(o[x]);
783 | });
784 |
785 | var user = {
786 | id: 2,
787 | name: 'Albert',
788 | };
789 |
790 | var ex3 = undefined;
791 |
792 |
793 | // Exercise 4
794 | // ==========
795 | // Use Maybe to rewrite ex4 without an if statement.
796 |
797 | var ex4 = function(n) {
798 | if (n) {
799 | return parseInt(n);
800 | }
801 | };
802 |
803 | var ex4 = undefined;
804 |
805 |
806 |
807 | // Exercise 5
808 | // ==========
809 | // Write a function that will getPost then toUpperCase the post's title.
810 |
811 | // getPost :: Int -> Future({id: Int, title: String})
812 | var getPost = function(i) {
813 | return new Task(function(rej, res) {
814 | setTimeout(function() {
815 | res({
816 | id: i,
817 | title: 'Love them futures',
818 | });
819 | }, 300);
820 | });
821 | };
822 |
823 | var ex5 = undefined;
824 |
825 |
826 |
827 | // Exercise 6
828 | // ==========
829 | // Write a function that uses checkActive() and showWelcome() to grant access
830 | // or return the error.
831 |
832 | var showWelcome = _.compose(_.add('Welcome '), _.prop('name'));
833 |
834 | var checkActive = function(user) {
835 | return user.active ? Right.of(user) : Left.of('Your account is not active');
836 | };
837 |
838 | var ex6 = undefined;
839 |
840 |
841 |
842 | // Exercise 7
843 | // ==========
844 | // Write a validation function that checks for a length > 3. It should return
845 | // Right(x) if it is greater than 3 and Left("You need > 3") otherwise.
846 |
847 | var ex7 = function(x) {
848 | return undefined; // <--- write me. (don't be pointfree)
849 | };
850 |
851 |
852 |
853 | // Exercise 8
854 | // ==========
855 | // Use ex7 above and Either as a functor to save the user if they are valid or
856 | // return the error message string. Remember either's two arguments must return
857 | // the same type.
858 |
859 | var save = function(x) {
860 | return new IO(function() {
861 | console.log('SAVED USER!');
862 | return x + '-saved';
863 | });
864 | };
865 |
866 | var ex8 = undefined;
867 | ```
868 |
--------------------------------------------------------------------------------
/ch9.md:
--------------------------------------------------------------------------------
1 | # Chapter 9: Monadic Onions
2 |
3 | ## Pointy Functor Factory
4 |
5 | Before we go any further, I have a confession to make: I haven't been fully honest about that `of` method we've placed on each of our types. Turns out, it is not there to avoid the `new` keyword, but rather to place values in what's called a *default minimal context*. Yes, `of` does not actually take the place of a constructor - it is part of an important interface we call *Pointed*.
6 |
7 | > A *pointed functor* is a functor with an `of` method
8 |
9 | What's important here is the ability to drop any value in our type and start mapping away.
10 |
11 | ```js
12 | IO.of('tetris').map(concat(' master'));
13 | // IO('tetris master')
14 |
15 | Maybe.of(1336).map(add(1));
16 | // Maybe(1337)
17 |
18 | Task.of({
19 | id: 2,
20 | }).map(_.prop('id'));
21 | // Task(2)
22 |
23 | Either.of('The past, present and future walk into a bar...').map(
24 | concat('it was tense.')
25 | );
26 | // Right('The past, present and future walk into a bar...it was tense.')
27 | ```
28 |
29 | If you recall, `IO` and `Task`'s constructors expect a function as their argument, but `Maybe` and `Either` do not. The motivation for this interface is a common, consistent way to place a value into our functor without the complexities and specific demands of constructors. The term "default minimal context" lacks precision, yet captures the idea well: we'd like to lift any value in our type and `map` away per usual with the expected behaviour of whichever functor.
30 |
31 | One important correction I must make at this point, pun intended, is that `Left.of` doesn't make any sense. Each functor must have one way to place a value inside it and with `Either`, that's `new Right(x)`. We define `of` using `Right` because if our type *can* `map`, it *should* `map`. Looking at the examples above, we should have an intuition about how `of` will usually work and `Left` breaks that mold.
32 |
33 | You may have heard of functions such as `pure`, `point`, `unit`, and `return`. These are various monikers for our `of` method, international function of mystery. `of` will become important when we start using monads because, as we will see, it's our responsibility to place values back into the type manually.
34 |
35 | To avoid the `new` keyword, there are several standard JavaScript tricks or libraries so let's use them and use `of` like a responsible adult from here on out. I recommend using functor instances from `folktale`, `ramda` or `fantasy-land` as they provide the correct `of` method as well as nice constructors that don't rely on `new`.
36 |
37 |
38 | ## Mixing Metaphors
39 |
40 | 
41 |
42 | You see, in addition to space burritos (if you've heard the rumors), monads are like onions. Allow me to demonstrate with a common situation:
43 |
44 | ```js
45 | // Support
46 | // ===========================
47 | var fs = require('fs');
48 |
49 | // readFile :: String -> IO String
50 | var readFile = function(filename) {
51 | return new IO(function() {
52 | return fs.readFileSync(filename, 'utf-8');
53 | });
54 | };
55 |
56 | // print :: String -> IO String
57 | var print = function(x) {
58 | return new IO(function() {
59 | console.log(x);
60 | return x;
61 | });
62 | };
63 |
64 | // Example
65 | // ===========================
66 | // cat :: String -> IO (IO String)
67 | var cat = compose(map(print), readFile);
68 |
69 | cat('.git/config');
70 | // IO(IO('[core]\nrepositoryformatversion = 0\n'))
71 | ```
72 |
73 | What we've got here is an `IO` trapped inside another `IO` because `print` introduced a second `IO` during our `map`. To continue working with our string, we must `map(map(f))` and to observe the effect, we must `unsafePerformIO().unsafePerformIO()`.
74 |
75 | ```js
76 | // cat :: String -> IO (IO String)
77 | var cat = compose(map(print), readFile);
78 |
79 | // catFirstChar :: String -> IO (IO String)
80 | var catFirstChar = compose(map(map(head)), cat);
81 |
82 | catFirstChar(".git/config");
83 | // IO(IO("["))
84 | ```
85 |
86 | While it is nice to see that we have two effects packaged up and ready to go in our application, it feels a bit like working in two hazmat suits and we end up with an uncomfortably awkward API. Let's look at another situation:
87 |
88 | ```js
89 | // safeProp :: Key -> {Key: a} -> Maybe a
90 | var safeProp = curry(function(x, obj) {
91 | return new Maybe(obj[x]);
92 | });
93 |
94 | // safeHead :: [a] -> Maybe a
95 | var safeHead = safeProp(0);
96 |
97 | // firstAddressStreet :: User -> Maybe (Maybe (Maybe Street) )
98 | var firstAddressStreet = compose(
99 | map(map(safeProp('street'))), map(safeHead), safeProp('addresses')
100 | );
101 |
102 | firstAddressStreet({
103 | addresses: [{
104 | street: {
105 | name: 'Mulburry',
106 | number: 8402,
107 | },
108 | postcode: 'WC2N',
109 | }],
110 | });
111 | // Maybe(Maybe(Maybe({name: 'Mulburry', number: 8402})))
112 | ```
113 |
114 | Again, we see this nested functor situation where it's neat to see there are three possible failures in our function, but it's a little presumptuous to expect a caller to `map` three times to get at the value - we'd only just met. This pattern will arise time and time again and it is the primary situation where we'll need to shine the mighty monad symbol into the night sky.
115 |
116 | I said monads are like onions because tears well up as we peel back layer of the nested functor with `map` to get at the inner value. We can dry our eyes, take a deep breath, and use a method called `join`.
117 |
118 | ```js
119 | var mmo = Maybe.of(Maybe.of('nunchucks'));
120 | // Maybe(Maybe('nunchucks'))
121 |
122 | mmo.join();
123 | // Maybe('nunchucks')
124 |
125 | var ioio = IO.of(IO.of('pizza'));
126 | // IO(IO('pizza'))
127 |
128 | ioio.join();
129 | // IO('pizza')
130 |
131 | var ttt = Task.of(Task.of(Task.of('sewers')));
132 | // Task(Task(Task('sewers')));
133 |
134 | ttt.join();
135 | // Task(Task('sewers'))
136 | ```
137 |
138 | If we have two layers of the same type, we can smash them together with `join`. This ability to join together, this functor matrimony, is what makes a monad a monad. Let's inch toward the full definition with something a little more accurate:
139 |
140 | > Monads are pointed functors that can flatten
141 |
142 | Any functor which defines a `join` method, has an `of` method, and obeys a few laws is a monad. Defining `join` is not too difficult so let's do so for `Maybe`:
143 |
144 | ```js
145 | Maybe.prototype.join = function() {
146 | return this.isNothing() ? Maybe.of(null) : this.__value;
147 | }
148 | ```
149 |
150 | There, simple as consuming one's twin in the womb. If we have a `Maybe(Maybe(x))` then `.__value` will just remove the unnecessary extra layer and we can safely `map` from there. Otherwise, we'll just have the one `Maybe` as nothing would have been mapped in the first place.
151 |
152 | Now that we have a `join` method, let's sprinkle some magic monad dust over the `firstAddressStreet` example and see it in action:
153 |
154 | ```js
155 | // join :: Monad m => m (m a) -> m a
156 | var join = function(mma) {
157 | return mma.join();
158 | };
159 |
160 | // firstAddressStreet :: User -> Maybe Street
161 | var firstAddressStreet = compose(
162 | join, map(safeProp('street')), join, map(safeHead), safeProp('addresses')
163 | );
164 |
165 | firstAddressStreet({
166 | addresses: [{
167 | street: {
168 | name: 'Mulburry',
169 | number: 8402,
170 | },
171 | postcode: 'WC2N',
172 | }],
173 | });
174 | // Maybe({name: 'Mulburry', number: 8402})
175 | ```
176 |
177 | We added `join` wherever we encountered the nested `Maybe`'s to keep them from getting out of hand. Let's do the same with `IO` to give us a feel for that.
178 |
179 | ```js
180 | IO.prototype.join = function() {
181 | var thiz = this;
182 | return new IO(function() {
183 | return thiz.unsafePerformIO().unsafePerformIO();
184 | });
185 | };
186 | ```
187 |
188 | We simply bundle running the two layers of IO sequentially: outer then inner. Mind you, we have not thrown out purity, but merely repackaged the excessive two layers of shrink wrap into one easier-to-open package.
189 |
190 | ```js
191 | // log :: a -> IO a
192 | var log = function(x) {
193 | return new IO(function() {
194 | console.log(x);
195 | return x;
196 | });
197 | };
198 |
199 | // setStyle :: Selector -> CSSProps -> IO DOM
200 | var setStyle = curry(function(sel, props) {
201 | return new IO(function() {
202 | return jQuery(sel).css(props);
203 | });
204 | });
205 |
206 | // getItem :: String -> IO String
207 | var getItem = function(key) {
208 | return new IO(function() {
209 | return localStorage.getItem(key);
210 | });
211 | };
212 |
213 | // applyPreferences :: String -> IO DOM
214 | var applyPreferences = compose(
215 | join, map(setStyle('#main')), join, map(log), map(JSON.parse), getItem
216 | );
217 |
218 |
219 | applyPreferences('preferences').unsafePerformIO();
220 | // Object {backgroundColor: "green"}
221 | //
222 | ```
223 |
224 | `getItem` returns an `IO String` so we `map` to parse it. Both `log` and `setStyle` return `IO`'s themselves so we must `join` to keep our nesting under control.
225 |
226 | ## My chain hits my chest
227 |
228 | 
229 |
230 | You might have noticed a pattern. We often end up calling `join` right after a `map`. Let's abstract this into a function called `chain`.
231 |
232 | ```js
233 | // chain :: Monad m => (a -> m b) -> m a -> m b
234 | var chain = curry(function(f, m){
235 | return m.map(f).join(); // or compose(join, map(f))(m)
236 | });
237 | ```
238 |
239 | We'll just bundle up this map/join combo into a single function. If you've read about monads previously, you might have seen `chain` called `>>=` (pronounced bind) or `flatMap` which are all aliases for the same concept. I personally think `flatMap` is the most accurate name, but we'll stick with `chain` as it's the widely accepted name in JS. Let's refactor the two examples above with `chain`:
240 |
241 | ```js
242 | // map/join
243 | var firstAddressStreet = compose(
244 | join, map(safeProp('street')), join, map(safeHead), safeProp('addresses')
245 | );
246 |
247 | // chain
248 | var firstAddressStreet = compose(
249 | chain(safeProp('street')), chain(safeHead), safeProp('addresses')
250 | );
251 |
252 |
253 |
254 | // map/join
255 | var applyPreferences = compose(
256 | join, map(setStyle('#main')), join, map(log), map(JSON.parse), getItem
257 | );
258 |
259 | // chain
260 | var applyPreferences = compose(
261 | chain(setStyle('#main')), chain(log), map(JSON.parse), getItem
262 | );
263 | ```
264 |
265 | I swapped out any `map/join` with our new `chain` function to tidy things up a bit. Cleanliness is nice and all, but there's more to `chain` than meets the eye - it's more of tornado than a vacuum. Because `chain` effortlessly nests effects, we can capture both *sequence* and *variable assignment* in a purely functional way.
266 |
267 | ```js
268 | // getJSON :: Url -> Params -> Task JSON
269 | // querySelector :: Selector -> IO DOM
270 |
271 |
272 | getJSON('/authenticate', {
273 | username: 'stale',
274 | password: 'crackers',
275 | })
276 | .chain(function(user) {
277 | return getJSON('/friends', {
278 | user_id: user.id,
279 | });
280 | });
281 | // Task([{name: 'Seimith', id: 14}, {name: 'Ric', id: 39}]);
282 |
283 |
284 | querySelector('input.username').chain(function(uname) {
285 | return querySelector('input.email').chain(function(email) {
286 | return IO.of(
287 | 'Welcome ' + uname.value + ' ' + 'prepare for spam at ' + email.value
288 | );
289 | });
290 | });
291 | // IO('Welcome Olivia prepare for spam at olivia@tremorcontrol.net');
292 |
293 |
294 | Maybe.of(3).chain(function(three) {
295 | return Maybe.of(2).map(add(three));
296 | });
297 | // Maybe(5);
298 |
299 |
300 | Maybe.of(null).chain(safeProp('address')).chain(safeProp('street'));
301 | // Maybe(null);
302 | ```
303 |
304 | We could have written these examples with `compose`, but we'd need a few helper functions and this style lends itself to explicit variable assignment via closure anyhow. Instead we're using the infix version of `chain` which, incidentally, can be derived from `map` and `join` for any type automatically: `t.prototype.chain = function(f) { return this.map(f).join(); }`. We can also define `chain` manually if we'd like a false sense of performance, though we must take care to maintain the correct functionality - that is, it must equal `map` followed by `join`. An interesting fact is that we can derive `map` for free if we've created `chain` simply by bottling the value back up when we're finished with `of`. With `chain`, we can also define `join` as `chain(id)`. It may feel like playing Texas Hold em' with a rhinestone magician in that I'm just pulling things out of my behind, but, as with most mathematics, all of these principled constructs are interrelated. Lots of these derivations are mentioned in the [fantasyland](https://github.com/fantasyland/fantasy-land) repo, which is the official specification for algebraic data types in JavaScript.
305 |
306 | Anyways, let's get to the examples above. In the first example, we see two `Task`'s chained in a sequence of asynchronous actions - first it retrieves the `user`, then it finds the friends with that user's id. We use `chain` to avoid a `Task(Task([Friend]))` situation.
307 |
308 | Next, we use `querySelector` to find a few different inputs and create a welcoming message. Notice how we have access to both `uname` and `email` at the innermost function - this is functional variable assignment at its finest. Since `IO` is graciously lending us its value, we are in charge of putting it back how we found it - we wouldn't want to break its trust (and our program). `IO.of` is the perfect tool for the job and it's why Pointed is an important prerequisite to the Monad interface. However, we could choose to `map` as that would also return the correct type:
309 |
310 | ```js
311 | querySelector('input.username').chain(function(uname) {
312 | return querySelector('input.email').map(function(email) {
313 | return 'Welcome ' + uname.value + ' prepare for spam at ' + email.value;
314 | });
315 | });
316 | // IO('Welcome Olivia prepare for spam at olivia@tremorcontrol.net');
317 | ```
318 |
319 | Finally, we have two examples using `Maybe`. Since `chain` is mapping under the hood, if any value is `null`, we stop the computation dead in its tracks.
320 |
321 | Don't worry if these examples are hard to grasp at first. Play with them. Poke them with a stick. Smash them to bits and reassemble. Remember to `map` when returning a "normal" value and `chain` when we're returning another functor.
322 |
323 | As a reminder, this does not work with two different nested types. Functor composition and later, monad transformers, can help us in that situation.
324 |
325 | ## Power trip
326 |
327 | Container style programming can be confusing at times. We sometimes find ourselves struggling to understand how many containers deep a value is or if we need `map` or `chain` (soon we'll see more container methods). We can greatly improve debugging with tricks like implementing `inspect` and we'll learn how to create a "stack" that can handle whatever effects we throw at it, but there are times when we question if it's worth the hassle.
328 |
329 | I'd like to swing the fiery monadic sword for a moment to exhibit the power of programming this way.
330 |
331 | Let's read a file, then upload it directly afterward:
332 |
333 | ```js
334 | // readFile :: Filename -> Either String (Task Error String)
335 | // httpPost :: String -> String -> Task Error JSON
336 |
337 | // upload :: String -> Either String (Task Error JSON)
338 | var upload = compose(map(chain(httpPost('/uploads'))), readFile);
339 | ```
340 |
341 | Here, we are branching our code several times. Looking at the type signatures I can see that we protect against 3 errors - `readFile` uses `Either` to validate the input (perhaps ensuring the filename is present), `readFile` may error when accessing the file as expressed in the first type parameter of `Task`, and the upload may fail for whatever reason which is expressed by the `Error` in `httpPost`. We casually pull off two nested, sequential asynchronous actions with `chain`.
342 |
343 | All of this is achieved in one linear left to right flow. This is all pure and declarative. It holds equational reasoning and reliable properties. We aren't forced to add needless and confusing variable names. Our `upload` function is written against generic interfaces and not specific one-off APIs. It's one bloody line for goodness sake.
344 |
345 | For contrast, let's look at the standard imperative way to pull this off:
346 |
347 | ```js
348 | // upload :: String -> (String -> a) -> Void
349 | var upload = function(filename, callback) {
350 | if (!filename) {
351 | throw "You need a filename!";
352 | } else {
353 | readFile(filename, function(err, contents) {
354 | if (err) throw err;
355 | httpPost('/uploads', contents, function(err, json) {
356 | if (err) throw err;
357 | callback(json);
358 | });
359 | });
360 | }
361 | };
362 | ```
363 |
364 | Well isn't that the devil's arithmetic. We're pinballed through a volatile maze of madness. Imagine if it were a typical app that also mutated variables along the way! We'd be in the tar pit indeed.
365 |
366 | #Theory
367 |
368 | The first law we'll look at is associativity, but perhaps not in the way you're used to it.
369 |
370 | ```js
371 | // associativity
372 | compose(join, map(join)) == compose(join, join);
373 | ```
374 |
375 | These laws get at the nested nature of monads so associativity focuses on joining the inner or outer types first to achieve the same result. A picture might be more instructive:
376 |
377 | 
378 |
379 | Starting with the top left moving downward, we can `join` the outer two `M`'s of `M(M(M a))` first then cruise over to our desired `M a` with another `join`. Alternatively, we can pop the hood and flatten the inner two `M`'s with `map(join)`. We end up with the same `M a` regardless of if we join the inner or outer `M`'s first and that's what associativity is all about. It's worth noting that `map(join) != join`. The intermediate steps can vary in value, but the end result of the last `join` will be the same.
380 |
381 | The second law is similar:
382 |
383 | ```js
384 | // identity for all (M a)
385 | compose(join, of) === compose(join, map(of)) === id
386 | ```
387 |
388 | It states that, for any monad `M`, `of` and `join` amounts to `id`. We can also `map(of)` and attack it from the inside out. We call this "triangle identity" because it makes such a shape when visualized:
389 |
390 | 
391 |
392 | If we start at the top left heading right, we can see that `of` does indeed drop our `M a` in another `M` container. Then if we move downward and `join` it, we get the same as if we just called `id` in the first place. Moving right to left, we see that if we sneak under the covers with `map` and call `of` of the plain `a`, we'll still end up with `M (M a)` and `join`ing will bring us back to square one.
393 |
394 | I should mention that I've just written `of`, however, it must be the specific `M.of` for whatever monad we're using.
395 |
396 | Now, I've seen these laws, identity and associativity, somewhere before... Hold on, I'm thinking...Yes of course! They are the laws for a category. But that would mean we need a composition function to complete the definition. Behold:
397 |
398 | ```js
399 | var mcompose = function(f, g) {
400 | return compose(chain(f), chain(g));
401 | };
402 |
403 | // left identity
404 | mcompose(M, f) == f;
405 |
406 | // right identity
407 | mcompose(f, M) == f;
408 |
409 | // associativity
410 | mcompose(mcompose(f, g), h) === mcompose(f, mcompose(g, h));
411 | ```
412 |
413 | They are the category laws after all. Monads form a category called the "Kleisli category" where all objects are monads and morphisms are chained functions. I don't mean to taunt you with bits and bobs of category theory without much explanation of how the jigsaw fits together. The intention is to scratch the surface enough to show the relevance and spark some interest while focusing on the practical properties we can use each day.
414 |
415 |
416 | ## In Summary
417 |
418 | Monads let us drill downward into nested computations. We can assign variables, run sequential effects, perform asynchronous tasks, all without laying one brick in a pyramid of doom. They come to the rescue when a value finds itself jailed in multiple layers of the same type. With the help of the trusty sidekick "pointed", monads are able to lend us an unboxed value and know we'll be able to place it back in when we're done.
419 |
420 | Yes, monads are very powerful, yet we still find ourselves needing some extra container functions. For instance, what if we wanted to run a list of api calls at once, then gather the results? We can accomplish this task with monads, but we'd have to wait for each one to finish before calling the next. What about combining several validations? We'd like to continue validating to gather the list of errors, but monads would stop the show after the first `Left` entered the picture.
421 |
422 | In the next chapter, we'll see how applicative functors fit into the container world and why we prefer them to monads in many cases.
423 |
424 | [Chapter 10: Applicative Functors](ch10.md)
425 |
426 |
427 | ## Exercises
428 |
429 | ```js
430 | // Exercise 1
431 | // ==========
432 | // Use safeProp and map/join or chain to safely get the street name when given
433 | // a user.
434 |
435 | var safeProp = _.curry(function(x, o) {
436 | return Maybe.of(o[x]);
437 | });
438 | var user = {
439 | id: 2,
440 | name: 'albert',
441 | address: {
442 | street: {
443 | number: 22,
444 | name: 'Walnut St',
445 | },
446 | },
447 | };
448 |
449 | var ex1 = undefined;
450 |
451 |
452 | // Exercise 2
453 | // ==========
454 | // Use getFile to get the filename, remove the directory so it's just the file,
455 | // then purely log it.
456 |
457 | var getFile = function() {
458 | return new IO(function() {
459 | return __filename;
460 | });
461 | };
462 |
463 | var pureLog = function(x) {
464 | return new IO(function() {
465 | console.log(x);
466 | return 'logged ' + x;
467 | });
468 | };
469 |
470 | var ex2 = undefined;
471 |
472 |
473 |
474 | // Exercise 3
475 | // ==========
476 | // Use getPost() then pass the post's id to getComments().
477 | //
478 | var getPost = function(i) {
479 | return new Task(function(rej, res) {
480 | setTimeout(function() {
481 | res({
482 | id: i,
483 | title: 'Love them tasks',
484 | });
485 | }, 300);
486 | });
487 | };
488 |
489 | var getComments = function(i) {
490 | return new Task(function(rej, res) {
491 | setTimeout(function() {
492 | res([{
493 | post_id: i,
494 | body: 'This book should be illegal',
495 | }, {
496 | post_id: i,
497 | body: 'Monads are like smelly shallots',
498 | }]);
499 | }, 300);
500 | });
501 | };
502 |
503 |
504 | var ex3 = undefined;
505 |
506 |
507 | // Exercise 4
508 | // ==========
509 | // Use validateEmail, addToMailingList, and emailBlast to implement ex4's type
510 | // signature.
511 |
512 | // addToMailingList :: Email -> IO([Email])
513 | var addToMailingList = (function(list) {
514 | return function(email) {
515 | return new IO(function() {
516 | list.push(email);
517 | return list;
518 | });
519 | };
520 | })([]);
521 |
522 | function emailBlast(list) {
523 | return new IO(function() {
524 | return 'emailed: ' + list.join(',');
525 | });
526 | }
527 |
528 | var validateEmail = function(x) {
529 | return x.match(/\S+@\S+\.\S+/) ? (new Right(x)) : (new Left('invalid email'));
530 | };
531 |
532 | // ex4 :: Email -> Either String (IO String)
533 | var ex4 = undefined;
534 | ```
535 |
--------------------------------------------------------------------------------
/code/lib/package.json:
--------------------------------------------------------------------------------
1 | {
2 | "name": "MAG_lib",
3 | "version": "0.0.1",
4 | "description": "Support libs for the book",
5 | "main": "index.js",
6 | "dependencies": {
7 | "ramda": "^0.13.0"
8 | },
9 | "repository": {
10 | "type": "git",
11 | "url": "https://github.com/DrBoolean/mostly-adequate-guide"
12 | },
13 | "author": "",
14 | "license": "ISC",
15 | "bugs": {
16 | "url": "https://github.com/DrBoolean/mostly-adequate-guide/issues"
17 | },
18 | "homepage": "https://github.com/DrBoolean/mostly-adequate-guide"
19 | }
20 |
--------------------------------------------------------------------------------
/code/part1_demo/flickr.html:
--------------------------------------------------------------------------------
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
10 |
11 |
--------------------------------------------------------------------------------
/code/part1_demo/flickr.js:
--------------------------------------------------------------------------------
1 | requirejs.config({
2 | paths: {
3 | ramda: 'https://cdnjs.cloudflare.com/ajax/libs/ramda/0.13.0/ramda.min',
4 | jquery: 'https://ajax.googleapis.com/ajax/libs/jquery/2.1.1/jquery.min'
5 | }
6 | });
7 |
8 | require([
9 | 'ramda',
10 | 'jquery'
11 | ],
12 | function (_, $) {
13 | ////////////////////////////////////////////
14 | // Utils
15 | //
16 | var img = function (url) {
17 | return $('"+p.title+"
"+makeComments(cs); });
32 |
33 |
34 | var ex3 = Task.of(render).ap(getPost(2)).ap(getComments(2));
35 | // or
36 | // var ex3 = liftA2(render, getPost(2), getComments(2))
37 |
38 |
39 |
40 |
41 | // Exercise 4
42 | // ==========
43 | // Write an IO that gets both player1 and player2 from the cache and starts the game
44 | localStorage.player1 = "toby";
45 | localStorage.player2 = "sally";
46 |
47 | var getCache = function(x) {
48 | return new IO(function() { return localStorage[x]; });
49 | }
50 | var game = _.curry(function(p1, p2) { return p1 + ' vs ' + p2; });
51 |
52 | var ex4 = liftA2(game, getCache('player1'), getCache('player2'));
53 |
54 |
55 |
56 |
57 |
58 | // TEST HELPERS
59 | // =====================
60 |
61 | function getPost(i) {
62 | return new Task(function (rej, res) {
63 | setTimeout(function () { res({ id: i, title: 'Love them tasks' }); }, 300);
64 | });
65 | }
66 |
67 | function getComments(i) {
68 | return new Task(function (rej, res) {
69 | setTimeout(function () {
70 | res(["This book should be illegal", "Monads are like space burritos"]);
71 | }, 300);
72 | });
73 | }
74 |
75 | module.exports = {ex1: ex1, ex2: ex2, ex3: ex3, ex4: ex4}
76 |
--------------------------------------------------------------------------------
/code/part2_exercises/answers/applicative/applicative_exercises_spec.js:
--------------------------------------------------------------------------------
1 | require('../../support');
2 | var E = require('./applicative_exercises');
3 | var _ = require('ramda');
4 | var assert = require("chai").assert
5 |
6 | describe("Applicative Exercises", function(){
7 |
8 | it('Exercise 1', function(){
9 | assert.deepEqual(Maybe.of(5), E.ex1(2, 3));
10 | assert.deepEqual(Maybe.of(null), E.ex1(null, 3));
11 | });
12 |
13 | it('Exercise 2', function(){
14 | assert.deepEqual(Maybe.of(5), E.ex2(Maybe.of(2), Maybe.of(3)));
15 | assert.deepEqual(Maybe.of(null), E.ex2(Maybe.of(null), Maybe.of(3)));
16 | });
17 |
18 | it('Exercise 3', function(done){
19 | E.ex3.fork(console.log, function (html) {
20 | assert.equal("Love them tasks
"+p.title+"
"+makeComments(cs); });
34 |
35 | // ex3 :: Task Error HTML
36 | var ex3 = undefined;
37 |
38 |
39 |
40 | // Exercise 4
41 | // ==========
42 | // Write an IO that gets both player1 and player2 from the cache and starts the game
43 | localStorage.player1 = "toby";
44 | localStorage.player2 = "sally";
45 |
46 | var getCache = function(x) {
47 | return new IO(function() { return localStorage[x]; });
48 | }
49 | var game = _.curry(function(p1, p2) { return p1 + ' vs ' + p2; });
50 |
51 | // ex4 :: IO String
52 | var ex4 = undefined;
53 |
54 |
55 |
56 |
57 |
58 | // TEST HELPERS
59 | // =====================
60 |
61 | function getPost(i) {
62 | return new Task(function (rej, res) {
63 | setTimeout(function () { res({ id: i, title: 'Love them futures' }); }, 300);
64 | });
65 | }
66 |
67 | function getComments(i) {
68 | return new Task(function (rej, res) {
69 | setTimeout(function () {
70 | res(["This book should be illegal", "Monads are like space burritos"]);
71 | }, 300);
72 | });
73 | }
74 |
75 | module.exports = {ex1: ex1, ex2: ex2, ex3: ex3, ex4: ex4}
76 |
--------------------------------------------------------------------------------
/code/part2_exercises/exercises/applicative/applicative_exercises_spec.js:
--------------------------------------------------------------------------------
1 | require('../../support');
2 | var E = require('./applicative_exercises');
3 | var _ = require('ramda');
4 | var assert = require("chai").assert
5 |
6 | describe("Applicative Exercises", function(){
7 |
8 | it('Exercise 1', function(){
9 | assert.deepEqual(Maybe.of(5), E.ex1(2, 3));
10 | assert.deepEqual(Maybe.of(null), E.ex1(null, 3));
11 | });
12 |
13 | it('Exercise 2', function(){
14 | assert.deepEqual(Maybe.of(5), E.ex2(Maybe.of(2), Maybe.of(3)));
15 | assert.deepEqual(Maybe.of(null), E.ex2(Maybe.of(null), Maybe.of(3)));
16 | });
17 |
18 | it('Exercise 3', function(done){
19 | E.ex3.fork(console.log, function (html) {
20 | assert.equal("Love them futures