先日、自分が書いた kmizu.hatenablog.com に対する反応として、「Javaのようなまがい物のジェネリクスと比較するのは適切でない」「Javaのジェネリクスと比較するのは適切でない」（おそらくC#や(C++等（2017/09/24追記）)の言語と比較して）といった コメントをいくつか見かけました（はてなブックマークコメントやツイッターなどで）。しかし、ここでは、そのような言説こそが適切でない、ということを言いたいです。なお、methane氏との 対話については既に終わったものなので、それとは関係ありません。 そもそも、Javaジェネリクスは、静的型付き関数型言語で既に一般的であったパラメータ多相をJavaに追加する目的で導入されました（C++テンプレートのようなものをJavaに追加するためだと思っている人がいるかもしれませんが、それは実態にあっていません）。実際、Java

先日自分がGoについてつぶやいたものが、id:methaneさんに捕捉されていて、それに対する反論記事 methane.hatenablog.jp があがっていたので、それに対する所感を書いてみました。（2017/09/22 追記）：cocoatomoさんから指摘があったのですが、引用元は全て id:methane さんの、上記ブログエントリの文章です。雑多な感想に関して反応しているものではないです。 前置き Goや言語批判に関するスタンスを誤解されると嬉しくないので、最初に書いておきます。 Goの言語仕様はあまり好きではないけど、Goユーザーを見下したり、馬鹿だとかそういう風には思っていない 言語仕様批判とユーザー批判は別の話ですが、しばしばいっしょくたにされて、糞言語Xを使うユーザは糞だ、みたいな主張がされることがあるので、 そういう意図はないという表明です。 Goユーザーの中で、ジェ

昨日、 kmizu.hatenablog.com という記事を書いたわけだが、その後、今日、型クラスに関する議論が一部で（？）盛り上がっているようだ。それは型クラスじゃなくても実現できるのでは、いや、やっぱりインタフェースのようなものと思っていいのでは、などなど。 今回の記事では、型クラスじゃないと実現が著しく困難であると思われる 使い方について書くことにする。 まず、前の記事では、Orderingの使い方を通して、型クラスの単純な使い方について説明したのであった。単純なオブジェクトの場合はそれでもいいが、より複雑なオブジェクトをOrderingを使ってソートしたい場合、前回の記事のようなやり方だけでは難しいことがある。 一例として、(A, B)というタプル型、つまり、A型の要素とB型の要素からなるペアを比較して、ソートしたいという要求を考える（実際には、標準ライブラリでタプル型の比較が提

追記：Twitterで、「それって、言語マニアにしかできない技のような気が」という指摘を受けました。自分としては一般的に適用可能な話だと思っていますが、あるいは自分の感性が著しくずれているのかもしれません。その辺承知の上でお読みください。 Scalaは習得が難しい言語だ、とよく言われます。また、実際問題として、Scalaの言語仕様の全体はそれなりに複雑でもあります。しかし、それはたとえばJavaでも言語仕様の全体像を把握するのは難しい話であり、Scalaに限った話ではありません。にも関わらず、Scalaの習得が難しいとよく言われるのはプログラミング言語の学習モデルが誤っているからではないかと最近思うようになりました。そこで、Scala（や他の言語も含めて）のコストを下げるために必要な心得についてちょっと書いてみます。 Scalaはオブジェクト指向言語である これは、Scalaは関数型プログ

表題の通りです。とりあえず、Kotlin版とScala版のコード貼ります。 gist.github.com gist.github.com これらのコードでは、両方とも明示的なダウンキャストやその他の抜け穴を使っていないので、実行しても決してClassCastExceptionが起きてはいけないのですが、実際に実行するとClassCastExceptionが起きてしまいます。 さて、これはコンパイラの実装のバグでもあり、言語仕様のバグでもあるのですが、ちょっと理由を説明してみたいと思います。 class B extends A with Comparable[B] { def compareTo(b: B): Int = 0 } 上記のコードをコンパイルすると、下記のコードが生成されます。ここで、int compareTo(java.lang.Object)というメソッドが 定義されている

タイトルは、斜め読み論文紹介ですが、 togetter.com ↑の辺の企画の亜種だと思ってください。気が向いたらときどき書いていこうと思います。第一回は、From APIs to Languages: Generalising Method Namesです*1。 唐突ですが、Smalltalkという言語があります。オブジェクト指向を発明したとかいう言語ですが（テキトーな言い方だ…）ここでは全く関係がないのでおいておきます。Smalltalkの系列の言語は、メソッド名の構成に関してやや特殊なところがあります。それは、メソッド名をいくつかの断片に分けて記述するところです。 たとえば、辞書に値を突っ込むには、次のようにします： kmizu := Dictionary new. kmizu at:'Age' put:'32'. kmizu at:'Sex' put:'Male'. kmizu a

