December 2010 - Haskell-Cafe

Strange error when using Attoparsec and Enumerator
by Crutcher Dunnavant 05 Dec '10

05 Dec '10

I have spent a good chunk of the past week tracing code, trying to solve this problem. I'm seeing an error when using Enumerator and Attoparsec that I can't explain. This is a reduced form of the problem. In general, I've observed that debugging broken iterators and enumerators is very hard. We probably want some tooling around that; I'm looking at an identity enumeratee with debug.trace shoved in, or something like that, not sure yet what would help. {- Haskell 2010, ghc 6.12.3 array-0.3.0.2 attoparsec-0.8.2.0 attoparsec-enumerator-0.2.0.2 bytestring-0.9.1.7 containers-0.4.0.0 deepseq-1.1.0.2 enumerator-0.4.2 text-0.10.0.0 transformers-0.2.2.0 -} import Control.Applicative ((<|>)) import qualified Data.Attoparsec.Char8 as AP import qualified Data.Attoparsec.Combinator as APC import qualified Data.Attoparsec.Enumerator as APE import qualified Data.ByteString.Char8 as B import qualified Data.Enumerator as E import Data.Enumerator (($$)) import System.IO as IO parseLine :: AP.Parser B.ByteString parseLine = do AP.char '+' return . B.pack =<< APC.manyTill AP.anyChar endOfLineOrInput endOfLineOrInput :: AP.Parser () endOfLineOrInput = AP.endOfInput <|> AP.endOfLine pp :: Show a => AP.Parser a -> String -> IO () pp p s = do result <- E.run $ E.enumList 1 [ B.pack s ] $$ E.sequence (APE.iterParser p) $$ E.printChunks False case result of (Right _) -> return () (Left e) -> IO.hPutStrLn stderr $ show e main = pp parseLine "+OK" {- Observed output: ["OK"] *** Exception: enumEOF: divergent iteratee Problems with this: 1) I didn't write an iteratee, enumerator, or enumeratee in this code. Something's wrong. 2) If the parser is divergent, I _should_ be getting the error message: "iterParser: divergent parser" -} -- Crutcher Dunnavant <crutcher(a)gmail.com>

3 3

New Xmobar maintainer: request for comments
by Jose A. Ortega Ruiz 05 Dec '10

05 Dec '10

