November 2012 - Beginners

exceptions and stacks
by Emmanuel Touzery 06 Nov '12

06 Nov '12

Hello, I'm getting really frustrated by error handling in haskell. By this I mean "assert"-like errors. Which means, something that should never happen, happens. This will happen in the development and deployment of software of any size. When coding the feature you'll say, I don't need to handle the "Nothing" case, because it will never happen, or almost never, and this is not critical production software. But if one day it happens you find yourself with a several thousand lines program and all you have to debug is the input data (most of the time anyway, sometimes not even that) and this error message (for instance): *** Exception: Prelude.head: empty list And you don't know even, did you call "head" or maybe a library you are using called it. This is really poor compared to what Java, python and others offers. I can understand that it's difficult to provide a stack trace, especially with lazy evaluation, but at least the function name and maybe a line number... Actually I don't know why it would be so difficult to also give me the values of the parameters of the function... using print and if it's a pure function it intuitively doesn't seem difficult. I've tried ghci with :trace and ":set -fbreak-on-exception" and I got nowhere. It breaks in things which are not important (I have no idea where it breaks, it claims an exception was thrown, maybe but not in my code and it never reaches my code for sure). After hitting ":continue" many times, I get to my exception and there I didn't manage to get useful information (:hist never printed me anything). But I would like not to have to use ghci at all. And to avoid having to write all over the place in my code these "else" and case situations for things I assume are impossible (these are cases I would not write in other modern languages). This is a feature for which I would be ready to pay a 50% speed penalty and 50% memory use penalty. I understand if it's the haskell way of writing all those else clauses... But I think in that case it really makes it compare negatively to other languages. It would be a real minus in my opinion (including to code readability). I have read (quickly) those but didn't find the solution there: http://www.haskell.org/ghc/docs/7.0.1/html/users_guide/ghci-debugger.html http://book.realworldhaskell.org/read/error-handling.html Any advice will be welcome! I really hope I missed something. Emmanuel

3 7

Re: [Haskell-beginners] Beginners Digest, Vol 53, Issue 7
by Patrick Lynch 06 Nov '12

06 Nov '12

