単にScalazを使う側の話じゃなく
「Scalaz自体のライブラリ設計を今後どうするか？」
という話です。色々ぼんやりと考えていることがあるので、コミッターになったついでにちょっと書きだしてみる
- 末尾再帰になっていなくてStackoverflowする函数が大量にあるので(ある程度簡単に直せるなら)なおす
- その他細かいパフォーマンス改善できるところがあれば改善？
CojoinとCobindが分かれるの明らかにデメリットのほうが大きいので1つにするべき完了した- (個人的に結構以前から思ってたけど)tonyさんがissue上げたから、まぁそのうち改善されるでしょう
- https://github.com/scalaz/scalaz/issues/414
- lawとかtestとか、もうちょっと整理できる部分あるのでは
- テストもっと書いてもいいと思う
- パフォーマンスのテストも？
- lawが本体にあるのは分離できないのか・・・？*1
- 例えばBifoldable1とか、Arrowのサブクラスとか、(主にekmettライブラリにあるようなもので)入れようと思えば、もっとtypeclass追加できるもの大量にある
- 上記と完全に相反するが、ライブラリが大きすぎる問題
- もうちょっと多くの人*2に使ってもらわないとバグ見つからないのでは？
- 明らかに「誰かが使っていればこんなバグすぐ見つかるだろ！」というのがたまにあってあれ
- ドキュメント書けばもっと使ってもらえるのだろうか？
- 2.10の新機能使って色々便利に
- まだ2.9とcross buildしてるので、結構遠い未来の話？
- 2.9切り捨てたとしても、2.10の機能使って便利になる部分がほとんど思いつかない・・・
- UnzipはFunctorから導出できるのでは？ https://github.com/xuwei-k/scalaz/commit/c9e3a0b7
- デメリットも大きいけど、個人的にはkind projectorと-Yinfer-argument-types使えば、型書く場所大幅に減るのになぁーとか思う
- ここ https://github.com/scalaz/scalaz/blob/v7.0.2/core/src/main/scala/scalaz/package.scala#L17-L82 の部分を生成するsbtのコマンドあるのだけど、sbt consoleから表示させたあと、手動でコピペしてることにより更新忘れが多いので、もうちょっと自動化？
あと思いついたら随時書き足す
