Haskell

Haskell は汎用の純関数型プログラミング言語です。

インストール

Haskell は Linux でネイティブに実行することができるマシンコードを生成します。(コンパイル済みの) バイナリのソフトウェアを実行するのに特別なものは必要ありません。公式リポジトリや ArchHaskell で提供されているソフトウェアと同じです。一方、AUR のパッケージやソースコードは、ソフトウェアをビルドするのにコンパイラを必要とします。

コンパイラをインストールするだけで Haskell のソースコードがビルドできるようになります。Haskell での開発を始めるためのツールのコンプリートセットである Haskell-Platform もあります。

コンパイラ

Haskell のソースコードをネイティブコードにビルドするには、コンパイラをインストールする必要があります。複数の 実装 が存在しますが、一番よく使われている (事実上のリファレンス実装となっている) のは GHC (Glasgow Haskell Compiler) です。公式リポジトリの ghc でインストールができます。

次のファイルを用意して:

Main.hs

main = putStrLn "Hello, World"

以下を実行して試すことができます:

$ ghc -dynamic Main.hs
$ ./Main 

Hello, World

リンクの問題

バージョン 8.0.2-1 から、Arch の ghc パッケージには GHC プラットフォームライブラリの静的バージョンが含まれていません。community リポジトリの haskell-* パッケージも同じです。GHC はデフォルトで静的リンクを使用します、動的リンクを使うときには -dynamic フラグを使用します。Cabal の場合、以下のようになります:

$ cabal configure --disable-library-vanilla --enable-shared --enable-executable-dynamic

• --disable-library-vanilla は静的ライブラリの作成を止めます (プロジェクトにライブラリが含まれる場合)。
• --enable-shared は共有ライブラリの作成を有効にします (プロジェクトにライブラリが含まれる場合)。
• --enable-executable-dynamic は実行ファイルで動的リンクを使用します (プロジェクトに実行ファイルが含まれる場合)。

~/.cabal/config に上記のフラグを設定することで、デフォルトで全てのプロジェクトで動的リンクを使うことができます:

~/.cabal/config

library-vanilla: False
shared: True
executable-dynamic: True

pacman でパッケージ化されている Haskell モジュールの多くは動的リンクを使っており、AUR のパッケージも同様です。GHC はコンパイラのバージョン間で ABI 互換性を維持していないため、パッケージシステムから外れたローカルの開発環境では静的リンクを使うことが推奨されます。

ノート: この記事では、静的リンクとは完全に静的な ELF バイナリの生成を意味しません。単体の ELF バイナリに静的リンクされるのは Haskell のコードだけで、glibc など他のシステムライブラリは動的リンクされる可能性があります。

静的リンク

静的リンクを使うには、最低でも ghc-static パッケージで静的ブートライブラリをインストールする必要があります。ブートライブラリや haskell-* パッケージでインストールされないライブラリに依存するプロジェクトをビルドできるようになります。

残念ながら、プロジェクトが haskell-* パッケージのどれかに依存する場合、Cabal は依存関係を解決するときに静的ライブラリが存在しないことを考慮しません。したがって、既存の haskell-* パッケージを使用しようとすると リンカのエラー によって静的ライブラリが存在しないことがわかります。ghc-static と違って、問題を解決するための haskell-*-static パッケージは存在しません。

問題を回避するために、ghc-pristine^AUR をインストールして既存の GHC 環境をラッピングして /usr/share/ghc-pristine に別の GHC 環境を作成することができます。パッケージデータベースにはブートライブラリのみが含まれます。静的リンクでソフトウェアをビルドするときは、ラッピングされたコマンド /usr/share/ghc-pristine/bin/ghc を実行します。Cabal の場合、以下のようになります:

$ cabal configure --with-compiler=/usr/share/ghc-pristine/bin/ghc

(cabal user-config init で作成される) ~/.cabal/config を編集することで設定を永続化できます。ghc-static は依然として必要なので注意してください。

