- Libraries - Haskell.org

small fixes patch
by John Meacham 26 Jan '05

26 Jan '05

attached is a patch to fix a module name and generalise a couple functions in Data.Map to be usable in an arbitrary monad (rather than being restricted to Maybe). if someone could integrate it, that would be great. John -- John Meacham - ⑆repetae.net⑆john⑈

2 1

RE: Time
by Simon Marlow 25 Jan '05

25 Jan '05

On 22 January 2005 07:14, Ashley Yakeley wrote: > There's been a lot of discussion here and other lists of replacing > System.Time, and indeed Simon M. is working on a replacement proposal: > > <http://www.haskell.org/~simonmar/time/NewTime.html> > <http://www.haskell.org/~simonmar/time/NewTime.hsc> > > Rather than talk about specific Haskell code, I'd like to discuss the > measurement of time in general, how these concepts might be expressed > in Haskell, and what people might want from a time library. Rather > than propose anything, I want to try to ask some of the right > questions. I'd like to join the others in saying thanks for a fine summary, Ashley. Nice work! On the subject of the NewTime library you mentioned, it was the culmination of a long thread (or threads) on this list a while ago. I think it's a pretty good stab at an API for manipulating and converting between: - absolute time (TAI) - UTC - times in calendar representation - timezones but it is missing - time offsets (eg. "1 day later") - a more complete/accurate timezone table - some way to update the leap second table - geographical time zones and probably some other things. my plan was that the whole "time offset" issue would be a layer on top of this library, as others have suggested. You can already do simple calculations using CalendarTime. The representation of absolute time could be revisited. What I mean by "geographical time zones" is some notion of a time zone that is independent of daylight savings time. The current TimeZone type is a fixed UTC offset (which I think is right), but there's no way to say "what's the local time in London at time T?". I probably won't be doing much to this library, but I think it's a good starting point for anyone who wants to explore further. Cheers, Simon

2 1

RE: Time
by Simon Marlow 25 Jan '05

25 Jan '05

