- Haskell-Cafe - Haskell.org

Error handling package
by Michael Snoyman 20 Oct '09

20 Oct '09

While working on the next release of data-object, I wanted to represent some operations that might fail. The typical candidates were: 1) Maybe 2) Either 3) Monad Monad is always iffy because of the often times poorly defined fail. Maybe doesn't provide any means of reporting what the problem was. Either is not defined as a Monad in the base library. Also, the usual candidate of Either String only provides for an error message. It would be nice to have more in-depth information available. So I've put together a package I call "attempt". It defines a data type called (surprise) Attempt with a Success and Failure constructor. The trick here is that it using the new extensible exceptions under the surface, so you can report any kind of exception you want. It also provides a "FromAttempt" type class for possible conversion targets from an Attempt, provides an attempt function with some helpers for performing the equivalent of Control.Exception.catches, and provides two samples of functions I would want to implement with this library: attemptJoin and attemptLookup. My questions for the list are: 1) Is the overall approach sound, or do people have better ideas? 2) Are there any other FromAttempt instances I should provide out of the box? 3) I was considering adding specialized versions of the fromAttempt function, ie ioFromAttempt, maybeFromAttempt. Thoughts? 4) Should I follow the naming scheme attemptJoin, attemptLookup, etc, or just call the functions join, lookup and force people to import the module qualified? 5) Any other suggestions for attempt functions? I've considered head/tail/etc. 6) Include ToAttempt? The code is available on github at http://github.com/snoyberg/attempt/blob/master/Data/Attempt.hs . I appreciate the review. Also, I have not yet documented the code, but I will do so before uploading to Hackage; I just didn't want to document a changing target. Thank you, Michael

3 6

debugtracehelpers Re: traceM and traceShowM
by Thomas Hartman 20 Oct '09

20 Oct '09

I have this and a couple other handy functions in DebugTraceHelpers: http://patch-tag.com/r/tphyahoo/DebugTraceHelpers/snapshot/current/content/… hackage: http://hackage.haskell.org/packages/archive/DebugTraceHelpers/0.12/doc/html… 2009/10/16 Martijn van Steenbergen <martijn(a)van.steenbergen.nl>: > Hello, > > I propose the addition of the following two functions to module Debug.Trace: > >> traceM :: Monad m => String -> m () >> traceM msg = trace msg (return ()) >> >> traceShowM :: (Show a, Monad m) => a -> m () >> traceShowM = traceM . show > > These functions allow tracing in any do-block. I often define them myself; I > think they are useful in general. > > Deadline: 23 October 2009. > > Martijn. > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://www.haskell.org/mailman/listinfo/libraries >

3 2

Make two windows work together
by xu zhang 20 Oct '09

20 Oct '09

Hi there, I am trying to make a sub-window of one window and make them work together. I mean, if I zoom or transform some content in one of the window, the other one works in the same way. What I have done so far is just open a new window which have the same drawing view as the original one, but when I try to change some content in one window, the other one does not work at the same time. They are separate. Can anyone give me some hint on how to make them work at the same time not separate anymore? Thank you so much!

2 1

GHC devs
by Andrew Coppin 20 Oct '09

20 Oct '09

