haskell-jp / random #54

@tmym has joined the channel
Internal(s)っぽいモジュールはそれが何のためにexposeされるかはパッケージ毎に提供者の意図によって異なるからです.
たとえば「テスト等の事情でexposeされているだけ」なのと「(速度のためなどで)内部構造にアクセスしたい人がいるかもでexposeしてる」では,
パッケージ提供者だけが使うのかパッケージ利用者も使うのかが違ってきます.
ここが違うと検索にひっかかって欲しいかどうかも異なってくるのではないでしょうか.
パッケージ利用者が検索するにしても、Hoogleで検索しますかね?わざわざInternalを使おうとするユーザーは直接パッケージのドキュメントを読みませんか?
そしていずれにしてもあくまで「デフォルトでは」という話ですし、わかりやすいところにチェックボックスを一つ置くなりして誘導すればいいでしょうし。
まさに同じ話をしているissueがあった https://github.com/ndmitchell/hoogle/issues/246
隠すのではなく検索結果での表示順を下げる、と
どうやって対応するんですかね.「それがInternal(s)相当である」ことをHoogle側が判断するのは不可能ですよね.
ネーミングは慣習でしかないし,Internal/Internalsで既にユレがあります.
やるなら「このモジュールはそういうモジュールである」ことを示す何かが入ってないと禍根を残すと思いますが.
「Internal(s)という名前を付ける」という慣習は十分に普及しているので、名前で特別扱いするので十分かと思います。
もちろん厳密な解ではありませんが、(実際私自身 PublicForTesting なんて名前を付けたことがありますし)厳密でなければならないという話ではないと思います。
慣習が広まっている以上、わざわざ公開しているmoduleにInternalなんて名前を含めるのは希でしょうし。
Testing時だけ全部Exposeされたものとして扱えるような言語機能があると嬉しそうですが…
それはそれで欲しいですね.
Internalなモジュールの関数を「とりあえず今は呼ばないとやりたいこと実現できねえ!次のバージョンアップの前にpull request出せば良い!」って呼び出すこと結構あるので検索に出ないのはちょっと困りますね
検索結果の順位を下げるのはどうでしょう?
まあそれなら別に問題はだいたいなさそうですね
それこそ、なんちゃらっていう正規表現(?)にマッチした・しないモジュールは除外みたいなオプションがあればいいってことなんですかね? そういう機能要望とかはありそうですけどどうなんですかね。
順位を下げる方法だとサーバサイドの修正が必要ですけどInternalもう一切見たくないって人向けには検索画面にフロントエンドでオプションとして追加できそうですね
@hongminhee has joined the channel
Takatoshi Ichikawa
@Takatoshi Ichikawa has joined the channel
Haskellで書かれたFRPライブラリー、Yampa製らしい。
https://linearity.itch.io/peoplemon
名指しは控えますがこういうのもっとこっちにも共有して頂けるとありがたい。
こっち中心に見てる人もいるようなので!
@ has joined the channel
(ツク)ヨミ
@(ツク)ヨミ has joined the channel
Hi, didn't find a #jobs channel, so posting here. I'm looking to hire a PureScript/Haskell intern or part-time developer, details at https://gist.github.com/rnons/c04acc1f4db94ffee890f425acfb3dc4, thanks
こっそりextensible-0.6をリリースしました。barbiesと互換になったので活用の機会も増えるはず http://hackage.haskell.org/package/extensible-0.6
HKDが着せ替え人形のイメージでbarbieって名前なんですね :eyes:
@karika has joined the channel
お気づきですか :smirk:
対応しなきゃ、extensible-0.6
extensible-0.6, 早速今日用事が出てきたので使います :muscle:
Petri Kivikangas
@Petri Kivikangas has joined the channel
@kanimum has joined the channel
http://hackage.haskell.org/package/winery-1.1.2 シリアライゼーションライブラリwinery-1.1.2をリリースしました。readFileSerialiseとencodeTermを追加しただけのささやかなアップデートです(もちろんGHC 8.8は対応済み)
チラ裏ですけど、最近はやりのHKDを使って、Redux的な事ができるんじゃないかなあと考えたりした。
UIの状態をJSONで持っているために、更新フック等のコードをある程度自動生成できる事が、Reduxのコア技術の一つだと思っています。
似たような事をHaskellでやろうとするとHKDになるのかなと
もしかすると既にやってる人いるかも
2年前実験的なGUIライブラリを作っていたのを思い出しました。UIを表すDSLから型族で状態を導出するという仕組みで、その一部で拡張可能レコードのHKD能力を利用していましたが、全部HKDに統一するというアプローチもできるかもしれません 
なるほど、かなりイメージに近い感じがします。
@sumitek has joined the channel
@ has joined the channel
@ has joined the channel
@coord.e has joined the channel
@haskellheads has joined the channel
@ has joined the channel
@ has joined the channel
@ has joined the channel
@penguin has joined the channel
@ほげやま has joined the channel
@ has joined the channel
@show has joined the channel
@kazup0n has joined the channel
マルチスレッド向けのRTS( -threaded で有効になるやつ)がデフォルトで有効になる提案がacceptされました。
https://github.com/ghc-proposals/ghc-proposals/pull/240
「実は -threaded が必要なライブラリーを使っていたけど有効にするのを忘れてたので全然うまく動かない」みたいなケースを未然に防げそうです(経験者談)。
型レベルプログラミングを型レベルでテストする。should-not-typecheckパッケージとはまた違った使い心地で面白そう。
https://github.com/sheyll/type-spec