「Haskell」の版間の差分

提供: ArchWiki
ナビゲーションに移動 検索に移動
(同期)
(→‎stack-static: 翻訳を修正)
 
(3人の利用者による、間の13版が非表示)
1行目: 1行目:
 
[[Category:プログラミング言語]]
  
[[Category:プログラミング言語]]
 
[[en:Haskell]]
  
[[en:Haskell]]
  +
{{Related articles start}}
−
[http://www.haskell.org Haskell] は汎用の純関数型プログラミング言語です。
  
  +
{{Related|Haskell パッケージガイドライン}}
  +
{{Related articles end}}
  +
  +
[[Wikipedia:ja:Haskell|Wikipedia]] から:
  +
:Haskell は高階関数や静的多相型付け、定義可能な演算子、例外処理といった多くの言語で採用されている現代的な機能に加え、パターンマッチングやカリー化、リスト内包表記、ガードといった多くの特徴的な機能を持っている。また、遅延評価や再帰的な関数や代数的データ型もサポートしているほか、独自の概念として圏論のアイデアを利用し参照透過性を壊すことなく副作用のある操作 (例えば 代入、入出力、配列など) を実現するモナドを含む。このような機能の組み合わせにより、手続き型プログラミング言語では記述が複雑になるような処理がしばしば簡潔になるばかりではなく、必要に応じて手続き型プログラミングを利用できる。
   
 
== インストール ==
  
== インストール ==
   
  +
{{Note|Haskell のインストールにはいくつかの選択肢があり、Arch Linux がサポートしているものもあれば、Haskell が公式にサポートしている Linux ディストリビューションもあります。
−
Haskell は Linux でネイティブに実行することができるマシンコードを生成します。(コンパイル済みの) バイナリのソフトウェアを実行するのに特別なものは必要ありません。[[公式リポジトリ]]や [[ArchHaskell]] で提供されているソフトウェアと同じです。一方、[[AUR]] のパッケージやソースコードは、ソフトウェアをビルドするのにコンパイラを必要とします。
  
  +
* Arch [[公式リポジトリ]] から [[pacman]] を使って Haskell をインストールしたい場合は、[[Haskell#ネイティブインストール|ネイティブインストール]]、[[Haskell#設定|設定]]、[[Haskell#パッケージ管理|パッケージ管理]] を読み進めてください。数百の {{ic|haskell-*}} パッケージをシステムにインストールするかもしれないことに注意してください。
  +
* もし [https://www.haskell.org/downloads 公式サイト] から Arch リポジトリのパッケージを使わずに Haskell バイナリをインストールしたい場合は、[[Haskell#代替インストール|代替インストール]] のセクションに進んでください。
  +
}}
   
  +
=== ネイティブインストール ===
−
コンパイラをインストールするだけで Haskell のソースコードがビルドできるようになります。Haskell での開発を始めるためのツールのコンプリートセットである ''Haskell-Platform'' もあります。
  
   
  +
Haskell は、Linux 上でネイティブに実行できるマシンコードを生成します。{{Pkg|xmonad}} や {{Pkg|pandoc-cli}} などのバイナリ (コンパイル済み) ソフトウェアを実行するために特別に必要なものは何もありません。一方、[[AUR]] パッケージのビルドやソフトウェアの開発には、コンパイラとビルド ツールをインストールする必要があります。
−
=== コンパイラ ===
  
   
  +
Haskell の最新バージョンをインストールするには、次のパッケージを [[インストール]] します。
−
Haskell のソースコードをネイティブコードにビルドするには、コンパイラをインストールする必要があります。複数の [http://www.haskell.org/haskellwiki/Implementations 実装] が存在しますが、一番よく使われている (事実上のリファレンス実装となっている) のは GHC (Glasgow Haskell Compiler) です。公式リポジトリの {{Pkg|ghc}} でインストールができます。
  
   
  +
# {{Pkg|ghc}} - Haskell コンパイラ。いくつかの [https://www.haskell.org/haskellwiki/Implementations 実装] がありますが、最もよく使われている (現在では ''事実上'' リファレンスとなっている) のは [https://www.haskell.org/ghc GHC] (Glasgow Haskell Compiler) です。
−
次のファイルを用意して:
  
  +
# {{Pkg|cabal-install}} または {{Pkg|stack}} です。- GHC に依存して Haskell ソースをコンパイルするビルドツール。[https://www.haskell.org/cabal Cabal] は依存関係の解決と [https://hackage.haskell.org Hackage] (Haskell コミュニティのオープンソースソフトウェアの中央パッケージアーカイブ) からのソースパッケージに焦点を当てた古典的なビルドツールです。[https://www.haskellstack.org Stack] は、[https://www.stackage.org Stackage] (Hackage の安定したサブセットで、互いにうまく動作することが知られているパッケージのキュレーションセット (スナップショット) を提供する) のキュレーションされたスナップショットとソースパッケージに焦点を当てた別のビルドツールです。
   
  +
{{Tip|Cabal と Stack はどちらも安定した成熟したビルドツールです。Haskell 開発者の多くは Cabal を使用していますが、Stack を好む開発者もいます。どのツールを選択すればよいかわからない場合は、両方をインストールして、どちらが最適であるかを確認してください。}}
−
{{hc|Main.hs|main = putStrLn "Hello, World"}}
  
  +
  +
== 設定 ==
  +
  +
バージョン [https://github.com/archlinux/svntogit-community/commit/7a948cdfb808afd3ce6f93047ae0dc1778e79f9f 8.0.2-1] 以降、''extra'' に含まれる Arch {{Pkg|ghc}} パッケージと全ての [https://archlinux.org/packages/?q=haskell haskell-*] パッケージは動的にリンクされるライブラリのみを提供します。そのため、リンクに成功するためには GHC, Cabal, Stack を動的リンクに設定する必要があります。
  +
  +
動的リンクを使用すると、通常、(実行中の複数の Haskell プログラム間でページを共有することにより) ビルドが高速化され、ディスクと RAM の使用量が削減され、GHC 間の混合エラーのトラブルシューティングから解放されます。しかし、これには独自の欠点もあります。それは、{{Pkg|ghc}}、{{Pkg|ghc-libs}}、または [https://archlinux. org/packages/?q=haskell haskell-*] パッケージは、GHC でコンパイルされたライブラリが安定した [[Wikipedia:ja:アプリケーションバイナリインタフェース|ABI]] を提供しないためです。このような壊れたバイナリを実行すると、通常のメッセージ {{ic|error whileloadingsharedlibraries:libHS...so:cannotopensharedobjectfile:No such file or directory}} が表示されます。これを修正するには、壊れたツールを再構築して再インストールし、新しいライブラリに再リンクします。
  +
  +
一方、静的リンクは一般に保守が容易で、依存関係を更新するたびにすべてのツールをソースから再構築する必要がありません。これらの理由から、静的リンクは、パッケージシステム外のローカル開発では多くの場合推奨されるオプションです。 静的リンクを希望する場合、詳細については [[Haskell#静的リンク|静的リンク]] または [[Haskell#代替インストール|代替インストール]] を参照してください。
  +
  +
{{Note|Arch が Haskell パッケージの動的リンクに移行した理由の詳細な説明については、この [https://www.reddit.com/r/linux/comments/9emwtu/arch_linux_ama/e5qssdz メンテナーの返答] を参照してください。}}
  +
  +
=== GHC を直接呼び出す ===
  +
  +
正常にリンクするには、{{ic|-dynamic}} フラグを GHC に渡す必要があります。次のファイルで試すことができます。
  +
  +
{{hc|Main.hs|2=
  +
main = putStrLn "Hello, World"
  +
}}
   
  +
次のようにコンパイルして実行します。
−
以下を実行して試すことができます:
  
   
 
{{hc|
  
{{hc|
 
$ ghc -dynamic Main.hs
  
$ ghc -dynamic Main.hs
−
$ ./Main |
 +
$ ./Main|
 
Hello, World
  
Hello, World
 
}}
  
}}
   
−
== リンクの問題 ==
 +
=== Cabal を動的リンク用に構成する ===
   
  +
まず、次のコマンドを実行して、Hackage からパッケージの最新リストをダウンロードし、グローバル設定ファイル {{ic|~/.cabal/config}} (または、{{ic|$CABAL_CONFIG}} が指すファイル) を作成します。
−
バージョン [https://git.archlinux.org/svntogit/community.git/commit/trunk?h=packages/ghc&id=7a948cdfb808afd3ce6f93047ae0dc1778e79f9f 8.0.2-1] から、Arch の {{Pkg|ghc}} パッケージには GHC プラットフォームライブラリの静的バージョンが含まれていません。''community'' リポジトリの [https://www.archlinux.jp/packages/?q=haskell haskell-*] パッケージも同じです。GHC はデフォルトで静的リンクを使用します、動的リンクを使うときには {{ic|-dynamic}} フラグを使用します。Cabal の場合、以下のようになります:
  
   
  +
$ cabal update
−
$ cabal configure --disable-library-vanilla --enable-shared --enable-executable-dynamic
  
   
  +
{{Tip|定期的に {{ic|cabal update}} を実行して、ローカルのパッケージと依存関係のリストを Hackage の最新バージョンと同期することをお勧めします。}}
−
* {{ic|--disable-library-vanilla}} は静的ライブラリの作成を止めます (プロジェクトにライブラリが含まれる場合)。
  
−
* {{ic|--enable-shared}} は共有ライブラリの作成を有効にします (プロジェクトにライブラリが含まれる場合)。
  
−
* {{ic|--enable-executable-dynamic}} は実行ファイルで動的リンクを使用します (プロジェクトに実行ファイルが含まれる場合)。
  
   
  +
Cabal を動的リンク用に設定するには、{{ic|~/.cabal/config}} 内の次のオプションのコメントを解除して編集します。
−
{{ic|~/.cabal/config}} に上記のフラグを設定することで、デフォルトで全てのプロジェクトで動的リンクを使うことができます:
  
   
 
{{hc|~/.cabal/config|
  
{{hc|~/.cabal/config|
41行目: 66行目:
 
shared: True
  
shared: True
 
executable-dynamic: True
  
executable-dynamic: True
  +
program-default-options
  +
ghc-options: -dynamic
 
}}
  
}}
   
  +
* {{ic|library-vanilla: False}} は静的ライブラリの作成を抑制します (プロジェクトにライブラリが含まれている場合)
−
[[pacman]] でパッケージ化されている Haskell モジュールの多くは動的リンクを使っており、[[AUR]] のパッケージも同様です。GHC はコンパイラのバージョン間で [[w:ja:Application Binary Interface|ABI]] 互換性を維持していないため、パッケージシステムから外れたローカルの開発環境では静的リンクを使うことが推奨されます。
  
  +
* {{ic|shared: True}} は共有ライブラリの作成を有効にします(プロジェクトにライブラリが含まれている場合)
  +
* {{ic|executable-dynamic: True}} は実行ファイルにダイナミックリンクを使用します (プロジェクトに実行ファイルが含まれている場合)
  +
* {{ic|ghc-options: -dynamic}} は GHC の全ての呼び出しに {{ic|-dynamic}} フラグを追加します (例えば、パッケージが自明でない{{ic|Setup.hs}} を持っている場合)
   
  +
=== 動的リンク用のスタックの設定 ===
−
{{Note|この記事では、静的リンクとは完全に静的な ELF バイナリの生成を意味しません。単体の ELF バイナリに静的リンクされるのは Haskell のコードだけで、''glibc'' など他のシステムライブラリは動的リンクされる可能性があります。}}
  
   
  +
{{ic|stack setup}} コマンドを使用してスタックを初期化し、グローバル設定ファイル {{ic|~/.stack/config.yaml}} を作成できます。デフォルトでは、スタックは最初の呼び出し時に独自のバージョンの GHC を隔離された場所に自動的にダウンロードします。代わりにスタックにシステム GHC インストールを使用させるには、{{ic|--system-ghc}} フラグと {{ic|--resolver}} フラグを指定して {{ic|stack setup}} を実行します。
−
=== 静的リンク ===
  
   
  +
$ stack setup --system-ghc --resolver ''resolver''
−
静的リンクを使うには、最低でも {{Pkg|ghc-static}} パッケージで静的ブートライブラリをインストールする必要があります。ブートライブラリや {{ic|haskell-*}} パッケージでインストールされないライブラリに依存するプロジェクトをビルドできるようになります。
  
   
  +
システムの GHC と互換性のあるリゾルバーを指定する必要があることに注意してください。それ以外の場合、スタックは {{ic|--system-ghc}} フラグを喜んで無視し、GHC の独自のコピーをダウンロードします。システム GHC のバージョンは、{{ic|ghc --version}} コマンドを使用して確認できます。
−
残念ながら、プロジェクトが {{ic|haskell-*}} パッケージのどれかに依存する場合、Cabal は依存関係を解決するときに静的ライブラリが存在しないことを考慮しません。したがって、既存の {{ic|haskell-*}} パッケージを使用しようとすると [https://bugs.archlinux.org/task/54563#comment158808 リンカのエラー] によって静的ライブラリが存在しないことがわかります。{{ic|ghc-static}} と違って、問題を解決するための {{ic|haskell-*-static}} パッケージは存在しません。
  
   
  +
{{hc|$ ghc --version|
−
問題を回避するために、{{AUR|ghc-pristine}} をインストールして既存の GHC 環境をラッピングして {{ic|/usr/share/ghc-pristine}} に別の GHC 環境を作成することができます。パッケージデータベースにはブートライブラリのみが含まれます。静的リンクでソフトウェアをビルドするときは、ラッピングされたコマンド {{ic|/usr/share/ghc-pristine/bin/ghc}} を実行します。Cabal の場合、以下のようになります:
  
  +
The Glorious Glasgow Haskell Compilation System, version 8.10.2
  +
}}
   
  +
次に、[https://www.stackage.org Stackage] Web サイトにアクセスし、システムの GHC バージョンに一致する適切な長期サポート (LTS) または夜間スナップショットを選択します。コマンドラインの {{ic|--resolver}} フラグに対して選択したスナップショットを使用します。例:{{ic|--resolver lts-16.15}} または {{ic|--resolver nightly-2020-09-01}}
−
$ cabal configure --with-compiler=/usr/share/ghc-pristine/bin/ghc
  
   
  +
Stackage は通常、新しい GHC リリースより遅れます。システム GHC のスタックスナップショットがまだリリースされていない場合があります。この場合、GHC の以前のマイナーバージョンのスナップショットを選択するか、Haskell インストールを一時的にダウングレードして、新しい GHC リリースのサポートが最終的に Stackage に提供されるまで待つことをお勧めします。
−
({{ic|cabal user-config init}} で作成される) {{ic|~/.cabal/config}} を編集することで設定を永続化できます。{{ic|ghc-static}} は依然として必要なので注意してください。
  
   
  +
動的リンク用にスタックを構成するには、次のスニペットを {{ic|~/.stack/config.yaml}} に追加します。
−
{{ic|ghc-pristine}} の代わりに以下の方法もあります:
  
   
  +
{{hc|~/.stack/config.yaml|
−
* {{ic|cabal install --force-reinstalls}} を手動で実行して対応する {{ic|haskell-*}} パッケージを遮蔽する。既存の {{ic|haskell-*}} パッケージと重なる依存パッケージを全て指定する必要があるため面倒です。
  
  +
# Stop downloading GHCs into isolated locations under ~/.stack.
−
* 完全に分離された GHC 環境を使用する: [https://www.haskell.org/ghc/ GHC] と [https://www.haskell.org/cabal/download.html cabal-install] の公式 Linux バイナリをダウンロードしてどこかに展開する。{{ic|ghc-pristine}} と同じことになりますが、{{ic|ghc-pristine}} の方が必要なディスク容量が小さくてすみます。
  
  +
install-ghc: false
   
  +
# Allow Stack to pick the system GHC (false by default).
−
=== Cabal で静的にリンクしたパッケージをビルド (共有ライブラリを使用しない) ===
  
  +
system-ghc: true
   
  +
# Allow to use, say, Stackage snapshot for GHC 8.8.2 with system GHC 8.8.3.
−
このセクションでは公式の {{Pkg|cabal-install}} パッケージの代わりに [https://hackage.haskell.org/package/cabal-install Hackage] から {{ic|cabal-install}} をインストールする方法を説明します。動的リンクが必要な公式の {{Pkg|cabal-install}} と異なり、Hackage の {{ic|cabal-install}} は [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/shared_libs.html 共有ライブラリ] を使用せずに Haskell パッケージをビルドします。
  
  +
compiler-check: newer-minor
   
  +
# Add the -dynamic flag to every invocation of GHC.
−
原則的に {{ic|cabal-install}} では Haskell のコードをリンクする時に静的・動的どちらの方法も選択できます。Arch では基本的な Haskell ライブラリ ({{ic|haskell-*}} パッケージ) が共有オブジェクト ({{ic|.so}} ファイル) として用意されており Cabal でグローバルにライブラリが登録されるため、静的リンクで同じライブラリを使用すると問題が起こります。リンクの [https://bugs.archlinux.org/task/54563#comment158826 エラー] を避けるために、同じ環境に静的・動的な Haskell パッケージを混在させてはいけません。どちらかのパッケージがグローバルに登録されている場合 ({{ic|ghc-pkg list}} コマンドで確認できます)、Cabal は必要なパッケージを取得しません (必要なパッケージのリンクの種別は関係ありません)。
  
  +
ghc-options:
−  
  +
"$everything": -dynamic
−
そのため、インストールする Haskell 関連のパッケージはコンパイルの {{Pkg|ghc}} と静的ブートライブラリの {{Pkg|ghc-static}} だけに限ります ({{Pkg|stack}}, {{Pkg|cabal-helper}}{{Broken package link|パッケージが存在しません}}, {{Pkg|cabal-install}}, 公式リポジトリに存在する {{ic|haskell-*}} 動的ライブラリ [https://www.archlinux.jp/packages/?q=haskell-] はインストールしません)。
  
  +
}}
−  
−
Haskell パッケージのビルドツールとして [https://www.haskellstack.org/ Stack] を使うこともできます。Stack はデフォルトで静的リンクを使います。Cabal で静的リンクを使ってビルドしたい場合、以下の手順に従うことで Hackage から {{ic|cabal-install}} をインストールできます。ここで [https://haskellstack.org/ Stack] ツールは必要な依存パッケージを取得して {{ic|cabal-install}} をビルドするのに使用します。
  
−  
−
まず {{AUR|stack-bin}} をインストールしてください。Cabal のコンパイルをブートストラップするのに使用します。依存パッケージとして {{ic|haskell-*}} 動的ライブラリを含む公式 Arch リポジトリのパッケージを使うことはしません。
  
−  
−
それから Stack のパッケージインデックスをダウンロードします。Stack は {{ic|cabal-install}} のコンパイルをブートストラップするためだけに使いますが、インストール済みの {{Pkg|ghc}} コンパイルも使用します:
  
−
$ stack setup --system-ghc
  
−  
−
そして {{ic|cabal-install}} をインストール:
  
−
$ stack install --system-ghc cabal-install
  
−  
−
新しくインストールされる {{ic|cabal-install}} は共有ライブラリを使わずにコンパイルされ、パッケージをビルドするときにデフォルトで共有ライブラリを使用しません。また、{{ic|cabal-install}} はインストールされた {{Pkg|ghc}} コンパイラを使用します。
  
−  
−
=== Haskell Platform ===
  
−  
−
Haskell での開発を簡単に始められる、[http://www.haskell.org/platform/ haskell-platform] バンドルは次のように説明されます:
  
−  
−
:''Haskell のプログラミングを始める一番簡単な方法です。立ち上げて動作させるのに必要な全てが入っています。次のように考えて下さい "Haskell: batteries included" (電池付属)。''
  
−  
−
[[公式リポジトリ]]から[https://bbs.archlinux.org/viewtopic.php?pid=1151382#p1151382 以下のパッケージ]を[[インストール]]することで Haskell Platform を置き換えられます:
  
−  
−
* ghc ({{Pkg|ghc}}) — 動的 [https://ghc.haskell.org/trac/ghc/wiki/Commentary/Libraries ブートライブラリ] ({{Pkg|ghc-libs}}) が付属するコンパイラ。静的ブートライブラリ ({{Pkg|ghc-static}}) は別個にインストールが必要です。
  
−
* cabal-install ({{Pkg|cabal-install}}) — Hackage の依存解決とパッケージの取得に焦点が置かれたビルドツール。
  
−
* stack ({{Pkg|stack}}) — Stackage の厳選されたスナップショットとパッケージの取得に焦点が置かれたビルドツール。
  
−
* haddock ({{Pkg|haskell-haddock-api}}{{Broken package link|{{aur-mirror|haskell-haddock-api}}}} と {{Pkg|haskell-haddock-library}}) — ドキュメントを生成するためのツール
  
−
* alex ({{Pkg|alex}}) — 字句解析器ジェネレータ
  
−
* happy ({{Pkg|happy}}) — パーサジェネレータ
  
−  
−
また、[https://docs.haskellstack.org/en/stable/install_and_upgrade/#arch-linux] に従って {{Pkg|stack}} を使って Haskell 環境を管理する方法もあります。
  
   
 
== Haskell パッケージの管理 ==
  
== Haskell パッケージの管理 ==
   
−
Haskell ライブラリや実行可能ファイルの多くはパッケージにまとめられています。どれも [http://hackage.haskell.org Hackage] から利用することが可能です。また、厳選されたパッケージが [https://www.stackage.org Stackage] に存在します。パッケージをインストール・管理する方法は複数存在します:
 +
Haskell のライブラリと実行可能ファイルのほとんどは、Hackage および Stackage から入手できるソースパッケージの単位で配布されます。
−  
−
* 以下のどちらか (共存不可):
  
−
** [[公式リポジトリ]]
  
−
** [[ArchHaskell|ArchHaskell リポジトリ]]
  
−
* [[#cabal-install|cabal-install]]
  
−
* [[#stack|stack]]
  
−
* [[Arch User Repository]]
  
   
  +
他のコンパイル言語では一般的なことですが、多くの人気のある Haskell パッケージは、事前構築された形式で公式 Arch リポジトリから入手できます。いくつかの追加パッケージは [[AUR]] からインストールできます。
−
[https://github.com/magthe/cblrepo cblrepo] は Linux ディストリビューションの Haskell パッケージを管理するために使用するツールです。これのラッパーである、{{AUR|cabal2pkgbuild-git}}{{Broken package link|{{aur-mirror|cabal2pkgbuild-git}}}} は Hackage パッケージから PKGBUILD を作成することができます。新しい Haskell パッケージを作成することについては [[Haskell パッケージガイドライン]]に詳しく記載があります。
  
   
  +
GHC、ライブラリ、およびツールをインストールするには [[pacman]] を使用することが推奨されますが、ある時点で、Hackage/Stackage から直接 Haskell パッケージをインストールしたり、ソースから独自の (または他の人の) パッケージをコンパイルしたくなるかもしれません。これを行うには、Cabal または Stack が必要になります。
−
=== 方法ごとのプラス面とマイナス面 ===
  
   
−
以下の表はそれぞれのパッケージ管理方法のメリットとデメリットのまとめです。
 +
次の表は、さまざまなパッケージ管理スタイルの長所と短所をまとめたものです。
   
 
{| class="wikitable"
  
{| class="wikitable"
124行目: 124行目:
 
|-
  
|-
 
| [[公式リポジトリ]] || ArchLinux 開発者が運営、パッケージのバージョンの整合性に問題なし、コンパイル済み || 利用できるパッケージの数が限られる、動的ライブラリのみ
  
| [[公式リポジトリ]] || ArchLinux 開発者が運営、パッケージのバージョンの整合性に問題なし、コンパイル済み || 利用できるパッケージの数が限られる、動的ライブラリのみ
−
|-
  
−
| [[#ArchHaskell リポジトリ|ArchHaskell リポジトリ]] || ArchHaskell グループが運営、パッケージのバージョンの整合性に問題なし、コンパイル済み || 使用するのに手動で設定が必要
  
 
|-
  
|-
 
| [[#cabal-install|cabal-install]] || 全てのパッケージが利用可能、root 権限が不要 || インストール先がホームフォルダ、{{Pkg|cabal-install}} [https://ivanmiljenovic.wordpress.com/2010/03/15/repeat-after-me-cabal-is-not-a-package-manager はパッケージマネージャではない]、パッケージのバージョンの整合性に問題がある可能性 (別名 [http://www.haskell.org/haskellwiki/Cabal/Survival#What_is_the_difficulty_caused_by_Cabal-install.3F cabal hell])
  
| [[#cabal-install|cabal-install]] || 全てのパッケージが利用可能、root 権限が不要 || インストール先がホームフォルダ、{{Pkg|cabal-install}} [https://ivanmiljenovic.wordpress.com/2010/03/15/repeat-after-me-cabal-is-not-a-package-manager はパッケージマネージャではない]、パッケージのバージョンの整合性に問題がある可能性 (別名 [http://www.haskell.org/haskellwiki/Cabal/Survival#What_is_the_difficulty_caused_by_Cabal-install.3F cabal hell])
135行目: 133行目:
 
|}
  
|}
   
−
=== ArchHaskell リポジトリ ===
 +
=== cabal ===
   
  +
{{Note|Haskell では、''cabal'' という用語は次のいずれかを指します。:
−
詳細は [[ArchHaskell]] を見て下さい。
  
  +
* Haskell パッケージとその依存関係を記述する Cabal ファイルフォーマット;
  +
* Cabal ファイルフォーマットで動作する Cabal ライブラリ;
  +
* Haskell パッケージをビルドするために Cabal ライブラリを使用する {{ic|cabal}} コマンドラインツール ({{Pkg|cabal-install}} パッケージで提供されます)
  +
この記事の文脈では、''Cabal'' は通常、特に指定がない限り {{ic|cabal}} コマンドラインツールを意味します。}}
   
  +
Cabal は Haskell の "オリジナル" のビルドシステムです。Hackage で見つかるライブラリやツールのほとんどは、Cabal 経由でインストールできます。
−
=== cabal-install ===
  
   
  +
==== パッケージのインストール ====
−
[[公式リポジトリ]]から {{Pkg|cabal-install}} をインストールしてください。
  
   
  +
Cabal によってインストールされたユーザー全体の実行可能ファイルを実行するには、{{ic|~/.cabal/bin}} を {{ic|$PATH}} [[環境変数]] に追加する必要があります。
−
{{Note|{{ic|cabal-install}} パッケージには "cabal" コマンドラインユーティリティが含まれています。一方、{{ic|Cabal}} は "Cabal" ライブラリを提供するパッケージであり、cabal-install と stack の両方が使用します。}}
  
   
  +
PATH="$HOME/.cabal/bin:$PATH"
−
==== 準備 ====
  
   
  +
次のコマンドを実行して、Hackage パッケージとそのすべての依存関係を 1 つのステップでインストールします。
−
パスを指定しないでインストールした実行可能ファイルを実行するには、cabal のバイナリフォルダ {{ic|~/.cabal/bin}} を {{ic|$PATH}} 変数に追加する必要があります。シェルの設定ファイルに以下の行を記述することで追加できます ({{Pkg|bash}} の場合 {{ic|~/.bashrc}}、{{Pkg|zsh}} の場合 {{ic|~/.zshrc}}):
  
  +
−
{{bc|PATH=$PATH:~/.cabal/bin}}
  
  +
$ cabal install --ghc-options=-dynamic ''package''
−
cabal sandbox の中で実行したい場合:
  
  +
−
PATH=$PATH:.cabal-sandbox/bin
  
  +
{{Note|2020年10月現在、Cabal は {{ic|~/.cabal/config}} の {{ic|ghc-options}} を無視し、{{ic|build-type: Custom}} を使ってパッケージをビルドしている間、{{ic|~/.cabal/config}} の {{ic|ghc-options}} を無視します。そのため、コマンドラインで {{ic|1=--ghc-options=-dynamic}} フラグを指定する必要があります。そうしないと {{ic|setup.hs}} で {{ic|Could not find module 'Prelude' There are files missing in the 'base-...' package}} のようなビルドエラーが発生するかもしれません。}}
  +
  +
Haskell パッケージをソースからビルドしてインストールすることもできます。これを行うには、パッケージディレクトリから次のコマンドを実行します。
  +
  +
$ cabal install --ghc-options=-dynamic
  +
  +
各 Cabal パッケージは、[https://pvp.haskell.org パッケージ バージョン管理ポリシー] (PVP) に従って、依存関係のリストとそのバージョン制約を {{ic|.cabal}} ファイルに指定する必要があります。パッケージのインストール中に、Cabal はすべての制約を満たす一連の依存関係を見つけようとします。このプロセスは ''依存関係の解決'' と呼ばれます。
  +
  +
スタックが存在するのには理由があります。cabal は初心者との間に多くの軋轢を生むことで知られています。ほとんどの場合、依存関係の解決はうまく機能しますが、失敗する場合もあります。この場合、問題の原因を突き止め、問題のある依存関係を解決する方法について Cabal にヒントを与える必要があります。たとえば、場合によっては、Cabal がパッケージの PVP によって規定された依存関係の上限を無視できるようにするために、{{ic|1=cabal install --allow-newer --ghc-options=-dynamic ''package''}} と言う必要があります。バージョンを変更し、パッケージ作成者が許可したものよりも新しい依存関係を持つパッケージを効果的にインストールします。 あまり適切に管理されていないパッケージの場合は、さらに面倒になります。別の例については、Idris (Haskell で書かれた別のプログラミング言語) のインストールに関する [https://groups.google.com/d/msg/idris-lang/h2uWYmqHcc0/5k0jNmQ3BAAJ このスレッド] を参照してください。{{ic|--allow-newer}} および {{ic|1=--constraint='haskeline < 0.8.0.0'}} コマンドラインフラグを使用してコンパイルを成功させます。
  +
  +
==== パッケージの削除 ====
  +
  +
簡単な方法はありません。 Cabal はこの機能をサポートしていませんが、[https://github.com/phadej/cabal-extras#cabal-store-gc cabal-store-gc] のような外部ツールがあります。
  +
  +
ユーザー全体の Haskell パッケージ システム全体を再インストールするには、{{ic|~/.cabal}} と {{ic|~/.ghc}} を削除して、最初から始めます。これは、GHC をアップグレードするときに必要になることがよくあります。
  +
  +
より正確に行うには、{{ic|ghc-pkg unregister ''package''}} または {{ic|ghc-pkg hide ''package''}}/{{ic|ghc-pkg expose ''package''}} を [https://downloads.haskell.org/ghc/8.10.2/docs/html/users_guide/packages.html#package-databases user package database] 上で直接使うことができます。しかし、どちらもファイルを削除しません。
  +
  +
=== Stack ===
  +
  +
Stack は、Haskell パッケージを管理するためのもう 1 つのツールです。それは cabal とは少し異なる目標を持ち、少し異なる哲学を持っています。これは内部で Cabal ライブラリを使用し、Hackage と統合します。ただし、スナップショットが厳選され、連携して適切に動作するパッケージが含まれることを約束して、独自のパッケージ (スナップショット) リポジトリを Stackage 上に維持します。
   
 
==== パッケージのインストール ====
  
==== パッケージのインストール ====
  +
  +
デフォルトの設定では、Stack はコンパイル済みの実行ファイルを {{ic|~/.local/bin}} にインストールします。このディレクトリをシェル設定ファイルの {{ic|$PATH}} 環境変数に追加してください。例えば {{Pkg|bash}} なら {{ic|~/.bashrc}}、{{Pkg|zsh}} なら {{ic|~/.zshrc}} です:
  +
  +
export PATH="$HOME/.local/bin:$PATH"
  +
  +
次のコマンドを実行して、Stackage パッケージをダウンロード、ビルド、インストールします。
  +
  +
stack install ''package''
  +
  +
{{Note|2020 年 10 月現在 Stackは、[https://github.com/commercialhaskell/stack/issues/3409 ignores] {{ic|~/.stack/config.yaml}} から {{ic|ghc-options}} を {{ic|Setup.hs}} ビルド時に無視します。もし {{ic|Setup.hs}} で {{ic|Could not find module 'Prelude' There are files missing in the 'base-...' package}} のようなビルドエラーが発生したら、{{Pkg|ghc-static}} パッケージをインストールしてみてください。}}
  +
  +
パッケージディレクトリから次のコマンドを実行して、ソースから Haskell パッケージをビルドしてインストールすることもできます。
  +
  +
stack install --resolver ''resolver''
  +
  +
{{ic|stack setup}} コマンドで使用したものと同じリゾルバーを指定する必要があることに注意してください。
  +
  +
==== パッケージの削除 ====
  +
  +
スタックは "アンインストール" 操作をサポートしていません。
  +
  +
ユーザー全体の Haskell パッケージシステム全体を再インストールする場合は、{{ic|~/.stack}} ディレクトリを削除して、最初から始めてください。これは、GHC をアップグレードするときに必要になることがよくあります。
  +
  +
== 開発ツール ==
  +
  +
=== ツール ===
  +
  +
==== haskell-language-server ====
  +
  +
[https://github.com/haskell/haskell-language-server haskell-language-server] は、Haskell の [https://microsoft.github.io/language-server-protocol 言語サーバープロトコル] (LSP) 実装です。これは、コード補完、"定義に移動"、ホバーに関するドキュメント、リンティング、書式設定、または LSP と統合されたエディターのリファクタリングなどの IDE のような機能を提供します。
  +
  +
[[pacman]] から動的にリンクされた Haskell パッケージを使用している場合は、{{Pkg|haskell- language-server}} をインストールします。それ以外の場合、静的リンクを希望する場合は、{{AUR|haskell-langage-server-static}} をインストールしてください。このパッケージには、サポートされている GHC バージョンごとに静的にリンクされたバイナリが含まれています。あるいは、haskell-language-server は [[Haskell#ghcup|ghcup]] 経由、または [[Haskell#Visual Studio Code|Visual Studio Code]] の [https://marketplace.visualstudio.com/items?itemName=haskell.haskell Haskell 拡張機能] によってインストールできます。
  +
  +
haskell-language-serverは、プロジェクトを開いたときに自動的にビルド構成を決定しようとします。自動判別に失敗した場合は、プロジェクトのルートディレクトリにある {{ic|hie.yaml}} ファイルを使って [https://haskell-language-server.readthedocs.io/en/latest/configuration.html#configuring-your-project-build 手動で設定する] とよいでしょう。
  +
  +
==== ghcid ====
  +
  +
[https://github.com/ndmitchell/ghcid ghcid] は、Haskell 開発用の [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/ghci.html GHCi] ベースのツールです。は、ソースコードの変更ごとにコンパイラエラーと警告を表示するシンプルかつ堅牢な方法を提供します。{{AUR|ghcid}} パッケージ経由でインストールできます。
  +
  +
==== hoogle ====
  +
  +
[https://github.com/ndmitchell/hoogle hoogle] を使用すると、関数名またはおおよその型シグネチャによって Haskell ライブラリを検索できます。{{Pkg|hoogle}} パッケージ経由でインストールできます。
  +
  +
hoogle のオンライン版は https://hoogle.haskell.org で入手できます。
  +
  +
=== リンター ===
  +
  +
==== hlint ====
  +
  +
[https://github.com/ndmitchell/hlint hlint] は、代替関数の使用、コードの簡素化、冗長性の特定など、Haskell コードの改善の可能性を示唆しています。これは、{{Pkg|hlint}} パッケージを通じて入手できます。
  +
  +
==== stan ====
  +
  +
[https://github.com/kowainik/stan stan] は、[[Haskell#hlint|hlint]] を補完する Haskell 静的アナライザーです。2021 年 6 月現在はベータ段階です。
  +
  +
==== weeder ====
  +
  +
[https://github.com/ocharles/weeder weeder] はプログラム全体のデッドコード解析を行うアプリケーションです。
  +
  +
=== フォーマッタ ===
  +
  +
* {{App|brittany|Haskell ソースコードフォーマッタ|https://github.com/lspitzner/brittany|{{Pkg|haskell-brittany}}}}
  +
* {{App|Floskell|柔軟性と設定可能性に焦点を当てた hindent のフォーク|https://github.com/ennocramer/floskell|{{Pkg|haskell-floskell}}}}
  +
* {{App|fourmolu|様々な書式パラメータを設定する機能を追加した Ormolu のフォーク|https://github.com/parsonsmatt/fourmolu|{{Pkg|haskell-fourmolu}}}}
  +
* {{App|hindent|拡張可能な Haskell プリンター|https://github.com/mihaimaruseac/hindent|{{Pkg|hindent}}}}
  +
* {{App|Ormolu|Haskell ソースコード用のフォーマッタで、設定を必要としない "真の" 書式スタイルを実装しています。|https://github.com/tweag/ormolu|{{Pkg|haskell-ormolu}}}}
  +
* {{App|stylish-haskell|シンプルな Haskell コードの整形ツール。|https://github.com/jaspervdj/stylish-haskell|{{Pkg|stylish-haskell}}}}
  +
  +
=== エディタ ===
  +
  +
==== Visual Studio Code ====
  +
  +
[[Visual Studio Code]] には、[[Haskell#haskell-language-server|haskell-language-server]] を利用した [https://marketplace.visualstudio.com/items?itemName=haskell.haskell Haskell 拡張機能] があります。haskell-language-server がインストールされていない場合は、Haskell 拡張機能が静的にリンクされた Linux バイナリを自動的にダウンロードしてインストールします。
  +
  +
==== IntelliJ IDEA ====
  +
  +
[https://www.jetbrains.com/idea IntelliJ IDEA] Haskell のサポートは、[https://plugins.jetbrains.com/plugin/8258-intellij-haskell Haskell プラグイン] によって提供されます。 {{Pkg|intellij-idea-community-edition}} を含む IntelliJ IDEA のどのエディションでも動作します。
  +
  +
新しいプロジェクトを作成するか、既存のプロジェクトを IntelliJ IDEA にインポートするには、Stack をインストールする必要があります。2021 年 6 月現在、Cabal のみのプロジェクト [https://github.com/rikvdkleij/intellij-haskell/issues/625 はサポートされていません]
  +
  +
==== Vim ====
  +
  +
[[Vim]] の基本的な設定のハイライトとインデントは、[https://github.com/neovimhaskell/haskell-vim haskell-vim] プラグインを介して取得できます。IDE のようなエクスペリエンスを向上させるには、[https://vimawesome.com/?q=LSP LSP client] プラグイン (例:[https://github.com/neoclide/coc.nvim coc.nvim]、[https://github.com/dense-analysis/ale ALE]、[https://github.com/autozimu/LanguageClient-neovim LanguageClient-neovim]) と [[Haskell#haskell-language-server|haskell- language-server]]
  +
  +
==== Emacs ====
  +
  +
Haskell の基本的な [[Emacs]] サポートは、公式 [https://github.com/haskell/haskell-mode haskell-mode] によって提供されます。より高度な機能については、[https://github.com/emacs-lsp/lsp-haskell lsp-haskell] を [[Haskell#haskell-langage-server|haskell-language-server]] とともに使用してください。
  +
  +
== 代替インストール ==
  +
  +
{{Note|このセクションでは、公式リポジトリのパッケージを使用せずに、Haskell を Arch にインストールする別の方法について説明します。以前に GHC、Cabal、Stack、またはその他の Haskell パッケージをインストールした場合は、必ず最初にそれらをアンインストールしてください。{{ic|~/.cabal}} ディレクトリと {{ic|~/.stack}} ディレクトリが存在する場合は削除します。}}
  +
  +
汎用 Linux ディストリビューションに Haskell をインストールするには、[https://ghcup.readthedocs.io/en/latest ghcup] と [https://www.haskellstack.org Stack] という 2 つの公式に推奨される方法があります。どちらの方法でも、静的にリンクされた GHC、ツール、ライブラリがホーム ディレクトリにインストールされます。
  +
  +
公式リポジトリの Haskell パッケージの代わりに ghcup または Stack を使用する利点は、複数のバージョンの GHC を並べてインストールして管理できることです。この方法でインストールされた Cabal と Stack は通常、追加の設定を行わずにすぐに動作するため、初心者にとっては簡単かもしれません。
  +
  +
Haskell をインストールするまったく異なる方法は、[[Nix]] パッケージ マネージャーです。Nix は学習曲線がより急峻ですが、Haskell パッケージと非 Haskell パッケージの両方を信頼性が高く再現可能な方法で管理する上でより高い柔軟性を提供します。
  +
  +
=== ghcup ===
  +
  +
ghcup は、GHC の複数のバージョンを簡単にインストールし、それらを切り替えることができるコマンドラインツールです。これは、[https://github.com/rust-lang/rustuprusup]、[https://github.com/pyenv/pyenv pyenv]、および [https://www.jenv.be jenv] とスコープが似ています。
  +
  +
{{AUR|ghcup-hs-bin}} パッケージをインストールしてください。あるいは、公式の [https://www.haskell.org/ghcup インストール手順] に従うか、手動で [https://downloads.haskell.org/~ghcup ghcup バイナリ] をダウンロードして {{ic|$PATH}} のどこかに置いてください。
  +
  +
デフォルトでは、ghcup は GHC 実行ファイルを {{ic|~/.ghcup/bin}} にインストールします。このディレクトリをシェル設定ファイルの {{ic|$PATH}} 環境変数に追加する必要があります。例えば {{Pkg|bash}} なら {{ic|~/.bashrc}}、{{Pkg|zsh}} なら {{ic|~/.zshrc}} です。Cabal によってインストールされた実行可能ファイルを実行したい場合は、{{ic|~/.cabal/bin}} も {{ic|$PATH}} に追加してください:
  +
  +
export PATH="$HOME/.cabal/bin:$HOME/.ghcup/bin:$PATH"
  +
  +
{{Tip|XDG スタイルのディレクトリを使用する場合は、{{ic|GHCUP_USE_XDG_DIRS}} 環境変数 (https://ghcup.readthedocs.io/en/latest/guide/#xdg-support) を定義します。}}
  +
  +
ghcup は、その機能のほとんどをサポートする便利な TUI を提供します。
  +
  +
$ ghcup tui
  +
  +
あるいは、次の CLI コマンドを使用することもできます。
  +
  +
GHC と Cabal の利用可能なバージョンをリストします。
  +
  +
$ ghcup list
  +
  +
推奨バージョンの GHC をインストールします。
  +
  +
$ ghcup install ghc
  +
  +
たとえば、GHC の特定のバージョンをインストールすることもできます。
  +
  +
$ ghcup install ghc 8.10.2
  +
  +
上記のコマンドでは、GHC が {{ic|$PATH}} で自動的に利用可能になるわけではありません。デフォルトで使用する GHC バージョンを選択する必要があります。
  +
  +
$ ghcup set ghc 8.10.2
  +
  +
Cabal の推奨バージョンをインストールします。
  +
  +
$ ghcup install cabal
  +
  +
Cabal を使用して、特別な設定やコマンドラインフラグを必要とせずに、静的にリンクされた Haskell 実行可能ファイルをビルドおよびインストールできるようになりました。
  +
 
{{bc|
  
{{bc|
−
1=$ cabal update
 +
$ cabal update
  +
$ cabal install ''executable''
  +
}}
   
  +
新しい Cabal プロジェクトを開始するには:
−
$ # Dynamic linking
  
  +
{{hc|
−
$ cabal install --disable-library-vanilla --enable-shared --enable-executable-dynamic ''<pkg>''
  
  +
$ cd /path/to/my-project
  +
$ cabal init
  +
$ cabal build
  +
$ cabal run|
  +
Up to date
  +
Hello, Haskell!
  +
}}
  +
  +
[[Haskell#haskell-language-server|haskell-language-server]] をインストールするには、次のコマンドを使用します。
  +
  +
$ ghcup install hls
  +
  +
詳細については、公式 [https://ghcup.readthedocs.io/en/latest/guide ghcup] および [https://cabal.readthedocs.io/en/latest Cabal] ドキュメントを参照してください。
  +
  +
=== Stack ===
  +
  +
{{AUR|stack-static}} パッケージをインストールします。あるいは、公式の [https://docs.haskellstack.org/en/stable/install_and_upgrade インストール手順] に従うか、[https://github.com/commercialhaskell/stack/releases スタックバイナリ] を手動でダウンロードして、それをあなたの {{ic|$PATH}} に配置することもできます。
  +
  +
スタックによってインストールされた実行可能ファイルを実行したい場合は、シェル設定ファイルの {{ic|$PATH}} 環境変数に {{ic|~/.local/bin}} ディレクトリを追加します (例:{{ic|~/) {{Pkg|bash}} の場合は、{ic|~/.bashrc}} {{Pkg|zsh}} の場合は {{ic|~/.zshrc}}:
  +
  +
export PATH="$HOME/.local/bin:$PATH"
  +
  +
{{ic|stack setup}} を実行して、最新のスタック LTS スナップショットから GHC を自動的にインストールします。
  +
  +
$ stack setup
  +
  +
特別な設定やコマンドラインフラグを必要とせずに、Stack を使用して静的にリンクされた Haskell パッケージを構築およびインストールできるようになりました。
  +
  +
$ stack install ''package''
  +
  +
詳細については、公式 [https://docs.haskellstack.org/en/stable Stack ドキュメント] を参照してください。
  +
  +
=== Nix ===
  +
  +
{{Expansion|I cannot offer a good enough overview, due to no experience with it}}
  +
  +
== ヒントとテクニック ==
  +
  +
=== 静的リンク ===
   
  +
{{Note|
−
$ # Static linking (requires ghc-static and ghc-pristine)
  
  +
* このセクションでは、静的にリンクされた Haskell パッケージを Arch 上でビルドしながら、公式リポジトリからインストールされた GHC を使用する方法について説明します。続行する前に、{{ic|~/.cabal}} ディレクトリと {{ic|~/.stack}} ディレクトリが存在する場合は必ず削除してください。
−
$ cabal install --with-compiler=/usr/share/ghc-pristine/bin/ghc ''<pkg>''
  
  +
* この記事の文脈において、静的リンクは完全に静的な ELF バイナリを生成することを意味するものではありません。Haskell コードのみが単一の ELF バイナリに静的にリンクされ、それは {{Pkg|glibc}} などの他のシステムライブラリに動的にリンクされる場合があります。
 
}}
  
}}
   
−
{{ic|-j}} を追加することで並列コンパイルができます。また、{{ic|--global}} フラグを使うことでシステム全体にパッケージをインストールすることもできますが、これは非推奨です。ユーザーごとのインストールでは、全てのファイルは {{ic|~/.cabal}} に配置されライブラリは {{ic|~/.ghc}} に登録されるので、フォルダを削除することで簡単にクリーンアップすることができます。システム全体にインストールすると、ファイルがファイルシステムに散らばってしまい管理するのが難しくなります。
 +
静的リンクを使用するには、少なくとも、{{Pkg|ghc-static}} パッケージを通じて静的ブートライブラリをインストールする必要があります。これにより、ブートライブラリだけでなく、公式リポジトリから {{ic|haskell-*}} パッケージを通じてインストールされない他のライブラリにもっぱら依存するプロジェクトをビルドできるようになります。
   
  +
残念ながら、プロジェクトがインストールした動的にリンクされた {{ic|haskell-*}} パッケージのいずれかに依存している場合、Cabal は依存関係の解決時に静的ライブラリの不在を考慮しません。その結果、既存の {{ic|haskell-*}} パッケージを使用しようとし、静的ライブラリを検出すると [https://bugs.archlinux.org/task/54563#comment158808 linker errors] で失敗します。:
−
==== サンドボックス ====
  
   
  +
Could not find module ‘''SomePackage.SomeModule''’
−
Cabal のサンドボックスは矛盾のないローカルパッケージデータベースと環境を提供します (Python における virtual-env あるいは Ruby における rvm に似ています)。カレントディレクトリにサンドボックスを作成するには:
  
  +
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.
   
  +
{{ic|ghc-static}}とは異なり、連携可能な "{{ic|haskell-*-static}}" パッケージはありません。ただし、以下の各セクションで説明するように、この問題を回避する他の方法もあります。
−
$ cabal sandbox init
  
   
  +
==== 静的グローバルパッケージデータベース ====
−
削除するには:
  
   
  +
直接的な [https://www.reddit.com/r/linux/comments/9emwtu/arch_linux_ama/efjnyd6/ アプローチ] は、公式の {{Pkg|ghc-static}} パッケージによって提供されており、代替の "静的" パッケージが公開されています。グローバルパッケージデータベース({{ic|/usr/lib/ghc-''version''/static-package.conf.d}})静的データベースは、静的にリンク可能なブートパッケージのみに制限されているため、デフォルトデータベースの代わりに静的データベースを使用するように Cabal が再構成されている場合、動的専用の {{ic|haskell-*}} パッケージがリンクされていないかのように動作します。
−
$ cabal sandbox delete
  
   
  +
静的データベースの正確なパスは、次のようなコマンドを使用して構築時に決定できます。
−
カレントディレクトリにサンドボックスが存在する場合、デフォルトで cabal はその環境を使用します。[[#パッケージのインストール]]と同じ手順でインストールができます。別のサンドボックスを使いたい場合、{{ic|cabal exec "$SHELL"}} を実行してサンドボックスのシェルを起動します。そこからディレクトリを移動しても cabal は指定されたサンドボックスを使用します。また、cabal に {{ic|1=--sandbox-config-file=''/somewhere''/cabal.sandbox.config}} フラグを渡して使うことも可能です。
  
   
  +
{{hc|
−
cabal のサンドボックスの中で実行ファイルを実行するには、{{bc|PATH&#61;$PATH:$PWD/.cabal-sandbox/bin}} を設定するか、{{ic|cabal exec "$SHELL"}} でローカルシェルを起動する必要があります。
  
  +
$ ghc --print-global-package-db {{!}} sed 's/\(package\.conf\.d\)$/static-\1/'|
  +
/usr/lib/ghc-''version''/static-package.conf.d
  +
}}
   
  +
静的データベースを使用できるようにする方法は次のとおりです。
−
==== パッケージの削除 ====
  
  +
−
パッケージの削除を簡単に行う方法はありません。Cabal には削除機能がありません。
  
  +
* 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 ====
  +
  +
{{AUR|ghc-pristine}} パッケージをインストールします。このパッケージは既存の GHC インストールをラップして、ブートライブラリのみを含むパッケージデータベースを備えた別の GHC ディストリビューションを {{ic|/usr/share/ghc-pristine}} に作成します。これにより、動的にリンクされた {{ic|haskell-*}} パッケージを使用せずに半分離環境が効果的に作成されますが、それでも公式リポジトリの GHC コンパイラーが利用されます。次に、静的リンクを使用してソフトウェアを構築するには、ラップされたコンパイラー {{ic|/usr/share/ghc-pristine/bin/ghc}} を呼び出すだけです。Cabal の場合、これは {{ic|~/.cabal/config}} の次の構成に相当します。
  +
  +
{{hc|~/.cabal/config|
  +
with-compiler: /usr/share/ghc-pristine/bin/ghc
  +
}}
  +
  +
プロジェクトディレクトリから次のコマンドを実行して、プロジェクトごとにコンパイラへのパスを指定することもできます。
  +
  +
$ cabal configure --with-compiler=/usr/share/ghc-pristine/bin/ghc
  +
  +
==== cabal-static ====
  +
  +
Arch で静的リンクを取り戻すもう 1 つの方法は、{{AUR|cabal-static}} パッケージをインストールすることです。公式の {{Pkg|cabal-install}} とは異なり、これは動的にリンクされた {{ic|haskell-*}} の依存関係を公式リポジトリから取得せず、同じシステムにインストールされた静的 Haskell ライブラリと共有 Haskell ライブラリの混合を回避します。その後、次の制限付きで通常どおり Cabal を使用できます: インストールした他の Haskell パッケージが {{Pkg|ghc}}、{{Pkg|ghc-libs}} のみであることを確認する必要があります。および {{Pkg|ghc-static}} ({{Pkg|cabal-install}}、{{Pkg|stack}}、および公式リポジトリで入手可能な {{ic|haskell-*}} パッケージではありません。)
  +
  +
==== stack-static ====
  +
  +
{{AUR|stack-static}} パッケージをインストールします。{{ic|cabal-static}} メソッドと同様に、公式リポジトリからインストールした他の Haskell パッケージが {{Pkg|ghc}}、{{Pkg|ghc-libs}}、および {{Pkg|ghc-static}} のみであることを確認してください。次に、[[Haskell#動的リンク用のスタックの設定|動的リンク用のスタックの設定]] で説明されているように、システム GHC を使用するようにスタックをセットアップします。
  +
  +
$ stack setup --system-ghc --resolver ''resolver''
  +
  +
これらのオプションを永続的にするには、次のスニペットを {{ic|~/.stack/config.yaml}} に貼り付けます。
  +
  +
{{hc|~/.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 ====
−
zsh の自動補完を使うことで haskell パッケージを探し出しやすくなります。
  
   
  +
{{AUR|hpack-static-bin}} は、{{Pkg|haskell-hpack}} の代わりに静的にリンクされた ({{ic|haskell-*}} 依存関係がないことを意味します) を提供します。プリコンパイルされているため、make 依存関係は必要ありません。
−
Haskell のパッケーシステム全体を修正・再インストールしたい場合、{{ic|~/.cabal}} と {{ic|~/.ghc}} を削除してスクラッチからインストールしなおしてください。GHC をアップグレードした場合に必要になります。
  
   
−
=== stack ===
 +
==== ghcup ====
   
  +
[[Haskell#ghcup|ghcup]] は、GHC をシステムパッケージマネージャーの外部でローカルにインストールできるツールです。さらに、複数のバージョンの GHC を並行してサポートします。このツールが提供する GHC を使用すると、システム GHC がまったく使用されないため、静的リンクに関連する問題が完全に回避されます。また、システム GHC とそのブートライブラリのアップグレードによって引き起こされる、ローカルに構築されたライブラリの破損も自然に回避されます。
−
[https://haskellstack.org Stack] は依存関係の解決よりも自動的に精選された、矛盾のないパッケージに焦点を置いたビルドツールです。Stackage スナップショットの中で共存させる限り、バージョンの衝突に気をつかうことなくパッケージを簡単にインストールすることができます。Stack は {{Pkg|stack}}, {{AUR|stack-static}}, {{AUR|stack-bin}} パッケージでインストールできます。後者は静的リンクライブラリを提供し、様々な {{ic|haskell-*}} 依存パッケージを必要としません。詳しくは [https://docs.haskellstack.org/en/stable/install_and_upgrade/#arch-linux § Install/upgrade # Arch Linux] を参照。
  
   
 
== 参照 ==
  
== 参照 ==
   
  +
* [https://www.haskell.org Official website of the Haskell programming language]
−
*[https://estore.ohmsha.co.jp/titles/978427406885P すごいHaskellたのしく学ぼう！] ([http://learnyouahaskell.com/ 英語版])
  
−
*[https://www.oreilly.co.jp/books/9784873114231/ Real World Haskell]
 +
* [https://www.haskell.org/documentation Haskell documentation]
  +
* [https://wiki.haskell.org/Haskell Haskell Wiki]
  +
* [https://downloads.haskell.org/ghc/latest/docs/html/users_guide GHC User Guide]
  +
* [https://cabal.readthedocs.io/en/latest Cabal User Guide]
  +
* [https://docs.haskellstack.org/en/stable Stack User Guide]
  +
* [https://hackage.haskell.org Haskell community's central package archive]
  +
* [https://www.stackage.org Stable source of Haskell packages]
  +
* [https://hoogle.haskell.org Haskell API search engine]
  +
* [http://learnyouahaskell.com Learn You a Haskell for Great Good!]
  +
* [http://book.realworldhaskell.org Real World Haskell]
  +
* [https://en.wikibooks.org/wiki/Haskell Haskell Wikibook]
  +
* [http://dev.stephendiehl.com/hask What I Wish I Knew When Learning Haskell]
  +
* [https://github.com/krispo/awesome-haskell Awesome Haskell: an auxiliary list of awesome Haskell links, frameworks, libraries and software]

2023年8月2日 (水) 18:43時点における最新版

関連記事

Wikipedia から:

Haskell は高階関数や静的多相型付け、定義可能な演算子、例外処理といった多くの言語で採用されている現代的な機能に加え、パターンマッチングやカリー化、リスト内包表記、ガードといった多くの特徴的な機能を持っている。また、遅延評価や再帰的な関数や代数的データ型もサポートしているほか、独自の概念として圏論のアイデアを利用し参照透過性を壊すことなく副作用のある操作 (例えば 代入、入出力、配列など) を実現するモナドを含む。このような機能の組み合わせにより、手続き型プログラミング言語では記述が複雑になるような処理がしばしば簡潔になるばかりではなく、必要に応じて手続き型プログラミングを利用できる。

インストール

ノート: Haskell のインストールにはいくつかの選択肢があり、Arch Linux がサポートしているものもあれば、Haskell が公式にサポートしている Linux ディストリビューションもあります。

ネイティブインストール

Haskell は、Linux 上でネイティブに実行できるマシンコードを生成します。xmonad や pandoc-cli などのバイナリ (コンパイル済み) ソフトウェアを実行するために特別に必要なものは何もありません。一方、AUR パッケージのビルドやソフトウェアの開発には、コンパイラとビルド ツールをインストールする必要があります。

Haskell の最新バージョンをインストールするには、次のパッケージを インストール します。

  1. ghc - Haskell コンパイラ。いくつかの 実装 がありますが、最もよく使われている (現在では 事実上 リファレンスとなっている) のは GHC (Glasgow Haskell Compiler) です。
  2. cabal-install または stack です。- GHC に依存して Haskell ソースをコンパイルするビルドツール。Cabal は依存関係の解決と Hackage (Haskell コミュニティのオープンソースソフトウェアの中央パッケージアーカイブ) からのソースパッケージに焦点を当てた古典的なビルドツールです。Stack は、Stackage (Hackage の安定したサブセットで、互いにうまく動作することが知られているパッケージのキュレーションセット (スナップショット) を提供する) のキュレーションされたスナップショットとソースパッケージに焦点を当てた別のビルドツールです。
ヒント: Cabal と Stack はどちらも安定した成熟したビルドツールです。Haskell 開発者の多くは Cabal を使用していますが、Stack を好む開発者もいます。どのツールを選択すればよいかわからない場合は、両方をインストールして、どちらが最適であるかを確認してください。

設定

バージョン 8.0.2-1 以降、extra に含まれる Arch ghc パッケージと全ての haskell-* パッケージは動的にリンクされるライブラリのみを提供します。そのため、リンクに成功するためには GHC, Cabal, Stack を動的リンクに設定する必要があります。

動的リンクを使用すると、通常、(実行中の複数の Haskell プログラム間でページを共有することにより) ビルドが高速化され、ディスクと RAM の使用量が削減され、GHC 間の混合エラーのトラブルシューティングから解放されます。しかし、これには独自の欠点もあります。それは、ghc、ghc-libs、または org/packages/?q=haskell haskell-* パッケージは、GHC でコンパイルされたライブラリが安定した ABI を提供しないためです。このような壊れたバイナリを実行すると、通常のメッセージ error whileloadingsharedlibraries:libHS...so:cannotopensharedobjectfile:No such file or directory が表示されます。これを修正するには、壊れたツールを再構築して再インストールし、新しいライブラリに再リンクします。

一方、静的リンクは一般に保守が容易で、依存関係を更新するたびにすべてのツールをソースから再構築する必要がありません。これらの理由から、静的リンクは、パッケージシステム外のローカル開発では多くの場合推奨されるオプションです。 静的リンクを希望する場合、詳細については 静的リンク または 代替インストール を参照してください。

ノート: Arch が Haskell パッケージの動的リンクに移行した理由の詳細な説明については、この メンテナーの返答 を参照してください。

GHC を直接呼び出す

正常にリンクするには、-dynamic フラグを GHC に渡す必要があります。次のファイルで試すことができます。 

Main.hs
main = putStrLn "Hello, World"

次のようにコンパイルして実行します。 

$ ghc -dynamic Main.hs
$ ./Main
Hello, World

Cabal を動的リンク用に構成する

まず、次のコマンドを実行して、Hackage からパッケージの最新リストをダウンロードし、グローバル設定ファイル ~/.cabal/config (または、$CABAL_CONFIG が指すファイル) を作成します。 

$ cabal update
ヒント: 定期的に cabal update を実行して、ローカルのパッケージと依存関係のリストを Hackage の最新バージョンと同期することをお勧めします。

Cabal を動的リンク用に設定するには、~/.cabal/config 内の次のオプションのコメントを解除して編集します。 

~/.cabal/config
library-vanilla: False
shared: True
executable-dynamic: True
program-default-options
  ghc-options: -dynamic
  • library-vanilla: False は静的ライブラリの作成を抑制します (プロジェクトにライブラリが含まれている場合)
  • shared: True は共有ライブラリの作成を有効にします(プロジェクトにライブラリが含まれている場合)
  • executable-dynamic: True は実行ファイルにダイナミックリンクを使用します (プロジェクトに実行ファイルが含まれている場合)
  • ghc-options: -dynamic は GHC の全ての呼び出しに -dynamic フラグを追加します (例えば、パッケージが自明でないSetup.hs を持っている場合)

動的リンク用のスタックの設定

stack setup コマンドを使用してスタックを初期化し、グローバル設定ファイル ~/.stack/config.yaml を作成できます。デフォルトでは、スタックは最初の呼び出し時に独自のバージョンの GHC を隔離された場所に自動的にダウンロードします。代わりにスタックにシステム GHC インストールを使用させるには、--system-ghc フラグと --resolver フラグを指定して stack setup を実行します。 

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

システムの GHC と互換性のあるリゾルバーを指定する必要があることに注意してください。それ以外の場合、スタックは --system-ghc フラグを喜んで無視し、GHC の独自のコピーをダウンロードします。システム GHC のバージョンは、ghc --version コマンドを使用して確認できます。 

$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 8.10.2

次に、Stackage Web サイトにアクセスし、システムの GHC バージョンに一致する適切な長期サポート (LTS) または夜間スナップショットを選択します。コマンドラインの --resolver フラグに対して選択したスナップショットを使用します。例:--resolver lts-16.15 または --resolver nightly-2020-09-01

Stackage は通常、新しい GHC リリースより遅れます。システム GHC のスタックスナップショットがまだリリースされていない場合があります。この場合、GHC の以前のマイナーバージョンのスナップショットを選択するか、Haskell インストールを一時的にダウングレードして、新しい GHC リリースのサポートが最終的に Stackage に提供されるまで待つことをお勧めします。

動的リンク用にスタックを構成するには、次のスニペットを ~/.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

# Add the -dynamic flag to every invocation of GHC.
ghc-options:
  "$everything": -dynamic

Haskell パッケージの管理

Haskell のライブラリと実行可能ファイルのほとんどは、Hackage および Stackage から入手できるソースパッケージの単位で配布されます。

他のコンパイル言語では一般的なことですが、多くの人気のある Haskell パッケージは、事前構築された形式で公式 Arch リポジトリから入手できます。いくつかの追加パッケージは AUR からインストールできます。

GHC、ライブラリ、およびツールをインストールするには pacman を使用することが推奨されますが、ある時点で、Hackage/Stackage から直接 Haskell パッケージをインストールしたり、ソースから独自の (または他の人の) パッケージをコンパイルしたくなるかもしれません。これを行うには、Cabal または Stack が必要になります。

次の表は、さまざまなパッケージ管理スタイルの長所と短所をまとめたものです。

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

cabal

ノート: Haskell では、cabal という用語は次のいずれかを指します。:
  • Haskell パッケージとその依存関係を記述する Cabal ファイルフォーマット;
  • Cabal ファイルフォーマットで動作する Cabal ライブラリ;
  • Haskell パッケージをビルドするために Cabal ライブラリを使用する cabal コマンドラインツール (cabal-install パッケージで提供されます)
この記事の文脈では、Cabal は通常、特に指定がない限り cabal コマンドラインツールを意味します。

Cabal は Haskell の "オリジナル" のビルドシステムです。Hackage で見つかるライブラリやツールのほとんどは、Cabal 経由でインストールできます。

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

Cabal によってインストールされたユーザー全体の実行可能ファイルを実行するには、~/.cabal/bin を $PATH 環境変数 に追加する必要があります。 

PATH="$HOME/.cabal/bin:$PATH"

次のコマンドを実行して、Hackage パッケージとそのすべての依存関係を 1 つのステップでインストールします。 

$ cabal install --ghc-options=-dynamic package
ノート: 2020年10月現在、Cabal は ~/.cabal/config の ghc-options を無視し、build-type: Custom を使ってパッケージをビルドしている間、~/.cabal/config の ghc-options を無視します。そのため、コマンドラインで --ghc-options=-dynamic フラグを指定する必要があります。そうしないと setup.hs で Could not find module 'Prelude' There are files missing in the 'base-...' package のようなビルドエラーが発生するかもしれません。

Haskell パッケージをソースからビルドしてインストールすることもできます。これを行うには、パッケージディレクトリから次のコマンドを実行します。 

$ cabal install --ghc-options=-dynamic

各 Cabal パッケージは、パッケージ バージョン管理ポリシー (PVP) に従って、依存関係のリストとそのバージョン制約を .cabal ファイルに指定する必要があります。パッケージのインストール中に、Cabal はすべての制約を満たす一連の依存関係を見つけようとします。このプロセスは 依存関係の解決 と呼ばれます。

スタックが存在するのには理由があります。cabal は初心者との間に多くの軋轢を生むことで知られています。ほとんどの場合、依存関係の解決はうまく機能しますが、失敗する場合もあります。この場合、問題の原因を突き止め、問題のある依存関係を解決する方法について Cabal にヒントを与える必要があります。たとえば、場合によっては、Cabal がパッケージの PVP によって規定された依存関係の上限を無視できるようにするために、cabal install --allow-newer --ghc-options=-dynamic package と言う必要があります。バージョンを変更し、パッケージ作成者が許可したものよりも新しい依存関係を持つパッケージを効果的にインストールします。 あまり適切に管理されていないパッケージの場合は、さらに面倒になります。別の例については、Idris (Haskell で書かれた別のプログラミング言語) のインストールに関する このスレッド を参照してください。--allow-newer および --constraint='haskeline < 0.8.0.0' コマンドラインフラグを使用してコンパイルを成功させます。

パッケージの削除

簡単な方法はありません。 Cabal はこの機能をサポートしていませんが、cabal-store-gc のような外部ツールがあります。

ユーザー全体の Haskell パッケージ システム全体を再インストールするには、~/.cabal と ~/.ghc を削除して、最初から始めます。これは、GHC をアップグレードするときに必要になることがよくあります。

より正確に行うには、ghc-pkg unregister package または ghc-pkg hide package/ghc-pkg expose package を user package database 上で直接使うことができます。しかし、どちらもファイルを削除しません。

Stack

Stack は、Haskell パッケージを管理するためのもう 1 つのツールです。それは cabal とは少し異なる目標を持ち、少し異なる哲学を持っています。これは内部で Cabal ライブラリを使用し、Hackage と統合します。ただし、スナップショットが厳選され、連携して適切に動作するパッケージが含まれることを約束して、独自のパッケージ (スナップショット) リポジトリを Stackage 上に維持します。

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

デフォルトの設定では、Stack はコンパイル済みの実行ファイルを ~/.local/bin にインストールします。このディレクトリをシェル設定ファイルの $PATH 環境変数に追加してください。例えば bash なら ~/.bashrc、zsh なら ~/.zshrc です: 

export PATH="$HOME/.local/bin:$PATH"

次のコマンドを実行して、Stackage パッケージをダウンロード、ビルド、インストールします。 

stack install package
ノート: 2020 年 10 月現在 Stackは、ignores ~/.stack/config.yaml から ghc-options を Setup.hs ビルド時に無視します。もし Setup.hs で Could not find module 'Prelude' There are files missing in the 'base-...' package のようなビルドエラーが発生したら、ghc-static パッケージをインストールしてみてください。

パッケージディレクトリから次のコマンドを実行して、ソースから Haskell パッケージをビルドしてインストールすることもできます。 

stack install --resolver resolver

stack setup コマンドで使用したものと同じリゾルバーを指定する必要があることに注意してください。

パッケージの削除

スタックは "アンインストール" 操作をサポートしていません。

ユーザー全体の Haskell パッケージシステム全体を再インストールする場合は、~/.stack ディレクトリを削除して、最初から始めてください。これは、GHC をアップグレードするときに必要になることがよくあります。

開発ツール

ツール

haskell-language-server

haskell-language-server は、Haskell の 言語サーバープロトコル (LSP) 実装です。これは、コード補完、"定義に移動"、ホバーに関するドキュメント、リンティング、書式設定、または LSP と統合されたエディターのリファクタリングなどの IDE のような機能を提供します。

pacman から動的にリンクされた Haskell パッケージを使用している場合は、haskell- language-server をインストールします。それ以外の場合、静的リンクを希望する場合は、haskell-langage-server-staticAUR をインストールしてください。このパッケージには、サポートされている GHC バージョンごとに静的にリンクされたバイナリが含まれています。あるいは、haskell-language-server は ghcup 経由、または Visual Studio Code の Haskell 拡張機能 によってインストールできます。

haskell-language-serverは、プロジェクトを開いたときに自動的にビルド構成を決定しようとします。自動判別に失敗した場合は、プロジェクトのルートディレクトリにある hie.yaml ファイルを使って 手動で設定する とよいでしょう。

ghcid

ghcid は、Haskell 開発用の GHCi ベースのツールです。は、ソースコードの変更ごとにコンパイラエラーと警告を表示するシンプルかつ堅牢な方法を提供します。ghcidAUR パッケージ経由でインストールできます。

hoogle

hoogle を使用すると、関数名またはおおよその型シグネチャによって Haskell ライブラリを検索できます。hoogle パッケージ経由でインストールできます。

hoogle のオンライン版は https://hoogle.haskell.org で入手できます。

リンター

hlint

hlint は、代替関数の使用、コードの簡素化、冗長性の特定など、Haskell コードの改善の可能性を示唆しています。これは、hlint パッケージを通じて入手できます。

stan

stan は、hlint を補完する Haskell 静的アナライザーです。2021 年 6 月現在はベータ段階です。

weeder

weeder はプログラム全体のデッドコード解析を行うアプリケーションです。

フォーマッタ

  • brittany — Haskell ソースコードフォーマッタ
https://github.com/lspitzner/brittany || haskell-brittany
  • Floskell — 柔軟性と設定可能性に焦点を当てた hindent のフォーク
https://github.com/ennocramer/floskell || haskell-floskell
  • fourmolu — 様々な書式パラメータを設定する機能を追加した Ormolu のフォーク
https://github.com/parsonsmatt/fourmolu || haskell-fourmolu
  • hindent — 拡張可能な Haskell プリンター
https://github.com/mihaimaruseac/hindent || hindent
  • Ormolu — Haskell ソースコード用のフォーマッタで、設定を必要としない "真の" 書式スタイルを実装しています。
https://github.com/tweag/ormolu || haskell-ormolu
  • stylish-haskell — シンプルな Haskell コードの整形ツール。
https://github.com/jaspervdj/stylish-haskell || stylish-haskell

エディタ

Visual Studio Code

Visual Studio Code には、haskell-language-server を利用した Haskell 拡張機能 があります。haskell-language-server がインストールされていない場合は、Haskell 拡張機能が静的にリンクされた Linux バイナリを自動的にダウンロードしてインストールします。

IntelliJ IDEA

IntelliJ IDEA Haskell のサポートは、Haskell プラグイン によって提供されます。 intellij-idea-community-edition を含む IntelliJ IDEA のどのエディションでも動作します。

新しいプロジェクトを作成するか、既存のプロジェクトを IntelliJ IDEA にインポートするには、Stack をインストールする必要があります。2021 年 6 月現在、Cabal のみのプロジェクト はサポートされていません

Vim

Vim の基本的な設定のハイライトとインデントは、haskell-vim プラグインを介して取得できます。IDE のようなエクスペリエンスを向上させるには、LSP client プラグイン (例:coc.nvim、ALE、LanguageClient-neovim) と haskell- language-server

Emacs

Haskell の基本的な Emacs サポートは、公式 haskell-mode によって提供されます。より高度な機能については、lsp-haskell を haskell-language-server とともに使用してください。

代替インストール

ノート: このセクションでは、公式リポジトリのパッケージを使用せずに、Haskell を Arch にインストールする別の方法について説明します。以前に GHC、Cabal、Stack、またはその他の Haskell パッケージをインストールした場合は、必ず最初にそれらをアンインストールしてください。~/.cabal ディレクトリと ~/.stack ディレクトリが存在する場合は削除します。

汎用 Linux ディストリビューションに Haskell をインストールするには、ghcup と Stack という 2 つの公式に推奨される方法があります。どちらの方法でも、静的にリンクされた GHC、ツール、ライブラリがホーム ディレクトリにインストールされます。

公式リポジトリの Haskell パッケージの代わりに ghcup または Stack を使用する利点は、複数のバージョンの GHC を並べてインストールして管理できることです。この方法でインストールされた Cabal と Stack は通常、追加の設定を行わずにすぐに動作するため、初心者にとっては簡単かもしれません。

Haskell をインストールするまったく異なる方法は、Nix パッケージ マネージャーです。Nix は学習曲線がより急峻ですが、Haskell パッケージと非 Haskell パッケージの両方を信頼性が高く再現可能な方法で管理する上でより高い柔軟性を提供します。

ghcup

ghcup は、GHC の複数のバージョンを簡単にインストールし、それらを切り替えることができるコマンドラインツールです。これは、[1]、pyenv、および jenv とスコープが似ています。

ghcup-hs-binAUR パッケージをインストールしてください。あるいは、公式の インストール手順 に従うか、手動で ghcup バイナリ をダウンロードして $PATH のどこかに置いてください。

デフォルトでは、ghcup は GHC 実行ファイルを ~/.ghcup/bin にインストールします。このディレクトリをシェル設定ファイルの $PATH 環境変数に追加する必要があります。例えば bash なら ~/.bashrc、zsh なら ~/.zshrc です。Cabal によってインストールされた実行可能ファイルを実行したい場合は、~/.cabal/bin も $PATH に追加してください: 

export PATH="$HOME/.cabal/bin:$HOME/.ghcup/bin:$PATH"
ヒント: XDG スタイルのディレクトリを使用する場合は、GHCUP_USE_XDG_DIRS 環境変数 (https://ghcup.readthedocs.io/en/latest/guide/#xdg-support) を定義します。

ghcup は、その機能のほとんどをサポートする便利な TUI を提供します。 

$ ghcup tui

あるいは、次の CLI コマンドを使用することもできます。

GHC と Cabal の利用可能なバージョンをリストします。 

$ ghcup list

推奨バージョンの GHC をインストールします。 

$ ghcup install ghc

たとえば、GHC の特定のバージョンをインストールすることもできます。 

$ ghcup install ghc 8.10.2

上記のコマンドでは、GHC が $PATH で自動的に利用可能になるわけではありません。デフォルトで使用する GHC バージョンを選択する必要があります。 

$ ghcup set ghc 8.10.2

Cabal の推奨バージョンをインストールします。 

$ ghcup install cabal

Cabal を使用して、特別な設定やコマンドラインフラグを必要とせずに、静的にリンクされた Haskell 実行可能ファイルをビルドおよびインストールできるようになりました。 

$ cabal update
$ cabal install executable

新しい Cabal プロジェクトを開始するには: 

$ cd /path/to/my-project
$ cabal init
$ cabal build
$ cabal run
Up to date
Hello, Haskell!

haskell-language-server をインストールするには、次のコマンドを使用します。 

$ ghcup install hls

詳細については、公式 ghcup および Cabal ドキュメントを参照してください。

Stack

stack-staticAUR パッケージをインストールします。あるいは、公式の インストール手順 に従うか、スタックバイナリ を手動でダウンロードして、それをあなたの $PATH に配置することもできます。

スタックによってインストールされた実行可能ファイルを実行したい場合は、シェル設定ファイルの $PATH 環境変数に ~/.local/bin ディレクトリを追加します (例:<code~/.bashrc>~/) bash の場合は、{ic zsh の場合は ~/.zshrc: 

export PATH="$HOME/.local/bin:$PATH"

stack setup を実行して、最新のスタック LTS スナップショットから GHC を自動的にインストールします。 

$ stack setup

特別な設定やコマンドラインフラグを必要とせずに、Stack を使用して静的にリンクされた Haskell パッケージを構築およびインストールできるようになりました。 

$ stack install package

詳細については、公式 Stack ドキュメント を参照してください。

Nix

この記事またはセクションは加筆を必要としています。
理由: I cannot offer a good enough overview, due to no experience with it (議論: トーク:Haskell#)

ヒントとテクニック

静的リンク

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

stack-static

stack-staticAUR パッケージをインストールします。cabal-static メソッドと同様に、公式リポジトリからインストールした他の Haskell パッケージが ghc、ghc-libs、および ghc-static のみであることを確認してください。次に、動的リンク用のスタックの設定 で説明されているように、システム 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-binAUR は、haskell-hpack の代わりに静的にリンクされた (haskell-* 依存関係がないことを意味します) を提供します。プリコンパイルされているため、make 依存関係は必要ありません。

ghcup

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

参照

「https://wiki.archlinux.jp/index.php?title=Haskell&oldid=33147」から取得