haskell-jp / random #29

evalShow :: Int -> Expr -> String
というのを実装してみました.値の近似列を指定した段数まで,または,確定するまで表示します.
@mizunashi-mana それは1/0が無限ループになるようにDivの定義を変えて辻褄合わせるしかないですね…
個人的にはdenotation、つまり式が抽象的に持つ値をvalueと呼ぶ立場は実はけっこう好きなんですが、ただ一般的なプログラマの感覚とずれる部分は間違いなくあるっぽいんですよね…
@as_capabl 停止するボトムにコンストラクタを割り当てることでも可能じゃないですかね?
変更したLazy版は 1/0が無限ループに落るようになってます.:)
たとえば今回の場合、Iter Value'をvalueと呼んでしまうとcall-by-valueというタームが意味不明になってしまう
Porの定義は、何をfalseとするかの問題なので、あまり細かく考えてないです
call-by-hogehoge はあんまり使いたくないというのが正直なところ,
一般的な「imperative」プログラマの感覚とはずれるけど...
(私はもはやimperativeな感覚を失なっているようで,declarativeな表現の方がしっくりきます)
新しいPorの定義だと、 Por (Con 1) (Con 2)Por (Let (...) (Con 1)) (Con 2) が違う値になってしまうのが気持ち悪いかな…
この場合は Por の意味は先に計算が終った方という意味なので,ありかなと思います.
まあ,最適化とか考えるときに問題にはなると思いますが,あくまでToyなのでそこは突っ込みませんでした
もちろん,左のオペランドにすこしバイアスがありますが,
Por は非決定性をもちこむことになるので,決定性があることが前提の最適化とは最悪の相性でしょうねぇ.
(かなり本題から外れる気がしますが)多分一番の問題はまともなequational reasoningが書けないことにあると思いますね(本来のporの定義であれば書けます)(なお, @as_capabl さんの方も書けなそう.あと,porがstrictじゃない(⊥ por ⊥ /= ⊥)のも気になる感じですね).なので,今の定義だと幾つか嬉しい性質が壊れる気がします
eval (Por bot bot)が停止しないのと,evalShow 20 (Por bot bot) =>"⊥,⊥,⊥,⊥,⊥,⊥,⊥,⊥,⊥,⊥,⊥,⊥,⊥,⊥,⊥,⊥,⊥,⊥,⊥,⊥,..." なので多分 Por ⊥ ⊥ = ⊥になると思います.
あ,すいません勘違いでした. 想定してたのは Por (Div (Con 1) (Con 0)) (Div (Con 1) (Con 0)) みたいなやつなんですが,普通にこれは exception 吐くんですね.普通にstrictでした
あれっ.いまのは,例外をはかないと思います.
あ, @as_capabl さんの方ので言っています.多分, @nobsun の方も問題ないと思いますね (ミスって, random にも投稿してしまったっっ)
一応補足ですが, @as_capabl さんの方で問題になりそうと思ったのは,
>>> eval $ Div (Con 1) (Con 0) `Por` Con 1
1
>>> eval $ Div (Con 1) (Con 0) `Por` Div (Con 1) (Con 1)
*** Exception: divide by zero

ですね
@blue271828 has joined the channel
それも1/0が無限ループするようにすれば整合性がつきますが、それはそれとしてporの意味論とかはもう少し勉強してきます
「高階な」って言葉が気になるのは私だけですかねえ・・・。 MonadPlus m であれば m a はモノイド、ならシンプルかつ正しい主張でいいんですけど。
Monoid1みたいな?
@to has joined the channel
私が勝手に意味を変えたPorは参照透明性を破壊します.
というわけでまともなものではないです.勝手に意味を変えてすみません.:disappointed:
husking_pimento_novel
@husking_pimento_novel has joined the channel
@pkmcrb63 has joined the channel
@ykaneoka7 has joined the channel
@superhahnah has joined the channel
@tomotom16 has joined the channel
@m.nagashio.n618m has joined the channel
@decimaltsukumo has joined the channel
@dimension.sf has joined the channel
@hanotch88 has joined the channel
@mihchang has joined the channel
賛成多数、反対意見はゼロだったので、当該チャンネルはアーカイブしました
@quantumular has joined the channel
GHC か stack のバージョンが上がったせいなのか、Windows でこの手順で iconv がビルドできなくなっててしんどい
resolver: lts-12.17
https://teratail.com/questions/102462#reply-157722
GHC 8.2 から GHC の iconv 依存がなくなったのかな?
stack exec -- pacman -S libiconv-devel

して
stack build --extra-include-dirs="$(stack path --programs)\msys2-20180531\usr\include" --extra-lib-dirs="$(stack path --programs)\msys2-20180531\usr\lib"

でいけた
リンク時にエラーになった……
> `libiconv_open' に対する定義されていない参照です
--- a/iconv.cabal
+++ b/iconv.cabal
@@ -26,7 +26,7 @@ library
   includes:        hsiconv.h
   include-dirs:    cbits
   c-sources:       cbits/hsiconv.c
-  if os(darwin) || os(freebsd)
+  if os(darwin) || os(freebsd) || os(windows)
     -- on many systems the iconv api is part of the standard C library
     -- but on some others we have to link to an external libiconv:
     extra-libraries: iconv

で大丈夫っぽい
iconv って darcs 管理なんですけど PR とかどうすればいいんですかね?
メールでパッチ?
ちょっとずれるかもしれませんが、Windowsでposix系ライブラリを使う場合、msysを別途インスコしてstackでskip-msysする手順の方が色々うまくいく印象があります http://fumieval.hatenablog.com/entry/2017/10/11/230117
もう一つ蛇足ですが、窓まで考慮に入れるとiconvよりicuの方が良さそうという意見も https://twitter.com/as_capabl/status/783601389666643968