October 2009 - Haskell-Cafe

Problems with Haskell
by Philippos Apolinarius 19 Oct '09

19 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

Hackage down
by Dougal Stanton 19 Oct '09

19 Oct '09

Has not been responding for at least the last 12 hours. Is there somewhere to look for status reports on sysadmin details like this, so we can tell if - it's a scheduled down time - it's a problem but the admins know about it - etc etc. D -- Dougal Stanton dougal(a)dougalstanton.net // http://www.dougalstanton.net

7 6

Re: [Haskell-cafe] Error handling package
by Michael Snoyman 19 Oct '09

19 Oct '09

On Mon, Oct 19, 2009 at 3:39 PM, Jose Iborra <pepeiborra(a)gmail.com> wrote: > You may want to take a look at anoother option in Hackage, the > control-monad-exception package. > > http://pepeiborra.github.com/control-monad-exception/ > > The control-monad-exception library provides the building blocks for > > * Explicitly Typed exceptions (checked or not) > * which are composable > * and even provide stack traces (experimental feature) Jose, Thank you very much, thinks looks like just the thing I was looking for. The only thing that slightly concerns me is the transformers dependency, but it's not a serious worry. I'd love to try out the package right now, but with hackage being down I can't get the dependencies yet ;). I'll try it out as soon as I can. > > > > On 19/10/2009, at 01:00, Michael Snoyman wrote: > > (Sorry, accidently took off cafe.) >> >> On Mon, Oct 19, 2009 at 12:44 AM, Henning Thielemann < >> lemming(a)henning-thielemann.de> wrote: >> >> On Mon, 19 Oct 2009, Michael Snoyman wrote: >> >> Does the explicit-exception package provide what you need? >> >> http://hackage.haskell.org/package/explicit-exception >> >> >> I don't think so, but correct me if I'm wrong. I want to make it easy to >> chain together >> computations which could fail in different ways. For example, something >> like this: >> >> attemptReadInt :: String -> Attempt Int >> attemptLookup :: String -> [(String, String)] -> Attempt String >> attemptLookupInt :: String -> [(String, String)] -> Attempt Int >> attemptLookupInt k m = attemptLookup k m >>= attemptReadInt >> >> Now, in the explicit-exception package, I could- in this simple example- >> define >> something like: >> >> data MyErrors = KeyNotFound | InvalidInt >> >> >> type Attempt = Exceptional MyErrors >> >> True; that's what I meant by I could do this in my simple example. >> >> >> But this solution would not scale. >> >> You want to add other exceptions? The idea of my package is to make >> exceptions explicit in the type. Otherwise you would use >> extensible-exceptions. Or you could define MyErrors using an existential >> type. >> >> Which is my point. I'm trying to provide a package for non-explicit >> exceptions. To compare to other programming languages, I think your package >> is providing the equivalent of Java checked exceptions, while mine is >> providing (safe) unchecked exceptions. I say safe because you still need to >> explicitly decide to turn an Attempt into a possible runtime exception which >> will bring down your program. >> >> Defining MyErrors using an existential type would essentially recreate the >> entire attempt package; I don't see that purpose in everyone wanted >> unchecked exceptions needing to reinvent the wheel in non-compatible ways. >> If multiple libraries use attempt, they can easily have their >> possible-error-returning functions chain together safely. >> >> > I believe that control-monad-exception solves this tension between > composability and explicit exceptions. > You can have explicit exceptions which are composable: > > > data DivideByZero = DivideByZero deriving (Show, Typeable) > > data SumOverflow = SumOverflow deriving (Show, Typeable) > > > instance Exception DivideByZero > > instance Exception SumOverflow > > > data Expr = Add Expr Expr | Div Expr Expr | Val Double > > > eval (Val x) = return x > > eval (Add a1 a2) = do > > v1 <- eval a1 > > v2 <- eval a2 > > let sum = v1 + v2 > > if sum < v1 || sum < v2 then throw SumOverflow else return sum > > eval (Div a1 a2) = do > > v1 <- eval a1 > > v2 <- eval a2 > > if v2 == 0 then throw DivideByZero else return (v1 / v2) > > GHCi infers the following types > > > :t eval > > eval :: (Throws DivideByZero l, Throws SumOverflow l) => Expr -> EM l > Double > > > :t eval `catch` \ (e::DivideByZero) -> return (-1) > > .... :: Throws SumOverflow l => Expr -> EM l Double > > > :t runEM(eval `catch` \ (e::SomeException) -> return (-1)) > > .... : Expr -> Double > > >> Additionally, there's two immediate features I think I would miss from my >> package: >> >> 1) fail works properly, so an Attempt would be a valid monad response from >> people who >> use that function. >> >> As far as I understand, 'fail' is used/abused for reporting failed pattern >> matches in do notation. If a failed pattern match indicates a programming >> error, it should be a really error, and not something that must be handled >> at run-time. >> >> That's a lot of very debateable statements you just made. It might be that >> it's strongly encouraged to only use fail for failed pattern matching, but >> in practice you could use it for any monadic failure. Also, there's nothing >> stopping a user from re-throwing pattern match exceptions received in an >> Attempt. >> > > I am with Henning on 'fail'. > It must not be used as a replacement for throw, only for failed pattern > matches which are programming errors and thus unchecked exceptions. > I'm not arguing how it *should* be used, I'm arguing how it *might* be used, and I think calling error is not appropriate. An unchcked exception which can be caught if necesary (I'm assuming that's what runEMParanoid does) sounds like that right thing. Michael

