January 2011 - Haskell-Cafe

Re: [Haskell-cafe] hledget: mtv vs transformers
by Simon Michael 21 Jan '11

21 Jan '11

You mean mtl 2.*, right ? Yes that is a problem. I'm nervous about requiring mtl 2 because when I bumped hledger 0.13's process dependency to 0.14 for similar reasons it made all kinds of trouble for folks who just want to install the hledger core in standard/older haskell environments. On Jan 20, 2011, at 5:11 PM, Dmitry Astapov wrote: > Since hledger-chart depends on Chart, which in turn depends on > transformers 0.2.*, it will make a sense to bump all mtl > dependencies in hledger to 2.2 > > When one does "make install" with older GHC (like 6.12.1, for > example), and mtl 1.x is available, it would be happily used for > hledger-lib and hledger, but compilation of hledger-chart will pull > in transformers 0.2 (but not the newer mtl) and will fail due to > conflicting instances.

3 5

Where is the CABAL file for haskell-platform 2010.2.0.0?
by Magnus Therning 21 Jan '11

21 Jan '11

I'm not sure I'm reading the release plan for 2011.x.0.0[1] correctly (the switching between 2011.1.0.0 and 2011.2.0.0 is *very* confusing) but it looks like a stable release is scheduled for Feb 1,2011. I was expecting that the link on the front page[2] would lead to the 2010.2.0.0 release until a new stable version was released. This doesn't seem to be the case however: % curl -s http://code.haskell.org/haskell-platform/haskell-platform.cabal | head name: haskell-platform version: 2011.1.0.0 homepage: http://haskell.org/platform license: BSD3 license-file: LICENSE author: libraries(a)haskell.org maintainer: haskell-platform(a)projects.haskell.org category: System synopsis: The Haskell Platform description: Where can I find the cabal file for 2010.2.0.0 until 2011.1.0.0 is formally released (or will it be 2011.2.0.0 as the release plan says)? Will the CABAL file for 2010.2.0.0 not be available *at all* after 2011.x.0.0 is released? /M [1]: http://trac.haskell.org/haskell-platform/wiki/ReleaseTimetable [2]: http://code.haskell.org/haskell-platform/haskell-platform.cabal -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus(a)therning.org jabber: magnus(a)therning.org twitter: magthe http://therning.org/magnus

3 4

Re: [Haskell-cafe] Are constructors strict?
by Sebastian Fischer 21 Jan '11

21 Jan '11

sorry, forgot to cc cafe. On Fri, Jan 21, 2011 at 7:12 PM, Sebastian Fischer <fischer(a)nii.ac.jp>wrote: > Hi Daryoush, > > On Fri, Jan 21, 2011 at 6:18 AM, Daryoush Mehrtash <dmehrtash(a)gmail.com>wrote: > >> I am having hard time understanding the following paragraph in "Purely >> functional Lazy non-deterministic programing" paper >> http://www.cs.rutgers.edu/~ccshan/rational/lazy-nondet.pdf >> >> The problem with the naive monadic encoding of non-determinism is that the >> arguments to a constructor must be deterministic. If these arguments are >> themselves results of non-deterministic computations, these computations >> must be performed completely before we can apply the constructor to build a >> non-deterministic result. >> >> >> >> Why does the argument to constructors must be deterministic? >> > > Because of the type of the constructor. Say you want to compute a list of > Ints nondeterministically (like in the paper). Than the first argument of > the (:) constructurs in the result must be an Int. A nondeterministic > computation that yields an Int has type (m Int) for some nondeterminism > monad (for example, it has type [Int] in the list monad). That the (:) > constructur is polymorphic and would allow to make a value of type [m Int], > is a coincidence and does not help to make a value of type (m [Int]). > > >> WHy is it that thunks are not used in this case? >> > > Thunks do not model nondeterminism, only laziness. > > Did that help you understand? > > Regards, > Sebastian >

1 0

parsec2 vs. parsec3... again
by Evan Laforge 20 Jan '11

20 Jan '11

Yeah, I know this has been discussed a number of times, but I have some concrete questions I haven't seen asked before. And the "parsec 3 is now as fast as parsec 2" thing I've seen around doesn't seem to be true for me. I have an app that does a lot of parsing of small expressions. It's currently parsec2 operating on lots of little Texts (after an unpack, of course). A few parsing functions show up near the top of the profile output, so I thought an obvious improvement would be to parse Text directly and avoid the overhead and garbage of unpacking. Since parsec3 is now supposed to be as fast as parsec2 I thought I would give it a try. Parsec3 is 3.1.0, parsec 2 is 2.1.0.1: parsec2, String: total time = 10.66 secs (533 ticks @ 20 ms) total alloc = 2,340,113,404 bytes (excludes profiling overheads) parsec3, String: (this is just after upgrading the library and editing it to fix breakage from Parser being a type alias now) total time = 13.76 secs (688 ticks @ 20 ms) total alloc = 2,706,625,256 bytes (excludes profiling overheads) parsec3, Text: (wrote a Text instance similar to the one for ByteString, updated imports, no longer unpacking to String) total time = 15.96 secs (798 ticks @ 20 ms) total alloc = 3,338,005,896 bytes (excludes profiling overheads) This is not very encouraging! Especially strange is how Text generates *more* allocation... I'd expect less since it doesn't unpack all the Texts. The parsing functions are no longer at the top of the profile, but there are new 'unParser' and 'parsecMap' and 'parserBind' up at or near the top. 'unParser' just looks like it's unwrapping the Parsec newtype, so I don't fully understand how it's the most expensive, but it's called on every bind so it does get called a lot. There are no obvious super expensive ones, just lots and lots of them that add up. Parsec 3's unParser covers up the parsing function I wrote, so it's now hard to tell what the expensive parsing function actually is. I've seen a few remarks that you can't just throw together parsers and expect them to be fast, you have to profile them, but nothing on how to actually interpret the results of profiling. For instance, here's one of the main expensive parsers: p_unsigned_float :: P.CharParser st Double p_unsigned_float = do i <- P.many P.digit f <- P.option "" (P.char '.' >> P.many1 P.digit) if (null i && null f) then P.pzero else do let int = List.foldl' (\total c -> 10 * total + fromIntegral (Char.digitToInt c)) 0 i frac = foldr (\c total -> (total + fromIntegral (Char.digitToInt c)) / 10) 0 f return (int + frac) There's an obvious problem where I get the digits as a String and then parse that with list functions, but I can't see any way to get parsec to return a chunk of Text. This is roughly how parsec itself parses numbers, in Text.Parsec.Token. So, my current options are either figure out some way to speed up parsec3+Text, revert to parsec2+String and give up, or try an entirely different parsing library. I've heard attoparsec is fast but I'd have to switch to utf8 bytestring which is a big change, and Text seems like the more correct choice anyway. Any ideas or experience?

