November 2009 - Libraries

Re: [patch] #562: cabal-install update fails going through a HTTP proxy
by Valery V. Vorotyntsev 16 Nov '09

16 Nov '09

On Sun, Nov 15, 2009 at 12:10 AM, Sigbjorn Finne <sigbjorn.finne(a)gmail.com> wrote: > > I've got a tentative fix in for this, not disabling closing altogether (that > wouldn't be compliant with Connection:close handling), but delaying > it until EOF is reached...at least that's the intent. It may not be lazy > enough, but I'm unable to verify either way right now. > > If anyone's interested in testing, the repo contains the changes made -- > > git://code.galois.com/HTTPbis.git/ Thanks, Sigbjorn! I'll test it this Monday (by running `cabal update' with new HTTP). -- vvv

1 1

Proposal: System.FilePath: current directory should be ".", not ""
by Simon Marlow 15 Nov '09

15 Nov '09

See http://hackage.haskell.org/trac/ghc/ticket/2034 to which I have attached a fairly simple patch. All the tests pass. The main change is that splitFileName "foo" = (".", "foo") and takeDirectory "foo" = "." and "." </> x = x Discussion period: 2 weeks (5 October) Cheers, Simon

12 18

Re: Data.Map/Data.IntMap additional features
by Louis Wasserman 11 Nov '09

11 Nov '09

> > but if it were a choice between findMax and > extractWithKey with some Applicative and Monoid and whatever else > magic, I'd use findMax every time :) I'd be wary of putting anything > difficult to describe in a default interface for a basic data type. > Okay, some restatement required here: I'm suggesting this method *only* for Data.Map and Data.IntMap -- not for anything more common -- and I'm not by any means suggesting that I'd use this in every case over findMin, but merely using findMin as an example application. I *do* think it's okay for a commonly used module to have some advanced methods for advanced users. > And of course creating, inserting, updating, and deleting. Rarely key > and value mapping. Any interface that provides those 9 functions will > satisfy all needs I can think of. If they can all be implemented with > extractWithKey, then great, put that in the class interface and define > the rest with defaulting methods. > Quite honestly, I use key and value mapping all the time, in most applications I need maps for, and extractWithKey generalizes (and makes more efficient) several applications use regularly. Here's one more example of an application that can't be done nicely or efficiently with application of the currently existing methods: extractMinPair :: Map k1 (Map k2 v) -> Maybe (((k1, k2), v), Map k1 (Map k2 v)) extractMinPair m = do ((k1, m1), m') <- minViewWithKey m ((k2, v), m1') <- minViewWithKey m1 return (((k1, k2), v), if null m1' then m' else insert k1 m1' m) (In particular, this is the extractMin implementation from the generalized trie on keys of type (k1, k2), which motivated the method in the first place.) Note that in most cases, we'll need to insert m1' back into m, which is really ugly, and definitely destroys the nicer recursive properties that I'm looking for. Rather, if I can extract information and modify a value from the map with a single use of extractWithKey, extractMinPair m = getFirst $ extractWithKey (\ k1 m1 -> fmap (\ ((k2, v), m1') -> (((k1, k2), v), guardNull m1')) (minViewWithKey m1)) m where guardNull m = if null m then Nothing else Just m In the list of methods you named as particularly critical, you talked about creating, inserting, updating, and deleting; you actually didn't mention looking up values, which I assume you meant to -- since what's the point of the map if you can't look up any values? extractWithKey is useful when I want to look up a value, and edit it, at the same time, without an exra O(log n) pass, and it specifically and elegantly takes care of the case where we want to simultaneously look up and edit the minimum or maximum value of a map. Louis Wasserman wasserman.louis(a)gmail.com http://profiles.google.com/wasserman.louis

2 1

seq as type class method
by Henning Thielemann 09 Nov '09

09 Nov '09

I have read in the History of Haskell, that originally 'seq' should be a method of a type class, that can be automatically derived by a 'deriving' clause. It was also mentioned that this clean solution was dropped because of particular experiences with developing a parser. However the arguments appeared to me, like these were problems of debugging. I think that hacks are ok for debugging, such as dynamically finding a Show method for a message for 'error', although no Show constraint was given in the type signature. But I think that hacks are not ok for regular programming. In the History of Haskell it is told that the hack of making 'seq' not a member of a type class leads to invalid fusion optimization. While it is not possible to get rid of 'seq' anymore, wouldn't it be feasible to define a new type class with a new 'seq' - maybe just a new module, from where I can import the new 'seq' instead of the one from Prelude? This would also allow us to handle cases like this one: When I have a datatype like data T = A | B | C and I use 'seq' for it a lot, and once I have to switch to data T = Cons Int S data S = A | B | C and I like that 'seq' on T is strict both on Cons and on the constructors of S, this would be possible using a custom instance Seq T. Actually in stream-fusion:Data.Stream I found such a class, called Unlifted. How about moving this into a separate package? class Unlifted a where -- | This expose function needs to be called in folds/loops that consume -- streams to expose the structure of the stream state to the simplifier -- In particular, to SpecConstr. -- expose :: a -> b -> b expose = seq -- | This makes GHC's optimiser happier; it sometimes produces really bad -- code for single-method dictionaries -- unlifted_dummy :: a unlifted_dummy = error "unlifted_dummy"

8 14

Three patches for cabal
by Niklas Broberg 09 Nov '09

09 Nov '09

(Trying again since my previous patches were too big for the list.) While doing a survey[1] of the extensions registered with Cabal, I came across two warts in the list of constructors, and one constructor that should be deprecated. First there's the constructor called TransformListComp, which should really be named GeneralizedListComp, since the constructor should describe the extension and not the implementation scheme. Second there's the constructor NoMonoPatBinds, which actually describes the default Haskell 98 behavior, even if GHC has a different default. It's GHC's behavior that is the extension, so the constructor in cabal should really be named MonoPatBinds. Also, the PatternSignatures constructor has been deprecated in GHC and superceded by ScopedTypeVariables. The attached patches (three in one file) adds the proposed new constructors, deprecates the old ones, and adds documentation. Cheers, /Niklas

8 15

traceM and traceShowM
by Martijn van Steenbergen 05 Nov '09

05 Nov '09

Hello, I propose the addition of the following two functions to module Debug.Trace: > traceM :: Monad m => String -> m () > traceM msg = trace msg (return ()) > > traceShowM :: (Show a, Monad m) => a -> m () > traceShowM = traceM . show These functions allow tracing in any do-block. I often define them myself; I think they are useful in general. Deadline: 23 October 2009. Martijn.

12 20

Data.IntMap/IntSet inconsistencies
by Louis Wasserman 04 Nov '09

04 Nov '09

> > 2) the types are not general enough : like zip you should be able to > take functions f : a->b->c instead of what intersectionWith forces you > to do (f: a->b->a). > According to my documentation, the type of intersectionWith *is* (f :: a -> b -> c). On another note, with respect to my proposed change: I concede that it might be too general for some people. Here's a simpler change that I'd like: to be able to project information out of a value and modify it simultaneously, so simply alterProject :: (Maybe a -> (z, Maybe a)) -> k -> Map k a -> (z, Map k a ) for a specific key. and perhaps something similar for the min/max operations. I'd very much like to be able to do more general things than just min/max operations with this sort of generality -- hence the Alternative approach in my original proposal. Louis Wasserman wasserman.louis(a)gmail.com http://profiles.google.com/wasserman.louis

2 1

Network library broken on Windows with GHC 6.12rc1
by ndmitchell＠gmail.com 04 Nov '09

04 Nov '09

Hi, The subject says it all really. Using: network-2.2.1.5 from Cabal Windows XP, Admin mode Cygwin 1.6 The Glorious Glasgow Haskell Compilation System, version 6.12.0.20091010 $ runhaskell Setup configure Setup.hs:3:0: Warning: In the use of `defaultUserHooks' (imported from Distribution.Simple): Deprecated: "Use simpleUserHooks or autoconfUserHooks, unless you n eed Cabal-1.2 compatibility in which case you must stick with defaultUserHooks" Warning: defaultUserHooks in Setup script is deprecated. Configuring network-2.2.1.5... checking build system type... i686-pc-cygwin checking host system type... i686-pc-cygwin checking for gcc... gcc checking for C compiler default output file name... a.exe checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... .exe checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for an ANSI C-conforming const... yes checking how to run the C preprocessor... gcc -E checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking limits.h usability... yes checking limits.h presence... yes checking for limits.h... yes checking for stdlib.h... (cached) yes checking for sys/types.h... (cached) yes checking for unistd.h... (cached) yes checking winsock2.h usability... no checking winsock2.h presence... yes configure: WARNING: winsock2.h: present but cannot be compiled configure: WARNING: winsock2.h: check for missing prerequisite headers? configure: WARNING: winsock2.h: see the Autoconf documentation configure: WARNING: winsock2.h: section "Present But Cannot Be Compiled" configure: WARNING: winsock2.h: proceeding with the preprocessor's result configure: WARNING: winsock2.h: in the future, the compiler will take precedence configure: WARNING: ## ------------------------------------ ## configure: WARNING: ## Report this to libraries(a)haskell.org ## configure: WARNING: ## ------------------------------------ ## checking for winsock2.h... yes checking ws2tcpip.h usability... no checking ws2tcpip.h presence... yes configure: WARNING: ws2tcpip.h: present but cannot be compiled configure: WARNING: ws2tcpip.h: check for missing prerequisite headers? configure: WARNING: ws2tcpip.h: see the Autoconf documentation configure: WARNING: ws2tcpip.h: section "Present But Cannot Be Compiled" configure: WARNING: ws2tcpip.h: proceeding with the preprocessor's result configure: WARNING: ws2tcpip.h: in the future, the compiler will take precedence configure: WARNING: ## ------------------------------------ ## configure: WARNING: ## Report this to libraries(a)haskell.org ## configure: WARNING: ## ------------------------------------ ## checking for ws2tcpip.h... yes checking wspiapi.h usability... no checking wspiapi.h presence... no checking for wspiapi.h... no checking arpa/inet.h usability... no checking arpa/inet.h presence... yes configure: WARNING: arpa/inet.h: present but cannot be compiled configure: WARNING: arpa/inet.h: check for missing prerequisite headers? configure: WARNING: arpa/inet.h: see the Autoconf documentation configure: WARNING: arpa/inet.h: section "Present But Cannot Be Compiled" configure: WARNING: arpa/inet.h: proceeding with the preprocessor's result configure: WARNING: arpa/inet.h: in the future, the compiler will take precedenc e configure: WARNING: ## ------------------------------------ ## configure: WARNING: ## Report this to libraries(a)haskell.org ## configure: WARNING: ## ------------------------------------ ## checking for arpa/inet.h... yes checking netdb.h usability... no checking netdb.h presence... yes configure: WARNING: netdb.h: present but cannot be compiled configure: WARNING: netdb.h: check for missing prerequisite headers? configure: WARNING: netdb.h: see the Autoconf documentation configure: WARNING: netdb.h: section "Present But Cannot Be Compiled" configure: WARNING: netdb.h: proceeding with the preprocessor's result configure: WARNING: netdb.h: in the future, the compiler will take precedence configure: WARNING: ## ------------------------------------ ## configure: WARNING: ## Report this to libraries(a)haskell.org ## configure: WARNING: ## ------------------------------------ ## checking for netdb.h... yes checking netinet/in.h usability... no checking netinet/in.h presence... yes configure: WARNING: netinet/in.h: present but cannot be compiled configure: WARNING: netinet/in.h: check for missing prerequisite headers? configure: WARNING: netinet/in.h: see the Autoconf documentation configure: WARNING: netinet/in.h: section "Present But Cannot Be Compiled" configure: WARNING: netinet/in.h: proceeding with the preprocessor's result configure: WARNING: netinet/in.h: in the future, the compiler will take preceden ce configure: WARNING: ## ------------------------------------ ## configure: WARNING: ## Report this to libraries(a)haskell.org ## configure: WARNING: ## ------------------------------------ ## checking for netinet/in.h... yes checking netinet/tcp.h usability... no checking netinet/tcp.h presence... yes configure: WARNING: netinet/tcp.h: present but cannot be compiled configure: WARNING: netinet/tcp.h: check for missing prerequisite headers? configure: WARNING: netinet/tcp.h: see the Autoconf documentation configure: WARNING: netinet/tcp.h: section "Present But Cannot Be Compiled" configure: WARNING: netinet/tcp.h: proceeding with the preprocessor's result configure: WARNING: netinet/tcp.h: in the future, the compiler will take precede nce configure: WARNING: ## ------------------------------------ ## configure: WARNING: ## Report this to libraries(a)haskell.org ## configure: WARNING: ## ------------------------------------ ## checking for netinet/tcp.h... yes checking sys/socket.h usability... no checking sys/socket.h presence... yes configure: WARNING: sys/socket.h: present but cannot be compiled configure: WARNING: sys/socket.h: check for missing prerequisite headers? configure: WARNING: sys/socket.h: see the Autoconf documentation configure: WARNING: sys/socket.h: section "Present But Cannot Be Compiled" configure: WARNING: sys/socket.h: proceeding with the preprocessor's result configure: WARNING: sys/socket.h: in the future, the compiler will take preceden ce configure: WARNING: ## ------------------------------------ ## configure: WARNING: ## Report this to libraries(a)haskell.org ## configure: WARNING: ## ------------------------------------ ## checking for sys/socket.h... yes checking sys/uio.h usability... no checking sys/uio.h presence... yes configure: WARNING: sys/uio.h: present but cannot be compiled configure: WARNING: sys/uio.h: check for missing prerequisite headers? configure: WARNING: sys/uio.h: see the Autoconf documentation configure: WARNING: sys/uio.h: section "Present But Cannot Be Compiled" configure: WARNING: sys/uio.h: proceeding with the preprocessor's result configure: WARNING: sys/uio.h: in the future, the compiler will take precedence configure: WARNING: ## ------------------------------------ ## configure: WARNING: ## Report this to libraries(a)haskell.org ## configure: WARNING: ## ------------------------------------ ## checking for sys/uio.h... yes checking sys/un.h usability... no checking sys/un.h presence... yes configure: WARNING: sys/un.h: present but cannot be compiled configure: WARNING: sys/un.h: check for missing prerequisite headers? configure: WARNING: sys/un.h: see the Autoconf documentation configure: WARNING: sys/un.h: section "Present But Cannot Be Compiled" configure: WARNING: sys/un.h: proceeding with the preprocessor's result configure: WARNING: sys/un.h: in the future, the compiler will take precedence configure: WARNING: ## ------------------------------------ ## configure: WARNING: ## Report this to libraries(a)haskell.org ## configure: WARNING: ## ------------------------------------ ## checking for sys/un.h... yes checking for readlink... yes checking for symlink... yes checking for struct msghdr.msg_control... yes checking for struct msghdr.msg_accrights... no checking for struct sockaddr.sa_len... no checking for in_addr_t in netinet/in.h... yes checking for SO_PEERCRED and struct ucred in sys/socket.h... yes checking for _head_libws2_32_a in -lws2_32... yes checking for getaddrinfo... no checking for getaddrinfo if WINVER is 0x0501... no checking for gai_strerror... no checking whether AI_ADDRCONFIG is declared... no checking whether AI_ALL is declared... no checking whether AI_NUMERICSERV is declared... no checking whether AI_V4MAPPED is declared... no checking for sendfile in sys/sendfile.h... no checking for sendfile in sys/socket.h... no checking for gethostent... no configure: creating ./config.status config.status: creating network.buildinfo config.status: creating include/HsNetworkConfig.h $ runhaskell Setup build Setup.hs:3:0: Warning: In the use of `defaultUserHooks' (imported from Distribution.Simple): Deprecated: "Use simpleUserHooks or autoconfUserHooks, unless you n eed Cabal-1.2 compatibility in which case you must stick with defaultUserHooks" Preprocessing library network-2.2.1.5... Network\Socket.hsc: In function `main': Network\Socket.hsc:994: error: invalid application of `sizeof' to incomplete typ e `ucred' Network\Socket.hsc:994: error: invalid application of `sizeof' to incomplete typ e `ucred' Network\Socket.hsc:994: error: invalid application of `sizeof' to incomplete typ e `ucred' Network\Socket.hsc:999: error: `SO_PEERCRED' undeclared (first use in this funct ion) Network\Socket.hsc:999: error: (Each undeclared identifier is reported only once Network\Socket.hsc:999: error: for each function it appears in.) Network\Socket.hsc:1000: error: dereferencing pointer to incomplete type Network\Socket.hsc:1001: error: dereferencing pointer to incomplete type Network\Socket.hsc:1002: error: dereferencing pointer to incomplete type compiling dist\build\Network\Socket_hsc_make.c failed command was: C:\ghc\ghc-6.12.0.20091010\mingw\bin\gcc.exe -c -BC:\ghc\ghc-6.12.0 .20091010\gcc-lib -IC:\ghc\ghc-6.12.0.20091010\include\mingw -D__GLASGOW_HASKELL __=612 -Iinclude -DCALLCONV=ccall -DBASE4 -IC:\ghc\ghc-6.12.0.20091010\base-4.2. 0.0\include -IC:\ghc\ghc-6.12.0.20091010/include -IC:\ghc\ghc-6.12.0.20091010/in clude -IC:/ghc/ghc-6.12.0.20091010/lib/include/ dist\build\Network\Socket_hsc_ma ke.c -o dist\build\Network\Socket_hsc_make.o Thanks, Neil

7 9

Data.Map/Data.IntMap additional features
by Louis Wasserman 03 Nov '09

03 Nov '09

Hey all, Amid the discussion of inconsistencies between Data.IntMap and Data.Map, I thought I'd throw in some more ideas. I've been working on a rather thorough generalized trie map implementation, which has done nothing if not force me to make really very generalized signatures for every method offered by Data.Map, etc. Some of these generalizations are, I think, independently useful, and I wanted to throw them out for discussion before creating a ticket. A function that I call extract/extractWith/extractWithKey: extractWithKey :: Alternative f => (k -> a -> f (z, Maybe a)) -> Map k a -> f (z, Map k a) which is actually defined as follows: > extractWithKey f (Bin n kx x l r) = fmap (\ (z, l') -> (z, Bin n kx x l' r)) (extractWithKey f l) <|> > fmap (\ (z, x') -> (z, maybe (glue l r) (\ xx -> bin kx xx l r) x')) (f kx x) <|> fmap (\ (z, r') -> (z, Bin n kx x l r')) (extractWithKey f r) > extractWithKey f Nil = empty If m is fromList [(k1, x1), (k2, x2), ..., (kn, xn)], then > fst <$> extractWithKey (\ k a -> pure (f k a, <whatever>)) m == f k1 x1 <|> f k2 x2 <|> ... <|> f kn xn and then the second component is obtained by modifying a single element accordingly and taking the alternative over every element to choose from. A few observations: with an appropriate Alternative instance for Data.Monoid.First and Data.Monoid.Last, > extractWithKey (\ k a -> return ((k, a), Nothing)) m == First (minViewWithKey m) so this generalizes minViewWithKey and maxViewWithKey according to the First Alternative instance. (Note that the extractWithKey implementation is also O(log n), because the natural First Alternative instance will ignore the irrelevant pathways lazily, > extractWithKey (\ k a -> if p k a then pure ((k, a), Nothing) else empty) in the First Alternative instance, will extract the first element of the map that satisfies p, or will return Nothing if there is no such element, and will take O(i) time to do so if the first satisfying element is at index i, > mapPermK :: Int -> Map k a -> [[(k, a)]] > mapPermK 0 m = [[]] > mapPermK (n+1) m = do ((k1, a1), m') <- extractWithKey (\ k a -> return ((k, a), Nothing)) m > liftM ((k1, a1) :) (mapPermK n m) returns a list of all permutations of k distinct associations from the map m, and does it exactly as lazily as one might hope. (Generating combinations efficiently is somewhat harder, and I'm not sure this approach grants much in the way of additional efficiency beyond a couple other approaches I can think of.) In any event, you get the idea: this is a preposterously general method, albeit difficult to describe. It is moderately easier to describe the individual projections, which I name arbitrarily, about :: Alternative f => (k -> a -> f z) -> Map k a -> f z modify :: Alternative f => (k -> a -> f (Maybe a)) -> Map k a -> f (Map k a) Finally, I'll define neighborhood. Internally, neighborhood has the signature neighborhood :: Ord k => k -> Map k a -> (Last (k, a), Maybe a, First (k, a)) where neighborhood k m = (sup [(k', a) | k' < k], lookup k m, inf [(k', a) | k' > k]) == case splitLookup k m of (mL, v, mR) -> (fmap fst (maxViewWithKey mL), v, fmap fst (minViewWithKey mR)) is defined as follows: neighborhood k Tip = (empty, empty, empty) neighborhood k (Bin _ kx x l r) = case compare k kx of LT -> case neighborhood k l of (lb, v, ub) -> (lb, v, ub <|> pure (kx, x)) EQ -> (Last (fmap fst (maxViewWithKey l)), Just x, First (fmap fst (minViewWithKey r))) -- we can also use the *about* generalization here, since we only need the minimum and maximum associations GT -> case neighborhood k r of (lb, v, ub) -> (pure (kx, x) <|> lb, v, ub) Using MonadPlus or Alternative instances for First and Last are rather elegant here, and I strongly support adding their Applicative, Alternative, Monad, and MonadPlus instances to base. Louis Wasserman wasserman.louis(a)gmail.com http://profiles.google.com/wasserman.louis

