Topic Request: 普通のレコード型を定義するときのベストプラクティス

[igrep]

Slackでの https://haskell.jp/slack-log/html/C4M4TT8JJ/64.html#message-1577159731.008800 あたりの議論から:

@as_capabl

なるほど、この辺ふまえて2019年時点で、普通のレコード型を定義する場合のベストプラクティス、みたいな奴をだれかがまとめると良いかもしれませんね

[as-capabl]

とりあえず

• rioのベストプラクティス をベースに
• RecordWildCards はrio的には非推奨ですが有効にして
• DuplicateRecordFields OverloadedLabels を有効にして
• どこかのパッケージのIsLabelインスタンスを使って #member 等をgetterとして使えるようにする
• rioのReaderTパターンで使う Has インスタンスを定義する

みたいなストーリーになると思っています。

[igrep]

どこかのパッケージのIsLabelインスタンスを使って #member 等をgetterとして使えるようにする

generic-lensがいいでしょうね。Has のインスタンスも自分で定義する必要はないはず。

[igrep]

RecordWildCards はrio的には非推奨ですが有効にして

せめて NamedFieldPuns にしません？

[as-capabl]

Has のインスタンスも自分で定義する必要はないはず。

すいません、ものすごく飛躍しました。rioのHasインスタンスは、上記rioベストプラクティスの
When defining Has-style typeclasses から始まる節で触れられているやつです。

普通のlensを使う時は makeClassy をよく使うので、OverloadedLabelsに移行する時はどうしようかと悩んでいる所です。

[igrep]

いや、それはわかるんですが、わざわざ手で定義しなくても十分 http://hackage.haskell.org/package/generic-lens-1.2.0.1/docs/Data-Generics-Product-Fields.html#t:HasField で代用できるのではないかなぁと思いまして。

[as-capabl]

なるほど、自分の書くコード間だったら、それでいけそうです。
ただ既にrio準拠で作られているライブラリを使う場合は、手書きが必要になってしまうという問題があります。

このボイラープレート嫌だよね、とは本家の方でも言われているみたいです
commercialhaskell/rio#113

[as-capabl]

issueリンク入れると向こうのissueに表示されてしまう……

[as-capabl]

いろいろ調べてみたのですが、generic-lensのヘッダに "Use at your own risk." などと書かれているのを鑑みるに、まだベストプラクティスと呼ぶには成熟していないと考えた方がいいと思います。

https://hackage.haskell.org/package/generic-lens-1.2.0.1/docs/Data-Generics-Labels.html

とはいえOverloadedLabelsによるレコード操作は今後主流になっていくであろう機能なので、タイトルを変更して「OverloadLabelsとgeneric-lensでストレスフリーなレコード型を」という記事にするのはどうでしょう（せっかくなので執筆してみたい）

[igrep]

いいですね！
個人的には、多少タイプ数が多くても field @name などと書くつもりだったので、 Data.Generics.Labels については想定していませんでした。
#name でアクセスできるようにもしてくれてるんですね。
「Use at your own risk.」なのはgeneric-lens全体ではなく、このモジュールが IsLabel のorphanなインスタンスを定義してしまっているからではないかと。

タイトルを変更して「OverloadLabelsとgeneric-lensでストレスフリーなレコード型を」という記事にするのはどうでしょう（せっかくなので執筆してみたい）

ぜひぜひ！ 👍

[debug-ito]

だいぶ前のissueですみません。このトピック、かなり読んでみたいのですが・・・。