ghc-pristine の代わりに以下の方法もあります:

• cabal install --force-reinstalls を手動で実行して対応する haskell-* パッケージを遮蔽する。既存の haskell-* パッケージと重なる依存パッケージを全て指定する必要があるため面倒です。
• 完全に分離された GHC 環境を使用する: GHC と cabal-install の公式 Linux バイナリをダウンロードしてどこかに展開する。ghc-pristine と同じことになりますが、ghc-pristine の方が必要なディスク容量が小さくてすみます。

Cabal で静的にリンクしたパッケージをビルド (共有ライブラリを使用しない)

このセクションでは公式の cabal-install パッケージの代わりに Hackage から cabal-install をインストールする方法を説明します。動的リンクが必要な公式の cabal-install と異なり、Hackage の cabal-install は 共有ライブラリ を使用せずに Haskell パッケージをビルドします。

原則的に cabal-install では Haskell のコードをリンクする時に静的・動的どちらの方法も選択できます。Arch では基本的な Haskell ライブラリ (haskell-* パッケージ) が共有オブジェクト (.so ファイル) として用意されており Cabal でグローバルにライブラリが登録されるため、静的リンクで同じライブラリを使用すると問題が起こります。リンクの エラー を避けるために、同じ環境に静的・動的な Haskell パッケージを混在させてはいけません。どちらかのパッケージがグローバルに登録されている場合 (ghc-pkg list コマンドで確認できます)、Cabal は必要なパッケージを取得しません (必要なパッケージのリンクの種別は関係ありません)。

そのため、インストールする Haskell 関連のパッケージはコンパイルの ghc と静的ブートライブラリの ghc-static だけに限ります (stack, cabal-helper^{[リンク切れ: パッケージが存在しません]}, cabal-install, 公式リポジトリに存在する haskell-* 動的ライブラリ [1] はインストールしません)。

Haskell パッケージのビルドツールとして Stack を使うこともできます。Stack はデフォルトで静的リンクを使います。Cabal で静的リンクを使ってビルドしたい場合、以下の手順に従うことで Hackage から cabal-install をインストールできます。ここで Stack ツールは必要な依存パッケージを取得して cabal-install をビルドするのに使用します。

まず stack-bin^{AUR[リンク切れ: パッケージが存在しません]} をインストールしてください。Cabal のコンパイルをブートストラップするのに使用します。依存パッケージとして haskell-* 動的ライブラリを含む公式 Arch リポジトリのパッケージを使うことはしません。

それから Stack のパッケージインデックスをダウンロードします。Stack は cabal-install のコンパイルをブートストラップするためだけに使いますが、インストール済みの ghc コンパイルも使用します:

$ stack setup --system-ghc

そして cabal-install をインストール:

$ stack install --system-ghc cabal-install

新しくインストールされる cabal-install は共有ライブラリを使わずにコンパイルされ、パッケージをビルドするときにデフォルトで共有ライブラリを使用しません。また、cabal-install はインストールされた ghc コンパイラを使用します。

Haskell Platform

Haskell での開発を簡単に始められる、haskell-platform バンドルは次のように説明されます:

Haskell のプログラミングを始める一番簡単な方法です。立ち上げて動作させるのに必要な全てが入っています。次のように考えて下さい "Haskell: batteries included" (電池付属)。

公式リポジトリから以下のパッケージをインストールすることで Haskell Platform を置き換えられます:

• ghc (ghc) — 動的 ブートライブラリ (ghc-libs) が付属するコンパイラ。静的ブートライブラリ (ghc-static) は別個にインストールが必要です。
• cabal-install (cabal-install) — Hackage の依存解決とパッケージの取得に焦点が置かれたビルドツール。
• stack (stack) — Stackage の厳選されたスナップショットとパッケージの取得に焦点が置かれたビルドツール。
• haddock (haskell-haddock-api^{[リンク切れ: アーカイブ: aur-mirror]} と haskell-haddock-library) — ドキュメントを生成するためのツール
• alex (alex) — 字句解析器ジェネレータ
• happy (happy) — パーサジェネレータ

