NixによるHaskell開発環境の構築

Nix package manager によって Haskell のスクリプティングおよびパッケージ開発の環境構築をしていく。

こいついつも環境構築してんな

環境構築以外はブログに書くような一般性のあることをやっていないということで……。

ここで触れられないこと

• cabal.project によるマルチプロジェクトを扱う方法
• 外部の nix store を使うこと
• nix の新しいコマンド群 (nix コマンドのサブコマンド群)
• デプロイや公式 Docker イメージについて
• Stack integration
• IOHKのリソース
• NixOS
• その他 Nix の深い話

Nix

Nix がなにかよく分からないが様々な環境で使えるパッケージセットとして利用している。

そこだけ聞くと stackage みたいだが全然 Haskell に閉じたものではなくて普通の OS のパッケージマネージャのようなカバー範囲を持っている。 それでいて Haskell のライブラリ依存関係も相当なリソースを投入して安定に保たれているということのようだ。

自分は Mac と Ubuntu on WSL で同じ設定ファイルで Haskell の環境を構築できている。

さて Nix で検索すると NixOS というのが出てくるが OS を考えずにパッケージマネージャだけ利用することができる。

利用形態:

• Nix package manager のみ
• NixOS と Nix package manager

Nix ではパッケージセットを channel と呼び、これには何種類かある。
https://nixos.wiki/wiki/Nix_channels

Nix channel:

• nixpkgs-unstable (= nixpkgs)
• NixOS-xx.yy (NixOS-21.11 など)

NixOS channel は名前の通り NixOS 用であり Nix package manager だけのときに使うことは推奨されない。 つまり Nix package manager のみの利用のときには nixpkgs を使うことになる。 なお nixpkgs-stable という channel はないようだ。

プロジェクトの環境を固定したいときはこの channel のバージョンを固定すればいい。
https://nixos.wiki/wiki/FAQ/Pinning_Nixpkgs

スクリプティング

まず、Nix を使わなくても Haskell スクリプティングはできる。 cabal および stack のスクリプトはだめぽ氏による記事がとても参考になると思う。
https://zenn.dev/mod_poppo/scraps/e2891dbebb235d

Nix による方法は、まず Nix package manager をお使いの環境にインストールする。

https://nixos.org/download.html

するとシンプルなスクリプトは以下のように書ける (標準入力から1行読んで適当な色をつけて出力するスクリプト)。

> echo "ヤッホー" | ./yamabiko-nix.hs
ヤッホー

nix-shell は Nix の環境の中に入るためのコマンドだが、 shebang に書くことで特殊な動作をしてそのスクリプトを Nix 環境の中で実行するように動く。

コマンドライン引数は複数行に分けて記述できる。

• -p / --packages: 依存パッケージを指定。デフォルトの channel は nixpkgs が選ばれる。
• -i / --interpreter: このスクリプトを処理するコマンドを指定。

パッケージ指定が Nix Haskell の特徴的な記述になっている。 これは次のように構成されている。

• pkgs: nixpkgs のルート
• haskell.packages.ghc921: GHC 9.2.1 用の Haskell 依存関係の名前空間
• ghcWithPackages: 依存ライブラリとGHCを同時に指定するための Nix 式 (関数)
• p: [p.ansi-terminal]: 依存ライブラリのリストを返す無名関数 リストはスペース区切り

GHCバージョンにこだわりがない場合 haskell.packages.ghc921 を haskellPackages で置き換えてもいい。

選択可能なGHCバージョンは次のコマンドでわかる。

> nix-env -f '<nixpkgs>' -qaP -A "pkgs.haskell.compiler"
pkgs.haskell.compiler.ghc8107                 ghc-8.10.7
pkgs.haskell.compiler.ghc884                  ghc-8.8.4
pkgs.haskell.compiler.ghc902                  ghc-9.0.2
pkgs.haskell.compiler.ghc921                  ghc-9.2.1
...

また channel で管理されている依存ライブラリのバージョンは次のコマンドでわかる。

> nix-env -f '<nixpkgs>' -qaP -A "pkgs.haskell.packages.ghc921.ansi-terminal"
pkgs.haskell.packages.ghc921.ansi-terminal  ansi-terminal-0.11.1

ghcWithPackages の実装は ここ にある。 GHCとライブラリを別々に指定してしまうとGHCがライブラリを見つけられないらしい。

ちゃんとした開発

haskell-language-server の導入

haskell-language-server はエディタが見るものだし、 複数のGHCバージョンに対応するものでもあるので、 他に使いそうなものと一緒にグローバルにインストールしてしまう。

次のファイルを $HOME/nix/haskell/default.nix にでも用意して nix-env -i をたたくとグローバルにインストールされる。 (この default.nix は こちら を参考にさせてもらっている)。

> nix-env -i --file $HOME/nix/haskell/
...
building '/nix/store/knnnspc3dxxbk9nwv9rqznrrf01rrl8d-user-environment.drv'...

overlay によって haskell-language-server にオプションを与えている。 supportedGhcVersions は読んでの通り。

dynamic=true については何のドキュメントも見つけられないが Template Haskell のコードを扱うなら必要なようだ。 ただしこのオプションを有効にすると haskell-language-server のインストールに余計に時間がかかるかもしれない。 オプションの実装は ここ にある。 haskell-language-server 側のドキュメントでは ここ に相当する処理をしていると思われる。

パッケージの設定

Nix での Haskell 開発について調べていると cabal2nix という名前がよく出てくるが、これを直接使う機会はあまりなさそうだ。 今は nixpkgs の Haskell module が cabal2nix をラップした便利関数をいろいろ提供していて、 それらを使うのが主流のようだ。 この記事でも cabal2nix を直接は使わない方法を説明する。

まずはいつものように cabal init でパッケージを初期化する。 (--enable-nix オプションは不要かもしれない)。

> mkdir test-package
> cd test-package
> nix-shell -p "pkgs.cabal-install" -p "pkgs.haskell.compiler.ghc921" --run "cabal --enable-nix init --exe"

初期化ができたら次のような default.nix を用意する。

これで次のようにすればパッケージの executable が実行できる。 (nix-build は初回だけでいいはず)。

> nix-build
> nix-shell --run "cabal run"
"Hello, Haskell!"

あとは普通に .cabal ファイルを編集して開発していけばいい。

さて、この default.nix は nixpkgs の Haskell module が提供する developPackage を呼んで Haskell パッケージの開発のための設定を構築している。

source-overrides で依存関係のオーバーライドができる。 Hackage のバージョンを指定する方法と tarball のURLを指定する方法がある。

modifier では cabal のいくつかのオプションを設定できる。 設定項目の内訳は ここ にある。

なお、ghcBuild 引数に値を与えて別のGHCバージョンを指定することもできる。 (GHCと base のバージョンが合わないときは version-history を参照して調整する)。

