February 2013 - Beginners

How to unnest "do"
by Martin Drautzburg 09 Feb '13

09 Feb '13

Hello all, in the code snippet below, is there a way to factor out the second "do"? import System (getArgs) main :: IO () main = do args <- getArgs case args of [fname] -> do fstr <- readFile fname let nWords = length . words $ fstr nLines = length . lines $ fstr nChars = length fstr putStrLn . unwords $ [ show nLines , show nWords , show nChars , fname] _ ->putStrLn "usage: wc fname"

8 13

interface/abstract class: what is the haskell way?
by Emmanuel Touzery 09 Feb '13

09 Feb '13

Hello, i wrote two programs in haskell which have the same problem: they define a common datatype (let's say Event for instance), and they have several modules, each one importing a list of Event from a specific data source. So all these modules have a similar api: getEvents :: <params> -> IO [Event] And maybe a couple extra functions, more or less the same for each module. In OO, I would make a base class, like EventProvider, with a couple abstract methods and in the main class of my app, I would have a list of EventProvider and loop over them. That way to add a new EventProvider, I would just add the import and an element in that list. Currently in haskell I duplicate the function calls for each provider. And because there is no interface constraint, each module has a slightly different API. The "obvious" way to do in haskell what I would do in OO would be through type classes. However I realize type classes are not quite interfaces. I'm wondering what would be the "haskell way" to solve this problem? For sure type classes do the job. But is it the idiomatic way of solving this problem? Thank you! Emmanuel

3 8

Mixed typeclasses
by Mateusz Neumann 08 Feb '13

08 Feb '13

Hi I came across a problem, which I deeply believe, might be solved in Haskell in much nicer way (than I did it). I have: class (Eq a) => ThatsMyProblem a where fromMyProblem :: a -> Int toMyProblem :: Int -> a data MyType1 = MyType1_1 | MyType1_2 | MyType1_3 Int deriving (Show) instance Eq MyType1 where (==) a b = fromMyProblem a == fromMyProblem b instance ThatsMyProblem MyType1 where [...] data MyType2 = MyType2_1 | MyType2_2 Int deriving (Show) instance Eq MyType2 where (==) a b = fromMyProblem a == fromMyProblem b instance ThatsMyProblem MyType2 where [...] data MyType3 = MyType3_1 | MyType3_2 | MyType3_3 Int deriving (Show) instance Eq MyType3 where (==) a b = fromMyProblem a == fromMyProblem b instance ThatsMyProblem MyType3 where [...] I would very much like to create one single instance like this: instance (FutureVal a) => Eq a where (==) x y = fromFVal x == fromFVal y but that does not seem to work, as I get an error stating “Illegal instance declaration for `Eq a' (All instance types must be of the form (T a1 ... an) where a1 ... an are *distinct type variables*, and each type variable appears at most once in the instance head. Use -XFlexibleInstances if you want to disable this.) In the instance declaration for `Eq a'” Could you please point me out my mistake and/or direct me to some documentation? -- Mateusz

2 2

How do I perform things inside a Monad?
by Martin Drautzburg 08 Feb '13

08 Feb '13

Hello all, In the ALSA Midi package, there is an example, where he first sets up client, port, queue and stuff. All of these are IO actions, and there are a number of nested "do"s. Then in the innermost "do" he has all the pieces together and starts playing. In this case the actual "song" is coded in the innermost do. My question is: how can I inject a song from outside. Of course I could make it another parameter, which would have to travel through all the "do"s, but I already have more than enough parameters. Then I tried fmap. But the actual playing is an IO operation itself, so I cannot write a pure function and fmap it over the Monad. Any ideas? -- Martin

3 3

Hackages that only depend on Haskell Platform
by Darren Grant 07 Feb '13

07 Feb '13

So after encountering the dangers associated with installing many random hackages I am on a mission to cull the herd. So to that effect: Is there a list of hackages available that *only* depend on the latest Haskell Platform? -or- Can such a list be reasonably generated? -or- Will there even be anything left after the hackages are filtered? Apologies if this is in fact already in the archives! Cheers, Darren

6 11

How to improve the accuracy of floating point calculation?
by yi lu 06 Feb '13

06 Feb '13

Hi, I found that in ghci, I input [0.1,0.2..2] and run, I get a result of [0.1,0.2,0.30000000000000004,0.4000000000000001,0.5000000000000001,0.6000000000000001,0.7000000000000001,0.8,0.9,1.0,1.1,1.2000000000000002,1.3000000000000003,1.4000000000000004,1.5000000000000004,1.6000000000000005,1.7000000000000006,1.8000000000000007,1.9000000000000008,2.000000000000001] But, as you know, it is not the exact answer. So, I wonder if there is something I can do to achieve a better performance and get [0.1,0.2,0.3,0.4..] as the result. Thanks.

9 13

Re: [Haskell-beginners] too lazy parsing?
by Daniel Fischer 04 Feb '13

04 Feb '13

On Monday 04 February 2013, 11:50:24, Kees Bleijenberg wrote: > module Main where > > import Text.ParserCombinators.Parsec (many,many1,string, Parser, parse) > import System.IO (IOMode(..),hClose,openFile,hGetContents,hPutStrLn) > > parseFile hOut fn = do > > handle <- openFile fn ReadMode > cont <- hGetContents handle hGetContents does read the file only on demand > print cont Here the contents is demanded, so the file is read. > let res = parse (many (string "blah")) "" cont The binding of res is lazy, so it's not demanded yet, without the printing, the file would still not be read. > hClose handle Now the file handle is closed, so nothing more can be read from the file. If nothing has been demanded so far, cont will be an empty string. 1. You should rather use readFile, unless you need to read a lot of files, in which case opening too many at once may exhaust the available file handles; the you need strict IO with exact control over when a file is opened, read, and closed. readFile only semi-closes the file handle, reading from the file still works until the contents goes out of scope or the end of the file is reached. Also readFile leads to simpler code, cont <- readFile fn let res = parse (many (string "blah")) "" cont case res of ... 2. if you absolutely want to use the more cumbersome hOpen - hGetContents - hClose sequence, you need to force the file contents to be read before closing the file. Instead of printing the contents, let res = ... res `seq` hClose handle would work here, generally, to ensure the entire file was read, a common way is length cont `seq` hClose handle But in those cases, it would probably make more sense to use strict IO anyway, rather than lazy IO. 3. The only reason to use hOpen - hGetContents - hClose instead of readFile is more exception-safety, in which case you should use bracket (from Control.Exception), or the wrapper around bracket withFile :: FilePath -> IOMode -> (Handle -> IO r) -> IO r > case res of > > (Left err) -> hPutStrLn hOut $ "Error: " ++ > (show err) > (Right goodRes) -> mapM_ (hPutStrLn hOut) > goodRes > > main = do > > hOut <- openFile "outp.txt" WriteMode > mapM (parseFile hOut) ["inp.txt"] > hClose hOut > > I’am writing a program that parses a lot of files. Above is the simplest > program I can think of that demonstrates my problem. The program above > parses inp.txt. Inp.txt has only the word blah in it. The output is saved > in outp.txt. This file contains the word blah after running the program. if > I comment out the line ‘print cont’ nothing is saved in outp.txt. If I > comment out ‘print cont’ and replace many with many1 in the following line, > it works again? Hmm, I get (as expected) Error: (line 1, column 1): unexpected end of input expecting "blah" with many1. When you parse an empty string with `many parser`, the parse succeeds and returns an empty list. Successively printing an empty list of strings means printing nothing at all. Using `many1` instead of `many` makes the parse fail, and then you print the error, thus `many1 (string "blah") produces some output from an empty file [and without forcing the file contents in some way before closing, the file is effectively empty]. > Can someone explain to me what is going on? > > Kees

1 0

Re: [Haskell-beginners] too lazy parsing?
by Kyle Murphy 04 Feb '13

04 Feb '13

I can't say 100% for sure, but I'd guess it's because parsec is pure, and the file operations are using lazy bytestrings. Since no IO operations are applied to cont until after you close the handle, nothing can be read (since at that time the handle is closed). If you want to keep the program structured the same I believe there are functions that can convert a lazy bytestring into a strict one, and then you can perform the parsing on that. Alternatively you could rewrite things to close the file handle after you write it's contents to the output file. The default file operations in Haskell are known to be a source of difficulty in terms of laziness, and there has been some debate as to whether they're poorly designed or not. I might suggest you look into some of the alternatives, particular those based on stream fusion principles, that allow you to kill two birds with one stone by iteratively dealing with input thereby forcing evaluation and also improving memory usage and making it harder to trigger space leaks. I don't have the names available at the moment or I'd provide them, but I'm pretty sure at least one of them is named something like enumeratee, although I believe there's at least one other that might debatably be considered better. On Feb 4, 2013 5:51 AM, "Kees Bleijenberg" <k.bleijenberg(a)lijbrandt.nl> wrote: > module Main where **** > > ** ** > > import Text.ParserCombinators.Parsec (many,many1,string, Parser, parse)*** > * > > import System.IO (IOMode(..),hClose,openFile,hGetContents,hPutStrLn)**** > > > **** > > parseFile hOut fn = do**** > > handle <- openFile fn ReadMode**** > > cont <- hGetContents > handle **** > > print cont**** > > let res = parse (many (string "blah")) "" cont**** > > hClose handle **** > > case res of**** > > (Left err) -> hPutStrLn hOut $ "Error: " ++ > (show err)**** > > (Right goodRes) -> mapM_ (hPutStrLn hOut) > goodRes **** > > **** > > main = do **** > > hOut <- openFile "outp.txt" WriteMode**** > > mapM (parseFile hOut) ["inp.txt"]**** > > hClose hOut**** > > ** ** > > I’am writing a program that parses a lot of files. Above is the simplest > program I can think of that demonstrates my problem.**** > > The program above parses inp.txt. Inp.txt has only the word blah in it. > The output is saved in outp.txt. This file contains the word blah after > running the program. if I comment out the line ‘print cont’ nothing is > saved in outp.txt. **** > > If I comment out ‘print cont’ and replace many with many1 in the following > line, it works again?**** > > Can someone explain to me what is going on?**** > > ** ** > > Kees**** > > _______________________________________________ > Beginners mailing list > Beginners(a)haskell.org > http://www.haskell.org/mailman/listinfo/beginners > >

2 2

too lazy parsing?
by Kees Bleijenberg 04 Feb '13

04 Feb '13

module Main where import Text.ParserCombinators.Parsec (many,many1,string, Parser, parse) import System.IO (IOMode(..),hClose,openFile,hGetContents,hPutStrLn) parseFile hOut fn = do handle <- openFile fn ReadMode cont <- hGetContents handle print cont let res = parse (many (string "blah")) "" cont hClose handle case res of (Left err) -> hPutStrLn hOut $ "Error: " ++ (show err) (Right goodRes) -> mapM_ (hPutStrLn hOut) goodRes main = do hOut <- openFile "outp.txt" WriteMode mapM (parseFile hOut) ["inp.txt"] hClose hOut I'am writing a program that parses a lot of files. Above is the simplest program I can think of that demonstrates my problem. The program above parses inp.txt. Inp.txt has only the word blah in it. The output is saved in outp.txt. This file contains the word blah after running the program. if I comment out the line 'print cont' nothing is saved in outp.txt. If I comment out 'print cont' and replace many with many1 in the following line, it works again? Can someone explain to me what is going on? Kees

1 0

Re: [Haskell-beginners] Parsec problem
by Daniel Fischer 03 Feb '13

03 Feb '13

On Saturday 02 February 2013, 15:00:52, Kees Bleijenberg wrote: > module Main(main) where > > import Text.ParserCombinators.Parsec > > parseToNewLine = do > line <- manyTill anyChar newline > return line > > keyValue = do > fieldName <- many letter > spaces > char '=' > spaces > fieldValue <- parseToNewLine > return (fieldName,fieldValue) > > main = parseTest keyValue "key=\n" > > I don’t understand why te code above doesn’t parse to (“key”,””) Because the newline is already consumed by the `spaces`. So parseToNewLine gets an empty string as input, and fails on that. > parseToNewLine “\n” parses to “" > > parseTest keyValue “a=b\n” works fine and parses to (“a”,”b”) The input of parseToNewLine must contain a newline, or it fails. In the last example, the `spaces` after `char '='` stops at reaching the 'b', so the newline remains. In the first (problematic) example, all the remaining input after the '=' consists of whitespace.

2 1