February 2005 - Libraries

Trie implementation
by Keith Wansbrough 10 Mar '06

10 Mar '06

Hi... I was writing some code yesterday to walk over a directory tree, and needed a Trie. Not seeing one around, I wrote a basic implementation of the functions I needed (attached below). Has anyone else done this? Should I polish it up and offer it for inclusion in Data? --KW 8-)

7 8

NewBinary Library
by Peter Simons 05 May '05

05 May '05

Hi, the NewBinary library used to be available via Darcs at this place: http://www.n-heptane.com/nhlabca/repos/NewBinary It appears, though, that this repository has vanished. Does anyone know what happened? Is anyone aware of the new home of the library? Peter

2 1

Non-H98 crusade, contd.
by Sven Panne 13 Mar '05

13 Mar '05

Apart from the recent Monoid problems, I'm a bit concerned about the non-portable ReadP creeping into some modules, making them non-H98. This affects e.g. Cabal and even something as simple as System.Info (which incorrectly claims that is portable). IMHO we should really keep at least those portable, even if this would involve a little bit more work. Is local universal quantification really needed for those simple parsing tasks? It looks a bit like overkill here... Cheers, S.

15 30

Hierarchical module namespace extension not sufficiently flexible
by Duncan Coutts 07 Mar '05

07 Mar '05

All, So here's the problem: we have a binding to a large foreign library (GTK) which we are trying to fit nicely into hierarchical module name space. It would live under Graphics.UI.Gtk Graphics.UI.Gtk.Button Graphics.UI.Gtk.Frame ... etc Now there are over 100 modules directly under Graphics.UI.Gtk and you don't want to have to import each one of them separately. Of course you will not use all of them in one module but you might reasonably use 20+ of them. So it'd be nice to be able to say: > import Graphics.UI.Gtk or > import qualified Graphics.UI.Gtk as Gtk But now we have a problem. These import directives import a flat namespace, or a flat namespace qualified by a single module alias (ie Gtk in the second example). But the Gtk modules are deliberatly designed to have hierarchical names. You cannot simply combine them all together into a flat namespace without falling back to the trick of prefixing each function name with the module name. So while we would like to be able for users to do this: > import Graphics.UI.Gtk > > ... Button.setLabel ... They will instead have to say: > import Graphics.UI.Gtk > > ... buttonSetLabel ... Which is one of the things that the hierarchical module namespace extension was trying to get rid of! All the other language bindings for Gtk (apart from C) use the former import and useage style. It doesn't make us look good! :-) So my question is: have I overlooked something or is this really not possible at the moment. And secondly, if it is currently not possible is there a 'nice' extension that would allow this sort of thing. (Where nice probably means Haskell98 compatible / 'doesn't' break existing programs) How about: > module Graphics.UI.Gtk ( > > module qualified Graphics.UI.Gtk.Button as Button > ... > ) where > > import Graphics.UI.Gtk.Button or equivalently(?): > module Graphics.UI.Gtk ( > > module qualified Button > ... > ) where > > import Graphics.UI.Gtk.Button as Button Duncan Ps there's a oddity I found where if you say: > module Foo ( > module Bar > ) > > import qualified Bar then module Foo exports precisely nothing. But there's no error or warning.

6 8

Time Library darcs Repository
by Ashley Yakeley 04 Mar '05

04 Mar '05

OK, I finally managed to get darcs to work on my ISP. Do this to get the code: darcs get "http://semantic.org/TimeLib/" Do this to get any subsequent changes: darcs pull I hope to get more implementation done this coming week. -- Ashley Yakeley, Seattle WA

2 2

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