> nix-shell --argstr "ghcBuild" "ghc902" --run "cabal run"

高度な依存関係オーバーライド

この項目を書くときに力尽きた。 依存関係オーバーライドはそれほど困難な道だった。 どうしてもオーバーライドしたいなら次の記事が参考になる。

Nix recipes for Haskellers – Sridhar Ratnakumar

How to override dependency versions when building a Haskell project with Nix

トラブルシューティング

nix-shell の立ち上がりが遅い

direnv Nix integration を導入するといいかもしれない。 direnv 自体は Nix と関係なく使えるひとつのツールだが、 Nix がこれと連携するのにはいくつかのオプションがある。

https://github.com/direnv/direnv/wiki/Nix

自分はシンプルそうな nix-direnv を使っている。

VSCode に direnv 拡張を導入すると VSCode からも direnv の環境が見えるようになる。 ただ過渡期にあるようで何を選ぶか注意が必要そうだ。

VSCode direnv 拡張は上から3番目のが公式かつ最新らしい。なかなかの罠。 pic.twitter.com/IOkIJBIaQk

— しょしー (@syocy) 2022年3月18日

cabal run で cabal 自体の出力を無視したい

これは Nix というより cabal の Tips だが次のようにするといいかもしれない。

> nix-shell --run "cabal build && \$(cabal list-bin test-package) | clip.exe"

Mac で nix-env -i が失敗する

すでに修正されたようだが Mac 環境で nix-env -i が失敗することがある。 そのときは以下の issue にある方法で回避できることがある。

https://github.com/NixOS/nixpkgs/issues/163374

Mac で channel が消滅する

理由は分からないが Mac で channel 設定が消滅することがある (nix-channel --list が何も返さない)。 nixpkgs を自分で再設定する必要があるかもしれない。

> nix-channel --add https://channels.nixos.org/nixpkgs-unstable nixpkgs 
> nix-channel --update nixpkgs

家から出ない生活４週間

出社非推奨になったのを機に家から出ない生活を始めて４週間が経った。今までやったことをまとめていく。

食料品

せっかくだから生活で縛りプレイをしてみようと思って Amazon と Yodobashi を禁止にしている。この２社は最近評判が良くないこともあるし。

業務スーパーの通販

いわゆるネットスーパーはサイトが激重になっていたり配達可能日がすべて☓になっていたりで機能不全を起こしているようだった。そこで飲食店がメインターゲットであろう業務スーパーなら今空いているだろうという読み。ここではピザ材料、冷凍野菜、割り箸などを入手している。

とにかく業務スーパーの通販を最大限利用するには冷凍室の容積が必要で、製氷皿とズブロッカには戸棚待機をお願いすることとなった。

日清オールインパスタ

栄養が偏って脚気とか壊血病になるのが怖いのでやや高いしかさばるが栄養補助の目的で食べている。

森永製菓の通販

もともと健康食品用のサイトだったのか矢鱈とコラーゲンを推してくるが、普通のお菓子もいくらか買える。inゼリー、プロテインバー、ラムネなど。

コーヒー

マクドナルドのコーヒーを入手できなくなって家のコーヒー豆消費が増えた。そしたら実家が秋田の『薫』と『アラジン』の豆を送ってくれた。ありがたい。

通販だとだいたい『ネルソンコーヒーロースター』か『たまこのコーヒー』を利用している。

ネルソンコーヒーロースター

仙台所在のロースター。同市の『ネルソンコーヒー』とは別らしい。まじかよ。よくふざけた名前のパックを出している。500g1300円のパックが安い。

たまこのコーヒー

『多摩ワールドコーヒー』の通販。キャラクターがかわいい。vtuber にもなっている。

リモートワークあるいはWFM

椅子

ずっと家にいると腰がやばそうなので椅子は買うことにした。ところが部屋の片付けをしないうちに届いてしまったため倉庫番ゲームが発生し結局腰は痛めた。

『座面と背面が細かいメッシュ』という条件だけで10万円超えるんだよね……。会社の補助制度っぽいものを利用できたとはいえ試座してから決めたかった。

テレビ会議

カメラはラップトップ備え付けのものでいいとしてもマイクが雑音源と近すぎて憚られたため、マイクは買うことにした。が、すでに低価格帯のマイクの在庫はなくなっていたのだった。

BGM

あるていどの騒がしさがないと作業に集中できない人は vtuber の歌枠でも流しておけばいいんじゃないかな。雑に最近のをまとめた再生リストを置いておく。 https://www.youtube.com/playlist?list=PL1bkZdoXAsdpO3zlsyU5zDUdqh8fS2jmG

運動

品薄になる前にリングフィットアドベンチャー買えた勢。

余暇

FF14 と STEAM と vtuber があるので暇はない。

未解決問題と所感

散髪に行けないのが辛い。さいわいなぜかパナソニックの長めに切れるバリカンみたいなの(これ)を持っているので自分で切れないこともない。

窓から遠くが見える立地でないので近眼がさらに進みそう。HMDをかぶると視力が良くなる説を検証してみるべきか。今HMD手に入るのか知らないが……。

あとは４週間も在宅勤務できるなら今までも毎日出社する必要はなかったのではと思う。たとえ出社非推奨が解かれたとしても前のように毎日全員が出社する前提には戻らないんじゃないだろうか。個人的にも満員電車がもたらす不快指数に加担するのは心苦しい。

とは言え

とは言えそろそろ外に出たくもなってきた。記憶が確かなら歩いていける距離に卵の自販機があったはずだ。さしあたってそこを目標地点にして人のいない時間帯に出歩いてみることにしよう。

HaskellやっていくGHC8.8.1令和元年白露の候

GHC 8.8.1 が出たので雑に環境を整えていきます。

OS: Ubuntu 18.04 LTS on VirtualBox on Windows

screenshot

GHC, Cabal

最近は ghcup で入れている。

$ ghcup upgrade
$ ghcup list --tool all
$ ghcup install 8.8
$ ghcup install-cabal latest

~/.ghcup/bin と ~/.cabal/bin にPATHが通っていない場合は通しておく。

stack は手になじまない感じがして最近使っていない。 stack のいいところとしてスクリプトが書けるというのがあったが、最近は cabal でもいい感じに shebang を書けばスクリプティングできるようになったというのもある。

Haskellツール

使いそうなHaskellツールをインストールする。

$ cabal new-update
$ cabal new-install doctest hlint ghcid fast-tags --installdir=$HOME/.cabal/bin

まだ GHC 8.8.1 が世に出て日が浅いのでインストールできないパッケージも多い。 自分が試した時点では以下のものはインストールできなかった。

• apply-refact
• hasktags
• stylish-haskell
• hhp (HEADでは対応済みだがhackageに上がっていない?)
• haskell-ide-engine (rc版は出ている?)

