トップ «前の日記(2006-12-05) 最新 次の日記(2006-12-07)» 月表示 編集

日々の流転


2006-12-06 [長年日記]

λ. newtypeはHaskellの仕様に不要では?

向井さんのdataとnewtypeのちがいのわかりやすい例というエントリへの便乗なのだけど、newtypeはHaskellの仕様に不要だったのではないかと私は思っている。

向井さんの例でいうと「data T2 = T2 !Int」と「newtype T3 = T3 Int」の表す領域は全く同じである。違うのは「メモリ上のデータの表現の効率」と「パターンマッチの意味」だけ。しかし、この場合にはメモリ上のデータ表現はコンパイラによる最適化が可能であろうし、そのような最適化はプログラマにとって十分透過的*1だろうから、プログラマがメモリ上の表現を明示する意味はあまり無いはず。また、newtypeで宣言した場合のパターンマッチの意味については、dataで宣言した場合でも遅延パターンを用いれば実現できる。

仮にHaskellの仕様にnewtypeがなくても困ることはないと思うし、newtypeの存在はHaskellを仕様を無駄に複雑化しているだけではないか?

【2012年7月追記】

ただ、newtypeを単純に無くしてしまって、同等なdata宣言を用いることにすると、newtypeと同じ効果を実現するために、正格性フラグや遅延パターンなど、「既存の型の別名をつける」という典型的なユースケースに比べてややこし過ぎる機能を利用しなくてはならなくなってしまうので、最近は、単純なことを単純にすませるための妥協として、newtypeはあっても良いかと思っている。

関連

Tags: haskell

*1 「透過的」の意味については <URL:http://www.ipl.t.u-tokyo.ac.jp/~onoue/pub/drthesis02.pdf> を参照。

本日のツッコミ(全3件) [ツッコミを入れる]
ψ 向井 (2006-12-06 22:22)

じつは私も不要だと思っています。それはコンパイラが最適化で頑張ることなんじゃないの、と。<br>例のエントリは、そこのところをはっきりさせるために「ほらぜんぜん違いないんですよ」というのを言おうと思ったら、パターンマッチで違いのあるケースを発見してしまった困ったなあ、という感じであります。

ψ 山本和彦 (2012-07-19 10:02)

プラグまでもよかったんじゃないですかね。

ψ さかい (2012-07-19 14:24)

dataとnewtypeには意味上の違いがあるので、今と同様の分け方なら、プラグマではなく言語内での記述であるべきだと思っています。<br>UNPACK, INLINE, SPECIALIZE 等、意味が変わらず効率だけが変わるものについては、プラグマで良いと思うのですが。