August 2007 - Haskell-Cafe

Newbie question: Where is StackOverflow on the Wiki?
by Peter Verswyvelen 23 Aug '07

23 Aug '07

When reading an article about tail recursion (http://themechanicalbride.blogspot.com/2007/04/haskell-for-c-3-programmers. html) I came across the follow statements: "If you can write a non-recursive function that uses the colon syntax it is probably better than a tail recursive one that doesn't. This is because Haskell's lazy evaluation enabled you to use the non-tail recursive version on an infinite stream without getting a stack overflow. " and ""Unfortunately", laziness "gets in the way". While transforming non-tail-recursive code to a tail-recursive form is important and useful for functional programming in general, dealing with laziness requires a little more care, and often "non-tail-recursive" versions are preferrable. flatten is an example of this, the first version is better in many ways. While I don't believe it happens in this case, oftentimes naively writing code "tail-recursively" in Haskell will actually -make- it overflow the stack. Another (actual) benefit of the first version of flatten is that it will work on infinite lists. http://www.haskell.org/hawiki/StackOverflow gives a simple example and some explanation." Unfortunately I can't find the StackOverflow page anymore. Now if I understand this correctly, this just means that when writing something like: foo n = if n<0 then [] else n : foo (n-1) bar n = aux 0 [] where aux i xs = if i>n then xs else aux (i+1) (i:xs) that foo is more efficient than bar because lazy evaluation of foo just puts the delayed computation in the "cdr" of the list, while lazy evaluation of bar has to keep track of all aux calls (the "closures") which gives much more overhead, maybe even stack overflow? Something like that? Thanks, Peter

9 14

Re: [Haskell-cafe] Re: Newbie question: Where is StackOverflow on the Wiki?
by Peter Verswyvelen 23 Aug '07

23 Aug '07

I think DrScheme does that for Scheme. So a must have for Haskell! Maybe could be added to the Helium project? >----- Oorspronkelijk bericht ----- >Van: apfelmus [mailto:apfelmus@quantentunnel.de] >Verzonden: donderdag, augustus 23, 2007 08:00 PM >Aan: haskell-cafe(a)haskell.org >Onderwerp: [Haskell-cafe] Re: Newbie question: Where is StackOverflow on the Wiki? > >Neil Mitchell wrote: >>>> sum (enum 1 10) => >>>> sum' 0 (enum 1 10) => >>>> ... >>>> >>>> sum' 36 (9 : enum (9+1) 10) => >>>> (sum' $! (36+9)) (enum (9+1) 10) => >>>> sum' 45 (enum (9+1) 10) => >>>> sum' 45 [] => >>>> 45 >>>> >>>> (I need to find some way to automate making these trails :) ) >>> Yes! We'd need such an automatic tool for the wikibook, too. >> >> The problem is that Haskell is ridiculously complex, and the "small >> step" interpretation is much harder than you'd think. For example, sum >> may well be defined as foldl' (+) 0, which is a CAF, so gets reduced >> once. The 0 won't actually be a 0, but will be fromInteger 0, which >> will correspond to looking up an item in the dictionary and applying >> it. Dictionaries especially make the "simple" interpretation >> completely wrong. >> >> It's easy to do informally, but once you start being more precise, its >> very complex. > >Yeah, the precise details may vary, even :) But for teaching, an >automatic tool that does graph reduction would be great. I don't mind if >it's sloppy (directly apply definitions & pattern matching VS everything >is a lambda abstraction) and only does simply typed lambda calculus (no >type applications, no type classes). > >Regards, >apfelmus > >_______________________________________________ >Haskell-Cafe mailing list >Haskell-Cafe(a)haskell.org >http://www.haskell.org/mailman/listinfo/haskell-cafe > >

1 0

help understanding lazy evaluation
by Xavier Noria 23 Aug '07

23 Aug '07

I am learning Haskell with "Programming in Haskell" (an excellent book BTW). I have background in several languages but none of them has lazy evaluation. By now I am getting along with the intuitive idea that things are not evaluated until needed, but there's an example I don't understand (which means the intuitive idea needs some revision :-). We have factors(), defined on page 39 like this[*]: factors :: Int -> [Int] factors n = [x | x <- [1..n], n `mod` x == 0] and we base prime() on it this way: prime :: Int -> Bool prime n = factors n == [1, n] Now, the books says prime does not necessarily compute all of the factors of n because of lazy evaluation. Meaning that if n is composite as soon as some non-trivial divisor appears we halt computation and return False. My vague intuition said "we either need factors or we don't, we do because we need to perform the test, so we compute it". That's wrong, so a posteriori the explanation must be something like this: 1. someone knows we want factor() to perform an equality test 2. someone knows an equality test between lists is False as soon as we have a mismatch, left to right 3. thus, instead of evaluating factors completely we are going to build sublists of the result and perform the tests on those ones against [1, n]. That's a lot of *context* about that particular evaluation of factors, in particular step puzzles me. Can anyone explain how lazy evaluation fits there? I suspect the key is the implementation of == together with the fact that list comprehensions are lazy themselves, is that right? -- fxn [*] Which notation do you use for functions in text? is f() ok?

11 11

Ann: Gtk2Hs Tutorial Port
by Hans van Thiel 23 Aug '07

23 Aug '07

Hello All, I've already announced this on the Gtk2Hs users' list, but for those who are not using Gtk2Hs at the moment, but who might be interested: I've started a port of the Gtk+2.0 tutorial by Tony Gail and Ian Main and the first part is available on: http://darcs.haskell.org/gtk2hs/docs/tutorial/Tutorial_Port/ The chapters are: Contents and Copyright Notice chap1.html Getting Started chap3.html Packing Widgets chap4.html Packing Demonstration Program chap5a.html Packing Using Tables chap5b.html The Button Widget chap6.html Adjustments, Scale and Range chap7.html All examples are also available as .hs files. For a beginner, working through these should be sufficient, so that he/she can carry on with the original C based tutorial. The correlation between the examples and the Gtk2Hs API is (mostly) straightforward. But I'm working on the other widgets in the Gtk+2.0 tutorial too (might take a while). Currently available on my own web site (but no .hs files): Labels chap8.html Arrows and Tooltips chap9.html http://j-van-thiel.speedlinq.nl/gtk2hs/chap8.html http://j-van-thiel.speedlinq.nl/gtk2hs/chap9.html New additions will be listed in chap1.html As said, probably the second part of the port is not really needed, as the Gtk2Hs API documentation maps (mostly) very clearly onto the C functions. Note 1: I'm not a Gtk2Hs expert, but I'm journaling my own learning experience. The code works, but feel free to comment. Someone has kindly promised to review this version, so it will certainly be improved later on. Note 2: the Gtk+2.0 tutorial has not been updated since 2002 (if the copyright notice is to be trusted) and does not cover everything. The same applies to the port. Moreover, advanced widgets like Tree List are large and complicated and will not be treated at all. Note 3: This tutorial, and in particular the 'Getting Started' chapter, replaces the old 'Getting Started' page, which has been removed. Many Thanks, Hans van Thiel

1 0

Tackling IO (the correct way)
by Dave Tapley 23 Aug '07

23 Aug '07

Hi again all, I could do with some design pointers for a project I'm working on combining Haskell with a robot. My situation is: I read sensor data from the robot lazily a line at a time, as soon as a line is read in my code sends out a response down a pipe. Implemented in this fashion: > mapM_ (updateFunction myIORef) fromRobot ::IO () > fromRobot :: String > updateFunction :: IORef -> String -> IO () Now I wish to update a HOpenGL window synchronously with this. To establish this I make a new HOpenGL window & return an IORef (IO ()) which holds the actions to draw my graphics. In this fashion: > myIORef <- makeWindow --- Above code --- > mainLoop This can be passed to updateFunction as shown above so every time it processes a new line from the robot is can update the graphics via the IORef. Because neither 'mapM_ (updateFunction myIORef) fromRobot' nor 'mainLoop' terminate I've been using 'forkIO' to split one off. This way the lazy evaluation keeps running and then window keeps updating itself. This works, sort of. I have problems because the my HOpenGL code also has magic to allow you to change the point of view using the keyboard. But when I do I get this after a while: LOCK SET! Previous intel_span.c:210 Current: intel_batchbuffer.c:63 Can anyone suggest how to resolve this "two functions which never terminate but both share IORefs" problem? Many thanks, Dave

4 3

Using Collections: ElemsView and KeysView
by Benjamin Franksen 22 Aug '07

22 Aug '07

Hi I am using collections-0.3 and need to perform some operations on keys resp. values of a map. In the concrete implementations there are functions like 'elems' and 'keys' but there is no such thing in Data.Collections. Instead there are the types 'ElemsView' and 'KeysView' and functions 'withElems' and 'withKeys', but I have not the slightest idea how they are supposed to be used, there is very sparse documentation and no examples. I'd be glad for any hints. Cheers Ben

2 2

Haskell vs GC'd imperative languages, threading, parallelizeability (is that a word? :-D )
by Hugh Perkins 22 Aug '07

22 Aug '07

Haskell vs GC'd imperative languages =========================== On 8/10/07, Thomas Conway <drtomc(a)gmail.com> wrote: > > > Well, C++ is not really competitive with Haskell, because C++ does not > have > > a GC, and it's trivial to corrupt the stack/heap. > > Beg to differ. I offer the following proof by contradiction. :-) > > In my current job, I had a version-1 implementation in Python which > had severe performance problems, and was not amenable to concurrency > (The Python interpreter has a global lock, so you can only execute > python bytecodes from one thread at a time. :-(). The natural > alternative implementation language was C++, but I argued successfully > that a Haskell implementation would be significantly easier to make > concurrent. > > Well, Python is comparable to Haskell to the extent that it has a GC. OTOH it is interpreted, and, well, slow. It's also got a Big Lock around the core system libraries. Trying to avoid naming it by name, because there's a lot of elitism against using mainstream languages that are used by "stupid people", but the fastest imperative GC'd language that I know of is C#. Even the opensource mono version is wickedly fast. The Microsoft version shaves another 20% off execution speed or so. See, I get the feeling that a lot of people are using Haskell not because they compared it to C# and found it better ,but because they compared it to: - C -> Haskell is easier - C++ -> Haskell is easier - Python -> Haskell is faster C# -> fast and easy ;-) Threading ======= I'm not trolling, despite strong appearances to the contrary ;-) My primary objective/goal is to find a way to make threading easy. Thread management today is like memory management in the early 90s. We kindof had tools (new, delete in C++ for example) to do it. At some point we started to use things like Smart Pointers to make it easier, but none of it really worked. Issues such as circular referential loops caused this not to work very well. At some point, someone came out with the idea of a garbage collector, which is really very simple once you know: all it does is walk the graph of variables, starting with those we know are definitely used, and delete all those objects that didnt get walked on. Simple, easy, magic. We should do the same thing for threads. Threading is going to become a major issue soon, maybe not tomorrow, but there is a GPL'd Niagara 2 out with 64 threads (I think?), so the time is now. Haskell solves a huge issue with threads, which is locking, which is a total PITA in imperative languages, it's of the same order of magnitude of problem as eliminating memory leaks, without deleting something twice etc, used to be in pre-GC C++. Nevertheless, one cannot be interested in threads without being interested in performance. There's no point in running a program in 1024 threads, if the single-core C# version runs faster than that, and often it does! Parallelizeability ============ Now, I did have kindof a shootout thread with Don and Sebastien, calculating prime numbers, where Don managed to get to within an order of magnitude of C# performance (I think he got to about 70-80% of C# performance, cool!) -> BUT, and its a big but ;-), as far as I can tell, he did that by sacrificing the Haskell ability to be easily parallelized; his solution was essentially imperative.