Can anyone recommend a way of using Haskell on the web? ----- Original Message ----- From: <beginners-request(a)haskell.org> To: <beginners(a)haskell.org> Sent: Monday, November 05, 2012 4:27 PM Subject: Beginners Digest, Vol 53, Issue 7 > Send Beginners mailing list submissions to > beginners(a)haskell.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.haskell.org/mailman/listinfo/beginners > or, via email, send a message with subject or body 'help' to > beginners-request(a)haskell.org > > You can reach the person managing the list at > beginners-owner(a)haskell.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Beginners digest..." > > > Today's Topics: > > 1. Double usage of a wire (arrow) (Nathan H?sken) > 2. Trying to write netwire combiner similar to multicast > (Nathan H?sken) > 3. Re: Double usage of a wire (arrow) (Ertugrul S?ylemez) > 4. Re: Trying to write netwire combiner similar to multicast > (Ertugrul S?ylemez) > 5. Re: Trying to write netwire combiner similar to multicast > (Nathan H?sken) > 6. Missing termination rule for recursive function (Oscar Benjamin) > 7. Re: Missing termination rule for recursive function > (Daniel Fischer) > 8. Re: Missing termination rule for recursive function > (Jay Sulzberger) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 05 Nov 2012 15:12:00 +0100 > From: Nathan H?sken <nathan.huesken(a)posteo.de> > Subject: [Haskell-beginners] Double usage of a wire (arrow) > To: beginners(a)haskell.org > Message-ID: <5097C930.605(a)posteo.de> > Content-Type: text/plain; charset=ISO-8859-1 > > Hey, > > If I double use an arrow (in this example a wire from netwire) like this: > > objectWire :: WireP [Collision] Object > objectWire = (Object <$> integral_ initPos) . speedWire <*> speedWire > > will it be double evaluated, or can the compiler optimize this to > evaluate speedWire only once? > > Thanks! > Nathan > > > > ------------------------------ > > Message: 2 > Date: Mon, 05 Nov 2012 17:04:51 +0100 > From: Nathan H?sken <nathan.huesken(a)posteo.de> > Subject: [Haskell-beginners] Trying to write netwire combiner similar > to multicast > To: beginners(a)haskell.org > Message-ID: <5097E3A3.5060208(a)posteo.de> > Content-Type: text/plain; charset=ISO-8859-1 > > Hey, > > I am trying to write a netwire combiner similar to multicast. The only > difference is that when one of the wires inihibts, I want to remove it > from the list. > > So this is my attempt: > > manager :: (Monad m) => [Wire e m a b] -> Wire e m [a] [b] > manager ws' = mkGen $ \dt xs' -> do > res <- mapM (\(w,x) -> stepWire w dt x) $ zip ws' xs' > let filt (Left a, b) = Just (a, b) > filt _ = Nothing > resx = mapMaybe filt res > return (Left $ (fmap fst) resx,manager (fmap snd resx)) > > ghc gives this compiler error: > > BreakoutImproved.hs:90:62: > Couldn't match type `e' with `[e]' > `e' is a rigid type variable bound by > the type signature for > manager :: Monad m => [Wire e m a b] -> Wire e m [a] [b] > at BreakoutImproved.hs:85:1 > Expected type: [(e, Wire [e] m a b)] > Actual type: [(e, Wire e m a b)] > In the second argument of `fmap', namely `resx' > In the first argument of `manager', namely `(fmap snd resx)' > > Now this, I do not get. > Why does manager expect an argument of type [(e, Wire [e] m a b)]. > The type signature clearly says [(e, Wire e m a b)] (which is what it is > getting). > > Thanks! > Nathan > > > > ------------------------------ > > Message: 3 > Date: Mon, 5 Nov 2012 17:22:48 +0100 > From: Ertugrul S?ylemez <es(a)ertes.de> > Subject: Re: [Haskell-beginners] Double usage of a wire (arrow) > To: beginners(a)haskell.org > Message-ID: <20121105172248.11ea27da(a)tritium.streitmacht.eu> > Content-Type: text/plain; charset="utf-8" > > Nathan H?sken <nathan.huesken(a)posteo.de> wrote: > >> If I double use an arrow (in this example a wire from netwire) like >> this: >> >> objectWire :: WireP [Collision] Object >> objectWire = (Object <$> integral_ initPos) . speedWire <*> speedWire >> >> will it be double evaluated, or can the compiler optimize this to >> evaluate speedWire only once? > > It will be double-evaluated. To prevent this you can use the Arrow > interface: > > proc x' -> do > x <- speedWire -< x' > {- ... use x ... -} > > However, in WireP it's guaranteed that you get the same result, so for > code conciseness you can still have speedWire twice, if sacrificing some > speed is not too big an issue. > > > Greets, > Ertugrul > > -- > Not to be or to be and (not to be or to be and (not to be or to be and > (not to be or to be and ... that is the list monad. >

1 0

Trying to write netwire combiner similar to multicast
by Nathan Hüsken 06 Nov '12

06 Nov '12

Hey, I am trying to write a netwire combiner similar to multicast. The only difference is that when one of the wires inihibts, I want to remove it from the list. So this is my attempt: manager :: (Monad m) => [Wire e m a b] -> Wire e m [a] [b] manager ws' = mkGen $ \dt xs' -> do res <- mapM (\(w,x) -> stepWire w dt x) $ zip ws' xs' let filt (Left a, b) = Just (a, b) filt _ = Nothing resx = mapMaybe filt res return (Left $ (fmap fst) resx,manager (fmap snd resx)) ghc gives this compiler error: BreakoutImproved.hs:90:62: Couldn't match type `e' with `[e]' `e' is a rigid type variable bound by the type signature for manager :: Monad m => [Wire e m a b] -> Wire e m [a] [b] at BreakoutImproved.hs:85:1 Expected type: [(e, Wire [e] m a b)] Actual type: [(e, Wire e m a b)] In the second argument of `fmap', namely `resx' In the first argument of `manager', namely `(fmap snd resx)' Now this, I do not get. Why does manager expect an argument of type [(e, Wire [e] m a b)]. The type signature clearly says [(e, Wire e m a b)] (which is what it is getting). Thanks! Nathan

