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 <[email protected]> To: David House <[email protected]> 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 上的文本编辑器支持。