haskell-jp / random #70

λ> e a b = either a b
λ> :t e 
e :: (a -> c) -> (b -> c) -> Either a b -> c
λ> 

??
いやマグマは M × M → M なので Either a b = a が求められるので結局無理な気がしますね Haskellの問題ではなくSemiGroupではない何かになってしまう
eitherEither は違って, eitherはEitherを同じ型にする関数です
maybe と同じ
λ> :t maybe 
maybe :: b -> (a -> b) -> Maybe a -> b

これは、、、
λ> maybe False odd (Just 4) 
False
λ> maybe False odd (Just 3) 
True
λ> maybe False odd Nothing 
False

なるほど。Nothing の場合に適応するのを第一引数ととるのか
fmap_maybe 関数(追記: fold_maybe を間違えたと勘違いし、fmap_maybe と訂正したが、やはり正しくは fold_maybe ) と書いてくれれば分かりやすい?
なるほど、fmap_either (追記: これも同様に正しくは、fold_either )関数が either な訳ですね。理解しました。
fmapとは無関係です
えええ?
代数的に同じ構造してない?
普通MaybeでもJustの時にやるなら <$> 使いますし fromMaybe はともかく maybeeither も私はあまり使いませんね
Functorの要件である写像は、Maybe a → Maybe bのように同じ構造にマップするものです。eitherやmaybeなどの関数は圏論ではF-代数と呼ばれます
MaybeもEitherも剥がれちゃってるので fmap とは余り近くないですね… 他の言語で言う unwrap_or みたいなのにこれらの関数は相当するかと
いや、それは違うんじゃないでしょうか
List A -> B も構造を保つわけですし
それと同じです。
fmapというよりcase~ofでは
少なくともHaskellにおける fmap は違いますね。。。
リスト型に対する fmap(a -> b) -> [a] -> [b] ですし。
maybe 0 (const 0)はMaybeの構造を保つと言えるでしょうか?
1 -> List A <- A x List A 

1 -> B <- B x B  

のようなものであれば
例えば、
A = B = Nat で
下は、0 , (+)
maybeはMaybeの構造を潰すものじゃないかしらん.catamorphismだろうから.
なるほど、やっぱ fold_either でいいのか。
なるほど、fmap ではない。
ありがとうございます。
(ただ、
• fmap と fold を無関係とは思わない。
• catamorphism は準同型を保つわけだから構造が潰れているというのもちょっと )
stackageがk8sのデプロイミスったのか証明書ぶっ壊れてる
:interrobang: 手元で見た感じアクセスできましたが、そういう意味ではない?
https://www.stackage.org/
あ,今アクセスできましたね
さっきの一瞬はデプロイミスなのかデプロイ中だったからなのかわからないですがこうなってたので
ここに、1000 人規模でユーザがいるので、
Agda_JP クラスタ、Coq_JP クラスタってあるのだろうなあと思うのですが、オープンなものってありますか?
メーリスくらいだろうか。
上の方のdataかtypeかの話、dataで定義してPrismを使えば、必要な時だけMaybeやEitherの恩恵を受ける事ができないかな
逆にtypeで定義したものにPatternSysnonyms拡張を使って pattern E1 x = Left (Right x) みたいにやる手も。
しかしPatternSynonymsは微妙にコンパイラバグがあったりするので(少なくともdataで済む所では)あえて使いたくない、みたいな認識です。
僕はパターンシノニム使うぐらいに共通基盤ほしいなら、open union 使いますね
@n_odoki has joined the channel
今朝起きてそういや PatternSynonyms とか ViewPatterns が使えたなと気付いて戻ってきたら書いてあった。
3直和程度で open union は個人的にはやりすぎかな。だったら素直に data するのが一番平和そう。
逆にパターンシノニム利用の動機が分かった気がする。
さて、実際 PatternSynonyms 程度ならちょちょっと使ってみて、思ったほどよくなければ data が現時点で一番素直で読みやすいってなりそうだな。
https://summer.haskell.org 今年のGoogle Summer of CodeのStudent Application Periodは4/1 3am JSTまでです。学生はふるってご参加ください。
プロジェクトアイデアは https://summer.haskell.org/ideas.html にあります。学生が自身のアイデアを出すこともできます。
指定した範囲内のみをスクリーンキャストするウェブアプリ。Herokuなどにデプロイすればすぐ使えるらしい。
新型コロナウイルス拡大をきっかけにオンラインで授業を行うために作ったらしい。すごい名前だ... :joy:
https://discourse.haskell.org/t/covideo19-a-quirk-dirty-screen-sharing-app/1153
Googleは消したいものの名前を付ける(Chrome, Map)と噂されてますがそんな感じの命名センスを覚えますね
地図とクロムを消したい、とは? :thinking_face:
:balloon:ハイライト :balloon:
• レイテンシの少ない並行GC(`+RTS --nonmoving-gc` で有効にできるぞ!)
• コンパイラの出力の改善
• Addr#のようなUnliftedな型もnewtype可能に
• `ImportQualifiedPost` : `import Data.ByteString qualified as BS` のように、文法的にも自然かつソートしやすい構文でインポートできる拡張機能
• GeneralisedNewtypeDerivingとDeriveAnyClassを併用したときの怪しいインスタンスに警告が出るようになった
• `StandaloneKindSignatures` *種*シグネチャを明示的に書ける
• GHCiにおいて、`-fobject-code` を明示しなくても状況に応じて自動で有効化される
• `RecordWildCards` で `Foo{..}` のようなパターンを記述した際、Fooのフィールドを一つも使っていないなら警告が出る(Tsuru Capitalの賞金首第一弾)
• ビット反転操作`bitReverse#` を追加
Chromeはメッキなので,Google Chromeでメッキを消したいとか,Mapで紙の地図を見なくなるようになるとかそういう文脈です
「`GeneralisedNewtypeDeriving` と DeriveAnyClass を併用したときの怪しいインスタンスに警告が出るようになった」のは以前からで、8.10では -Wno-deriving-defaults でその警告を抑制できるようになった、というのが変化ですね
ImportQualifiedPost で地味に違和感あったこところが解消されてて嬉しい!