このエントリは、これまで自分がさんざんTwitterで書いてきたことですし、Martin Odersky教授へのインタビュー www.artima.com でおおむね語られていることでもあります。ただ、この辺の事情についてあまり詳しくない方も居るようなので、上記インタビューの引用を交えて、JavaにGenericsが入るに至った経緯や関連して活躍した人物についても書いてみようと思います。 事の始まりは1995年にJavaが発表されたことでした。これに触発された、Philip Wadler先生（世界的に有名なコンピュータ科学者）、Martin Odersky先生と同じ研究室に居た助手さん？がこれでなんかやってみないかと煽ったらしく、翌年の1996年には、JavaにGenericsや高階関数、ADTなど関数型プログラミング言語の機能を入れ込んだPizza言語をMartin Odersky先生が

タイトルは煽りではありません。もちろん、Scalaを実用的に使う上では「直接」Genericsを扱えないのは困ります。しかし、記述の冗長ささえ我慢すればGenericsのほぼ全ての機能をAbstract Type Membersによって表現できます。このことを指して、GenericsはAbstract Type Membersでエンコードできると言ったりします。とりあえずコード出せやといわれそうなので、実際のコードを貼りつけてみます。 gist.github.com このコードでは、不変Listと、その上の高階関数mapとforeachをGenericsなしで構築しています。 ポイント： Genericな型 => Abstract Type Memberを持った型 Genericなメソッド => Abstract Type Memberとメソッドを持った型 関数 => Abstract T

最近、ネット上でカリー化に関する記事を読んでいると、特にGroovy界隈でカリー化に関して誤解がまかり通っているようなので(特に実用的なGroovy: カレー化クロージャーによるファンクショナル・プログラミングはひどい。そもそも、Groovyの標準ライブラリ自体がカリー化を行うための関数ではないものにcurryとか付けてるから仕方無いのかもしれんが)、一言言っておく。 カリー化というのは、Groovyで言うと、 def add = {x, y -> x + y} のように、xとyという複数の引数を取って値を返す関数を def add = {x -> {y -> x + y}} //間違ってパースできないコードになっていたので修正(12/17) のように、一つの引数xをとって、「yを引数にとって値を返す関数」を値として返すような関数に変換すること、あるいは最初からそのように表現することを言う

