July 2003 - Haskell-Cafe

Why no findM ? simple Cat revisited
by Ahn Ki-yung 11 Nov '03

11 Nov '03

Simple Cat (revisitied) \begin{code} import IO findM f [] = return Nothing findM f (x:xs) = do { v <- x; if f v then return (Just v) else findM f xs } isLeft (Left _) = True isLeft _ = False main = findM (isLeft) (hCat stdin) where hCat h = try (hGetLine h) : hCat h \end{code} This is my answer for the question of my own, which is posted a couple There are mapM, filterM in the Haskell 98 Standard Library. But why no findM there ? As you can see from simple cat, it seems quite useful. I think fildM should be added to the module Monad. -- Ahn Ki-yung

5 8

Exporting GHC functions.
by Thomas L. Bevan 31 Jul '03

31 Jul '03

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Here is a copy of all the files I am using to try to export a Haskell function. This compiles but produces a executable that simply hangs. Tom -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/KUHbYha8TWXIQwoRAs8RAKCIFcnH9uuqfMpDYXA0gfFjBtMfEwCgjZeD 5dkfLbz/lz4btmsR9G4kL2A= =pCBN -----END PGP SIGNATURE-----

1 1

Linking to exported GHC functions.
by Thomas L. Bevan 31 Jul '03

31 Jul '03

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Could someone give me a command line example of how to link a C programme using functions exported via GHC FFI? I've compile C object files using an FFI function but can't for the life of me work out what arguments to pass to the compiler to make it link correctly. Thanks, Tom -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/KTyZYha8TWXIQwoRAlAwAKDu/gh3/TVvrVo8Damrr5K8YvbGgACgsz17 2MZqp/GG0K51O+6Gn829I0A= =mIS3 -----END PGP SIGNATURE-----

1 0

RE: Ann: HAllInOne bug fix release
by Hal Daume 31 Jul '03

31 Jul '03

(cafe) This seems like a reasonable hypothesis. Is there a way to get GHC to keep trying, despite the enormity of the input file? Specifically, I expect it to do a better job of (a) inlining and (b) specialization. Is there a way to hint to it to try a bit harder? :) - Hal -- Hal Daume III | hdaume(a)isi.edu "Arrest this man, he talks in maths." | www.isi.edu/~hdaume > -----Original Message----- > From: Koen Claessen [mailto:koen@cs.chalmers.se] > Sent: Thursday, July 31, 2003 1:49 AM > To: Simon Peyton-Jones > Cc: Hal Daume; Wolfgang Jeltsch; The Haskell Mailing List > Subject: RE: Ann: HAllInOne bug fix release > > > Simon Peyton-Jones wrote: > > | I don't know why the all in one version might go > | slower though. > > How about some (artificial) cut-offs during optimization > phases? Optimizing a hugs module could lead to some kind of > combinatorial explosion (which gets cut off by the > optimizer) which does not happen when you have separate > modules? > > Just my 2 öre! > > /Koen > >

1 0

RE: Ann: HAllInOne bug fix release
by Hal Daume 31 Jul '03

31 Jul '03

