HListパッケージは、現在では古代のHaskell テクノロジーに基づいています。簡単な質問は次のとおりです: 過去 8 年間の Haskell/GHC 開発のすべての素晴らしい新機能を考えると、「最新の」HList は非常に異なる方法で構築されるでしょうか? ここでの答えはnoである可能性が高いことを認識しています。HList の特定のケースでは、当時使用されていたテクノロジが依然として最も洗練されたソリューションを生成します。
拡張可能なレコードページに記載されている項目の多くを読みましたが、唯一の本当の競合相手 (つまり、ハックで利用可能なライブラリとして実装されているもの) はrecords パッケージです。または、拡張可能なレコードから欠落しているリンクはありますか?
これらのパッケージの問題は、その目標の範囲です。HList は、実際にはラベルの 5 つの異なる実装、2 つの型等価、2 つの型キャスト、2 つの Record/RecordP、および Variant と TIC の選択です。すべて似ていますが、使いやすさ、移植性、および使用される拡張機能のトレードオフは異なります。
新しい GHC 機能 (GADT、関連付けられた型、制約の種類、ポリモーフィックな種類、シングルトン型) では、わずかに異なるトレードオフが許容される場合があります。特に、シングルトン型はより良いラベルを可能にする可能性があり、ポリモーフィックな種類はよりエレガントな Typeable/Data/Generics を可能にする可能性があります。
リンク先の「records」パッケージは、次を主張する「kinds」パッケージに依存します。
「Haskell はサブカインドとサブカインド ポリモーフィズムをサポートしていません。ただし、このパッケージを使用して、カインド * とサブカインド変数のサブカインドをエミュレートできます。」
しかし、GHC の新しいバージョンではデータ型が種類に昇格したため、これはもはや当てはまりません。したがって、この 2012 年 1 月のパッケージは、現在では時代遅れになっている可能性があります。
レコードに関しては、おそらく新しいシステムは、レンズおよび/またはlens-familyという最新のポリモーフィック レンズから引き出されるでしょう。