PL Lecture 10/28 （續）
談談一種特別的 function — Coroutine
之前幾週停課，終於再次開始隔週的 PL Lecture。
然後就是最後一堂了。
月有陰晴圓缺、人有悲歡離合。
PL Lecture — Subprogram 2
Coroutine 執行的順序有個 resume 的特色，就是在某個點可以跑去別的地方執行，執行結束後回來。
跟一般 function 必須從頭到底不太一樣，比較嚴謹得定義如下。
一個 Coroutine 的例子
假設我們有個 Iris.csv ，這個檔案內有很多行都是4，有一個 coroutine 叫做 tail, 另外一個 coroutine 叫做 grep。
grep 參數帶4這個 coroutine 會把帶有4的 行print 出來。
Tail (會 output the last part of file)有個 input 從 iris.csv 來， -f 會 output appended data as the file grows。
用 tail -f 來監控 iris.csv 拿到 output ，透過一個 pipeline 送給 grep 當 input ，grep 再 output 到 terminal (或 console)。
Tail 有可能一行一行去讀，到某個 buffer size 然後丟給 grep，處理好就把資訊丟出去。
如果繼續丟更多行資料給 iris.csv ，裡面有包含 4 ，grep 就接續往下跑，而不會從頭 print。
Possible Computation Modal
第一種可能：只有一個 thread 的時候
假設這條線（黑色）是一個 thread，A 跑一跑（藍色）換 B 跑一跑（綠色）。
如果是 single thread，共用 thread 的時候，有可能會共用 memory space，要小心 memory conflict 的問題。
Coroutine 可能有 A 又有 B 又有 C，如果是一個 single thread 可能會不知道要 swap 成誰。
第二種可能：兩個 thread
兩條線（黑色）是兩個 thread，A跑一跑（藍色）換 B 跑一跑（綠色）。
沒有資源共享的問題，但會有資源浪費的問題（紫色圈圈）。
KK 提問：為什麼不各自跑自己的 thread？
記得之前的圖嗎？需要A跑到一個地方才會 resume 另外一個 B開始跑。
因此，所有好的 Coroutine 都會用 message passing 來做。
Resume 是一種概念，實際上怎麼做，有可能 B 是一個 function，然後去呼叫他。
另外一種方式，是要 resume 的時候會丟一個 message ，好處是可以等對方丟 message 回來再做事，但需要確保這件事情發生。
網路找到的補充：
這篇2015的文章就很有趣，直接說 Our CPUs are not getting any faster. What’s happening is that we now have multiple cores on them. If we want to take advantage of all this hardware we have available now, we need a way to run our code concurrently. Decades of untraceable bugs and developers’ depression have shown that threads are not the way to go. But fear not, there are great alternatives out there and today I want to show you one of them: The actor model.
Wikipedia 也有不少著墨
假設今天有個 Actor 是 A ，收到了 m1 (message 1) 和 m2 (message 2) 會做一些事情。
另外一個 Actor 是 B ，收到了 m1 (message 1) 和 m2 (message 2) 會做一些事情。
Thread 會定義兩種，一種是處理 msg (message) 的，另外看系統還有多少資源，創一個 thread pool。
Msg 要獨立開出來的原因，是因為要確保 message passing 不會被 block 住。
紫色 m1 丟給 A 這個 Actor ，m1 就會去 thread pool 看有多少資源。
做完之後，就會綠色 m1 再丟給 B，等 B 做完再丟 m2 給 A 。
系統裡面就會有各種 Actor ，收到 message 就會把執行內容丟到 thread pool 進行。
這邊爽燈就是稍微談一下 Coroutine 這個 design pattern。
Parameter Passing Method
Function 會有 Argument （或稱Parameter），function 也會有 return 的值。
這邊列有：
Call by value, Call by result (Return by value), Call by value result, Call by reference, Call by name 這五種。
Call by value 跟 Call by result 其實是一樣的東西，方向性不同，Call by value result 就是 1+2。
前三種都是 Call by copy ，如果有個 function ， x => x+1 ，在 Global 的地方呼叫 f(x) ，x 就會指向一個 copy 的 2。
Call by reference 就不會長新的，會 reference 同一個 2。
Call by name 有點類似 call by reference ，等到需要用的時候才會去運算值。
設計函數的時候要思考什麼？
哪些參數是 in （pass 值進去）, out （return 值） 或 inout （通常不會去設計但有些例子不錯）。
如果 Primitive Type ，通常都是用 copy 的。
Structured Type (比較複雜的，如 map、dictionary、list、class、function)，都會是 by reference ，因為 copy 的成本太高。
而 by reference 的危險在，如果語言是 mutable 的語言，function 對 pass by reference 的東西可能會不小心修改到。
如果是做 functional programming 的話就不用考慮這個問題。
補充延伸討論：這篇很有趣
Call by Name
以下這個例子以 Scala 語法來說明，左邊是正常的 function call。
右邊有寫箭頭 => 的時候，就是 call by name 的概念。
假設今天定義 f(x) 會回傳一個 Int = 1/x 。
剛剛的兩個 function都是 print 3 。
左邊的第一個情形，因為需要先把 f(0) evaulate 出來，碰到 divide by 0 所以會噴掉。
右邊第二個例子，當 x 被需要的時候才會執行，因此不會被展開，順利 print 3。
如果程式有很多 condition，call by name 可以當作一種優化程式碼的方式。
沒有被跑到的程式碼，則不會被執行。
另外一個好處是，因為無限的概念無法被存在記憶體裡，用 call by name可以做出一個代表無限序列的資料結構。
補充：Lazy evaluation strategies
Lazy evaluation means that when an expression is passed as a parameter to a function, it is not evaluated before entering the function body, but only when it is accessed/read the first time inside the function. If the result of such expression is never used inside, then it will never be evaluated.
補充：無限序列的資料結構
一些未來可以去多學習的
- Polymorphism
- Function Overloading
