- Libraries - Haskell.org

RE: Concerning Time.TimeDiff
by Simon Marlow 20 Jun '03

20 Jun '03

> > in any case, since a pair of Int64's is not a clear win and > an Integer > > definatly is a clear win in terms of usability then I > believe we should > > go for that. > > It's a radical idea but... Maybe we could avoid all these > issues by using an > abstract type with all sensible instances (including Num > though it is only > semi-sensible for times). > > Internally, we might use Integer or two Int64s or we might > even add Int128 to > our compilers. Externally it looks like an Integral (or > Fractional?) type. Yes, I think that's a reasonable compromise. The accuracy is still specified to be picoseconds, but the representation is hidden. Any objections? Cheers, Simon

2 1

RE: Concerning Time.TimeDiff
by Simon Marlow 20 Jun '03

20 Jun '03

> On Mon, Jun 16, 2003 at 04:42:53PM +0100, Graham Klyne wrote: > > ... I think it's quite usual for people and applications to deal > > with a day as a consistent time interval without concern for > > possible leap seconds, so dealing with days as intervals of 24*60*60 > > seconds is useful for a majority of applications that deal with such > > intervals. > > What about the fact that days are not actually intervals of 24*60*60 > seconds (as I'm sure you know)? Most applications don't care, but > it's crucial to give correct and unsurprising results. > > I'm worried that the complexity to deal with leap seconds will end up > being just as complicated as the complexity to deal with more general > TimeDiff's as in the current library, in which case it may be > necessary to bite the bullet and specify the behaviour of TimeDiffs > completely and accurately. Agreed, this discussion tends to get rather vague at times, so I'd like to put it on a more concrete footing if I may. I've put together rough suggestion for a starting point for a replacement System.Time, appended below. Please comment! Cheers, Simon ------------------------------------------------------------------------ ---- -- * ClockTime -- | A representation of absolute time data ClockTime = ClockTime { ctSeconds :: Integer, ctPicoseconds :: Integer } deriving (Eq, Ord, Show, Read) -- | returns the current absolute time getClockTime :: IO ClockTime -- | Difference between two 'ClockTime's data TimeDiff = TimeDiff { tdSeconds :: Integer, tdPicoseconds :: Integer } deriving (Eq, Ord, Show, Read) -- | An empty 'TimeDiff' noTimeDiff :: TimeDiff -- | Returns the difference between two 'ClockTime's diffClockTimes :: ClockTime -> ClockTime -> TimeDiff -- | Adds a 'TimeDiff' to a 'ClockTime' addToClockTime :: ClockTime -> TimeDiff -> ClockTime {- Rationale: - TimeDiff is now an absolute measure of time period. Invariants: t1 `addToClockTime` (t2 `diffClockTimes` t1) == t2 t1 `addToClockTime` noTimeDiff == t1 t1 `diffClockTimes` t1 == noTimeDiff TODO: - This representation of TimeDiff is maybe not the best. Two other possibilities: use just picoseconds, or have the type be abstract with a way to extract picoseconds. - If we keep the seconds/picoseconds representation, should we specify that the TimeDiff returned by diffClockTimes is normalised? Should we provide a way to normalise a TimeDiff? -} ------------------------------------------------------------------------ ---- -- * CalendarTime data CalendarTime = CalendarTime { ctYear :: Int, ctMonth :: Month, ctDay :: Int, ctHour :: Int, ctMin :: Int, ctSec :: Int, ctPicosec :: Integer, ctTZ :: Timezone } deriving (Eq, Ord, Read, Show) data Timezone -- abstract -- | Make a 'Timezone' -- TODO: do we need to specify daylight savings time too? timezoneFromOffset :: Int -> Timezone timezoneFromName :: String -> Timezone timezoneOffset :: Timezone -> Int timezoneName :: Timezone -> String -- | Convert a 'ClockTime' to a 'CalendarTime' in the current timezone clockTimeToCalendarTime :: ClockTime -> IO CalendarTime -- | Convert a 'ClockTime' to a 'CalendarTime' in UTC clockTimeToUTCTime :: ClockTime -> CalendarTime -- | Convert a 'CalendarTime' to a 'ClockTime' -- TODO: can this raise an exception if the CalendarTime does not -- represent a valid time? Or should it return Maybe ClockTime? calendarTimeToClockTime :: CalendarTime -> ClockTime -- OPTIONAL: these are hard to implement, and require -- careful specification (see rationale below): addPicoseconds :: CalendarTime -> Integer -> CalendarTime addSeconds :: CalendarTime -> Integer -> CalendarTime addMinutes :: CalendarTime -> Integer -> CalendarTime addDays :: CalendarTime -> Integer -> CalendarTime addWeeks :: CalendarTime -> Integer -> CalendarTime addMonths :: CalendarTime -> Integer -> CalendarTime addYears :: CalendarTime -> Integer -> CalendarTime {- Rationale: - Adding "irregular" time differences should be done on CalendarTimes, because these operations depend on the timezone. - Need to define the meaning when the offset doesn't exist. eg. adding a day at the end of the month clearly rolls over into the next month. But what about adding a month to January 31st? -}

9 28

RE: Concerning Time.TimeDiff
by Graham Klyne 20 Jun '03

20 Jun '03

At 13:37 19/06/03 +0100, Simon Marlow wrote: >UTC is only a kludge for the fact that the Earth wobbles a bit on its >trajectory through space - I think that's a reasonable kludge :-) > >POSIX "seconds since the epoch" is a *real* kludge. Let's not get the >two confused. I think this is an important point, and thanks for pointing it up. Whatever we may decide about TimeDiff values, I think this indicates that a clocktime should *not* be a single integer. The minimal representation that avoids getting dragged into leap-second issues would seem to be, e.g., a pair of Integers (days and picoseconds). This also leaves me thinking that, completely aside from efficiency issues, that a TimeDiff should also be expressed in days and sub-days. I have two related reasons for this: (1) the point that I made previously that adding a TimeDiff of an exact number of days to a Clocktime should always result in a new Clocktime that yields the exact same time-of-day. (2) I assert that ct+dt (ct::ClockTime, dt::DiffTime) should always yield the same answer for any giver ct and dt. If dt is expressed only as a sub-day value (e.g. picoseconds) then the actual value depends on whether there is a leap second in the time interval [dt,dt+ct). But the occurrence of leap seconds is not known very far into the future, so if you try to take account of leap seconds you may end up with different answers depending on the state of knowledge at the time the calculation is performed. Ugh! #g ------------------- Graham Klyne <GK(a)NineByNine.org> PGP: 0FAA 69FF C083 000B A2E9 A131 01B9 1C7A DBCA CB5E

1 0

RE: Readline (was Re: state of ghc6 on sparc)
by Simon Marlow 20 Jun '03

20 Jun '03

> > > [SimpleLineEditor] > > > > It seems to behave strangely here: I can delete the > prompt, and if I > > move the cursor to the left and delete some characters, the > characters > > to the right of the cursor don't move. Also, the backspace > key doesn't > > work, although C-Backspace does work (backspace works fine with > > readline). This is in an xterm; in a cygwin shell window different > > strange things happen. > > There were a couple of bugs (now fixed) in the version I posted which > account for being able to delete the prompt, and for some strange > behaviour when retrieving history whilst in the middle of the line. > > But I'm also perfectly well aware that a different terminal > environment > might completely mess up some assumptions in the keystroke lexer. > For instance, in a gnome-terminal, ^H and backspace register as the > same single character, but in cbreak mode the former is echoed to > screen as two characters, whilst the latter is apparently echoed > as one. Or least, that was the case yesterday - today they seem to > be the same! > > Perhaps the best way to take care of such differences is by turning > off terminal echo, but sadly there is no portable Haskell'98 method > for that. Hmm. I'm highly dubious that this can be done portably enough to be worthwhile. The only way to get information about the terminal is by consulting termcap or terminfo, otherwise you're just guessing. Even Xterm itself differs in what keystrokes it generates between versions of XFree86, and even between vendor releases (RedHat IIRC uses its own key mappings in XTerm and has a special termcap entry). Isn't this just a pile of bug reports waiting to happen? Or a neverending maintenance headache? Cheers, Simon

2 1

RE: Readline (was Re: state of ghc6 on sparc)
by Simon Marlow 20 Jun '03

20 Jun '03

> Alastair Reid <alastair(a)reid-consulting-uk.ltd.uk> writes: > > > It would be nice to have those bindings but just having > backspace and > > left-right cursors work would already be a huge improvement > over nothing. > > OK, here is my contribution. The attached module SimpleLineEditor > is API-compatible with readline, and is a slight elaboration of > the line editor currently distributed as part of hmake interactive. It seems to behave strangely here: I can delete the prompt, and if I move the cursor to the left and delete some characters, the characters to the right of the cursor don't move. Also, the backspace key doesn't work, although C-Backspace does work (backspace works fine with readline). This is in an xterm; in a cygwin shell window different strange things happen. Cheers, Simon

2 1

RE: Concerning Time.TimeDiff
by Simon Marlow 20 Jun '03

20 Jun '03

> Well, my main problem with representing time as a pair, is that a > point in time isn't uniquely defined (e.g. should it be 3s + 5e-11ps, > or 2s + 5e-11ps), and that, in most suggested formats, they overlap > (e.g. 3s or 2s + 1e12 ps). So you need to normalize -- possibly after > each operation. Are you sure this is more efficient than using > bignums? > > Further, I'm not sure Haskell has a standard 64 bit Int. I'm fairly > sure it's in GHC, and probably in the other compilers, but it'd be > nice if it were in the standard. On the other hand, Integer can be > implemented any way that's efficient on each architecture. Haskell does have a standard 64 bit Int, known as Int64. (standard in the sense that the FFI addendum defines it, which is almost but not quite as standard as Haskell 98). If there are performance concerns, then we should measure both the version with an Int64 pair and the version with Integer. My guess is that there won't be enough of a difference for it to matter. > > I find it hard to lose sleep over missing leap-seconds and > dates beyond > > Leap seconds are a completely orthogonal issue. From the discussion > here, it seems plain that UTC is a kluge, and TAI is the way to go. > In any case, we already agree to counting seconds, the question is how > to count them :-) UTC is only a kludge for the fact that the Earth wobbles a bit on its trajectory through space - I think that's a reasonable kludge :-) POSIX "seconds since the epoch" is a *real* kludge. Let's not get the two confused. Cheers, Simon

