haskell-jp / questions #3

再現手順も概ねはっきりしているようですし。まぁ何か間違ったら誰か優しく教えてくれますよ。
私も購読してみますね。

今たまたまcabalファイルのsignaturesの欄を削ったらエラーが出なくなったので多分backpackのバグですね
バグであることが確定したっぽいのでそれっぽい例を作ってあとでissueを投げてみようと思います

hashableをimportすると死ぬことがわかったので報告しておきました :innocent: :innocent: :innocent:
https://github.com/haskell/cabal/issues/4847

lensのIso' s a、Isoといいつつview (some :: Iso' S A) :: S -> AというSからAの変換しか作れない気がしてきたんですが、A -> Sって作れますか？

@ynomura has joined the channel

from :: AnIso s t a b -> Iso b a t s ですね

若干邪悪な方法ですがViewPatternsを使うとかですかね

pattern Cons'' :: CallowSExpr -> CallowSExpr -> CallowSExpr
pattern Cons'' x y <- Cons' (CallowSExpr -> x) (CallowSExpr -> y) where
  Cons'' x y = Cons' (growup x) (growup y)

補足ですが．それこそViewPatternsでも使わない限りPatternSynonymsはその名の通りただのシノニムなので，パターンマッチで可能なこと以上のことができるようにはなりません．つまり，コンストラクタをかぶせていく(=マッチして取り出したい値を別の値に変質させずそのまま持たせる)だけで値を作れるルートがある場合にしか，コンストラクトの逆操作であるパターンマッチ(によるデストラクト，中身の取り出し)は定義できません．今回定義しようとしているシノニムに対してあてはめると，(パターンマッチにより分解して出そうとしている，パターンに現れる1，2番目の)CallowSExprをそのまま使って，つまり「その中身を一旦取り出す(grouup)」というコンストラクタをかぶせる以外の操作を挟まずには(パターンに現れる3番目の)CallowSExprをコンストラクトできるルートが無いので，パターンマッチによってCallowSExprを分解してCallowSExprを取り出すことはできないということになります．このことは定義したいなと思ったパターンの型を考えた際に，いろいろとその実現方法について試行錯誤せずとも，それらに現れる型のコンストラクタの情報からできそう/できなさそうについては判断可能かと思います．

ありがとうございます！！

ViewPatternsを除けば、PatternSynonymsは有限なパターンマッチで表現可能なもののみ定義できるって感じですかね？

@notogawa

うおおできた！！ ありがとうございます！！

@myuon_myon

今のケースって、CallowSExpr型のtermをAtomの場合とConsの場合でそれぞれパターンマッチできるようにしたいってことだと思うんですが、newtypeで作った型をコンストラクト・デストラクトする方法は常に1通りしかないのでこういうpatternが記述できてもいいんじゃないかという気はした(ぼやき)

newtypeがdataの特殊な場合だと思うと(つまり一般にdataに対しては)こういうのは当然記述できないわけですが、newtypeは1つのコンストラクタのみからなる型と思えばそのコンストラクタに対するパターンは常にbidirectionalに作れるでしょみたいな

わかる～！

このような解決方法が存在していてよかった。

久々に https://www.slideshare.net/pfi/ss-9780450 を読んでいて気になったのですが、Haskellにconcurrent revisionsの実装はあるんでしょうか？

参考: Purely Functional Concurrent Revisions https://www.microsoft.com/en-us/research/publication/prettier-concurrency-purely-functional-concurrent-revisions/

Database.Relational.Type が relational-query 0.9.5.0 の GitHub の cabal ファイルの exposed-modules にはあるのに Stackage LTS-9.11 見るとないのなんでなんでしょう？
• GitHub https://github.com/khibino/haskell-relational-record/blob/502ff25dcb0b8bd430951192d6deb31657d1ea04/relational-query/relational-query.cabal
• Stackage https://www.stackage.org/lts-9.11/package/relational-query-0.9.5.0

https://github.com/khibino/haskell-relational-record/blob/release-relational-query-0_9_5_0/relational-query/relational-query.cabal にも
https://hackage.haskell.org/package/relational-query-0.9.5.0
にもないということは、
リリース時のミスっぽい感じがしますね。。。 :cold_sweat:

Issueとして送った方が良さそうな気が強います。

いや違うわ。
https://github.com/khibino/haskell-relational-record/blob/release-relational-query-0_9_5_0/relational-query/relational-query.cabal
にもなかったので、参照しているGitHubのコミットがおかしい気がします。

