haskell-jp / questions #95

取り急ぎ。package.yamlは使わなくともstackは使えます。
stackとcabalの全般的な話ですが、 https://the.igreque.info/slides/2019-11-29-stack-cabal.html#(1) から大きく状況は変わっていないと思います。
取り急ぎ。package.yamlは使わなくともstackは使えます。
あーそういう意味ですか、僕の解釈ミスっぽい・・・?
はい、cabalファイルは独自形式な上構文エラーがむちゃくちゃ分かりづらいので使う意義はそれなりにあるとは思いますが、確かに機能的な差はあまりなくなりました。
ありがとうございます!
最初「package.yamlは要らないと思う。Stack(そのもの)が非推奨だから。cabalで良い」というニュアンスで読んでいましたが「Stackを使うにあたりpackage.yamlは不要」と読むのが正しいということですね。
スライドも目を通させて頂きました、ありがとうございます。
• 一昔前はCabal Hellとか言われててまあStack使った方が良いよねという雰囲気だった
• 最近はCabalも改善・進化した
• Haskell開発に慣れてる人はCabalだけでも特に困らない
という肌感なのかなと思いました。
この件と関係するかは分かりませんが、1年ほど前に package.yaml から生成された .cabal ファイルをバージョン管理下に置くことが推奨されるようになっています。 https://github.com/commercialhaskell/stack/issues/5210
ですが、自分の肌感覚としては自動生成されるファイルをVCS管理下に置くのは「面倒」なので、 package.yaml を捨てて .cabal を直接書くのは十分検討に値する選択肢だと思います(自分は .cabal の最近の書き方をちゃんと把握していないのでまだ移行できてませんが)。
Stackがpackage.yamlの使用を非推奨にしたと言っています。真偽の程は分かりませんが。
Issuesをざっと検索してみましたが非推奨になった話は見つかりませんでした。どこかで議論があったのかなあ
他の方がコメント書いてましたね。手元のslackアプリがちゃんとロードできてなくて気が付きませんでした。
hpackとcabalファイルの違いはだいぶ減りましたがモジュール一覧の生成に音楽性の違いみたいなものがあって、cabalでは全部列挙する必要があります。
ありがとうございます!
cabal ファイルと package.yaml (hpack) に関して、確か Cabal コマンドは cabal ファイルがないとビルドできないので、Cabal で hackage に無い野良 Haskell ライブラリ(GitHub にだけあるとか)を使う場合は cabal ファイルもあげてもらわないと困るはず?
僕は普段TypeScriptを書いて、たまにHaskellを書くのですが、なんとも上達(?)している感じがしません。
Qiitaやブログで解説されているGHC拡張や、高度なモナドにたまに触れたりしますが、実際に応用する機会に気付けません。

そこで、2つほど、感覚的な質問をさせてください。
• みなさんが「これは美しい..!!」と感じたHaskellコード(断片コード、Repository、人物)はありますでしょうか?
• イケイケGHC拡張や、高度なモナドは頻繁に使用するものなのでしょうか、それとも目の前の課題に対してたまにキレイにハマるものがある、という感じなのでしょうか?
雑で主観的な質問なので、軽い気持ちで返答していただけると嬉しいです。

ちなみに、僕がキレイだ!と思ったのは↓この辺です
https://scrapbox.io/mrsekut-p/Haskell%E3%81%AE%E7%BE%8E%E3%81%97%E3%81%84%E3%82%B3%E3%83%BC%E3%83%89
イケイケGHC拡張や、高度なモナドは頻繁に使用するものなのでしょうか、それとも目の前の課題に対してたまにキレイにハマるものがある、という感じなのでしょうか?
使わないで済むならなるべく使わずに書こう、という動きもあり、私自身それに従っています。
例えばこれ: https://www.snoyman.com/blog/2019/11/boring-haskell-manifesto
Haskellerではなく恐縮ですが、自分はIOや再代入に言語機能レベルで制約が設けられていることに魅力を感じて勉強しています。
美しさというよりは実用性重視です:+1:
(そういえば僕も業務では専らTSです)
昔cabalファイルignoreしてたらNixOSだかArchだかのメンテナに「無いと困るんですが…」って言われましたね
オプションいじったら問題なかったみたいですが
@hal2cilu has joined the channel
@paulpoiu123 has joined the channel
@mpenz.m_0 has joined the channel
jimi.woodstock1995
@jimi.woodstock1995 has joined the channel
@okinakahiro has joined the channel
@kaz45684 has joined the channel
dist-newstyle\build\x86_64-windows\ghc-8.10.3\foo-0.1.0.0 みたいなパスを cabal-install で取得する方法をどなたかご存じですか?
背景を書くと、
• DLL を生成したい
• DLL に C で実装した関数も含めたい
• cabal build では ghc に -c オプションを渡して .o ファイルを生成している
• C コードも別途 ghc -c で .o ファイルを生成している
• DLL 生成は ghc -shared で、このとき事前に生成した .o の場所を知りたい
そもそも cabal で DLL 生成までできるのかな
--enable-shared 試したけどどこに生成されるんだ?
• cabal build では ghc に -c オプションを渡して .o ファイルを生成している
ここの -c は要らないな
• C コードも別途 ghc -c で .o ファイルを生成している
ここもオプション要らないな
新しいcabal-planだとplan.jsonの場所を取得する機能もあるみたいです
教えてもらった cabal-plan でビルドツール書いてたんですけど、cabal ファイルに foreign-library というのがあるのを発見した
https://cabal.readthedocs.io/en/3.4/cabal-package.html#foreign-libraries
foreign-library でイッパツだった:hugging_face:
kimura.masatoshi74
@kimura.masatoshi74 has joined the channel
@kdxu has joined the channel
@mzkxkze has joined the channel
@winterland1989 has joined the channel
@kshiva1126 has joined the channel
benzene.chlorobenzene
shake256のハッシュを無限リストとして返してくれるようなライブラリってありますか?
必要な長さがハッシュの内容に依存するような計算をしたいです
benzene.chlorobenzene
結局必要に応じて"入力"++"カウンター"の固定長のハッシュを計算させれば良いという結論に至りました。
@stat.yukiyama has joined the channel
@hiro.1nakanishi has joined the channel
@harupiyo has joined the channel
@gloel.loe2 has joined the channel
@yf.vermilion has joined the channel
https://matrix.hackage.haskell.org/#/package/doctest-driver-gen で、 GHC の 7.10.3 より大きいバージョンでのテストがされていないんですが、これは仕様が変わったのでしょうか? それとも、まだテストが終わっていないので表示されていないだけ?