Haskell Learning Note(3)

試論curring

在Haskell中，不用C++這麼複雜的方法來解決問題，而是採用curried function來解決這個問題。

Prelude> let add x y = x + y   -- 簡單來說就是寫一個 (+)
Prelude> :t add
add :: (Num a) => a -> a -> a   -- 此時的add是一個具有兩個引數的function
Prelude> :t add 1
add 1 :: (Num t) => t -> t        -- 此時的add 1 是具有一個引數的function
Prelude> :t add 1 2
add 1 2 :: (Num t) => t          -- 此時的add 1 2是一個不具有引數的function

在Haskell裡，使用單純的curried function即可解決，寫起來很像C++的function default arguemnt，意義不太一樣，在Haskell裡是真的把引數代入形成一個新的function，其實+ operator也可以做出同樣的功能(Josh Ko說這是語法糖XD)

Prelude> :t (+)
(+) :: (Num a) => a -> a -> a
Prelude> :t (1+)
(1+) :: (Num t) => t -> t
Prelude> :t (1+2)
(1+2) :: (Num t) => t

寫到這裡我在想，我幹麻沒事自己寫一個add呢 XD那麼，可以試著用map寫出一點有趣的東西

Prelude> map (1+) [1..10]
[2,3,4,5,6,7,8,9,10,11]

當然，一個curried function在FP中的功用不止於此，curried funciton可以做更多事，隨你寫，隨你造，而不用C++ STL裡的bind2nd這種相較之下較不直覺的方法。curried fuction的好處是在Haskell底下是lazy evaluation，也就是說，你function引數可以不用給全，直到你要求把答案算出來的那一刻把argument給全就行了，而且可以隨你組合，隨你寫，可以做出相當多的靈活變化，也就是說，curried function並非要求一次把function arguement給齊，在Haskell底下大部分的funciton都是curried function。

那麼有沒有要求要一次給齊的，換個腦子想想，就是uncurried function，在這樣子的一個function底下，沒有一次給足所有的argument就會出錯(一時想不到有什麼function)。

補充:當我們寫(1+)而我們又呼叫這個function時，是類似C++的default argument還是wrapper function的技法呢，如果記得是沒有錯，是前者，也就是說，不管怎麼compose，都是只有一層的呼叫，相當的方便。

---
真糟，寫的真少。

Haskell Learning Note(3) - 前傳

我本來想要參考和Josh Ko的MSN對話紀錄來這一篇的，但是發現MSN對話紀錄竟然不見了...Orz

funciton interface如何改變

一個function，會有0個至多個不等的argument，而function只有一個signal output(當然也不一定是signal output，你可以說傳一個list出來，說我傳了一堆東西，但是就整體而言，你還是傳了一個符合某一個type的東西出來)，這對 functional programming更是如此，基本上就算是function name相同但是arguments 個數不同的話，我們仍視為不同的function

先跳回C/C++，眾所皆知，C++有著function overloading機制(靠著compile-time決定呼叫那一個function，為一個static-linking)，基本上靠著這樣子的機制，避免非常多的name collision。

題外話，C++靠著三種機制來避免name collision，一種是name scope，一種是funciton overloading，一種是polymorphism，不過很可惜的是，沒有類似Java裡的inner class來避免一次性的class使用，但是到了boost，有提供lambda calculus來解決部分的問題。

或許換個角度來想，程式碼複用性一直是一個很重要很重要的問題，以function層面而言，最常見的wrapper function

int add(int a, int b){
    return add(a, b, 0);
}

int add(int a, int b, int c){
    return a+b+c;
}

當然，這個程式在C++中可以更簡單的寫成

int add(int a, int b, int c=0){
    return a+b+c;
}

這些都是程式撰寫上的技巧，不足以掛齒，在寫程式的單純呼叫function時，引數是不足以構成問題的，可是call-back function上呢，在STL algorithm的比較呢，以STL的find_if為例。

template<lass InputIterator, class Predicate>
InputIterator find_if(InputIterator first, InputIterator last,
                     Predicate pred);

其中的Predicate要求傳入一個value type的變數，傳回bool，也就是說，如果你的function不是一個引數，是不符合Predicate的要求，那麼就無法變成find_if所能使用的function object。

STL所提供的解決方法有二，如果你要求剛好是function object adaptor和predefined function object組合起來可解決，那麼就使用組合技，第二個方法為，自行撰寫一個較為general function object ，再使用funciton object adaptor來改變一個function object的interface。舉個簡單的例子

std::find_if(u.begin(), u.end(), std::bind2nd(std::less<int>(), 0)); //尋找某個區間第一個小於0的數字。

我不能不說，我當初看到這樣子的寫法，我以為找到了救星，funciton可以玩組合技耶，而且這樣子的確解決了call back function的問題。

利用wrapper function或者是STL裡面的function object adapter或種種程式語言的技能的確可以改變一個function原本的interface，但是有沒有更好的方法? 有啊，不然我就白寫了，看到Haskell的方法之後，以前的我好傻好天真(大誤)~XD。

---
還沒進入正題XD

有趣的圖

靠腰這圖真是彷彿穿透了我的內心，洗滌了我的靈魂，讓我淚如雨下~我應該認真面對的~m(__.__)m

好友gb014388的創作，還是以後blog走這種路線也不錯XD?

---
歡迎廣為流傳XD

猜測

我不喜歡去猜測人的想法，雖然大部分人的行為都有跡可循，但是僅止於明顯的行為部分。

常常會有說者無心，聽者有意的狀況發生，我最近常常下意識的去猜測其他我所不認識人的想法，感到非常漸愧，這不是我該做的事。或許有90%的事是可預測的，但是我們遇到的事常常是落在10%的範圍，程式可以預測行為，但是人的預測，往往有太多足以造成蝴蝶效應的因素而難以預測，我的做法相當直接，傾向直接詢問，當然，詢問的方法往往也得適當。

最近的自己，或許會縮自內省自己世界的狀況，被親人責斥，其實不管問題的源始為何，如果發生這樣子的問題，只能說，如果自己沒有做錯什麼或表達錯什麼，不會發生這樣子的事，所以最該做的是反省自己。

雖然發生很多事，很多想寫的，仍得靜下心來看待每件事

---
無欲則剛