haskell-jp / random #20

依存性については、実はLens APIを公開するだけだったらlensパッケージに依存する必要はなかったり。

You can even define lenses without incurring a dependency on the lens library

http://hackage.haskell.org/package/lens-tutorial-1.0.3/docs/Control-Lens-Tutorial.html

ただ、これをやるためにtype MyLens = ...とか定義し始めると "DO NOT REPEAT YOUSELF!!!!!!" ってなるんですけど、どうすればいいんだろう

makeLenses をlens（やmicrolensなど）に依存しないでやるのを自動化できればいいって話ですよね。
THがなかったころのEtaでは、GHCに -ddump-splice させて出てきたものをコピペしろ、なんて言われてたなぁ（めんどい）

最近はlensに依存したパッケージがかなり多くなったので、個人的にはライブラリでもあまり気にせずlensに依存してしまうこともあります。

ああ、その問題もありますね……私が言おうとしたのは、 point :: Lens' Atom Point ではなく point :: Functor f => (Point -> f Point) -> Atom -> f Atom みたいなシグネチャを大量に書く羽目になると可読性がアレなので、結局Lensと同じtype宣言を各プロジェクトでやる羽目になってしまう問題です。結局lens依存しちゃっていいやってなるかもしれませんね

型シノニム程度ならコピペしちゃうかな。。。この間実際 Getting と view がほしくなってしましたし。

lens、使いたくなったら使っちゃう派！
（不用意には使わないようにしてるけど、便利すぎる）

ライブラリでlensを使うことの是非については、ネストしたデータ構造なら推奨、コンテナに入れて処理しないような単なるパラメータなら非推奨という立場です

@mitsugk has joined the channel

地味な内容ですが、広く影響のある提案が、ghc-proposalsに提案されています。
カインド（種）の仕様から、'*'の表記を削除してしまおうというものです。
今の期間内であれば、同意・反対などの意見や、改善提案などが可能です:slightly_smiling_face:
https://github.com/ghc-proposals/ghc-proposals/pull/143

upvoteしました！

8年かけてやるという気の長い話しです。
今なら止める側にも倒せますし、進める側にも倒せます。
何か新しい観点に気づいたら教えてあげてください:slightly_smiling_face::haskell:

全く中身を読んでないので書いてあったら申し訳ないんですが、これはhaskell primeにはプロポーサル出さないんですかね？

ghc-proposalsの方が進めば、いずれ、Haskell primeの方にも提案されるかなぁと思います。
ちなみに、Haskell primeの方は、実装されて使用された実績のある仕様が、提案対象になっていたと思います。
ただ最近は、Haskell primeの方は動きが停滞してますね。 2020年直前になると活発化するのかな？

今日はHaskell Dayの日程候補挙げをやるぞい :shikamaro_kun:

Type の方が確かに説明しやすそうですね！私はupvoteしました。

あと`*`だと、将来的にDependent Haskellの世代に、-XTypeOperatorsと見栄えが衝突するのが痛いんですよね。
既存の説明文書が古くなってしまうことや、ライブラリの更新負担が発生することとのトレードオフですね。

あ、これreddit でも話題になってましたね。 私的には、* 種は無くさないほうに一票という感じです。 特に理論的な根拠や理由がある訳では有りませんが、 強いて言うなら、 Erik Meijerがいつか語ってたように、言語機能(と言って良いのか微妙ですが)を無くす事は言語を強化する事にならない。 (言っていた文脈は全く別で私が勝手にその部分だけ引用してますが) という感じでしょうか。

確かghcidを解説している記事にあったかと思うのですが、型わからなくなったらとりあえず hoge :: ()と注釈加えたり () <- とパターンマッチしてみたりしてわざとコンパイルエラー起こすの、確かに有効ですね！

type holeと比べてどうなんだろう。

