- Libraries - Haskell.org

Re: Proposal: add ByteString support to unix:System.Posix.IO API
by wren ng thornton 04 Mar '11

04 Mar '11

On 2/28/11 12:28 PM, Johan Tibell wrote: > On Mon, Feb 28, 2011 at 9:20 AM, Bryan O'Sullivan<bos(a)serpentine.com> wrote: >> On Sun, Feb 27, 2011 at 9:18 PM, wren ng thornton<wren(a)freegeek.org> wrote: >>> >>> I've written variants of the System.Posix.IO API for strict and lazy >>> ByteStrings which are currently lingering in their own unpublished >>> package[1]. It's silly to have a separate package for just four functions, >>> so I'd like to see it combined into the unix package. I don't have access to >>> create a new ticket with the patch, but it's available at [2]. >> >> I think that the strict bytestring version should just replace the current >> function in System.Posix.IO, and the lazy version should not go in at all. >> This is the approach taken by the network package, and it's cleanest. > > Thanks for working on this Wren. > > I agree with Bryan's point. So then what would become of the string variants? Backwards compatibility and all... not _everyone_ uses ByteStrings yet. Also, FWIW, the real impetus behind writing these was to deal with lazy ByteStrings, since that's what one of my dependencies uses[1]. It seems like a common enough situation that it should be handled directly. Forcing people to call (BS.concat . BL.toChunks) first muddies up the code and introduces additional copying, whereas making people use (mapM_ fdWrite . BL.toChunks) is still rather messy and it's buggy in the face of partial writes. For network usage I agree that the strict-only approach is clean and effective. For general purpose writing to Fds, I'm not so sure. [1] http://hackage.haskell.org/packages/archive/protocol-buffers/1.8.0/doc/html… -- Live well, ~wren

11 22

ANN: Version 0.14 of dataenc, version 0.5 of omnicodec
by Magnus Therning 03 Mar '11

03 Mar '11

I've just uploaded a new version of dataenc to hackage[1]. It contains a large change to the API. The old, rather simplistic, lazy API has been removed. It has been replaced by an API based on incremental encoding/decoding. This should make the library easier to use together with left-fold enumerators such as enumerator[2] and iteratee[3]. It's accompanied by a release of omnicodec[4] which makes use of the modified API of dataenc. /M [1] http://hackage.haskell.org/package/dataenc [2] http://hackage.haskell.org/package/enumerator [3] http://hackage.haskell.org/package/iteratee [4] http://hackage.haskell.org/package/omnicodec -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus(a)therning.org jabber: magnus(a)therning.org twitter: magthe http://therning.org/magnus Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay

1 0

union in Data.Map
by Ross Paterson 01 Mar '11

01 Mar '11

[sidetracking from the discussion of unordered-containers] On Thu, Feb 24, 2011 at 12:36:42PM +0000, Ross Paterson wrote: > On Wed, Feb 23, 2011 at 08:45:47AM +0000, Max Bolingbroke wrote: > > 3. Some map combining algorithms work more efficiently when one of > > their two arguments are smaller. For example, Data.Map.union is most > > efficient for (bigmap `union` smallmap). If you don't care about which > > of the two input maps wins when they contain the same keys, you can > > improve constant factors by testing the size of the map input to size > > (in O(1)) and flipping the arguments if you got (smallmap `union` > > bigmap) instead of the desirable way round. > > This is a most unfortunate feature of Data.Map, forcing users to bend the > logic of their application to suit the library. On closer inspection, I think the documentation is underselling the code here. From experiments adding 1000 trees of size 10 to a tree of size 1000, it seems that the best order varies with the distribution of keys, but on average they come out about even. (Maybe small U big is slightly faster.) Also, I believe the hedge algorithm does achieve the asymptotic optimum, namely O(m log(n/m)), where m and n are the sizes of the smaller and larger trees respectively. It does do more comparisons than necessary, but these can be avoided, e.g. by altering hedgeUnionL to hedgeUnionL :: Ord a => MaybeS a -> MaybeS a -> Map a b -> Map a b -> Map a b hedgeUnionL _ _ t1 Tip = t1 hedgeUnionL blo bhi Tip (Bin _ kx x l r) = join kx x (filterGt blo l) (filterLt bhi r) hedgeUnionL blo bhi (Bin _ k1 x1 l1 r1) t2@(Bin _ k2 _ l2 r2) = case compare k1 k2 of LT -> join k1 x1 (hedgeUnionL blo bmi l1 (trim blo bmi l2)) (hedgeUnionL bmi bhi r1 t2) EQ -> join k1 x1 (hedgeUnionL blo NothingS l1 (trim blo NothingS l2)) (hedgeUnionL NothingS bhi r1 (trim NothingS bhi r2)) GT -> join k1 x1 (hedgeUnionL blo bmi l1 t2) (hedgeUnionL bmi bhi r1 (trim bmi bhi r2)) where bmi = JustS k1 and similarly for difference. The extra lookup in the With versions seems harder to avoid, though.

1 0

add Data.Bool.ifThenElse
by Henning Thielemann 01 Mar '11

01 Mar '11

If I activate RebindableSyntax in GHC-7.0, I have to provide a function named ifThenElse. How about a default implementation in Data.Bool that is equivalent to classical if-then-else? So far, I only use RebindableSyntax for overloaded number literals.

3 3

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 26 Feb '11

26 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