2016/05/14

TeXと10年戦ってわかったこと

世間では「TeX」と一口に言われているけど、実際には3つの異なる側面があります。10年以上TeXで何かやってきたわけだけど、「TeXはアレ」の本質はこの3つがごちゃごちゃになってるとこかなと思ったりしているので、書いてみました。

  • マークアップ形式としてのTeX
  • 組版エンジンとしてのTeX
  • プログラミング言語としてのTeX

TeXの話をするときって、これら3つが案外と区別されていないなあと感じることがあります。具体的には、組版エンジンとしての機能について言及している場面でマークアップ形式の話を持ち出されたり、マークアップの話をしているときに名前空間がないからダメといった感じでプログラミング言語として批判されたり、ようするに、あまり建設的ではない。

もちろん、TeXというエコシステムについて何か言うときにはこの3つが不可分で、それぞれを切り出して論じてもしょうがないんだけど、まあポエムなので気にしないことにします。

マークアップ形式としてのTeX

TeXのマークアップというと\{}がやたらに出てくるアレを思い浮かべると思いますが、「いわゆるTeXのマークアップ」と見なされているものに厳格な文法とかルールはありません。 よく、「XML自体はマークアップではなくマークアップを作る仕組みを提供するものだ」と言いますが、TeXはさらにひどくて、シンタックスさえもが自分の知っているTeXでない可能性があるのです。

現状のTeXは、いろいろな人や団体が過去に考案してきた「マークアップ」を、使う人が自分のユーザ文書の用途に応じて混ぜて使っている状態だといえます。 なので、たとえば「TeXのマークアップのパーザがほしい」といった要件を満たすものがあるとしたら、それはTeXそのものになります。 この、ユーザが目的に応じていくらでも変更できる余地がある、というのが、マークアップとしてのTeXの革新的かつ悲劇的な点なのかなと思っています。

とはいえ、だいたい用途ごとに「デファクト」のマークアップはあって、たとえば文章そのものに対する基本的なマークアップの文法でいま主に実用されているのはLamportさんが拡張したLaTeXです。 この、LaTeXで導入され、現在に至るまで主に使われている「いわゆるTeXのマークアップ」は、なかなかよく考えられているなあと思います(もとをただせばScribeのアイデアだし)。 数式に対するマークアップも、Knuthが考えたオリジナルTeXにおける数式の書き方を延々と使っているわけではなく、現在ではアメリカ数学会AMSが拡張したやつが広く使われています。 TeXの中で図を使うためのマークアップは、文章や数式とは別体系で、これはいまはTikZが主流になっています。

拡張したマークアップをパーズするための仕掛けはプログラミング言語としてのTeXで作ります。 また、その出力であるレイアウトは組版エンジンとしてのTeXで実現します。

というわけで、TeXのマークアップはひどい、ふつうの人には無理、という意見は、種々のマークアップが混在していることからくる感想なのかもしれないと思います。 \{}$はオリジナルのTeXに沿って使われることが大半なので、どれも構文は緩く似た感じになり、「えー、なんでこんな一貫性がないのー」って感じますよね。 できることに制約がないので、たとえば「○○用のマークアップとかないし、別の表現にするか」という発想にならず、「○○したいだけなのにこんな複雑なことをしなければならないのかくそが」という感想になりやすいという面もあると思います。

文章に対するマークアップとして見た場合、LaTeXのマークアップは別に筋は悪くはないんじゃないですかねえ。 現代的な構造化もできるし、もちろん必要に応じて拡張もできる(←そこがアレ)。 「マークアップ形式拡張のためのAPIを設計するセンス」を養う本とかどこかにないかなあ。

組版エンジンとしてのTeX

一部のアレな人以外、TeXを使う目的は組版でしょう。これについては、あまり批判的な人はいない気がします。 TeXは当初から組版のための要件がかなり高く、しかもそれが一通り実現されています。 さらに、それなりに長い歴史のなかで、本職の組版技術を知る人たちが自分たちの必要とする付加的な要件を本気で実現してきました。 そのため、ほとんどの人にとっては、世界中の多くの言語で実用的なブラックボックスとして機能できていると思います (ふだん使っているTeXが組版についてブラックボックスに見えない人は、マークアップとしての側面と混同しているか、ただの組版のプロでしょう)。

プログラミング言語としてのTeX

なんというか、KnuthはもともとTeXをプログラミング言語として設計するつもりはさらさらなかったんじゃないかなあと思います。 自分の秘書でも使えるようなマークアップを自分で後から定義できるだけの機能を詰め込んだら、必然的にチューリング完全になってしまったというか。 あるいは、組版エンジンとして必要だろうなーと思う機能を作りこんでいて、その機能を外部からつつけるようにしたら、必然的にチューリング完全になってしまったというか。 とにかく、プログラミング言語としてのTeXにまともな設計思想はない気がするし、プログラミング言語として使いやすくする開発とかもされてこなかった。 なので使いづらいのは当然だし、使いづらさを楽しむのもまた一興かもしれません。 そもそもこれだけの機能がなかったら、後に続く人たちが「自分たちも仕事で使える」ものに魔改造できなかっただろうし(←その結果がアレ)。

とはいえ、そうも言ってられないという人たちは一定数いて、その先鋒がLaTeX3プロジェクトです。 それこそもう10年以上の歴史があるけど、過去のTeX資産を壊さないように慎重に開発が進められているので、いつになってもLaTeX3は完成しません(←だからアレ)。

とはいえ、LaTeX3のうちプログラミング言語として利用できる部分については現在のLaTeX2eでも使える状態にあります(expl3という)。 使いやすいかどうかはともかく、名前空間が実現できたり、関数っぽいものが定義できたり、プログラミング言語としてはふつうになってると思います。 次の10年に期待ですね(それまで選択肢がTeXしかないのも微妙だけど)。

2016/05/02

執筆・編集のためのGit(GitHub)ワークフローを考えてみた