関連提案(#146)も出てきたので、まだまだ紆余曲折ありそうですね^^

書くぞ～

そもそもGHC 8.6でこれが実装されるのが，ホットになってる要因なんですかね
https://github.com/ghc-proposals/ghc-proposals/pull/83

からみ具合を追いきれてないのですが、TypeInType関連で、激しく手を入れている関係なのでしょうね、、、おそらく。
型とかカインド関連で、過激にいろんな試行をしてるようですが、本当は、言語オプションでうまくやりくりできるはずが、考慮もれがあって、workaroundを検討中という感じのようです。

-XStarIsType拡張でうまく行くはずが、TypeOperatorsと競合して、他世代のライブラリの保守を考えると、いろいろと発散しているようです。 が、 で抑えこもうとしている感じでしょうか。
まだ、追いきれてません。（というか、各々の理解がまだ不十分で、、、）:sweat_smile:

最近、 Menoh というDNN推論ライブラリ https://research.preferred.jp/2018/06/menoh-release/ の Haskell binding を作ってみたので、ご参考までに。
http://hackage.haskell.org/package/menoh
命令的なAPIを素朴にラップしただけで、特に関数的なインターフェースは用意できていないですが。

@kanjiro_f has joined the channel

@seiji3030 has joined the channel

現状の個人的な理解を， https://www.reddit.com/r/haskell_jp/comments/8t8p4j/typeoperators_nostaristype%E3%81%AE%E5%BB%B6%E6%9C%9F%E3%81%AE%E6%8F%90%E6%A1%88/ にて書きました

複雑な関係がまとまってて分かりやすくて有り難いです！
本題から外れますが１点だけ。 ghcの8.6のアルファ版は、これからリリースされる予定です。 ちょうど、8.6アルファのbranchが切られて、整備されている最中のようです。（この関連の修正を急ピッチで反映させるのかもしれません。）

なるほど、まだブランチが切られただけなんですね。ありがとうございます、該当部分修正しときます

GHCへの改善提案（ghc-proposals）について、現時点で、steering-committeeに提案されている案件の検討ステータス一覧です。
GitHub上でのghc-proposalsの仕組みが出来てから、提案がかなり活況になっています。
結構な数が並走して流れていくので、何かあればGitHub上でツッコんでみてください:haskell:

https://mail.haskell.org/pipermail/ghc-steering-committee/2018-June/000634.html

@canneryrow2016 has joined the channel

直接Haskellと関係なくて申し訳ないんですが、みなさんRedditの新しいバージョンって見えてますかね。
https://www.reddit.com/r/haskell_jp/
古いバージョンで使っていたテーマが無効になってしまったのでせっかくなんでHaskell-jpのウェブサイトと同じような色にしてみました。

Pandocに目次を自動生成する--tocオプションがあるから楽勝……と思ったんですけど --standaloneと一緒に指定しないと無効っぽいですね。自力でPandocの中間データを舐める感じで行きます https://github.com/haskell-jp/blog/issues/117

@ghasshee has joined the channel

僕の本もPandocで書いただから、この前に結構調べたけど、結果的に、個別の文章はPandocにやらせて、目次とカバーなどのページはやはりTexでやるのが楽だと思う。
Pandocはスイッチ少ないね

https://cosmius.bitbucket.io/tkhe/
今書いてるHaskellの本です、無料ダウンロードできるよ ヽ(^。^)ノ

間違ったとこなどがあったら是非ともご指摘してください

現状では、基礎的な部分のみなので、最近Haskellを勉強し始めた方にお勧めです

reStructuredTextだと、`.. contents::`ディレクティブで目次を生成してくれるのですが、markdownだとラクな手がなさそうですね、、、

どうもです、色々試してみます！

@sora42024 has joined the channel

Pandocの自動生成,日本語を食わせると不正なリンクを作るか,英語だけに切り詰めて重複リンクを作ってしまうか
みたいな問題があるのでパーセントエンコーディングする修正しないと正しいリンクは作れなさそうです

久々にHaskellでNewline-deimited JSONでも読んでみるか…と思ってPipesを使おうとしたら意外と`readFile`的な関数がなくて、このコメントに行き当たりました。bracketで囲むパターンじゃ駄目なのかなあ

The main reason is that I feel that pipes is the wrong abstraction for resource-safety. I feel that a more restricted abstraction (like Shell from turtle, for example) is necessary to get predictable resource management guarantees and a nice user experience.

@insight.insight has joined the channel

ですよね。 結局 パース出来ないだの、ファイル(コンソールを含む)を開けないだのは出る訳なんだから、 withFile みたいな(中身は bracket でしょうけど)関数くらい用意しても良いと思います。

実務上不便ですよねー。結局、面倒なのでio-streamsにしました。

リソース管理に対応したライブラリってconduit(かdrinkery)くらいしかないんですよね…大事なところなのに

@ion.alkali has joined the channel