haskell-jp / beginners #9

あ、なるほど。
@sesame.parrot has joined the channel
stackの使い方について質問させていただきたいです.
yamlファイルやcabalファイルについてまだ使い方がちゃんとわかっていないところがあると思うのですが,回答いただければ幸いです.

環境はWindows10でstack2.3.1を使っています.

Haskellでsqliteを扱いたく, sqlite-simple というライブラリを使おうと,`stack.yaml` の extra-devs と プロジェクトのcabalファイルに以下のように追加しました.
# stack.yaml
# コメント行は省略します

resolver: lts-16.2

packages:
- .

extra-deps:
- [email protected]:aeb9502c0004054846829766a08d856122a7e7386077b95048e60edaf9f46b88,2947

# cabalファイル(一部)
library
  hs-source-dirs:      src
  exposed-modules:     Lexer, Writer
  build-depends:       base >= 4.7 && < 5
                     , text
                     , sqlite-simple       # この行を追加しました
  default-language:    Haskell2010


するとビルド時に以下のようなエラーが出ました.
Error: While constructing the build plan, the following exceptions were encountered:

In the dependencies for sqlite-simple-0.4.16.0:
    base-4.13.0.0 from stack configuration does not match <4.13  (latest matching version
                  is 4.12.0.0)
    direct-sqlite must match >=2.3.13 && <2.4, but the stack configuration has no specified
                  version  (latest matching version is 2.3.26)
    semigroups-0.19.1 from stack configuration does not match ==0.18.*  (latest matching version
                      is 0.18.5)
needed due to AIQRating-0.1.0.0 -> sqlite-simple-0.4.16.0

Some different approaches to resolving this:

  * Build requires unattainable version of base. Since base is a part of GHC, you most likely
    need to use a different GHC version with the matching base.

Plan construction failed.

dependencies 等々書いてあったため,baseのバージョンが新しすぎて対応していないのかな?などと思い,cabalファイルの build-depends をいじったりしていたのですが,エラーが全く解決できず困っています.
初歩的な質問かもしれないのですが,原因と対処法を教えていただければ幸いです.
そのエラーは「sqlite-simpleのバージョンを0.4.16を指定してるけど、stackage の LTS-16.2 の base バージョン 4.13 では使えないよ(<4.13 という条件がある)」って感じ
エラーの解決方法は次のどちらか
1. 古い base のバージョンを使う(stack.yaml の resolver を lts-15 系を使う)
2. 新しい sqlite-simple を使う(stack.yaml の extra-deps[email protected]sqlite-simple-0.4.18.0 とかにする)
ありがとうございます!やってみます!!
@tatsurotamashiro has joined the channel
@fal19cotton has joined the channel
@shiogai1987 has joined the channel
すこし漠然とした質問なのですが、Haskellで個人のウェブサイトを立ち上げようとした場合、どのフレームワークを使うのがおすすめですか?CMSライブラリも使いたいと考えています。
バックとフロントをWebAPIで繋ぐヘッドレス構成にし、フロントはReasonMLを使ってみようと思います。ちなみにHaskellユーザはPureScriptを使うものなのでしょうか?
eagle.hokkaido2317
@eagle.hokkaido2317 has joined the channel
APIを作るならservantが人気ですね。
フロントは好きなの使えばいいんじゃないっすかね。確かにPureScriptの方がReasonより流行っている イメージ はありますけど。
servant, ありがとうございます!!試してみます!!
@stmtk13044032 has joined the channel
:pray: 進めておいてからなんで申し訳ないのですが、servantはもりもりの型レベルプログラミングを必要とする、結構しんどいフレームワークである点はご注意ください。
https://wiki.haskell.jp/Hikers%20Guide%20to%20Haskell#web%E3%82%A2%E3%83%97%E3%83%AA%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3 にも書いたとおり難しければspockでもいいかも。
あるいは思い切って、servantもspockもベースとしているWAI http://hackage.haskell.org/package/wai を直接使うのもいいでしょう。
情報ありがとうございます!
今使ってるMacBook Proを修理に出そうと思っていて、
代わりにWindowsにstack.exeをDLしてstackからhlintとhoogleをインストールしようとしたところエラーが出たのですが
この記事
https://haskell.jp/blog/posts/2017/windows-gotchas.html
のおかげで助かりました。
chcp 65001

これ知らないと詰まりますね…
takatoshi.ichikawa
@takatoshi.ichikawa has joined the channel
eagle.hokkaido2317
質問です.
glossとgloss-juicyを入れたいのですが,Bitmap型コンストラクタの引数がgloss-1.11.1.1とgloss>=1.13で変わっているため