まとまった量の文章を執筆・編集するのにバージョン管理システムを使うことは、少なくとも技術文書においては特別なことではなくなりました。 原稿が汎用のテキストファイルの場合には、バージョン管理システムとして、GitやMercurialなどのソフトウェア開発用のツールを使いたいことが多いと思います。 実際、GitHubやGitBucketを利用して技術書やドキュメントの原稿を共同執筆するという話はとてもよく聞きます(知っている世間が狭いだけかもしれないけど)。

とはいえ文章の執筆・編集という作業には、プログラムのソースコードを開発する作業とは違う側面もいっぱいあります。 そのため、ツールとしてはソフトウェア開発用のバージョン管理システムを利用する場合であっても、そのワークフローについては、執筆・編集ならではの工夫が多少は必要なのかなと考えています。

もちろん、同じソフトウェア開発でもプロジェクトの種類や参加者の考え方によって最適なワークフローは異なるだろうし、 ソフトウェア開発で成功するワークフローが執筆・編集には適用できないなんていうことでもありませんが、 こうやったら技術書を作る時にうまくいった、あるいはうまくいかなかったという経験に基づく考察をここらでいったん公開しておくのは悪くないかなと思ったので、まとめてみました。

なお、あくまでも経験に基づいた独断を書きなぐったものなので、これが正解と主張するものではないし参考文献とかもありません。 また、バージョン管理システムとしてGit(GitHub)が前提の書きっぷりになると思いますが、これも自分の経験に基づく話だからというだけです。 が、だいたいどのバージョン管理システムでも通用する話であろうな、とは想像しています。

目次

  1. 正史モデル:伝統的な文章のバージョン管理ワークフロー
  2. 執筆・編集というプロジェクトの実態
  3. 「じっくり読まなければ何となくいい感じ」が分水嶺
  4. 執筆・編集にとって最適(いまのところ)だと思っているGitワークフロー
  5. 余談:「じっくり読まなければ何となくいい感じ」に到達したことを知るには

正史モデル:伝統的な文章のバージョン管理ワークフロー

旧来、印刷して出版される文書は、初校、再校、念校、下版といった形式でバージョン管理されていました。 複数の関係者がいる場合には著者の代表や編集者が全員の意見(赤字)をマージして一つの修正指示を練り上げ、それが次の校正に反映されるというワークフローです。 つまり、正史が一つだけ存在するモデルです。

この伝統的な正史モデルのワークフローに、バージョン管理システムを適用したいとして、いちばん分かりやすいのは次のようなマイルストーンの細分化でしょう。

従来であれば数日から数カ月おきに確定するバージョン(初校とか再校とか)の間に、バージョン管理システムを使って細かくコミットを重ねていくイメージです。 さらにこのワークフローを突き詰めれば、初校や再校といった従来のマイルストーンの役割も消えて、全期間にわたってコミット履歴だけが並ぶことになるでしょう。 もちろん何らかのマイルストーンは設定することになるでしょうが、いずれにせよワークフローとしてはあくまでも一直線です。

このワークフローでは、みんなが同一のmasterに対してコミットを重ねていくため、誰かの作業内容が妥当であるかどうかを意識的に確認する役割の人がいるのがベターです。 ただし経験では、そのような役割を特定に人に押し付けるのではなく、関係者全員が「あれっ」と思った時点で履歴を検索して適宜blameや再修正をかけられるような空気があるほうが、うまく回ることが多かったと思います。 そのような空気は、関係者どうしの広帯域なコミュニケーションを通じて醸成されますが、 メール(メーリングリスト)、バグトラッキングシステム(TracやGitHub issue)、会議システム(SlackやSkype)を複数併用していた場合にわりとうまくいっていた印象があります。

執筆・編集というプロジェクトの実態

正史モデルのワークフローには、従来型の延長なので比較的導入しやすいというメリットがありますが、制限もあります。 このワークフローでは、どのコミットも、それまでの作業を塗りつぶして上書きする作業として扱います。 あとからコミット単位でrevertしたりrebaseしたりすることをあまり考慮していないワークフローだということです。

せっかくバージョン管理システムを使うのだから、作業の内容を明確化してブランチを切ったり、 それをあとからチェリーピックしたりマージしたり、逆に過去に加えた変更をなかったことにしたり、 そういうことができるほうがうれしいですよね。 正史モデルに拘泥してアドホックな上書き修正を積み重ねるのではなく、修正の意図や作業内容に応じてコミットをきっちり切り分けることで、原稿の変更による手戻を防いだり差分を見やすくしたりできるはずです。

ところが、経験上、文章の執筆・編集では作業内容ごとにコミットを整理したりブランチを切ったりするのが難しいなあと感じる場面がとてもよくあります。 文章の修正を局所的で互いに独立したコミットに収めることができず、コミットどうしが密に結合したり、一見すると巨大すぎるような修正コミットが発生したり、他の人の作業と競合したりしがちなのです。

もちろん、だからといって文章の執筆・編集では正史モデルで徹頭徹尾やるべきという話ではありません。 これまでの経験で感じるのは、うまくコミットとして切り分けられる問題もあれば、コミットとして切り分けるのが徒労でしかないような問題もある、という単純な事実です。 この二種類の問題を整理したところ、執筆・編集という作業には2つのフェーズがあり、この両フェーズを意識するとそこそこ最適なワークフローが説明できそうだなと気がつきました。

執筆・編集には2つのフェーズがある

正史モデルの説明では、「脱稿」以降のワークフローについてバージョン管理システムを使うかのように説明しましたが、あれは嘘です。 バージョン管理システムを使って、共著者、編集者、外部のレビュアーによる共同作業を始めるのは、脱稿よりも前の段階、具体的には「内容をすべて書き出した」時点であるべきです。

ここが重要なんですが、「内容をすべて書き出した」時点は脱稿とは異なります。 「内容をすべて書き出した」時点は、ソフトウェア開発でいうと、まだ最低限の機能がコンパイルすら通っていない状態です。 ここから待っているのは下記のような作業です。

  • 段落や節の見直し、統廃合、順序の入れ替え
  • それにともなう文章の書き直し、表現や語調の調性
  • 全体にわたる用字用語(漢字の使い方とか)の統一、誤用や誤植の修正
  • タグやメタ情報(ルビとか索引とか)の修正、追加

