July 2007 - Libraries

darcs patch: s6_addr32 is undefined on darwin. Added an AC check a...
by Thomas Schilling 13 Jul '07

13 Jul '07

Fri Jun 22 18:58:52 CEST 2007 Thomas Schilling <nominolo(a)gmail.com> * s6_addr32 is undefined on darwin. Added an AC check and a definition taken from the NetBSD sources.

3 8

Proposal: Data.Stream
by Wouter Swierstra 13 Jul '07

13 Jul '07

Dear all, I just uploaded a fairly unspectacular package Data.Stream to Hackage. It implements quite a few operations on streams (infinite lists), analogous to those defined in Data.List. Sometimes it is just good to know a list is infinite. * Haddock documentation: http://www.cs.nott.ac.uk/~wss/repos/Stream/ dist/doc/html/ * Hackage homepage: http://hackage.haskell.org/cgi-bin/hackage- scripts/package/Stream-0.1 I know of a few libraries that implement this package themself (Ross Paterson's arrow library and my IOSpec spring to mind). I think it's fairly uncontroversial, and would like to see it added to base (I realize that there are also proposals to clean up base to speed up the build of ghc), or at least, the standard libraries. What's the right way to accomplish this? Send a darcs patch to Ian? Submit a trac ticket? Thanks, Wouter

13 25

Re: Optimising words
by Neil Mitchell 11 Jul '07

11 Jul '07

Hi > > Now we have eliminated an extra isSpace test per character, and as it > > happens, isSpace is very slow. > > Isn't it possible to improve isSpace, too? Yes, most definitely. But unless we improve it to the stage where it takes 0 time, its still worth eliminating useless additional calls. Thanks Neil

1 0

Optimising words
by Neil Mitchell 10 Jul '07

10 Jul '07

Hi While benchmarking a word count program I found that it wasn't running as fast as it could. I traced this back to the original definition of words, which isn't as good as it could be: This is the version in Base: words :: String -> [String] words s = case dropWhile isSpace s of "" -> [] s' -> w : words s'' where (w, s'') = break isSpace s' We can instantiate s' with s:ss, since we already pattern match: words :: String -> [String] words s = case dropWhile isSpace s of "" -> [] s:ss -> w : words s'' where (w, s'') = break isSpace (s:ss) Now we know that s is not a space, since if it was the dropWhile would have removed it. This means that we don't need to test it, and can put it straight on to w: words :: String -> [String] words s = case dropWhile isSpace s of "" -> [] s:ss -> (s:w) : words s'' where (w, s'') = break isSpace ss Now we have eliminated an extra isSpace test per character, and as it happens, isSpace is very slow. Is my reasoning correct? If so, can we make this optimisation? Thanks Neil

3 5

Read TypeRep? standard for typeRepKey?
by Claus Reinke 10 Jul '07

10 Jul '07

is there a reason why there is a Show TypeRep, but no Read TypeRep? and isn't it time to standardise typeRepKeys? something based on package name/version, module, name, so that one could rely on being able to read in what one writes out, and on TypeRep-based maps being compatible accross programs (at least as long as the versions match)? i was thinking about improving the reading of existentially typed data (see haskell-cafe thread) of that name, and was surprised to find that Data.Typeable doesn't quite support these things. or is there a workaround i'm missing? claus

1 0

Applicative Identity
by Dan Doel 07 Jul '07

07 Jul '07

Hello, I ran into a tiny snag recently, attempting to write a library for a monad + transformer. If one uses MTL, it typically nice to be able to do something like the following: newtype FooT m a = FooT { runFooT :: ... } ... instances for FooT newtype Foo a = Foo { unFoo :: FooT Identity a } deriving (Functor, Monad, ...) Since the normal monad is just the case of the transformer parameterized by the Identity monad. However, we now have the Control.Applicative library, which sits in between Functors and Monads, so it seems reasonable to provide instances of those, as well. However, Identity (and, for that matter, all of the monads in MTL, I think) lacks an appropriate instance for Applicative, so generalized deriving can't be used there. On the other side, Control.Applicative has a newtype WrappedMonad, which provides such instances for an arbitrary monad. However, it has the reverse problem: There are no Monad (and related) instances for WrappedMonad. So, it seems that the full gamut of instances can't be automatically derived in this way, as the libraries currently stand. Now, this clearly isn't a dire situation, but it might be nice to fill in one or both of these gaps so the libraries play a little nicer with each other. For instance, I think the Identity instance is as simple as: instance Applicative Identity where pure = Identity f <*> a = Identity $ runIdentity f (runIdentity a) And, of course, in general, one can fill in the MTL instances as easily as: instance Applicative MTLType where pure = return (<*>) = ap Although it may be less trivial with transformers (though I assume Applicative a => Applicative (T a) aren't too hard). Many thanks, Dan Doel

1 0

Proposal #1464: add dropPrefix to Data.List
by Ian Lynagh 06 Jul '07

06 Jul '07

Hi all, I seem to have a copy of this function in everything I write sooner or later, so I'd like to propose its addition to Data.List. It strips a prefix from a list and, if successful, returns the tail. I often use it with pattern guards: foo :: String -> IO () foo x | Just y <- dropPrefix "foo=" = putStrLn ("foo is " ++ show y) foo _ = putStrLn "Unknown" but you can of course achieve the same by using case etc. The definition is: dropPrefix :: Eq a => [a] -> [a] -> Maybe [a] dropPrefix [] ys = Just ys dropPrefix (x:xs) (y:ys) | x == y = dropPrefix xs ys dropPrefix _ _ = Nothing Let's try 11 July for a discussion deadline. Thanks Ian