ツールによってはわざわざGHC8.8.1でインストールする必要がないものもある。 そういうものは ghcup set でGHCを切り替えてインストールするといいかもしれない(試してはいない)。

エディタ

モーダルでカスタマイザブルなエディタがいいので Spacemacs を使う。 おそらく Emacs 26 が必要になるが素の apt だと入らないかもしれない。 そのときは apt repository を追加するなどする。 あと Spacemacs は master がだいぶ古くて皆 develop を使っているようなので自分もそうしている。

自分の.spacemacs: https://gist.github.com/syocy/5ea4d65f3f819a2a2e82e3f8ff2f3d82

シェルは fish シェルを使っているが、そのせいか Spacemacs がうまくPATHを継承しないことがあった。 そのときは SPC f e e で環境設定ファイルを開いて直接編集すればいいようだ。

Haskell layer の補完バックエンドは company-ghci を使っている。 dante は自分の環境では動かなかった(戦いの爪痕が.spacemacsに残っている)。 company-ghci は SPC m s b で ghci をロードしておかないと動作しないので注意。

インタラクティブなエラーチェックは Haskell layer に含まれる flycheck-haskell を使っている。 ghci のほか、hlint があるとそれも走らせてくれる。 タイル型ウィンドウマネージャ(i3wm)を使っていた頃は ghcid を使っていた。 flycheck-haskell を使っていくうちに不都合があれば戻るかもしれない。

そのほか細かい設定は .spacemacs を見てほしい。

サンプルプロジェクト

cabal init が最近強化されたらしく、プロジェクトを作るのがより楽になったようだ。 cabal init --help を見るとオプションが増えている。 たとえばテストのあるライブラリとしてプロジェクトを作るには以下のようにする。

$ cabal init --lib --source-dir=src --tests --test-dir=test -p sample-project

ちなみに冒頭の画像を再現するには、

• SPC e L で flycheck のエラーウィンドウを開く
• SPC f t (SPC p t) で treemacs ウィンドウを開く
• SPC w でウィンドウをお好みで配置する

などすればできる。 なおウィンドウレイアウトの保存は SPC l でできる(昔の eyebrowse layer?)。

以上、GHC 8.8.1 でも Haskell やっていくぞ。

追記: Cabal 3.0 から一部オプションのデフォルト値が変わった関係で flycheck-haskell や doctest のようなツールが動作しないということがあった。そういうときは cabal のオプションに --write-ghc-environment-files=ghc8.4.4+ を指定するとよい。 stackoverflow にもその旨を書いた。

GHCの線形型プロトタイプを試すだけ

GHCに線形型を導入すると以下のような良い事があるらしい。

• リソース安全性: ファイルハンドル、ソケット、DBコネクションのようなリソースについて、これらを提供するAPIの設計者が安全な使用を強制できる。リソース解放後のアクセス、二重解放、解放忘れを防止することができる。
• レイテンシ: リソースAPIの実装をうまくやるとoff-heap(GCの対象外)でリソースを確保・解放できる。GC対象が少なくなることによりGCによってプログラムが停止する時間を減らせる。
• 並列性: 過剰な直列化を強要しない。リソース安全性を保ちつつもできる限り並列化できる。

詳しくはproposal。

この記事では線形型GHCのプロトタイプ実装および線形型ファイル操作ライブラリのプロトタイプ実装を試してみる。 ここで紹介するものが正式リリースで変更されている可能性は大いにある。

なおcabalのnew APIを使うのがマイブームなので今回はstackを使わない方法でやっていく。

GHCのビルド準備

まずGHCのビルドに必要なものをインストールする。

• autoconf
• automake
• ncurses
• happy
• alex
• cabal-install
• ghc

このうち、autoconf, automake, ncursesはapt等でインストールできるはず。

ghcはUnix系環境であればghcupで導入するのがやりやすいと思う。 異なるバージョンのghcを切り替えることもできる。 (今回のように独自ビルドしたghcも管理対象に追加できるのかは未確認)

ghcup install 8.6.3
ghcup set 8.6.3
ghcup install-cabal
ghcup new-install cabal-install

happy, alexはcabalで入れればよい: cabal new-install happy alex

linear-typesブランチをビルド

GHCのソースはGitHubのミラーから取得するのが速い。

git clone https://github.com/ghc/ghc

linear-typesブランチは別のところで開発されているのでリモートソースに追加してチェックアウトする。 (この記事でのcommit id: 782869e3d1a25b4a84c405be346ef5b9c1fbfc8b)

cd ghc
git remote add tweag https://github.com/tweag/ghc.git
git fetch tweag linear-types
git checkout tweag/linear-types

GHCのgit運用がGitHubとミスマッチを起こしているところがあるので少し手を加える。

git config --global url."git://github.com/ghc/packages-".insteadOf git://github.com/ghc/packages/
git config --global url."http://github.com/ghc/packages-".insteadOf http://github.com/ghc/packages/
git config --global url."https://github.com/ghc/packages-".insteadOf https://github.com/ghc/packages/
git config --global url."ssh://git\@github.com/ghc/packages-".insteadOf ssh://git\@github.com/ghc/packages/
git config --global url."git\@github.com:/ghc/packages-".insteadOf git\@github.com:/ghc/packages/

ビルドする。makeのNは物理CPUコア+1にするのが良いらしい。

./boot
./configure
make -j N

ビルドできたら、 ./inplace/bin/ghc-stage2 がよく知るghcコマンドになっている。

実際に試す

やっと線形型GHCを実行する準備ができた。 コードを様々に変えて試すには ghci の :reload や ghcid の変更検知のようなインタラクティブな環境を用意するとやりやすい。

ghci は ./inplace/bin/ghc-stage2 --interactive で起動する。

ghcid なら ghcid --command='/path-to-ghc/ghc/inplace/bin/ghc-stage2 --interactive' Main.hs のようにするとよいだろう。

実験用プロジェクトを cabal init で作る場合は cabal new-configure でプロジェクトのビルドで使うghcを変更できる。 このサブコマンドによる変更は cabal.project.local というローカル環境用ファイルに保存される。 プロジェクトを GitHub などに上げるなら .gitignore に追加しておくとリポジトリから環境依存のファイルをなくせる。

cabal new-configure --with-compiler=/path-to-ghc/ghc/inplace/bin/ghc-stage2

それではコードをコンパイラにかけてみよう。

