Haskellに纏わるツールたち
Haskellに纏わるツールたちを3行で説明する
多すぎでは？キレそうmrsekut.icon
ビルドツール
最新の一番わかり易いbuild tool
Haskellでプロジェクトの作成やビルドをする
前からあったが、地獄が生まれるのでStackが誕生した
パッケージ管理をする
とはいえ、最近はcabalもまともになっているらしい
大規模アプリケーションを作るときに使おう
上級者向けらしい
2022年現在deprecated
補足
cabal-installとstackの対応表がある やっていることがかぶっているからmrsekut.icon
名前が紛らわしいが、Stackとcabal-installは、どちらも
ビルドツールは別だが、内部で同じものを使っている箇所がある、という感じ
だからstackでprojectを作ってもcabalの概念が出てくる
Stackとcabal-installの大きな違いは、LTS ResolverであるStackageを使うか否か 前者はコレを使っているため、library同士のversion解決の問題が起こりにくい
table:雑なイメージ
Stack cabal-install
内部で使ってる Cabal Cabal
package管理 package.yaml(hpackで.cabalに変換)または.cabal .cabal
Stackでプロジェクトを作成すれば自動的に付いてくる なくても良いが、勝手に付いてくるし、ちょい便利だし使うか、ぐらいのイメージ
設定ファイル
package管理
Stackを使うとついてくる
package管理をする
だから、直接.cabalに書くなら削除してしまっても問題ない package管理をする
Stackを使うとついてくる
Stackの追加の構成の指定をする
Stackageにないlibaryの使用や、LTSのversion指定などをする インタプリタとコンパイラ
Haskellのコンパイラと言えば基本的にこれを指す。これ一択
Haskell仕様に沿ったコンパイラとインタプリタ
GHCより軽量なインタプリタ
インタプリタのみ
使わなくて良さそう
パッケージアーカイブ
Haskellパッケージの集まり
多数の Cabal パッケージを集めたリポジトリ管理サービス
ただのパッケージ集合なHackageに、依存関係安全性の構造をいれたような感じ
全ての依存関係がおかしくならないように頻繁に更新されている
ほぼこっちを使えばいい
ユースケースや、向き不向きを知りたいんだよmrsekut.icon
利用者に見せたくない振る舞い
デフォルトで使えるやつ？
テストフレームワーク
もともとあったtest-frameworkの後継
ランダムな値を生成してテスト
単体テスト
利用者に見せたい振る舞いを、コメントとしてテストを書く
ドキュメントツール
最も使われているやつっぽい
importのasとかは右側に揃えられる
IDE
Language Server
通称HLS
HLSの前身
2020/8頃に開発終了している
ぐぐると記事がいっぱい出てくるが全部古い
これはなに？
参考
experimentalなpackage manager
Fragment-based code distribution!
HaskellでModule単位で共有するんじゃなくてもっと小さい単位で共有していこうぜというやつ
ここでの「共有」は「Hackageで管理」と同じような文脈で言ってるmrsekut.icon
Nix-based incremental build tool for Haskell projects 既にメンテされてないmrsekut.icon
Predictable Haskell development environments with Cabal and Nix.
2019で止まってるmrsekut.icon
Yet another Haskell build system.
2018で止まってるmrsekut.icon
たぶんいらんやつ
stackage-cli
Stackに一本化された
何するかは知らん
まだ色々読んでいる途中mrsekut.icon
何が違う？
$ cabal install hogehoge
$ stack install doctest
$ stack ghciはなに？
baseパッケージを読み込んでghciを起動
つまりルートが読み込まれるということ？
$ stack ghci --package array
arrayパッケージ追加して起動
$ runhaskell
はなに？
だれのもの？
いみわからんので 年表作ってくれ
table:年表
cabalがいた
2015 stack登場
どのsnapshot を使うかを stack.yaml の resolver の項目で指定とは