7 14

Browser Game Engine
by Tom Hawkins 20 Jan '11

20 Jan '11

I want to create a simple browser game using Haskell. It would be nothing complicated: basic 2D graphics, limited sound, and minimal network traffic. What is the recommended medium? Flash or JavaScript+SVG? Any recommended Haskell libraries for the server-side logic or client code generation? -Tom

5 4

Re: [Haskell-cafe] Building lambdabot
by Max Bolingbroke 20 Jan '11

20 Jan '11

On 20 January 2011 17:30, Gwern Branwen <gwern0(a)gmail.com> wrote: >> * You need to loosen the base upper bound to < 4.4 >> * If using base >= 4, you need to depend on the syb package as well >> (current version 0.3) > > Would this break GHC 6.12 builds? Thats why I suggested the flag stanza. Cabal has a weird kind of flag semantics where it will try every possible combination of flags until it finds one that builds. The solution I suggested uses this behaviour to either depend on base >= 4 && < 4.4 WITH syb, OR base < 4 WITHOUT syb. Because of the default flag setting of True, the first possibility will be tried first, but it if fails Cabal will just fall back on base < 4. In short, it should work perfectly for either GHC 7 or 6.12 clients (modulo syntax issues - I haven't actually tried the syntax I sent you). > data-memocombinators is only the tip of the iceberg; I believe much of > lambdabot would need modifications. (Apparently Control.OldException > has gone away, which alone guarantees many changes.) So there wouldn't > be much point to changing show. Actually, I: * Fixed the show upper bound * Fixed data-memocombinators and data-inttrie upper bounds (and sent a pull request to get Luke to take these changes upstream) * Got Wouter to change the upper bound on IOSpec (will be in the 0.2.2 release, out soon) And after all that lambdabot seemed to compile OK (though I got a link-time error about iconv because I'm on a Mac). So if you fix show GHC 7 users will be able to cabal install lambdabot! Cheers, Max

2 4

A question about monad laws
by C K Kashyap 20 Jan '11

20 Jan '11

Hi, I am trying to get a better understanding of the "monad laws" - right now, it seems too obvious and pointless. I had similar feelings about identity function when I first saw it but understood its use when I saw it in action. Could someone please help me get a better understanding of the necessity of monads complying with these laws? I think, examples of somethings stop working if the monad does not obey these laws will help me understand it better. Regards, Kashyap

4 5

Re: [Haskell-cafe] Haskell, C and Matrix Multiplication
by John Lato 20 Jan '11

20 Jan '11

Rather than commenting on the code provided, here are the two biggest wins I've had recently with Haskell. Both of these are part of a physical modeling project. 1) uu-parsinglib - simple to use and automatic error correction. I really, really enjoy working with this library, and how often can you say that? 2) STM - the original design reads a system and all inputs from a config file, then runs the system and produces output. I wanted to build the system from a file but collect inputs and produce output in real-time. After a few small adjustments, a few TVar's and a TMVar, and three forkIO's, it was working. One concern is that the engine (which is computation-intensive) shouldn't block waiting for input, it should just continue on and catch up later. With STM, this can be expressed as: atomically $ getInputs inputTVar `orElse` return () and there's the desired behavior. Couldn't be easier. John From: Blake Rain <blake.rain(a)gmail.com> > > Dear Haskellers, > > I thought I'd take some time to share something of my weekend with > you all. Not because of anything new, but because it is a > feel-good example of Haskell being win. A good read for Monday > morning, perhaps. > <code snipped> > Now over to you guys! What experiences have you had which make you > glad you use Haskell? Anything make you smile recently? > > - Blake >

5 12

Haskell time line?
by michael rice 20 Jan '11

20 Jan '11

The Haskell language is some twenty years old. Is there a time line for what features were in the language's initial release and what has been added along the way? Michael

4 5

A question about monad based on http://en.wikipedia.org/wiki/Monad_(category_theory)
by C K Kashyap 20 Jan '11

20 Jan '11

Hi, I was going through http://en.wikipedia.org/wiki/Monad_(category_theory) - under Formal Definition I notice that monad is a Functor T:C -> C My question is - when we think of Maybe as a functor T:C -> C .... should we think that C here refers to Hakell types? As in, (Int and Maybe Int are objects in C) and (Int -> Int and Maybe Int -> Maybe Int are arrows in C) and T is an arrow between them. Is that right? For some reason, I was imagining them as two different categories C and D. I am not able to fully understand how those diagrams translate to haskell - I can guess that T^2 -> T referes to things like concat operation but not able to relate it to bind. Regards, Kashyap

4 4