{-# LANGUAGE LinearTypes #-}

module Main where

flugal :: a ->. (a, a)
flugal a = (a, a) -- Error!

wasteful :: a ->. b ->. a
wasteful a b = a -- Error!

main = putStrLn "Hello, LinearTypes"

flugal と wasteful はコンパイルエラーになる。 ->. が LinearTypes で有効になる型レベル演算子で、 -> とほぼ同じだが左の値を必ず一度だけ使わなければならないという制限がつく。 flugal は a を2回使っているのでエラー、 wasteful は b を1回も使っていないのでエラーとなる。

より実用的な例も見てみよう。 linear-base パッケージは線形型によるファイル操作API(とそれに必要な諸々)を提供する。 これは現時点で Hackage にアップロードされていないので GitHub から入手する必要がある。 実験用プロジェクトをcabalプロジェクトで作っている場合は、以下の内容で cabal.project というファイルを作ると cabal new-build で GitHub からパッケージを持って来てくれる。

source-repository-package
    type: git
    location: https://github.com/tweag/linear-base
    tag: 0d6165fbd8ad84dd1574a36071f00a6137351637

packages: ./

ファイルを2つオープンし、片方から1行読んでもう片方に書き込むプログラムは以下のようになる。 cabalプロジェクトの場合は cabal new-run で実行できる。 これはちょっと込み入っている。

{-# LANGUAGE LinearTypes #-}
{-# LANGUAGE RebindableSyntax #-}
{-# LANGUAGE RecordWildCards #-}

module Main where

-- linear-base
import qualified Control.Monad.Linear.Builder as Linear
import qualified System.IO.Resource as RIO
import Prelude.Linear (Unrestricted(Unrestricted))

-- base
import System.IO (IOMode(ReadMode, WriteMode))
import qualified System.IO as System

mainRIO :: RIO.RIO (Unrestricted ())
mainRIO = do
  inHandle <- RIO.openFile "Main.hs" ReadMode
  outHandle <- RIO.openFile "dup.txt" WriteMode
  (inHandle', outHandle') <- dupOneLine inHandle outHandle
  RIO.hClose inHandle'
  RIO.hClose outHandle'
  return (Unrestricted ())
    where
      Linear.Builder{..} = Linear.monadBuilder -- for do-notation

      dupOneLine :: RIO.Handle ->. RIO.Handle ->. RIO.RIO (RIO.Handle, RIO.Handle)
      dupOneLine inHandle outHandle = do
        (Unrestricted l, inHandle') <- RIO.hGetLine inHandle
        outHandle' <- RIO.hPutStrLn outHandle l
        return (inHandle', outHandle')

main :: System.IO ()
main = RIO.run mainRIO

いくつかの要素が登場している。 要素ごとに見ていこう。

RebindableSyntax と RecordWildCards は do 記法の実装を通常の Control.Monad から別のものに変更するためにつけている。 なんでそんなことをするのかというと Control.Monad は線形型向けに作られたものではないため評価に線形型の制限が入っていない。 線形型の制限が入ったバージョンの Monad として linear-base は Control.Monad.Linear を提供しており、 線形型 do を使いたい関数の where 節で Linear.Builder{..} = Linear.monadBuilder のようにすると、 RebindableSyntax と RecordWildCards の働きにより do の実装を線形型版 Monad に変更することができる。

RIO は Resource-aware IO の意味で、線形型 Monad 版の IO となっている (rioとは関係ない)。 IOという名前だが現状提供されているのはいくつかのファイル操作だけである。 基本的なAPIと型シグネチャは通常のIOのものと似ているが、 hClose 以外の関数はすべてハンドルも返すようになっているのがポイント。

RIO は RIO.run 関数によって通常のIOの中で起動することができる。 ところどころに出てくる Unrestricted というのは線形型の制限の中から制限のない値を取り出すときに使うデータ型である。

さて、このプログラムで線形型の制限がちゃんと働いているか確かめるには hClose を削ったり2回呼んでみるとか、 dupOneLine で hGetLine や hPutStrLn が返したハンドルではなく引数のハンドルをそのまま返すなどしてみるとよい。 コンパイルエラーのメッセージがどのようなものになるかぜひ確認してみてほしい。

所感

線形型の導入によって一般のHaskellプログラマーは影響を受けるだろうか？

私は影響は限定的だと思う。 線形型は LinearTypes をONにして型シグネチャに ->. を使ってはじめて有効になる。 線形型の導入による実行時システムへの変更もない。 今後リソース系ライブラリで線形型APIを提供するものが現れて、 それを使うのであれば線形型Haskellの書き方を学習する必要はあるだろう。

別に今までのHaskellのリソース管理が危険だったということもなく、 以下の記事に紹介されているようにHaskellにはすでに様々なリソース管理のツールがある。

qiita.com

あえて線形型を必要とするのは、 上記のように低レイヤーのAPIを提供するリソース系ライブラリか、 レイテンシが特に気になるサーバやゲームの開発くらいだろうか。

ひとつ気になることがあるとすれば、線形型GHCを主導しているのが Tweag I/O だということだ。 Tweag はGHCを拡張して asterius という Haskell to WebAssembly コンパイラを開発している。 GHCへの線形型の導入が、将来の Haskell によるWebプログラミングを見据えてのものだという可能性はあると思う。 クライアントサイドWeb開発はまさにレイテンシが重要な領域だからだ。

Dhallによるリッチな設定ファイル体験

(この記事のレギュレーション: lts-11.9)

Dhall という設定記述用言語があり、使ってみたところ良い感じだったので紹介します。

なお、この記事は先日某所で発表したものの拡大版になります。

speakerdeck.com

Dhallとは何か

Dhallについて短かく表現するなら公式サイトの以下の説明が分かりやすいです。

You can think of Dhall as: JSON + functions + types + imports

データ表現にプログラマブルさと静的な検査とファイルのインポートを加えたものというわけです。

まだ開発中のためかあまりアピールされていませんがツールチェインも充実しており、 ちょっとした処理を確かめるためのREPLや、 今どきの言語らしく公式フォーマッタもあります。

あと大事なのはチューリング完全ではないということです。 具体的にはループなどは書けません。

設定ファイルの役割というものはソフトウェアの成長に従って肥大化していく宿命にあり、 最初は単純なJSONやYAMLで済んでいたものの上に独自形式のマクロが追加され、 単純な文字列置き換えで済んでいるうちはいいものの要求の向上に従ってマクロの役割は増えていき、 屋上屋を重ねた末にはシンタックスハイライトが効かない・実行時にならないとどういう設定になるか分からない・下手すれば無限ループして停止しない設定ファイルができあがってしまいます。

Dhallは意図的にパワーを抑えて設定ファイルの領分を守りながらも「簡単な関数くらいは使いたいよね」という要望に応えてくれる、 とても良いバランスを達成していると思います。

Dhallはすでにいくつかの 導入事例 もまとまっており、プロダクションで十分に利用可能と言えるでしょう。 (僭越ながら先日私も会社で使われている長大なYAMLをDhallから生成する仕組みを作りました。 とても便利)。

導入方法

Dhallには dhall コマンドなどのコマンドラインツール群と、 dhall-json や dhall-to-cabal といったアプリケーション、 そして各プログラミング言語から Dhall ファイルを読み込むためのいくつかのバインディングがあります。 サポートされている言語には今のところ Haskell と Nix があり、他にも Scala と Rust が開発中のようです。

Dhallコマンドラインツール

Stackがない場合はインストールします。 例として Un*x の場合:

$ curl -sSL https://get.haskellstack.org/ | sh
$ stack setup --resolver=lts-11.9

必要に応じて ~/.local/bin にPATHを通してください。

Dhallツール群は以下のようにしてインストールします。

$ stack install dhall --resolver=lts-11.9
$ ls ~/.local/bin/dhall*
dhall    dhall-format    dhall-hash    dhall-repl

(注意: 最近コマンドラインツールの構成に変更があり dhall-format と dhall-hash が dhall のサブコマンドになりました (issue)。 この変更は今回採用している lts-11.9 にはまだ入っていないので、この記事ではこれらはまだ独立したコマンドとして扱います。)

dhall コマンドは Dhall ファイルの評価をするもので、関数の展開や型チェックをします (つまり、アプリケーションに投入する前にどのような設定になるか&形式が間違っていないかが分かる!)。

dhall-format コマンドは Dhall ファイルのフォーマッタです。 Dhall ファイルの保存時にこれが走るようにエディタを設定しておくのがおすすめです。 Emacsであれば dhall-mode を入れておけば勝手にそのような設定にしてくれます。

Dhallアプリケーション

現在のところ Dhall を利用したアプリケーションとしては以下のものがあるようです。

dhall-json
Dhall ファイルを JSON や YAML に変換します。 既に JSON や YAML の設定ファイルを使用しているのであれば、 これを使えば静的検査や関数のある Dhall を本番フローに導入しやすいかもしれません。 stack install dhall-json --resolver=lts-11.9 とすると dhall-to-json と dhall-to-yaml の2つのコマンドがインストールされます。

dhall-to-cabal
Dhall ファイルを cabal ファイルに変換します。 またそれだけでなく、cabal ファイルのための(おそらく cabal を完全にカバーする**多くの型定義、 そして記述を楽にするための多くの関数を提供します。 Dhall を本格利用する上でのノウハウの宝庫ですので cabal ファイルに興味がない人でも参考文献として覚えておくとよいでしょう。 stack install dhall-to-cabal --resolver=lts-11.9 でインストールできます。

dhall-kubernetes Dhall ファイルで Kubernetes の設定を記述できるようにするツールです。 Kubernetes は長大な YAML 設定ファイルで知られるのでまさに Dhall が生きる領域と言えるでしょう。 dhall-kubernetes 自体は Dhall ファイルのみで構成され、YAMLへの変換には dhall-json を用います。 ただ、要求する Dhall のバージョンがより新しいもののため LTS-11.9 環境ではインストールできません。 stack instal dhall-json --resolver=nightly で最新の dhall-json をインストールする必要があります。

バインディング

Dhall をプログラミング言語から利用する場合はその言語での Dhall のバインディングが必要です。

たとえば Dhall ファイルを Haskell アプリケーションから読む場合は Haskell の dependencies に dhall パッケージを加えます。

Dhall基礎編

それではDhallの各要素を見ていきましょう。

データ表現

データの表現は一般的な設定ファイルを表現するのに十分なものを揃えています。

プリミティブとして Bool, Integer, Double, Text (あとそれほど使わない気がするけど正の整数を表す Natural) があります。

$ echo 'True || False' | dhall
Bool

True
$ echo '1' | dhall
Integer

1
$ echo '2.0' | dhall
Double

2.0
$ echo '"Hello, World"' | dhall
Text

"Hello, World"

複合表現として List, Optional, Record, Union があります。

$ echo '[1, 2]' | dhall
List Integer

[ 1, 2 ]
$ echo '[] : Optional Integer' | dhall
Optional Integer

[] : Optional Integer
$ echo '{ x = 1, y = 2 }' | dhall
{ x : Integer, y : Integer }

{ x = 1, y = 2 }

$ echo '<Number = 1 | Name : Text>' | dhall
< Name : Text | Number : Integer >

< Number = 1 | Name : Text >

Union の値の書き方が煩雑(使わない方の識別子も書かなければならない)ですがこれには解決策が用意されています。 後で述べます。

型定義

複合表現に名前をつけて独自の型を定義することができます。

$ echo 'let Point2d = {x:Integer, y:Integer}: Type in {x=1, y=2}: Point2d' | dhall
{ x : Integer, y : Integer }

{ x = 1, y = 2 }

もちろん型が合っていなければ教えてくれます(出力にあるように dhall の代わりに dhall --explain を使えばより詳細なメッセージを出してくれます)。

$ echo 'let Point2d = {x:Integer, y:Integer}: Type in {x=1, y="2"}: Point2d' | dhall

Use "dhall --explain" for detailed errors

Error: Expression doesn't match annotation

{x=1, y="2"}: Point2d

(stdin):1:47

外部ファイルのインポート

Dhallでは外部のファイルをインポートして使うことができます。

たとえば以下のような Point2d 型を定義する Point2d.dhall を用意します。

$ cat Point2d.dhall
{ x : Integer, y : Integer } : Type
$ cat Point2d.dhall | dhall
Type

{ x : Integer, y : Integer }

これを以下のようにインポートすれば別のファイルで Point2d 型を使って型チェックすることができます。

$ dhall
{ x = 1, y = 2 } : ./Point2d.dhall [Enter]
[Ctrl-d]
{ x : Integer, y : Integer }

{ x = 1, y = 2 }
$ dhall
{ x = "1", y = 2 } : ./Point2d.dhall [Enter]
[Ctrl-d]
Use "dhall --explain" for detailed errors

Error: Expression doesn't match annotation

{ x = "1", y = 2 } : ./Point2d.dhall

(stdin):1:1

なおここではローカルのパスからインポートしましたがURLからインポートすることもできるようです。

関数

関数は無名関数として作ることができます。 以下は Integer の引数を1つ受け取ってそのまま返す関数です。

$ echo 'let id = \(x:Integer) -> x in id 10' | dhall
Integer

10

複数の引数を取る関数は1つの引数を取る関数をネストすることで記述できます。 これは一見面倒にも見えますが、無名 Record を引数に取ることもできるので実際のところ問題にはなりません。

また、Dhallの関数は 型を引数に取る ことができます。 引数に取る型は標準のものだけでなく自作の型でもOKです。 以下のようにすれば前述の id 関数が任意の型の値を取れるようになります。

$ echo 'let id = \(t:Type) -> \(x:t) -> x in id Double 1.0' | dhall
Double

1.0

便利な演算子・標準関数

演算子 // は2つの Record を併合します。 実用上は自作型のデフォルト値を少し書き換えるような場合によく使います。

$ echo '{x=1, y=2} // {y=-1, z=-2}' | dhall
{ y : Integer, z : Integer, x : Integer }

{ y = -1, z = -2, x = 1 }

上の方で Union の値を記述するときは使わない識別子も書かねばならず煩雑であることを述べました。 constructors 関数は Union のコンストラクタを生成して値の記述を楽にしてくれます。

$ echo 'let NN = constructors <Number:Integer | Name:Text> in NN.Number 1' | dhall
< Name : Text | Number : Integer >

< Number = 1 | Name : Text >

merge 関数は Union を何らかの特定の型に変換するときに使います。 実用上は、人間が設定を記述するときは変な値が入らないように型で制限したいけども最終的に欲しいのは文字列であるような場合によく使います({=} は空の Record 値を表します)。

$ dhall[Enter]
let OS = <iOS:{} | Android:{}>
in let OSs = constructors OS
in let handlers = {iOS=\(_:{})->"iOS", Android=\(_:{})->"Android"}
in let osToText = \(o:OS) -> merge handlers o
in osToText (OSs.Android {=}) 
[Ctrl-d]
Text

"Android"

あと Dhall の Text は string interpolation ができます。

$ echo 'let hello = \(name:Text) -> "Hello, ${name}!" in hello "Dhall"' | dhall
Text

"Hello, Dhall!"

Dhall実践編: Kubernetes設定ファイル

Dhall 実践編として、 dhall-kubernetes ではありませんが簡単な Kubernetes の YAML 設定ファイルを Dhall で作成してみます。 目標とする YAML は https://kubernetes.io/docs/concepts/services-networking/service/ にある以下のものです。

kind: Service
apiVersion: v1
metadata:
  name: my-service
spec:
  selector:
    app: MyApp
  ports:
  - protocol: TCP
    port: 80
    targetPort: 9376

まずはこれを型チェックもなにもないシンプルな Dhall で表してみます。

service.dhall:

{ kind =
    "Service"
, apiVersion =
    "v1"
, metadata =
    { name = "my-service" }
, spec =
    { selector =
        { app = "MyApp" }
    , ports =
        [ { protocol = "TCP", port = 80, targetPort = 9376 } ]
    }
}

これを dhall-json に通してみます。

$ cat service.dhall | dhall-to-yaml 
apiVersion: v1
kind: Service
spec:
  selector:
    app: MyApp
  ports:
  - targetPort: 9376
    protocol: TCP
    port: 80
metadata:
  name: my-service

目標とする YAML が得られました。

ただこれだと、例えば "Service" を "Servise" と typo してしまったとしてもエラーを教えてくれたりはしません。

そこで Dhall の持つ静的チェック、関数、インポートの機能を駆使して記述をサポートしていきましょう。 設定ファイルの記述をサポートするためのファイルは k8s_types.dhall という名前で作り、 実際の設定を記述するファイルがそれをインポートするようにします。

k8s_types.dhall:

    let Kind_ = < Service : {} | Deployment : {} | Pod : {} >

in  let kindHandlers =
          { Service =
              λ(_ : {}) → "Service"
          , Deployment =
              λ(_ : {}) → "Deployment"
          , Pod =
              λ(_ : {}) → "Pod"
          }

in  let ApiVersion = < v1 : {} >

in  let apiVersionHandlers = { v1 = λ(_ : {}) → "v1" }

in  let Metadata : Type = { name : Text }

in  let Selector : Type = { app : Text }

in  let Protocol = < TCP : {} | UDP : {} >

in  let protocolHandlers = { TCP = λ(_ : {}) → "TCP", UDP = λ(_ : {}) → "UDP" }

in  let Port
        : Type
        = { protocol : Protocol, port : Integer, targetPort : Integer }

in  let PortMerged
        : Type
        = { protocol : Text, port : Integer, targetPort : Integer }

in  let _mergePort =
            λ(p : Port)
          → { protocol =
                merge protocolHandlers p.protocol
            , port =
                p.port
            , targetPort =
                p.port
            }

in  let Spec : Type = { selector : Selector, ports : List Port }

in  let SpecMerged : Type = { selector : Selector, ports : List PortMerged }

in  let List/map =
          https://raw.githubusercontent.com/dhall-lang/Prelude/35deff0d41f2bf86c42089c6ca16665537f54d75/List/map 

in  let _mergeSpec =
            λ(s : Spec)
          → (   { selector =
                    s.selector
                , ports =
                    List/map Port PortMerged _mergePort s.ports
                }
              : SpecMerged
            )

in  let Config
        : Type
        = { kind :
              Kind_
          , apiVersion :
              ApiVersion
          , metadata :
              Metadata
          , spec :
              Spec
          }

in  let ConfigMerged
        : Type
        = { kind :
              Text
          , apiVersion :
              Text
          , metadata :
              Metadata
          , spec :
              SpecMerged
          }

in  let _mergeConfig =
            λ(c : Config)
          → (   { kind =
                    merge kindHandlers c.kind
                , apiVersion =
                    merge apiVersionHandlers c.apiVersion
                , metadata =
                    c.metadata
                , spec =
                    _mergeSpec c.spec
                }
              : ConfigMerged
            )

in  { Kinds =
        constructors Kind_
    , ApiVersions =
        constructors ApiVersion
    , Protocols =
        constructors Protocol
    , Config =
        Config
    , mergeConfig =
        _mergeConfig
    }

これを使って実際の設定を記述します。 ({=} は空の Record 値を表します)。

service_typed.dhall:

    let k8s = ./k8s_types.dhall 

in  let myService =
            { kind =
                k8s.Kinds.Service {=}
            , apiVersion =
                k8s.ApiVersions.v1 {=}
            , metadata =
                { name = "my-service" }
            , spec =
                { selector =
                    { app = "MyApp" }
                , ports =
                    [ { protocol =
                          k8s.Protocols.TCP {=}
                      , port =
                          80
                      , targetPort =
                          9376
                      }
                    ]
                }
            }
          : k8s.Config

in  k8s.mergeConfig myService

先ほどと同じように dhall-to-yaml に通します。

$ cat service_typed.dhall | dhall-to-yaml
apiVersion: v1
kind: Service
spec:
  selector:
    app: MyApp
  ports:
  - targetPort: 80
    protocol: TCP
    port: 80
metadata:
  name: my-service

結果を変えずに静的なチェックを追加することができました! もちろん "Service" などを typo したらエラーが出て教えてくれます。

なお、今回はあくまで設定ファイルに間違った値が入り込まないようにすることに主眼を置きましたが、 設定ファイルがより長いものになってくると、

• 型のデフォルト値を定義する
• 繰り返し使う値を定数にする
• 雑多なボイラープレートな記述をヘルパー関数に切り出す

など、 Dhall のさらなる恩恵を受けることができます。

参考資料

• dhall-lang: 公式サイト
• Dhall in production: Dhall導入事例集
• dhall-json: DhallファイルをJSON/YAMLに変換
• dhall-to-cabal: Dhall本格利用のためのノウハウの宝庫
• dhall-kubernetes: DhallファイルでKubernetesの設定を記述
• dhall-mode: 自動フォーマットもしてくれるEmacsモード
• dhall-lang Cheatsheet: チートシート
• Dhall Tutorial: チュートリアル

Haskellの実行バイナリにファイルを埋め込む

(この記事のレギュレーション: lts-10.5)

file-embed パッケージを使う

コンパイルしてできる実行バイナリにファイルを埋め込みたいことがある。 アプリのGUIで使うアイコンとか機械学習の学習済みモデルとか。 Go では (現在では非推奨らしいが) go-bindata を使う場面だろうか。

Haskell ではそういうときには file-embed パッケージが使える。 たとえば [project root]/resources/lorem.txt に置かれた lorem ipsum テキストを埋め込む場合:

{-# LANGUAGE TemplateHaskell #-}

import Data.FileEmbed (embedFile, makeRelativeToProject)
import qualified Data.ByteString as BS

lorem :: BS.ByteString
lorem = $(makeRelativeToProject "resources/lorem.txt" >>= embedFile)

main :: IO ()
main = do
  print lorem -- > "lorem ipsum..."

$(...) の部分が Template Haskell というやつでコンパイル時に実行されるので、ファイルは実行時に参照されるのではなくバイナリに埋め込まれることになる。

自分で実装してみる

file-embed は小さいライブラリだが、もし依存関係を減らしたいなら自分で template-haskell パッケージを使って書いてしまってもよいかもしれない。 単純な実装で良ければそれほど行数を使わずに書ける。

{-# LANGUAGE TemplateHaskell #-}

import Language.Haskell.TH
import qualified Data.ByteString as BS
import qualified Data.ByteString.Char8 as BSC

lorem :: BS.ByteString
lorem = $(do
             file <- runIO $ fmap BSC.unpack $ BSC.readFile "resources/lorem.txt"
             pack <- [|BSC.pack|]
             return $ AppE pack (LitE $ StringL file)
         )

main :: IO ()
main = do
  print lorem -- > "lorem ipsum..."

$() の中の実装のポイントはこんな感じ

• Template Haskell の中では runIO で IO アクションを起こすことができ、それを使って外部のファイルを読んでいる。
• Haskell の構文木に直接 ByteString は入れ込めないので BSC.unpack で String を経由している。
• 準クオート構文 [|...|] を使って BSC.pack を Template Haskell のレベルに持ち上げている。
• あとは AppE, LitE, StringL などの Haskell の構文木を表すコンストラクタで構文木を作ればOK。template-haskell のリファレンスを読めば雰囲気は分かる。まあ間違っててもコンパイラが教えてくれるので。

ただこの単純な実装は問題があって、file-embed と違い [project root]/ が考慮されていない。 こういったプロジェクトのメタデータにアクセスするには cabal が自動生成する Paths_pkgname モジュール を使う方法があるが、これは Template Haskell では使えないようだ。 file-embed ではちょっと面白いやり方でこの問題に対処している。 ソースを読んでみると面白いかもしれない。

結論としては自前実装よりは file-embed を使うのが良いと思う。

余談

file-embed にはもう一つ機能があって 「コンパイル時にバイナリに固定サイズのスペースを空けて、コンパイル後にそのスペースにデータを埋め込む」 というのができる。 バイナリのハッシュ値をバイナリ自体に埋め込むなどの使い方があるようだ。

A Tour of Go in Haskellを作ったのと、GoとHaskellの比較

(この記事は Haskell (その2) Advent Calendar 2017 - Qiita の３日目の記事です)

A Tour of Go in Haskell というサイトを作りました。 英語版(開発中) もあります。

サイトのソースは GitHub で管理しています。

概要

今流行りの Go 言語は並行並列処理が簡単に書けることを１つの売りにしているようです。 Haskell も Go と同じく軽量スレッドやチャネルを利用することができ、並行並列が得意な言語の１つです。 そこで、A Tour of Go という Go の有名なチュートリアルの 並行性 の章を Haskell で書いてみることで、 Haskell と Go を並行並列処理の記述という観点で比べてみよう、というのが A Tour of Go in Haskell になります。

Go ユーザや Haskell に慣れ親しんでいない人が見ても雰囲気がつかめるコードを目標にしたので、あまり難しい書き方はしないようにしています。 たとえば、Haskeller にはよく知られているユーティリティ関数を使わなかったり、ポイントフリーにできるところをポイントフリーにしていなかったり、関数はあまり純粋にせず IO にしていたりします。 また、Go との比較を重視したので、もっぱら async や stm を使い、EvalモナドやParモナドは説明していません。 Haskell に詳しい方はそのあたりご了承下さい。 なお、コードのレファレンス性のために import はかなり明示的に書いています。 その場のコーディング規約にもよると思いますが本来はもっとワイルドカードな import ができます。

サイトの作りとしては完全に静的サイトになっていて、残念ながら現状は本家のようにコードを実行する機能はありません。 一応作る気はあり、静的サイトホスティングとして Firebase Hosting を使っているのもいずれ GCE かなにかでコード実行サーバを立てたいというのがあるためです。 そういえば最近は他にも静的サイトホスティングの選択肢はあるようですが、Firebase Hosting は独自ドメインも使えるし SSL 証明書もついてくるし HTTP/2 で通信されるし、 結構便利な感じでした。

あと、Haskell は言語拡張を多用することに毀誉褒貶があったりしますが、A Tour of Go in Haskell は言語拡張を１つも使わずに書けました。 並行並列が Haskell (GHC) に早い段階から入っていた（枯れた）機能なことが分かります。

比較

いくつかの観点から、比較と言えるほど厳密ではないですが、感触の違いを述べます。 今回はパフォーマンスについては見ていません。

軽量スレッド

軽量スレッドというのはOSのスレッドとは違って言語のランタイムが管理するスレッド（でいいはず）。 軽量というだけあって軽くてたくさん（数千個とか）作ることができます。 どれくらい軽いかというと Haskell の場合はスレッド１つにつき18ワード+1K (pdf) しかメモリを消費しない（slackで教えていただきました m(_ _)m）。 よく並行処理がすごいと言われる Erlang の軽量プロセス（軽量スレッドとは違うのか？）が309ワード(リンク) なことを考えれば、Haskell はなかなかすごいと言えそうです。 Go の軽量スレッドのサイズは分かりませんでしたが、おそらく Haskell か Erlang くらいでしょう。

さて軽量スレッドについては Go と Haskell で使い勝手はほとんど変わらないと思います。 Go では go とやると軽量スレッドになるところを、Haskell では async とやると軽量スレッドになるというだけです。 （forkIO でもいいが async の方がよく使われていると思います）。

違いは go が専用の構文なのに対して async は普通の関数というところです。

あとたぶん goroutine というのは軽量スレッドという言葉を言い換えたものだと思うのですが、 別の名前をつけることで言語固有のすごい機能として見せるのはうまい手だなと思いました。

チャネル

チャネルはスレッド間で値をやり取りするのに使う First-In-First-Out キューという理解。

Go はかなりチャネルに特化して構文や機能を用意していて、チャネルに関しては Haskell より使いやすいと言えそうです。 チャネルに値を書き込む/取り出すための演算子のような構文があったり、for式でチャネルの要素をイテレーションできるなど、 ストレスフリーにチャネルを取り扱えるように考えられています。

Haskell でも真似できる部分は結構あり、例えば getChanContents 関数を使えば Go の range 句のようなことができます（Range and Close - A Tour of Go in Haskell）。 加えて Haskell は演算子が定義できるので工夫すれば Go のような書き味を実現できるかもしれません。 ただ、それはおそらくやりすぎなのでやらない方が良いでしょう。

A Tour of Go in Haskell では取り扱わなかったこととして、Haskell のより高速なチャネルの話題があります。 Hackage には Haskell 標準のチャネルより高性能な実装を目指したパッケージがいくつかあります。 もし標準チャネルの性能に不満があるなら検討してみるとよいかもしれません。

• unagi-chan: Fast concurrent queues with a Chan-like API, and more
• kazura-queue: Fast concurrent queues much inspired by unagi-chan （作者によるQiitaでの解説）

Mutex, STM

チャネルは便利ですが、スレッド間で変数を共有する方法としてそれだけで完結するというわけではありません。 たとえば int の変数を複数のスレッドで共有してコンフリクトを起こさないようにそれぞれ読み書きをするような場合です。

Go はそのような場合のために古典的な Mutex を用意しているようです。 しかし Mutex を直接的に使うことは変数の書き換えの前後でロック処理およびアンロック処理が明示的に必要で、 シンタクティックノイズなだけでなくデッドロックを生みやすくなってしまいます。 （これは私の憶測ですが、Goの設計はユーザにチャネル以外の共有変数を禁止しようとしているように見えます）。

Haskell ではそのような場合や、複数の共有変数が絡むようなより複雑な場合のために STM（ソフトウェア・トランザクショナル・メモリ）が用意されています。 STM では一連の不可分な共有変数の操作を「トランザクション」という単位でまとめることができます。 トランザクションの実行中に、利用したい共有変数の１つが他のスレッドによってすでに使われていることが分かったら、トランザクションは実行前の状態までロールバックし、変数がフリーになるのを監視します。 いけそうになったらトランザクションはリトライされ、ロールバックせず完遂できるまで繰り返します。

STM を使うと複雑な並行処理もうまく記述できることがあります。 まあ STM にも弱点はあり、ふつうのコードとの組み合わせに注意が必要なこと、ロールバック・リトライの回数やタイミングを人間が完全に予測することはほとんど不可能なことなどがあります。 もしトランザクション中にミサイルを発射する処理が入っていた場合、トランザクションが間違いでロールバックされることになってもミサイルの発射はロールバックできません。 そこまでいかなくても、トランザクション中に何かのインクリメント処理が入り込んでいて実行環境依存でリトライ回数が激増して int の最大値を超える、といったことは十分考えられます。 「ソフトウェア」とわざわざ付けているだけあって元は電子回路上のアルゴリズムなので、任意の処理が差し込めるようにはできていないのです。 Haskell の場合、STM は STM モナドとして IO モナドと分離することでこの問題を完全に回避しています。 もしトランザクション中に副作用のある処理を入れてしまったとしても、実行時ではなくコンパイル時にエラーになります。 IOに型が付くという Haskell の特徴はこういったところでもメリットを生んでいます。

Haskell の STM について詳しく知るには O'Reilly Japan - Haskellによる並列・並行プログラミング が最も良いと思います。 よく言われる「STMは遅いのか？」という話題も取り扱われています。

さて、Mutex のページは Mutex を使う A Tour of Go と STM を使う in Haskell で顕著な違いがある部分です。 ぜひ２つのコードを見比べてほしいと思います。

• sync.Mutex - A Tour of Go
• sync.Mutex - A Tour of Go in Haskell （atomically 関数が STM のトランザクションを作ります）

（補足: GoにもSTMライブラリはあるようですが更新が止まっているようです GitHub - lukechampine/stm: Software Transactional Memory in Go）。

やり残したこと

• 本家のようにコード実行機能をつけたい。
  • hint-server を使えば、Haskell コードを渡して動的ロードするサーバーが作れそう。
  • あるいは直接 ghc コマンドを叩く。
  • この部分は静的サイトにできないのでサーバ代がかかる……。（たぶんGCE Managed Instance Groupを使う←Twitterで教えていただきました m(_ _)m）
• 英語版の完成。
• CSSの改善。

おわりに

Go の軽量スレッドやチャネルの構文はとてもよく設計されていて、特にチャネルに的を絞って専用の構文をたくさん用意する設計選択にはすごいセンスを感じました。 ただ、チャネル以外の共有変数のサポートが薄いというのは、並行並列処理に関してちょっと強すぎる仮定な気もしました。 しかしもしかすると、Go の想定する適応領域（システムプログラミング？）ではスレッドとチャネル以外の並行並列ツールはほとんど必要ないのかもしれません。 そうだとすると Go の設計選択のセンスはやはりすごいということになる。

O'Reilly Japan - Haskellによる並列・並行プログラミング から少し長いですが引用します。

スレッドとロックは、並列画像処理から並行ウェブサーバまで、必要なものをすべて記述できるだけの表現力を有しています。 このような単一の汎用的なAPIが存在するのはたしかに利点ではあります。 しかしながら、並列・並行ソフトウェアの作成を容易にしたいのであれば、 異なる問題に対しては異なるツールを用いるという考えが、やはり重要になってきます。 一本のナイフではうまく切れないのです。

私個人としては１つのツールに寄り掛かるのは恐いので状況に応じたツール選択ができるようになっておきたいという思いがあります。

「Haskellによる並列・並行プログラミング」は A Tour of Go in Haskell で利用した async や stm だけでなく、純粋な関数での並列性、メッセージパッシング、そもそも並列と並行の違いとは、といった広範な話題を扱っていて、 Haskell に限らず並列・並行をやる人にとてもおすすめの本です。 A Tour of Go in Haskell を作るにあたっても大いに参考にしました。