星期六, 10月 04, 2008

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

星期四, 10月 02, 2008

有趣的圖



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

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

---
歡迎廣為流傳XD

猜測

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

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

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

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

---
無欲則剛