haskell-jp / random #23

(私もちょっと寄稿しています)
すげーいいなー!
ほんとすごい!!!
@k.marumaru524 has joined the channel
ここで聞く話なのかは微妙ですが、 Ix のインスタンスに (Bounded a, Enum a) => a が無いのは何故なのでしょう? それだけあれば 必要要件は書けるはずなんですが。。。
あ、要件だけで言えば、Bounded a の部分は要らないですね。
FlexibleInstancesが必要になっちゃうのを避けたいという信念じゃないっすかね。。。
実害があるのかは知りませんが。
DerivingViaでその辺の問題が解決してIxのインスタンスをderiveしやすくなるかも!
@toshihident has joined the channel
一般論として、具体的でない型のインスタンスを定義するのは避けられています。もし`instance (Bounded a, Enum a) => Ix a`を定義してしまうと、それより特殊化された効率の良い実装を与えることができなくなってしまいますからね。もちろんigrepさんの言う通り、newtypeのラッパーを定義して、DerivingViaを活用するのも面白いと思います
Haskell Symposium 2018のproceedingsの一覧を作りました。PDFが公開されている論文にはURL付きです。
https://gitlab.com/igrep/papers-notes
個人的なメモを追記していく予定ですが、参考までにどうぞ。
instance (Bounded a, Enum a) => Ix a って {-# LANGUAGE UndecidableInstances #-} も必要な奴では。

UndecidableInstancesは、型推論が停止しなくなる可能性があるのがデメリットですね。
https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#instance-termination

もっとも、モダンな型関係ライブラリほとんどで使われてる RankNTypes を入れた時点で型推論は停止しなくなるので、最近のHaskellでは「型推論の停止性(笑)」状態っぽいですけど
いっそIxクラスをなくしてrangeやindexを range :: Enum a => (a, a) -> [a] 等にしてしまったらどうか、と思ったんですが、例えばVoidはIxではあるけどEnumではないんですね
良いですね!、英語版のredditに貼っておけば喜ばれるのではないかと。:haskell:
ふっと思った事を聞いてみただけですが、色んな理由や考えがあるんですね。 まだまだ知らない事だらけだ
いっその事、型変数の量で選ばれる 0個が一番強くて大きくなると選ばれにくくなるみたいなのがあればいいんでしょうね。
型変数の量っていうのは少々間違いで、正確には抽象度の少さ で選ぶ その基準の一つとして上げられるのが型変数の種類 っていう話です
https://github.com/serokell/universum#gotchas-
You can't call some Foldable methods over Maybe and some other types. Foldable generalization is useful but potentially error-prone. Instead we created our own fully compatible with Foldable Container type class but that restricts the usage of functions like length over Maybe, Either, Identity and tuples.
:thinking_face: :thinking_face: :thinking_face: :thinking_face: :thinking_face:
MaybeにmapM_できないの、反知性的と言いたくなるデザインだ…
https://twitter.com/igrep/status/1022732186510811137 こういう話ですよね。
エラーは絶対無視したくないっていうGo言語からきた発想だと、気持ちはわからなくもないです。
でもリスクをわかった上でMaybeにmapM_する自由ぐらい与えてやれよって気持ちもわかります。 :sweat_smile:
何か制約を課す場合、それは論理に沿ったものあるべきと考えていて、このライブラリのように人間本位の制限を付けるのは好きにはなれないです。値を捨てたくないなら線形型のようにもっと筋の通った概念があるわけですし
どのインスタンスが選ばれるかはプログラムの意味を変えうる重要な問題なので、その基準が複雑になるほどプログラムの論証は難しくなります。書き換え規則(RULESプラグマ)のような補助的な機能でさえその問題は深刻なので、Haskellの根幹をなす型クラスは、できる限り簡潔にするのがよい設計だと思います
なるほどね。そういう抽象化が進めばボイラープレートが減るんじゃないかなと思ったんですが、実装が複雑化するのは否めないですね。
今見てみたら、gitlabの表示で、レンダリングが崩れてるようですよ。
<details> 入れてからかな... 確認します
@rapptea6 has joined the channel
ちょっと視点がずれますが,Haskell の Enum 型クラスはちょっと直感に反するところがあるような気がしますね.Double や Float が具体例だったり,列挙方法が与えられていなかったりします.列挙方法が示されるという意味では Ix の方が 「Enum」 の印象に近いですね.
@takumi.k.5610 has joined the channel
@kyotsuya has joined the channel
サークルチェックできるようになってた
一昨日らしい
さすぎじ
GHC 8.2に追加されたもののあまり話題に上がらないCompact regions () について、最近いい使い方がわかってきたのでシェアします:
・一秒に数回以下の低頻度で更新するデータをcompactする(Mapなど、ポインタ数が多いものによく効く)
・IORefに突っ込む
・GCが速い!:v:('ω':v:)三:v:('ω'):v:三(:v:'ω'):v:
不変データを格納するイメージに反して、参照型と相性がよいです。大規模なプログラムはどうしてもGCで止まる時間が長くなってしまう宿命がありましたが、それを打開しうる非常に強力な機能です
一度compactすると、その時点でそこから参照で繋がっている塊を一つのでかいメモリオブジェクトだと考える=GCが楽できるから早い、みたいなイメージですね。すごい、使ってみたい
確かに 音沙汰無いって感じですよね。 面白そうな感じで使ってみたいです
そういえば、そもそも GHC がどういう GC 戦略なのか知らないな
http://hackage.haskell.org/package/compact こういうラッパーがあるみたいですけど、使いましたか?
GCの頻度よりもデータの更新頻度が低ければ効果が出るので、使える場面は少なくないと思うのですが、そもそも低レイテンシを求める人が少ないがゆえに取り沙汰されないのかもしれませんね
GHC は、回る黒板みたいに、生きてる(?)アイテムを裏にコピーしてコピーが終わったら回すっていうやつが標準で、RTSオプション(だったと思う)で(黒板の例えで言うと)使わなくなったのを消すみたいな戦略だったと思います。
ですね、Haskell は一度きりのデータ生成が多い(ほか言語のと違いstatic変数の使用が少いと個人的に思ってる)ので、実質的にこれが一番という事なんでしょうね。
デフォルトでは2世代の世代別GC(したがってりんご姫さんの言う通りコピーGC)ですね。メモリ確保などでスレッドがyieldしたとき、条件を満たした場合に並列で処理されます
並列で処理されるのは知らなかったや。 そんな機能もあるんですね
実用してる人の生情報は興味深いです! 不変データの格納と参照型の相性の良さというのは面白いですね!

あと、うろ覚えですが、確か速さ的には、こんな感じだったと思います。
・Compact regionに入れるときに、全てを完全評価済みにした上で、連続的なメモリに配置するので次からの参照が速い。キャッシュが荒れない。
・Compact region内のどれかへの参照があるかぎり、塊ごと、GCの対象から外れる。GCの量が減る。

あと補足共有情報です。 Compact region作者による(論文出ない方の)説明資料です。
http://ezyang.com/slides/ezyang15-cnf-slides.pdf

あと、GHCのcopying GCの、雰囲気イメージ図と、
https://takenobu-hs.github.io/downloads/haskell_ghc_illustrated.pdf#page=41

GHCの2世代のGCの、雰囲気イメージ図です。
https://takenobu-hs.github.io/downloads/haskell_ghc_illustrated.pdf#page=71
@syanidar has joined the channel
hfmtのビルドにひたすら時間がかかるなどした(stack使っているはずなのにcabal hellみたいなことになった)
最終的に http://hackage.haskell.org/package/hfmt-0.2.3.1/reports/1 に書いてあるバージョンで全部揃えてやっと成功(それまでに4880行を費やした)
最近のnewtypeの盛り上がりに触発されて、newtype, data, typeでカジュアルに遊ぶ内容を書いてみました。enjoy:haskell:
https://qiita.com/takenobu-hs/items/14101cabf313e6d594ca
unsafePerformIO(を用いた式)が正当化される式への条件みたいなの、定式化されて欲しいな