November 2013 - Libraries

Proposal: free shrinking with QuickCheck
by Reid Draper 25 Nov '13

25 Nov '13

I originally sent this message to the QuickCheck mailing list, but haven't heard anything in a while, and realized there are only ten subscribers. Below is the original message, any feedback appreciated. --- I have an idea to eliminate the `shrink` function from the `Arbitrary` type class. Currently, users can optionally implement shrinking manually, this tends to be boilerplate code and is "...clearly a generic programming problem" [1]. Further, users often have to create separate types to accommodate their domain's restrictions. For example, a user may wish to only generate power-of-two numbers for their test. Their code simply uses `Int`, but with QuickCheck they must create a `newtype` wrapper and implement this logic in both the `arbitrary` and `shrink` implementation. My idea is to eliminate the `shrink` function, and to integrate shrinking with the `arbitrary` function. Currently, the type for `arbitrary` is: arbitrary :: Gen a and `Gen` has the definition: newtype Gen a = MkGen{ unGen :: StdGen -> Int -> a } I suggest that instead of the inner-function returning `a`s, it should return `RoseTree a`. The root of the tree is the generated value, and the rest of the tree is all of the ways to shrink the value. Here's how things would fit together: data RoseTree a = RoseTree a [RoseTree a] -- this is the same as the current Gen newtype Generator a = Gen { unGen :: StdGen -> Int -> a } newtype Gen a = MkGen { unGen :: Gen (RoseTree a) } Conveniently, `Gen` still has a unary type constructor of `a`. Further, if users have implemented their `arbitrary` implementations in terms of the QuickCheck combinators, their code won't have to change at all (I don't think…). The lower-level combinators would be updated to manipulate trees, with functions like `joinRose` and `filterRose`. Let's next look at how `Gen` would implement the monad type class: instance Monad Gen where return = MkGen . return . return gen >>= f = MkGen $ helper (unGen gen) (unGen . f) -- sequence is from Data.Traversable where helper m k = m >>= \y -> fmap joinRose $ sequence $ fmap k y The implementation of `return` is clear. `>>=` isn't too bad either: the function provided to bind will return `Gen b`'s, and `joinRose` and `sequence` help us pull this `Generator (RoseTree b))` 'out', much like `join` does. This means our users can still write code like: (arbitrary :: Gen [Int]) >>= elements Which brings up a good point. The above code has an issue, `elements` is a partial function with respect to the empty list. With the current implementation, we'd use the `NonEmptyList` modifier, which much respect this predicate both during generation and shrinking. This change would allow all predicates to be expressed simply with `suchThat`, which, since it acts on both values _and_ shrink trees, applies the predicate in both places. The implementation of `suchThat` would have to unwrap `Gen`, and apply `roseFilter` to the `RoseTree` inside of `Generator`, using `fmap`. I have implemented the above description in my Clojure port of QuickCheck, called simple-check [1], and it seems to be working quite nicely. Further, I suspect Erlang QuickCheck [3] is doing something similar, though their implementation is not open source, I can't presume too much. Clearly this would be a big change, and my goal now is simply to start a discussion: how does this sound? What's wrong, what's likely to break? Feedback and criticism welcome. Reid [1] Scrap your boilerplate with class: extensible generic functions: http://research.microsoft.com/pubs/67439/gmap3.pdf [2] https://github.com/reiddraper/simple-check [3] http://www.quviq.com/index.html

4 7

System.Posix.IO.ByteString fdRead and fdWrite.
by Ashley Yakeley 25 Nov '13

25 Nov '13

In unix-2.7.0.0, fdRead and fdWrite in System.Posix.IO.ByteString use String instead of ByteString. This is wrong, isn't it? The point of the .ByteString modules is to do IO in ByteString. -- Ashley

5 5

Lista de emails como fazer mala direta lista de empresas
by Ed Soares 23 Nov '13

23 Nov '13

Lista de emails como fazer mala direta lista de empresas listagem de empresas além de lista de emails, email em massa envio de email: http://www.maladiretaemails.com todos devem saber que como fazer uma mala direta, é geralmente um muito legal para a maioria das pessoas. trabalhe com mala direta emails de empresas tais como lista de emails, envio de email o que e mailing, é realmente o objetivo de nosso Site. Você está procurando list mail, email em massa juntamente com email cadastro: http://www.maladiretaemails.com é muito legal emails empresas que contém listas email, trabalhe com mala direta listagem de empresas. é otimo email de empresas e como email marketing. list mail programa para enviar e mail, endereco de email. no momento listas de emails adicionalmente Enviar email, lista de mail é realmente otimo. o objetivo de nosso website: email em massa, Enviar email, e também emails empresas. Nós fornecemos listas de emails emails empresas, list mail.

1 0

Who needs and wants parallelism-friendly core libs?
by Ryan Newton 22 Nov '13

22 Nov '13

[Popping up to the big-picture question for a moment, from the previous thread on Vector CAS.] Given that a lot of people are really advertising Haskell on the parallel/concurrent front, it seems like we *should* be committed as a community to making our basic libraries support parallel/concurrent use cases effectively. This will necessarily mean touching some core libraries (container, vector...). The two things that have come up for me recently are (1) CAS/RMW on [unboxed] Vectors and a general notion of balanced-splitting for tree-based structures (Map,Set). But I'm sure there are others! Is any one else invested in getting this kind of thing moving? It would be great to have a partner. I can commit a small amount of cycles, but I don't have lots of bandwidth for non-research infrastructure work presently. Edward, is any of this useful to you? In many of these cases it seems like the main problem is not a technical one, but the social one of consensus building (and fighting excessive "stop energy" if it appears). Edward, as chair of the core libraries committee, maybe you could help with this? Cheers, -Ryan On Thu, Nov 21, 2013 at 10:25 AM, Ryan Newton <rrnewton(a)gmail.com> wrote: > [@Aleksey] Very good point! I'd missed that vector does the SOA->AOS > business too. (I thought that was just Repa & Accelerate.) > > In any case, an unboxed vector of tuples can't *actually* support atomic > CAS anyway, so not supporting it is inevitable. > It does mean that exposeMutableByteArray can't be a method of the Unbox > class. It would need to be another class capturing the subset of vector > types that are "Atomic" (support concurrent/atomic memory ops). > > > >

6 15

Maintaintership of HaLeX
by Jan Rochel 22 Nov '13

22 Nov '13

Hello. The current version (1.2) of HaLeX does not build on my machine (ghc-7.6.3). The fix is very simple*, but the package maintainer has not reacted on any of my emails during the last couple of months. I'd be willing to take over maintainership, if people agree that this is the best course of action. Otherwise I'd upload an additional fixed variant of the package. Greetings, Jan * add assumption (Eq st) on lines 80 and 104 of file HaLeX_lib/Language/HaLex/Fa2RegExp.hs

2 1

Best way to get to CAS/fetch-and-add on unboxed vectors?
by Ryan Newton 21 Nov '13

21 Nov '13

Since GHC 7.8 will now absorb the functionality that was previously only in the atomic-primops package<http://hackage.haskell.org/package/atomic-primops>, it would be great to start exposing this for the data structures people actually want to use: i.e. unboxed vectors rather than raw MutableByteArrays<http://hackage.haskell.org/package/atomic-primops-0.4/docs/Data-Atomics.htm…> . I've been reading through the code of vector, thinking that I would release some kind of "vector-atomics" package. Alas, I don't see how that is possible. There's no way to get at the MutableByteArray associated with an unboxed vector. (1) I think the minimum that would be necessary would be to modify "Data/Vector/Unboxed/Base.hs", where the instances for the type family actually exist, to provide an additional instance for each "MVector s Foo" that records the fact that the vector has and can expose a MutableByteArray. (2) Alternatively, an "exposeMutableByteArray" function could be added to the existing Unbox class. But this would affect other third party Unbox instances out there in the world... Is there any interest insupporting Unbox instances that are NOT implemented as a MutableByteArray? (3) The most invasive (but best for the user) change would be to extend the basic MVector interface to include notions of concurrency-related operations right inside the vector package (CAS, etc). But they should still probably go in a separate class (not class MVector), just because they will be specific to Unboxed and Storable vectors rather than boxed ones.... -Ryan

4 8

2013.4.0.0 proposal
by Mark Lentczner 20 Nov '13

20 Nov '13

I know it is late, and so I've done some preliminary version sleuthing.... Here's my proposal for HP 2013.4.0.0. I know this e-mail's is long - but hoping to hear from all relevant parties soon. *GHC 7.6.3* -- this is a compiler bump, but all the included packages remain at the same version as 2013.2.0.0 *Packages with no changes:* fgl, haskell-src, html, HTTP, HUnit, mtl, parsec, QuickCheck, random, regex-base, regex-compat, regex-posix, split, stm, text, transformers, xhtml, zlib *Packages with minor version bumps:* *I'll advance these automatically this time - no need for maintainer input* cgi: 3001.1.7.5 → 3001.1.8.4 network: 2.4.1.2 → 2.4.2.0 parallel: 3.2.0.3 → 3.2.0.4 syb: 0.4.0 → 0.4.1 unordered-containers: 0.2.3.0 → 0.2.3.3 vector: 0.10.0.1 → 0.10.9.1? primitive: 0.5.0.1 → 0.5.1.0? *Packages with major version bumps:* *I'd like to get confirmation from the maintainers of these packages that this bump is "the right thing to do". The bump should ideally only add API, and not orphan any program that used to compile under the HP - at least not without a good reason.* case-insensitive: 1.0.0.1 → 1.1.0.1 hashable: 1.1.2.5 → 1.2.1.0 GLUT: 2.4.0.0 → 2.5.0.1 GLURaw: 1.3.0.0 → 1.4.0.0 OpenGL: 2.8.0.0 → 2.9.1.0 OpenGLRaw: 1.3.0.0 → 1.4.0.0 alex: 3.0.5 → 3.1.0 happy: 1.18.10 → 1.19.0 *New Packages:* *There was prior discussion on the libraries mailing list, and generally all around resounding "YES!" for including aeson.* *I think we should include it. I'm looking for confirmation from the maintainer that this is the right version to include.* aeson: 0.6.2.1 *Cabal:* *The Cabal 1.18 release was a major new release, including the very very useful sandbox feature. This would require shipping a different Cabal lib than the version shipped with the included GHC. I'm not sure of the implications of doing this - in particular, whether we would have to ship two Cabal packages or just the later.* Cabal: 1.16.0 → 1.18.1.2 cabal-install: 1.16.0.2 → 1.18.0.2 What do you all think? — Mark "late, but not forgotten" Lentczner

14 30

Proposal: add fusion RULES for Data.Maybe.mapMaybe
by Akio Takano 20 Nov '13

20 Nov '13

Apologies, the subject of my previous email was wrong. It is about Data.Maybe.mapMaybe, not Data.Map.mapMaybe. On Wed, Nov 20, 2013 at 4:40 PM, Akio Takano <tkn.akio(a)gmail.com> wrote: > Hi, > > Currently mapMaybe does not fuse at all. The attached patch implements > necessary rules for fold/build fusion in both sides (the result and the > second argument) to happen. When fusion does not happen, the function > should behave exactly the same as before. > > I ran some benchmarks, testing cases where fusion does and does not happen: > > > http://htmlpreview.github.io/?https://github.com/takano-akio/mapmaybe-bench… > > The benchmark code is: > > https://github.com/takano-akio/mapmaybe-benchmarks/blob/master/main.hs > > Discussion period: 2 weeks. > > Thank you, > Takano Akio >

1 0

Proposal: Add `instance Bits Bool`
by Edward Kmett 18 Nov '13

18 Nov '13

We went through all the pain of removing Num as a superclass of Bits to support it, but we apparently never actually put the instance of Bits (and FiniteBits) for Bool into base. I propose we do so. Discussion Period: 2 weeks -Edward

4 3

Proposal: Expand TBQueue API with 'currentSize'
by David Luposchainsky 14 Nov '13

14 Nov '13

Hey everyone, Concurrent channels are very opaque right now: all that can be done is checking they're empty. The upcoming release will, thanks to Merijn, contain a way of checking whether a TBQueue is full. However, there may be scenarios where it is desirable to retrieve the current size of a TBQueue. The reason I mention TBQueue specifically is because it already contains said information, but does not export corresponding accessor functions, so the implementation would be fairly easy. Probably the most compelling use case I can think of is debugging. Sometimes "full" or "empty" just isn't enough: it may be useful at which point in time the queue starts being filled disproportionately. (I just had a case where I could have saved many hours.) Another one inspired by someone on #haskell a couple of minutes ago is when a "size moderated" queue is desirable, i.e. one that is usually somewhat filled but still allows being written to in important cases. The specific example given was a device sending data through a channel where the input can be throttled based on how fast the output ends process the data. The code would be simply the following: > lengthTBQueue :: TBQueue a -> STM Int > lengthTBQueue (TBQueue rsize _read wsize _write) = readTVar rsize Another possible addition would be retrieving a TBQueue's maximum size. Although this has to be known in order to create the queue in the first place, when the queue is used deep down in other functions passing the size explicitly as a parameter seems a little unnecessary. David/quchen

1 0