向井です。


西川さんの発言のうち、
> そして、やっぱり上記のようになり、
> そうすると、継承ライクなことができないと図形の種類を増やすたびに
> Drawのメソッドを全て実装&管理する必要があるんですよねえ。

ということについて気になりました。
あるいはひょっとすると、 class でデフォルトの定義が可能なのですが、
それによって解決されないでしょうか。

実際的な例が思いつかなかったのですが、たとえばある一点を経由して2回動
く move2 という関数を定義するならば、
class Draw a where
  move :: Int -> Int -> a -> a
  move2 :: Int -> Int -> Int -> Int -> a -> a
  move2 dx1 dy1 dx2 dy2 = (move dx2 dy2) . (move dx1 dy1)

のように move2 を定義することができます。むろんインスタンス宣言時にオー
バーライドすることも可能です。

もちろん本質的な部分は実装されていないといけないのですが、それはどんな
言語でも同じことですよね。


もしくは move2 のような関数は class の外で書くこともできますよね。イン
デントが違うだけですけれど。その場合、 Draw のメソッドではありませんが、 
Draw な型ならなんでも受け入れることができるので、 Draw な型に共通する
関数を定義することができています。ただこの場合はオーバーライドはできま
せん。


外していたらすいません。


個人的な感覚ですし私も大してHaskell力が高いわけではないのですが、西川
さんは class という単語にひっかかっているのではないでしょうか。Haskell 
の型クラスは OOP のクラスとは別物で、いわゆるクラスは Haskell では個別
の型に相当すると考えた方が良いと思います。ですから Haskell で、まず 
class の構成を考えたりするということはないように思います。

個別の型と、それらの間でのデータの流れ(&関数の型)を考えていくうちに共
通化できそうなところをまとめて class 化する、というステップになるので
はないでしょうか。たけをさんの「インターフェースに近い」というのはそう
いう意味だと思います。

--
ML: haskell-jp / quickml.com
使い方: http://QuickML.com/