- Haskell-Cafe - Haskell.org

Testing web-interfacing applications
by Mateusz Kowalczyk 30 Jun '14

30 Jun '14

Hi, Whenever I write a program which has to interface with the web (scraping, POSTing, whatever), I never know how to properly test it. What I have been doing up to date is fetching some pages ahead of time, saving locally and running my parsers or whatever it is I'm coding at the moment against that. The problem with this approach is that we can't test a whole lot: if we have a crawler, how do we test it it goes to the next page properly? Testing things like logging in and such seems close to impossible, we can only test if we are making a good POST. Let's stick to a crawler example. How would you test that it follows links? Do people set up local webservers with few dummy pages they download? Do you just inspect that GET and POST ‘look’ correct? Assume that we don't own the sites so we can't let the program run tests in the wild: page content might change (parser tests fail), APIs might change (unexpected stuff back), our account might be locked (guess they didn't like us logging in 20 times in last hour during tests) &c. Of course there is nothing which can prevent upstream changes but I'm wondering how we can test the more-or-less static stuff without calling out into the world. -- Mateusz K.

2 1

Munich Haskell Meeting
by Heinrich Hördegen 30 Jun '14

30 Jun '14

Dear all, today again is out monthly Haskell Meeting in Munich. I completly forgot inviting you! Sorry! Today at 19h30, we will meet here: http://www.max-emanuel-brauerei.de/de/Kontakt.html I will try to reserve a table for 10 to 12 persons. If the weather is fine, it will be outside. Please be early, because I cannot defend the table very long if nobody shows up! Cheers, Heinrich

1 0

Conceptualizing Functor vs Performance
by Yuri Lensky 30 Jun '14

30 Jun '14

I am having trouble consolidating a performance-based data representation decision I would like to make against the concept of a "functor". The question can be reduced to the following: Conceptually I think that Data.Vector /should/ be a functor. More specifically, I see no CONCEPTUAL reason that it shouldn't be possible to define some "efficient" container-like object (for example for fast Matrix operations for unboxable numbers, but something that still works for a symbolic variable type) that chooses to represent its data as a Data.Vector.Unboxed if possible, but chooses some more generic structure (perhaps a strict list or a generic Data.Vector) if that is not the case. I haven't found such a functor, and can't seem to implement it on my own. The point is that in theory there is no true constraint on the type of the object being contained so it SHOULD be a Functor/Traversable/etc., the representation simply changes to something more efficient only if possible, and decays to a more generic type gracefully if necessary. Perhaps there is some type hackery that can be done with TypeFamilies? I.E. define some container type "data C a = (ListType a) a", but I haven't found a generic way to do this. Finally, I understand that "efficient" data structure can be problem-dependent, but I have no problem defining many different such "generic" types for different applications. The simplest example would be something like (invalid Haskell): (Data.Vector.Unboxed.Vector v a) => data instance (ListType a) = v (Data.Vector.Generic.Vector v a) => data instance (ListType a) = v data instance (ListType a) = ([]) Of course implementing fmap is a whole separate issue. The point is I do not think this is the right way/possible, but am wondering what the "true" solution is. Thanks.

2 2

Smallcheck Depth
by Omari Norman 30 Jun '14

30 Jun '14

The docs for smallcheck, and the original paper, say that the depth is the depth of nested constructor applications. For some reason this behavior has changed in newer versions of Smallcheck and maybe someone can shed some light on why. For instance, I would think the depth of True and False is 0, as there are no nested constructors. Sure enough, in Smallcheck 0.2.1, (series 0) :: [Bool] gives [True, False]. Yet in smallcheck 1.1.1, (list 0 series) :: [Bool] gives []. Thanks. Omari

2 1

Implementing parental using blood type
by Rafael Almeida 29 Jun '14

29 Jun '14

Hello, I'm trying to practice my Haskell. So I had the idea of making a program which, given a mother's and a child blood type, it can determine whether a certain father is possible or not. Please take a look on this gist with my implementation: https://gist.github.com/aflag/14429dfb2e89791a44e2#file-parentaltesting Would you care to comment on it? It looks a bit cumbersome to my eyes. I'm trying to find the most intuitive and elegant way of do it. I'm not so much worried with performance. []'s Rafael

4 6

Requesting maintainership: bzlib-conduit and process-conduit
by Michael Snoyman 29 Jun '14

29 Jun '14

I'd like to request to be granted maintainership of two conduit-related packages: bzlib-conduit and process-conduit. Both packages are maintained by the same author. I opened up a pull request[1] on bzlib-conduit back in January, and haven't heard back yet. There's also an issue with process-conduit[2] which I'd like to address, but given the lack of response of bzlib-conduit, haven't sent a pull request yet. I also emailed the author directly five days ago regarding the bzlib-conduit pull request, and have not received a response. [1] https://github.com/tanakh/bzlib-conduit/pull/7 [2] https://github.com/tanakh/process-conduit/issues/14

3 4

HSpec vs Doctest for TDD
by Gautier DI FOLCO 29 Jun '14

29 Jun '14

Hi all, I'm a huge fan of TDD (Test-Driven Development) et I used to use tools such as RSpec (Ruby). So naturally, I looked to HSpec, but it seems not idiomatic in Haskell. I have a bunch of questions: - Do you do TDD? - Which tools do you use? - Is doctest "better" (in some senses) than HSpec? Why? - Are HSpec and Doctest complementary? If so, in which case do you use one or another? - Is there some Haskell-specific good practices do to TDD? Thanks in advance for your lights.

23 39

Empty case alternative
by Frantisek Farka 28 Jun '14

28 Jun '14

Hello cafe, I was looking into Haskell Report 2010 and notice something in the definition of case statement: https://www.haskell.org/onlinereport/haskell2010/haskellch3.html#x8-460003.… Apparently an empty alternative within case statement is a plausible production. ('alt' production rule, third option). If I get it correctly, following example shows the empty alternative: > > cStmt e = case e of { 'a' -> True ; {-- empty here --} ; 'b' -> False } > What I miss is any ratio behind this. What is the empty alternative good for? Any idea? Franta

3 2

Moderators, please block zhangliu529@sina.com
by Nikita Volkov 28 Jun '14

28 Jun '14

Every time I send a message to Cafe I get an autoreply from this user with the following text: 您发的邮件我已收到，我将尽快给您答复。 It's extremely annoying. Please, exclude this user from the mailing list.

1 0

"Generating" type synonyms without Template Haskell
by Tom Ellis 27 Jun '14

27 Jun '14

I'd like to know how to conveniently generate specialisations of a product type without resorting to Template Haskell. Concretely, I have a type like data MyProduct a b c = MyProduct { foo :: a , bar :: b , baz :: c } and I use it in type signatures in various different specialisations. Generally the "base" type of each component stays fixed but it is wrapped in zero or more type constructors. For example a. MyProduct Int Bool String b. MyProduct (Maybe Int) (Maybe Bool) (Maybe String) c. MyProduct [IO Int] [IO Bool] [IO String] d. MyProduct (P Int) (P Bool) (P String) for various P that are not always functors in my uses. I thought I might be able to reduce this duplication by parametrisation, that is data MyProduct f a b c = MyProduct { foo :: f a , bar :: f b , baz :: f c } However, I can't always substitute a type constructor for `f` because that doesn't work for cases a. or c.. I thought a type family might work but it seems they have to be fully applied, like type synonyms. Is there an approach to this problem that will allow me to avoid Template Haskell here? Thanks, Tom

3 3