December 2011 - Libraries

Proposal: Use time rather than old-time in directory
by Ian Lynagh 17 Sep '14

17 Sep '14

Hi all, This proposal is to change directory to use the time package rather than the old-time package. This will hopefully be a significant step towards actually making the transition in general. I'm not sure if POSIXTime or UTCTime is the better type to use. Does anyone know? I started off with UTCTime, then switched to POSIXTime as UTCTime didn't have a Show instance. I've since found that actually UTCTime has both Show and Read instances, but they are orphaned. So actually, if UTCTime is the better type then switching back to UTCTime would allow us to fix this comment in hpc: -- We would rather use ClockTime in Mix, but ClockTime has no Read instance and simplify the code slightly. Attached are patches for directory, hpc and ghc. Suggested discussion period: Until 5th Nov 2011. Thanks Ian

14 35

Proposal: Add newUniqueSTM to Data.Unique
by Edward Kmett 28 Apr '12

28 Apr '12

Data.Unique's newUnique uses atomically internally to update a TVar. Consequently attempting to "unsafeIOToSTM newUnique" to allocate a Unique within an STM transaction blows you sky high. The proposal is to split the definition of newUnique into: newUnique = atomically newUniqueSTM and expose newUniqueSTM. Alternately, since bug #3838 has been resolved, we could revert to using an IORef, which would avoid the wart of having us have an overtly IO action detonate because of an internal implementation detail of using STM. Since, there are two paths forward, I haven't put forward a patch, but wanted to open a discussion. Discussion Period: 2 weeks. -Edward Kmett

6 12

Improve System.Environment haddocks
by Gwern Branwen 07 Feb '12

07 Feb '12

17:52:34 < goodgrue> Is there a way to change the environment variables associated with Xmonad.Prompt.Shell at runtime? e.g. I'd like to be able to modify $http_proxy and have that affect subsequently launched processes. 17:55:31 < gwern> goodgrue: that'd be kind of hard. you could prepend a mpodification of $HTTP_PROXY to each command 17:56:10 < gwern> ideally you'd modify xmonad's own environment 17:56:33 < goodgrue> gwern: yeah, the latter is what I was thinking of. is that possible? 17:57:08 < gwern> shell uses `getEnv` from System.Environment but there's no setEnv! 17:57:21 < gwern> if there were, you could probably bind it to a key and use a prompt 17:58:44 < goodgrue> Hm...sounds like this may be a nice piece of missing functionality. is there any reason you can think of that i wouldn't be able to implement setEnv myself? 17:59:04 < gwern> http://hackage.haskell.org/trac/ghc/ticket/3587 17:59:14 < gwern> looks like 'putEnv' may be the real name -- gwern http://www.gwern.net

2 3

Add meaningful instances to ZipList
by Daniel Peebles 02 Feb '12

02 Feb '12

I noticed that the ZipList newtype in Control.Applicative has no derived instances at all. We can't show a ZipList, check it for equality, or do anything to it except unpack it or treat it like an Applicative or Functor. It seems fairly uncontroversial to suggest adding some instances for it, but there are some minor questions to address: the obvious instances to add might be Eq, Ord, Show, Read, and possibly Typeable and/or Data. Are there any others I've missed? For the Read/Show instances, do we want manual ones that don't use the verbose record-style output? Since it's just defined as data ZipList a = ZipList { getZipList :: [a] } to get an easy accessor (does anyone actually use getZipList as a field for record updates?), it might be easier to write the projection manually and change the definition to data ZipList a = ZipList [a] with a separate getZipList function, so the deriving mechanism can give us a less noisy Show instance. Discussion period: 2 weeks, I guess - Dan

6 9

Proposal: add 'state' to the MonadState class
by Twan van Laarhoven 22 Jan '12

22 Jan '12