また、[2] に従って stack を使って Haskell 環境を管理する方法もあります。

Haskell パッケージの管理

Haskell ライブラリや実行可能ファイルの多くはパッケージにまとめられています。どれも Hackage から利用することが可能です。また、厳選されたパッケージが Stackage に存在します。パッケージをインストール・管理する方法は複数存在します:

• 公式リポジトリ
• cabal-install
• stack
• Arch User Repository

cblrepo は Linux ディストリビューションの Haskell パッケージを管理するために使用するツールです。これのラッパーである、cabal2pkgbuild-git^{AUR[リンク切れ: アーカイブ: aur-mirror]} は Hackage パッケージから PKGBUILD を作成することができます。新しい Haskell パッケージを作成することについては Haskell パッケージガイドラインに詳しく記載があります。

方法ごとのプラス面とマイナス面

以下の表はそれぞれのパッケージ管理方法のメリットとデメリットのまとめです。

方法	良い点	悪い点
公式リポジトリ	ArchLinux 開発者が運営、パッケージのバージョンの整合性に問題なし、コンパイル済み	利用できるパッケージの数が限られる、動的ライブラリのみ
cabal-install	全てのパッケージが利用可能、root 権限が不要	インストール先がホームフォルダ、cabal-install はパッケージマネージャではない、パッケージのバージョンの整合性に問題がある可能性 (別名 cabal hell)
stack	(Stackage にある) 全てのパッケージが利用可能、root 権限が不要	インストール先がホームフォルダで、バージョンがスナップショットに固定、特定のパッケージを削除するのは難しい
Arch User Repository	始めるのが簡単	パッケージのメンテナンスがなくなる可能性、パッケージのバージョンの整合性に問題がある可能性

cabal-install

公式リポジトリから cabal-install をインストールしてください。

ノート: cabal-install パッケージには "cabal" コマンドラインユーティリティが含まれています。一方、Cabal は "Cabal" ライブラリを提供するパッケージであり、cabal-install と stack の両方が使用します。

準備

パスを指定しないでインストールした実行可能ファイルを実行するには、cabal のバイナリフォルダ ~/.cabal/bin を $PATH 変数に追加する必要があります。シェルの設定ファイルに以下の行を記述することで追加できます (bash の場合 ~/.bashrc、zsh の場合 ~/.zshrc):

PATH=$PATH:~/.cabal/bin

cabal sandbox の中で実行したい場合:

PATH=$PATH:.cabal-sandbox/bin

パッケージのインストール

$ cabal update

$ # Dynamic linking
$ cabal install --disable-library-vanilla --enable-shared --enable-executable-dynamic <pkg>

$ # Static linking (requires ghc-static and ghc-pristine)
$ cabal install --with-compiler=/usr/share/ghc-pristine/bin/ghc <pkg>

-j を追加することで並列コンパイルができます。また、--global フラグを使うことでシステム全体にパッケージをインストールすることもできますが、これは非推奨です。ユーザーごとのインストールでは、全てのファイルは ~/.cabal に配置されライブラリは ~/.ghc に登録されるので、フォルダを削除することで簡単にクリーンアップすることができます。システム全体にインストールすると、ファイルがファイルシステムに散らばってしまい管理するのが難しくなります。

サンドボックス

警告: サンドボックスは廃止予定であり、Cabal 3.4 で取り除かれます。

Cabal のサンドボックスは矛盾のないローカルパッケージデータベースと環境を提供します (Python における virtual-env あるいは Ruby における rvm に似ています)。カレントディレクトリにサンドボックスを作成するには:

$ cabal sandbox init

削除するには:

$ cabal sandbox delete