2 5

Pattern guard inside function
by Nathan Hüsken 06 Nov '12

06 Nov '12

Hey I have a function which originaly locked like this: collInfo :: Rect -> Rect -> Maybe CollInfo collInfo (Rect x1 y1 w1 h1) (Rect x2 y2 w2 h2) | x1 + w1 < x2 = Nothing | x1 > x2 + w2 = Nothing | y1 + h1 < y2 = Nothing | y1 > y2 + h2 = Nothing | otherwiese = Just $ makeCollInfo r1 r2 Now I want to refactor it to take Maybe input values collInfo' :: Maybe Rect -> Maybe Rect -> Maybe CollInfo collInfo' mr1 mr2 = r1 <- mr1 r2 <- mr2 collInfo r1 r2 This is fine, but I would like to write it using only one function. Is there any possibility I can remove collInfo and merge its body into collInfo' and still somehow use the guards (and not a bunch of ifs)? Thanks, Nathan

4 4

Missing termination rule for recursive function
by Oscar Benjamin 05 Nov '12

05 Nov '12

Hi all, I'm new to this list and I'm in the very early stages of learning Haskell but I am confident with Python and some other languages. Seeing the connection between Haskell's lists and Python's generators I tried to reimplement a generator-based Python program in Haskell. I now have it working but I was hoping that someone could help me resolve a few queries. The Python program used itertools.permutations which is an iterator that yields all permutations of a sequence. Does Haskell have a similar function in it's standard library? I found a suggestion [1] for implementing a permutations function: -- Select each item and remainder from a sequence selections :: [a] -> [(a, [a])] selections [] = [] selections (x:xs) = (x,xs) : [ (y,x:ys) | (y,ys) <- selections xs ] -- Permutations of a sequence permutations :: [a] -> [[a]] permutations xs = [ y:zs | (y,ys) <- selections xs, zs <- permutations ys ] After a while I established that this permutations function seemed to be returning an empty list. Looking at it I thought that it might be missing a termination condition so I added permutations [] = [] but the result was unchanged. When I changed it to permutations [] = [[]] I got the desired result. I can understand why this termination condition is needed to make the function recurse properly. What's confusing me though is why neither of the first two raised any kind of error at compile- or run-time. I would understand if an infinite loop had occurred (a common result for non-terminating recursion) but as far as I can tell it just returned an empty list. Can anyone explain to me how the function terminates in the three different cases? Also what is a good way of debugging this kind of problem? I found it quite difficult to establish that permutations was returning an empty list (in context there were other functions that could have been failing). Thanks in advance, Oscar [1] http://www.haskell.org/pipermail/haskell-cafe/2002-June/003122.html

3 5

cascade of if statements
by Emmanuel Touzery 05 Nov '12

05 Nov '12

Hello, I am wondering if this code can be made a bit nicer? I am checking if a file exists... and then if it exists I'm checking whether it's older than two hours from now. It is a bit annoying to have that second block in the else (i could make a second function but i think it all belongs in this function). This structure makes me think about the Maybe monad, where it would automatically exit after it would find out that the file doesn't exists, instead of having a cascade of if statements inside one another. But this function is already in the IO monad (maybe I'm thinking about this in the wrong way though). Any idea for an improvement? -- don't re-fetch if I fetched in the last 2 hours needToFetchAgain :: FilePath -> IO Bool needToFetchAgain export_filename = do exists <- doesFileExist export_filename if (not exists) then return False else do modif <- getModificationTime export_filename curTime <- getClockTime let diff = diffClockTimes curTime modif return $ tdSec diff >= (3600*2) -- 2 hours Thank you! Emmanuel

6 12

Double usage of a wire (arrow)
by Nathan Hüsken 05 Nov '12

05 Nov '12

