haskell-jp / random #58

ありがとうございます！

これですね:eyes:
https://gitlab.haskell.org/ghc/ghc/merge_requests/1934

今月切られる予定の ghc-8.10のbranch には間に合わないので、ghc-8.12 くらいへの反映になります。
それまでの当面は、 ~/.ghci に、 :def! k! (\e -> return (":kind! " ++ e)) の
ように書くと、 k! のエイリアスを作れます。
（:def については、こちらです。 https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/ghci.html#ghci-cmd-:def ）

lts 指定した場合って /root/.stackとかキャッシュした方がいいのかな

@Yachi Wataru has joined the channel

@ has joined the channel

Dhall、去年の Haskell Day の紹介から使い始めたんだけど、1年前からすごい変わっててびびった....
https://github.com/dhall-lang/dhall-haskell/blame/master/dhall/CHANGELOG.md

format が変だなって思ったらいつのまにか multiline let がついてるし（1年前）

Dhall standard も v10.0 を数え、去年とは別物になっているようですね（最近触ってない）

そうなんですよね
hackage での dhall は 1.26 なんですけど

1.17 あたりから別に v1.0 に対応して、
1.18 が v2.0、 1.19 が v2.0 という具合に別に言語のバージョンが振られてる

language standard のバージョンと Haskell implementation のバージョンは別ですね．前者のバージョンアップに対して，後者が追従する形です．

language standard は言語仕様で Haskell implementation はリファレンス実装みたいな感じなんですかね？（よく分かってない

以下私の記憶が正しければですが (どこで読んだか忘れた)，Closure とかも実装があって () これも一級市民 (language standard に対する投票権的なのがある) だった気がします．
Haskell の impl がリファレンス実装というわけではなくて，他の言語の impl と立場としては一緒なはずなんですが，事実上そうなっているという側面はありそうですね．

出典ありました
https://github.com/dhall-lang/dhall-lang/blob/76494a43c48e6a5c3db6510918d138c27d055835/.github/CONTRIBUTING.md#how-do-changes-get-approved

へぇ、そういう関係だったんだ

Haskell の implementation は Gabriel Gonzalez がメンテしてるので，結局一番早いし正確っていうｗ

Clojure?

にわかが露呈してしまった :cold_sweat:

半年くらい前は、速度がとてもおそい（dhall-cabalの実行が1分くらいかかる）という問題があったんですけど、最近どうなってるんだろう

@matoruru has joined the channel

:serval: すっごーい！ https://twitter.com/mr_konn/status/1184138224853114885
https://chrispenner.ca/posts/wc

@hiroshi has joined the channel

http://hackage.haskell.org/package/ghc-datasize-0.2.2/docs/GHC-DataSize.html
任意の値がヒープを何バイト消費しているかを計算してくれる関数を提供するそうです。 :sugoi:

実行が遅いの，だいたい dhall freeze してないことが原因な気がします．
(`dhall freeze` しておくとローカルのキャッシュを見に行くはずなので．)

@ has joined the channel

@momohatt has joined the channel

@Yutaro has joined the channel

どっちの結果になるかぱっと分からなかったやつ https://twitter.com/kakkun61/status/1186133897643352064

StateT IO の落とし穴ですね... これが意図通りに動かないので ReaderT を使えと https://www.fpcomplete.com/blog/2017/06/readert-design-pattern でも書いてるやつだ。

SQL でいうところの ROLLBACK をしてると思えば自分は納得なので、意図通りじゃないかどうかは微妙ですね

@temp_la has joined the channel

トランザクショナルな処理を表現するのに中途半端な状態が出来てしまうと困るので、実は大事な性質ですね。lisztのインサート処理も内部で意図的にStateTを使っています

@tobita has joined the channel

Eta のホームページ（トップページ）見たら猫耳の人載ってるんですね
https://eta-lang.org/

みんなの開発環境が知りたいぞ https://kakkun61.hatenablog.com/entry/2019/10/23/%E6%9C%80%E8%BF%91%E3%81%AE%E8%87%AA%E5%88%86%E3%81%AE_Haskell_%E9%96%8B%E7%99%BA%E7%92%B0%E5%A2%83%EF%BC%88Windows%EF%BC%89

- もともと Win で、最近は Mac
- build tool は stack (resolver は lts の最新)
- editor は Atom に IDE-Haskell を雑に使ってるだけ (HIE は使ってない)

ぐらい？開発環境をカスタマイズするのが苦手なので基本いじってない。

自分もエディターのカスタマイズなんかは最小限に済ましたい
後で分からなくなるから

- Linux
- 実行するアプリはstack（resolverはltsをできるだけ上げていく）、ライブラリはcabal
- SpacemacsのHaskell layerにhie
みたいな感じですかね

（ghcup はなんで Haskell 製じゃないんだ？）

PATH を書き換えたりする必要があるので必然的にシェルに依存せざるを得ないのではないかと。
単にインストールするだけの為にツールを作るのも確かにありですけど。

ちなみに私はNeovim + languageclient-neovimを惰性で使ってます。
が、HIEのGHC 8.8向けのビルドスクリプトがまだ提供されてないのでまだかなーと思いながら概ね筋力で書いてます。多分やろうと思えばビルドできるんだろうけどね

エディタは職場とLinux機でspacemacs、Win機では試しにvscodeですが、spacemacsでいいんじゃないかなって感じです。ide engineは一回セットアップしたけどバージョンアップで壊れて以来直してません

ビルド面倒くさくて結局惰性で書いちゃいますよねー

Spacemacs わりと人気

Windows, Stack (lts-12.26 で固定), vim (フォーマッターなし)

Haskell をあまり使ってないので特殊なケースだと思います

OS: Linux
ビルドツール: stack
エディター: vscode
ide: ghcid
HIEは気に入ってたけど、パソコンの問題なのか、プロジェクトがある程度の規模になると壊れるので、使うのやめました。

Haskellとは関係ないけど、Slackでもついにダークモードが実装されました。
https://slackhq.com/intl-ja-jp-dark-mode-for-slack-desktop

HIE 小さいプロジェクトだと動くけど、大きくなるとなぜかあやしくなるんですよね……

頑張って改善してはいるらしいっすよ。大きさというよりコードの内容に依存するのかも。
GHC本体のコードだとするとTHとか特殊なことはあまりしてないでしょうし。
https://github.com/haskell/haskell-ide-engine/issues/1357#issuecomment-520127513

postgresql-pure リリースしました

Hello.

I published a library “postgresql-pure”, which is a PostgreSQL driver

written in pure Haskell, a few days ago.

This library is developed to aim:

- to increase the performance on multi CPU core environments
- to run on multi platform
- to build it easier especially on Windows to remove the dependency
on libpq, which is made by C
- there is postgres-wire which is a fast implementation but it
doesn't support Windows

I confirmed that:

- the performance was proportional to the number of cores
- the performance on 12 cores were 28% better than postgres-wire, 300%
better than postgresql-simple

Both test cases are simple constant value queries like “SELECT
2147483647 :: int4, …” to decrease server's load.

I'm writing a report about this development and I will send email again.

Please try this and feel free to report issues.

Best,
Kazuki Okamoto

Hackage: http://hackage.haskell.org/package/postgresql-pure
GitHub: https://github.com/iij-ii/postgresql-pure

https://mail.haskell.org/pipermail/haskell-cafe/2019-October/131609.html

ちなみに HDBC インタフェースを提供しているので relational-record のバックエンドとして使える
https://github.com/iij-ii/postgresql-pure/blob/master/test-relational-record/Spec.hs