参考：ジェネリクスによるVisitorパターン拡張の考察 Scalaは元々は、複数の関連しあったクラス群をうまく再利用可能なことにすることも視野にいれていただけあって、こういうのを(オブジェクト指向モデルの中で)簡単に取り扱えます。 trait VisitorsBase {self => trait Node { def accept(v: V) } case class Add(l: Node, r: Node) extends Node { def accept(v: V) { v.visit(this) } } case class Sub(l: Node, r: Node) extends Node { def accept(v: V) { v.visit(this) } } case class Value(value: Int) extends Node { def accep

JavaとScalaとC#のジェネリクスは、いずれも継承を持ったオブジェクト指向言語においてParametric Polymorphismを実現するための手段であり、それぞれ異なった特性を持っている。というわけで、それぞれの言語においてジェネリクスがどのようにサポートされているかを比較した表を用意してみた。後で気が向いたら、各項目の説明を追加するかも。 Java(5.0以降) Scala C#(4.0) ジェネリックなクラス ○ ○ ○ ジェネリックなメソッド ○ ○ ○ 型パラメータの上限 ○ ○ ○ 型パラメータの下限 × ○ × 型パラメータの推論 ○ ○ ○ 全ての型のサブタイプ(ScalaにおけるNothing) × ○ × definition-site variance × ○ ○ use-site variance ○(Wildcard) ○(Existential Typ

参考：id:soutaroは就職活動中です 実はいわゆるリアルの方での就職活動はようやく始めたところで、既に遅いのではという気がしないのでもないのですが、先輩のid:soutaroさんもそれがきっかけで就職(というか起業？)できたようなので、id:soutaroさんにならって、書いてみることにします。 水島宏太(id:kmizushima,Twitter kmizu)は現在就職活動中です。2011年3月に博士後期課程修了見込みで、来年度以降の職を探しています。水島がどういう人間か興味あるので面接してみようという方がいらっしゃいましたら、ご連絡をいただければ幸いです。 メールアドレスは、 mizukota{at}gmail.com です({at}を@に置き換えてください)。 2011年3月に博士(工学)の学位を取得して、筑波大学大学院システム情報工学研究科博士後期課程を修了する予定です。 プ

Java変態文法最速マスターなんてのがかなりブクマされてるみたいだが、変態さならJavaなんてScalaの足元にも及ばないぜ！！ということで、Scala版を書いてみました。しかし、実はあまり変態ではないかもしれません。元ネタと違って、これを読めば何かがわかる、という意味の実用性はあまり無いでしょう。 implicit conversion編 基本 Scalaのimplicit conversionは使いようによってはScalaの強力な型システムを台無しにしてしまう力を持っています。たとえば、 implicit def string2int(x: String): Int = Integer.parseInt(x) というimplicit conversionを定義してやると、"300" / 3が100になるなどというキモい挙動を実現することができます。また、さらにカスタマイズして、16進数

特に説明はしません。IOモナドなんて言っても、別に難しいことではなく、結局やってる事はこんな感じですというのがわかってもらえれば。もちろん、実際のHaskell処理系がこのような実装になっているという意味ではなく、JavaプログラマはこのようなイメージでIOモナドを理解すればいいのではないかという提案に過ぎないので、その点は注意してください。 package iomonad; import java.util.Scanner; public class IOLib { enum Unit{VALUE};//一つしか値を持たない型 public static Unit UNIT = Unit.VALUE; /** * HaskellのIO 'a型に相当 */ public interface IO<A> { /** * IOを「実行」して、A型の値を得る処理． * ユーザが直接呼び出すと参照

最近、こことかこことかこことかで、Javaの検査例外に関する議論が話題になっているようだ。検査例外に関しては、自分も以前から一言言いたいと思っていたので、ちょっと書いてみることにする。とはいえ、他の人と同じ論点で書いてもつまらんので、ここではちょっと違った視点から。 まず、意識しなければいけないのは、 検査例外という概念そのものが良くない Javaの検査例外の仕様、つまり検査例外の特定の実装がマズい この二つを区別すべきだということだ。実用的に使われている言語で検査例外を実装しているのがJavaしか実質存在しないこともあって、この二つの区別が曖昧になっている場合が多いように思う*1。 このエントリでは、前者についてはとりあえず置いておいて、後者、つまり、Javaの(現在の)検査例外の仕様がイケてない点について述べたいと思う。 例外の型を透過的に扱う手段が存在しない 文だけだとわかりにくいと

Scalaでthis.typeとcloneを組み合わせたときに起こる問題について、@cocoa_rutoさんの一連のポストが興味深かったので引用してみる： Scalaでthis.typeなフィールドを持つオブジェクトをcloneしてもそのフィールドは元のオブジェクトを差す。クラスの型メンバも Outer.this.type#Innerという型を持つのでInnerをフィールドとして持つOuterをcloneすると悲しいことになる。 http://twitter.com/cocoa_ruto/status/6399352940 cloneした後で newOuter.inner = new newOuter.Innerとやる。Innerのサブクラスを作っている場合は、innerの型をOuter#Innerと明示して、Innerに create(o: Outer): Outer#Innerを用意す

scala.NothingはScalaのクラス階層における、「一番下」に位置するクラスで全ての型のサブタイプになるが、これが何のためにあるかという点でつまづく人が時々居るようだ。というわけで、scala.Nothingがあると何が嬉しいのかという点をちょっと説明してみようと思う。 例外やエラーを投げる式のような、戻ってこない計算の型として使う たとえば、次のような、階乗を計算する関数factorialを考えてみよう。factorialはnの階乗を計算する関数で、nを引数に取りnの階乗を計算して返す。また、nは0以上の整数でなければならないものとし、0未満の値が引数として渡されたらIllegalArgumentExceptionを投げるものとする。このとき、factorialの定義は、たとえば def factorial(n: Int): Int = { if(n < 0) throw ne

Scalaでは普通に副作用が使えるので、Stateモナドみたいなのの出番はまず無いんだけど、最近Haskellの各種モナドをScalaで書き直すのがマイブーム(死語)なのでやってみた。今回も、All About MonadsのState monadの解説ページの実装丸写しで大した工夫も無いけど、まあそれはそれで。しかし、こういう事毎回やるたびに思うんだけど、やはり型推論がHaskellに比べて弱いのは痛いなあと。無駄な型注釈が必要になる場面がたびたびあるし。 class State[S, A](x: S => (A, S)) { val runState = x def flatMap[B](f: A => State[S, B]): State[S, B] = { new State(s => { val (v, s_) = x(s); f(v).runState(s_) }) } de

.@kmizu のScalaのサンプルコードが、まるでPerlのコードのようにイミフだ... http://d.hatena.ne.jp/kmizushima/20090925/1253890980 *P3 http://twitter.com/t_yano/statuses/4370238778 よーし。じゃあ、Javaなら大丈夫ですよね？*1というわけでJavaで書いてみた。…………非常にしんどかった。なんか本当に人間型推論器になった気分。せっかく作ったので一応貼っておくけど、読む気がしないことうけあいのコードになったと思う(ライブラリ側はさほどではないけど、利用側が…)。 import java.util.*; import static java.lang.Integer.*; import static java.lang.Character.*; public class Co

(snip) 今まで、Java では型パラメータは単純に Object になるものだと思っていたんだけど、もしかして extends 使うと一番左側のクラスになる・・・？ http://d.hatena.ne.jp/bleis-tift/20090731/1249037236 ちょっと気になったので、JLS(3rd Edition)を調べてみました。すると、4.6 Type Erasureのところに、こんな記述が。 (snip) The erasure of a type variable (§4.4) is the erasure of its leftmost bound. http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.6 型パラメータでextends使って(複数の)境界を指定した場合、