Hey, If I double use an arrow (in this example a wire from netwire) like this: objectWire :: WireP [Collision] Object objectWire = (Object <$> integral_ initPos) . speedWire <*> speedWire will it be double evaluated, or can the compiler optimize this to evaluate speedWire only once? Thanks! Nathan

2 1

netwire, <<loop>> with accum1
by Nathan Hüsken 04 Nov '12

04 Nov '12

Hey, I have another <<loop>> with netwire. This is the minimal example I got it down to: {-# LANGUAGE Arrows #-} import Control.Wire mainWire :: WireP () Double mainWire = proc _ -> do rec out <- accum1 (+) 0 -< oldOut oldOut <- delay 0 -< out returnA -< out main = wireLoop mainWire wireLoop :: WireP () Double -> IO () wireLoop w' = do let (mx, w) = stepWireP w' 1.0 () putStrLn $ show mx wireLoop w Output: <<loop>> I am aware, in this context I could just use accum. I triggered the error where I changed integral_ and accum1. By the way, is it apropriate, that I always write these "netwire bug reports" over this list? Regards, Nathan

2 1

Excellent illustration of using the Haskell types -- revising Richard Bird's floor function so that it works properly
by Costello, Roger L. 04 Nov '12

04 Nov '12

Hi Folks, On page 82 of the book "Introduction to Functional Programming using Haskell" the author Richard Bird provides this sample implementation of the floor function: floor x = searchFrom 0 where searchFrom = decrease . upper . lower lower = until (<=x) decrease upper = until (>x) increase decrease n = n - 1 increase n = n + 1 The problem with that implementation is that it does not return an Integer value; rather, it returns a decimal (Double) value. Here's an example: floor (-3.4) -- returns (-4.0) That is wrong. The specification for floor says that it "maps a value of type Float to a value of type Integer." Clearly it is not producing an Integer result. I will now explain how to revise floor so that it returns an Integer value. In the process we will see an excellent illustration of the Haskell types. The heart of the problem is with the until function. Here is how Richard Bird implements it: until :: (a -> Bool) -> (a -> a) -> a -> a until p f y = if p y then y else until p f (f y) It takes three arguments, p, f, and y. Look at the signature of that function. The type of the third argument, y, dictates the type of the other arguments and the type of the result--whatever type y is, the other arguments must be the same type and the result must be the same type. Function until is first invoked by function lower: lower = until (<=x) decrease 0 Here are the three arguments provided to function until: (1) p is the partial function (<=x), where x is the input to the floor function. Suppose x is this value: x = (-3.4) (2) f is the function decrease (3) y is 0 Now you may argue, "Hey, the third argument, y, is 0 and that's an Integer, so clearly the result of function until will be an Integer." However, that is not correct. The type of 0 is ambiguous, it could be an Integer or it could be a Double. This ambiguity can be seen by checking its type using WinGHCi: :type 0 0 :: Num a => a The class Num is high up in Haskell's type hierarchy and it represents any number (Integer, Double, etc.). Thus, we cannot determine the type of function until's result just by examining its third argument. The other arguments will determine whether the 0 is an Integer or a Double. Let's examine the first argument: p is the partial function (<=x), where x = (-3.4) p compares "some value" against (-3.4). Let's check the type of (-3.4) using WinGHCi: :type (-3.4) (-3.4) :: Fractional a => a The datatype Double falls within the class Fractional. So p compares "some value" against a Double. Fundamental rule of Haskell: you cannot compare an Integer against a Double, you can only compare a Double against a Double. Recall that p compares "some value" against (-3.4). What is that "some value"? If we examine the body of function until we see that it is the third argument, y, and we know that y = 0. Ah, now we know how Haskell will treat 0: since the 0 is being compared against a Double value Haskell will treat the 0 as a Double. Okay, now that we know the type of y we can plug it into the type signature for function until: until :: (a -> Bool) -> (a -> a) -> Double -> a All a's must be of the same type, so the other a's must also be Double: until :: (Double -> Bool) -> (Double -> Double) -> Double -> Double Therefore function until will return a Double value. For example: until (<=x) decrease 0 -- returns (0.0) The output of function until is assigned to function lower: lower = until (<=x) decrease So the result of function lower is a Double value. The output of lower is then input to upper and the Double datatype propagates through the entire chain of composed functions: decrease . upper . lower The result of function floor is therefore a Double value. Okay, so how do we get floor to return an Integer value? The key is to prevent p in function until from casting the type of y to a Double. Recall function lower: lower = until (<=x) decrease 0 Notice that p is this partial function: (<=x) We must modify p to express, "Hey, compare x against an Integer value that has been cast to a Double value." That is implemented using a Lambda (anonymous) function: (\a -> (realToFrac a) <= x) Read that as: For whatever value, a, is provided convert it to a Fractional (Double) value and then compare it to x. Wow! So we are telling Haskell that the 0 is not to be treated as a Fractional (Double) value, it is to be treated as a Real (Integer) value. At last, we can implement function floor and it will return the desired Integer result: floor x = searchFrom 0 where searchFrom = decrease . upper . lower lower = until (\a -> (realToFrac a) <= x) decrease upper = until (\a -> (realToFrac a) > x) increase decrease n = n - 1 increase n = n + 1 Notice that wherever function until is called (in lower and upper), the first argument, p, is a Lambda (anonymous) function that takes its argument, a, and casts it from a Real (Integer) value to a Fractional (Double) value. Here are a couple examples of using this revised floor function: floor (-3.4) -- returns (-4) floor 3.4 -- returns 3 Notice that floor now returns an Integer value, which is what we want. Here is the signature for floor: floor :: (Fractional a, Ord a, Real c) => a -> c Read as: Invoke function floor with a Fractional (Double) value and it will return a Real (Integer) value. On page 83 Richard Bird shows a second version of function floor that uses a binary search: floor x = searchFrom (-1, 1) where searchFrom = fst . middle . cross(lower, upper) lower = until (<= x) double upper = until (> x) double middle = until done improve done (m, n) = (m + 1 == n) improve (m, n) = if p <= x then (p, n) else (m, p) where p = (m + n) div 2 That has multiple problems. First, it is syntactically not a well-formed Haskell program because the div operator (on the last line) must have back ticks ( ` ) surrounding it: where p = (m + n) `div` 2 Second, the functions lower and upper invoke function until. The first argument to until must be a Lambda function as described above: lower = until (\m -> (realToFrac m) <= x) double upper = until (\n -> (realToFrac n) > x) double Third, the function improve compares p (an Integer) against x (a Double), so p must be cast to a Fractional (Double) value: improve (m, n) = if (realToFrac p) <= x then (p, n) else (m, p) where p = (m + n) div 2 With those three changes the function works as desired: floor x = searchFrom (-1, 1) where searchFrom = fst . middle . cross(lower, upper) lower = until (\m -> (realToFrac m) <= x) double upper = until (\n -> (realToFrac n) > x) double middle = until done improve done (m, n) = (m + 1 == n) improve (m, n) = if (realToFrac p) <= x then (p, n) else (m, p) where p = (m + n) `div` 2 Here are a couple examples of using the revised floor function: floor (-3.4) -- returns (-4) floor 3.4 -- returns 3 Notice that floor now returns an Integer value, which is what we want. Here is the signature for floor: floor :: (Fractional a, Ord a, Real c) => a -> c Read as: Invoke function floor with a Fractional (Double) value and it will return a Real (Integer) value. /Roger

4 4

netwire accum delayed by one
by Nathan Hüsken 04 Nov '12

04 Nov '12

Hey, With this netwire based program: {-# LANGUAGE Arrows #-} import Control.Wire import Data.List mainWire :: WireP () Double mainWire = proc _ -> do accum (+) 0 -< 1 main = do wireLoop mainWire wireLoop :: WireP () Double -> IO () wireLoop w' = do let (mx, w) = stepWireP w' 1.0 () case mx of Left x -> putStrLn $ show mx Right x -> putStrLn $ show mx wireLoop w I get (output): Right 0.0 Right 1.0 Right 2.0 ... Should the output not start with 1.0 (and not 0.0)? The accum should be applied already in the first invocation, should it not? Regards, Nathan

2 5