May 2011 - Libraries - Haskell.org

ANN: stm-chans 1.2.0
by wren ng thornton 07 May '11

07 May '11

-------------------------------------------- -- stm-chans 1.2.0 -------------------------------------------- The stm-chans package offers a collection of channel types, similar to Control.Concurrent.STM.TChan but with additional features. -------------------------------------------- -- Changes (since 1.0.0) -------------------------------------------- * (Version 1.1.0) Added tryWriteTBChan. * (Version 1.1.0) Added tryWriteTBMChan. * Some major performance improvements in TBChan and TBMChan, thanks to Thomas DuBuisson. In particular, these improvements reduce contention between readers and writers, improving throughput by up to 2--3 times when producers and consumers are running in separate OS threads. The cost for non-parallel programs is trivial (<1% worst-case running time, per Criterion). * Added estimateFreeSlotsTBChan, freeSlotsTBChan, estimateFreeSlotsTBMChan, and freeSlotsTBMChan. These functions return either the exact number or a lower-bound on the number of free slots available before the channels will block/retry. * Some other minor optimizations and code improvements. -------------------------------------------- -- Long description -------------------------------------------- In particular stm-chans offers these types: * Control.Concurrent.STM.TBChan: Bounded FIFO channels. When the channel is full, writers will block/retry. This ensures that the writers do not get too far ahead of the readers, which helps to make sure that memory and cpu resources are used responsibly. * Control.Concurrent.STM.TMChan: Closeable FIFO channels. This is like TChan (Maybe a) but with a monotonicity guarantee that once Nothing is returned all future reads will be Nothing as well. * Control.Concurrent.STM.TBMChan: Bounded Closeable FIFO channels. This combines the capabilities of TBChan and TMChan. In addition, the stm-chans package offers a (partial) compatibility layer for some recent API improvements to the stm package (see ticket #5104 [1]). These new functions include: * tryReadTChan :: TChan a -> STM (Maybe a) A version of readTChan which does not retry. Instead it returns Nothing if no value is available. * peekTChan :: TChan a -> STM a Get the next value from the TChan without removing it, retrying if the channel is empty. * tryPeekTChan :: TChan a -> STM (Maybe a) A version of peekTChan which does not retry. Instead it returns Nothing if no value is available. [1] http://hackage.haskell.org/trac/ghc/ticket/5104 -------------------------------------------- -- Links -------------------------------------------- Homepage: http://code.haskell.org/~wren/ Hackage: http://hackage.haskell.org/package/stm-chans Darcs: http://community.haskell.org/~wren/stm-chans Haddock (Darcs version): http://community.haskell.org/~wren/stm-chans/dist/doc/html/stm-chans -- Live well, ~wren

1 0

Re: Proposal: Tidy up and export PSQ from base
by wren ng thornton 06 May '11

06 May '11

On 5/1/11 7:58 PM, Edward Z. Yang wrote: > OK, to summarize the current discussion: > - It would be nice to have a general-purpose priority queue in containers. > I'm not interested in this goal per se, but I do view it as the cleanest way > to get what I want. With regards to this point, is there any reason why the following does not suffice (albeit not in base)? http://code.google.com/p/priority-queues/ They're not priority *search* queues, but I'm not sure how much to read into your leaving out that word... -- Live well, ~wren

4 4

Proposal: add Int indexing functions to Data.Set
by Luis Casillas 02 May '11

02 May '11

Hi everybody. First time proposer here, so bear with me. While I was looking at the Haddock documentation for Data.Map, I noticed that it has a section with "Indexed" operations that address the map with Int indexes: http://www.haskell.org/ghc/docs/latest/html/libraries/containers/Data-Map.h… The relevant functions' signatures are these: lookupIndex :: Ord k => k -> Map k a -> Maybe Int findIndex :: Ord k => k -> Map k a -> Int elemAt :: Int -> Map k a -> (k, a) updateAt :: (k -> a -> Maybe a) -> Int -> Map k a -> Map k a deleteAt :: Int -> Map k a -> Map k a Now, the Data.Set module, which is a near carbon-copy of Data.Map, does not have any counterparts to these functions. My proposal is to add such counterparts to Data.Set (I'm writing some code that could benefit from them). The proposed functions' signatures: lookupIndex :: Ord a => a -> Set a -> Maybe Int findIndex :: Ord a => a -> Set a -> Int elemAt :: Int -> Set a -> a deleteAt :: Int -> Set a -> Set a I attach a patch to add these to Data.Set. Note that the implementation of the Set functions is basically a copy-paste-and-edit of their counterparts in Data.Map. That seems to be the convention in those two modules; Data.Set is really just like Data.Map but with no "value" field in the datatype's constructor. Since I am a noob, I mistakenly created a Trac ticket before figuring out the correct library proposal process (#5162, which promptly got closed; my apologies). There have been a couple of responses there, which I will summarize here: 1. Concern over the efficiency of the code in my patch (Trac comment by tibbe). At my present skill level with Haskell, frankly, the most intelligent response I can give to this is that I'm copying the Data.Map implementation from darcs to the best of my ability, and that the most I hope is to make the Set versions no worse than the Map versions. 2. Concern that Int-based indexing breaks the set abstraction by exposing a specific ordering (Trac comment by Malcolm Wallace). My assumption when I decided to submit this patch was that if it's OK for Data.Map to have these operations, then it should also be ok for Data.Set to have them. But Malcolm's concern makes me wonder if some people will find the original Data.Map functions objectionable and dislike the idea of "spreading the infection" to Data.Set. Discussion period: 2 weeks.

10 20

Instances for BaudRate from System.Posix.Terminal
by Heka Treep 02 May '11

02 May '11

Hi, the c-libraries use BaudRate as integers, so how about to add Enum instance for BaudRate? It allow users to use fromEnum, toEnum methods. Like this: module System.Posix.Terminal ( ... data BaudRate = B0 ... | B115200 deriving ( Eq, Ord ) instance Enum BaudRate where fromEnum b = case b of B0 -> 0 B50 -> 50 B75 -> 75 B110 -> 110 B134 -> 134 B150 -> 150 B200 -> 200 B300 -> 300 B600 -> 600 B1200 -> 1200 B1800 -> 1800 B2400 -> 2400 B4800 -> 4800 B9600 -> 9600 B19200 -> 19200 B38400 -> 38400 B57600 -> 57600 B115200 -> 115200 toEnum i = case i of 0 -> B0 50 -> B50 75 -> B75 110 -> B110 134 -> B134 150 -> B150 200 -> B200 300 -> B300 600 -> B600 1200 -> B1200 1800 -> B1800 2400 -> B2400 4800 -> B4800 9600 -> B9600 19200 -> B19200 38400 -> B38400 57600 -> B57600 115200 -> B115200 _ -> error $ "unsupported baudrate " ++ show i

2 2

Arrows that are also Functors
by Henning Thielemann 01 May '11

01 May '11

Is it common to make a type an instance of both Arrow and Functor type class? If a type is both instance of Arrow and Functor, would you expect that fmap = (^<<) ? If yes, how about adding this as expected law to the Control.Arrow documentation? Same question for Applicative functors and liftA2 (,) = (&&&). (Btw. Control.Arrow haddock documentation does not mention any Arrow law so far.)

6 12