2018年にLinuxにHaskell（プラットフォームまたはスタック）をインストールする方法は？
HaskellをMiranLipovačaの本 Learn You a Haskell から学ぼうとしています。本とhaskell.orgは両方とも Haskell Platform のインストールを推奨していますが、私が使用しているManjaro Linux（Archベース）のダウンロードはありません。
私はこれを見つけました ガイド 2014年から、Manjaroのリポジトリからパッケージをインストールすることにしました。 Emacsでhaskell-modeを使用するまで、これはうまくいきました。私はこれをトラブルシューティングし、パッケージ（主にスタック）の問題であることがわかりました。
これを修正する方法を探して、私はこれを見つけました Reddit スレッド。これはHaskell（プラットフォームではない）のインストール方法とパッケージの問題を説明しています。私はコメントの1つに従い、記述されたスクリプトでStack（およびGHC）をインストールすることになりました here ：
wget -qO- https://get.haskellstack.org/ | sh
stack setup
stack update
私の質問はこれに関連しています：
- これは、2018年にLinux（Manjaro）に機能するHaskell（Platform）をインストールするための推奨される最初の方法ですか？そうでない場合：それを行う方法/方法は何ですか？
- Haskellプラットフォームには、GHC、Cabal、Stack、およびいくつかのパッケージが含まれています。 GHCとStackがインストールされていますが、Stackを介してCabalをインストールするにはどうすればよいですか？
- Cabalは必要ですか（スタックは機能が重複しているようです）。
- Haskell Platform のパッケージを見ると、上記のようにStackをインストールすることで何か足りないものがありますか？
$HOME/.stack/programs/x86_64-linux/ghc-tinfo6-nopie-8.2.2/lib/ghc-8.2.2これらの多くはすでにインストールされているようです。
これが（長い）別の答えです。以前は初心者にもStackをお勧めしていましたが、その後、気が変わったことに注意してください。
TL; DR：Haskellプラットフォームまたは純粋なStackインストールのいずれかが必要なすべてを提供でき、選択することで何も「見逃す」ことはありませんどちらか一方。 Stackをスキップして、「Generic」Linuxインストーラーを使用してHaskell Platformをインストールするのが最も簡単でしょう。必要なものがすべて付属しており、セットアップがLYAHブックで説明されている内容により近く一致するからです。複数のプロジェクトでより深刻な開発を行っている場合は、後でStackをインストールできます。純粋なStackインストールを使用する場合は、「グローバルプロジェクトのみ」のワークフローから開始することをお勧めします。どちらの方法でも、「haskell-mode」を使用して、以下に示すいくつかの構成修正を行うことができます（スタックのみのインストールのグローバルプロジェクトで作業している場合に必要なキー設定を含む）。
ここに長い答えがあります...
スタック対プラットフォーム対カバル
LYAHの本はStackに先立って書かれていますが、これは確かにそれが言及されていない主な理由です。 haskell.orgでは、最小インストーラー、Stack、またはHaskellプラットフォームの使用を推奨しています。 2018年には、これら3つの方法はすべて、Haskell環境をセットアップするための完全に合理的な方法です。それらは、開発作業のためにコンパイラーやライブラリーの異なるバージョンを「サンドボックス」に分離する方法と、インストール量初期の両方で異なりますが、オンデマンドでインストールできないそれらの1つ。どちらを選択するかによって、ワークフローにいくつかの違いがあります（以下を参照）。
StackとCabalは、パッケージマネージャーとビルドツールを組み合わせたものです。 （Stackには実際にHaskellインストール全体をbootstrapする追加機能があります。これが、それ自体がインストール方法でもある理由です。）LYAHを使用している間、実際には自分のプロジェクトで「ビルドツール」機能を直接使用する（GHCのビルトインビルド機能は、小さなマルチモジュールプロジェクトをビルドするのに十分です。）追加のライブラリをインストールするために必要なのは、パッケージマネージャー機能だけです。 。
StackとCabalはパッケージを個別に管理するため、Stackを使用している場合、Cabalを直接使用する必要は特にありません。必要に応じてインストールできます（実際、Stackは「スタックソルバー」などの難解な機能のためにCabalを使用し、そのような場合にはインストールする必要があります）。
$ stack install cabal-install
ただし、これにより「cabal」が「$ HOME/.local/bin」に配置されます（これがパスにあることを確認する必要があります）が、実行するにはフープをジャンプする必要があることがわかります。 ：
$ stack exec --no-ghc-package-path cabal -- list
また、Stack環境に関する限り、実際には何の役にも立ちません。
更新：「$ HOME/.local/bin」パスに関する注意。 https://get.haskellstack.org/ のインストールスクリプトは、既存のインストールがない場合、デフォルトでStack自体を/usr/local/bin/stackにインストールするように見えます。ただし、パスに$HOME/.local/binを挿入する警告が表示されるはずです。今後、stack upgradeを使用してStackをアップグレードすると、そこに新しいバージョンのstackがインストールされ、バイナリを含むパッケージをインストールする場合はそのディレクトリも使用されます。たとえば、stack install hlintはHaskell Lintプログラムhlintをそのディレクトリにインストールします。ですから、あなたのパスと/usr/local/binの前のどこかにそれを置くことは良い考えです。
Stackに欠けているもの
これで最初の3つの質問がカバーされると思います。最後に、Haskellプラットフォームの代わりにStackをインストールしたことで欠けている主なものは、設計上、Stackが「スタック」自体以外のグローバルなものを実際にインストールしないことです。そのため、Haskellインタープリター（ "ghci"）またはコンパイラー（ "ghc"）の実行を含むすべてのHaskell作業は、特定の対応するStackコマンドを使用して、すべてStack環境内で実行する必要があります。
$ echo 'main = putStrLn "Hello, world!"' > Hello.hs
$ stack ghc -- Hello.hs
[1 of 1] Compiling Main ( Hello.hs, Hello.o )
Linking Hello ...
$ ./Hello
Hello, world!
$
または、「stack exec」を使用して、適切なStack環境内で汎用プログラムを実行します。たとえば、スタックの下でBashシェルを実行すると便利な場合があります。その後、グローバルにインストールされたHaskellプラットフォーム環境のように動作します。
$ stack exec bash
$ ghci
GHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help
Prelude> :quit
$ ghc -O2 Hello.hs
[1 of 1] Compiling Main ( Hello.hs, Hello.o ) [flags changed]
Linking Hello ...
$ exit
$ ghc
The program 'ghc' is currently not installed. ...
$
もう1つ欠けているのは、Haskellプラットフォームがデフォルトで一般的なライブラリをインストールするのに対し、新しいStack環境はほとんど何も開始しないことです（stack setupを実行する前に、コンパイラさえも）。 LYAHでの作業中に、追加のライブラリを定期的にインストールする必要がある場合があります。たとえば、Input and Outputの章では、乱数を使用した例（モジュールSystem.Random）を実行する必要があります。
$ stack install random
インタプリタを再起動します。
Haskellプラットフォームの使用に関する推奨事項
Stackは少し複雑であり、最初に提供される機能を実際に必要としないため、Haskellプラットフォームは使い始めるときに使いやすいかもしれません。 （ "Generic"インストーラーはディストリビューションで正常に動作するはずです。）すべてがインストールされているので、使用方法はLYAHで説明されている方法により近くなります。 haskell-modeとともに、かなりまともなHaskell環境が必要です。
一般に、StackとHaskell Platformを並行してインストールしても問題はありません（Haskell Platformが実際にincludes Stackであるという事実によって証明されます）。 Stackは、すべてを「$ HOME/.stack」サブディレクトリの下に個別に保持するため、コンパイラやパッケージなどの間で干渉はありません。この設定では、cabalを使用して物事のプラットフォーム側にインストールされたパッケージを管理し、stackを使用してスタック側のパッケージを管理します。
Pure Stackインストールの初心者ワークフロー
純粋なStackのインストールに固執したい場合は、開始時に次のワークフローをお勧めします。
「stack new」または「stack init」で作成されたStackプロジェクトへの参照が表示されます。最初はこれらを避け、スタックの「グローバルプロジェクト」に固執します。これは、「stack.yaml」ファイルがないディレクトリ（直接または親ディレクトリ）で「stack」を実行したときに有効になる暗黙のプロジェクトです。
$ cd
$ stack path --project-root
/u/buhr/.stack/global-project
$
グローバルプロジェクト（つまり、stack.yamlファイルの下ではない場所）で作業している場合、インタープリターとコンパイラーを次のように呼び出すことができます。
$ stack exec ghci
$ stack ghc -- -O2 Hello.hs
また、両方とも、次のようなコマンドを使用してインストールした追加のライブラリ（パッケージ）にアクセスできます。
$ stack install random
更新：stack ghciとstack exec ghciの違いに関する注意。前者は、ローカルプロジェクトのコンテキスト内でGHCiを実行することを目的としています（つまり、stack.yamlファイルの下で作業する）。グローバルにインストールされたパッケージを非表示にし、パッケージから利用可能なモジュールを自動的に作成するために、いくつかの追加フラグを渡します。グローバルプロジェクトで作業する場合、stack ghciが警告を生成することを除いて、実際的な違いはないと思います。どちらを使用する場合でも、:load Whatever.hsを使用して独自のモジュールを明示的にロードする必要があります。 このStackドキュメンテーションページ の違いについて、もう少し情報があります。特に、一番下の違いについて説明しようとしています。
最終的に、Stackプロジェクトを使用するワークフローに切り替えることができます。これには、stack newを使用して新しいStackプロジェクトディレクトリを作成し、stack setupを使用してプライベートコンパイラバージョンをそのディレクトリにインストール/リンクし、プロジェクトのxxx.cabalファイル（および場合によってはstack.yamlファイル）stack installを使用する代わりに、どの追加パッケージが必要かを示します。コードの作成を始めたいだけの場合は、少し複雑です。
また、スタック専用に設計されたEmacsモードであるInteroへの参照が表示される場合があります。 Interoは非常に優れていますが、グローバルプロジェクトでファイルを操作する場合はうまく機能しません。ディレクトリ "〜/ .stack/global-project"でインタープリターを起動する傾向がありますが、これはほとんど役に立ちません。 （Interoを使用していますが、この点で動作が向上するようにパッチを適用しました。）
Haskell-Modeの構成（プラットフォームまたはスタックのいずれか）
代わりに「haskell-mode」に固執し、非グローバルプロジェクトの使用を開始するときにInteroについて検討することをお勧めします。指示に従ってMELPAから「haskell-mode」をインストールすることをお勧めしますが、ドキュメントで提案されているものの代わりに.emacsファイルに以下を追加します。
(require 'haskell)
;; add capability to submit code to interpreter and mark errors
(add-hook 'haskell-mode-hook 'interactive-haskell-mode)
;; add missing keybindings for navigating errors
(define-key interactive-haskell-mode-map (kbd "M-n") 'haskell-goto-next-error)
(define-key interactive-haskell-mode-map (kbd "M-p") 'haskell-goto-prev-error)
(define-key interactive-haskell-mode-map (kbd "C-c M-p")
'haskell-goto-first-error)
;; merge this with your existing custom-set-variables
(custom-set-variables
;; NOTE: include following line to work around haskell-mode
;; bug if using GHC >= 8.2.1.
;; See: https://github.com/haskell/haskell-mode/issues/1553
'(haskell-process-args-stack-ghci
'("--ghci-options=-ferror-spans -fshow-loaded-modules"
"--no-build" "--no-load"))
;; some options suggested in the haskell-mode documentation
'(haskell-process-auto-import-loaded-modules t)
'(haskell-process-log t)
'(haskell-process-suggest-remove-import-lines t)
;; make sure "stack ghci" is used, even in the global project
'(haskell-process-type 'stack-ghci))
「haskell-mode-20171022.26」を使用した純粋なStackインストールでこれをテストしましたが、うまくいくようです。グローバルプロジェクトに新しいHaskellファイルを読み込み、「C-c C-l」を使用してインタラクティブセッションに送信し、「M-n」および「M-p」を使用してソースファイル内の強調表示されたエラーを参照できます。 （エラーはミニバッファーに表示されます。）
代わりにHaskellプラットフォームを使用することにした場合、最後のカスタマイズ行を削除する必要があることを除いて、この「haskell-mode」構成はすべて適用されると思います。 （autoのデフォルトのhaskell-process-typeは適切なものを選択します。）
お役に立てば幸いです！
3つの選択肢があります。
Haskellプラットフォーム
これは可能性ですが、この方法で行くことを選択した場合、やがて発見する多くの理由で一般的な選択ではありません。 StackまたはNixを使用すると、はるかに優れたエクスペリエンスが得られ、muchのサポートが向上します。これら2人がどちらを使用するかは、主に個人的な好みに関するものと思われます。それらは異なる獣ですが、初心者にとって違いはすぐには明らかにならないので、「情報に基づいた決定」ができるという希望はほとんどありません。いずれかを選択して、後で再評価してください。
スタック
これは、Haskellをすぐに使い始めたい人（Nixに詳しくない人）に私が提案することです。期間。個別に何かをインストールする必要はありません。StackがすべてのHaskellを処理します。通常、Stackでcabalを直接使用することはありません。 stack buildはcabalを内部的に使用しますが、心配する必要はありません。 1つ注意すべき点は、Stackはパッケージマネージャーではないということです。これはビルドツールです。通常はinstall何もしません。ただし、必要なすべての依存関係を取得し、~/.stackに他のものとともに格納します。
ニックス
これは私が個人的に使用しているものなので、偏見があるかもしれませんが、これは長期的には全体的に最良のソリューションだと思います。警告は、かなり急な学習曲線があり、開始時に自分の足で撃つ機会が多く与えられることです。
Stackから始めることを強くお勧めしますが、Haskellでの旅が続くようにNixについては心を開いておくことをお勧めします。