11 25

#haskell irc channel reaches 400 users
by dons＠cse.unsw.edu.au 22 Aug '07

22 Aug '07

A small announcement :) 5 1/2 years after its inception, under the guiding hand of Shae Erisson (aka shapr), the #haskell IRC channel[1] on freenode has finally reached 400 users! To chart the growth, we can note that the channel was founded in late 2001, and had slow growth till 2006, reaching 200 users in January of that year. Since then growth in the user base has been far more rapid, reaching 300 users in Dec 2006, and 400 users now, in August 2007. This puts the channel at around the 13th largest community of the 5500 freenode channels. For comparision, a sample of the state of the other language communities: #php 485 #perl 472 ##c++ 457 ##c 445 #python 430 #ruby-lang 420 > #haskell 411 #lisp 246 ##java 236 ##javascript 226 #perl6 144 #scheme 139 #erlang 118 #lua 105 #ocaml 58 You can see the growth of the channel over here: http://www.cse.unsw.edu.au/~dons/irc If you've not dropped by the channel yet, feel free to come and chat, and toss around some lambdas! :) Cheers, Don 1. http://www.haskell.org/haskellwiki/IRC_channel

5 4

-f flag to runghc broken, or is it just me? (because trying switch elegantly between ghc 6.6 and ghc 6.7)
by Thomas Hartman 22 Aug '07

