February 2009 - Beginners

Appending to a list
by Francesco Bochicchio 09 Feb '09

09 Feb '09

Hi all, in my haskell exercises I often build list by appending values at the end. But I read somewhere that in haskell this is inefficient since there is no 'pointer to the tail of the list'. I've also seen some example of recursive functions which build the list tail-first and then in the base case of the recursion returns the reverse of the accumulated results, counting on the fact that in haskell 'reverse list' just means 'consume the list from the tail'. Just out of curiosity (I have no need to speed up my little programs with which I try to teach myself some haskell): is this a consolidated pattern? And are append really expensive? Ciao ------- FB

4 5

Installing packages
by Tymur Porkuian 08 Feb '09

08 Feb '09

I'm trying to install wxcore-0.11.0 using Cabal. I've downloaded it from http://hackage.haskell.org/cgi-bin/hackage-scripts/package/wxcore-0.11.0, unpacked and tried to follow instructions from http://haskell.org/haskellwiki/Cabal/How_to_install_a_Cabal_package, but this is what I'm getting: D:\libraries\wxcore-0.11.0>runhaskell Setup configure Setup: sh: runGenProcess: does not exist (No such file or directory) What does this mean?

3 5

Re: [Haskell-cafe] Re: [Haskell-beginners] Just how unsafe is unsafe
by Roel van Dijk 06 Feb '09

06 Feb '09

On Fri, Feb 6, 2009 at 5:22 PM, Alberto G. Corona <agocorona(a)gmail.com> wrote: > then Data.List.head Data.Maybe.fromMaybe etc are also unsafe?. Yes, I consider them unsafe. Whenever I see those functions I know that I have to look elsewhere to see if their preconditions hold. I would have preferred that listToMaybe was called head and the existing head called unsafeHead, partialHead or something else of that nature. > unsafe does > not mean "with possible errors". unsafeXXX convert something in the IO monad > into something that is not. So it can potentially contaminate your pure > code. > But Data.List.head applied to a empty list will interrupt the computation > abruptly, so your code using head will either run side effect free or not > run at all. I guess what unsafe should mean is a matter of taste. Personally I find correctness more important that pureness. An unsafe function will crash your program if evaluated when its preconditions do not hold. Whether that is because of impurity (segmentation fault?), a partial pattern match or a direct error "bla" is not that important. It might be important when determining why your program crashed, but the result is still the same. The ByteString library has a module called Data.ByteString.Unsafe with plenty of unsafeXXX functions. The comment for unsafeHead for example states: "A variety of head for non-empty ByteStrings. unsafeHead omits the check for the empty case, so there is an obligation on the programmer to provide a proof that the ByteString is non-empty." That perfectly reflects my own philosophy on this issue.

1 0

Parsing a file with data divided into sections
by Patrick LeBoutillier 06 Feb '09

06 Feb '09

Hi all, I wanted to parse a file that looks like this: MONDAY JOHN JIM LINDA TUESDAY BILL BOB WEDNESDAY THURSDAY SAM TODD LARRY LUKE FRIDAY TED in order to count the number of people for each day. After a (very) long time and a lot of trial and error, I managed to do it with this program: import Char (isSpace) main = interact (unlines . countSections . lines) where countSections = map (show) . snd . foldr compileSections (0, []) compileSections line (n, acc) = if isSection line then (0, (line, n) : acc) else (n + 1, acc) isSection line = not . isSpace . head $ line which outputs: ("MONDAY",3) ("TUESDAY",2) ("WEDNESDAY",0) ("THURSDAY",4) ("FRIDAY",1) I had quite a hard time figuring out how to keep count of the number of records in each sections. Is there a more obvious way to handle these types of problems? Are there some builtins that could of made it easier? In Perl I would probably have used a hash and a variable to keep count of the current day, incrementing the hash value for each person until I got to the next day, but it's not obvious to me how to transpose this technique to functional programming. Thanks a lot, Patrick -- ===================== Patrick LeBoutillier Rosemère, Québec, Canada

5 10

Just how unsafe is unsafe
by Andrew Wagner 06 Feb '09

06 Feb '09

So we all know the age-old rule of thumb, that unsafeXXX is simply evil and anybody that uses it should be shot (except when it's ok). I understand that unsafeXXX allows impurity, which defiles our ability to reason logically about haskell programs like we would like to. My question is, to what extent is this true? Suppose we had a module, UnsafeRandoms, which had a function that would allow you to generate a different random number every time you call it. The semantics are relatively well-defined, impurity is safely sectioned off in its own impure module, which is clearly labeled as such. How much damage does this do? Can we push the lines elsewhere? Is sectioning unsafeXXX into Unsafe modules a useful idiom that we can use for other things as well?

12 15

linked lists
by Matthew J. Williams 03 Feb '09

03 Feb '09

Dear All What would be the haskell equivalent of the C++ linked list complete with nodes? the list structure -- x:[} -- is the closest I've found. Sincerely Matthew J. Williams

2 1