1 0

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

19 Oct '09

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. > > From: "Bryan O'Sullivan" <bos(a)serpentine.com> > > I think maybe someone else will have to take a crack at a Data instance for > Text, because the documentation for Data.Data is not written in English. In > its syntax and structure, it closely hews to what we think of as English, > but it is the kind of documentation that can only be understood by someone > who already knows what it is going to say. > > This is an exemplar of my experience with the cottage industry of generic > programming in Haskell: I'd really quite like to use the stuff, but for > goodness's sake, o beloved researchers, please aim your expository papers at > non-specialists once in a while. An endless chain of papers of the form "my > technique, which you won't understand, is better than this other technique, > which you haven't read about and won't anyway understand, in subtle ways > that you won't understand" does not feel to me like progress. > > Yours in some misery and frustration, > Bryan.

5 4

Too much strictness in binary-0.5.0.2
by Khudyakov Alexey 18 Oct '09

18 Oct '09

Hello I run into problems with new binary package. Following function reads a list of elements one by one until end of stream. List is very long (won't fit into memory). In binary-0.5.0.1 and earlier it read list lazily. Now it seems that it tries to read whole list to memory. Program does not produce any output and memory usage steadily grows. > getStream :: Get a -> Get [a] > getStream getter = do > empty <- isEmpty > if empty > then return [] > else do x <- getter > xs <- getStream getter > return (x:xs) How could I add laziness to this function to revert to old behavior. -- Khudyakov Alexey

3 3

Merging modules
by pat browne 18 Oct '09

18 Oct '09

Hi, I want to establish the strengths and weakness of the Haskell module system for the ontology merging task (I know it was not designed for this!). I wish to make a new module (MERGEDONTOLOGY) from three input modules one of which is common to the other two. The desired merge should contain the following data types: Woman FinancialBank HumanBeing RiverBank Which are all identifiable without any qualifying module names. Below is the detailed requirement and my first attempt at this task in Haskell. I would be grateful for any information on how to merge these modules giving a set of unique unqualified types (i.e. without reference to their originating modules). Regards, Pat ======================== Informal Specification ======================== The diagram and text below explain the requirement MERGEDONTOLOGY { Woman, RiverBank, FinancialBank, HumanBeing} /\ /\ / \ / \ / \ / \ / \ / \ ONTOLOGY1 ONTOLOGY2 {Woman, Bank, Person} {Woman, Bank, Human} /\ /\ \ / \ / \ / \ / \ / \ / \ / {Woman , Person} COMMMON This example includes both synonyms and homonyms. 1)The Woman sort (or data type) should be the same in all modules, there is only one Woman sort and it is named as such in each module. Hence there should be only one MERGEDONTOLOGY.Woman. 2)There is only one sort MERGEDONTOLOGY.HumanBeing, but there are 3 synonyms for it called ONTOLOGY2.Human, ONTOLOGY1.Person, and COMMON.Person. The last sentence considers ONTOLOGY1.Person and COMMON.Person as synonyms; they have different qualifiers but the intention is that they represnt the same thing. Hence should be mapped to same MERGEDONTOLOGY.HumanBeing. To do this (in Maude) COMMON.Person was renamed to ONTOLOGY2.Human which in turn was renamed to MERGEDONTOLOGY.HumanBeing. 3)The homonyms are ONTOLOGY1.Bank and ONTOLOGY2.Bank should become distinct sorts MERGEDONTOLOGY.RiverBank and MERGEDONTOLOGY.FinancialBank in the final ontology at the top of the diagram. ================================================ My first attemt at merging using Haskell modules ================================================= module COMMON where data Woman = WomanC data Person = PersonC module ONTOLOGY1 where import COMMON data Bank = BankC module ONTOLOGY2 where import COMMON data Bank = BankC module MERGEDONTOLOGY where import ONTOLOGY1 import ONTOLOGY2 If I use qualified names all the constructors are interpreted correctly MERGEDONTOLOGY> :t COMMON.WomanC COMMON.WomanC :: COMMON.Woman MERGEDONTOLOGY> :t COMMON.PersonC COMMON.PersonC :: COMMON.Person MERGEDONTOLOGY> :t ONTOLOGY2.BankC ONTOLOGY2.BankC :: ONTOLOGY2.Bank MERGEDONTOLOGY> :t ONTOLOGY1.BankC ONTOLOGY1.BankC :: ONTOLOGY1.Bank MERGEDONTOLOGY> :t COMMON.Woman However, I wish that these types and constructors be fully defined in the context of the MERGEDONTOLOGY. I have tried type synonyms and newtypes. type RiverBank = ONTOLOGY1.Bank type FinancialBank = ONTOLOGY2.Bank newtype RiverBank = BankC Int I have not explored import modes or qualified imports.

