Does not typecheck with time-1.8 (HEAD) about unix HOT 11 CLOSED

There's a time-1.9? I thought that HEAD was only at version 1.8?

from unix.

I'm quite positive @ezyang meant time-1.8

that being said, its new type-definition is

data POSIXTime
  = Data.Time.Clock.POSIX.POSIXTime {ptSeconds :: !GHC.Int.Int64,
                                     ptNanoSeconds :: !GHC.Word.Word32}
  	-- Defined at lib/Data/Time/Clock/POSIX.hs:35:1
instance Eq POSIXTime
  -- Defined at lib/Data/Time/Clock/POSIX.hs:38:17
instance Ord POSIXTime
  -- Defined at lib/Data/Time/Clock/POSIX.hs:38:20

The question is whether it'll remain in that state lacking a Fractional instance (fwiw, using realToFrac to convert to/from POSIXTime has been quite popular in Haskell code....)

However, the code in unix would actually benefit from being able to construct a POSIXTime efficiently as a combination of integral seconds + integral nano-seconds, as that's what the POSIX apis provide us with, e.g.

accessTimeHiRes (FileStatus stat) =
  unsafePerformIO $ withForeignPtr stat $ \stat_ptr -> do
    sec  <- (#peek struct stat, st_atime) stat_ptr :: IO EpochTime
#ifdef HAVE_STRUCT_STAT_ST_ATIM
    nsec <- (#peek struct stat, st_atim.tv_nsec) stat_ptr :: IO (#type long)
    let frac = toInteger nsec % 10^(9::Int)
#elif HAVE_STRUCT_STAT_ST_ATIMESPEC
    nsec <- (#peek struct stat, st_atimespec.tv_nsec) stat_ptr :: IO (#type long)
    let frac = toInteger nsec % 10^(9::Int)
#elif HAVE_STRUCT_STAT_ST_ATIMENSEC
    nsec <- (#peek struct stat, st_atimensec) stat_ptr :: IO (#type long)
    let frac = toInteger nsec % 10^(9::Int)
#elif HAVE_STRUCT_STAT_ST_ATIME_N
    nsec <- (#peek struct stat, st_atime_n) stat_ptr :: IO (#type int)
    let frac = toInteger nsec % 10^(9::Int)
#elif HAVE_STRUCT_STAT_ST_UATIME
    usec <- (#peek struct stat, st_uatime) stat_ptr :: IO (#type int)
    let frac = toInteger usec % 10^(6::Int)
#else
    let frac = 0
#endif
    return $ fromRational $ toRational sec + frac

c.f. haskell/time#54 (CC @AshleyYakeley @winterland1989: what's the recommended way to construct a POSIXTime in future?)

from unix.

Yes, the new POSIXTime is intended to be a low level type to make the conversion between POSIX presentation and high level types more efficient AFAICT, i 'm not having any particular feelings about the Fractional instance, if there is too much breakage I guess it should be add then.

from unix.

Since POSIXTime was previously just a type synonym for NominalDiffTime (a.k.a. Pico, a.k.a Fixed E12), if we want to avoid other breakages like this, we should mirror all instances for Fixed a as well. From a quick glance at Fixed's Haddocks, it looks like that would include:

• Data
• Enum
• Fractional
• Num
• Read
• Real
• RealFrac
• Show

from unix.

Sorry, I mean 1.8! Edited.

from unix.

time HEAD is not in a stable state right now. I am considering reverting the changes to POSIXTime and adding a RawTime instead, to maintain compatibility.

from unix.

@winterland1989 @AshleyYakeley ok, but while adding a new RawTime provides maximum compatibility, this also means that unix won't be able to benefit from this, unless we start duplicating the API (similiar to what we already do for RawFilePath <-> FilePath; for RawTime we'd probably get away duplicating just one/two module or so)

(...or we leverage @ezyang's backpack for abstracting over POSIXTime/RawTime)

from unix.

I'm inclined to change POSIXTime directly for the same reason. My patch start with POSIXTimeRaw routine, then i removed it and changed POSIXTime directly in next commits followed discussion with @AshleyYakeley.

The situation now is quite frustrating, while we're still looking for a judgement on POSIXTime changing itself, here's what i see as an appropriate solution if we do change it:

• Add missing Num, Real, RealFrac, Fractional instance.
• Derive Show, Read, Data instances.
• Document the change of POSIXTime and its instances.
• Document the removal of Enum instance.

from unix.

I'm trying to avoid breaking downstream packages by changing POSIXTime. I figure if we introduce a new type, it should have a new name.

from unix.

I believe this issue can be closed.

from unix.

Given that time-1.8 has been released (without this breaking change) and unix compiles just fine with it, I'll close this issue.

from unix.