3 2

Data.IntMap/IntSet inconsistencies
by Ben 03 Nov '09

03 Nov '09

while we're on the topic, i'm curious as to why there isn't a zip / join-type method for IntMaps / IntSets. (i use the term join in reference to SQL.) i have defined some in the past like -- maybe not efficient joinOuterWithKey f m1 m2 d1 d2 = M.union (M.intersectionWithKey f m1 m2) $ M.union (M.mapWithKey f1 $ m1 M.\\ m2) (M.mapWithKey f2 $ m2 M.\\ m1) where f1 k l = f k l d2 f2 k r = f k d1 r -- left biased joinLeftWithKey f m1 m2 d2 = M.union (M.intersectionWithKey f m1 m2) (M.mapWithKey f1 $ m1 M.\\ m2) where f1 k a = f k a d2 -- right biased joinRightWithKey f m1 m2 d1 = M.union (M.intersectionWithKey f m1 m2) (M.mapWithKey f2 $ m2 M.\\ m1) where f2 k b = f k d1 b joinInnerWithKey = M.intersectionWithKey but 1) these are probably not terribly efficient, as they do multiple traversals 2) the types are not general enough : like zip you should be able to take functions f : a->b->c instead of what intersectionWith forces you to do (f: a->b->a). the proper implementation should be easy, and trivially generalizes intersectionWith and friends, i believe. or am i missing something? best, ben

1 0