20 26

Supported Windows versions (was: Re: unix package)
by Esa Ilari Vuokko 06 Jul '07

06 Jul '07

On 6/30/07, Ian Lynagh <igloo(a)earth.li> wrote: > On Sat, Jun 30, 2007 at 08:01:09PM +0300, Esa Ilari Vuokko wrote: > > > > Indeed. Also, as Win32 maintainer, I am unsure how far we are supporting > > old Windowses. When I tentavily asked some people about it, they thought > > we should continue to support old Windows versions. > > Our (GHC) plan is not to support Win 9x (and Me?) from 6.8 onwards, as > we don't have machines on which test it or debug problems. I don't think > the installers that we make now install a GHC that works on Win 9x, but > I could be wrong. Thanks for info! This also might mean that GHC could be made to exclusively use IO Completion Ports in Windows instead of hacks now in place. Maybe this is a good place to ask for opinions. Anyone have any or know of need to support old Windows versions? I am also curious if someone still writes software for pre-Windows 2000 NTs, as there's some nice API functions in Windows 2000. Thanks, Esa

3 4

Gtk2Hs 0.9.12 release candidate 1 available for testing
by Duncan Coutts 04 Jul '07

04 Jul '07

All, The first release candidate for Gtk2Hs 0.9.12 is now available. (The actual version number is 0.9.11.3) The source tarball and windows installer are available: http://haskell.org/gtk2hs/gtk2hs-0.9.11.3.tar.gz (md5sum 72ae779f8d12c6013787cc735272f723) http://haskell.org/gtk2hs/gtk2hs-0.9.11.3.exe (md5sum e1be8f38d33d76492c078cb66a790db1) Changes since 0.9.11: * ps, pdf and svg cairo backends are now supported * drag & drop support added * can run mainGUI in GHCi after :reload * Graphics.SOE.Gtk now works with threaded rts and GHCi * Windows build now includes OpenGL and SourceView packages * c2hs no longer chokes on some system headers (eg glibc-2.4) * various bug fixes and minor code cleanups * major overhaul of the code generator (will help binding gtk-2.10) Please test this on your platform and report success or failures to the gtk2hs-users list. Reports for less common platforms, processors architectures and older versions of GHC and Gtk+ are particularly appreciated. This release has seen less churn than most, so we expect relatively few build issues. We're expecting more significant changes in the next major release, including support for the new features in Gtk+ 2.10 and 2.12, a simplified signals and properties api which should make for considerably simpler documentation. In the long term we also expect to modularise Gtk2Hs and build each component using Cabal. For testing this release, try building, installing and then run: make installcheck This should build all the demo programs that are appropriate for your configuration. Running a selection of them would be good. Then if you have any other programs that use Gtk2Hs then testing those with this new release would be good. Windows notes: The installer expects GHC 6.6.1. (As always if you need a build for a different version of GHC then that's possible by building from source.) If anyone thinks we should include support for older versions of GHC in the windows installer (eg 6.4.2 or 6.6) then to say so. For example the last Gtk2Hs release included support for both 6.4.2 and 6.6. The windows build now includes the gtkglext and sourceview packages, but not svgcairo as that has pretty heavy dependencies. This makes the download a bit bigger, but on the other hand currently it includes support for only one GHC version, so overall the installer is rather smaller than in the last release. Duncan

1 0

FW: [Haskell-cafe] Sparse documentation
by Simon Peyton-Jones 04 Jul '07

04 Jul '07

A reasonable question from Michael. Can someone who’s more deeply involved in library development answer? Cc haskell-cafe. An easy “here’s how to contribute” wiki page would be great. Michael: I think we are talking about library documentation rather than documentation of GHC’s internals. But your question stands. Thanks Simon From: Michael T. Richter [mailto:ttmrichter@gmail.com] Sent: 04 July 2007 08:24 To: Simon Peyton-Jones Cc: haskell-cafe(a)haskell.org Subject: RE: [Haskell-cafe] Sparse documentation On Wed, 2007-04-07 at 08:03 +0100, Simon Peyton-Jones wrote: | Fortunately, some kind soul has gone through and converted the | documentation to haddock format: | http://hackage.haskell.org/trac/ghc/ticket/1410 | | So it'll all appear in the html docs in the next version. In the mean | time one can look at the haddock comments in the source: | http://darcs.haskell.org/packages/mtl/Control/Monad/ Furthermore, you can always get the GHC HEAD documentation here http://www.haskell.org/ghc/dist/current/docs >From there you can get to Control.Monad, which indeed shows at least some documentation. Simon, if the less-talented among us (like me) want to contribute to GHC's docs -- and especially documenting the libraries -- what's the best way to go about this? I'm not too comfortable with the notion of just going into GHC's guts and Haddocking the comments, contributing patches willy-nilly because I'd not be certain I did the job right, that I explained things correctly where I had to amplify, etc. Is there some kind of documentation team we poor souls could interact with to assist? -- Michael T. Richter <ttmrichter(a)gmail.com<mailto:ttmrichter@gmail.com>> (GoogleTalk: ttmrichter(a)gmail.com) When debugging, novices insert corrective code; experts remove defective code. (Richard Pattis)

1 0