(haskell-cafe now) Interesting. I've stripped them and they are exactly the same size. diff says they differ though. pre-stripping, the normal nhc (non ai1) is marginally larger (6.8m versus 7.0m). I'll try to measure memory usage if someone tells me how :) - Hal -- Hal Daume III | hdaume(a)isi.edu "Arrest this man, he talks in maths." | www.isi.edu/~hdaume > -----Original Message----- > From: haskell-admin(a)haskell.org > [mailto:haskell-admin@haskell.org] On Behalf Of John Meacham > Sent: Wednesday, July 30, 2003 5:22 PM > To: The Haskell Mailing List > Subject: Re: Ann: HAllInOne bug fix release > > > Another useful thing would be the striped binary sizes of the two > versions. I am curious how much AllInOneing affects the resultant > binary. Memory usage would also be interesting. > John > > On Wed, Jul 30, 2003 at 04:22:58PM -0700, Hal Daume wrote: > > Ah, apparently it is not (at least not the Cygwin version). > > > > I recompiled NHC with GHC -O2, both the separate > compilation version and > > the all-in-over version. Averaged over five runs, we see that the > > separate compilation version is actually *faster* than the > ai1 version: > > > > standard nhc compiled with ghc: > > > > real 0m27.167s > > user 0m9.991s > > sys 0m1.304s > > > > nhc all-in-one: > > > > real 0m31.411s > > user 0m10.007s > > sys 0m1.299s > > > > > > > > i am completely unable to explain this. someone want to > hazard a guess? > > > > - hal, who is a bit disappointed now :( > > > > -- > > Hal Daume III | hdaume(a)isi.edu > > "Arrest this man, he talks in maths." | > www.isi.edu/~hdaume > > > > > > > -----Original Message----- > > > From: haskell-admin(a)haskell.org > > > [mailto:haskell-admin@haskell.org] On Behalf Of Wolfgang Jeltsch > > > Sent: Wednesday, July 30, 2003 2:59 PM > > > To: The Haskell Mailing List > > > Subject: Re: Ann: HAllInOne bug fix release > > > > > > > > > On Wednesday, 2003-07-30, 23:36, CEST, Hal Daume III wrote: > > > > [...] > > > > > > > A few people have asked me for speed-up results from > > > All-In-One-ifying code, > > > > so here's a good one. We take two versions of NHC. One is > > > the original > > > > binary distribution and the other is the All-In-One-ified > > > version, compiled > > > > by GHC. > > > > > > Hi, > > > > > > is the original binary distribution compiled with GHC? If > > > not, the speed-up > > > may also be the result of using a different compiler (i.e., GHC). > > > > > > > [...] > > > > > > Wolfgang > > > > > > _______________________________________________ > > > Haskell mailing list > > > Haskell(a)haskell.org > > > http://www.haskell.org/mailman/listinfo/haskell > > > > > -- > > Haskell mailing list > > Haskell(a)haskell.org > > http://www.haskell.org/mailman/listinfo/haskell > > > > -- > -------------------------------------------------------------- > ------------- > John Meacham - California Institute of Technology, Alum. - > john(a)foo.net > -------------------------------------------------------------- > ------------- > _______________________________________________ > Haskell mailing list > Haskell(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell >

1 0

RE: Ann: HAllInOne bug fix release
by Hal Daume 31 Jul '03

31 Jul '03

(moved to haskell cafe -- hopefully the other threads will follow) > >I don't know why the all in one version might go slower though > > Virtual memory thrashing? (Hal did say something about > needing lots of RAM.) only to compile. i haven't measured, but the resulting executable shouldn't require any more memory. it only hits about 400mbs max, though, which won't swap on my machine. - hal

1 0

Re: Ann: HAllInOne bug fix release
by Malcolm Wallace 31 Jul '03

31 Jul '03

> Normal: > real 3m14.295s > user 3m9.879s > sys 0m2.143s > > All-In-One: > real 1m11.380s > user 0m10.102s > sys 0m1.711s > Something very odd is going on. GHC does not generate programs than run > 3x faster between GHC versions. This comparison is actually between an nhc98-built program (the first one) and a ghc-built program (the second one), showing that (in this specific case) nhc98 is generating code that is three times slower than that generated by ghc. In my experience, a speed difference of between 2x and 5x of the (unoptimised) generated code between the two compilers is fairly typical. The really odd thing is in the second set of figures. Unless there has been a cut-n-paste mistake, the user+system times do not add up even close to the wall-clock time, suggesting a much greater difference of 18x, which would start to worry me a little if it were true. However, Hal posted an updated set of figures comparing a program separately compiled with ghc to all-in-one compiled with ghc, and these figures seem to have a similar same user+system /= real discrepancy: > separately compiled with ghc: > real 0m27.167s > user 0m9.991s > sys 0m1.304s > all-in-one compiled with ghc: > real 0m31.411s > user 0m10.007s > sys 0m1.299s Is this some kind of known Cygwin timing problem? Do ghc executables fiddle with the internal timers at runtime? :-) Regards, Malcolm

1 0

CSV parser, quotes?
by Shawn P. Garbett 31 Jul '03

31 Jul '03

In attempting to improve the CSV parser based on comments, I have the following code that's attached. I'm having a heck of a time getting the double quotes = an escaped quote thing to work. There is some commented out code which was my last attempt. As it stands the code works, minus the escaped quotes. Remove the comments and it just hangs. module CSV (contents, csv) where import Parsec ---------------------------------------------------------------------- -- CSV Module ---------------------------------------------------------------------- -- Useful common parsers comma :: Parser Char comma = char ',' quote :: Parser Char quote = char '\"' -- How to handle these buggers.... --esc_quote :: Parser Char --esc_quote = do {char '\"'; char '\"';} --text :: Parser String --text = do {esc_quote; t<-text; return ('\"':t)} -- <|> do {c <- noneOf "\""; t<-text; return (c:t) } -- <|> return "" -- A cell can be a quoted value, a number or empty -- Quotes can be embedded by using double quotes "" cell :: Parser String cell = between quote quote (many (noneOf "\"")) -- quoted values --cell = between quote quote text -- quoted values <|> many1 (noneOf "\",\n") -- unquoted values <|> return "" -- give up, Empty cell -- Group of cells with a newline cells :: Parser [String] cells = do c <- sepBy cell comma newline return c -- Comma Separated Values, set of rows followed by eof csv :: Parser [[String]] csv = manyTill cells eof -- Useful For extracting comma delimited values of a cell contents :: Parser [String] contents = sepBy1 (many (noneOf ",")) comma

