haskell-jp / random #83

https://scrapbox.io/haskell-shoen/barbies-th barbies-thの新しいバージョン0.1.7をリリースしました。今まで扱いがあやふやだったderiving周りの変換を改善し、元のデータ型と等価なものが導出されるようになったため、既存のコードを歪めずに導入しやすくなりました。データ型の形状と実体を分離できるHKDは幅広い応用ができ、ボイラープレートを一掃できることも珍しくないので、その有用性がさらに評価されることを願っています
また物騒なタイトルだけどいい記事が出ましたね
https://www.snoyman.com/blog/2020/10/haskell-bad-parts-1
Data.Monoid.First が deprecated になるよとドキュメントに書いてあったので代替方法などについて書きました
https://kakkun61.hatenablog.com/entry/2020/10/28/Data.Monoid.First_%E3%81%A8_Data.Semigroup.First_%E3%81%82%E3%82%8B%E3%81%84%E3%81%AF_Last
このdeprecationは撤回されたような記憶があります。
(あまりよく知らない状態ですが)Firstでくるんだだけだと単位元が存在しないのでMonoid(単位元のあるSemigroup)にはなれない、ということですかね。
sumは何が悪くて、代わりに何を使うべきなのか、よく読み取れないんですが、分かりますか?
大抵の Num 型クラスのインスタンスは + の両辺を正格に評価すべきであるにも関わらず、`sum` などは事実上 foldr (+) 相当なので、最適化で特殊化されない限りサンクが増えてしまうよ、という主張だという認識です。
代わりは foldl' (+) ではないかと。
あー、そうですね。sum' = fold' (+) が必要なのかも。
First/Lastモノイドについては「Haskellerのためのモノイド完全ガイド」でも触れました(宣伝) https://blog.miz-ar.info/2019/02/monoid-for-haskellers/
mod_poppo さんのに書いてたっけなーと書く前に見直しました
@naohaq Data.Semigroup.First は Monoid になれないと思います。
Data.Monoid.FirstMaybe の性質を持ってて Nothing が単位元になってますね。
Merge Request が Merge Bot にクローズされてるのはどういうステータスなんでしょうか?
botのコメントの通り、マージされたのでは
元投稿の主題から離れてきましたが、自分が GHC の MR や Git の運用が理解できていないみたいです
Haskellと圏論の関わりがいつからなのか気になって歴史を調べてみたら、各標準へのリンクをまとめているとてもステキなページを見つけました。
https://typeclasses.com/timeline :sugoi:
別のところで聞いてたんですけど、本当にHaskell 1.0ってIOが(どうやらMonadも)なかったんですねー! :open_mouth:
これ超大作ですね :open_mouth:
GHC 3.02 の位置が気になる…w
Haskell Reportにばっかり気をとられて気づかなかった!
やっぱりざっと調べた限り、圏論っぽい名前のFunctorやMonadなどが標準に入ったのはHaskell 1.3からみたいですね。
高パフォーマンスかつwell-typedなシリアライズライブラリ、の1.3.2を公開しました。からExtractorを生成するbuildRecordExtractorが目玉で、たとえ大きなレコードであっても最小限のコードでカスタマイズできます。
extractor = fmap bstrip $ buildRecordExtractor bextractors
    { hoge = extractField "hoge" <|> extractField "oldHoge" }

また、直前の1.3.1では、《貧者のDerivingVia》と名付けた技法を用いたbundleViaという関数が追加され、DerivingViaのような使い心地でありながら必要に応じてメソッドを上書きすることもできます。
instance Serialise Foo where
  bundleSerialise = bundleVia WineryRecord
  extractor = buildExtractor ...

wineryはaesonよりも時間・空間効率に優れ、cerealと違って変更に強いので、Haskellのデータの永続化にきっと役に立つと思います
ご指摘あざっす!修正しました!
やっぱりざっと調べた限り、圏論っぽい名前のFunctorやMonadなどが標準に入ったのはHaskell 1.3からみたいですね。

Haskell 1.2 までは、確かそもそも higher kind type に対するクラスが作れなくて、それが Monadic notions of computations が大きな動機となって 1.3 で緩和されたという話だった気がしますね。1.2 まではそもそもユーザ定義の Functor クラスも書けなかったはずです
@suotani has joined the channel
Nobuyuki Tomizawa
学生の頃にこれを読んだのですが、このあと入ったのだとするとたしかにタイミング的には入っていなかったのかと思います。


