- Libraries - Haskell.org

Data.Dynamic
by John Meacham 04 Mar '05

04 Mar '05

Could we add a function: getTypeRep :: Dynamic -> TypeRep to Data.Dynamic? right now, there is no way to tell if two dynamics are of the same type. John -- John Meacham - ⑆repetae.net⑆john⑈

1 1

(no subject)
by Duncan Coutts 01 Mar '05

01 Mar '05

Gtk2Hs - A Haskell GUI library based on the Gtk+ GUI Toolkit. Version 0.9.7.1 is now available from: http://gtk2hs.sourceforge.net/ This release is only needed for Windows users. If you have version 0.9.7 working there is no need to upgrade. Source and binary packages are available for Windows. There are binary packages for Gtk+ 2.4.x and 2.6.x. The binary packages require GHC 6.2.2. You may wish to use Gtk+ 2.6 since it follows the Windows native look and themes whereas Gtk+ 2.4 did not. Installation on Windows is fairly straightforward. There is an installer for Gtk+ on Windows and installing Gtk2Hs just involves unzipping and running a batch file. Instructions are here: http://gtk2hs.sourceforge.net/archives/2005/02/17/installing-on-windows/ For future Gtk2Hs releases we hope to provide an MSI installer to make it even easier. Changes since 0.9.7: * build fixes for Windows * almost all modules now carry LGPL 2.1 license * a couple of extra functions are now bound Other changes and news since the last release announcement: * there is an introductory article by Kenneth Hoste in the first issue of The Monad.Reader: http://www.haskell.org/hawiki/TheMonadReader_2fIssueOne * a complete website redesign * many new screenshots: http://sourceforge.net/project/screenshots.php?group_id=49207 * packages of version 0.9.7 are available for Gentoo and FreeBSD Please report all problems to gtk2hs-users(a)lists.sourceforge.net . Contributions and feedback are also most welcome. Duncan

1 0

RE: Non-H98 crusade, contd.
by Simon Marlow 28 Feb '05

28 Feb '05

On 27 February 2005 10:47, Sven Panne wrote: > OK, let's try to summarize what seems to be the current consensus > about more or less conservative & settled extensions to Haskell98: > > a) rank 2 type signatures > b) polymorphic components for data constructors > c) pattern guards > d) data declarations with no constructors > e) constraints on typeclass methods > f) instances on type synonyms > g) relaxation of polymorphic recursion I'd also like to see at least h) exceptions up until the recent discovery of STM, I would have said concurrency too. Cheers, Simon

1 0

Re: Data.Monoid + collections = trouble
by ross＠soi.city.ac.uk 25 Feb '05

25 Feb '05

[moving from cvs-something to libraries] Sven Panne writes: > Now that I'm finally able to build Hugs again, almost all my stuff is > suddenly non-H98 due to Data.Monoid ('Repeated type variable "a" in > instance head', etc.). This is due to the fact that Data.Map & friends > are importing it, so all our shining new collection code is non-H98 > currently. :-( This should urgently be fixed before releasing GHC 6.4; > is moving the Monoid instances to Data.Monoid the right thing to do? I think the choices are: A) move instance Monoid (Map a) etc to Data.Monoid. B) make Data.Monoid portable by replacing the instance Monoid (a -> a) with one for newtype Endo a = Endo { runEndo :: a -> a } C) make the instance Monoid (a -> a) conditionally compiled. D) mark the four collection modules and any that import them as non-portable (imports Data.Monoid). Although A) goes against the usual policy of instance placement, it will at least solve the problem until the next Monoid instance comes along. Alternative B) makes using this monoid a little more cumbersome, and if this instance isn't in Data.Monoid it's more or less ruled out everywhere. Having different interfaces for different implementations (C) is deeply unattractive. And it's not clear what to do for Hugs.

3 2

RE: Data.Monoid + collections = trouble
by Simon Peyton-Jones 25 Feb '05

25 Feb '05