各作業について具体的な内容には踏み込みませんが、ようするに、全体にわたる読み直しとリライトを何度か繰り返すことで、これらの問題をひとつずつ潰していく必要があります。 そうやって確認と修正を繰り返していると、あるときふいに原稿が「じっくり読まなければ何となくいい感じ」になっていることに気づきます。 このへんでようやく、ソフトウェアでいえば警告を無視すればコンパイルが通った状態、つまり本当の意味での「脱稿」の一歩手前です。

「じっくり読まなければ何となくいい感じ」が分水嶺

「じっくり読まなければ何となくいい感じ」ゾーンまでくると、文書の骨組みや各文に対する大幅な修正は起こりにくくなります。 したがって、「どこそこのタイポ修正」とか「この文を修辞的に書き換える」とか「この段落は内容が疑わしい」といった具合に、文書に存在する問題を局所化できる場合が多くなります。 「どの箇所にどんな修正がなぜ必要か」をかなり具体的に切り出せるようになるということです。

修正が必要な箇所と、その意図をはっきり区分できるのだから、修正の妥当性や方針をissueで議論したり、必要だと判断できた修正を切り分けたり、そういった作業が現実的になります。 「じっくり読まなければ何となくいい感じ」にまで到達した原稿に対しては、issueやブランチを切ったうえで、それに従ってコミットを細かく管理したりPull Requestを発行したりするワークフローが可能だともいえます。

問題なのは、まだ「じっくり読まなければ何となくいい感じ」に到達していない原稿です。 この段階になっていない文章を読むと、「どの箇所にどんな修正がなぜ必要か」をはっきりとは明言しにくいけれど、とにかく何かしら修正が必要であると感じます。 経験上、この段階の原稿が抱えている問題の多くは、切り分けが困難な問題です。 そのため、バージョン管理という視点で考えると、作業を分担したり作業内容に応じたコミットやブランチを駆使しようという努力があまり実を結ばない気がしています。

表面的な問題:統一感と文の品質

「内容をすべて書き出した」時点での原稿は、ソースのバージョン管理という観点で見ると、下記のような問題を抱えている状態です。

  • 統一感がない
  • 読みにくい文がある「ように感じる」

統一感がない

「内容をすべて書き出した」時点の原稿で用字用語がきれいに整っているケースはまずありません。 言葉遣いや文体、文章の温度もまちまちです。 なんとなく統一感がない状態です。

用字用語が揺れているだけなら機械的に対処できる面はかなりあるし、そのためのツールもいくつかあります。 とはいえ、「いう」と「言う」の使い分けみたいな、書き手がふだんあまり意識せずに書いている表現ほど、自動的な統一だと不自然な結果になったり、そもそも自動化しにくいように思います。 結局、けっこうなボリュームの本を編集するときは、頭から読みながら気になった時点でgrepして全体に修正をかける、といった作業をある時点で誰かがやっています。 そして、この作業は、たとえば用語ごとに独立したコミットとして切り分けるのが案外と困難なのです。 しかも、経験上は切り分ける意味もほとんどありません。

文章の統一感を上げる作業を、独立した細かいコミットとして切り分けにくい(切り分ける意味があまりない)理由としていちばん大きいのは、単一の行に複数の用語揺れが混在するケースが珍しくないからです。 「行う」と「行なう」の揺れを正す作業と、「無い」を「ない」に開く作業を別々の人がやれば、「行なわ無い」という非標準的な表記を「行わない」に直すだけであっさり衝突します。

それでもコミットを細かく分割すべきという考え方もあると思いますが、個人的な意見としては、 これはソフトウェア開発で「関数の仕様を変更したので関数名と引数リストを同時に修正しなければならないが、コミットとしては関数名に対する修正と引数リストに対する修正とで区分する」みたいな話に近いと思っています。 つまり実質的には分割の意味がほとんどない。

もう一つの理由は、他の修正作業との関係です。 ソフトウェア開発でも、バグ修正とコーディング規約に合わせる作業を同時にやれば、同一の行に対して何度も修正、加筆、削除、入れ替えが発生し、そのため競合が発生しやすくなるでしょう。 文章でも、統一感を上げる作業を文章・段落・節全体などの見直し作業と同時にやれば、解消に手間がかかる競合が多発します。 そのため、たとえば「用字用語の統一」のためのブランチを切って作業し、後でPull Requestとして一発でマージ、といった理想的に見えるワークフローは、他の作業をまじめにやっているケースほど非現実的だと考えています。 この作業は、ブルトーザーで荒地を耕すようなものだと割り切って、見つけた誰かがmasterに対して随時pushしていくほうが経験上はうまくいきます。

読みにくい文がある「ように感じる」

プログラムなら、コンパイルして型エラーが出たりテストに通らなかったりすれば問題の位置がかなり絞り込めます。 文章でも、文法上のミスや文章の品質については、指摘して問題箇所を特定してくれるツールがいくつかあります(textlintとかRedPenとかJustRight!とかMS Wordの校正ツールとか)。 とはいえ、人間が読むために書いているものをチェックしようとしている以上、結局は誰かが読んで初めて見えてくる問題がかなりあるわけです。 文意に曖昧さがないかとか、語調が不自然でないかとか、そういう問題は実際に読んでみなければ見えてきません。

こういった問題を修正しようとして、「この文を読みやすくした」とか「文意をはっきりさせた」といった名目で局所的なコミットをたくさん作ってしまうと、あとで面倒なことになります。 というのも、文章を読むことで初めて見つかるような問題というのは、実際には文章レベルより上位の段落や節が抱える問題の一部であることが多いからです。 このような問題に対する局所的な修正コミットや、それを意図したPull Requestは、後述する「段落や節に対する俯瞰的な修正」のための作業と競合してしまいます。

このような競合では、「段落や節に対する俯瞰的な修正」のほうが修正として適切なことが多いので、「局所的な修正」の作業は単純に水泡に帰すことになります。 「じっくり読まなければ何となくいい感じ」未満の原稿では、「局所的な修正」は「段落や節に対する俯瞰的な修正」と競合するものだと考えたほうがいいでしょう。 この段階の原稿に対しては、コミットを小さくすることが正義とは限らないともいえます。 「段落や節に対する俯瞰的な修正」を先にやることにして、気が付いた局所的な問題はissueなどの形でコメントを残すのみにしておくのが無難かもしれません。

