haskell-jp / random #37

@tech_machii has joined the channel

もくもく会で少し紹介したやつを、Dhall本家リポジトリに載っけて貰うissue立てた…めっちゃ緊張します https://github.com/dhall-lang/dhall-lang/issues/356

ビルドオプションとか変えてみて動作確認したまとめ
http://kakkun61.hatenablog.com/entry/2019/01/30/Haskell_Ctrl-C_%E5%8B%95%E4%BD%9C%E7%A2%BA%E8%AA%8D

@Koyanagi S has joined the channel

@heyclor has joined the channel

@ has joined the channel

moduleをqualifyした状態でre-exportできるようにする提案 https://github.com/ghc-proposals/ghc-proposals/pull/205

そう言えば、去年の話になるけど、 https://haskell-jp.slack.com/archives/C4M4TT8JJ/p1545795271024900?thread_ts=1545795271.024900 な事を言ったと思うのですが、 それっぽい状況に遭遇した かな？ と思ったので追記

Resolving dependencies...
cabal.exe: Could not resolve dependencies:
[__0] trying: generic-storable-0.1.0.0 (user goal)
[__1] next goal: base (dependency of generic-storable)
[__1] rejecting: base-4.12.0.0/installed-4.1... (conflict: generic-storable =>
base==4.5.*)
[__1] rejecting: base-4.12.0.0, base-4.11.1.0, base-4.11.0.0, base-4.10.1.0,
base-4.10.0.0, base-4.9.1.0, base-4.9.0.0, base-4.8.2.0, base-4.8.1.0,
base-4.8.0.0, base-4.7.0.2, base-4.7.0.1, base-4.7.0.0, base-4.6.0.1,
base-4.6.0.0, base-4.5.1.0, base-4.5.0.0, base-4.4.1.0, base-4.4.0.0,
base-4.3.1.0, base-4.3.0.0, base-4.2.0.2, base-4.2.0.1, base-4.2.0.0,
base-4.1.0.0, base-4.0.0.0, base-3.0.3.2, base-3.0.3.1 (constraint from
non-upgradeable package requires installed instance)
[__1] fail (backjumping, conflict set: base, generic-storable)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: base, generic-storable