カレントディレクトリにサンドボックスが存在する場合、デフォルトで cabal はその環境を使用します。#パッケージのインストールと同じ手順でインストールができます。別のサンドボックスを使いたい場合、cabal exec "$SHELL" を実行してサンドボックスのシェルを起動します。そこからディレクトリを移動しても cabal は指定されたサンドボックスを使用します。また、cabal に --sandbox-config-file=/somewhere/cabal.sandbox.config フラグを渡して使うことも可能です。

cabal のサンドボックスの中で実行ファイルを実行するには、

PATH=$PATH:$PWD/.cabal-sandbox/bin

を設定するか、cabal exec "$SHELL" でローカルシェルを起動する必要があります。

パッケージの削除

パッケージの削除を簡単に行う方法はありません。Cabal には削除機能がありません。

サンドボックスにインストールした場合、他のサンドボックスへの影響を及ぼさずに削除することができます。

zsh の自動補完を使うことで haskell パッケージを探し出しやすくなります。

Haskell のパッケーシステム全体を修正・再インストールしたい場合、~/.cabal と ~/.ghc を削除してスクラッチからインストールしなおしてください。GHC をアップグレードした場合に必要になります。

stack

Stack は依存関係の解決よりも自動的に精選された、矛盾のないパッケージに焦点を置いたビルドツールです。Stackage スナップショットの中で共存させる限り、バージョンの衝突に気をつかうことなくパッケージを簡単にインストールすることができます。Stack は stack, stack-static^AUR, stack-bin^{AUR[リンク切れ: パッケージが存在しません]} パッケージでインストールできます。後者は静的リンクライブラリを提供し、様々な haskell-* 依存パッケージを必要としません。詳しくは § Install/upgrade # Arch Linux を参照。

ヒントとテクニック

静的リンク

ノート:

• このセクションでは、静的にリンクされた Haskell パッケージを Arch 上でビルドしながら、公式リポジトリからインストールされた GHC を使用する方法について説明します。続行する前に、~/.cabal ディレクトリと ~/.stack ディレクトリが存在する場合は必ず削除してください。
• この記事の文脈において、静的リンクは完全に静的な ELF バイナリを生成することを意味するものではありません。Haskell コードのみが単一の ELF バイナリに静的にリンクされ、それは glibc などの他のシステムライブラリに動的にリンクされる場合があります。

静的リンクを使用するには、少なくとも、ghc-static パッケージを通じて静的ブートライブラリをインストールする必要があります。これにより、ブートライブラリだけでなく、公式リポジトリから haskell-* パッケージを通じてインストールされない他のライブラリにもっぱら依存するプロジェクトをビルドできるようになります。

残念ながら、プロジェクトがインストールした動的にリンクされた haskell-* パッケージのいずれかに依存している場合、Cabal は依存関係の解決時に静的ライブラリの不在を考慮しません。その結果、既存の haskell-* パッケージを使用しようとし、静的ライブラリを検出すると linker errors で失敗します。:

Could not find module ‘SomePackage.SomeModule’
There are files missing in the ‘somepackage-0.1.0.0’ package,
try running 'ghc-pkg check'.
Use -v (or `:set -v` in ghci) to see a list of the files searched for.

ghc-staticとは異なり、連携可能な "haskell-*-static" パッケージはありません。ただし、以下の各セクションで説明するように、この問題を回避する他の方法もあります。

静的グローバルパッケージデータベース

直接的な アプローチ は、公式の ghc-static パッケージによって提供されており、代替の "静的" パッケージが公開されています。グローバルパッケージデータベース(/usr/lib/ghc-version/static-package.conf.d)静的データベースは、静的にリンク可能なブートパッケージのみに制限されているため、デフォルトデータベースの代わりに静的データベースを使用するように Cabal が再構成されている場合、動的専用の haskell-* パッケージがリンクされていないかのように動作します。

静的データベースの正確なパスは、次のようなコマンドを使用して構築時に決定できます。

$ ghc --print-global-package-db | sed 's/\(package\.conf\.d\)$/static-\1/'

/usr/lib/ghc-version/static-package.conf.d

静的データベースを使用できるようにする方法は次のとおりです。