Hello list, Currently the 'state' function is only defined for the State type (aka StateT Identity): state :: (s -> (a, s)) -> State s a state f = StateT (Identity . f) But this function makes sense for all MonadState instances. I therefore propose to either add it to the MonadState class: class MonadState s m | m -> s where ... state :: (s -> (a,s)) -> m a state f = do s <- get let (a,s') = f s set s' return a or as a stand alone function like modify. I personally prefer to add it to the class, since that allows for a more efficient implementation. In particular: instance Monad m => MonadState s (StateT s m) where .... state = StateT (return . f) Discussion period: 2 weeks (ends October 10th) Twan

6 10

Proposal: Overloaded Quotes for Template Haskell
by Michael D. Adams 18 Jan '12

18 Jan '12

(This was originally posted to haskell-cafe, but I've since learned that haskell-libraries is a more appropriate venue. Apologies for the resulting cross-post.) == Description == I would like to propose a generalization of the types of quote forms (i.e. "[| ... |]") and nested splices (i.e. "[| ... $( ... ) ... |]"). Currently quote forms have type "Q Exp" and nested splices expect their contents to have type "Q Exp". I propose that quote forms have type "forall m. Quasi m => m Exp" and nested splices expect a body of type "m Exp" where the "m" of the nested splice is the same as the "m" of the quote form that it is inside of. Top-level splices (i.e. those not inside a "[| ... |]") continue to expect their body to have type "Q Exp", and do *not* have a generalized to the type. (Otherwise, the compiler wouldn't know how to evaluate the monad. Nested splices do not have this problem as it is the responsibility of the user code between the splice and its enclosing quote to determine how to evaluate the monad.) Note that generalizing the types of quotes in this way is very similar to the generization of the types of strings that happens with the "-XOverloadedStrings" flag. However, unlike with strings which require an extra class (i.e. "IsString"), I believe generalizing quotes does not require an extra class. The already existing "Quasi" class is sufficient. An implementation could treat each quote or nested splice as mere syntactic sugar for an equivalent do-block, then use the usual type inference. == Example Use Case == I discovered a need for this generalization when writing a Template Haskell program in which part of it operates in a "StateT S Q a" monad instead of the usual "Q a" monad. The "S" type stores the state of a memoization table which contains code fragments already generated. Without memoization, the program would loop infinitely when processing certain recursive structures. It is fairly easy to declare an instance of "Quasi" for "StateT S Q", so that is not a problem. In order to keep the code clean, I'd like to use quotations with splices in them (i.e. [| ... $( ... ) ... |] ) for expressing the generated code. However, as quotations and splices are tied to the "Q" monad, I have to manually write "LamE ... VarP ... VarE ... etc." instead of using the much nicer quotation syntax. Without access to the quote syntax, I've had a one-line quotes turn into a half-a-dozen-line do-blocks. In this particular program, I can simulate the state monad using an IORef and lifting IO operations into Q using runIO. However, this merely a workaround. == Open Questions == ~~ Flags ~~ Generalizing the type of quotes can either be an "always-on" feature or it could be enabled by a flag (e.g. "-XOverloadedQuotes"). Since "Q" is an instance of "Quasi", we would expect programs that are type correct without the generalization to also be type correct with the generalization. Thus "always-on" would seem to be a backwards compatible change. However, while I am not an expert on GHC's type system, I suspect there are pathological cases where generalizing the types of quotes would result in the inference system not being able to infer a type that it would be able to without the generalization. In addition, type incorrect programs may yield more confusing type errors. I don't have a particular position on this question so long as the generalization is available (even if only by a flag) to those who want it. I suspect that, in the interests of design conservatism, having it as a flag will be the preferred choice. ~~ Quasi-Quotes ~~ The type of quasi-quoters (i.e. "String -> Q Exp") can be generalized to "forall m. Quasi m => String -> m Exp". However, this poses a compatibility program for existing user-written quasi-quoters. I am uncertain about the best way to handle this. It may be best to leave quasi-quoters without a generalized type unless someone can come up with a good backwards compatibility story. == Deadline == I propose the usual two week deadline (January 13) for discussion. If the overall response is positive, I'll submit a GHC Track ticket.

3 9

more automatic tests for containers
by Kazu Yamamoto 09 Jan '12

09 Jan '12

Especially to Johan and Milan, I'm thinking to introduce more automatic tests for the containers library. Let's take Data.Map as example: 1) doctest Some haddoc documents include the following style. -- > Data.Map.null (empty) == True If we modify it like -- >>> Data.Map.null (empty) -- True we can use doctest. And we can remove corresponding unit test from test/*-properties.hs. Note that I'm not sure how to specify errors with doctest at this moment. 2) test-framework-th If we replace "test_" with "case_", we can use test-framework-th to generate the long list of test cases. We don't need to update it when we add "prop_" and "case_". We can specify the number of QuickCheck test as follows: runghc -i.. -DTESTING map-properties.hs --maximum-generated-tests=500 Since this is test stuff, we don't have to add doctest and test-framework-th to containers.cabal. What do you think? If you like this, I will work and send you pull request. --Kazu

7 11

Using cabal to 'install' a shared library for wxhaskell
by Dave Tapley 04 Jan '12

04 Jan '12

Hi all, I've been working on a new development version of wxhaskell[1] and one of my goals was to integrate previous work on using a shared library[2]. I'm please to report that I have more-or-less achieved this goal at least under Linux, but there is still some cleaning up to do. After performing a cabal I end up with a .so file as expected, the only problem currently is that now whenever you compile something which uses wxhaskell you have to pass in an rpath to the .so in the cabal-dev / local / system packages location. Obviously this .so somehow needs to end up where the system can find it, and I wondered if someone has already (or has ideas about how to) make this happen in cabal? You can see where I believe it should fit in in the ldconfig function in Setup.hs[3]. Thanks, Dave [1] http://darcsden.com/DukeDave/wxhaskell-dev [2] http://wewantarock.wordpress.com/2010/11/03/building-a-shared-library-in-ca… [3] http://darcsden.com/DukeDave/wxhaskell-dev/browse/wxc/Setup.hs

1 1

Faster break and span for Prelude
by Boris Lykah 29 Dec '11

29 Dec '11

Hello everyone, I noticed that Prelude break and span Core uses boxed tuples which is quite expensive. Since functions from Prelude are used everywhere, many programs will benefit from their optimization. Please see my implementation which uses internal worker function and unboxed tuples. In the best case it could perform more than twice faster than Prelude functions. import Criterion.Main newspan :: (a -> Bool) -> [a] -> ([a], [a]) newspan p xs = go xs where go xs@[] = (xs, xs) go xs@(x:xs') | p x = case go xs' of (ys, zs) -> (x:ys,zs) | otherwise = ([], xs) newbreak :: (a -> Bool) -> [a] -> ([a], [a]) newbreak p xs = go xs where go xs@[] = (xs, xs) go xs@(x:xs') | p x = ([], xs) | otherwise = case go xs' of (ys, zs) -> (x:ys,zs) versus f1 f2 pred arg = [ bench "new" $ whnf (f1 pred) arg , bench "prelude" $ whnf (f2 pred) arg ] variousLists f1 f2 pred = [ bgroup "fullMatch" $ versus f1 f2 pred (replicate 1000 1 :: [Int]) , bgroup "failOnFirst" $ versus f1 f2 (not . pred) (replicate 1000 1 :: [Int]) , bgroup "emptyList" $ versus f1 f2 pred ([]::[Int]) ] main = defaultMain [ bgroup "span" $ variousLists newspan span (==1) , bgroup "break" $ variousLists newbreak break (/=1) ] -- Regards, Boris

2 3

PROPOSAL: Export "readEither" from Text.Read
by Iavor Diatchki 23 Dec '11

23 Dec '11

Hello, when writing simple String parsers, I find implementing this function over and over: readEither :: Read a => String -> Either String a I just found out that it is already defined in the module "Text.Read" in the "base" package but, sadly, it is not exported. Would there be any objections if: 1. I was to export it 2. I was to add another convenience function "readMaybe :: Read a => String -> Myabe a" defined in terms of "readEither". I can't think of any problems that this might cause and it would be very helpful to me and my colleagues. Discussion period: 2 weeks, so until 22 December 2011. -Iavor

9 9