2019Tweet現職でHaskellを仕事で書き始めるようになってからというもの、度々小さなパッケージをリリースするようになりました。パッケージにするほどのものでもなさそうなぐらい小さなものが多いですが、もし再利用したくなったらな、という気持ちで書いております。tohereなに作ったかstrip-ansi-escapeというパッケージです。今回もメインの処理は100行にも満たないような小さなもので、また用途もニッチです。具体的には、名前のとおりANSIエスケープコードを文字列から取り除く、ただそれだけです。tohereなぜ作ったか通常我々がANSIエスケープコードを扱うときは、ユーザーのために端末に文字列を分かりやすく表示したいときで、それをプログラムで再利用することは想定していません。そのためANSIエスケープコードを出力できるアプリケーションは、大抵の場合出力しないよう設定できる(あるいは、出力先がttyでないことを検出して出力しない)ようになっています。プログラムがANSIエスケープコードの混ざった文字列を扱わざるを得ない、という事態は、何かがおかしい事態だと言えるでしょう。「失敗しながら学ぶHaskell入門」(以下、英語名を略して「mmlh」と呼びます)では、ユーザーが書いたHaskellのソースコードを受け取って、GHCにコンパイルさせることで、型エラーなどのエラーメッセージを取得しています。当初からmmlhはそれを簡単にパースしてユーザーへのヒントを出すのに使ったり、ユーザーにそのまま表示したりするのに使うため、-fdiagnostics-color=alwaysというオプションをGHCに渡していました。8.2から導入されたオプションで、「エラーメッセージに必ず(ANSIエスケープコードを使って)色を着ける」というものです。GHCが出すエラーメッセージを「簡単にパース」しつつ「ユーザーにそのまま表示」する、という2つの要件を満たすためには、このオプションを利用して、強制的にエラーメッセージに色を着ける必要がありました。最近、GHCが出したエラーメッセージをファイルに保存して、GitHubで閲覧できるようにする(正確には、閲覧して各行にコメントできるようにする)、という機能も追加した結果、ANSIエスケープコードを取り除かざるを得なくなってしまったのです。いうのも、-fdiagnostics-color=alwaysを有効にしている限り、GHCは必ずANSIエスケープコードをエラーメッセージに混ぜるので、ファイルに保存してGitHub上で表示する際、下記のように余計な文字として混ざってしまい、エラーメッセージが読みづらくなってしまうためです。^^^^^^^^^^^^^^^^^^^^^^^^^^^^^�[0m�[0m�[0m�[0m�[0m-fdiagnostics-color=alwaysを有効にしなければこんな問題は起こらないのですが、そうすると今度はユーザーにエラーメッセージを表示させる際、色が着かなくなってしまいます。8.2以降を使っているのに色つきのエラーメッセージが見られないのは残念ですよね。GHCを2回実行することで、ユーザーに表示する用のエラーメッセージとファイルに保存する用のエラーメッセージを分けることもできますが、それでは効率が悪いでしょうし。そんなわけで、GHCが出力するエラーメッセージをユーザーに端末上で表示する用途と、ANSIエスケープコードを解釈しない箇所で表示する用途、両方に使用したくなったため、今回敢えてANSIエスケープコードを取り除くライブラリーを作りました。tohere最近のmmlhついでにここ数ヶ月弊社でやっている、mmlhを使った社内勉強会のお話も書こうかと思いましたが、やっぱり社内でのことなんで、会社のブログに書くことにします。ライセンスの下に提供されています。Analyticsでアクセス情報を収集しています。集めた情報は統計的に処理した上で、当ウェブサイトの改善のための参考情報としてのみ使用します。