2 4

x -> String
by Andrew Coppin 18 Oct '09

18 Oct '09

Is there any way that you can turn an arbitrary Haskell value into a string? I rephrase: There *is* a way to turn arbitrary values into strings. I know there is, because the GHCi debugger *does* it. The question is, does anybody know of an /easy/ way to do this? Basically, I'm writing a mutable container implementation. It can hold any type of data, but it would massively aid debugging if I could actually print out what's in it. On the other hand, I don't want to alter the entire program to have Show constraints everywhere just so I can print out some debug traces (and then alter everything back again afterwards once I'm done debugging). Anybody know of a way to do this? (As it happens, the values I'm testing with are all Showable anyway, but the type checker doesn't know that...)

8 13

Happstack + network package issue on the Mac
by Sean Leather 18 Oct '09

18 Oct '09

We have run into an issue that it seems other people have already found but has apparently not been resolved, yet. It manifests as with the error "HTTP request failed with: Unsupported socket". The problem is described in two places with different workarounds. http://code.google.com/p/happstack/issues/detail?id=88 http://groups.google.com/group/HAppS/msg/0c9a0d0fd7c6aff0 One workaround is to rewrite part of the network package, and the other is to downgrade the package. It could be the case that the rewrite came from the older version, though I'm not sure. I'm curious if it is possible to fix this, either in Happstack or the network package, once and for all. The workarounds are rather painful when so many things depend on the network package. Thanks, Sean

5 9