- Haskell-Cafe - Haskell.org

Derived Read for records
by Conal Elliott 12 Jun '12

12 Jun '12

Someone at work just asked me about the inflexibility of the derived Read instances for records -- specifically that they require fields to be given in the same order as in the type definition and that fields cannot be omitted. I hadn't been aware of these restrictions. A few questions: * Are there known work-arounds? * Is it particularly difficult to synthesize more flexible Read instances? * Do people just not mind the restrictions? Thanks, -- Conal

1 0

ANN: clckwrks - a Haskell blogging and CMS framework
by Jeremy Shaw 12 Jun '12

12 Jun '12

Hello! I am pleased to announce the launch of clckwrks.com. clckwrks (pronounced, 'clockworks') is a new Haskell-based content management (CMS) and blogging framework: http://www.clckwrks.com/ It is freely available under the BSD3 license. clckwrks is still in early alpha development. We are looking for developers who want to contribute or just like to try bleeding edge software. clckwrks is already being used to power happstack.com and clckwrks.com -- so it is already useful. There are a lot of things we are not happy with yet ranging from code formatting to design issues. But, at the same time, there are a lot of things we are very happy with. If you would like to help get us to clckwrks 1.0, we'd love to have your help! For more information, check out the website and consider joining the mailing list. Thanks! - jeremy

1 0

Troubles understanding Parsec Error Handling
by Matthias Hörmann 11 Jun '12

11 Jun '12

