Haskellの "Dependent optional"データ

Question

日付が存在する必要があるDateTime型を考えてみましょう。ただし、秒単位の時間はオプションです。時間部分がある場合は、オプションのミリ秒部分もあります。ミリ秒がある場合は、ナノ秒の部分もあります。これに対処するための多くの方法があります

、例えば：

--rely on smart constructors 
data DateTime = DateTime { days:: Int, 
          sec :: Maybe Int, 
          ms :: Maybe Int, 
          ns :: Maybe Int 
         } 

-- list all possibilities 
data DateTime = DateOnly Int 
       | DateWithSec Int Int 
       | DateWithMilliSec Int Int Int 
       | DateWithNanoSec Int Int Int Int  

-- cascaded Maybe 
data DateTime = DateTime Int (Maybe (Int, Maybe (Int, Maybe Int))) 

-- cascaded data 
data Nano = NoNano | Nano Int 
data MilliSec = NoMilliSec | MilliSec Int Nano 
data Sec = NoSec | Sec Int MilliSec 
data Date = Date Int Sec 

構築物はあなたが（もちろん上記の例に限定されない）を使用するでしょう、そして、なぜ？

[意図]

私は、フレーゲ（http://code.google.com/p/frege/）の日付タイプの可能性を模索しdate4jのDateTimeガイドラインとしてを使用して（Haskellの日付と時刻のlibがあまりにも複雑であるとして、そしてjava.util.Dateよあまりにも壊れた）。私の現在のおもちゃの実装では、すべてのフィールドは必須ですが、もちろん、望ましくない精度からユーザーを解放するのが良いでしょう（元の実装にはオプションフィールドがあります）。

だから、主な目標は以下のとおりです。

• 安全性：不正な状態はすべてのコスト
• 都合の良い時に避けなければならない。例えば、タイプで動作するように簡単にする必要がありますパターンマッチングは、クールになる、カレンダーの計算が簡単なはず...

それほど重要ではないが、次のとおりです。

• パフォーマンス：もちろんタイプでの作業が遅すぎることが、典型的なのためにはなりませんそれは最後のクロックサイクルをsqeezeする必要はありません。
• メモリ：これが本当に重要な場合は、よりコンパクトなストレージフォーマットを導出するのが簡単です
• 簡潔な実装：ライブラリです。物事をスムーズにするために必要なすべてのコードを追加する意思がある

しかし、これはすべて非常に暫定的なものであり、あまり深刻ではありません。

Answer 1

（これが答えではないが、それはコメントのためにあまりにも長いですし、ここに明確になります。）

あなたはそれを扱うことができる別の方法があります：常にすべてのフィールドを保存する単一DateTimeタイプを持っています精度を表すパラメータ、例えば

data Precision = Days | Seconds | Milliseconds | Nanoseconds deriving (Ord, Eq {- etc -}) 
data DateTime = DateTime { prec :: Precision, 
          days :: Int, 
          sec :: Int, 
          ms :: Int, 
          ns :: Int } 

スマートコンストラクタを使用して、未使用のパラメータを0に設定します。 dateDifferenceなどを使用している場合は、精度を伝播できます（Ordインスタンスはこれをきれいにします）。

（私はこれがどのように良い/ハスケル-Yについて少し考えを持っているが、他の解決策は、多分これは、よりエレガントで、かなり厄介なようです。）

Answer 2

「違法状態はすべてのコストで避けなければなりません」 「パターンマッチングはクールだ」というのは、この場合、互いに直接衝突するという罰則です。

さらに、日付と時刻は、多くのエッジケースと不規則なコーナーを持つぎこちない人間の文化的構成です。型システムで簡単にエンコードできるルールのようなものではありません。

この場合、私は不透明なデータ型、スマートコンストラクタ、スマートデコンストラクタを使用します。パターンマッチングを使用したいときは、常にパターンとパターンガードを表示します。

（そして私も動機要因として依存オプションのデータを説明していない。）

Answer 3

に@ dbauppのソリューションに触発され、私は候補者にファントムタイプのバージョンを追加したい：

-- using EmptyDataDecls 
data DayPrec 
data SecPrec 
data MilliPrec 
data NanoPrec 

data DateTime a = DateTime { days :: Int, sec :: Int, ms :: Int, ns :: Int } 

date :: Int -> DateTime DayPrec 
date d = DateTime d 0 0 0 

secDate :: Int -> Int -> DateTime SecPrec 
secDate d s = DateTime d s 0 0 

...  

--will work only for same precision which is a Good Thing (tm) 
instance Eq (DateTime a) where 
    (DateTime d s ms ns) == (DateTime d' s' ms' ns') = [d,s,ms,ns] == [d',s',ms',ns'] 

私は間違っていないとすれば、これによって1つのタイプで作業することができますが、必要に応じて精度を区別することができます。しかし、私はそこにもいくつかの欠点があると思います...

Answer 4

あなたはこの問題（より一般的なものとは対照的に）を解決したいとすれば、decimalライブラリはあなたが望むものかもしれません。