5 6

RE: Concerning Time.TimeDiff
by Simon Marlow 19 Jun '03

19 Jun '03

> > ...and I don't think it's entirely given that two 64 bit > numbers will > > be faster than one Integer. > > I do. the implementation of Integer requires traversing additional > indirections to an array of bits, reading the size of the operands, > allocating space for the result, etc. It's a lot of work even if the > arguments and result are simple values like 0 or 1. I'm not sure I believe that. Compare: data T = T Int64 Int64 newtype T = T Integer In pure space terms, with GHC, the first rep takes 9 words. The second probably takes 8 words, assuming 3 words for the integer value. The second version is probably faster at most things, too. The fastest representation would be data T = T !Int64 !Int64 and compile with -funbox-strict-fields to remove two indirections and two unnecessary bottoms in the domain. Nevertheless, I still think this is all moot. Cheers, Simon

1 0

Data.Generics, instance Data Int?
by Markus.Schnell＠infineon.com 18 Jun '03

18 Jun '03

Hi, why are Float, Char and Bool instances of Data, but not Int or Integer? Markus -- Markus Schnell

2 1

RE: Concerning Time.TimeDiff
by Simon Marlow 18 Jun '03

18 Jun '03

> Simon Marlow wrote: > > John suggested using (pico)seconds since 1970-01-01 > 00:00:10 TAI. Isn't this equivalent to saying that ClockTime > is the number of > > seconds since 1970-01-01 00:00:00 UTC? > > Yes. > > TAI started ticking on 1 Jan 1958. > > UTC started ticking on 1 Jan 1972, and started 10 seconds > behind of TAI > (to keep it within 0.9 sec of UT1). So before 1 Jan 1972, UTC is defined as being the same as TAI? Or is it just undefined? Cheers, Simon