(A) seems good; it reduces dependencies. And the instance Monoid (Map ...) is in the module that defines Monoid which is one of the two obvious places to look S | -----Original Message----- | From: libraries-bounces(a)haskell.org [mailto:libraries-bounces@haskell.org] On Behalf Of | ross(a)soi.city.ac.uk | Sent: 25 February 2005 11:29 | To: libraries(a)haskell.org | Subject: Re: Data.Monoid + collections = trouble | | [moving from cvs-something to libraries] | | Sven Panne writes: | > Now that I'm finally able to build Hugs again, almost all my stuff is | > suddenly non-H98 due to Data.Monoid ('Repeated type variable "a" in | > instance head', etc.). This is due to the fact that Data.Map & friends | > are importing it, so all our shining new collection code is non-H98 | > currently. :-( This should urgently be fixed before releasing GHC 6.4; | > is moving the Monoid instances to Data.Monoid the right thing to do? | | I think the choices are: | | A) move instance Monoid (Map a) etc to Data.Monoid. | | B) make Data.Monoid portable by replacing the instance Monoid (a -> a) | with one for | | newtype Endo a = Endo { runEndo :: a -> a } | | C) make the instance Monoid (a -> a) conditionally compiled. | | D) mark the four collection modules and any that import them as | non-portable (imports Data.Monoid). | | Although A) goes against the usual policy of instance placement, it will | at least solve the problem until the next Monoid instance comes along. | | Alternative B) makes using this monoid a little more cumbersome, and if | this instance isn't in Data.Monoid it's more or less ruled out everywhere. | | Having different interfaces for different implementations (C) is deeply | unattractive. And it's not clear what to do for Hugs. | _______________________________________________ | Libraries mailing list | Libraries(a)haskell.org | http://www.haskell.org/mailman/listinfo/libraries

1 0

RE: Typeable SockAddr
by Simon Marlow 25 Feb '05

25 Feb '05

On 24 February 2005 17:53, Thomas Jäger wrote: > Also, a Typeable instance of Data.Queue.Queue seems to be missing. Done. Simon

2 1

System.Time.Clock Implementation - Clock.hs (1/1)
by Ashley Yakeley 24 Feb '05

24 Feb '05

OK, I have my own darcs repository for code, but I seem to have trouble pushing it to the empty repository I set up on a server: <http://www.abridgegame.org/pipermail/darcs-users/2005-February/005828.ht ml> In the mean time, attached is a first attempt at an implementation of System.Time.Clock. It should compile OK. Some notes: * I use FFI to call gettimeofday to get the current day. * DiffTime and UTCDiffTime are instances of Num, Integral etc., and as such it represent picoseconds. This isn't ideal with regards to physical dimension, but that's the way the numeric classes are. * Arithmetic on UTC times works by "squeezing" leap seconds, i.e. converting them to POSIX times: 1998-12-31 23:59:60.5 UTC + 0 UTC = 1999-01-01 00:00:00.0 UTC I'm not sure what the best solution is here. * More haddock comments will be forthcoming... -- Ashley Yakeley, Seattle WA {-# OPTIONS -ffi -fglasgow-exts #-} module System.Time.Clock ( -- Modified Julian days and dates (for UT1) ModJulianDay,ModJulianDate, -- absolute time intervals DiffTime,timeToSISeconds,siSecondsToTime, -- UTC arithmetic UTCTime(..),UTCDiffTime,utcTimeToUTCSeconds,utcSecondsToUTCTime, addUTCTime,diffUTCTime, -- getting the current UTC time getCurrentTime ) where import Foreign import Foreign.C -- | standard Julian count of Earth days type ModJulianDay = Integer -- | standard Julian dates for UT1, 1 = 1 day type ModJulianDate = Rational secondPicoseconds :: (Num a) => a secondPicoseconds = 1000000000000 newtype DiffTime = MkDiffTime Integer deriving (Eq,Ord,Num,Enum,Real,Integral) instance Show DiffTime where show (MkDiffTime t) = (show t) ++ "ps" timeToSISeconds :: (Fractional a) => DiffTime -> a timeToSISeconds t = fromRational ((toRational t) / (toRational secondPicoseconds)); siSecondsToTime :: (Real a) => a -> DiffTime siSecondsToTime t = fromInteger (round ((toRational t) * secondPicoseconds)) data UTCTime = UTCTime { utctDay :: ModJulianDay, utctDayTime :: DiffTime } newtype UTCDiffTime = MkUTCDiffTime Integer deriving (Eq,Ord,Num,Enum,Real,Integral) instance Show UTCDiffTime where show (MkUTCDiffTime t) = (show t) ++ "ps" utcTimeToUTCSeconds :: (Fractional a) => UTCDiffTime -> a utcTimeToUTCSeconds t = fromRational ((toRational t) / (toRational secondPicoseconds)) utcSecondsToUTCTime :: (Real a) => a -> UTCDiffTime utcSecondsToUTCTime t = fromInteger (round ((toRational t) * secondPicoseconds)) posixDaySeconds :: (Num a) => a posixDaySeconds = 86400 posixDayPicoseconds :: Integer posixDayPicoseconds = posixDaySeconds * secondPicoseconds unixEpochMJD :: ModJulianDay unixEpochMJD = 40587 posixPicosecondsToUTCTime :: Integer -> UTCTime posixPicosecondsToUTCTime i = let (d,t) = divMod i posixDayPicoseconds in UTCTime (d + unixEpochMJD) (fromInteger t) utcTimeToPOSIXPicoseconds :: UTCTime -> Integer utcTimeToPOSIXPicoseconds (UTCTime d t) = ((d - unixEpochMJD) * posixDayPicoseconds) + min posixDayPicoseconds (toInteger t) addUTCTime :: UTCDiffTime -> UTCTime -> UTCTime addUTCTime x t = posixPicosecondsToUTCTime ((toInteger x) + (utcTimeToPOSIXPicoseconds t)) diffUTCTime :: UTCTime -> UTCTime -> UTCDiffTime diffUTCTime a b = fromInteger ((utcTimeToPOSIXPicoseconds a) - (utcTimeToPOSIXPicoseconds b)) -- Get current time data CTimeval = MkCTimeval CLong CLong ctimevalToPosixPicoseconds :: CTimeval -> Integer ctimevalToPosixPicoseconds (MkCTimeval s mus) = ((fromIntegral s) * 1000000 + (fromIntegral mus)) * 1000000 instance Storable CTimeval where sizeOf _ = (sizeOf (undefined :: CLong)) * 2 alignment _ = alignment (undefined :: CLong) peek p = do s <- peekElemOff (castPtr p) 0 mus <- peekElemOff (castPtr p) 1 return (MkCTimeval s mus) poke p (MkCTimeval s mus) = do pokeElemOff (castPtr p) 0 s pokeElemOff (castPtr p) 1 mus foreign import ccall unsafe "sys/time.h gettimeofday" gettimeofday :: Ptr CTimeval -> Ptr () -> IO CInt getCurrentTime :: IO UTCTime getCurrentTime = with (MkCTimeval 0 0) (\ptval -> do result <- gettimeofday ptval nullPtr if (result == 0) then do tval <- peek ptval return (posixPicosecondsToUTCTime (ctimevalToPosixPicoseconds tval)) else fail ("error in gettimeofday: " ++ (show result)) )

