Haskell/貢獻者須知
除了各種印刷書籍,網路上還散佈著大量的 Haskell 教程。這些教程都不能為學習 Haskell 的學生提供一站式服務。印刷書籍主要描述的是 Haskell 98,但從那時起,GHC 引入的許多“擴充套件”已經成為事實上的標準。此外,單子理論和實踐得到了極大的發展,箭頭也開始被用於主流庫中。因此,初學者 Haskell 開發人員面臨著大量混亂的資源,包括教科書、專家撰寫並面向專家的學術論文、獨立的教程和維基頁面上的解釋,當然,還有郵件列表、IRC 頻道和論壇上的熱心幫助者。
充分利用所有資源可能是一段令人沮喪且困難的經歷。理想情況下,這本華夏公益教科書將繼續隨著語言的演變而發展和成長。我們希望有一個權威的參考資料,讓 Haskell 程式設計師能夠輕鬆地找到他們需要學習的下一件事,然後學會充分而清晰地理解它。為此,貢獻者應遵循以下幾點:
- 確保你在解釋了某個語言結構或概念之後才使用它。這可能很困難:Haskell 將許多複雜的概念緊密地結合在一起,每個概念都支援其他概念。然而,不可能透過一次性吞下整個語言來學習它。一個好的教程會將內容分解成易於消化的塊。有時,以一種比你想要的更笨拙或更不通用方式來解釋或演示事物有助於保持內容的易懂性。
- 不要將現有文字或結構視為神聖不可侵犯。如果有改進的空間,那麼請隨時更改內容。請記住,華夏公益教科書是在版本控制下的,因此任何錯誤都可以隨時撤回。(話雖如此,重大更改可能需要先進行討論)。
- 隨意撰寫更高階主題的內容,即使主要文字尚未跟上進度。特別是關於併發、GADTs、箭頭、解析、使用者介面和 FP 設計原則的章節都需要進行改進。只是在引言中說明任何主要文字尚未涵蓋的先決條件。
任何瞭解 Haskell 的人都可以在這裡貢獻。如果你...
- Haskell 新手:請通讀本書的前幾個模組。這些模組對於你開始理解這門語言至關重要。如果這些模組不夠清晰,則需要進行更改。如果你無法理解它們,或者發現它們沒有提供足夠廣泛的知識基礎,請在某個討論頁面上新增投訴(最好是針對內容頁面的討論頁面)。
- 仍在適應 Haskell:你正處於“重構”華夏公益教科書中初學者模組的最佳位置!你最瞭解什麼對新手有幫助,什麼只是完全令人困惑。要勇敢,如果某些文字毫無用處,請大膽刪除它們。
- 伴隨著 Haskell 成長:有很多工適合你。華夏公益教科書需要更好地涵蓋分層模組(不過不要與 Haddock 文件過於重疊),以及新的練習(以及答案)。高階模組也需要一些重構。
- 真正的專家:你可以開始或提出許多新的模組。華夏公益教科書沒有範圍限制。涵蓋許多更高階的主題將非常棒。
請積極參與!隨意隨意更改內容。再說一次,整本書都在版本控制下,所以任何更改都不算太大。
請注意,華夏公益教科書貢獻者有時可以在 irc.freenode.net 的 #haskell 頻道中找到。這是一個討論想法和方向的好地方。
還有一個專門針對 Haskell 華夏公益教科書(實際上是所有 Haskell 教育資料)的郵件列表。請參見 http://www.haskell.org/pipermail/wikibook/
以下是過去和現在貢獻者關於高效編輯華夏公益教科書的一些筆記
FIXME:將此釋出到更合理的地方
我喜歡 Emacs,不能忍受使用text area來編輯華夏公益教科書頁面,尤其是長頁面,我將在那裡進行大量寫作。在 Firefox 一兩次崩潰並丟失了幾個小時的工作之後,我意識到必須有一種更合理的方式來為 MediaWiki 專案做出貢獻。這是我的解決方案
首先,wikipedia-mode對於字型加亮至關重要。它基於 outline mode。然而,它確實包含一些愚蠢的快捷鍵,因此這是我安裝它的方式
(autoload 'wikipedia-mode "wikipedia.el"
"Major mode for editing documents in Wikipedia markup." t)
(add-hook 'wikipedia-mode-hook 'flyspell-mode)
(add-to-list 'auto-mode-alist
'("\\.wiki\\'" . wikipedia-mode))
(defun unset-wikipedia-bindings ()
(interactive)
(local-unset-key (kbd "C-<up>"))
(local-unset-key (kbd "C-<down>"))
(local-unset-key (kbd "C-<left>"))
(local-unset-key (kbd "C-<right>")))
(add-hook 'wikipedia-mode-hook 'unset-wikipedia-bindings)
現在我們可以在 Emacs 中編輯 MediaWiki 檔案,能夠將它們釋出回伺服器而不必複製貼上到 Firefox 中將是一件很棒的事情。一位名叫 Mark Jaroski 的人編寫了MVS,這是一個用於與 MediaWiki 伺服器互動的客戶端程式。以下是一個典型的會話
Specify login details for the wikibook, with the 'en' locale mvs login -d wikibooks.org -u <username> -p <password> -l en Pull the 'Haskell/Notes for contributors' module from the server mvs update 'Haskell/Notes for contributors.wiki' ... hack away on that file ... Commit the changes back to the server mvs commit -m "New notes" 'Haskell/Notes for contributors.wiki'
很快就會有新版本 1.0,它應該包含一些新功能,讓生活更輕鬆一些。以下是我與他的一封電子郵件對話中的摘錄,表明了將要新增的功能
Date: Thu, 20 Jul 2006 09:50:06 +0200 From: Mark <mark@geekhive.net> To: David House <dmhouse@gmail.com> Subject: Re: MVS comments and requests David House wrote: > I've been using MVS for a while now, moving my Wikibooks editing over > to Emacs, which has been very handy. As Emacsers are never productive > enough, I decided to try and hack together some Emacs lisp to > integrate Emacs and MVS a bit further. The end result will basically > be the ability to do C-x v v (that's Emacs-speak for Ctrl+x, then v, > then v), type a message, C-c C-c and have the page sent to the server. > Or, C-c C-p whilst I'm still typing and I get a preview automatically > displayed in Firefox. That's very cool. I have a similar vim module. > Firstly, the restriction that you have to issue commands from the > 'working copy root', or whatever it's called, is a little... > restrictive. :) Say if I download Foo/Bar, then cd to Foo, I should be > able to update/commit/preview/etc Bar, with the relative paths > resolved. Is this feasible? Yes, but I think it's probably going to have to wait for the next version or so. I'm working on an major overhaul for the 1.0 version, with more of an OO api. This will make it easier to add images and other neato things. > Secondly, MVS is slow. I realise this is probably because WikiMedia's > servers aren't the snappiest in the world, and most of the time, I'm > willing to wait for update and commit commands, but preview is where > it bites. I'd like the possibility to install MediaWiki locally, then > have MVS fire off preview requests to the local, rather than remote, > server. This would basically boil down to an option allowing you to > have a separate recipient address for previews, AFAICT. That's also part of my little plan. Of course you can pretty much get this effect now just by having two .mediawiki files and swapping them around when you want to switch servers. > I can think of two problems here: templates obviously > wouldn't work, and namespaces might get a little funky. > However I'm willing to live with both of these for a > faster preview. In the future, perhaps you could also > implement something to download all the templates linked > to from a page, perhaps even automatically. I agree.
尚未實現,但在宏偉計劃中,是為 Emacs 編寫一些 VC 繫結,這樣提交就像 C-x v v 一樣簡單。但是,我將等到上面提到的某些功能實現之後再做。目前,我的按鍵繫結設計將類似於
- C-x v v, C-c C-f
- 將檔案提交到伺服器。
- C-c C-m
- 將次要版本提交到伺服器
- C-c C-p
- 預覽檔案。
除了 VC 繫結之外。
MVS 的大部分功能都比較慢,但這沒關係,因為 MediaWiki 本身就比較慢。但是,預覽是一個可以改進的領域。我的計劃是安裝一個本地 MediaWiki,然後在 MVS 中提供一個選項,將預覽請求傳送到該伺服器,而不是傳送到遠端伺服器,從而提高速度。正如 Mark 指出的那樣,目前可以透過交換 .mediawiki 檔案來實現這一點。
如果你有任何想法,請在這裡貼出來。
上面的大多數提示都可以適應其他文字編輯器。有關詳細資訊,請參見Wikipedia 上的文字編輯器支援。