haskell-jp / atcoder-lang-updates #7 at 2023-04-06 01:50:59 +0900

GHCについてくるライブラリ群で現環境では使えるが新環境では使えない状態のものがあるので対応しておきたいです

import Data.Binary () -- binary
import Data.Time () -- time
import System.Directory () -- directory
import System.FilePath () -- filepath
import System.Posix () -- unix
import System.Process () -- process
import Text.PrettyPrint () -- pretty

main=pure()

あーそれ，（競プロに関係あるかわかんなくて）入れるか迷ってたんですよね．入れる側に一票入ったので入れることにしましょう！

あと， GHC-bundled library で現環境で使えるけど新環境では使えない，というと ghc-boot, ghc-boot-th, hpc, integer-gmp, terminfo, ghc-prim あたりもそうなはずですね．ここら辺も入れた方がいいでしょうか？

現環境は cabal install --lib を用いているので， GHC-bundled library ( で確認できます)のうち，`cabal-install <= 3.8.1.0` が Distribution.Client.CmdInstall.globalPackages 変数によって明示的に global package とみなしていたものは利用可能だったはずです．

ほかには，現環境では使用できない GHC-bundled package (一度も cabal install --lib を投げたことのない裸の ghc では使えるが，一度でも cabal install --lib を投げてしまうと top-level ghc から不可視になってしまうタイプのGHC-bundled package．`globalPackages` 変数に名前が挙がってないとそうなる)もありますが，そこら辺についてはどうしましょうか．

GHC-bundled packageは入れてしまってもいいんじゃないでしょうか

競プロでの使用例としては
timeは制限時間ギリギリまで乱択するときとか，日付関連の問題でたまに使います。これはないと困ると思う。
processはインタラクティブ系問題のローカルデバッグで使ってました。
Cabal-syntaxはDistribution.Compat.Preludeでimportを減らしたり，ライブラリがあまり入ってない環境でlensとか使えるなみたいなことは考えていました

なるほど． Windows 環境下でないとビルドできない Win32 を除き，
• Cabal
• Cabal-syntax
• binary
• directory
• filepath
• ghc
• ghc-boot
• ghc-boot-th
• ghc-compact
• ghc-heap
• ghc-prim
• ghci
• haskelline
• hpc
• integer-gmp
• libiserv
• pretty
• process
• stm
• terminfo
• time
• unix
• xhtml
を全て追加する，ということですか． ghc-compact をただ追加するのもアレなので，
• compact
を追加してもいいかもしれませんね．

さしあたって気にすべき点は，特に ghc-prim などの ghc* 系が GHC のバージョン間で安定したAPIを提供しそうに見えない，ということでしょうか．

細かい反論としては:
• ghc とか terminfo とか本当に要るの？ → 「本当に」要る要らないの線引きは難しいので，「GHC-bundled」という明確な線引きがあるのは良いこと
• ghc* 系はHackageにアップロードされていないことが多い（ 「GHC-bundled version しか使えないからHackageからのダウンロードの需要がない以上，面倒だからいいよね〜」という理由なのかは知らない）ので，`cabal-plan license-report` が自動でライセンスを拾ってこれないため，License report の Human-written caveat を手書きで追加執筆しなければならないのが面倒 → 頑張れ
という点もありますが，ここら辺は簡単に再反論できるところですね．とくに「GHC-bundled」という明確な線引きがある，というのは結構な美点っぽいです．

みなさんのご意見もお聞きしたいので，よろしくお願いします．

GHCのバージョンごとにAPIが大きく変動するのは ghc-prim の時点でそうで， ghc-prim を入れないのはどうなんだ，というのがあるので今更な気がしてきました…

haskell-platformではGHC-bundledなものであっても区別して扱ってますね。
これにならってterminfoやghc*系は含めないという判断はありかもしれないです。
ghc自体はいろんなデータ構造が入ってるので，あったらあったで面白いとは思っています。UnionFindとかもあるし
https://github.com/haskell/haskell-platform/blob/master/hptool/src/Releases2018.hs

ghc-primはbaseのGHC.Extsから使えるのがほとんどなので直接使えなくても大丈夫だとは思います

Haskell-platform も stability guarantee に入れてないってだけで，アクセスできるようになってる，とは言えるんですけどね…

libiserv が GHC master から library として消滅していて焦りましたが，Hackage にないやつは一応全部 GHC 9.4.4 codebase の libraries/ に存在したので，手書きで license report を弄るのも難しくなさそうです．

なんかunstableだとかいう警告をどっかに書ければいいんですけど…。どうせ cabal.project.freeze の公開ページを作るんだからそこに書けば良いか？