導入：フィールド名の「単相性」が引き起こす悩み
Haskellでプログラムを書いていると、異なるデータ型で「同じ名前のフィールド」を使おうとして、コンパイルエラーに悩まされたことはありませんか？例えば、User型にもProduct型にも「name」というフィールドを持たせたいのに、Haskellの伝統的な設計ではそれが許されません。これは「フィールド名の単相性」という性質によるものです。なぜこのような厳しい制約があるのか、どうすれば解決できるのかを解説します。
基礎知識：フィールド名は「関数」である
Haskellにおいて、データ型のフィールド定義（レコード構文）は、実は「アクセサ関数」を自動生成しています。
例えば、data User = User { name :: String } と書くと、コンパイラは自動的に name :: User -> String という関数を作ります。
ここで重要なのは、Haskellの関数は「引数の型」が一つに決まっている必要があるという点です。もし別のデータ型でも name という名前を使ってしまうと、コンパイラは「nameという関数は、Userを受け取るのか、それとも別の型を受け取るのか？」と混乱してしまいます。これが「名前の衝突」の正体です。
実装と解決策：DuplicateRecordFields拡張
この問題を解決する最も現代的で推奨される方法は、言語拡張である「DuplicateRecordFields」を使用することです。これを有効にすると、コンパイラは文脈から「どの型のフィールドを指しているか」を推論してくれるようになります。
サンプルプログラム：DuplicateRecordFieldsを使ってみよう
以下のコードをコピーして、GHCiやファイルで実行してみてください。最初の行のプラグマが重要です。
{-# LANGUAGE DuplicateRecordFields #-}
— 名前が同じ「name」フィールドを持つ二つの型を定義
data User = User { name :: String, id :: Int } deriving Show
data Product = Product { name :: String, price :: Int } deriving Show
main :: IO ()
main = do
let user = User { name = “Haskell太郎”, id = 1 }
let product = Product { name = “関数型プログラミング入門”, price = 3000 }
— DuplicateRecordFieldsがあれば、同じ「name」でも文脈に応じて正しく扱われます
putStrLn $ “ユーザー名: ” ++ name user
putStrLn $ “商品名: ” ++ name product
応用・注意点：現場での立ち回り
DuplicateRecordFieldsは非常に便利ですが、使いすぎには注意が必要です。同じ名前のフィールドが多用されると、型推論がうまくいかずに「どの型のnameなのか不明です（Ambiguous）」というエラーが発生することがあります。その場合は、型注釈（name user :: String のように）を明示的に記述することで回避可能です。
また、古いライブラリなどでは、フィールド名の頭に型名の略称をつける（例：userName, productName）という慣習も根強く残っています。プロジェクトの規模やチームのルールに合わせて、これらの方針を使い分けるのが「Haskellらしい」設計の第一歩です。
コメント