https://www.microsoft.com/en-us/research/wp-content/uploads/1993/01/imperative.pdf
Nobuyuki Tomizawa
でこれを読んだのは大学で他の部門の先生から、純関数型言語で入出力のうまい解決方法を考えてみるとか興味ない?と言われて、Goferで遊んだりしていたのですが、その当時ですと、CPS使うとかストリームの遅延束縛を使うとかしていて、これがまたなかなかユニークな感じ往生していました。
Nobuyuki Tomizawa
多分そのころに、GHCがだいぶ広まったりしてきて、東大の武市先生?の周りでもいろいろ活動をし始めた頃で、monadの解説聞いた記憶があります。

'92-93ころでしょうか。
そうですね、dialogue から io monad に切り替わったのも Haskell 1.3 のタイミングなはずですね
@ has joined the channel
Nobuyuki Tomizawa
今日だけ1299円みたいです。(実際に買うときはレートの関係?で若干変動します…経験者談)
https://www.apress.com/jp/book/9781484244791
ブログに deprecation 撤回の旨追記しました
fumievalさん作のWitherableライブラリをopticsに使う記事をRedditで見つけたので共有します。また、Redditのコメント欄で`Traversable, Filterable, Applicative`の制約があれば`wither`を実装できるのになんで`Witherable`クラスがいるの?的なことが書いてあり、それも気になったので投稿しました…
https://www.reddit.com/r/haskell/comments/jlr1g4/blog_composable_filtering_optics_using_witherable/?utm_source=share&utm_medium=ios_app&utm_name=iossmf
optparse-declarative 0.4.0 をリリースしました
foo -t a -t b とあるとき -t a が優先されていたのが、GNU getopt などに合わせて -t b が優先されるように
foo -t a -t b とあるとき [a] のようにリストとして取得できるように
https://hackage.haskell.org/package/optparse-declarative-0.4.0
今年のState of Haskell Surveyが今年もやってきました https://haskellweekly.news/survey/2020.html
AtCoder 過去問の Haskell 実行速度が遅くなっている 9月の GHC7.10.3➝8.8.3 更新以来? :white_frowning_face:
言語アップデートに伴うジャッジシステムの変更で、全ての言語で実行時間のオーバーヘッドが増えてますが、そういうことではなくて?
新作: deriving-show-simple http://hackage.haskell.org/package/deriving-show-simple-0/docs/Deriving-Show-Simple.html
newtypeに対するshowを、`Foo { unFoo = 42 }` ではなく単に`Foo 42` にしたいというニーズに応えるパッケージです。`deriving Show via WrapSimple Foo` のようにDerivingViaと組み合わせて使えます
Redditに上がってました。 Haskell eXchange 2020 の案内です。
その中で、Haskell Foundation というのが発表されると書いてあります。 Mozilla財団とかFSFとかみたいなもの?
https://www.reddit.com/r/haskell/comments/jml10v/haskell_exchange_2020_opening_keynote_the_launch/
https://skillsmatter.com/conferences/13135-haskell-exchange-2020#program
Haskell言語とは無関係な同名団体が既にあるようなので、少し紛らわしいですね
https://www.haskellfoundation.org
Quicksortの話、というよりどうやって RULES プラグマで狙った実装に書き換えるか、という話
https://qnikst.github.io/posts/2020-10-18-quicksort.html
アナウンスのあった、Haskell Foundation のURLです。
https://haskell.foundation/
RichardさんからTwitterアカウントなどもろもろまとめたメールが。
https://mail.haskell.org/pipermail/haskell-cafe/2020-November/132901.html
サイロというのは、真っ平らな平原の上にでかい塔が疎に立ってる、みたいなイメージでしょうか https://twitter.com/syocy/status/1323962751304134661?s=19
まだ昨日の動画を見てないので詳細はわかりませんが、 https://haskell.foundation/en/affiliates/ を見る限り他のcommitteeなども入っているもしくは調整中なので、HFの方向性や実効性が有効と考えるのであればHaskell-jpも入ることを検討しても良いのではと思いました。
ちなみにこの場合GRCと親和性のあるガイドライン・CoCの採用が必要になるようです。
I am of the opinion that there should be a nomination from Japan as well, @igrep you are a good candidate in my view.
以前のissueのとおり、ちょうどGRC・CoCを作ろうとしていたところなので渡りに船ですね。前向きに検討しましょう。
なんとなくAdvent Calendar自体が徐々に下火になっているような印象を受けましたが作りました。
https://qiita.com/advent-calendar/2020/haskell
今年中に仕上げたいネタが2, 3本ほどあるので...