cabal install generic-storable` で、でました。 無論 allow-newer で解決したんですが、、、SemVarが絶対の世界(っていうと問題ありそうだけど、、、)だと特になんの意識もしないで入れられる筈ですよね？

@白椿 has joined the channel

まず、 SemVer というのが上3つのバージョンを対象に指しているなら、 base は SemVer に準拠していません。今回問題になっている 4.5.x と4.12.x の間だと
* Monad が Applicative のスーパークラスでない
* Prelude から catch が消えた
などの破壊的変更があります。今回、 allow-newer で問題が起きなかったのは、たまたまこれらの問題を運良く踏まなかったからです。

また個人的には、依存 constraints をライブラリ作者が提供している以上、それに違反する制約でビルドすることは、例えどのような背景がありその制約が生み出されたにしても、動作保証外という認識です。なので、 allow-newer 以上の矯正的な自動解決に需要はあまりないと考えています。

動作保証があるなら、その旨をライブラリ作者に伝え、 constraints を緩めてもらうことを個人的には推奨します

@ has joined the channel

うーん。 今回はたまたま、1個のライブラリだったから良かったものの、10個も20個もみたいな状況だと対応しきれないような。。。 みたいな事を思ってたのですが。。。 やっぱり、人間が付ける バージョン番号には限界があるって事 なんでしょうか。

えっと，上で主張したいのは2点あって
• 今回の場合そもそも allow-newer はたまたま成功しただけで，安全な操作ではない．よって，今回の事例ではそもそも rely-on-version 相当のものがあっても安全に依存解決ができたわけではなく，むしろ SemVer にちゃんと準拠していたなら今回の generic-storable は rely-on-version ではビルドできていない (つまり，今回の事例は動機になっていないように思う)
• cabal の依存 constraints は SemVer の制約を表すのに十分な表現力を持っています（例えば SemVer に準拠したライブラリを使う場合 >= その時のバージョン && < 次のメジャーバージョン と指定すればいい) し， constraints とはそのライブラリの動作保証の範囲を表します．それに違反するような constraints を使うということは少なくともライブラリ作成者は意図していないはずです(そもそも constraints はその意図を表すものなので)．そのような場合に強い需要がなく実装コストの高い柔軟な自動解決が手段が必要なのか

という感じです． 10 個も 20 個も SemVer 準拠だと解決できるような状況は個人的にはあまり起こらないと思います(むしろ，10数個 constraints が解決できない場合， SemVer 準拠でも解決できなくて，手動で解決する必要がある場合がほとんどだと思います)．なので，需要があまりなさそうというのが個人的な意見です．

私の主張は、
allow-newer は 単なる緊急回避でしかなく 極端にいえば絶対悪であること
SemVer が絶対だとすれば、 同一メジャーバージョンでマイナーバージョンが最低でも同一かそれ以上なら 互換性は保障されているということ。今回の例で言えば、 base == 3.* の依存だった場合は保障の対象外となること

限界だと言ったのは、SemVer自体には強制力がないので、100%の互換性を失ったとしても、マイナーバージョンのみの変更でよくてそれを(機械的に)調べるすべがない事

rely-on-version は allow-newer に上限を付けるもので ライブラリ作者が適切にバージョニングを行っていると仮定した場合安全になる ということ。 constraint フラグは あくまでも手動の解決であって、 制約自体は機械的に与えられたものではないこと

とは言ったものの

GHC is the de facto standard compiler

とあるようにGHCが事実上の標準だとするとそれの依存である baseパッケージがバージョニングを適切に行なってないならあまり効果はなさそうですね。

@yantene has joined the channel

GHCが事実上の標準だとするとそれの依存である baseパッケージがバージョニングを適切に行なってないならあまり効果はなさそうですね。

ちょっと勘違いしているように見えるんですが、base (そして大多数のライブラリ) は PVP versioning に従っています。本題とは関係ありませんが…… https://pvp.haskell.org/

勘違いかもしれませんが、PVPは、 Major1.Major2.Minor.Patch であって SemVer は Major.Minor.Patch ではないですかね？ まぁ SemVer ではMinor アップデートだった物がPVPとして解釈(Patchは実は必須ではなくて)されてMajor アップデートになるのは問題ないのですが、、、

その通りです。だから、base が 4.5 から 4.12 へ上がった時は Major が上がっていることになり、破壊的変更が許されます。base のバージョンの付け方は以下のようになっています。

1. GHC のバージョンが上がった時に base の Major バージョンも上げる。
2. Major バージョンを上げる時に、破壊的変更を計画的に行う。

さて、ここから本件と関連しているかもしれないんですが、base の破壊的変更は計画的に行われ極力少なくなるようになっているため base == 4.* というように指定する慣習があります。そのため、本件のような時に大抵は問題が起きないようになっています。あたかも Major.Minor.Patch.Patch であるかのように扱われているってことですね。ただ、本来なら base == 4.5.* と指定するのが厳密です。

そういうことなら、私のリサーチ不足だったということですね。。。 お恥かしい。 お二方には感謝です。

しかし、やっぱり バージョニングに頼らない互換性を見つける方法を見つけなくては。。。

豆知識: DerivingViaをStandaloneDerivingと組み合わせて使うときは、 deriving via Sum Int instance Monoid Counter のように書く

GHC本体から切り離されたGHC API。ランタイムがないため実行することはできないが、パースしたり型チェックしたりは出来る。外部のパッケージを扱うのも難しそうなので、結構用途は限られそう。
https://github.com/digital-asset/ghc-lib

igrepさんだったかが「 RebindableSyntax で (<<) の定義を上書きし忘れてハマった」と言っているのを見かけた記憶があるんですが、すごく良さそうな解決法がありました。 https://github.com/sleexyz/rebindable

なるほどRecordWildCardsで！
https://code.i-harness.com/en/q/b1f28b の応用ですね！

https://github.com/isovector/do-notation よりも安全で確実そう。

@shinichir0 has joined the channel

@keisuke.i has joined the channel

今年もvimconfにcfp出すぞ～

面白そうなんでこちらにも共有しちゃいますね。
https://www.reddit.com/r/haskell_jp/comments/apdtgf/experiment_ghc_bug_bounty/
:money_mouth_face: TLDR: Fix https://ghc.haskell.org/trac/ghc/ticket/15957, get $500 from Tsuru

2016年頃からやってるSYAKERAKEをYesod標準のインデント4からモダンなインデント2にほぼ全部置き換える作業やったら,
58 files changed, 3932 insertions(+), 3921 deletions(-)
になりました.
hindentのコードスタイルが気に入らないのでEmacsで手作業でやったら結構疲れました…
いい加減prettierみたいに https://github.com/lspitzner/brittany に巻かれるべきなんですかね…
でもあれまだHaskell IDE Engineから使うと壊れてますし…(自分のeglotとの相性が悪いだけかも)

もう遅いですが今回のように一気にやる目的なら、Haskell IDE Engineから使わずに普通にコマンドラインから brittany --write-mode inplace で呼べばよかったのではないかと。 :thinking_face:
私は普段はそうしてます。

Add Floskell and formatterProvider #1080
https://github.com/haskell/haskell-ide-engine/pull/1080

今日マージされたPRです。Floskell に期待。

あーそういえばbrittanyがちゃんとTemplate Haskellふんだんに使ったコードで動くかの検証すらやってないんでした

ソースコードにタブ文字が含まれてると警告する-Wtabsってもうデフォルトで有効だから書く必要無かったのか…
-Wall
-Wcompat
で十分そうですね

そういえば、Haskellとは何も関係ないpythonコミュニティでの話ですが、Raymon Hettingerさんが話してた Beyond PEP8の話を思い出してしまいました。 曰く、Googleはインデントが深くなりがちだが、どのようにしてPEP8の制限(?)である80文字を乗り越えたのか、彼らの答えは2文字インデントだった。 それを Raymonさんはそこまで好んでないよ、4文字にして改行の方が見やすいと思うね。 みたいな話でしたが、結局pythonでも2文字インデント化が進んでる気がするんですよね。。。何でしょうこの感じ

最悪Haskellだとまあ4文字でも良かったんですがhamletの分割はつらいしネストはHTMLなのでガンガン深くなっていくので厳しさがありました

斯く言う私も2文字インデント賛成派なので 2文字化が進むのは良いんですが、一度1文字インデントを試したのですが少なくとも私のHaskell力では理解できませんでした。。。

-Wall と -Wcompat を自分も付けてたんですが、ドキュメント見ると、-Wall で有効に ならない リストの中に、-Wcompat で有効になる警告が含まれてないってことは、-Wall は -Wcompat を内包する？
https://downloads.haskell.org/~ghc/8.6.3/docs/html/users_guide/using-warnings.html

これはドキュメントのミスだと思いますね． -Wall に -Wcompat は含まれません
https://github.com/ghc/ghc/blob/master/compiler/main/DynFlags.hs#L4733

実際-Wmissing-monadfail-instancesは-Wcompatを有効にしないと有効になりませんでしたしね…

個人的には，
• -Wall
• -Wcompat
• -Wredundant-constraints
• -Wincomplete-uni-patterns
• -Wpartial-fields
• -Wincomplete-record-updates
を通常は使っています． redundant-constraints は必要な場合もあるのでその場合モジュールレベルでオフにしてますね．

デニスさんのこれを上げるべき時ですね！
https://functor.tokyo/blog/2017-07-28-ghc-warnings-you-should-enable

that indicate potentially suspicious code が何を指してるのかが肝で、 -Wmissing-monad-fail は無視しても(さほど？？) 変なコードは生成されないって事なんでしょう。

お、もうfixedになってますね！ :money_with_wings:
bountyを始めてから3日と5時間ぐらいでしょうか。

Hspecでutf8の文字列をちゃんと表示したいなぁ．と思ったら，同じようなことを考えたひとがいたようで，とりあえずの対処法がしめされてました．
https://github.com/hspec/hspec/issues/384

http://hackage.haskell.org/package/hspec-expectations-pretty を参考に作ってみるのもいいかもしれませんね（もうメンテされてないパッケージなのが悩ましいですが :sweat: ）。
ちなみに、 http://hackage.haskell.org/package/pretty-simple も同じように日本語の表示をサポートしているので、作る場合は使ってみるといいかもしれません。

ghc-8以降でこのコードを`-O`オプション付きでコンパイルしようとするとコードサイズの爆発が起こり、`Simplifier ticks exhausted`と言われてコンパイルに失敗します。

面白いですね funcの中のxsを map (n+) [1..10] にするとこのエラーが吐かれない

@tribal_tech has joined the channel