February 2011 - Libraries

Clarify relationship between Functor and Applicative
by roconnor＠theorem.ca 28 Feb '11

28 Feb '11

In the applicative documentation, it says for an Applicative functor f: The Functor instance should satisfy fmap f x = pure f <*> x I think the documentation should be clarified that this does not need to be checked because it is a consequence of the other applicative laws. See <http://hpaste.org/44315/applicative_implies_functor>. -- Russell O'Connor <http://r6.ca/> ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.''

3 6

Patching STM
by wren ng thornton 28 Feb '11

28 Feb '11

Hello all, I have a number of functions and data structures I'd like to see added to the stm package. The package is listed as being maintained by the list, so I thought I'd ask how "sacred" stm is considered before going through the process to propose things. The extra functions are no-brainers. Some are common conveniences (e.g., modifyTVar and modifyTVar'), some aim to make the API more consistent (e.g., add swapTVar like swapTMVar), and some can be optimized if they're included in the package (e.g., tryReadTMVar[1]). The data structures are all variations on TChan which seem common enough to be included in the package, though I could also fork off a stm-data package instead. The variations include channels that can be closed, channels which have bounded depth (i.e., cause extra writes to block until room is available), and channels which are both bounded and closeable. Thoughts? Also, to make proper patches, where is the stm repo? [1] From outside the package we must define this as: tryReadTMVar :: TMVar a -> STM (Maybe a) tryReadTMVar var = do m <- tryTakeTMVar var case m of Nothing -> return () Just x -> putTMVar var x return m Whereas, from inside the package we can just do: tryReadTMVar :: TMVar a -> STM (Maybe a) tryReadTMVar (TMVar t) = readTVar t thus saving an extraneous read and write. -- Live well, ~wren

2 1

darcs patch: Expand and clarify MVar documentation.
by Edward Z. Yang 25 Feb '11

25 Feb '11

1 patch for repository http://darcs.haskell.org/packages/base: Sun Jan 16 19:23:34 GMT 2011 Edward Z. Yang <ezyang(a)mit.edu> * Expand and clarify MVar documentation.

2 1

Testing a local package with Cabal?
by Howard B. Golden 25 Feb '11

25 Feb '11

Hi, I am making my first package to be installed with Cabal from Hackage. I know how to run the various steps (configure, build, install, etc.) using runhaskell Setup.hs. Is there some way I can package my package as a tar.gz (using sdist) and then test it from a local file as if it were being downloaded from Hackage by cabal install? (If this is documented, I couldn't find it. If this isn't documented, it should be IMO. If this isn't currently available, I request the feature be added.) Also, do I have to do something special in the .cabal file (or elsewhere) to get Haddock run on the source files? Thanks. Cheers, Howard B. Golden Northridge, California, USA

2 1

Re: [Haskell-cafe] Faster timeout but is it correct?
by Bas van Dijk 21 Feb '11

21 Feb '11

On 21 February 2011 22:11, Job Vranish <job.vranish(a)gmail.com> wrote: > I'm curious, is it possible that your new timeout implementation would fix > this problem?: > doesntWork :: Int -> Int > doesntWork x = last $ cycle [x] > test :: IO (Maybe Bool) > test = timeout 1 $ evaluate $ doesntWork 5 == 5 -- never terminates, even > with the timeout I just tested this with the new timeout and unfortunately it's not fixed. Bas

1 0

Proposal: Strict types
by Edward Z. Yang 21 Feb '11

21 Feb '11

Hello all, This proposal would like to make it easier to build data types for strict data structures. Everything described here can be done by making a new data declaration; we'd like to support some more ad-hoc mechanisms. This is not intended to be complete, rather it's intended to jump start discussion about the selection and use of strict and lazy data structures in Haskell. 1. Move strict Maybe and Either into base We create a new module Data.Maybe.Strict and Data.Either.Strict which implement the following semantics: Just _|_ = _|_ Left _|_ = _|_ Right _|_ = _|_ We do not expose a left-strict or right-strict version of Either. 2. Move strict Tuple into base We create a new module Data.Tuple.Strict that defines a new data type Pair with: Pair _|_ a = _|_ Pair a _|_ = _|_ 3. Syntax extension for strict pairs We extend syntax to allow a way of specifying strict pairs (maybe (! 1, 2, 3 !), with operator (!,) (!,,) etc). These are distinct from normal pairs and have their own set of functions. 4. Move strict IO into base Unpredicatable resource usage behavior with hGetContents (which is lazy) and similar functions frequently affects newbies. Offer a module System.IO.Strict. We note that proposals 1, 2 and 4 are implemented by the strict package, as is a form of 3 without nice syntax. 5. Move strict-concurrency into base The package strict-concurrency offers strict versions of MVars and Chans, which are frequent culprits for unpredicatable behavior in which thread a thunk is evaluated on. As an alternative to moving 1-5 into base, we can place them in the Haskell Platform. 6. Syntax extension for anonymous strict types If I have a type (a, b), and I would like to make it strict in the first argument, I have to create a new data type. This syntax extension would permit me to create such data type simply by writing (!a, b). This is probably going to be difficult, so here are some possible implementation strategies: * Such syntax is simply sugar for creating an anonymous data type with those properties. Coercions would need to be specified manually. Type inference errors might become harder to diagnose. * We modify all types to have a strictness bit and modify the inference algorithm to propagate these bits. It sounds like a fascinating research problem with a paper at the end, if it actually works. If this is implemented, it supersedes all of the previous points (and in fact, probably many of the .Strict modules that currently exist, if application of strictness is strictly (ahem) mechanical.) Discussion time: 1 month

7 15

parsec-3 problem
by Christian Maeder 19 Feb '11

19 Feb '11

Hi, the following code goes through parsec-2 (and parsec1) but is rejected by parsec-3 import Text.ParserCombinators.Parsec gqrrel = many1 (alphaNum <|> char '_') myparser = sepBy gqrrel (char ',') The error message is: No instance for (parsec-3.1.1:Text.Parsec.Prim.Stream s m Char) arising from a use of `char' at P3.hs:3:25-32 Possible fix: add an instance declaration for (parsec-3.1.1:Text.Parsec.Prim.Stream s m Char) In the second argument of `sepBy', namely `(char ',')' In the expression: sepBy gqrrel (char ',') In the definition of `myparser': myparser = sepBy gqrrel (char ',') Please review your decision to put parsec-3 into the HP. Cheers Christian

7 9

Data.HashMap: Strict or lazy by default?
by Johan Tibell 18 Feb '11

18 Feb '11

Hi all, I'm about to release my new unordered-containers library, which includes a Data.HashMap module. I have one remaining design issue I'd like to get some feedback on. Here are the constraints: * There are a number of functions that need both lazy and strict versions. Example: insertWith * There are a number of functions that don't need a strict version, but where having a strict version would help avoid space leaks and support the common strict use case. Example: insert * A particular use case for a map rarely uses both the lazy and strict versions (suggesting a module split). * Keeping both the strict and lazy versions in the same module makes the module very large and users typically want to see only half of the functions in there (the ones that fit their current use case). My current thinking is to provide lazy and strict versions in different modules. The two modules could still share the same data type. The question is, what should be the default? Haskell is a lazy language but the most common use cases for maps are strict (e.g. a map from strings to integer counters). I intend to to use one of three possible module layouts: Option 1: Data.HashMap (strict) Data.HashMap.Lazy Option 2: Data.HashMap (lazy) Data.HashMap.Strict Option 3: Data.HashMap (re-export one of the two modules below) Data.HashMap.Lazy Data.HashMap.Strict I'd like to see some arguments for and against each of the two possible defaults (lazy or strict). Also, real life examples of cases where lazy maps are useful would be appreciated. Cheers, Johan

7 14

Moving Foldable.foldl' inside the type class
by Johan Tibell 17 Feb '11

17 Feb '11

Hi all, It would be nice if foldl' was moved inside the Foldable type class. Right now you get terrible performance if you use foldl' from Foldable. Ironically it'll also use O(n) space. Someone should move the function inside the type class. Johan

2 1

Proposal: Add MonadFix instance to STM
by Sebastiaan Visser 17 Feb '11

17 Feb '11

Hi all, The STM monad currently has no MonadFix instance, but wonderful things are possible when it has one. I propose adding the 'MonadFix STM' instance provided by Antoine Latter on the Haskell-Cafe[1] list to the STM package: > {-# LANGUAGE MagicHash, UnboxedTuples, DoRec #-} > > import GHC.Exts > import GHC.Conc > import Control.Monad.Fix > > data STMret a = STMret (State# RealWorld) a > > liftSTM :: STM a -> State# RealWorld -> STMret a > liftSTM (STM m) = \s -> case m s of (# s', r #) -> STMret s' r > > instance MonadFix STM where > mfix k = STM $ \s -> > let ans = liftSTM (k r) s > STMret _ r = ans > in case ans of STMret s' x -> (# s', x #) Discussion Period: 1 week -Sebastiaan Visser [1] http://www.haskell.org/pipermail/haskell-cafe/2011-February/089226.html

2 2