根本的な対策:段落や節にまたがる俯瞰的な修正

コードが適切にモジュール化されているソフトウェア開発であれば、それほど変更が衝突することなく、個々のモジュールに対する作業を別々の人が同時にできるでしょう。 文章でモジュールに相当するのは段落ですが、段落は互いに密に結合しているし、抽象的なインタフェースもないので、互いの順序や文章表現について同時に配慮が必要です。 そのため、段落ごとに執筆や編集を分担するという方法は、あまりいい結果になりません。 とりあえずまとまった量を読んでみないと問題を切り分けられないし、切り分けている途中で問題が直せてしまったりするので、 判断を下しながらある程度の範囲を集中して読み進める、という工程が必要になります。

で、そういう不備を直していると、結果としてまったく別の問題が解消されたりすることがよくあります。 段落がまるまる修正されたので誤植が消滅したとか、段落を直した結果としていまいち曖昧だった文意がはっきりしたとか、 リライトが必要と思われた節とほぼ同じ内容の説明が他の場所にあったので節ごと不要になったとか。 しかし、誰かが該当する文章を局所的に修正していたり用字用語の統一を全体にわたってかけたりしていると、当然、その部分で競合が発生します。

俯瞰的な修正の作業は、かなり大きな範囲全体でコミットとして意味を持つので、他でコミットされたりPull Requestされた局所的な文章の修正をこのコミットの内容と調整するのはけっこう厄介です。 経験上うまくいくのは、たとえば「1章の見直し」といった作業内容ベースでブランチを切り、別のブランチでの1章に対する修正は用字用語の統一くらいに留めておく(この程度なら手動でマージできる)というワークフローです。 修正する内容に対するブランチを作るのではなく、修正する範囲を区切るためにブランチを作るイメージです。 このブランチでは、最終的にmasterへと自動マージできるような状態を維持しながら(masterの内容をときどきmergeしながら)、修正作業を続けるようにします。

執筆・編集にとって最適(いまのところ)だと思っているGitワークフロー

以上、だらだらと背景を書いてきましたが、結論です。

「内容をすべて書き出した」状態から「じっくり読まなければ何となくいい感じ」ゾーンにもっていくまでの間は、各コミットに必要以上に意味を持たせることはあきらめましょう。 完全に正史モデルを採用する必要はありませんが、この段階は開墾地をブルトーザーで整地するようなものです。 「木を抜く」作業と「穴を埋める」作業は並行してできるわけではないし、あとから一方の作業だけをやり直したいことも通常はありません (将来もし穴が必要になるとしたら、それは別の作業として考えるべきでしょう)。 それなりの規模の区画ごとに、全体の出来を眺めつつ、もくもくと均していくのが現実的なはずです。

一方、「じっくり読まなければ何となくいい感じ」ゾーンまで到達した原稿は、問題とその対処がコミットとして明確に切り分けられるので、修正の意図をはっきりさせた最低限のコミットを作り、それをmasterにマージするようにしましょう。

まとめると、次のようなポリシーで執筆・編集をするのがよさそうだというのが現時点での結論です。

  • 「じっくり読まなければ何となくいい感じ」まで達している原稿は、これから入れる修正の意図を明らかにしたいので、issueで議論してからコミットしたり、ブランチを切ってPull Requestにしたりする
  • それ以前の段階では、用字用語統一、誤記修正、タグ追加などの作業はブルドーザーによる整形作業だと割り切り、細かく管理するのはあきらめる。経験上、どのみちrevertやrebaseが不可能な作業なので徒労に終わる。信頼できる担当者どうしで作業をしているなら、見つけた人がmasterに随時pushするのが、他の作業との競合を回避するためにも効率的
  • それ以前の段階における局所的な文章の修正は、「じっくり読まなければ何となくいい感じ」ゾーンまではissueやコメントに留める。それ以降はPull Requestにする
  • それ以前の段階における節以上の範囲におよぶ内容上の修正は、作業範囲を隔離するためのブランチを切って作業する(このブランチではmasterにおける用字用語統一などの修正を適宜取り込みながら作業をする。Pull Requestにしてからマージしてもよいし、手動でマージしてもよい)

このほか、本文では言及しませんでしたが、下記のようなポリシーも経験上は有効であると考えています。

  • 脚注追加のように独立性が高いコミットとして修正を加えられる場合には、どの段階でもPull Requestにしてよい
  • メタ情報を、永遠にマージしないブランチで管理することもできる。索引タグなどは本文にマージする必要がないかもしれない

余談:「じっくり読まなければ何となくいい感じ」に到達したことを知るには

というわけで、文章のバージョン管理では「じっくり読まなければ何となくいい感じ」に至る前後のフェーズでコミットに対する考え方を変えよう、というのが現時点での自分の結論なのですが、 そもそも原稿の状態がこのティッピングポイントを越えたことはどうやって知ればいいのでしょうか?

残念ながら分かりやすい指標はまだ手にしていません。 しかし、循環論法めいていますが、ほぼすべてのコミットの意図を明確にできるようになった原稿は「じっくり読まなければ何となくいい感じ」になっているといえそうです。 その瞬間に気づくためには、いま施している修正が他の修正に依存していないかどうかを常に意識しながらコミットを刻む必要があるのかもしれません。

2016/02/29

バイナリ化したデータ構造を外部のファイルに保存して、コンパイル時にHaskellソースに埋め込む

Haskellには連想配列のように使えるMapというデータ構造(Data.Map)があります。 実行中にキーと値を更新するつもりがなく、コンパイル時に生成される固定的なMapを実行時に毎回使うという場合には、 リテラルのリストをソースコードに書いてMapに変換して使うのですが、 リストのサイズが1万要素とかになるとソース全体が肥大化してコンパイルに無駄な時間がかかるようになります。 生のリストをコンパイルのたびになめる必要はないのだから、Mapに変換したデータを辞書のように外部に持っておいて、 それをソースから読み込んで使う方法があるに違いありません。(ようするに、RubyでいうMarshal、PythonでいうPickleがしたい、ということです。)

