haskell-jp / random #4

@giwanaga17 has joined the channel
Packt 社の品質は物によるそうですが http://note.golden-lucky.net/2017/12/blog-post.html
ではなおさら安いうちに買っておきたいですね!私は買います!
eagle.hokkaido2317
@eagle.hokkaido2317 has joined the channel
GHC の 8.4.1のアルファ版のリリースについての補足です。 お楽しみ!:haskell:

https://www.reddit.com/r/haskell_jp/comments/7lm52h/ghc_841alpha1_available_ghc841%E3%81%AE%E3%82%A2%E3%83%AB%E3%83%95%E3%82%A1%E7%89%88/
あちこちで古いと言われてなぜか悔しかったので意地で更新しました。
https://qiita.com/igrep/items/da1d8df6d40eb001a561
残念ながら、追記が多くて読みにくくなってしまってはいますが。。。 :disappointed:
questionsの方でも書きましたが、Linuxは昔は複数のファイルディスクリプタ(fd)の変化を監視して待つシステムコールがselect(2)しかなかったんですよね。
selectは変化を監視したいfdをビットマップで指定する(fd = nを待つ場合はビットnを立てる)ようなインターフェースになっているので、あまり沢山のfdは扱えないようになっていました。ビットマップをスキャンしたり更新したりするのはカーネルの負担になるので。
今のLinuxカーネルにはepoll(*BSDでいうところのkqueue)があってfdの変化をイベントキューのようなインターフェースで待てるので、そのような制限をかける必要がなくなったと。
最大値の数ビット分だけメモリーをあらかじめ確保する必要があった、っていうことですか?
ZaloraはHaskellやめちゃったんですかねえ https://github.com/zalora/
数年前、PHPから乗り換えるって言ってたけど、GitHubにも動きがないし、Haskellerがいる気配もなくなってしまった
はい。プロセスが持てるfdの数が1024個だとすると、1024bitのデータをユーザースペースとカーネルとでやり取りする必要がありました。どんな定義になっているかはこちらの記事 https://qiita.com/fujinochan/items/2337ce48a998cf67966b で言及されています
https://github.com/commercialhaskell/stack/issues/2240
ダウンロード、s3直なのをどうにかしたいですね
https://github.com/sozysozbot/akrantiain2
自分がHaskellで書いたコードを置いておくとプロの方々がマサカリを投げてくださると聞いて
stack使ってない
テストはよくあるフレームワーク使おう
ciやろう
すみませんが、まだ中身は読んでいません
もっとキレのいいマサカリが準備できるとよかったのですが。
まさか Makefile とは。。。なぜcabalも使わなかったのか逆に気になりますね。。。
igrepさんのは「自プロジェクトをcabalizeしなかった(.cabalファイルを作らない)のは何故ですか」という話ですよね .
dependenciesをinstallするとこの話じゃなくて
https://github.com/sozysozbot/akrantiain2/blob/f1b741b11cea585f72ba2ce6c68cdf9411fa172e/akrantiain2.hs#L48-L59 らへんのエラー処理ですが、
自分の場合、 IO (Either e a) みたいな値は eException のインスタンスとなるように変換した上で :point_down: みたいな関数で処理することが多いですね。
throwOnLeft = either throwIO return
どうなんでしょうね。パース結果がせっかくEither で来ているのにException?
パーサーの中ならExceptionもいいかもしれないですが。
私だったら EitherT コンストラクタを被せてdo文で書くと思います(リンクはMaybeTですが似たような感じで書けるはず) https://github.com/as-capabl/armageddon/blob/f5f6d676e00f508fe37efa77cedad89b58cf1023/app/Content.hs#L137
全部同じ型のエラーだったらその方がよさそうですね。
main 関数のような、トップレベルに近い、「中の処理でいろいろな例外が起こりうるけどもう復帰できないから最後に最低限何が起きたのかログだけ書いておこう!」みたいな状況でを想定してました。(が、今回の場合全部同じエラーなのかな?)
確かに、そういう状況だと例外がいいですね
コンストラクタ1つでその種類は番号を持たせることで識別するようなエラー型の設計はやや気になります.
エラーが起きたときそれが何のエラーかを判定してワークアラウンドするなりというのはよくあることと思いますが,
エラー番号で識別することになると識別(=パターンマッチによる)の網羅性が緩くなる懸念が発生します.
種類毎にコンストラクタを定義して,番号が欲しい場合は数値への変換を別途定義しておくのが好ましいのではないかと.
ところで, EitherT は非推奨になったので,使うなら ExceptT ですかね?
https://www.stackage.org/haddock/lts-10.1/either-4.5/Control-Monad-Trans-Either.html
そうですが、IOと一緒につかうExceptTは。。
https://www.fpcomplete.com/blog/2016/11/exceptions-best-practices-haskell
違うモナド間の移動が発生するのは大変ですので、できれば避けたい。
Yesodでこりごりです。
yesod monad, conduit monad, aws monad ...
確かに ExceptT については、局所的に使うのであれば、って感じですかね。。。
ところで,あんまり議論をよく見ていないんですが,このUIの良し悪しはともかくUIをそのまま守るなら,わざわざ >>>= みたいな汎用的なインタフェースを用意しないで,こんな感じで書くのが好きですね
  ...
  toks <- pure <$> runParser toTokens () fname input `catchEither` \e -> do
      printError e
      exitWith $ ExitFailure TOKEN_FAILURE_CODE
  ...

catchEither :: Either a b -> (a -> b) -> b
catchEither e f = either f id e

printError :: (Show a) => a -> IO ()
printError x = do
  hPrint stderr x
  hPutStrLn stderr "\n\nPress Enter after reading this message."
  void getLine
そうか。 IO が絡むから >>>= なんて作ったのかな、と思っていたけど、よく見たら IO (Either e a) ですらないんですね。
それから, https://github.com/sozysozbot/akrantiain2/blob/f1b741b11cea585f72ba2ce6c68cdf9411fa172e/akrantiain2.hs#L72 ですが,cabalのパッケージシステムを使うと,version情報をPaths_<pkg>というcabalが自動生成するモジュールから取れたりするので,その点でもcabalパッケージへの移行はおすすめですね
あと, https://github.com/sozysozbot/akrantiain2/blob/master/Akrantiain/Pattern_match.hs#L86 これとかは現状コメントとしてなんですかね? doctest() を使うとこういうサンプルコードコメントをコメントの書式を変えるだけで Haddockでハイライティングされて,さらにテストに流用できるようになるので,おすすめですね.cabalパッケージ化すると, がパッケージと依存一覧を自動生成してくれるようになるのでこれもおすすめです(cabalのバージョンが1.24以上じゃないと使えないのが難ですが)
インターフェイスとして露出させるならEitherTもといExceptTは嫌ですね。逆に外に漏らさないというメリットでもあるので、適材適所だと思います
帰宅したらたくさんのマサカリが来ていてありがたい限りです
年末年始でゆっくり直していきます
自プロジェクトをcabalizeできることを知ったのがコードを書き始めた後だったからです(完)
番号振ったのは…なんでだっけ(忘れた)
テストにまで流用できるのですか、情報ありがとうございます
そうか。。。そういえばすごいH本とかじゃその辺教えないですもんね。。。 :disappointed_relieved:
そういうことです、すごいHとReal World Haskellと「関数プログラミング 珠玉のアルゴリズムデザイン」ぐらいしか当時は読んだことがなかったもので(最近やっと「Haskell入門 関数型プログラミング言語の基礎と実践」を読んだ)