• Cabal でパッケージを構築する場合、次のフラグを渡すと、グローバルパッケージの選択をブートパッケージのみに制限できます。

$ cabal configure --ghc-pkg-option="--global-package-db=$(ghc --print-global-package-db | sed 's/\(package\.conf\.d\)$/static-\1/')"

• Cabal ではなく GHC を使用して直接ビルドする場合、次のフラグを渡してグローバルパッケージデータベースをオーバーライドできます。

$ ghc -clear-package-db -package-db "$(ghc --print-global-package-db | sed 's/\(package\.conf\.d\)$/static-\1/')" -user-package-db ...

ghc-pristine

ghc-pristine^AUR パッケージをインストールします。このパッケージは既存の GHC インストールをラップして、ブートライブラリのみを含むパッケージデータベースを備えた別の GHC ディストリビューションを /usr/share/ghc-pristine に作成します。これにより、動的にリンクされた haskell-* パッケージを使用せずに半分離環境が効果的に作成されますが、それでも公式リポジトリの GHC コンパイラーが利用されます。次に、静的リンクを使用してソフトウェアを構築するには、ラップされたコンパイラー /usr/share/ghc-pristine/bin/ghc を呼び出すだけです。Cabal の場合、これは ~/.cabal/config の次の構成に相当します。

~/.cabal/config

with-compiler: /usr/share/ghc-pristine/bin/ghc

プロジェクトディレクトリから次のコマンドを実行して、プロジェクトごとにコンパイラへのパスを指定することもできます。

$ cabal configure --with-compiler=/usr/share/ghc-pristine/bin/ghc

cabal-static

Arch で静的リンクを取り戻すもう 1 つの方法は、cabal-static^AUR パッケージをインストールすることです。公式の cabal-install とは異なり、これは動的にリンクされた haskell-* の依存関係を公式リポジトリから取得せず、同じシステムにインストールされた静的 Haskell ライブラリと共有 Haskell ライブラリの混合を回避します。その後、次の制限付きで通常どおり Cabal を使用できます: インストールした他の Haskell パッケージが ghc、ghc-libs のみであることを確認する必要があります。および ghc-static (cabal-install、stack、および公式リポジトリで入手可能な haskell-* パッケージではありません。)

stack-static

stack-static^AUR パッケージをインストールします。cabal-static メソッドと同様に、公式リポジトリからインストールした他の Haskell パッケージが ghc、ghc-libs、および ghc-static のみであることを確認してください。次に、Haskell#動的リンク用のスタックの設定 で説明されているように、システム GHC を使用するようにスタックをセットアップします。

$ stack setup --system-ghc --resolver resolver

これらのオプションを永続的にするには、次のスニペットを ~/.stack/config.yaml に貼り付けます。

~/.stack/config.yaml

# Stop downloading GHCs into isolated locations under ~/.stack.
install-ghc: false

# Allow Stack to pick the system GHC (false by default).
system-ghc: true

# Allow to use, say, Stackage snapshot for GHC 8.8.2 with system GHC 8.8.3.
compiler-check: newer-minor

この設定では、通常と同じように静的にリンクされたパッケージをビルドできますが、Stack によって提供される GHC の代わりにシステム GHC インストールを使用します。

hpack-static-bin

hpack-static-bin^AUR は、haskell-hpack の代わりに静的にリンクされた (haskell-* 依存関係がないことを意味します) を提供します。プリコンパイルされているため、make 依存関係は必要ありません。

ghcup

ghcup は、GHC をシステムパッケージマネージャーの外部でローカルにインストールできるツールです。さらに、複数のバージョンの GHC を並行してサポートします。このツールが提供する GHC を使用すると、システム GHC がまったく使用されないため、静的リンクに関連する問題が完全に回避されます。また、システム GHC とそのブートライブラリのアップグレードによって引き起こされる、ローカルに構築されたライブラリの破損も自然に回避されます。

参照

• すごいHaskellたのしく学ぼう! (英語版)
• Real World Haskell