22 Aug '07

I'm doing a lot of switching between ghc 6.6 and ghc 6.7 on the same computer. I install modules using $ runghc Setup.hs configure etc. I would like to specify which version of ghc should be getting the package installed via the f flag to runghc $ :~/personal/PersonalRepos/pharchive/learning/haskell/UnixTools/arghandling>runghc runghc: syntax: runghc [-f GHCPATH] [GHC-ARGS] FILE ARG... but this appears to be broken. $ :~/personal/PersonalRepos/pharchive/learning/haskell/UnixTools/arghandling>runghc arghandling-nice.hs arghandling-nice.hs: args length does not equal 3. args: : [] usage example: $ runghc arghandling-nice.hs firstarg secondarg thirdarg without the flag works but $ :~/personal/PersonalRepos/pharchive/learning/haskell/UnixTools/arghandling>runghc -f /usr/local/bin/ghc-6.6.1 arghandling-nice.hs does nothing. $ :~/personal/PersonalRepos/pharchive/learning/haskell/UnixTools/arghandling>ls -l /usr/local/bin/ghc-6.6.1 -rwxr-xr-x 1 root root 151 2007-06-16 20:22 /usr/local/bin/ghc-6.6.1 In general I don't like using runghc because it doesn't appear to be documented anywhere except that (incorrect?) usage message. Is there a way to do a package install just using ghc -e? (Sure I could compile, but it helps me sometimes if I can not, a la runghc.) At any rate I couldn't figure out how to pass arguments to main via ghc -e. $ :~/personal/PersonalRepos/pharchive/learning/haskell/UnixTools/arghandling>cat arghandling-nice.hs import System main = do args <- getArgs let usagemsg = "usage example: $ runghc arghandling-nice.hs firstarg secondarg thirdarg" case args of [first,second,third] -> process first second third _ -> error $ "args length does not equal 3. args: : " ++ ( show args ) ++ "\n" ++ usagemsg process a b c = print $ unwords [a,b,c] Thanks for anybody who can help me out with this. Thomas. --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

3 3

Parsing binary data.
by Peter Cai 22 Aug '07

22 Aug '07

Hi all, Recently I am considering doing part of my job using Haskell. My duty is writing a network server which talks to another server through a binary based private protocol. As the old version of this component is written in C, it's very natural that this protocol is base on C structure definitions, which are, unfortunately, very complicated. And the worse is that every field in every structure must be converted to Network Endian. As I am a newbie to Haskell, I am not sure how to handle this problem with less work. Do you have any ideas about this problem? Thanks in advance! -- There is No CODE That is More Flexible Than NO Code!

8 12