Datos "dependientes opcionales" en Haskell

Question

Considere un tipo de fecha y hora donde la fecha debe estar presente, pero la parte de tiempo en segundos es opcional. Si la parte de tiempo está allí, también puede haber una parte de milisegundos opcional. Si hay milisegundos, también puede haber una parte de nanosegundos.

Hay muchas maneras de hacer frente a esto, por ejemplo .:

--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 

que construyen usaría (por supuesto no se limita a los ejemplos anteriores), y por qué?

[intenciones]

estoy explorando las posibilidades de un tipo de fecha en Frege (http://code.google.com/p/frege/), utilizando date4j de DateTime como una línea guía (como la fecha y la hora lib de Haskell es demasiado complicado, y java.util.Date demasiado roto). En mi implementación actual de juguetes, todos los campos son obligatorios, pero, por supuesto, sería bueno liberar al usuario de la precisión no deseada (y la implementación original tiene campos opcionales).

Así que los principales objetivos son:

• seguridad: estados ilegales deben ser evitados a toda costa
• conveniencia: Debe ser fácil de trabajar con el tipo, por ejemplo, la coincidencia de patrones estaría bien, los cálculos del calendario debe ser fácil ...

No tan importantes son:

• rendimiento: Por supuesto trabajar con el tipo no debe ser demasiado lento, pero para la típica uso no tiene que sqeeze el último ciclo de reloj
• memoria: en los casos en que esto realmente importa, sería fácil derivar un formato de almacenamiento más compacto
• implementación concisa: Es una biblioteca, y estoy dispuesto a agregar todo el código necesario para que las cosas se suavicen

Dicho esto, todo esto es muy tentativo y no debe tomarse demasiado en serio.

Answer 1

(Esto no es una respuesta, pero es demasiado largo para un comentario y será más claro aquí.)

Hay otra forma que se podía manejar la situación: tienen un solo tipo DateTime que almacena todos los campos siempre junto con un parámetro que representa la precisión, por ejemplo

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

Y el uso de constructores inteligentes que establecen los parámetros utilizados para 0. Si tiene dateDifference o lo que sea, puede propagar la precisión a través de (la instancia Ord lo haría limpio).

(Tengo poca idea de lo bueno/Haskell-y esto es, pero las otras soluciones parecen bastante desordenado, tal vez esto es más elegante.)

Answer 2

“estados ilegales deben ser evitados a toda costa” y "la coincidencia de patrones sería genial" son buenos principios que en este caso están en conflicto directo entre sí.

Además, las fechas y los tiempos son construcciones humanas humanas gnarly con muchos bordes y rincones irregulares. No son el tipo de reglas que podemos codificar fácilmente en el sistema de tipos.

Así que en este caso iría con un tipo de datos opaco, constructores inteligentes y deconstructors inteligentes. Siempre hay patrones de vista y patrones de protección para las ocasiones en que queremos usar la coincidencia de patrones.

(Y ni siquiera he discutido datos opcionales dependientes como un factor de motivación.)

Answer 3

Inspirado por la solución de @ dbaupp Me gustaría añadir una versión de tipo fantasma para los candidatos:

-- 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'] 

Si no me equivoco, esto me permite trabajar con un tipo, pero para distinguir las precisiones si es necesario. Pero supongo que también habrá algún inconveniente ...

Answer 4

Suponiendo que solo quiere resolver este problema (a diferencia de uno más genérico), entonces la biblioteca decimal podría ser lo que usted desea.