1 0

Fw: library infrastructure roundup (Alastair Reid)
by Dominic Steinitz 18 Jun '03

18 Jun '03

I meant to copy this to the libraries mailing list. Dominic Steinitz ----- Original Message ----- From: "Dominic Steinitz" <dominic.steinitz(a)blueyonder.co.uk> To: <alastair(a)reid-consulting-uk.ltd.uk> Sent: Tuesday, June 17, 2003 8:31 PM Subject: Re: library infrastructure roundup (Alastair Reid) > Alastair, > > I have put together a crypto library based on other people's contributions > so that you can use standard padding and modes with them. I'm currently > trying to find some web space to put the whole package in. I also haven't > got a CVS repository so that other people can add to it. It isn't finished > but there is nothing else out there (that puts things in one place and has > the modes and padding). I wanted to be able to use all the modules in > Codec/Encryption by saying -package crypto. > > Should I add it to your list in http://haskell.org/hawiki/LibrariesAndTools? > > Here's the instructions for using it: > > tar -xvf crypto.tar > > make depend > make > make install > make doc > > You will need to be root to make install. > > You should then be able to compile and run a test program from anywhere: > > ghc -o Test Test.hs -package crypto > ./Test > Testing DES... > Passed > Testing Blowfish... > Passed > > Dominic Steinitz > > >

3 2