On 25 January 2005 14:25, Simon Marlow wrote: > my plan was that the whole "time offset" issue would be a layer on top > of this library, as others have suggested. You can already do simple > calculations using CalendarTime. One other thing I just remembered: IIRC there was a proposal to handle the whole timezone offset issue with a single function normalizeCalendarTime :: CalendarTime -> CalendarTime which would essentially just roll over the out of range fields in CalendarTime. This is essentially the same as the idea Marcin proposed in his message, I believe. Of course, normalizeCalendarTime needs to know about leap seconds (some minutes don't have 60 seconds!). Cheers, Simon

1 0

--prefix and --copy-prefix in Cabal
by Krasimir Angelov 25 Jan '05

25 Jan '05

Hello, Guys There are two options for prefixes: --prefix and --copy-prefix. In my opinion they have the same meaning and I wonder whether we need to have two different options for configure and copy commands. Any thoughts? Cheers, Krasimir

3 2

RE: Time
by Bayley, Alistair 24 Jan '05

24 Jan '05

I added this to the Wiki. Hope that's OK. http://haskell.org/hawiki/TimeLibrary > -----Original Message----- > From: Ashley Yakeley [mailto:ashley@semantic.org] > Sent: 22 January 2005 07:14 > To: libraries(a)haskell.org > Subject: Time > > There's been a lot of discussion here and other lists of replacing > System.Time, and indeed Simon M. is working on a replacement proposal: > > <http://www.haskell.org/~simonmar/time/NewTime.html> > <http://www.haskell.org/~simonmar/time/NewTime.hsc> > > Rather than talk about specific Haskell code, I'd like to discuss the > measurement of time in general, how these concepts might be > expressed in > Haskell, and what people might want from a time library. Rather than > propose anything, I want to try to ask some of the right questions. > > ... ----------------------------------------- ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. *****************************************************************

1 0

RE: FW: FW: cvs commit: fptools/libraries/base package.conf.in fptools/libraries/base/Data IntMap.hs IntSet.hs Map.hs FiniteMap.hs Set.hs
by Simon Marlow 21 Jan '05

21 Jan '05

On 20 January 2005 17:39, Sven Panne wrote: > Alain Cremieux wrote: >>> As I see it: we could change all the operations in >>> Data.Set/Data.Map to be right-biased, but that's a fair bit of work >>> and might introduce new bugs. >>> >>> If someone wants to do this work, it needs to be done fairly quickly >>> (i.e. in the next couple of weeks) because we plan to release GHC >>> 6.4 with the new code, and we won't be able to make further library >>> changes until 6.6. Any volunteers? >>> >>> Cheers, >>> Simon >>> >>> >> Hi, >> If everyone agrees on what's to be done, I volunteer for doing it. >> Alain > > I'm not sure if we should really do this, I was just trying to find > out the reason for this bias change. Perhaps adding a BIG comment in > the new API is enough. Right. I think the concensus is that we don't need to systematically change the bias in Data.Map, but we do need to document the change carefully for those porting old code. For the most part, old code will continue to work without changes because we've kept the old APIs. The exception (Data.Set.union) was pointed out by Ross, but it's unlikely to affect "normal" uses of union. Cheers, Simon

1 0

FW: FW: cvs commit: fptools/libraries/base package.conf.in fptools/libraries/base/Data IntMap.hs IntSet.hs Map.hs FiniteMap.hs Set.hs
by Alain Cremieux 20 Jan '05

20 Jan '05

>As I see it: we could change all the operations in Data.Set/Data.Map to >be right-biased, but that's a fair bit of work and might introduce new >bugs. > >If someone wants to do this work, it needs to be done fairly quickly >(i.e. in the next couple of weeks) because we plan to release GHC 6.4 >with the new code, and we won't be able to make further library changes >until 6.6. Any volunteers? > >Cheers, > Simon > > Hi, If everyone agrees on what's to be done, I volunteer for doing it. Alain

2 1

Data.Map.splitLookup
by Ross Paterson 18 Jan '05

18 Jan '05

Currently there is splitLookup :: Ord k => k -> Map k a -> (Maybe a,Map k a,Map k a) returning the matching element (if any) and the submaps less and greater than the key. I think it would be neater to return the element in the middle: splitLookup :: Ord k => k -> Map k a -> (Map k a,Maybe a,Map k a) Perhaps Data.Set.splitMember should similarly be changed from splitMember :: Ord a => a -> Set a -> (Bool,Set a,Set a) to splitMember :: Ord a => a -> Set a -> (Set a,Bool,Set a)

1 0

RE: cabal posix build-depends issue
by Simon Marlow 18 Jan '05

18 Jan '05

On 17 January 2005 18:24, Malcolm Wallace wrote: > Isaac Jones writes: >>> If it depends on posix, on a non-posix system, the user will get an >>> error because the posix package doesn't exist. >>> >>> If it doesn't depend on posix on a posix-based system, then ghc >>> won't get the -package posix flag, and so cabal will fail to link. > > There is a further problem: nhc98 has neither posix nor util packages, > so a straightforward dependency on either would be wrong. In general yes - in this particular case I don't see why nhc98 can't provide the unix package (not the posix package - that's the old non-hierarchical version, sorry for the confusion). There might be minor porting issues, but it's mostly just FFI code. > Simon Marlow writes: >> My gut feeling is that we should be able to say something like >> build-depends: if-not-os("mingw32",unix >= 1.0) > > I would agree that we need platform-selected dependencies. Platform > includes compiler, compiler version, OS, and possibly OS version. Yup. Cheers, Simon

1 0

RE: FW: FW: cvs commit: fptools/libraries/base package.conf.in fptools/libraries/base/Data IntMap.hs IntSet.hs Map.hs FiniteMap.hs Set.hs
by Simon Marlow 18 Jan '05

18 Jan '05

On 17 January 2005 19:59, Iavor Diatchki wrote: > On Mon, 17 Jan 2005 16:04:29 -0000, Simon Marlow > <simonmar(a)microsoft.com> wrote: >> If someone wants to do this work, it needs to be done fairly quickly >> (i.e. in the next couple of weeks) because we plan to release GHC 6.4 >> with the new code, and we won't be able to make further library >> changes until 6.6. Any volunteers? > > It seems strange to me that the DData library and GHC need to evolve > at the same rate. > Why not have a library website where interested programmers can go and > download the > latest version of the library? Absolutely, that's the direction we want to move in with Cabal and Hackage. But at the moment, GHC is shipped with a monolithic collection of libraries, and we make certain promises about when we change those interfaces. Don't worry, in the future you'll be able to upgrade most libraries independently of GHC (and get a whole new set of problems :-). Cheers, Simon

1 0