dependencies:
- base >= 4.7 && < 5
- gloss == 1.11.1.1
- gloss-juicy == 0.2.2
の構成でstack buildしようとすると
> In the dependencies for hima-0.1.0.0:
>   gloss-1.13.1.2 from stack configuration does not match ==1.11.1.1 
>           (latest matching version is 1.11.1.1)
> needed since hima is a build target.
>
> Some different approaches to resolving this:
>
>  * Set 'allow-newer: true'
>   in /Users/vogel/.stack/config.yaml to ignore all version constraints and build anyway.
>
>  * *Recommended action:* try adding the following to your extra-deps
>   in /Users/vogel/Documents/Haskell/hima/stack.yaml:
>
> - [email protected]:6b5f8428b204b2c8fecba0b3dc5f49278d5c57a0003e59c46b16b356a770adaf,3840
と返ってきます.
・一番下のextra-deps追加 → baseやcontainersでさらにエラーが返ってくる
のですが,
・config.yamlのallow-newerはtrueにしても問題ないのでしょうか(他のプロジェクトへの影響など)
・他に解決方法はないでしょうか
他のプロジェクトへの影響など
allow-newertrue にしてもとくに他のプロジェクトへの影響はありません。
自力で直す気もより古いバージョン(古いGHCと合わせて)を使う気もないなら allow-newer する以外の方法はないでしょう。
補足: baseやcontainerはGHCに付属しているパッケージなので、それらが合わない、といわれたらGHCのバージョンを下げる(古いLTS Haskellに変える)しかないです。
eagle.hokkaido2317
ありがとうございます,あんまり大元のファイルをいじりたくないのでバージョン下げる方法でtryしてみます
eagle.hokkaido2317
gloss-juicyの作者に変更点を送ることも考えます
あれ,最新のgithubみると修正されていますね,私の設定が悪い気がしてきました,見直してみます
単純にリリースを後回しにしている可能性もあります(作者に連絡してリリースをせかすのもいいでしょう)。
GitHubに上がっているバージョンを直接使う場合は https://haskell.e-bigmoon.com/stack/intro/extra-deps.html に書かれている方法を参考にしてください。
eagle.hokkaido2317
ありがとうございます,無事環境設定できました!
趣味や民間(?)のパッケージが多いプロジェクトは、stackよりもcabal-installのほうが詰まりにくいかもしれません。StackageのLTSは新しいライブラリや処理系が出回るまでどうしてもタイムラグがあるので、cabalで最新版を使ってもらったほうがライブラリ開発者としてもありがたいです
eagle.hokkaido2317
なるほど,これまでもstackで使えずに車輪の再発明したものもあるので,そろそろ真面目にcabalやり直した方がいいかもしれません.
皆様色々とありがとうございます
@imura has joined the channel
@henri.saks.math has joined the channel
あらたに環境をUbuntu上でつくりはじめました。いままで、開発ツールとしてはstack を使っていましたが、
この際新しいcabalを使ってみようかなぁとか、編集環境はEmacsだったのをVS Codeにしてみようかなぁとか、
hls と連携するにはとか、よく把握してないのです。歴は長いですが、こういうところはさっぱりだめです。
なにか、さくっと決まる定番の組み合わせ、詰め合わせ一式としてはどのようなものがありますでしょうか?
ありがとうございます。じっくり見てみます。
vscodeと hls の連携については、以下の画面イメージのように、簡単になりつつあるそうです。
https://twitter.com/meeple_/status/1286046745076670465
(vscodeから、hls拡張を選ぶと、hlsの静的バイナリが自動ダウンロードされるそうです。)
便乗質問すみません。ghcupとstackを両方いれています。今のところ不具合なく使えていますが、両方入れる事で何か不都合な点があったりするのでしょうか?
stackの --system-ghc オプションを使わない限り両方別々の場所にあるものを使いますし、パッケージもお互いの管理している箇所にインストールしますし、特に問題はないかと。
以前、stackを入れるならcabalはインストールしない方がいいというような記事を見た気がしたのですが、これでスッキリしました!ありがとうございます!
単純に混乱しそうだから両方入れない方がいい、と考える気持ちはわかりますね。でも少なくともstackはそういう併用を意識して作っているのか、原則環境変数やcabalの設定をいじるようには作られてないわけですから、安全かと。
お世話になっております。
YAML形式の設定ファイルからファイルパスのリストを読み込んで、各ファイルパスに対して存在チェックとサイズチェックを行い、
ファイルが存在しない o rサイズが大きすぎる場合にはエラーメッセージを返すようなCLIツールを書いているのですが、自分のコードのどこがイケてないのか全くわかりません。そこで、有識者の方にコードレビューをして頂きたく投稿しました。何かしらコメント頂けたら嬉しいです。