他のファイルの内容をHaskellソースに埋め込むには、一般にTemplate Haskellが必要です。 ありがたいことに、外部のファイルの内容をソースコードに埋め込む機能に特化したfile-embedという便利なパッケージが用意されているので、これをTemplate Haskellと一緒に利用してこの問題を解決してみました。

バイナリの辞書を作る

まず、外部に保持するバイナリ辞書を下記の手順で用意します。

  1. リストからMapを作る
  2. そのMapをバイナリ化する
  3. さらにGzipで圧縮
  4. 結果を別ファイルに書き出す

コードにするとこんな感じ。このコードはバイナリの辞書(Map)を生成するだけなので、コンパイルと実行はきっかり一回だけです。

mkdict.hs

{-# LANGUAGE OverloadedStrings #-}

import qualified Data.ByteString.Lazy as BSL
import qualified Data.ByteString.Lazy.UTF8 as BSLU
import qualified Data.Map as Map
import Codec.Compression.GZip (compress)
import Data.Binary (encode)

dictList :: [(Int, BSLU.ByteString)]
dictList =
  zip [1..] $
      (map BSLU.fromString ["西住", "武部", "秋山", "五十鈴", "冷泉", ...その他大勢 ]

main = do
  BSL.putStr $ compress . encode . Map.fromList $ dictList
  return ()

ここでのポイントは、Mapのもとになる連想リストに日本語などの多バイト文字列がある場合、Data.TextではなくData.ByteString.Lazy.UTF8を使うことです。 なぜData.Textが使えないかというと、バイナリ化に使うData.BinaryData.Textに対応していないためです。 また、Data.ByteString.Lazy.Char8ではバイト列がぶった切られて日本語の文字が壊れてしまうので、結果的にData.ByteString.Lazy.UTF8を使うしかありません。(ほかによい方法があったら教えてください)

バイナリ辞書をソースに埋め込んで使う

上記で生成したバイナリ辞書をdict.datのような名前でどこかに保存したら、 下記のようにしてHaskellソースに埋め込んで使います。

  1. embedFile関数にファイルを指定すると、Template HaskellのQモナドにくるまれたデータが返ってくるので、これを$(...)で取り出す(というかソースファイル中に接ぎ木する)
  2. 接ぎ木されるデータは正格なByteStringなので、fromChunksで遅延ByteStringに変換する(fromChunksはByteStringのリストをとるので、リストの文脈に入れるためにreturnしている)
  3. 圧縮された状態を解凍
  4. バイナリをほどく

getmessage.hs

{-# LANGUAGE TemplateHaskell #-}

import qualified Data.ByteString.Lazy as BSL
import qualified Data.ByteString.Lazy.UTF8 as BSLU
import qualified Data.Map as Map
import Data.FileEmbed (embedFile)
import Codec.Compression.GZip (decompress)
import Data.Binary (decode)

dictMap :: Map.Map Int BSLU.ByteString
dictMap = decode . decompress $ BSL.fromChunks . return $ $(embedFile "data.dat")

getMember id = putStrLn $ case Map.lookup id dictMap of
  Just x -> BSL.toString x
  Nothing -> error $ "No entry for " ++ id

実行結果

$ ghc mkdict.hs -o mkdict
[1 of 1] Compiling Main             ( mkdict.hs, mkdict.o )
Linking mkdict ...
$ ./mkdict > data.dat
$ ghci
GHCi, version 7.10.3: http://www.haskell.org/ghc/  :? for help
Prelude>  :l getmember.hs
[1 of 1] Compiling Main             ( getmember.hs, interpreted )
Ok, modules loaded: Main.
*Main> getMember 3
秋山
*Main> getMember 5
冷泉
*Main>

参考資料

Compiling in constants(Haskell Wiki)
Gzipしたバイナリデータのリテラル表現をソースに埋め込んでいる事例(そんな人間が見ても意味がないデータをソースに貼り付けるのはいやだ)。 バイナリ辞書をCに変換して利用する例も紹介されているけど。
Haskellでバイナリデータ(yuga/gist:8255552)
Data.Textに対応したバイナリライブラリがなさそうなんだなということが分かりました。
How to compile a resource into a binary in Haskell?(Stack Overflow)
file-embedパッケージの存在を知りました。

2016/02/21

ターミナルモードのEmacsでHaskellを書いているときに補完候補をポップアップしてくれるcompany-ghc

Haskellのコードを書くときは、Windows 10からTeratermでDebianサーバにSSH接続し、そこでEmacsを-nwで起動して使っています。 標準のhaskell-modeでとくに不満はないのですが、いちおうghc-modも入れていて、単純なエラーの確認にはとても重宝しています。 でも、ghc-modの補完機能はほとんど使っていませんでした。補完のためのコマンドが手になじまず、調べている間に手打ちしてしてしまうので、ちっとも身に付かなかったからです。

とはいっても、ある程度の量を書いていると、やはり手で打っているのではしんどくなってきます。何とかならないかなーと思っていたところ、company-ghcというものを発見しました。

Company GHC
https://github.com/iquiw/company-ghc

ターミナルで開いているEmacsでも、統合開発環境のような補完メニューを実現するcompany-modeというツールがあって、そのHaskell版をghc-modを介して実現するためのパッケージらしい。試しにインストールしてみたところ、こんなふうに、まるで統合開発環境のようになりました。これならぼくにも使えそう。

インストールと設定の概略

すでにghc-modを入れているなら、そのインストール時にEmacsのパッケージをMELPAから取得できる状態にしていると思います。その場合は、M-x package-installcompany-ghcを指定するだけで、必要なパッケージを含めてインストールしてくれます(したがって事前にcompany-modeを個別にインストールする必要もありません)。MELPAからパッケージを取得する設定にしていない場合は、init.elかどこかに以下を設定します。

(require 'package)
(add-to-list 'package-archives
  '("melpa-stable" . "http://stable.melpa.org/packages/") t)
(package-initialize)

無事にインストールできたら、まずはcompany-modeを有効にします。haskell-mode利用時のみ有効にすることも可能ですが、せっかくなのでグローバルに有効にしておきます。そのほうがCtrl-c Ctrl-lでGHCiを起動したときにも補完が効くようになるし、いろいろ便利なはず。

(require 'company)
(global-company-mode)
あとは下記のようにcompany-ghcを設定すれば完了です。
(add-to-list 'company-backends 'company-ghc)
(custom-set-variables '(company-ghc-show-info t))

これだけでもとりあえず動くはずですが、company-modeのパラメータを少しいじったほうが使いやすそう。

(setq company-idle-delay 0.5)          ; 補完候補を表示するまでの待ち時間
(setq company-minimum-prefix-length 2) ; 補完候補の表示を開始する入力文字数
(setq company-selection-wrap-around t) ; 補完候補のスクロールが末尾に到達したら先頭に戻る

さらに、補完候補がポップアップ表示される際の背景色などを好みで設定します。下記の設定に加えて、Teratermの[ウィンドウの設定]で「256色モード(xterm形式)」にチェックが入っていて、かつサーバ側の環境変数TERMxterm-256colorに設定されていないと、とても日常の使用には耐えない悲惨なユーザインタフェースになってしまいます。

(set-face-attribute 'company-tooltip nil                  ; ポップアップ全体
  :foreground "black" :background "ivory1")
(set-face-attribute 'company-tooltip-common nil           ; 入力中の文字列と一致する部分
  :foreground "black" :background "ivory1")
(set-face-attribute 'company-tooltip-selection nil        ; 選択項目の全体
  :foreground "ivory1" :background "DodgerBlue4")
(set-face-attribute 'company-tooltip-common-selection nil ; 選択項目のうち入力中の文字列と一致する部分
  :foreground "ivory1" :background "DodgerBlue4")
(set-face-attribute 'company-preview-common nil           ; 候補が1つしかなくて自動で入力される場合
  :background "black" :foreground "yellow" :underline t)
(set-face-attribute 'company-scrollbar-fg nil             ; ポップアップのスクロールバー
  :background "Midnight Blue")
(set-face-attribute 'company-scrollbar-bg nil             ; ポップアップのスクロールバー
  :background "ivory1")

これで、最初の例のように、いい感じに補完候補が表示されるようになりました。

ちなみに、上記の色の設定例で「候補が1つしかなくて自動で入力される場合」とあるのは、下記のように候補が決定的になった状況のことです。

項目を選択した状態で[F1]を押すと、その項目のヘルプも見られます。

関係ないけど、TeXも捗る。

2016/02/09

LaTeXで連番リストに丸数字(\ajMaru)を使えたはずだけどhyperrefで困る話

LaTeXで丸数字の連番リスト環境の基本

そもそもLaTeXで丸数字を使いたいときは、otfパッケージajmacros.styの機能を使うのが一番お手軽です。 このスタイルでは、数値を指定してさまざまな囲み数字のグリフ(あれば)を呼び出すという便利な機能が提供されています。 たとえば、ふつうの丸数字であれば、\ajMaru{数値}として出力できます。

\ajMaru{1}、\ajMaru{100}、\ajMaru{101}

一方、enumerate環境でラベルのスタイルを変えたいときは、\theenumiとか\theenumiiといったコマンドを再定義します。 \theenumi\theenumiiは、それぞれ「enumi」や「enumii」という名前のカウンタに対応した「アラビア数字」に展開されるコマンドです。 その結果がenumerate環境でラベルを表示するのに使われているので、これらのコマンドの挙動を変えることで別の種類の数字を出力できるというわけです。 たとえばこんなふうにすれば、ラベルが大文字のローマ数字であるような連番環境が作れます。

\renewcommand{\theenumi}{\Roman{enumi}}
\begin{enumerate}
  \item 最初\label{A}
  \item\label{B}
\end{enumerate}
最初は\ref{A}、次は\ref{B}。

以上の知見を組み合わせれば、こんなふうにして丸数字の連番環境が作れそうです。

\renewcommand{\theenumi}{\ajMaru{enumi}}

しかしこれはうまくいきません。\ajMaruの引数は数値でなければならず、enumiはあくまでもカウンタの名前だからです。

ではどうすればいいかというと、ajmacros.styに用意されている\ajLabelというコマンドを使います。 このコマンドは、後続の\ajMaru{enumi}の中身を実際のカウンタ値として取り出してくれるように定義されています。

\renewcommand{\theenumi}{\ajLabel\ajMaru{enumi}}
\begin{enumerate}
  \item 最初\label{A}
  \item\label{B}
\end{enumerate}
最初は\ref{A}、次は\ref{B}。

hyperrefと一緒に使えなくなっているっぽい(2016年2月現在)

本当ならこれで話は終わりのはずなんですが、相互参照をクリッカブルにしてくれるhyperrefパッケージを同時に使うと話がややこしくなります。 hyperrefは、相互参照をクリッカブルにするためにカウンタ関連の機能をいろいろ勝手にオーバーライドするという鬼仕様なのですが、 ajmacros.styではそれに振り回されないように、 hyperrefを読み込んだ場合には\begin{document}の時点で\ajLabelなどをhyperref用にカスタマイズし直してくれます。

しかし、さらに厄介なことに、hyperrefはときどき内部の振る舞いをドラスティックに変更します。 そのため、せっかく再定義されている\ajLabelがまた使えなくなるという事態が2016年2月現在では発生しているようです。 具体的には、以下のような例で、上記のような事情を理解していないとちょっと追跡しにくいエラーが起きます。

\documentclass[dvipdfmx]{jsarticle}
\usepackage{otf}
\renewcommand{\theenumi}{\ajLabel\ajMaru{enumi}}
\usepackage{hyperref} % hyperrefを使う
\begin{document}
\begin{enumerate}
  \item 最初\label{A}
  \item\label{B}
\end{enumerate}
最初は\ref{A}、次は\ref{B}。
\end{document}

実行例

...
! Undefined control sequence.
\ajLabel ...abel \@arabic \else \Hy@ReturnAfterFi
                                                  \hyperref@ajLabel #1\fi {
l.17  \item 最
              初\label{A}
?

エラーが起きている\Hy@ReturnAfterFiは、かつてはhyperref.sty内で定義されて使われていたようですが、現在のhyperrefでは使われていないため、このような事態になってしまうようです。hyperrefパッケージのSVNのログを見ると、どうやら2011年4月に消えたようですね。

[hyperref-svn] oberdiek: r1291 - trunk
http://mail.gnu.org.ua/mailman/listarchive/hyperref-svn/2011-04/msg00002.html

上記のログを見る限り、oberdiekバンドルのltxcmdsパッケージで定義されている\ltx@ReturnAfterFiを使うようにしたので、\Hy@ReturnAfterFiをディスコンにしたようです。 \ajLabelの再定義では、この\Hy@ReturnAfterFiを利用しているので、上記の例がうまく処理できない結果になっているようです。

そこで、\Hy@ReturnAfterFi\ltx@ReturnAfterFiに変更するだけの以下のパッチをajmacros.sty(1.7b6)に当てて試したところ、意図した挙動に戻りました。 (\Hy@ReturnAfterFi\ltx@ReturnAfterFiの定義は同一なので当然といえば当然なのですが。。)

--- ajmacros.sty.org    2016-02-09 16:16:17.700785982 +0900
+++ ajmacros.sty        2016-02-09 16:15:57.548561902 +0900

@@ -685,7 +685,7 @@
 %      \def\check@UTF##1##2##3{\ifx\UTF##1\0x##2\else##3\fi}}{}}
 \gdef\ajRedefine@ajCommands{\@ifpackageloaded{hyperref}{%
        \let\hyperref@ajLabel\ajLabel
-       \def\ajLabel##1##{\ifHy@pdfstring\Hy@ReturnAfterElseFi\hyperref@ajLabel\@arabic\else\Hy@ReturnAfterFi\hyperref@ajLabel##1\fi}%
+       \def\ajLabel##1##{\ifHy@pdfstring\Hy@ReturnAfterElseFi\hyperref@ajLabel\@arabic\else\ltx@ReturnAfterFi\hyperref@ajLabel##1\fi}%
        \ajRedefine@ajCommand\"${Lig"$}\"&{Lig"&}\!*{Lig>.}\ajLig{Lig}\ajPICT{PICT}\"({PICT}\ajVar{Var}\@nil\@nil
        \aj@Redefine@ajCommand!{{Maru}!|{KuroMaru}""{Kaku}"#{KuroKaku}!~{MaruKaku}"!{KuroMaruKaku}\@nil\@nil
        \def\!J##1!K{\ifHy@pdfstring(##1)\else\expandafter\ifx\csname ajLig(##1)\endcsname\relax\@ajnumber{##1}{Kakko}%

hyperrefは、電子書籍をLaTeXで制作するうえでは唯一無二のパッケージなのですが、ときどきこういう面倒が起きるのがつらい。。

まとめ

またhyperrefか。

2016/01/27

技術書編集者として「これはやられた!」2015年の本

技術書の年間ランキング的なものについて、編集者たちに「これはやられた!」と思う他社の本を候補として出させたら面白いのでは、という会話を小耳にはさみました。これはまたとないアマゾンアソシエイトの機会!ということで、勝手に自分の候補を上げてみます。

と思ったものの、新刊の技術書をそんなにたくさん読んでいないうえに、去年「これはやられた!」と思った本はいずれも技術書ではなく、どちらかというと数学書っぽい本ばかりでした。それでも、ジュンク堂池袋本店の「新春座談会 このコンピュータ書がすごい! 2015年版」で取り上げられた本ばかりだし、たぶん技術者が読む(べき)本としても妥当なはずです。

コンピュータは数学者になれるのか? -数学基礎論から証明とプログラムの理論へ-

いま自分の本棚を見返したら、この本の隣にたまたま『日本の著作権はなぜこんなに厳しいのか』が並んでいて、一瞬だけ姉妹書に見えました。疑問形タイトル、文芸系とかビジネス系の出版社だと割と普通に見かけるけど、自分で本を企画するときには扱い方がわからず避けてしまうので、そういう書名を使いこなせる編集者になりたいです。というか、たぶん疑問形タイトルって、「これは既成の考え方をなぞった本ではなく、なおかつ人類は読むべきである」ことについて相当な自信がないと付けられない書名な気がします。

この本の場合、コンピュータと数学者のことを「算術計算に秀でたモノ」と考えている人にとっては、確かに「既成の考え方をなぞった本」ではないのでしょう。しかし、コンピュータとは自分が考えたプログラムが本当に動くことを確かめるためのものであるという人や、数学者はコーヒーから証明を生成する仕事であると気づいている人にとっては、どこかで見聞きして知っていたり知らなかったりする話にぐさっと明快な筋道を通してくれる本でした。一般向けの数学の読み物で見かける話も含まれてますが、call/ccは背理法ありの古典論理で純粋関数型言語は直感主義論理に対応しているんだという第5章のクライマックスに至る話を素で楽しめるのは、実際にプログラムを書いている技術者の特権だろうと思います。

出版社は青土社です。選択公理の読み物として一部で有名な‟The Pea and the Sun: A Mathematical Paradox”(Leonard M. Wapner)の翻訳である『バナッハ=タルスキの逆説 豆と太陽は同じ大きさ?』をはじめ(原書しか読んでないので翻訳の出来は知らない)、意外に「え?」っていう理学系の本も出してくるし、割と好きです。「現代思想」とか「ユリイカ」でも思想的な文脈で現代数学の記事をたまに掲載しているし、そのうち計算機科学や機械学習の特集もあるに違ない。

圏論の歩き方

Haskellを使うのに圏論はいらないって言うけど、みんな圏論圏論って言ってるので、どうしたって圏論が気になりますよね。そんな人間を狙いうちする本が日本評論社から発売されました。タイトルどおり、圏論の名所をめぐるツアーガイドのような本です。いつか自分の足で行ってみたいけど余裕がなくて行けない場所へ行った気になれる本です。去年の夏に読んで、いまこうやって記事を書くつもりで内容を要約しようとしても、さっぱり具体的な言葉にできないんですが、そのへんもツアーガイドに似ています(実際、「地球の歩き方」なんかにしても、行く場所を決めるときに読んだ内容をあらためて説明しろと言われても言葉に詰まりそう)。

正直、この本のうち計算機に関する部分については、まさに自分でこんな本を作りたかったという気にさせてくれる本でした。この本が企画として面白いと思うのは、コンピュータ書でいえばフレームワークに対する「クックブック」のような本を、数学の一分野で形にしてしまった点です。数学書、コンピュータ書でいえば「コードの動作について説明しただけ」だったり「コード読めばわかるよね」だったり、そんな立ち位置の教科書が少なくない気がします。コンピュータ書の場合には、実行例を見せることで「どんな場面でどんなコードが必要なのか」を説明できたりしますが、それを数学書でやったのがこの本なのかなあと思いました。いわば「圏論の実行例」。あるいは「圏論のクックブック」。もし何らかの事情で圏論について本当に「わかる」必要があるなら、体系的に書かれた教科書を読みながら紙と鉛筆で勉強するのが近道なんですが、そうやって教科書の証明を読み進めるときの「実行例」だけが本として、しかも圏論みたいな分野で出たということで、自分のなかでは「これはやられた!」一冊でした。

あなたの知らない超絶技巧プログラミングの世界

自分が過去に企画にできなかった本が企画化され、しかも想像以上に出来がいいのだから、「これはやられた!」一冊として選ばざるをえない。発売当時、くやしさをばねに紹介記事を書いたので、そちらを読んでください。

2016/01/08

英数字文字列を任意位置で改行するTeXパッケージを使う話

技術系のドキュメントでは、長い連続した英数字からなる文字列を等幅フォントで組む必要に迫られることが多々あります。 本文中にそんな文字列が連続して出現する原稿を、字間が異常に空いたり版面をはみ出したりすることなく組版するためのベストプラクティスは、有識者の間でも意見が分かれるようです。 うまく自然な改行位置に収まるように原稿のほうに手をいれられればベストですが、政治的経済的な理由で困難だったり、そもそも解説内容からして無理筋という場合もあります(Javaの変数名とかJavaの変数名とか)。

よくあるのは、空白やハイフンや記号文字の直後に恣意的な改行位置を指定する、という方法でしょう。 変数名を英単語の組み合わせだとみなすなら、この方法が自然に思えます。 キャメルケースの大文字の手前を恣意的な改行位置にすることもありうるでしょう。

しかし、「英単語として有意味な改行位置」は、このような文字列にとって必ずしも適切な改行位置ではないはずです。 たとえば、空白とかハイフンで区切ってしまうと、文字列のその部分に文字通り空白やハイフンがあるのか、たまたま改行があって空白やハイフネーション記号が挿入されているのか、区別しにくくなります。 キャメルケースの大文字の手前で改行されていると、その位置に文字通りの空白が入る可能性が気になって仕事になりません。 もちろん読者として読むなら意味を考えて区別できるんですが、作り手側にいると「勘違いして読まれたらまずいのでは」という不安をぬぐえないということです。

で、最近は、任意の文字間で改行するという思い切ったルールにするほうが理に適っているのではないかと考えるようになりました。 つまり、英数字の文字列ではあるけど、日本語や中国語のように組むわけです。 任意の音節区切りで改行くらいのほうが穏当な気もしますが、Webページだとword-wrap: break-word;が指定されている例も見かけるし、これをTeXでやってみようというのが本題です。

結論から言うと、seqsplitというパッケージがあります。もともとはDNAなんかの塩基配列を組むためのパッケージで、TeX Liveにも入ってます。 つまり、acgtの4文字からなる長大な文字列をページに組むことを目的にしています。 これを以下のような感じに使うことで、任意の位置で改行可能なバージョンの\textttが実現できます(実行例

\usepackage{seqsplit}
\usepackage{fancyvrb}
\VerbatimFootnotes

\makeatletter
% \def\seqinsert{\ifmmode\allowbreak\else\hspace{0pt plus 0.02em}\fi
\def\wordwraptt{\begingroup\obeyspaces\do@codeline}
\def\do@codeline#1{\texttt{\seqsplit{#1\relax}\endgroup}}
\makeatother

\begin{document}

Wikipediaによると、Brain*uckでは
\wordwraptt{%
++++++++[>++++[>++>+++>+++>+<<<<-]%
>+>+>->>+[<]<-]>>.>---.+++++++..+++.>>%
.<-.<.+++.------.--------.>>+.>++.%
}というHello World!プログラムが書けます。

\end{document}

fancyvrbパッケージを読み込んでいるのは、\VerbatimFootnotesを使うためです。 このコマンドが提供するような仕組みがないと、\wordwrapttを脚注に配したときにスペースがなくなってしまいます。

改良したい点として、事前に中身の文字列を数えてあまり短いものは改行しないようにするといった処理もしたほうがよさそう。 (\penaltyによる調整は試してみたけれどあまりうまくいかなかった。)

なお、上記のような異常ケースでない場合は、Listingsというパッケージを使って\lstset{breaklines=true, breakatwhitespace=true}という設定をしてあげることで、そこそこ妥当な結果になるかもしれません。

(追記)さっそく改良案をいただきました。

あながちネタでもないと思っていて、似たようなことは考えていました(さすがに雪だるまをつかう発想はなかったけれど)。 上の例のコードブロックではコメントアウトしてある\seqinsertの再定義部分を書き換えると、このようなことが可能になります。


宣伝

TechBoosterがC89で頒布した6点のラインナップでは、上記のような仕組みを使うことで、Re:VIEWからでは制御困難な長い変数名の折り返し調整をなんとかしてみました。 が、コマンド中のスペースの存在を根本的に見逃すという大変残念かつ申し訳ない失敗をしています。本当にすみません。 電子版はなおっているはずなので、本誌に挿入されているQRコードでぜひ電子版も入手してください><

TechBooster in C89 特設ページ

というわけで、いろいろ微妙なTeXマクロだけど(LaTeXのことは知らない)、冒頭のツイートで思い出したのでネタとして。