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

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

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

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

speakerdeck.com

Dhallとは何か

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

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

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

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

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

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

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-formatdhall-hashdhall のサブコマンドになりました (issue)。 この変更は今回採用している lts-11.9 にはまだ入っていないので、この記事ではこれらはまだ独立したコマンドとして扱います。)

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

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

Dhallアプリケーション

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

dhall-json
Dhall ファイルを JSONYAML に変換します。 既に JSONYAML の設定ファイルを使用しているのであれば、 これを使えば静的検査や関数のある Dhall を本番フローに導入しやすいかもしれません。 stack install dhall-json --resolver=lts-11.9 とすると dhall-to-jsondhall-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 ではありませんが簡単な KubernetesYAML 設定ファイルを Dhall で作成してみます。 目標とする YAMLhttps://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 のさらなる恩恵を受けることができます。

参考資料

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.unpackString を経由している。
  • 準クオート構文 [|...|] を使って 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 の3日目の記事です)

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

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

概要

今流行りの Go 言語は並行並列処理が簡単に書けることを1つの売りにしているようです。 Haskell も Go と同じく軽量スレッドやチャネルを利用することができ、並行並列が得意な言語の1つです。 そこで、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 は言語拡張を1つも使わずに書けました。 並行並列が Haskell (GHC) に早い段階から入っていた(枯れた)機能なことが分かります。

比較

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

軽量スレッド

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

さて軽量スレッドについては 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 標準のチャネルより高性能な実装を目指したパッケージがいくつかあります。 もし標準チャネルの性能に不満があるなら検討してみるとよいかもしれません。

Mutex, STM

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

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

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

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 で顕著な違いがある部分です。 ぜひ2つのコードを見比べてほしいと思います。