Hi, I've recently accepted Andrea Rossato's kind offer to take over maintainership of xmobar, and i wanted to ask for feedback to the community. My apologies for cross-posting to the cafe and xmonad, but xmobar didn't have a mailing list until a couple days ago. My immediate plans are to fix some low-hanging bugs, incorporate a handful of patches and contributions i have in my repo and make a new release (0.12). Besides that, i've created a mailing list (xmobar(a)projects.haskell.org, http://projects.haskell.org/cgi-bin/mailman/listinfo/xmobar, also mirrored at gmane.comp.lang.haskell.xmobar) and i will move xmobar's homepage to http://projects.haskell.org/xmobar (not done yet). Perhaps more disruptingly, i'm thinking of moving source code management from darcs to git (right now, i maintain a _mirror_ at github, http://github.com/jaor/xmobar) But xmobar has a very lively user base and many contributors, and i wouldn't like to alienate or disturb anyone: would that move be frown upon by the community? I also plan to keep hacking and adding (not many) features to xmobar in the future, and would be delighted to hear from you: please, do not hesitate to send your feature requests or any other comment directly to me or to the new list. Thanks in advance for your feedback, and special thanks to Andrea for creating xmobar and giving me this great chance of being more than a mere spectator of the haskell world. Cheers, jao -- Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it. - Alan Perlis, Epigrams in Programing

1 0

getErrorStatus in HXT
by Tobias Schoofs 05 Dec '10

05 Dec '10

Hi, I have some problems with the error processing in HXT. Here is a trivial example: e <- runX (transformDoc [] someRules src dst) transformDoc cfg rules src dst = configSysVars cfg >>> readDocument [] src >>> rules >>> -- some transformations writeDocument [] dst >>> getErrStatus I would expect "e" to contain an error value >= c_err for the case where any of the processing steps in transformDoc fails. But it does not, even with an io error on writeDocument. I guess I misunderstand "getErrStatus" in some way. Any idea? Thanks, Tobias

2 3

Hackage have ghc 7.0 false positives builds
by Maciej Piechotka 05 Dec '10

05 Dec '10

Hackage seems to hae false positive builds. For example llvm is reported to have been built with ghc despite problems with cabal (type errors and after quick'n'dirty fix it has errors). Regards

1 0

Safer common subexpression elimination
by Joachim Breitner 04 Dec '10

04 Dec '10

Hi, although semantically it could, ghc does not do common subexpression elimination (CSE), at least not in every case. The canonical example where it would be bad is the function (with div to avoid numerical casting): > avg :: [Int] -> Int > avg n = (sum [0..n] `div` length [0..n]) The reason why [0..n] is not shared is because then it would be kept in memory completely after the evaluation of sum, because length will still need it, possibly overflowing the memory. In the non-shared form, though, the garbage collector can clean up directly behind sum and length, and the program runs in constant space. Note that the shared expression would be very large compared to the thunks. Now consider the program: > avg' :: [Int] -> (Int, Int) > avg' n = (sum [0..n] `div` length [0..n], length [0..n]) I’d say that CSE to > avg n = (sum [0..n] `div` l, l) > where l = length [0..n] is safe, because the shared expression (an Int) is smaller than the thunks and the compiler can tell. So I wonder: * Is sharing values of type Int (and Bool and similar small values) always safe? * If so: does GHC already do that? * Would it be technically possible? * Is there an established theory that can tell, for a sharing candidate, whether it is safe to share it? Thanks, Joachim -- Joachim "nomeata" Breitner mail: mail(a)joachim-breitner.de | ICQ# 74513189 | GPG-Key: 4743206C JID: nomeata(a)joachim-breitner.de | http://www.joachim-breitner.de/ Debian Developer: nomeata(a)debian.org

4 5

Reduceron: reduced to numbers.
by Serguey Zefirov 04 Dec '10

04 Dec '10

I decided to calculate Reduceron's number of transistors (I had to, we have some argument here;). Reduceron allocate 14% of 17300 slices of Virtex-5 FPGA. If we assume that each slice correspond to 8 4-input NAND-NOT elements, we will get 20000 4-input NAND. Each 4-input NAND contains 8 transistors, so the count of logic transistors is about 160000. Reduceron use 90% of 1.5Kbyte RAM blocks. Using 6 transistors per RAM bit, we get 66K transistors more. So Reduceron should contain about 230K transistors if someone decides to go ASIC. It's 3 orders of magnitude less than x86, on par with most late chips of Chuck Moore (inventor of Forth, MISC concept and the one who develops some strange chips in GreenArrays http://greenarraychips.com/ now). The difference between Reduceron and GA144 of Chuck Moore is that Reduceron could be programmed much more easily, and that rocks. Clock frequency of 96MHz should go up too. My experience suggest numbers between 5 and 8 times. So single Reduceron should be of equal performance to Core2 Duo, at least. PS Of course, Reduceron in ASIC will require some cache memory, some controllers, etc. So it won't be that small, like 230K transistors. But, mzke it 2.3M transistors and it still be 2 orders of magnitude less than Core2 Duo... ;)

2 2

Wondering if this could be done.
by Magicloud Magiclouds 04 Dec '10

04 Dec '10

Hi, For example, I have a data A defined. Then I want to add (+) and (-) operators to it, as a sugar (compared to addA/minusA). But * or other stuff defined in class Num is meanless to A. So I just do: (+) :: A -> A -> A (+) a b = A (elem1 a + elem1 b) (elem2 a + elem2 b) -- I got errors here, for the (+) is ambiguous. So, just wondering, does this way work in Haskell? -- 竹密岂妨流水过山高哪阻野云飞

8 7

"Out of memory" if compiled with -O2, why?
by Dmitry Kulagin 04 Dec '10

04 Dec '10

Hi, I have problems with memory leaks and can't find out how to avoid them. I tried to reduce sample to demonstrate the following problems: 1) when compiled without -O2 option, it iconsumes 1582MB (!) total memory 2) when compiled with -O2 option it terminates with "out of memory" Actually I don't understand the reasons, particulary why GC can't collect already processed objects g,...,n (see code below)? I would appreciate very much any help with this situation. Thanks! module Main where import qualified Data.Map as M len = 15*1024*1024 lst from = take len $ zip [from..] [0..] g = M.size $ M.fromList $ lst 0 h = M.size $ M.fromList $ lst 0 i = M.size $ M.fromList $ lst 0 j = M.size $ M.fromList $ lst 0 k = M.size $ M.fromList $ lst 0 l = M.size $ M.fromList $ lst 0 m = M.size $ M.fromList $ lst 0 n = M.size $ M.fromList $ lst 0 main = do mapM_ print [g,h,i,j,k,l,m,n]

4 5

regex libraries: matching operators (=~) and (=~~) are not methods
by José Romildo Malaquias 04 Dec '10

04 Dec '10

Hello. When learning how to use the many regular expression libraries for Haskell, I noticed that the interface API from the regex-base package introduces several high level operations that are abstracted from the implementations (backends). This is done by means of classes. For instance, there are methods for compiling an external representation (like a string or a bytestring) into a regular expression. There are also methods for matching a regular expression and some text (like a string, or a bytestring). But the most high level functions for pattern matching using regular expressions, (=~) and (=~~), are not defined as methods in a class. They are independent functions defined for each backend in the corresponding package. This prevents one from writing a general function using these operators without deliberately choosing a regex backend. Why are those operators not defined as methods, like all other relevant functions? Romildo

1 1

Type families again
by Andrew Coppin 03 Dec '10

03 Dec '10

Yes, it's me. And yes, I come with yet more questions. With Haskell 98 (or, indeed, Haskell 2010) it is impossible to define a polymorphic version of "head" that works for [], Set and ByteString. You can use a higher-kinded type class for [], but that fails for Set (because you can't specify the Ord constraint) and fails spectacularly for ByteString (because it has the wrong kind). The basic problem is that the function's type needs to refer to the type of the container and the type of elements it contains, but the relationship between these types can be arbitrary. Type families allow you to neatly and cleanly fix the problem: class Head c where type Element c :: * head :: c -> Element c It's simple, comprehensible, and it /actually works/. Following this success, we can define functions such as tail, join, and so forth. What we /can't/ do is define a polymorphic map function. One might try to do something like class Functor f where type Element f :: * fmap :: (Element f2 ~ y) => (x -> y) -> f -> f2 instance Functor [x] where type Element [x] = x fmap = map However, this fails. Put simply, the type for fmap fails to specify that f and f2 must be /the same type of thing/, just with different element types. The trouble is, after spending quite a bit of brainpower, I literally cannot think of a way of writing such a constraint. Does anybody have any suggestions? Second, what's the difference between using "type", "newtype" and "data" in a class definition?

5 4