Random question of the day: How many developers are working on GHC? I had always *assumed* that there was something like a hundred core developers, with a much larger number of people casually testing and occasionally submitting the odd patch or two. However, I watched a video of a talk the other day (no, I don't remember which one) and it made me reconsider this view. Somebody muttered something like "GHC is really too big now for just 3 developers to manage", which makes it sound as if there are only 3 active developers... Surely that can't be correct. (There would never be any releases, for one thing...) Does anybody know anything concrete about this?

9 14

Re: [Haskell-cafe] Parsec bug, or...?
by S.Doaitse Swierstra 20 Oct '09

20 Oct '09

After some private exchange of info between Uwe and me it became clear that it may not have been immediately clear that the error messages in my original posting where actually part of a more involved process. By removing the optional part in the pCommand (i.e. making the part starting with `opt` invisible, we can show the full power of the built- in error correction. import Text.ParserCombinators.UU.Parsing pCommand [] = pure [] pCommand (x:xs) = ((:) <$> pSym x <*> pCommand xs) -- `opt` (x:xs) pCommands = amb . foldr (<|>) pFail . map pCommand $ ["banana", "chocolate", "frito", "fromage"] t :: String -> ([String], [Error Char Char Int]) t input = parse ( (,) <$> pCommands <*> pEnd) (listToStr input) Now one also gets error messages like: *Main> t "frxi" (["frito"],[ Deleted 'x' at position 2 expecting one of ['i', 'o'], Inserted 't' at position 4 expecting 't', Inserted 'o' at position 4 expecting 'o']) for free. However, since the decision what element to take is based on a limited look-ahead, one also gets: *Main> t "xfxrxix" (["fromage"],[ Deleted 'x' at position 0 expecting one of ['b', 'c', 'f', 'f'], Deleted 'x' at position 2 expecting 'r', Deleted 'x' at position 4 expecting 'o', Deleted 'i' at position 5 expecting 'o', Deleted 'x' at position 6 expecting 'o', Inserted 'o' at position 7 expecting 'o', Inserted 'm' at position 7 expecting 'm', Inserted 'a' at position 7 expecting 'a', Inserted 'g' at position 7 expecting 'g', Inserted 'e' at position 7 expecting 'e']) *Main> which is something not completely expected; the current look-ahead is however three symbols ahead, and once a decision is taken this is not reconsidered (for cost reasons). This is currently a consequence of the rather simplistic inner organisation of the intermediate library. In the next version we hope to have gotten rid of this artefact. Best, Doaitse > > Yes, for my particular problem the complexity is very limited. I > wouldn't even have used parsec for this, in spite of the comment I had > made earlier about this, if I were not already using it in a different > part of the project to parse individual records ("buy security <foo> > for this price on this date", etc), so it was natural to add a bit > more parsec code to also deal with the commands saying what I want to > see from the data. It's all still pretty trivial, but starting already > to be useful to me... it's really quite gratifying what a small amount > of haskell code suffices to make a useful and flexible program. > > best regards, > Uwe > > On 10/15/09, S. Doaitse Swierstra <doaitse(a)swierstra.net> wrote: >> >> On 15 okt 2009, at 16:58, Uwe Hollerbach wrote: >> >>> Hi, all, thanks for the further inputs, all good stuff to think >>> about... although it's going to be a little while before I can >>> appreciate the inner beauty of Doaitse's version! :-) >> >> The nice thing is that you do not have to understand the inner >> workings ;-} I basically builds a greedy parser for each word to be >> recognised which can stop and assume the rest is there if it can no >> longer proceed (the `opt` is greedy in its left alternative) . Hence >> it recognises the longest possible prefix. >> Since my parsers pursue all alternatives in parallel you >> automatically >> get what you want, without having to indicate prefix lengths, calls >> to >> try, etc. >> >> The "amb" combinator has type >> >> amb :: Parser a -> Parser [a] >> >> and collects the result from all alternatives its argument parser is >> constructed from; you might say it convert an ambiguous parser to a >> parser with a list as result, hence preventing the rest of the input >> being parsed over and over again. I am currently working on bringing >> back more abstract interpretation in the implementation (i.e. what we >> have had for almost 10 years in the uulib library), but I do not >> expect you to see a lot of that from the outside. >> >> If you want to work with left-recursive parsers (which does not seem >> to be the case), you may revert to more complicated solutions such as >> found in the "christmastree" (Changing Haskell's Read Implementation >> Such That by Manipulationg Abstract Syntax Trees Read Evaluates >> Efficiently) package if you need to generate parsers online, or to >> happy-based solutions in case your grammar is fixed. >> >> >> If you have any questions do not hesitate to ask, >> Doaitse >> >> >>> I had considered >>> the approach of doing a post-parsec verification, but decided I >>> wanted >>> to keep it all inside the parser, hence the desire to match prefixes >>> there (and lack of desire to write 'string "p" <|> string "pr" <|> >>> string "pre" ...'. >>> >>> By way of background, the actual stuff I'm wanting to match is not >>> food names, but some commands for a small ledger program I'm working >>> on. I needed something like that and was tired of losing data to >>> quicken every so often. I realize of course that there are other >>> excellent ledger-type programs out there, but hey, I also needed >>> another hacking project. I'll put this onto hackage in a while, once >>> it does most of the basics of what I need. No doubt the main >>> differentiator between mine and those other excellent ledger >>> programs >>> out there will be that mine has fewer features and more bugs... >>> >>> thanks again, all! >>> >>> Uwe >> >>

1 0

ANN: strptime bindings
by Eugene Kirpichov 20 Oct '09

20 Oct '09

Hi all. I had to parse dates from bytestrings efficiently and tried to use the parsedate library, but I had to port it to parsec3 to make it usable with bytestrings, and I could not get decent performance out of the resulting version due to ghc having difficulties with parsec3's generality, so I wrote bindings to strptime. Here they are: http://hackage.haskell.org/package/strptime They work for Strings and strict and lazy bytestrings. They are several orders of magnitude faster than parsedate and than Data.Time.readTime,parseTime (a program that ran in 40s with parsec3'd parsedate runs in less than 1s). -- Eugene Kirpichov Web IR developer, market.yandex.ru

1 0

Re: [Haskell-beginners] map question
by oleg＠okmij.org 20 Oct '09

20 Oct '09

> Something I wonder from time to time if it would be a good thing or > not is to allow > a `f g` b > to mean > f g a b You don't have to wonder: http://www.haskell.org/haskellwiki/Infix_expressions Granted, you have to use different characters rather than the backquote. On the other hand, you can play with infix expressions right now, on any Haskell98 system.

1 0

Problems with Haskell
by Philippos Apolinarius 20 Oct '09

20 Oct '09

Before anything else, I want to point out that I have no intention to confront your community, or denigrate Haskell. A few days ago I answered an email from a Clean programmer on something related to Clean. He was worried that Clean team could give up its good work, and Clean could disappear; therefore, he was thinking about switching to Haskell. Since I thought that my email could be of interest for the Clean community, I posted it in the -- small-- Clean list :-(Clean is not as popular as Haskell). I received a lot of furious and offensive private emails for suggesting the Clean programmer to stick with Clean. However, I also received a very polite, humorous, and illuminating private email from a person who seems to work at Microsoft. His name is Simon Peyton-Jones. He urged me to post my comments on a Haskell cafe. He also filed one of my comments as a bug in a Haskell bug track. Here is a couple of snippets from his email: --- I think it's v bad that a straightforward program runs so slowly, and it's certainly true that this is an area we could pay more attention to. --- Meanwhile, I'm curious: are the arrays in Philippos's program strict? Or lazy? If strict, that's a pretty big difference. Therefore, here are my comments, with a lot of code. A few months ago I came accross an unpublished article about a novel genetic programming system. The system was coded in Larceny Scheme. I translated it to Clean and to Haskell. Unhappily, I cannot post the program here because it is very large, and the authors of the original Lisp program don't want me to divulge it before they see in in a printed page of a Journal. Therefore, I wrote an empty genetic programming framework, just to compare languages. Comparing Clean and Haskell, I noticed: 1 -- Clean compiler almost never let me do very stupid things, like trying to unbox a tree, or to write in a closed file (I will post an example of this in a near future). For instance, Clean compiler would never swallow something like the code below: import Control.Monad.ST import Data.Array.ST import Data.Array.Base import System.Random data Op = AND | OR | NOT; data Tree= L Double | T Op [Tree] main = print $ runST (do arr <- newArray (1,2000000) (L 0.0) :: ST s (STArray s Int Tree) go arr 2000000 0.0 ) go :: STArray s Int Tree -> Int -> Double -> ST s Double go a i acc | i < 1 = return acc | otherwise=do b <- unsafeRead a i {- readArray a i -} writeArray a i (setDouble ((getDouble b)+3.0)) c <- readArray a i go a (i-1) (acc+ (getDouble c)) -- What I really need is a random index in Haskell. getDouble (L r)= r getDouble _ = 0.0 setDouble r= L r 2 -- Safety does not cost much in Clean. For instance, removing array boundary check does not seem to affect Clean. I believe that it does not affect Haskell either, but I have not verified this point. 3 -- Haskell seems to loop more often than Clean. For instance, Haskell may loop if I change function mutate to mutate e (L i) xs = (e, xs) mutate e t (y:ys) = ins t (rnLen t y, ys) where ins (T p (L i:xs)) (0, st)=(T p (e:xs), st) ins (T p (t:xs)) (n,(r1:rs)) | n > 0= let (T p mt, s2)= ins (T p xs)(n-1, rs) in (T p (t:mt), s2) ins (T p (t:xs)) (n,(r1:rs)) | rn 2 r1== 0= (T p (e:xs), rs) | rn 2 r1== 1= let (xpr, st)= mutate e t rs in (T p (xpr:xs), st) This might be a bug in my implementation of show Tree. It would be great if you people could "show" me what I did wrong. 4 -- On the plus side, there are libraries in Haskell that seem to behave better than the Clean equivalent libraries. This could be explained by the fact that there are a lot of people coding Haskell libraries, while Clean team seems to be reluctant in accepting libraries from outsiders. For instance, lethevert made a very important improvement in ObjectIO (changing fonts in edit text field), but it was never incorporated into Clean (yes, I wrote a lot of emails to Clean team about it). Last year, when I was learning Clean, I discovered that many of my professors and teachers are presbyopic. Therefore, it would be a good policy to use very large fonts for homework. I only succeeded in doing it thanks to lethevert. In the case of the program below, Haskell System.Random library seems to work much better than Clean MersenneTwister. 5 --- Any improvement in the program below will be welcome. The program is already very fast thanks to suggestions I received from the bug track people, and from Peyton-Jones. Function "show" seems to loop if I replace mutate in item 3 for mutate in the code below. {- ghc gp.hs -O2 --make -} {- Execute: gp.exe +RTS -sstderr -} import Control.Monad.ST import Data.Array.ST import Data.Array.Base import System.Random data Op = AND | OR | NOT; data Tree= L Int | T Op [Tree] psz= 20000 thr=4.0 gates= [AND, NOT, OR] table= [ (False, False, False), (True, False, True), (True, True, False), (False, True, True)] prt NOT= "NOT" prt OR= "OR" prt AND= "AND" instance Show Tree where show (L i) = "L"++(show i) show (T p xs) = (prt p)++(show xs) main = do xs <- (rnList (1, 20000)) print $ runST $ do arr <- newArray_ (1,psz) :: ST s (STArray s Int Tree) (arr, xs1) <- gen0 arr psz xs g1 <- evolve 30 arr (L 0) xs1; return $ g1 gen0 a i xs = if i<=0 then return(a,xs) else do (tree, rs) <- return(rndXpr gates 5 xs) writeArray a i tree gen0 a (i-1) rs mutate e (L i) xs = (e, xs) mutate e t (y:ys) = ins t (rnLen t y, ys) where ins (T p (L i:xs)) (0, st)=(T p (e:xs), st) ins (T p (t:xs)) (n,(r1:rs)) | n > 0= let (T p mt, s2)= ins (T p xs)(n-1, rs) in (T p (t:mt), s2) ins (T p (t:xs)) (n,(r1:rs)) | rn 2 r1== 0= (T p (e:xs), rs) | rn 2 r1== 1= let (xpr, st)= mutate e t rs in (T p (xpr:xs), st) fxy NOT r= T NOT [L (rn 2 r)] fxy AND st = T AND [L 0, L 1] fxy OR st = T OR [L 0, L 1] rndXpr fs beastSz xs= loop beastSz xs where rth s r= s!!(rn (length s) r) loop n (r1:r2:rs) | n<1 = (fxy (rth fs r1) r1, rs) |otherwise= mutate (fxy (rth fs r1) r2) f1 rs where (f1, ys)= loop (n-1) rs run (L 0) x y= x -- Interpreter run (L 1) x y= y run (T AND xs) x y = and [run c x y | c <- xs] run (T OR xs) x y= or [run c x y | c <- xs] run (T NOT (t:_)) x y= not (run t x y) rn n r= (abs r) `rem` n rnLen (T _ s) r= rn (length s) r rnList :: (Int, Int) -> IO [Int] rnList r=getStdGen>>=(\x->return(randomRs r x)) frag (L i) st = (L i, st) frag (T p xs) (r1:r2:rs) | rn 2 r2==0= (xpr, rs) | otherwise= frag xpr rs where xpr= xs!!(rnLen (T p xs) r1) crossover e1 e2 rs = ([c2, c1], rs4) where (g1, rs1) = frag e1 rs (g2, rs2) = frag e2 rs1 (c1, rs3) = mutate g1 e2 rs2 (c2, rs4) = mutate g2 e1 rs3 nGates (L i)= 0.0 nGates (T p xs) = (-0.1) + sum [nGates g | g <- xs] fitness tt gt = (ng + 1.0 + sum [ft t | t <- tt]) where ng= nGates gt ft (out, t1, t2) | run gt t1 t2 == out= 1.0 ft _ = 0.0 evolve n p b xs | n < 1 = do (arr, xs1) <- gen0 p psz xs evolve 30 arr b xs1 evolve n p b (r1:r2:rs) = do n1 <- return $ 1+(rn psz r1) n2 <- return $ 1+(rn psz r2) g1 <- readArray p n1; g2 <- readArray p n2 ([c1,c2], rs) <- return $ crossover g1 g2 rs insrt c1 p 1 psz insrt c2 p 1 psz res <- best 1 b p fitn <- return $ fitness table res if fitn > thr then return res else evolve (n-1) p res rs best i res p | i >= psz= return res best i fg p= do g <- readArray p i if (fitness table fg) > (fitness table g) then best (i+1) fg p else best (i+1) g p insrt g v i sz | i >= sz = return () insrt g v i sz = do a <- readArray v i fg <- return $ fitness table g fa <- return $ fitness table a if fa > fg then insrt g v (i+1) sz else do writeArray v i g __________________________________________________________________ Connect with friends from any web browser - no download required. Try the new Yahoo! Canada Messenger for the Web BETA at http://ca.messenger.yahoo.com/webmessengerpromo.php

2 1

Re: Documentation (was: ANN: text 0.5, a major revision of the Unicode text library)
by John Lato 19 Oct '09

19 Oct '09

> From: Derek Elkins <derek.a.elkins(a)gmail.com> > > On Sun, Oct 11, 2009 at 8:55 AM, Iain Barnett <iainspeed(a)gmail.com> wrote: >> >> On 11 Oct 2009, at 13:58, John Lato wrote: >> >>> For anyone writing introductions to generic programming, take this as >>> a plea from Haskellers everywhere. If one of the RWH authors can't >>> understand how to make use of these techniques, what hope do the rest >>> of us have? >>> >>> John Lato >>> >>> P.S. Some might wryly note that I'm the maintainer of a package which >>> is also known for incomprehensible documentation. To which I would >>> reply that our effort is much newer, I consider it a problem, and it's >>> being worked on, contrasted to the state of GP where similarly >>> impenetrable documentation has been and continues to be the norm. >>> >> >> You could say that about most documentation (for Haskell and beyond). >> Apparently, programmers like programming better than documenting. The effect >> of this is that less people use their programming, making their efforts >> redundant. >> >> Silly really, considering programmers are (allegedly:) intelligent. > > Apparently, programmers like programming better than reading as > well... in my experience. I won't disagree. But I think the real difficulty is that the intersection of programmers who can come up with really good ways to solve problems (not even all programmers, unfortunately) and people who are good at writing documentation is vanishingly small. It seems to me that when someone works in a problem domain (e.g. Generic Programming), they gain a very deep understanding of that area and are used to working at a certain level within it. When introducing the topic to newcomers (even ostensibly smart programmers) the introduction can't assume prior knowledge of the problem domain, but the authors are so used to thinking at one level they often take for granted knowledge that the audience doesn't have. I don't think this problem is particular to programming, but it is common in Haskell. Most likely because Haskell, with a reputation as a research language, has a lot of computer science types doing research in wide-ranging topics. Somebody's expertise in category theory, for example, might not directly carry over to generic programming (or maybe it does; I'm not an expert in either).

3 2

ANNOUNCE: cereal-0.2
by Trevor Elliott 19 Oct '09

19 Oct '09

Hello Everyone, cereal is a variation on the binary package that provides strict parsing, handleable exceptions with a named call stack, and a new parsing isolation feature. The major differences from binary are a new class called Serialize replacing the Binary class, getting and putting using strict ByteStrings and a number of combinators for parsing lists, arrays and other containers. Version 0.2 is available from hackage: * http://hackage.haskell.org/package/cereal-0.2 --trevor

1 0