June 2006 - Haskell - Haskell.org

Announcing Djinn, version 2004-12-11, a coding wizard
by Lennart Augustsson 07 Apr '11

07 Apr '11

Howdy, y'all! I've written a small program that takes a (Haskell) type and gives you back a function of that type if one exists. It's kind of fun, so I thought I'd share it. It's probably best explained with a sample session. calvin% djinn Welcome to Djinn version 2005-12-11. Type :h to get help. # Djinn is interactive if not given any arguments. # Let's see if it can find the identity function. Djinn> f ? a->a f :: a -> a f x1 = x1 # Yes, that was easy. Let's try some tuple munging. Djinn> sel ? ((a,b),(c,d)) -> (b,c) sel :: ((a, b), (c, d)) -> (b, c) sel ((_, v5), (v6, _)) = (v5, v6) # We can ask for the impossible, but then we get what we # deserve. Djinn> cast ? a->b -- cast cannot be realized. # OK, let's be bold and try some functions that are tricky to write: # return, bind, and callCC in the continuation monad Djinn> type C a = (a -> r) -> r Djinn> returnC ? a -> C a returnC :: a -> C a returnC x1 x2 = x2 x1 Djinn> bindC ? C a -> (a -> C b) -> C b bindC :: C a -> (a -> C b) -> C b bindC x1 x2 x3 = x1 (\ c15 -> x2 c15 (\ c17 -> x3 c17)) Djinn> callCC ? ((a -> C b) -> C a) -> C a callCC :: ((a -> C b) -> C a) -> C a callCC x1 x2 = x1 (\ c15 _ -> x2 c15) (\ c11 -> x2 c11) # Well, poor Djinn has a sweaty brow after deducing the code # for callCC so we had better quit. Djinn> :q Bye. To play with Djinn do a darcs get http://darcs.augustsson.net/Darcs/Djinn or get http://darcs.augustsson.net/Darcs/Djinn/Djinn.tar.gz Then just type make. (You need a Haskell 98 implementation and some libraries.) And then start djinn. For the curious, Djinn uses a decision procedure for intuitionistic propositional calculus due to Roy Dyckhoff. It's a variation of Gentzen's LJ system. This means that (in theory) Djinn will always find a function if one exists, and if one doesn't exist Djinn will terminate telling you so. This is the very first version, so expect bugs. :) Share and enjoy. -- Lennart

8 13

Haskell-mode 2.0
by Stefan Monnier 02 Feb '09

02 Feb '09

I have recently taken over maintainership of Haskell-mode, and after making a bunch of changes, I figured it would be a good idea to make a new release. You can find this new release at: http://www-perso.iro.umontreal.ca/~monnier/elisp/ If you think it should also be found at http://www.haskell.org/haskell-mode/, then please tell John Peterson to get back to me (my email to him seem to go straight to the bitbucket. John?). This release has several changes that have all been only lightly tested, especially w.r.t compatibility with various Emacsen. See appended the NEWS file that describes some of the notewirthy changes. Stefan Changes since 1.45: * keybindings C-c <char> have been replaced by C-c C-<char> so as not to collide with minor modes. * The following modules are now automatically activated without having to add anything to haskell-mode-hook: haskell-font-lock (just turn on global-font-lock-mode). haskell-decl-scan (just bind `imenu' to some key). * In recent Emacsen, haskell-doc hooks into eldoc-mode. * haskell-hugs and haskell-ghci are superceded by inf-haskell. * Indentation rules have been improved when using layout inside parens/braces. * Symbols like -> and \ can be displayed as actual arrows and lambdas. See haskell-font-lock-symbols. * Tweaks to the font-lock settings. Among other things paren-matching with things like \(x,y) should work correctly now. * New maintainer <monnier(a)gnu.org>.

3 6

Compilation of big, computed tables
by Stefan Karrmann 24 Oct '06

24 Oct '06

Dear all, can ghc compile huge tables into efficient code if they are constant at compile time? Two examples may clearify the question: big1 :: UArray Int Char big1 = array (0,1000) $! map (\i -> (i,toEnum i)) [0..1000] big2 = sum [0..10000]::Int -- == 50005000 == n*(n+1)/2 where n = 10000 Both values are constant at compile time. As they are given by pure functions, the compiler could evaluate them and write the *result* into the object file 'foo.o'. This would save code size and run time. I peeked into 'foo.hc' but I didn't found 0x2fb0408 nor an array {0, 1, 2, 3, ..., 1000} or similar things. The function in big2 should show that the computation of the value could be very time consuming. If the compiler does not compute it, the source file could be generated by a helper program (or template Haskell?). The function in big1 should show that the conversion of the data into an array could be run-time, code-size and heap-size consuming. (You need the list (maybe explicitly - think of 1000 fixed pseudo-random numbers) and convert it into an array.) If the compiler generates the unboxed array directly it could be rather efficient. PS: I compiled with: ghc6 -c -O2 -keep-tmp-files -keep-hc-files foo.hs Regards, -- Stefan Karrmann

