Nobuo Yamashita

仕組みとしては、Travis-CIとかを使えばいいのかもしれませんね。 工夫のしどころはコンテンツを 1. Markdownファイル(foo.md)として書いて、そこにコードブロックを埋め込む 2. Haskellスクリプトファイル(foo.hsまたはfoo.lhs)として書いて、説明はコメントとして埋め込む のどちらにするかで考え方が違ってくると思います。 基本的には、1. の場合は解説が主で、コードは説明のための具体例、2. の場合はコードが主で、解説はコメントと考えることになります。 そのうえで、1. の場合は、コードの抽出と抽出したコードの実行の仕組みに工夫がいりそうですね。2. の場合は、文書としてはHaddockで処理してHTMLでみる程度でよければ全体をパッケージにするとそのまま利用可能なので結構便利かも。 [TFwHのサイト](http://tfwh.sampou.org/) はTravis-CIとは未連携で未完成ですが 2.の考え方でサイトを構成しています。 自動コンパイルの仕組みは設定していませんが、master はHaskellスクリプトで構成しておいて gh-pagesをstack haddockで生成したhtmlで構成するようにしてます。 [tfwhパッケージ](http://tfwh.sampou.org/docs/index.html) はパッケージとしての汎用性はないですが、 コードはすぐに試せるようになってます。

> コンテンツは markdown のまま何とかしてパッケージにする、というのはさすがにムリでしょうか？ markdown から有効なコードブロックだけを抽出して、モジュールファイルに変換するツールがあれば、 masterブランチのリポジトリを処理してcodeブランチ（名前は適当）を構成する仕組みが作れそう。 自動化の具体的な方法はよく判っていないですがなんとかなるかも。

文字列に関するレシピをすこしずつ書こうと思うのですが、 私の個人的な感覚としては、 - 項目が大きすぎて具体的にどのような場面で何が欲しくなるのかが想像しにくい - ミュータブルなデータの扱いを想起させないように命令風の表現を宣言風に変えたい ものがあるのですが、個別に議論のissueをopenしたほうがいいでしょうか。

たとえば、 - 「〜にマッチする」は、照合して何を得たいのかがわかりません。 - 「〜を処理する」は、処理して何を得たいのかがわかりません。

ありがとうございます。 「マッチする」「処理する」「解析する」については、見出しをより具体的な説明になるようにします。

（項目をかってに追加して）昔Qiitaに書いたものをすこし変えて載せてみました。 https://github.com/haskell-jp/recipe-collection/commit/16534271c529dc55d635a6726c65bb7208c78f82