コードのベースは、もう4年くらい前 に書いたやつ持ってきただけ https://github.com/xuwei-k/sbt-class-diagram 使い方は これ http://www.graphviz.org/ をローカルにインストール(内部でこれをコマンドで呼び出すので必須) 本当は、dotというグラフの記述のための単純なテキストベースの言語から、pure javaでSVGに変換したかったのだけど、ライブラリなさそう(?)なので断念 手動でレンダリングすれば不可能ではないが、nodeの配置が*1汚くなるので、graphvizに頼ることに githubのREADMEに書いてあるとおりに、addSbtPluginをproject/plugin.sbtに追加と、build.sbtにsetting読み込ませる sbtのshellから、 classDiagram "クラス図に含めたいcla

まず、下記の10行程度のScalaコードをご覧ください sealed abstract class Foo[A, B] final case class X[A]() extends Foo[A, A] final case class Y[A, B](a: A, b: B) extends Foo[A, B] object Main { def hoge[F[_, _], A, B, C](foo: Foo[A, B], bar: F[A, C]): F[B, C] = foo match { case X() => bar case Y(a, b) => ??? // Yの場合のコードはどうでもいいので } } これは、コンパイルエラーになります(Scala2.11.1)。しかし、HaskellでGADTs使って同様のコード書くと、コンパイル通るらしいです。これの話をします。*1 Sc

できた気がする https://github.com/xuwei-k/twitterz/commit/b1d8201 https://github.com/xuwei-k/macro-annotation-sample/commit/47896fc1c0 単純にコンパニオンへのメソッド追加方法はなんとなくわかったけれど、InjectとCoproduct使ったパターンの単純化は難しそう。 そして、Scala2.11でも、未だにmacro annotationはcompiler pluginとしてしか提供されてないので、実際に使うのはかなり躊躇われる・・・。2.12では本体に入るのだろうか・・・？2.12でも本体には入らないことが、ほぼ決定したらしい。 http://d.hatena.ne.jp/xuwei/20140717/1405549390

Scaladays2014の写真がtwitter上で流れてきて「あーまたrunaroramaさん、Free Monadの話してるのかー」と思ったら、たしかにFree Monadの話もしてたみたいですが、それの発展形(?)的な感じで、Coproductや、Injectという型クラス(?)の話をしていたようです。 Woah, Coproducts (URL as replacement for transformer stacks look pretty cool! URL /cc @runarorama 2014-06-17 20:43:56 via Twitter Web Client それで、*1コードを読んでみたら、それなりにある程度理解できた気がするので、解説を書いてみます。*2 最初に断っておくと、タイトルに"Extensible Effects"と入れましたが、Extensibl

書いた https://github.com/xuwei-k/free-monad-java 以前紹介したhighj http://d.hatena.ne.jp/xuwei/20130501/1367395022 の仕組み使ったら、それほどキャスト使わずにできた。実装はScalaというかScalazのものを真似した。 しかし、Javaには末尾再帰最適化ないので、resumeがあれではダメで、自前でwhile使ったコードに書き直す必要がある。が、型合わせるのが辛くて一旦断念した。stack使わないように書き直せた https://github.com/xuwei-k/free-monad-java/commit/eab1b5d65bcc1d この仕組み真似したら、 C# とかで高階型を表現できたりしないのかなー、と一瞬思ったが、 C# というか .NET のVM詳しくないしよくわからない。ま

tototoshiさんの、これ Play 2.3 がリリースされたので変更点と試し方を説明します の便乗(?)的な感じで、なぜか自分もチュートリアルを書いてみます。普通に書いたら意味ないので、少しだけ変わった方法を書いてみます。 変わった方法とは、あえてtypesafe activatorを使わない方法を書きます。また、play2.3がどうやって成り立ってるのかを説明するのも兼ねて、activatorを使わないだけでなく、なんらかのテンプレート使ったりとか自動生成とかもせずに、一つずつ手作業でやって、最低限の構成のところまでだけを説明します。 なので、実用的なのかどうかはわかりません。慣れたら、それぞれみんなtypesafe activator使うなり、独自にテンプレート的なプロジェクトを用意しておくなり、giter8使うなりした方がいいかもしれません。 あと、先に完成後の最小限のplay

https://gist.github.com/xuwei-k/10002590 https://github.com/sbt/sbt/issues/1237 以前のsbtでは発生しなかった、ということから、明らかにsbtのバグだろーと思ったら、結局Scala側が悪い？という結論になったようですが https://issues.scala-lang.org/browse/SI-8486 そのバグ修正は、Scala 2.11.0のfinalには間に合わず、2.11.1 になるらしいです。 とりあえずバグの原因となったコミットのみをrevertしたversionが、sbt0.13.2-RC3としてリリースされました。 https://groups.google.com/d/msg/sbt-dev/adyQsDmlapQ/_RL46j6b_8QJ (sbt 0.13.2-RC2はリリースミスした

https://github.com/xuwei-k/play-json-extra 昨日の夜、数時間くらいで適当に作った。*1モチベーションとしては case class Foo(a: Int, b: String, c: List[String]) というようなcase classがあった場合、以下のようにReads*2を書くわけですが implicit val fooReads: Reads[Foo] = ( (__ \ "a").read[Int] and (__ \ "b").read[String] and (__ \ "c").read[List[String]] )(Foo.apply _) 上記のようにそのままFoo.applyに渡す場合、Int, String, List[String] の3つの型を書かないといけないのって面倒だと思いませんか？Fooの型から推論できそ

https://github.com/xuwei-k/httpz zというのは、特にいい名前思いつかなかったので、Scalaz的にとりあえずz付けておけばいいか、とかそういうノリです。 もともと何回かblogに書いたgithubのAPI clientライブラリ ghscala 0.2.5 リリース ScalaでOperational Monadを使って作ったAPI clientの内部実装の解説 を、抽象化というか汎用的にしていったら 「あれ、これgithub apiに依存する部分のほうが少ないし、切り離せるのでは？」 と思いつき、リポジトリ分けました。ghscalaは、httpzに依存する形にしました。 単なる「httpクライアントライブラリ」ではなく「APIクライアントライブラリを作るためのライブラリ」と言ったのは、そもそもこれのコア部分にはhttpのリクエストを実際に処理するコードがあ

飛び入りで、芸者東京さんの勉強会で、初心者にScalaを教えるという勉強会をしてきた時の話です http://partake.in/events/5c793335-6b54-43f5-ac6f-6234b0847308 事例1 sbt0.12.xのlauncherがインストールされていた ↓ それで、Play2.2やろうとすると、エラーでる(0.13のlauncherが必要) ↓ 初心者だとそのエラーの意味が、すぐにはわからない ↓ 「sbtどうやって入れた？いつ頃入れた？」 ↓ 「homebrewでいれました」 ↓ brew updateする ↓ sbt以外のものも大量にupdateされて、とても時間を消費する 事例2 sbtでOutOfMemoryエラーでる ↓ インストール方法によるが、少なくともhomebrewは、デフォルトではJVMのオプション設定されないらしい*1 ↓ 結論とし

以下のエントリ 「関数型Ruby」という病(6) - 関数合成と文脈、Proc#liftとProc#>=、そしてモナ に便乗して、(一部の例を)Scalaに翻訳してみるのと、ScalazのKleisliの話をします。Scalaや関数型に興味のない人は読まないほうがいいかもしれません。わざとMonadとかFunctorの用語も出します。また、もとのエントリの良し悪しとか、Rubyでああいうことをやることの是非などはあまり話しません、というか、それが主目的ではありません。とにかく便乗してScalaの話するのと、あえて元記事では避けている「関数型の用語を出した説明」を少しします。 まず、(nilはOptionを使うということにして)もとの>=の例を直訳すると以下 val f = (_: List[Int]).headOption val g = (_: Int) + 1 val h = (_:

公開されてました。たぶん1年くらいclosed sourceで開発されていたらしい？ https://github.com/lampepfl/dotty https://groups.google.com/d/topic/scala-internals/6HL6lVLI3bQ/discussion グラフみると、小田好先生がほぼ一人で開発してます。 https://github.com/lampepfl/dotty/graphs/contributors また、小田好先生が、scala本体に全くコミットしなくなった時期*1と完全に重なりますね。 (scala/scalaの最後のコミットが2012年10月31日。dottyの最初のコミットが2012年12月6日) https://github.com/scala/scala/commits?author=odersky https://git

Optionで説明してますが、ListやEitherでも同じはずです。とりあえずsequenceとjoinで、どんなにネストしていても、大概変換できるはず？ *1 *1:パフォーマンスとか、sequenceの呼び出し順による、細かい動作の違いとかはあれですが。もし似たような感じで困ったら、聞いて下さい

「再帰的implicit」という、普通にScala書いていたら遭遇しない話をします。なので、多くの人にとっては役に立たないだろうから、そういうのに興味のない人は読まないほうがいいです。 さて、これはekmett/freeの中にあるCofreeのEqのインスタンス(珈琲じゃなくて、Freeモナドの双対のCo Freeだよ！) *1 をScalaに翻訳していたとき(そしてScalazに入れようとした)に遭遇した話です。以下は翻訳元のHaskellコード instance (Eq (f (Cofree f a)), Eq a) => Eq (Cofree f a) where a :< as == b :< bs = a == b && as == bs https://github.com/ekmett/free/blob/v4.2/src/Control/Comonad/Cofree.hs#

まずいきなりコップ本第二版から引用(191ページ) 親クラスの具象メンバーをオーバーライドするすべてのメンバーにこの修飾子を付けなくてはならない。また、同じ名前の抽象メンバーを実装する場合、この修飾子はオプションとなるため、付けても付けなくてもよい。 この「付けても付けなくてもよい」についての話。「すでに実装があるメソッドをoverride」する場合は、必ずoverride修飾子は付けないといけない(コンパイルエラー)ので、その場合は関係ない。 あくまで「抽象メソッドをoverride」する場合に、付けるべきか？付けないべきか？の話。Scalaのversionによって違いは無いと思うけど、一応最新安定版の2.10.3という前提で。 「付けても付けなくてもよい」はある意味正しいです。しかし「ではどっちにするべきなのか？」「付けるのと付けないのとで、本当に違いがないのか？」 について言及してい

togetter 正規表現が構文として必要かどうかという話から プログラミング言語における正規表現リテラルの必要性について こういう収集がつかなそうな話題にあまり首突っ込むの好きじゃないんですが、blogに書いておけば、まぁそれはそれでScalaをあまり知らない人にとっては役に立つだろうから、丁寧に説明しておきましょう。 togetter(と、その他関連するtweet)はあまり読んでません。 とりあえずkazuhoさんがわかりやすくblogに要点まとめているので、まずそれに対応するかたちで説明しましょう。 また、大前提としてScalaに構文としての正規表現リテラルはありません。なので、以下の説明を読んで 「いや、それは単に苦しい言い訳だし、やはり正規表現リテラルは存在したほうがいいでしょ」 と思う人もいれば 「なるほど、このくらいの機能があれば、たしかにそれほど正規表現リテラル必要ないな」

以前「怖いScala」のときに紹介したように、すでに他の人が作ったクラス図が存在したり http://leifwarner.net/scalaz.svg また、自動で生成されるクラス図のサイトかなり昔に作ったこともありますが http://class-diagrams.herokuapp.com/scalaz.MonadPlus.svg https://github.com/xuwei-k/heroku-class-diagrams また別のもの作りました。 継承関係を線で結んで表すのもいいけど、いわゆる「ベン図(Venn diagram)」という、 論理和とか論理積を表すときによく使われるような、円が重なっていて集合の関係がわかりやすいやつ使ったらどうかな？と思って、svg-editというオンラインのSVGエディタ使って、地味に作ってた、結構時間かかった(なんて暇人なのでしょうか・・・)

Scalazネタです。しかもわりとマニアックな、Scalaz初心者向けではないネタかもしれません。前から書きたかったけど、良いサンプルが思いつかなくて躊躇してましたが、良いサンプルを見つけたのでKleisliとEndomorphicについて書きます。 Kleisliはともかく、Endomorphicは最近入ったので、日本語記事はおろか現時点では英語の解説もほとんど無いのではないかと思います。最近とはこのpull reqですが、7.1.0-M1からで、7.0.x系の最新版の7.0.4には入っていません。*1 さて前置きはこれくらいにして解説を始めます。まず、独習Scalazを引用します。 5日目 騎士の旅 case class KnightPos(c: Int, r: Int) { def move: List[KnightPos] = for { KnightPos(c2, r2) <-

scalacheckでバグ見つかる https://github.com/rickynils/scalacheck/issues/75 内容を一言でいうと 「OpitonのArbitraryの質が悪い」 もう少し詳しく説明すると 以下のテスト forAll { (x: Option[Int], y: Option[Int]) => x.isDefined == y.isDefined } が、必ず成功してしまう。というものです。 ここで絶妙なのが「すべてSome、またはすべてNoneしか発生しない」のではなく「SomeもNoneも発生するけど、発生する場合に必ず両方Someか両方Noneになる」*1というバグり方をしているということです。 そして、Scalazはかなり多くの部分でScalacheckを使っているので 「このScalacheckのバグ、Scalazに影響あるかな？」 と思って

runaroramaさんというScalazのFreeモナドを実装したり、まぁそのあたりに一番Scala界隈で詳しい有名な人が、 ScalaとScalaz使っての、Free、Yoneda、CoYonedaなどの解説blogを最近書いた↓ http://blog.higher-order.com/blog/2013/11/01/free-and-yoneda/ 以前ねこはるせんせーが、 ScalaでCoyoneda書いてて、うっ、ってなったのでScalaちゃんに代弁させたい。 2013-06-06 22:56:07 via Twitter for Android などと言って結局挫折していたけど、「CoYonedaが表現できるなら、Operational相当のこともできるのでは？」 と思い途中までやってみた、がsingleton関数の実装で行き詰まった・・・ものをとりあえず貼っておく。 やって