3 2

RE: Type design question
by Hal Daume 31 Jul '03

31 Jul '03

Hi Konrad, > I am a Haskell newbie working on my first serious test case, > and I would like > some feedback from the experts to make sure I am not doing > anything stupid > ;-) Well, I may not exactly qualify, but I can give you a few suggestions, nonetheless... > data Floating a => Vector a = Vector !a !a !a > deriving (Eq, Show) Here. Do not use 'data C x =>'. It's essentially a useless part of the language that really should have gone away. What you want is just: | data Vector a = Vector !a !a !a deriving (Eq, Show) The Floating constraint can come in on the functions. (I say this feature is useless because it only does one thing: disallows you to construct Vectors whose elements aren't instances of Floating. However, the useful thing that it might do -- namely, allow you to *use* the fact that the elements are instances of Floating -- it doesn't.) > I would like to keep the numerical representation as general > as possible, in > particular to postpone decisions about precision (Float, > Double, eventually > arbitrary precision arithmetic) as much as possible. > Therefore the "Floating > a" constraint. Which leads to my first question: doing it the > way I did, I > find myself having to add a "Floating a" constraint to almost > every function > specification with a vector argument. I would prefer to > specify once and for > all that vector elements need to be "Floating", everywhere. > Is there a way of > doing that? Not really. > -- Periodic universe > data Floating a => OrthorhombicUniverse a = OrthorhombicUniverse a a a Again, get rid of the 'Floating a =>' part. > instance Floating a => Universe (OrthorhombicUniverse a) where > distanceVector (OrthorhombicUniverse a b c) > (Vector x1 y1 z1) (Vector x2 y2 z2) > = Vector (fmod (x2-x1) a) (fmod (y2-y1) b) (fmod (z2-z1) c) > where fmod x y = x - y*truncate (x/y) There are actually two problems. First, you want to write fmod as: | fmod x y = x - y * fromInteger (truncate (x/y)) otherwise the type is wrong. Secondly, since you're using truncate, you need to be in RealFrac, not in Floating. Changing the signature to: | instance RealFrac a => ... fixes this problem. However, once we fix this, we can see the real problem. Your Universe class has a method, distanceVector, of type: | distanceVector :: Universe u, Floating a => u -> Vector a -> Vector a -> Vector a And here's the problem. When 'u' is 'OrthorhombicUniverse x', it doesn't know that this 'x' is supposed to be the same as the 'a'. One way to fix this is to parameterize the Universe data type on the element, something like: class Universe u where distanceVector :: (RealFrac a, Floating a) => u a -> (Vector a) -> (Vector a) -> (Vector a) distance :: (RealFrac a, Floating a) => u a -> (Vector a) -> (Vector a) -> a distance u v1 v2 = norm (distanceVector u v1 v2) -- Infinite universe data InfiniteUniverse a = InfiniteUniverse instance Universe InfiniteUniverse where distanceVector u v1 v2 = v2 <-> v1 -- Periodic universe data OrthorhombicUniverse a = OrthorhombicUniverse a a a instance Universe OrthorhombicUniverse where distanceVector (OrthorhombicUniverse a b c) (Vector x1 y1 z1) (Vector x2 y2 z2) = Vector (fmod (x2-x1) a) (fmod (y2-y1) b) (fmod (z2-z1) c) where fmod x y = x - y*fromInteger (truncate (x/y)) This is beginning to get a little ugly, but I think that's largely because you're using type classes in too much of an OO style (this is what a lot of my first programs looked like and I think for reasons similar to this, I moved away from that). However, not knowing more about the domain of discourse, I don't know what to suggest. Perhaps using the module system would serve you better. Instead of having a universe class, simply put each universe in a separate module and provide the same functions in each. Then you just import them selectively, or qualified. HTH. - Hal

15 24

RE: Useful list output function
by Kevin S. Millikin 30 Jul '03

30 Jul '03

On Wednesday, July 30, 2003 1:52 PM, Shawn P. Garbett [SMTP:Shawn@Garbett.org] wrote: > > output :: (a -> IO b) -> [a] -> IO () > output f = (foldr (>>) (return ())).(map f) Study the Prelude :) > output :: (a -> IO b) -> [a] -> IO () > output = mapM_

1 0