Haskell Learning Source

從 wiki 上移過來，大概會改變寫長文的寫作風格，拆成許多個小篇的來寫。

• Hayoo, Hoogle - function's type information (include hackageDB's package)
• hackageDB - package information, we can use cabal command install it.
• Haskell Cafe – Mailing List. You can google keyword, for example you can use google search like the following

  keyword site:http://www.haskell.org/pipermail/haskell-cafe/

---
持續寫作

中文小說與 Kindle DX

其實 Kindle DX 本身並不支援中文格式，所以如果在不變更任何程式的狀況下，有 pdf 可以選擇，如果想選擇破解的話，可以安裝 Unicode 字型，不過英文字體連帶閱讀起來感覺不好。我以下說說我的做法

目前中文小說網站有兩個比較有名

• 好讀網站
• 中文小說精選

後者網站我還沒有試過，不過好讀網站的 pdb file 在 Mac OSX 上讓我很頭痛，仔細看看大家都有這個困擾。我簡述步驟如下。

1. 利用網路上高手所提供的方法先把 pdb 轉成純文字./a.out xxx.pdb > xxx.txt
2. 得到 xxx.txt 之後，編碼是 Big5 的 Windows DOS file，這時候可以利用內建的 Mac OSX 文字編輯器，編碼時選擇這個打開，之後另存新檔成 utf8 即可(有想過要用 iconv ，這樣子可以寫成一個 script ，但是我不知道相對應的編碼名稱為何 ... Orz)使用iconv -f big5-2003 -t utf8 input.txt > output.txt即可，就可以把 Big5 的檔案轉成 utf8，如果是使用第一個程式製作出來的文字檔在轉換時會出錯，是不用理會的，因為那是第一隻程式所產生的一些資訊。
3. 得到 txt 之後基本上想做什麼事都可以，Kindle DX 對於 pdf 的支援度不高，而我大部分只是線性閱讀，所以丟到 calibre 中轉成 pdf 即可，行高記得選擇 20 pt ，output 可針對 Kindle DX 最佳化。
4. 丟到 Kindle DX 上即可閱讀

輸出後在 Kindle DX 上成果大概如下 (對不起，我不會取景...Orz)

預設輸出是黑體，有想過要用 LaTeX 排版，不過這可能要花很多功夫，所以暫時交給 calibre 來做這些事，而我覺得這樣子的輸出結果我可以接受啦。至少字夠大，閱讀起來不太吃力。

---
簡單記錄一下。

Compiler Research: The Next 50 Years

這篇是寫在嵐達網上，在自己的 blog 上做個備份。本文不開放回覆，統一至這篇回覆(寫這麼差...Orz)

Compiler Research: The Next 50 Years
Communication of the ACM - Febuary 2009

這篇是一篇很有趣的文章，在 CACM 上的文章都是接近科普類型，這篇也不例外，所以我花了幾天看懂這篇文章，又著實想了好幾天。

其實在這個領域中，要預測下一個十年比預測下一個五十年容易的多，那麼他覺得下一個 50 年的問題是什麼 ? 簡單的來說就是。 Program Optimization (Mulit-core, Architecture-Specific ... etc) 與 Security & Robust

就 parallel program 來說，multi-core 是一個趨勢(因為 Moore's Law 逼得大家努力的製作 multi-core CPU XD)，在過去的三十年來，Compiler 對於 parallel 並沒有一個泛用的方案(General Solution)，不管怎麼操作，lock, race condition 都是避免不了的問題，很多人嘗試要提出方案來解決，不過到目前為止沒有成功。

就 Security 來說，現在的 Compiler 勢必得去面對如何讓一個更複雜更為大型的程式保持正確(Corectess)且穩固(Robustic)，要用到很多手段報分析，讓一個程式在各個方面都 保持穩定。

回到 parallel 與 Compiler 的關係來說，用一個小故事來開個頭。有一天，我的指導老師問我，在 Embedded System 上，大部分的 CPU 是沒有 Floating Point Unit ，可是勢必得要去處理很多相關的運算，請問是怎麼解決的 ? 我想了很久想不出來，他說，其實解決不了(我被框了 ... Orz)，但是如果切割成許多個領域來解決是可以的，以 FFT 來說，在硬體上，只需要數個加法器與乘法器就可以搞定，以某個影像編碼來說，雖然每次都會用到 sin, cos，但是實際上來說，會轉的角度只有九個，所以查表即可解決。

回到正題，parallel programming 對於 Compiler 來說，如果切割成許多個領域來分別進行最佳化，其實到目前為止算是有相當的成果的， MIT 的 StreamIt Programming Langauge & Raw Processor (for streaming)，Google 的 Map Reduce (從 Functional Programming 來的 XD)，切割開來的時候，每個領域的平行其實都可以用巧妙的方式來解決，但是組在一起卻沒這麼容易。所以這篇文章有嘗試建議一些方法，例如說，撰寫高效能 的平行演算法並加以封裝，而寫程式的人就使用這些封裝的好的演算法來組合(BLAST ?)，這大概是目前可以做到的，或者是你可以想出一個全新的方法來解決現在的問題。綜合以上，這篇文章寫了很有趣的話，誰可以在平行上做出突破就可以引領 下一個研究年代。

而針對不同的平台來說，現在寫程式並比較不會這麼局限在單一架構上，你有可能寫程式寫在手機上，一張開發版上，自己的 CPU 上，針對不同的平台要做最佳化，其實是有一定的困難度的，而這也是 Compiler 下一個很重要的事。如果以 Embedded System 來說，多個晶片要協同運作是一個很常見的事，而這件事都需要很多方面來配合 (OS, Programming Langauge, Compiler ...etc)。這也是一個值得著力的點。

要寫出一個安全且穩固的程式是一件相當困難的事，可以就程式語言層面設計出一個更為安全的程式語言，教育程式員怎麼寫，或者是利用 Compiler 去做一些事，program analysis 就 wiki 來說有 Program Optimization 與 Program Correctness ，前者我不清楚，不過現在已經有很多現成工具可以用了，硬體設計上，用以分析出一個電路的 critical path，軟體設計上用以分析耗掉多少記憶體，那邊佔用的時間最多之類的。但是 Program Corectness 來說，我覺得是很重要，但是並不是我所了解的領域(這讓我想到這次 FLOLAC 10 的 Frama-C)，要如何保證程式在每個層面皆能正確運作，我相信有許多的議題需要討論。Compiler 在過去這麼多年來越來越重要有一個原因是因為 high-level programming language 受到了廣泛的使用，然而分析這些語言會不會產生更多的問題呢 ? (這個問題是個人猜測)

最後這篇文章提到一些有趣的建議，不外乎是針對 Compiler 設計一連串的專門課程啦，建立一個 Compiler 協會之類的，老實說，我覺得每個領域都會想這樣子建議吧 XD。所以我這個部分就沒有很認真的看了 XD。

題外話： 我的指導老師跟我說，這篇文章提到許多論點是許多傳統做 Compiler 的人不願意接受的，我看起來是覺得很不錯啊，至少我覺得蠻有趣的，他舉了一個例子，你要一個練了許多年武功的人不用這個武功來解決問題是很困難的。老實說 我也不知道是什麼，或許聽了 CHTPC 會有一些感覺吧 ... ?

---
為什麼我覺得我怎麼寫都像寫廢話一樣 ... Orz