9 12

"strange" behavior of Implicit Parameters
by Eike Scholz 08 Aug '06

08 Aug '06

Hi, I have just a short question, about the semantics of Implicit parameters on GHC 6.4. Given the following code: > (???) x f > = let ?foo = 1337 > in f x > fun :: (?foo::Int,Show x) => x -> String > fun x = "x = "++(show x)++"; ?foo = "++(show ?foo) > test = let ?foo = 23 > in 42 ??? fun I would expect: test == "x = 42; ?foo = 1337" Because I thought, that it gets reduced like: let ?foo = 23 in 42 ??? fun ~> let ?foo = 23 in (let ?foo = 1337 in fun 42) ~> ... ~> "x = 42; ?foo = 1337" however I get "x = 42; ?foo = 23" in ghci. Is there a special reason, why the implicit parameter is reduced first? Could it be a bug? Reducing it my way would be very useful for combinator-libraries, since it could be used passing around state info, or simple debug text, that tells where a Runtime-error occured? an odd example: > undef = error ?errstr > (<?>) x s = let ?errstr = ?errstr++"\n"++s in x -- annotate error tags so error annotations will accumulate and it would be easy to resolve runtime errors. best regards Eike Scholz

14 38

ANN: HDBC 1.0
by John Goerzen 03 Jul '06

03 Jul '06

Well, the latest HDBC has been stable for quite awhile. I've used it in a number of projects, and I know several others have as well. I've made some minor tweaks to the cabal files to work with GHC 6.4.2, and released it as 1.0.0. Have fun. http://quux.org/devel/hdbc -- John -- John Goerzen Author, Foundations of Python Network Programming http://www.amazon.com/exec/obidos/tg/detail/-/1590593715

2 1

Comments from Brent Fulgham on Haskell and the shootout
by Simon Marlow 02 Jul '06

02 Jul '06

Brent Fulgham has given me permission to share this message that he sent to us about his views on Haskell and the Great Computer Language Shootout. There's some nice advocacy material in here. I'd like to publicly thank Brent for all his work on the shootout - benchmarking 50 or so different language implementations and getting any kind of useful results at all is a significant feat. The shootout results have also influenced our direction in the Haskell community and GHC in particular. Here's the message, for your enjoyment... -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear Drs. Hudak and Peyton-Jones: (Feel free to forward these comments to anyone you think would enjoy them). A couple of years ago I revived the dormant "Great Computer Language Shootout" website because I wanted to create an up-to-date comparison of language implementations to use as ammunition against my nay- saying coworkers over the state of the art in Computer Science. Back in those days, I was mainly interested in the performance of Objective Caml and Lisp, but was also interested in a new (to me) language called Haskell . Haskell had (and still has) a beautiful, mathematical notation that was very easy to read, but it was such a poor performer that I despaired of ever getting to use it for anything but simple test programs. While it was conceptually satisfying, pragmatism seemed destined to keep it on the shelf for the foreseeable future. I wanted to write to inform you how shocked I was to see the great advances in performance in the Glorious Haskell Compiler over the last year or so. Of course, we have also benefited from some great contributions by the folks on the Haskell-Cafe mailing list. The thing I find most staggering about the compiler is that its quite brilliant at identifying wasted work. Many of the original shootout test cases were written to test the performance of simple scripting languages, and had grown a set of hacks over the years to keep the run times large enough to measure as processor speeds improved and language implementations became more sophisticated. In many cases, tests involved calculation or large values in loops, which would cause Perl and Python (and even C, Java, and C++) to chug merrily away burning cycles so that I could measure the timings in seconds, rather than microseconds. Then along came GHC, which began achieving enormous wins over the other languages because the lazy nature of the evaluation threw out the unneeded calculations, handing over the final useful result without breaking a sweat. Consequently, we had to revise many of the tests to force the programs to perform real work that could not be avoided, in some cases by forcing intermediate values to be printed in the solutions so we could be sure the work was actually being done. With those changes, Haskell began to fall back in speed to more moderate levels. However, in the last few releases of GHC (and the last several rounds of tweaks by the Haskellers on the Cafe list), GHC has risen to the top of the heap, approaching native C in performance overall. What I find quite appealing about this is that the performance is consistent across platforms. While Java's "HotSpot" compiler makes a good showing on Intel, my AMD test machine yields consistently worse results than the Pentium IV system. However, GHC performs equally well on both systems, yielding a similar fractional performance against C in both cases[1,2]. I think this is great because it means that applications written in Haskell can be reasonably expected to yield good performance on all of the common x86 platforms without customizations. Java and several other languages seem to yield varying performance, probably because of advanced optimizations available on the Intel platform that have been hand-coded into those systems. At any rate, I just wanted to write a quick fan letter about Haskell, and let you know how impressed I am with its performance. Looks like it's time for me to start taking a serious look at Haskell for some real-world problems at work now! Best regards, Brent Fulgham http://shootout.alioth.debian.org/ [1] "http://shootout.alioth.debian.org/gp4/benchmark.php? test=all&lang=all" [2] "http://shootout.alioth.debian.org/debian/benchmark.php? test=all&lang=all" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFEnLtkzGDdrzfvUpURAhRBAKCHWiIAJVONyKhDQgG/rBvSmGGDWgCeIufW G2nx/o1ruiXT5Yn9EcNxsFk= =U7WI -----END PGP SIGNATURE-----