I recently started writing my first application at work in Haskell and it deals with a lot of parsing. Among other things I often have to check for a lot of alternatives for fixed strings (parsing natural language text and people have a lot of ways to abbreviate the same thing in labels). So far I have been doing this basically via choice $ map (try . string) [ "foo", "bar", ... ] This works fine but has two disadvantages, it isn't very fast, in particular when many of the strings start with the same prefix and it also is a bit error prone since it breaks when you place a prefix of another string earlier in the list. My attempt at a solution was to use the bytestring-trie package for a little utility function that basically parses one character at a time, checks if the string parsed so far is in the trie and then calls itself recursively with the trie starting with that string. My attempt at that so far looks like this: (dependencies bytestring-trie, utf8-string and parsec 3) import qualified Data.ByteString.UTF8 as UTF8 import qualified Data.Trie as Trie import Text.Parsec import Text.Parsec.Text (GenParser) anyOf :: [String] -> GenParser u String anyOf l = try $ anyOf' t "" where t = Trie.fromList $ zip (map UTF8.fromString l) (repeat ()) anyOf' :: Trie.Trie () -> String -> GenParser u String anyOf' t s = try $ do c <- lookAhead $ anyChar let newS = s ++ [ c ] in case Trie.submap (UTF8.fromString newS) t of emptyT | Trie.null emptyT -> case Trie.member (UTF8.fromString s) t of True -> return s False -> unexpected $ show newS++", expecting one of "++show l restT -> do _ <- anyChar try $ anyOf' restT newS A successful example usage would be: parseTest (do; r1 <- anyOf ["Hello", "Hallo", "Foo", "HallofFame"]; r2 <- string "bla"; return (r1, r2)) "Hallobla" which results in ("Hallo","bla") (the extra string parser is there so errors in parsing too much are not hidden). An error would result .e.g. from parseTest (do; r1 <- anyOf ["Hello", "Hallo", "Foo", "HallofFame"]; r2 <- string "bla"; return (r1, r2)) "Hallofbla" which prints this: parse error at (line 1, column 8):unknown parse error And my question about this is made up of two parts 1. Why doesn't it print my "unexpected" message but instead says unknown parse error 2. Why is the location in the text off (I would expect it to fail at column 6 (first character beyond the result it could return) or 7 (first character that makes the string no prefix of any acceptable string) I am afraid my knowledge of Parsec internals is a bit too limited, some Google queries showed no similar problems and no obvious places in the Parsec source code to check for the answer to the first question in particular and I suspect the second is closely related to the first. Thanks for reading through my question and I hope someone knows the answer or at least some clues on where i might find it. Matthias Hoermann P.S.: I am hoping this time this works, last time it was rejected because google sends with @googlemail.com instead of @gmail.com for some reason.

4 8

vector operations
by Evan Laforge 11 Jun '12

11 Jun '12

So I wanted to find the first index in a vector whose running sum is greater than a given number. The straightforward way is to create the running sum and then search: Vector.findIndex (>=target) (Vector.scanl' (+) 0 vector) But vectors are strict so it could do extra work, and what if I don't want to generate garbage? I could do it with a fold, but it would have to have the ability to abort early. Of course I could write such a fold myself using indexing: import qualified Data.Vector.Generic as Vector fold_abort :: (Vector.Vector v a) => (accum -> a -> Maybe accum) -> accum -> v a -> accum fold_abort f accum vec = go 0 accum where go i accum = maybe accum (go (i+1)) $ f accum =<< vec Vector.!? i find_before :: (Vector.Vector v a, Num a, Ord a) => a -> v a -> Int find_before n = fst . fold_abort go (0, 0) where go (i, total) a | total + a >= n = Nothing | otherwise = Just (i+1, total+a) So it's bigger and clunkier, but I would think it would be much more efficient (provided using Data.Vector.Generic won't inhibit inlining and unboxing). But I'm a bit surprised there isn't already something like fold_abort... or is there?

4 7

GHCi Loop Detection
by John Van Enk 11 Jun '12

11 Jun '12

Hi Cafe, Is there a reason that the GHCi interpreter doesn't detect and report infinite loops in statements like this (like compiled programs do) even though no CPU time appears to be used? My (admittedly weak) searching for an answer didn't turn much up. let s | not $ null s = [] in s GHCi v7.0.4 on OSX Thanks, John

2 2

Re: [Haskell-cafe] attoparsec double precision, quickCheck and aeson
by Doug McIlroy 11 Jun '12

11 Jun '12

> Date: Tue, 5 Jun 2012 10:25:26 -0700 > From: Warren Harris <warrensomebody(a)gmail.com> > > On Jun 5, 2012, at 9:57 AM, Johan Tibell wrote: > >> I don't think applying == to something that contains floating point >> values at the leaves makes much sense. You want some approxEq function >> that uses approximate equality on floating point value or you want to >> equality function that ignores the floating point values. Probably not >> the answer you like, but I don't know how to define Eq in a robust way >> for types that include floating point values. > > I buy that in general for comparing floats (those that result from arithmetic operations), but this is a case where attoparsec's parser is munging the value. I would like to have a law that says "parse . print == id" ... which is why this seems more like a bug than the usual floating point concerns. This law seems to hold for haskell's double parser: quickCheck (\d -> read (show d) == d) > > Date: Tue, 5 Jun 2012 10:51:08 -0700 > From: "Bryan O'Sullivan" <bos(a)serpentine.com> > > If you need the full precision, use rational instead. The double parser is > there because parsing floating point numbers is often a bottleneck, and > double intentionally trades speed for precision. If I understand the intended meaning of "parse" correctly, what's at issue is decimal-to-binary conversion. It is hard to defend sloppy answers for such a fundamental operation. The recommendation of rational calculation makes little sense for most floating-point computation, which approximates irrationals. The necessary imprecision, though, does not justify sloppiness--and especially not sloppy tests. It's worth noting that a "law" of input being inverse to output must fail, though rarely. Different granularity of the two bases means that there must exist cases where adjacent values in one base convert to the same value in the other. (Conceivably the specialization to parse.print could hold for some hardware. Does anybody know whether the wish is actually hopeless?) Last I looked (admittedly quite a while ago), the state of the art was strtod in http://www.netlib.org/fp/dtoa.c. (Alas, dtoa.c achieves calculational perfection via a murmuration of #ifdefs.) It's disheartening to hear that important Haskell code has needlessly fallen from perfection--perhaps even deliberately. Doug McIlroy

3 4

High memory usage with 1.4 Million records?
by Andrew Myers 11 Jun '12

11 Jun '12

Hi Cafe, I'm working on inspecting some data that I'm trying to represent as records in Haskell and seeing about twice the memory footprint than I was expecting. I've got roughly 1.4 million records in a CSV file (400M on disk) that I parse in using bytestring-csv. bytestring-csv returns a [[ByteString]] (wrapped in `type`s) which I then convert into a list of records that have the following structure: > 3 Int > 1 Text Length 3 > 1 Text Length 11 > 12 Float > 1 UTCTime All fields are marked strict and have {-# UNPACK #-} pragmas (I'm guessing that doesn't do anything for non primitives). (Side note, is there a way to check if things are actually being unpacked?) My back of the napkin memory estimates based on the assumption that nothing is being unpacked (and my very spotty understanding of Haskell data structures): Platform: 64 Bit Linux # Type (Sizeof type (occasionally a guess)) 3 * Int (8) 14 * Char (4) -- Text is some kind of bytestring but I'm guessing it can't be worse than the same number of Char? 12 * Float (4) 18 * sizeOf (ptr) (8) UTC: -- From what I can gather through :info in ghci 4 * (ptr) (8) 2 * Integer (16) -- Shouldn't be overly large, times are within 2012 List: (Pointer to element and next cons cell) 1408113 * 8 * 2 = 2513G + 21.5M So even if the original bytestring file is being kept entirely in memory somehow that's not more than 3G. I've written a small driver test program that just parses the CSV, finds the minimum value for a couple of the Float fields, and exits. In the process monitor the memory usage is 6.9G before the program exits. I've tried profiling with +RTS -hc but it ran for >3 hours without finishing, it normally finishes within 4 minutes. Anyone have any ideas for me? Things to try? Thanks, Andrew

4 5

How to select n random words from a file ...
by Noon Silk 11 Jun '12

11 Jun '12

Hi, I'm clearly new to haskell, and I suppose those is a basic question, but after a bit of searching I've been unable to figure out the "best" way to do this. I was first trying to find out how to, say, get a random element from a list, but I'm starting to think that may not be the best way (because list access isn't constant time, among other reasons). So, I wonder if there is a more direct way to just get a random word from a wordfile (i.e. one word per line) ... can anyone suggest a method? Ideally I'd like to be able to adapt this to get n random words from several files (i.e. randomly select n words from all files; i.e. just read them into one merged array and choose from there?) Thanks for any advice ... -- Noon Silk Fancy a quantum lunch? https://sites.google.com/site/quantumlunch/ "Every morning when I wake up, I experience an exquisite joy — the joy of being this signature."

6 5

Re: [Haskell-cafe] converting functional dependencies to type families
by Henning Thielemann 11 Jun '12

11 Jun '12

On Thu, 7 Jun 2012, Simon Peyton-Jones wrote: > Very useful! Maybe worth turning into a page on the Haskell wiki? I created one: http://www.haskell.org/haskellwiki/Functional_dependencies_vs._type_families

2 2

Haskell User Group Hamburg (Germany) - Meeting Thursday June 14th 2012
by Stefan Schmidt 10 Jun '12

10 Jun '12

Hello cafe, there's an upcomming meeting of the Haskell user group Hamburg next Thursday (June 14th). We'll start 19:00 at the Xing AG in Hamburg (Gänsemarkt 43, 20354 Hamburg). Falko Peters will give a short talk about hedis ( http://hackage.haskell.org/package/hedis) a Redis client written in Haskell. Although this announcement is written in english the talk will be given in german. So if you are interested to come, have a look at our doodle (also in german) and give us a short note if you want to join us. http://www.doodle.com/3fz45uqupp8pzutb Further announcements will be made via Twitter, so you may want to follow https://twitter.com/hug_hh. Stefan Schmidt

1 0