2 2

Typeable SockAddr
by Peter Simons 24 Feb '05

24 Feb '05

I was wondering: Is there any reason why SockAddr (and other types in Network.*) are not instances of Typeable?

2 1

How to implement Data.Map.insertList*?
by Mirko Rahn 24 Feb '05

24 Feb '05

The old FiniteMap module contains the addListToFM* functions that are missing in Data.Map. But how to implement it? First answer: insertList_foldl :: Ord k => [(k,a)] -> Map.Map k a -> Map.Map k a insertList_foldl = flip (foldl ins) where fluc = flip . uncurry ins = fluc Map.insert Second answer: insertList_union :: Ord k => [(k,a)] -> Map.Map k a -> Map.Map k a insertList_union kas = Map.union (Map.fromList kas) Situation and Problem: We already have a map of size n and want to insert a list with m elements. Then we look at the documentation and one gets: * For the first answer we do need O(sum_{i=0}^{m-1}log(n+i)) = O(log((m+n)!/n!)) operations. * For the sencond answer we do need O(m*log(m))+O(n+m) = O(m*log(m)+n+m) operations. These terms are hard to compare but a plot shows that insertList_foldl should be faster than insertList_union. But a testprogram shows that insertList_union is faster (and needs less memory) whatever the sizes of n and m are. So my questions are: Why are the insertList* functions missing? How would the library implementors implement insertList* and why? thanks, -- -- Mirko Rahn -- Tel +49-721 608 7504 -- --- http://liinwww.ira.uka.de/~rahn/ ---

4 5

RE: required fields in Cabal
by Simon Marlow 23 Feb '05

23 Feb '05

On 22 February 2005 13:17, Krasimir Angelov wrote: > On Mon, 21 Feb 2005 17:56:08 -0800, Isaac Jones > <ijones(a)syntaxpolice.org> wrote: >> * What any good package should have: >> package (name and version) :: PackageIdentifier, >> license :: License, >> -- OR? >> licenseFile :: FilePath, >> copyright :: String, >> maintainer :: String, >> synopsis :: String, > > The good package should have these fields but they aren't required if > you only want to build some code with Cabal. This will be the typical > case with VSHaskell. The developer will use Cabal in order to build > his/her projects but may never fill these fields. These fields are > important when the developer decide to distribute the package. I think > that Cabal should check only for "package" field, but Hackage should > check for all fields. Krasimir's right, I'd forgotten about this. Cabal is going to be used not just for distributing libraries & tools, but also just as a simple build system for local code (and why not?), and as the main build system for Visual Haskell. In which case there's no need to have the license, copyright, maintainer or synopsis fields - since you're not necessarily giving the code to anyone. Perhaps if you attempt to do './setup sdist' then it should complain if these fields are missing, but otherwise omitting them shouldn't be fatal. Cheers, Simon

2 1