5 4

ANNOUNCE: HNOP 0.1
by Ashley Yakeley 01 Jul '06

01 Jul '06

HNOP: Haskell No Operation A first version of HNOP 0.1 is now available under a simple permissive license. This version should be considered "beta" quality, though I don't know of any bugs. http://semantic.org/hnop.tar.gz HNOP does nothing. Here's a sample session to illustrate: $ ./hnop $ The code is written entirely in plain Haskell 98 and makes no use of FFI or impure functions. The source is available in a darcs repository: darcs get http://semantic.org/hnop/ Possible applications include generated code size comparison for compilers, and as a starting point for more complex Haskell projects. -- Ashley Yakeley Seattle, WA

12 17

Re: ANNOUNCE: HNOP 0.1
by Paul Johnson 30 Jun '06

30 Jun '06

Now we just need the Godot version, in which nothing happens twice. Or are Godots considered harmful? Paul.

1 0

NEW: hpodder
by John Goerzen 30 Jun '06

30 Jun '06

Hello everyone, I'm pleased to announce the first release of hpodder. hpodder is a podcast downloader (podcatcher) written in pure Haskell. I wrote it because I was unsatisfied with the other podcatchers for Linux. I am using hpodder for my own purposes already. hpodder homepage: http://quux.org/devel/hpodder documentation: http://darcs.complete.org/hpodder/doc/hpodder.pdf darcs repo: http://darcs.complete.org/hpoder feature list: · Convenient, easy to learn, and fast command-line interface (it's sim- ple to do simple things, and advanced things are possible) · Automatic discovery of feed metadata such as title · Full history database for accurate prevention of duplicate downloads and tracking of new episodes · Conversion tools to convert your existing feed list and history from other applications to hpodder. Supported applications and formats include: castpodder and ipodder. · Most operations can work fully automatically across your entire pod- cast database, or they can work manually as well. · Automatic updating of ID3 (v1 and v2) tags based on metadata in the podcast itself. This important feature is available through iTunes but is often missed by other podcatchers. · hpodder operations can be easily scripted or scheduled using regular operating system tools. · Fully customizable naming scheme for downloaded episodes, including a name collision detection and workaround algorithm. · Automatic support for appending .mp3 extensions to MP3 files that lack it. · Numerous database and history inquiry tools · Small, minimalist footprint · Power users and developers can interact directly with the embedded Sqlite3 database used by hpodder. The database has a simple schema that is developer-friendly. · Support for resuming interrupted downloads of podcasts · hpodder is SAFE and is designed with data integrity in mind from the beginning. It should be exceedingly difficult to lose a podcast episode, even in the event of a power failure.

1 1

Speed of ByteString.Lazy
by Chad Scherrer 30 Jun '06

30 Jun '06

I have a bunch of data files where each line represents a data point. It's nice to be able to quickly tell how many data points I have. I had been using wc, like this: % cat *.txt | /usr/bin/time wc 2350570 4701140 49149973 5.81user 0.03system 0:06.08elapsed 95%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (152major+18minor)pagefaults 0swaps I only really care about the line count and the time it takes. For larger data sets, I was getting tired of waiting for wc, and I wondered whether ByteString.Lazy could help me do better. So I wrote a 2-liner: import qualified Data.ByteString.Lazy.Char8 as L main = L.getContents >>= print . L.count '\n' ... and compiled this as "lc". It doesn't get much simpler than that. How does it perform? % cat *.txt | /usr/bin/time lc 2350570 0.09user 0.13system 0:00.24elapsed 89%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (199major+211minor)pagefaults 0swaps Wow. 64 times as fast for this run, with almost no effort on my part. Granted, wc is doing more work, but the number of words and characters aren't interesting to me in this case, anyway. I can't imagine (implementation time)*(execution time) being much shorter. Thanks, Don! -- Chad Scherrer "Time flies like an arrow; fruit flies like a banana" -- Groucho Marx

4 5