- Libraries - Haskell.org

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

Add voidM to Control.Monad
by Jurriën Stutterheim 16 Jan '12

16 Jan '12

Hi all, I would like to propose adding the following function to Control.Monad to complement the `void` function: voidM :: Monad m => m a -> m () voidM m = m >> return () This function would be used to prevent warnings like Warning: A do-notation statement discarded a result of type Int. Suppress this warning by saying "_ <- bar", or by using the flag -fno-warn-unused-do-bind The (rather contrived) code below was used to generate the warning above: foo :: IO () foo = do bar return () bar :: IO Int bar = return 1 Using `voidM`, we can rewrite `foo` as such: foo' :: IO () foo' = do voidM bar return () after which no warning will be generated by GHC. Jurriën

6 8

[process] Fixed asynchronous exception bugs in readProcess and readProcessWithExitCode
by Bas van Dijk 13 Jan '12

13 Jan '12

Hi, I fixed two asynchronous exception bugs in readProcess and readProcessWithExitCode: 1) If an asynchronous exception was thrown to the thread executing readProcess/readProcessWithExitCode somewhere after createProcess was executed, the standard handles would not be closed anymore resulting in a "handle leak" so to speak. This is fixed by catching exceptions in the IO processing code and closing the standard handles when an exception occurs. Additionally, I also terminate the process and wait for its termination. Does the latter make sense? 2) If an asynchronous exception was thrown to the stdout/stderr-read-thread it did not execute the putMVar anymore resulting in a dead-lock when takeMVar was executed. This is fixed by properly catching exception in the read-thread and propagating them to the parent thread which will then handle them as described above. Regards, Bas

2 3

Problem about postgresql-simple
by Magicloud Magiclouds 11 Jan '12

11 Jan '12

Hi, Anyone used this library? Just trying to use it and got problem. alias here is a String. kerb.hs:18:9: No instance for (Database.PostgreSQL.Simple.Param.Param Char) arising from a use of `query' Possible fix: add an instance declaration for (Database.PostgreSQL.Simple.Param.Param Char) In a stmt of a 'do' block: rs <- query conn "select 0 from users where alias = ?" (alias) -- 竹密岂妨流水过山高哪阻野云飞

1 0

SYB generics and Monad vs Applicative
by Conal Elliott 10 Jan '12

10 Jan '12

I've been learning to the SYB generics functionality in Data.Data and the syb package. I find myself wondering whether the use of Monad and MonadPlus could be generalized to Applicative and Alternative. My first experiments suggest that they can be and that some of the code can be greatly simplified. Has this question already been explored? -- Conal

2 1

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

Traversable instance for ((,) o) ?
by Conal Elliott 04 Jan '12

04 Jan '12

I wanted a Traversable instance for pairing, so I defined one: > {-# LANGUAGE TupleSections #-} > {-# OPTIONS_GHC -Wall -fno-warn-orphans #-} > import Data.Traversable (Traversable(..)) > import Data.Foldable (Foldable(..)) > import Control.Applicative ((<$>)) > instance Traversable ((,) o) where > sequenceA (o,fa) = (o,) <$> fa However, Foldable is a superclass of Traversable, so I get an error message: Could not deduce (Foldable ((,) o)) from the context () arising from the superclasses of an instance declaration The best I've thought of is the following: > instance Foldable ((,) o) where > fold (_,m) = m However, I don't like how it discards information. Some questions: * Why is Foldable a superclass of Traversable? * Is there a good choice of a Foldable instance of ((,) o)? * Are there any other problems with the Traversable instance above (besides foldability)? - Conal

5 5

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

03 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 28 Dec '11

28 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 22 Dec '11

22 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