(補足: 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が存在するのはたしかに利点ではあります。 しかしながら、並列・並行ソフトウェアの作成を容易にしたいのであれば、 異なる問題に対しては異なるツールを用いるという考えが、やはり重要になってきます。 一本のナイフではうまく切れないのです。

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

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

GoのTickerみたいなやつをHaskellで作った

github.com

作った。

GoのTickerはとてもシンプルな関数で、 指定した周期でチャネルに値を送るスレッドを生成する。 一定間隔で何かの処理を行いたいときに利用する。

今回作ったHaskell版もだいたい同じようなものを提供する。

実際のところパッケージにするには小さすぎる気もするけど、 Haskellパッケージ製作の練習をしたかったのでHackageのアカウントを取ってHackageに上げた。 練習のため、HaddockによるAPIドキュメントおよびhspecとdoctestによるテストも書いてある。 あとは何かCIを導入してGithubのページにCIのステータスを表示するようなやつもやってみたい。

小さいわりにHaskellパッケージに求められる要素は結構入っているので、 Haskellパッケージ作ったことがない人が作り方の参考にすることができるかもしれない。

ちなみに言語拡張は一つも使っていない。

パッケージの説明

(Haddock を結構まじめに書いたのでこちらも参照されたい)

現在は2つの関数を提供している。

newTicker
  :: Int                 -- ^ ticker rate by micro sec
  -> IO (Chan (), IO ()) -- ^ ticker channel and ticker stopper
withTicker
  :: Int               -- ^ ticker rate by micro sec
  -> (Chan () -> IO a) -- ^ handler function
  -> IO a              -- ^ result of handler

newTicker のインターフェースはGoの time.NewTicker に近づけている。

Haskellのチャネルは getChanContents を使うとリストに化けさせることができる。 (Haskellのリストは遅延リストなのでこれが可能)。 「forループでチャネルの受信をする」というGoっぽい書き方もできる。

import Control.Concurrent.Ticker (newTicker)
import Control.Concurrent.Chan (getChanContents)
import Control.Monad (forM_)
import System.Timeout (timeout)

main :: IO ()
main = do
  (chan, cancelTicker) <- newTicker $ 10^3 * 100
  chanStream <- getChanContents chan
  _ <- timeout (10^3 * 350) $ forM_ chanStream $ \_ -> do
    putStr "Tick!"
  -- Tick!Tick!Tick!
  cancelTicker

newTicker はチャネルとともにTickerを止める関数を返す。 Tickerの受信者がいなくなったらこれを呼ばないとリークになる(たぶんGoも同じ)。

もう一つの関数 withTicker はハンドラーが終わったら Ticker を停止するのでリークを気にする必要はない。

main :: IO ()
main = do
  withTicker (10^3 * 100) $ \chan -> do
    chanStream <- getChanContents chan
    _ <- timeout (10^3 * 350) $ forM_ chanStream $ \_ -> do
      putStr "Tick!"
    return ()

withTicker の実装は超単純で newTickerbracket でくるんでいるだけ。

withTicker microSec action = bracket
                             (newTicker microSec)
                             (\(_, cancelTicker) -> cancelTicker)
                             (\(chan, _) -> action chan)

こういう必要な関数がぱっと出てくるので Haskell は好き。 ハンドラーが例外を投げたときでも Ticker は停止される。

既知の問題

Githubissueにも書いたが、 newTicker は「一定周期」の実現のためにスリープ関数だけを使っている。 当然 newTicker のループの中にはスリープ関数以外の処理によって生じるオーバーヘッドがあり、 チャネルに値が積まれる速度は指定した時間よりわずかに長くなってしまうと思われる。

GoのTickerは現在時刻を毎ループで取得することで時間を厳守しているようだ。 でも現在時刻って NTP アクセスなどによって巻き戻ることがあると思うんだけど、 そこはどうしてるのだろう。

ともかくGoは詳しくないがHaskellでは getCPUTime というCPU時間を取得する関数があり、 これを使えば巻き戻らない時間が取得できそうだ、 と最初は思ったのだが……。

試したところ getCPUTime はどうやらスリープ中はカウントが止まってしまうようだった。 ループで何かを待つ場合、ふつうはビジーループを避けるために適当にスリープを入れると思うのだが、 スリープを入れるとめっちゃ時間が延びてしまった。 考えてみれば当たり前な気もするがCPUを使っていない時間はCPU時間として計測されないらしかった。

(おまけ)Hackageまわりの知見

  • Hackageのアカウントは実名で取っている人が多いが実名である必要はない。
  • .cabal ファイルの descriptionsynopsis より長く書いておかないとアップロードのときに警告される(アップロードはできる)。
  • Hackageにアップロードしたものは基本的に修正や削除はできない。
    • 修正のためには新しいバージョンをアップロードする。
    • ただし .cabal ファイルの軽微な修正ならバージョンを更新しなくても可能。
  • HaddockAPIに "Deprecated" の印をつけるにはHaskellのプラグマを用いる。
    • 該当部分
    • Haddockの記法ではないので注意。
    • deprecated な関数を使っていたら処理系が警告を出さないといけないので、よく考えると処理系レベルの記述になっているのは妥当だ。

HaskellとJSON、そしてレコード型

HaskellJSON周りについて、こうやるのがいいんじゃないかという私の現在のやり方を書きます。 題材としては、 Swagger Petstore に記されている REST API にリクエストを投げてレスポンスを取り出すというのをやります。 (Swagger ですが scaffold は使わず自分で HTTP クライアントライブラリを使います)。

基本方針は「出力は厳密に入力には寛容に」(出典失念) です。

もくじ

JSONの前に: レコードのフィールドへのアクセス

Haskellのレコード型って、フィールドのゲッターがふつうの関数なのでレコードから値を取り出そうとすると f3 $ f2 $ f1 record みたいにフィールド名が左向きに繋がります。 そのくせレコードの更新構文は右向きだったりとか……。

そのあたりをいい感じにしてくれる lens というライブラリがあって (lens というと色々あるみたいですが以下これを単にlensと呼びます)、こんなことができます。

{-# LANGUAGE TemplateHaskell #-}
import Control.Lens (makeLenses, (^.))
import Prelude hiding (id)            -- idをフィールド名で使うため

data User = User { _id :: Int, _name :: Name }
data Name = Name { _firstName :: String, _familyName :: String }
makeLenses ''User
makeLenses ''Name

main :: IO ()
main = do
  let user = User 1 (Name "Takiji" "Kobayashi")
  print $ user ^. id                  -- -> 1
  print $ user ^. name . firstName    -- -> "Takiji"

makeLenses は TemplateHaskell によってコンパイル時に動く関数で、データ型の定義からいろいろなものを自動生成します。 すると (^.) などの lens の演算子がデータ型に対して使えるようになり、フィールド名を右向きに繋げていけるようになります。 レコードの更新も同様に右方向でできます。

lens を紹介しているサイトでは大体この makeLenses を紹介していると思います。 しかしレコード型をたくさん作っていると makeLenses ではちょっと面倒になってきます。 なんでかと言うと Haskell のレコード型のフィールド名って別のレコード型と衝突するんですよね。 衝突を避けるためにフィールド名のプレフィクスとしてレコード名をつけたりします。

data User = User { _userId :: Int }
data Pet = Pet { _petId :: Int }
makeLenses ''User
makeLenses ''Pet

main :: IO ()
main = do
  print $ (User 1) ^. userId    -- -> 1
  print $ (Pet 1) ^. petId      -- -> 1

そういう場合に便利なやつとして makeFields というのが lens で提供されています。

data User = User { _userId :: Int }
data Pet = Pet { _petId :: Int }
makeFields ''User
makeFields ''Pet

main :: IO ()
main = do
  print $ (User 1) ^. id    -- -> 1
  print $ (Pet 1) ^. id     -- -> 1

lens で利用するときにプレフィクスがいらなくなるわけですね。 この例だとまだありがたみが薄いですがレコードが増えてきてレコード名が長くなってくると大変便利です。 (というかないと破綻する)。

makeLenses を紹介しているサイトが多いですが makeFields 便利なので使いましょう。 makeFields でも不満がある場合は、lensライブラリにはフィールド名の扱いをより自由にカスタマイズする方法も提供されているみたいなのでそれを使うといいでしょう。

あと今回、lens だけでどうにかする方法を紹介しましたが、拡張可能レコードを使うのが今風でより良いかもしれません。 拡張可能レコードについては haskell/extensible-record.md at master · lotz84/haskell · GitHub がよくまとまっていると思います。

JSONの前に: レコードのデフォルト値

我々は怠惰なので複雑なレコード値を構築するのが面倒です。 レコード型にデフォルト値があって必要なフィールドだけを変更できると便利なことがあります。

そんなとき便利なのが data-default です。

Swagger Petstore の POST /store/order の入力値をこれを使って表現してみます。

{-# LANGUAGE OverloadedStrings #-}
{-# LANGUAGE DeriveGeneric #-}

import GHC.Generics (Generic)
import qualified Data.Text as T
import Data.Default (Default(..))

instance Default Bool where
  def = False

instance Default T.Text where
  def = ""

data PostOrder = PostOrder
                 { _postOrderId :: Int
                 , _postOrderPetId :: Int
                 , _postOrderQuantity :: Int
                 , _postOrderShipDate :: T.Text
                 , _postOrderStatus :: T.Text
                 , _postOrderComplete :: Bool
                 } deriving (Show, Generic)

instance Default PostOrder

main :: IO ()
main = print (def :: PostOrder) -- > PostOrder {_postOrderId = 0, _postOrderPetId = 0, _postOrderQuantity = 0, _postOrderShipDate = "", _postOrderStatus = "", _postOrderComplete = False}

型クラス Default の関数 def がその型のデフォルト値を意味します。 Int などの基本的な型にはすでにインスタンスが用意されていますが、

  • デフォルト値を定めづらい型: Bool など
  • 標準でないライブラリの型: Text など
  • 自作の型

についてはユーザがインスタンスを定義する必要があります。

def は2つの方法で定義できます。

  • ふつうにデフォルト値を手で与える: 上記BoolT.Text
  • Generic を使って自動的に導出する: 上記PostOrder

言語拡張 DeriveGeneric は型についてある種のメタデータを生成することを可能にします。 def はこのメタデータがあれば自動的に導出できるようになっているので、def について言及しなくても PostOrderDefaultインスタンスであると示すだけで def の内容が用意されます。

Haskellのデータ型→JSON

HaskellJSON ライブラリといえば aeson ですが、今回はそれに加えて aeson-casing というのも使います。

PostOrderJSON エンコーディングを記述します。 (既に書いた分は省略)。

import qualified Data.Aeson as JSON
import qualified Data.Aeson.Types as JSON
import qualified Data.Aeson.Casing as JSON
import qualified Data.Text as T
import qualified Data.ByteString.Lazy as LBS

instance JSON.ToJSON PostOrder where
  toJSON = JSON.genericToJSON JSON.defaultOptions { JSON.fieldLabelModifier = JSON.snakeCase . drop (T.length "_postOrder") }

main :: IO ()
main = LBS.putStr $ JSON.encode $ (def :: PostOrder) -- > {"status":"","quantity":0,"pet_id":0,"id":0,"ship_date":"","complete":false}

aeson でも Generic による自動導出ができて、実は toJSON の定義を書かなくても ToJSONインスタンスはできます。 ただ今回は lens のところでも書いたようにフィールド名のプレフィクスを消したいので、 自動導出をカスタマイズする方法を採っています。

T.length の部分はちょっと格好悪いしメンテナンス性を下げるのでいい方法がないか模索中です。

JSONデータを含むHTTPリクエス

ここまで書いてきたすべてのものを使って、いよいよ HTTP リクエストを投げていきます。

HTTP クライアントライブラリには req を使います。 このジャンルでは wreq が有名ですが、req もいいライブラリだと思います。 req の README には開発のモチベーションや wreq 等の他のライブラリとの比較があります。

POST /store/order へのリクエストは req ではこのように書きます。 (既に書いた分と makeFields は省略)。

import Network.HTTP.Req ( req
                        , MonadHttp(..)
                        , GET(..), POST(..)
                        , http, https
                        , (/:)
                        , NoReqBody(..), ReqBodyJson(..)
                        , jsonResponse
                        , responseBody
                        )
import Control.Exception (throwIO)
import Control.Lens ((&), (.~))

instance MonadHttp IO where
  handleHttpException = throwIO

postOrder :: (MonadHttp m) => PostOrder -> m JSON.Value
postOrder model = responseBody <$> req
  POST                 -- HTTPメソッド: POST
  (http "petstore.swagger.io" /: "v2" /: "store" /: "order")
                       -- URL: http://.../store/order
  (ReqBodyJson model)  -- リクエストボディ: (ToJSONのインスタンスである)PosrOrderを
                       --               JSON としてセット
  jsonResponse         -- レスポンスの型: レスポンスは JSON としてパース
  mempty               -- ヘッダなど: 今回はないので mempty

main :: IO ()
main = do
  let order = (def :: PostOrder) & petId .~ 3
                                 & quantity .~ 1
  postOrder order

req の提供する req が HTTP リクエストを投げる関数です。

req は使用環境に MonadHttp を要求します。 今回はシンプルに IO の中で req を使いたいので IOMonadHttpインスタンスにしていますが、 このやり方だと Orphan Instance の警告が出ます。

実は1週間ほど前にこの警告を回避する方法が提供され、最新の req 0.4 で利用可能になっています (詳細)。 まだ LTS Haskell には入っていないのでここでは紹介しませんが、警告が気になる場合は見てみるといいでしょう。

レスポンスにおけるJSONの扱い

これまでリクエストについては型を定義して名前が衝突しないように配慮してデフォルト値も設定して……と手塩にかけてやってきましたが、 レスポンスについてはそこまでしっかりやらなくてもいいと自分は思っています。 基本方針にも書きましたが「出力は厳密に入力には寛容に」という原則に従います。

具体的には lens-aeson というライブラリを使います。 lens-aeson を使って、Swagger Petstore の GET /pet/{:id} のレスポンスを処理してみます。

import Control.Lens ((^?))
import Data.Aeson.Lens (key, _String)

getPetById :: (MonadHttp m) => T.Text -> m JSON.Value
getPetById _petId = responseBody <$> req
  GET
  (http "petstore.swagger.io" /: "v2" /: "pet" /: _petId)
  NoReqBody
  jsonResponse
  mempty

main :: IO ()
main = do
  pet1 <- getPetById "1"
  let pet1Name = pet1 ^? key "name" . _String
  print pet1Name    -- > Just "some name"

レスポンスの型を特に指示していないのに値が取り出せてしまいます。

と言っても型がない訳ではなく、実際は関数によって型が与えられていて、しっかり静的にチェックされます。 ここでの key は引数が JSON のオブジェクトに相当する型であることを仮定します。 同様に _String は取り出した値が文字列であると仮定します。 その仮定が外れるような入力なら(または該当するキーがなかったら)単に Nothing が返ります。

出典を忘れたのですが「優れた言語は型付けのレベルを柔軟に変更できる」という意見を見たことがあります。 今回紹介したやり方は結構型を柔軟に取り扱っている感じじゃないでしょうか。

Haskellは真面目なアプリケーション開発に向いている

qiita.com

↑の記事で(主題ではないと思うものの)Haskellの批判に結構な分量が割かれていて、その批判のなかに「ちょっと違うんじゃないかな」という点がいくつかあったので反論ぽいことを書きます。

"Haskell は真面目なアプリケーション開発には向いてない"について

 これには多分いくつか事例を挙げればよくて、

このように Haskell は多方面の「真面目な」領域で用いられています。(特にプロバイダの認証サーバとか可用性への要求がやばそう)。

少なくとも "Haskell は真面目なアプリケーション開発に向いていない" とは言えないかなと思います。

~完~

各論への反論

これだけだとあれなので個別の批判点についても書きます。

ドキュメントがない?

Haskell の主要なライブラリホスティング場所である Hackage は、ライブラリをアップロードすると自動で Haddock という Javadoc 的な仕組みで API ドキュメントを生成して、ライブラリと一緒に公開します。その意味では Haskell のライブラリはほぼドキュメントが用意されているし、ドキュメントの形式にも統一感があって見やすいと言えます。

他の言語だとたまに20行くらいの Usage でドキュメントを済ませるようなやつとか、API ドキュメントらしきものがあっても引数と戻り値の型が書かれていないやつとか、引数と戻り値の型は書いてあるけど全部 Object 型のやつがあったりしますが、それらに比べると Haskell は最低限のドキュメントとそのアクセス経路が保証されている点でリードしています。

ただ事実としてドキュメントが十分に書かれていないライブラリがあることも確かです。しかし私の実感としては、ドキュメントが十分でないものの多くは未成熟なものや実験的なもののようです。基本的に Haskell のメジャーなライブラリは自動生成の API ドキュメントだけで済ませているということはあまりないと思います。

これは Haskell に限らないことですが、ライブラリのドキュメントが十分でないというのはライブラリが未成熟なサインのひとつです。実用する予定なら未成熟なライブラリをそもそも選ばないようにすべきでしょう。

(まあごく稀に有名なライブラリでもドキュメントが整っていないのがあったりはします。ekmettさんはもう少しlens以外のライブラリのドキュメントも書いてほしい)

あと有名だからとか話題になっているからと言ってそのライブラリが production ready であるとか battle tested であることは意味しません。(これは私もよく間違えてしまうところです)。実用するライブラリを選ぶなら、新奇なものと主流のものは見分けましょう。これは何の言語でも必要なスキルだと思います。

言語とライブラリの進化が速すぎる?

おそらく2011~2013年くらいのことかなと思うのですが、この時期は確かにいろいろと新しいものが出てきました。当該記事で挙げられている Iteratee/Enumerator/Conduit というのはどれもストリーム処理ライブラリで、より良いやり方があるのではないかと盛んに議論されていました。(現在も模索を続けている人たちもいます)。

元記事で腑に落ちていない部分があって "Iteratee/Enumerator/Conduit などを何度も調査し直すことになって全然実装が進まなかった" という部分です。私の記憶によれば当時これらは乱立していて API も洗練されていなかったものの、どれもストリーム処理ライブラリとしての最低限の機能はすでに有していました。開発しているアプリケーションにストリーム処理ライブラリが必要と分かったなら、一度調査してどれかに決定すればいいだけのはずで、何度も調査し直したというのは決定のフェーズを先延ばしにし続けてしまったということなのではないかと思います。これは例えば React で作り始めたウェブアプリを Vue がいいと聞いて Vue で作り直したり Angular がいいと聞いてまた作り直したりという、似た技術が並立する状況でありがちな悪循環にはまってしまったのではないでしょうか。Haskell のライブラリの進化が速いというところには問題の原因はないと思います。

実際、今では Conduit が主流なものの「Iteratee を採用したプロジェクトをメンテしている」という話を私は2016年にも聞きました。おそらくどれを選んでも前に進めたのではないでしょうか。間違ったものを選んでしまうのではないかという不安はもっともですし私もよく分かります。しかし決定はどこかでしないといけないのです。"私はアプリケーションを作りたいだけなのに" と言うならなおさらです。

また元記事では "Yesod は新しいライブラリを大量に使うのでそれに引っ張られた" という趣旨のことも書かれていますが、これは Yesod の問題であって Haskell の問題とは言えません。

互換性壊しすぎ?

これは当時のことをあまりよく覚えておらず自信がないのですが Yesod はともかく Haskell (GHC) が互換性を壊すということがそんなに頻繁にあったでしょうか? 自分にはあまりそんな記憶がないので、Yesod の問題が Haskell の問題と混同されているのではないかという気がしています。(ここはちょっと自信がないです)。

Yesod 以外でもライブラリが互換性を壊すということは当時は時折起こっていたことは覚えています。しかし元記事には Haskell と Yesod にしか言及がないのでその辺りのことは分かりません。

元記事の Yesod が自身のビルド方法を大転換したのについていけないと感じたという指摘は……やはり Haskell の問題ではなく Yesod の問題です。

そういえば最近、 別の言語のウェブフレームワークでビルド方法がdeprecatedになった という話がありましたね。現行verが 2.5 で、2.4 まではドキュメントに書かれている主要なビルド方法だったと記憶しているのですが混乱とかなかったのでしょうか。(追記: id:xuwei さんより、activatorは実態的にsbtとほぼ同じもので、終息による影響はあまりないとのご指摘を頂きました。ありがとうございます。)

全体的に

ここまで見てきたように、元記事は全体的に Yesod の問題であるところを Haskell の問題であるように肥大化して書かれています。Ruby on Rails の問題を Ruby の問題だと言っているようで、ちょっと誠実な態度ではないなと思います。

完全に推測ですが、元記事の筆者の方は、もともと Haskell に強い意欲のあった方なのだろうと思います。意欲があったからこそ Yesod という大規模なフレームワークを導入したり、ストリーム処理ライブラリについてのコミュニティの議論に耳を傾けたりしたのでしょう。そんな方がどこかの時点で可愛さ余って憎さ百倍となって Haskell を嫌いになってしまったということは、Haskell を今も好きでやっている者としては本当に悲しく思います。

しかしいくら Haskell が憎かったとしても、過剰なネガティブキャンペーンを張ることはやめてほしいのです。嘘の情報でせっかくの初学者の意欲を減退させてしまうようなことは、それこそ避けたいと思っています。

私がこういう風に言うのは、私が C++ に挫折して Haskell を始めた人間だからです。人間には向き不向きというのがあって、Haskell の水が合う人もいれば C++ が最高という人もいる。それだけのことではないでしょうか。

で、どうすれば真面目なアプリケーションを作れるの?

自分のユースケースに合致していてかつ成熟したライブラリを選定する方法や、依存関係地獄から自由になるための方法は、最近の Haskell では充実してきています。それらを少し紹介していこうと思います。ただしひとつ念を押しておきたいのは、ライブラリの選定とかビルド環境の構築というのはプログラマの責任範囲であるということです。わざわざ実験的ライブラリを選択して後で後悔することになってもプログラマの自己責任のうちです。これは Haskell に限らずそうです。

依存関係解決、ビルド環境

最近の Haskell には Stackage というサービスおよび Stack というツールがあります。Stackage というのは「依存関係問題を起こさないコンパイラ・ライブラリバージョンのセット」のようなもので、ここからライブラリを落としてくると「コンパイラ-ライブラリ間」および「ライブラリ-ライブラリ間」の依存関係で悩まされることはまずありません。Stackage は基本的に Stack から使います。Stack は Stackage や Cabal や GHC をひとまとめにしていい感じに実行してくれるツールで、stack コマンドを知っておけば ghc コマンドや cabal コマンドを意識しないで Haskell 開発ができます。

冒頭に挙げた Facebook, ASAHIネット, Tsuru Capital の Haskell 事例は Stackage 以前からあるものなので、Stackage が真面目な Haskell 開発に必須かと言われればそうではないのですが、我々としては Stackage を使ってカジュアルに楽をしてやっていけばいいのでないかと思います。

ライブラリの選定

いい感じにメジャーで成熟した Haskell ライブラリを選ぶための指標としては State of the Haskell ecosystem というのがあります。これは Haskell が応用される各分野における Haskell 環境の成熟度と、そこに関連する主要なライブラリ等をリストアップしたものです。ライブラリを選ぶときなどは参考にするとよいでしょう。

また手前味噌ですが、当ブログでも Haskellライブラリ所感2016 というのを書いています。恐縮ながら合わせてご参照下さい。

別の観点としては「(Hackageだけでなく)Stackageに上がっているライブラリは最近までメンテされていることが期待できる」という大雑把な指標もあります。

人間的サポート

もし本当にビジネスとして真面目に Haskell を採用するなら、Haskellコンサルティング会社と契約するのもひとつの手だと思います。有名な会社としては FP Complete や Well-Typed があります。Well-Typed はヨーロッパの会社ですが日本にもクライアントがいると彼らのサイトに書いてあります。

ふつうはそこまで本格的なサポートを受けるのはハードルが高いと思います。そういう場合は 日本Haskellユーザーグループ にコンタクトを取るのが良いでしょう。個人であれば、開放されている Slack チームに参加して質問チャンネルで何か質問を投げると暇な Haskeller が答えてくれます。実際に業務で Haskell を利用している人も何人か参加しています。(追記: 日本Haskellユーザーグループのsubredditが作られました。またStackOverflowなどの質問が当該Slackに流れるようになりました。 Slackに参加するのは気が引けるという人はこれらを利用するのも良いでしょう)

追記 最近のYesodについて

読み返すと「Yesodが悪い」みたいな書き方になっていたのでフォローしておくと、最近の Yesod はかなり良くなっています。年月を経て API が洗練されてきたとかだけでなく、Stackage の影響を大きく受けて初期構築や依存解決がとても楽になっています。というか、Yesod の開発チームが Yesod の構築を楽にするために Stack および Stackage を作っているという関係のようです。(このあたりの関係はあまり詳しくないです)。

超技術書典でGHCJSの本を出します

出します。

GHCJSの仕組みの話はほとんどなくて、あくまで使い方とか周辺事情の話になります。

GHCJSって昔は導入すること自体が難しくて、他のHaskell系AltJSに水をあけられている感があったのですが、 最近は(時間とディスク容量はかかるけど)簡単に導入できるようになりました。 またFFIを直接書くのではなく、EDSLとしてJavaScript処理を記述する方法も提供されるようになったので、かなり使いやすくなったと思います。

超技術書典Day1(2017-04-29)で id:y_taka_23 さんのスペースに委託して置かせてもらうことになっていますので、是非。

techbookfest.org