Open ear7h opened 3 years ago
I think it does make sense to rekindle the discussion in https://github.com/dhall-lang/dhall-lang/issues/80. The Dhall community has changed quite a bit in the two years since the last comment on that thread. In particular, there are quite a few more implementations that may or may not want to provide built-in support for dates.
Until we have a decision on the language support we might as well do the easiest thing which I think is to use a simple newtype like { date : Text }
or maybe { tomlDate : Text }
. The < Date : Text >
idea is nice too, but I think it's a bit less convenient to extract the field from it.
The main precedent for types that carry special meaning during marshalling is the JSON.Nesting
type used in dhall-json
.
How do the Haskell TOML libraries handle TOML's dates and times BTW? That might give us some inspiration.
Both tomland
and toml
haskell packages use the time
package, where the types are records. For example UTCTime
is:
data UTCTime = UTCTime {
-- | the day
utctDay :: Day,
-- | the time from midnight, 0 <= t < 86401s (because of leap-seconds)
utctDayTime :: DiffTime
}
Something I remembered is that there are different kinds of times in TOML:
So there would actually need to be multiple newtypes { offsetDatetime : Text}
, {localDatetime : Text}
, etc. I was thinking that a single { tomlDate : Text}
would work, but the the date kind is necessary in for making the correct Toml.Codec
value
I wrote up my thoughts on how this could be done as a change to the language standard here: https://github.com/dhall-lang/dhall-lang/issues/80#issuecomment-862463847
For reference:
Dhall.Pretty.temporalToText
might be handy for implementing date support in dhall-to-toml
.
TOML has native support for dates and times and I'm wondering how this should be handled in dhall. I can add to the discussion standardizing date/times in dhall, but perhaps a more specialized solution would be better.
I don't think
toml-to-dhall
poses too much of a problem, we can just turn the timestamps into strings. Butdhall-to-toml
requires some mechanism of distinguishing strings from timestamps since the syntax for times are different:In the above thread one approach mentioned is to use a newtype
{ date : Text }
to represent times, but overloading a record with adate
field seems like it would run into problems. I think a better approach, with a similar effect is to use an enumDate : Type = <Date : Text>
. This could live in the prelude underPrelude.Toml.Date
. However, it requires special-casing the type indhall-to-toml
and I'm not sure if that's acceptable or if there's a precedent for doing that in other dhall (en|de)coders.