lts-9 のブランチにはあるんで、単純に見てるコミットが 0.9.5 と 0.10.0 の間のコミットなだけだと思いますよ
https://github.com/khibino/haskell-relational-record/blob/lts-9/relational-query/relational-query.cabal

なるほど、バージョン番号上げる前の作業途中のリビジョンを見っちゃったのか

GitHub の検索欄から雑に検索して探してたのでちゃんと clone してブランチ指定して目的のもの探してみます
ありがとうございました

@ has joined the channel

.cabal ファイルに書いてあるけど使っていないパッケージを調べる方法……は packageunused というパッケージを使えば良さそうでした（自己解決） https://hackage.haskell.org/package/packunused

https://hackage.haskell.org/package/weeder の方が簡単そうですよ！

@ has joined the channel

@Hiroto has joined the channel

weeder 試しているのですが色々報告してくれていいですね！

package.yaml には使えないですよね…

引数の命名規則的なのHaskellにありますか?

うーん、型や変数については https://wiki.haskell.org/Programming_guidelines#Naming_Conventions がありますが、引数についてはあまり聞かないですね。。。
もしかして何か具体的に悩んでいたりしますか？

Maybeモナドを引数に取ってJustとNothingで場合分けする関数を作っていて、Maybeモナドの引数名を悩みました。細かいことなのですが…

長く書くのであればmaybeFooみたいにmaybeを頭に着けるか、短くするのであればmbっていうプレフィックスをつけますね。
というか、Maybeを引数にとるのであれば

f (Just x) = ...
f Nothing = ...

という書き方ができるので、そうすればMaybeを意識しなくて済むのでは？

そもそも、関数の型は推論ができても書くっていう慣習があるので、引数の型によって引数名を考える必要は無さそう(関数の型定義を見ろ)。

@igrep ぼくも結局そう書いてました:sweat_drops:
@matsubara0507 C++畑出身なので名前がどうしても気になって…

必要というより、型から引数名考えた方が楽じゃないっすか。だから決してそのアプローチは悪くないと思います。

@ has joined the channel

Foldable型クラスの foldMap は満たすべき Foldable則はないんでしたっけ。ないとしたら型引数を1個持つすべての型コンストラクタは

foldMap _ _ = memtpy

で Foldable にできますか（役には立たなそうですが）。

https://hackage.haskell.org/package/base-4.10.0.0/docs/Data-Foldable.html
曰く

foldr f z t = appEndo (foldMap (Endo . f) t ) z
foldl f z t = appEndo (getDual (foldMap (Dual . Endo . flip f) t)) z
fold = foldMap id

を満たせ、とありますね。
更にFunctorのインスタンスでもある場合は、

foldMap f = fold . fmap f

も満たせ、と。

Endo というのは関数の (.) を mappend として扱うための、関数に対する newtype で、 Dual というのは任意のMonoidの`mappend`を flip するための newtype だそうです。
つまり最初の2つを要約すると、
foldrもfoldlも、 foldMap で合成した関数によって作られなければならないってことのようですね。

foldMap 以外のメソッドは foldMap を使ったデフォルト実装にするとすれば上記のメソッド間の関係は自動的に満たされますね（多分）。foldMap 単独で満たすべき則はないんでしょうか。

foldMap = memptyの場合，Const m関手と同じFoldableを持つのでそれもFoldableといっていいものだと思います

mempty のケースは結構一貫性が感じられますね。例えば、リストを要素に持つ木の fold は普通要素を左から並べて concat したものを想像しますが木ごとに「この木の fold結果は好きに選んだこのリストとする」のように対応を勝手に決めてしまっても Foldable と言ってよいでしょうか。

foldの満たすべき性質の本質は，おそらくfold . fmap f = f . foldだと思います

ただ，これはfoldがどんなmに対しても定義できる多相関数である以上，その他のFoldableの法則が満たされれば，満たされるものだと思います．

「この木の fold結果は好きに選んだこのリストとする」
これは結局木の形に言及したものになるのでそれも一つのfoldの仕方と言えるのではないでしょうか？（今，ちょっと文献を探してます）

「この木」と書きましたが木の形だけでなく同じ木の形でも要素の値ごとに一貫性なく値を割り当てることも考えてました。

要素の値というのは， fold :: Monoid m => t m -> m での， m の型に言及するというのことでしょうか？

型にも具体的な値ごとにも。 fold (Leaf [1]) = [3,5]; fold (Leaf [2]) = []; ...