https://repl.it/@liveinwood/File-Check
※環境の都合で実際のコードとは違いがあります。

自分としては、mainの中のパターンマッチを省略できたらいいなと思うのですが。。。
よろしくお願いいたします。:man-bowing:
本質的に場合分けがなくなるわけではないですが、
either (putStrLn . show) return =<< ...
というイディオムで case 式をなくせます。
ただ、現状だと エラーがあっても標準エラー出力ではなく標準出力に出力され、exit codeも0になってしまうので、どうせ例外を吐いて終了するなら
either throwIO return
と書く方がよいでしょう。
そのためには import Control.Exception した上で
MyExceptioninstance Exception MyException にする必要があるのでお忘れなく。
しかしながら、そもそも論として ExceptT IOIO (Either ..) を使うのに適切な場面ではないように感じます。
ExceptT IOIO (Either ...) は、 either throwIO return などのイディオムで簡単にただの IO に変換できるものの、関数の利用者に「この例外は必ず処理しろよ!」という強い義務を与えるものであり、今回 liveinwoodさんが検討しているような小さなツールでは、扱いが煩雑になりがちです。
(余談ですがこれはJavaの検査例外と概ね同じ事情です)
そのためか IO (Either ...) などはアンチパターンだと考える人も多くいます(私はこの点については同意してませんが)。

今回書いたコードを特にライブラリーとして再利用するつもりでもなければすべて IO にしておいて throwIO すれば case式はいらなくなるし、それで十分じゃないでしょうか?
もっと言えば、発生した例外によって結果を分ける、ということをしない限り自前の例外を定義する必要すらなく、 fail で十分だとも考えられます。
Reminder:
beginnersチャンネルは、新しい人がスムーズにHaskellに慣れるための質問を歓迎するチャンネルです。
Haskell-Beginners ML や IRCの#haskell-beginners や RedditのMonthly Hask Anythingのような位置づけを意図しています。

beginnersチャンネルでの回答側は、以下の左側のような応答を厳禁とする運用です。
• それはくだらない質問だ → くだらない質問など無い
• その質問は以前にもあった → 質問者はそんなこと知らない
• Google検索せよ → 検索できないから質問している
beginnersチャンネルでは、例えば以下のレベルの質問から歓迎します。
: とは何のことですか。
• タプルとは何ですか。
コメントありがとうございます。:man-bowing:
ExceptT IO や `IO (Either ...)` は、 `either throwIO return` などのイディオムで簡単にただの `IO` に変換できるものの、関数の利用者に「この例外は必ず処理しろよ!」という強い義務を与えるものであり、
ExceptT IO にそのような意味があるとこは全く意識していませんでした。`IO` の中で`Either` を使いたいって理由だけで使っていました。`Either` を使いたい理由は、最初のチェックがエラーなら次のチェックは実行したくなかったからです。

もっと言えば、発生した例外によって結果を分ける、ということをしない限り自前の例外を定義する必要すらなく、 `fail` で十分だとも考えられます。
ExceptT IO には検査例外の意味があるのに、私のコードでは発生した例外を無視して標準出力に出力しているだけであり、規模からしても`ExceptT IO` を使うまでもない、ということでしょうか?
そうですね。 「最初のチェックがエラーなら次のチェックは実行したくなかった」という要件だけであればIOの例外で十分満たせます。
furuhashitakanobu0413
@furuhashitakanobu0413 has joined the channel
@mail927 has joined the channel
GHCユーザーガイドpdfの目次の12章の部分で文字が重なってしまっている箇所が沢山あるのですが、どこに報告するのが良いでしょうか?(既に報告済かもしれませんが…)
https://downloads.haskell.org/~ghc/8.8.4/docs/users_guide.pdf
正確なことはわかりませんが、GHCのissueにはdocumentation向けのものもあるので例えばそこですかね。
https://gitlab.haskell.org/ghc/ghc/-/issues/new?issue%5Bassignee_id%5D=&issue%5Bmilestone_id%5D=#
ありがとうございます。既に報告済か調べてみて、もしまだのようでしたら他の方のissueを参考に出してみようと思います。
あと事前に相談するとしたらghc-devsっていうメーリングリストですかねぇ
もしお手数でなければ、代わりに出していただいても…:muscle: