July 2006 - Haskell - Haskell.org

FLoC 06 -- Call For Participation
by Kreutzer + Schweikardt 03 Jul '06

03 Jul '06

Call for Participation --- FLoC'06 The 2006 Federated Logic Conference Seattle, Washington, USA August 10 -- August 22, 2006 http://www.easychair.org/FLoC-06/ Early registration deadline: July 10, 2006. We are pleased to announce the fourth Federated Logic Conference (FLoC'06) to be held in Seattle, Washington, in August 2006, at the Seattle Sheraton (http://www.easychair.org/FLoC-06/floc-hotel.html) FLoC'06 promises to be the premier scientific meeting in computational logic in 2006. The following conferences will participate in FLoC'06: CAV Conference on Computer Aided Verification (Aug 17-20) ICLP Int'l Conference on Logic Programming (Aug 17-20) IJCAR Int'l Joint Conference on Automated Reasoning (Aug 17-20) LICS IEEE Symposium on Logic in Computer Science (Aug 12-15) RTA Conference on Rewriting Techniques and Applications (Aug 12-14) SAT Int'l Conference on Theory and Applications of Satisfiability Testing (Aug 12-15) The six major conferences will be accompanied by 41 workshops, held on Aug. 10-11, 15-16, and 21-22. The FLoC'06 program includes a keynote session to commemorate the Goedel Centenary, with John Dawson and Dana Scott as speakers, a keynote talk by David Harel, plenary talks by Randy Bryant and David Dill, and invited talks by F. Bacchus, A. Blass, B. Buchberger, A. Darwiche, M. Das, J. Esparza, J. Giesl, A. Gordon, T. Hoare, O. Kupferman, M. Lam, D. Miller, K. Sakallah, J. Stoy, and C. Welty. Seattle, the Emerald city, sits on the shores of Puget Sound surrounded by mountains to the east and west. Lovely views of blue waters and snow capped peaks seem to appear everywhere - around the next bend in the road or between the buildings downtown. Seattle is the gateway to the Pacific Northwest, a premier tourist attraction. In Seattle, Mt. Rainier enchants visitors; in Vancouver, British Columbia, the Coast Range juts out over downtown; and in Portland, 5,000 acres of forestland north of the city center harbor deer, elk, and the odd bear and cougar. Online registration for FLoC is now open at: http://www.easychair.org/FLoC-06/ Deadline for early registration is July 10, 2006. The rates agreed upon between FLoC and the Seattle Sheraton are very reasonable rates for a first-class hotel in downtown Seattle during the summer vacation season. To reduce conference costs and keep registration fees reasonable, FLoC is contractually obligated to meet a commitment for a certain number of FloC attendees staying in the conference hotel. FLoC attendees are strongly encouraged to use the Seattle Sheraton for conference accommodation. Deadline for preferred hotel rate is July 21, 2006. FLoC'06 Steering Committee Moshe Y. Vardi (General Chair) Thomas Ball (Conference Co-Chair) Jakob Rehof (Conference Co-Chair) Edmund Clarke (CAV) Reiner Hahnle (IJCAR) Manuel Hermenegildo (ICLP) Phokion Kolaitis (LICS) Henry Kautz (SAT) Aart Middeldorp (RTA) Andrei Voronkov (IJCAR)

1 0

GADTs are not nice to me ;-)
by Wolfgang Jeltsch 03 Jul '06

03 Jul '06

Hello everybody, I wanted to do something like that: data Pair :: (* -> *) -> * where Pair :: a b -> b -> Pair a data Sel :: * -> * where A :: Sel Bool B :: Sel Integer showSnd :: Pair Sel -> String showSnd (Pair A bool) = show bool showSnd (Pair B integer) = show integer However, GHC 6.4.1 with -fglasgow-exts complains in the second last and last line that there is no instance for (Show b). I don't really understand this since in my opinion it is clear that bool :: Bool and integer :: Integer and that therefore bool and integer are showable. What's the problem with my code? Best wishes, Wolfgang

2 2

ANN: updates to ldap-haskell, arch2darcs, darcs-buildpackage
by John Goerzen 03 Jul '06

03 Jul '06

Hello, I have posted new versions of the following three packages. These versions do nothing but update the cabal file to be compatible with GHC 6.4.2. ldap-haskell http://quux.org/devel/ldap-haskell gopher://quux.org/1/devel/ldap-haskell darcs get --partial http://darcs.complete.org/ldap-haskell arch2darcs darcs get --partial http://darcs.complete.org/arch2darcs darcs-buildpackage darcs get --partial http://darcs.complete.org/darcs-buildpackage Thanks, -- John

1 0

FW: FORMAL METHODS 2006: Early Reg. Deadline
by Simon Marlow 03 Jul '06

03 Jul '06

[ forwarding on behalf of Jeff Zucker <zucker(a)cas.mcmaster.ca>] ======================================================================== ==== FM'06: 14TH INTERNATIONAL SYMPOSIUM ON FORMAL METHODS 21 - 27 August 2006 McMaster University, Hamilton, Ontario, Canada http://fm06.mcmaster.ca/ REMINDER: EARLY REGISTRATION ENDS ON JULY 7 The FM Symposia continue to be the premier international forum for practitioners and researchers applying mathematical methods to the design of highly trusted computer systems. It enables them to meet and exchange experiences and ideas. This is the 14th event in this series, and for the first time will take place in North America. Among the highlights: * Technical Symposium with 36 papers (out of 158 submissions) and Best Paper Award * Doctoral Symposium, aimed at young researchers * Industry Day with 8 speakers reporting on industrial usage * 5 Invited Speakers * 10 Tutorials * 4 Workshops * Commercial Tool Exhibition * Research Poster and Tool Exhibition * Book Exhibition

1 0

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

Haskell Weekly News: July 03, 2006
by dons＠cse.unsw.edu.au 02 Jul '06

02 Jul '06

--------------------------------------------------------------------------- Haskell Weekly News http://haskell.org/haskellwiki/HWN Issue 39 - July 03, 2006 --------------------------------------------------------------------------- Welcome to issue 39 of HWN, a weekly newsletter covering developments in the Haskell community. Each week, new editions are posted to [1]the Haskell mailing list as well as to [2]the Haskell Sequence and [3]Planet Haskell. [4]RSS is also available, and headlines appear on [5]haskell.org. A week of busy activity in the community. Thanks to Simon Marlow and Josef Svenningsson for contributions to this issue. 1. http://www.haskell.org/mailman/listinfo/haskell 2. http://sequence.complete.org/ 3. http://planet.haskell.org/ 4. http://sequence.complete.org/node/feed 5. http://haskell.org/ Announcements * HDBC 1.0 . John Goerzen [6]released the latest HDBC. HDBC is a database tool, modeled loosely on Perl's DBI interface, though it has also been influenced by Python's DB-API v2, JDBC in Java, and HSQL in Haskell. You can find the code [7]here. 6. http://article.gmane.org/gmane.comp.lang.haskell.general/13879 7. http://quux.org/devel/hdbc * hpodder . John Goerzen [8]announced the first release of hpodder. hpodder is a podcast downloader (podcatcher) written in pure Haskell. It exists because John was unsatisfied with the other podcatchers for Linux. Full details [9]here. 8. http://article.gmane.org/gmane.comp.lang.haskell.general/13880 9. http://quux.org/devel/hpodder * hmp3 1.1 . Don Stewart [10]announced a new release of hmp3, the curses-based mp3 player written in Haskell. Release 1.1 is a maintenance release, fixing support for GHC 6.4.2 10. http://article.gmane.org/gmane.comp.lang.haskell.general/13864 * HSP.Clientside 0.001 . Joel Bjornson [11]announced a prerelease version of Hsp.Clientside. This is Joel's [12]Summer of Code project aiming to add support for client-side script generation in Haskell Server Pages. The basic building blocks for embedding Javascript has been implemented. As the project proceeds a suitable programming model based on these components will be added. Hopefully this will also include some kind of higher level Ajax support. For more information see [13]here. 11. http://article.gmane.org/gmane.comp.lang.haskell.general/13851 12. http://code.google.com/soc/haskell/about.html 13. http://www.dtek.chalmers.se/~bjornson/soc * QDBM and Hyper Estraier bindings . Jun Mukai [14]released a library of bindings to Quick DBM, a database module similar to GDBM, Berkeley-DB, optimized for performance and a simple API. Additionally, Jun's code includes support for Hyper Estraier, a full-text search system using QDBM, with the ability to search documents according to keywords. 14. http://article.gmane.org/gmane.comp.lang.haskell.libraries/4821 * Streams 0.2 . Bulat Ziganshin [15]announced the beta release of his Streams 0.2 library, providing fast string and binary IO, now with Data.ByteString support. 15. http://article.gmane.org/gmane.comp.lang.haskell.libraries/4820 * HNOP 0.1 . Ashley Yakeley [16]released the first version of HNOP 0.1. HNOP does nothing. This version should be considered "beta" quality. 16. http://article.gmane.org/gmane.comp.lang.haskell.general/13881 * HList updates . Oleg Kiselyov [17]announced that HList, the library for strongly typed heterogeneous lists, records, type-indexed products (TIP) and co-products is now accessible via darcs, [18]here. Additionally, Oleg pointed to some new features for HList, including a new representation for open records. Finally, he [19]published a note on how HList supports, natively, polymorphic variants: extensible recursive open sum datatypes, quite similar to Polymorphic variants of OCaml. HList thus solves the `expression problem' -- the ability to add new variants to a datatype without changing the existing code. 17. http://article.gmane.org/gmane.comp.lang.haskell.general/13905 18. http://darcs.haskell.org/HList/ 19. http://article.gmane.org/gmane.comp.lang.haskell.general/13906 * Haskell IO Inside . Bulat Ziganshin [20]wrote a new introductory tutorial to IO in Haskell, [21]Down the Rabbit's Hole. 20. http://article.gmane.org/gmane.comp.lang.haskell.cafe/13409 21. http://haskell.org/haskellwiki/IO_inside * Bytecode API 0.2 . Robert Dockins [22]published the Yhc Bytecode API version 0.2. More details [23]here. 22. http://article.gmane.org/gmane.comp.lang.haskell.yhc/146 23. http://www.eecs.tufts.edu/~rdocki01/yhc-bytecode.html * Translating Haskell into English . Shannon Behrens [24]published a new Haskell tutorial, hoping to give readers a glimpse of the Zen of Haskell, without requiring that they already be Haskell converts. 24. http://www.linuxjournal.com/article/9096 Haskell' This section covers the [25]Haskell' standardisation process. * [26]Nested Guards 25. http://hackage.haskell.org/trac/haskell-prime 26. http://thread.gmane.org/gmane.comp.lang.haskell.prime/1561/focus=1561 Discussion * Haskell and the Great Language Shootout, reloaded . Simon Marlow [27]highlighted some remarks and discussion from Brent Fulgham, the driving force behind the [28]Great Language Shootout on the impact recent advances in the performance of GHC have had. In particular, many benchmarks had to be rewritten due to the performance advantage lazy Haskell programs had over strict (and wasteful) entries in other languages. Brent noted that "applications written in Haskell can be reasonably expected to yield good performance on all of the common x86 platforms without customizations". This in turn led to a discussion about further improvements we can expect to see in GHC Haskell over the next few months. 27. http://thread.gmane.org/gmane.comp.lang.haskell.general/13857/focus=13857 28. http://shootout.alioth.debian.org/ * HNOP, doing nothing, and really complex ways of doing nothing . Ashley Yakeley [29]forked a somewhat surreal thread regarding Haskell programs that do nothing. 29. http://thread.gmane.org/gmane.comp.lang.haskell.general/13881/focus=13881 Quotes of the Week * Brian Hulley : "It is definitely *a* haskell. There is actually no word in English with a silent 'h', though this statement is unfortunately controversial and news to whoever wrote the spell checker used in many printed publications. Of course some particular dialects use different pronunciation like 'me 'otel room 'ad an 'askell 'mpiler in t' closet as well as tub 'n sink tha knows'" Code Watch Thu Jun 29 06:58:36 PDT 2006 Simon Marlow * No longer force -fvia-C for the RTS, it can now be compiled with the NCG Sat Jul 1 01:43:45 PDT 2006 Don Stewart * Import Data.ByteString.Lazy, improve ByteString Fusion, and resync with FPS head This patch imports the Data.ByteString.Lazy module, and its helpers, providing a ByteString implemented as a lazy list of strict cache-sized chunks. This type allows the usual lazy operations to be written on bytestrings, including lazy IO, with much improved space and time over the [Char] equivalents. Contributing to HWN To help create new editions of this newsletter, please see the [30]contributing information. Send stories to dons at cse.unsw.edu.au. The darcs repository is available at darcs get http://www.cse.unsw.edu.au/~dons/code/hwn 30. http://haskell.org/haskellwiki/HWN

1 0

Polymorphic variants (extensible, recursive sums) with HList
by oleg＠pobox.com 02 Jul '06

02 Jul '06

The existing HList records support, without further programming, polymorphic variants: extensible recursive open sum datatypes, quite similar to Polymorphic variants of OCaml. HList thus solves the familiar (in OO, at least) `expression problem' -- an ability to add new variants to a datatype without changing the existing code. We should be able to extend old processing functions to deal with the extended data type, maximally reusing the old code. Furthermore, values of unextended data types should be processed by extended functions without any ado. http://darcs.haskell.org/HList/VariantP.hs Our implementation of polymorphic variants in terms of HList records uses no type classes, no type-level programming or any other type hacking. In fact, there are no type annotations, type declarations, or any other mentioning of types, except in the comments. Our example is patterned after the running example of the paper by Koji Kagawa,`Polymorphic Variants in Haskell' <http://guppy.eng.kagawa-u.ac.jp/~kagawa/PVH> which proposed quite different approach to the same problem. We start our example by `declaring' a list-like data type data List a = Nil | Cons a (List a) which we later extend with two more alternatives. In our example, we declare labels (for simplicity, of four models of labels, we use the simplest and the most ungainly) > l_nil = firstLabel > l_cons = nextLabel l_nil and define two constructrors: > nil consumer = consumer .!. l_nil > cons a l consumer = (consumer .!. l_cons) a (l consumer) and that is basically it. We can immediately build lists > tl2 c = cons 10 (cons 1 (cons 2 (cons 3 nil))) c and define list processing functions, e.g., to find the length of the list > lengthL () = l_nil .=. 0 > .*. l_cons .=. (\x a -> a + 1) > .*. emptyRecord > tekiyou consumer lst = lst (consumer ()) > test_lL2 = tekiyou lengthL tl2 Incidentally, the list tl2 is actually polymorphic over any numbers (Num). Now, we want to make our lists more efficient and so add to more alternatives to the List a data type, so it would now `read' data List a = Nil | Cons a (List a) | Unit a | App (List a) (List a) We only need to define two more labels, l_unit and l_app, and two constructors > unit a c = (c .!. l_unit) a > app l1 l2 c = (c .!. l_app) (l1 c) (l2 c) and we can build new lists > tl3 c = cons 1 (unit 2) c > tl4 c = cons 10 (app tl3 tl2) c by mixing old and new constructors. The code of the old constructors remains as it were. We can define a processing function over the extended lists: > sumA () = l_nil .=. 0 > .*. l_cons .=. (+) > .*. l_unit .=. id > .*. l_app .=. (+) > .*. emptyRecord and apply it to the extended list > test_sum2 = tekiyou sumA tl4 as well to the original, simple, unextended list: > test_sum1 = tekiyou sumA tl2 However, we can't pass extended lists tl3 and tl4 to a regular lenghtL. The type error message says that the field l_unit is missing But we can extend lengthL, reusing as much of previous functionality as possible > lengthA () = l_unit .=. const 1 > .*. l_app .=. (+) > .*. (lengthL ()) > > test_lL4 = tekiyou lengthA tl3 > test_lL5 = tekiyou lengthA tl4 The VariantP.hs file has more examples. An attentive reader has noticed that we took advantage of the fact that the deMorgan law NOT (A | B) -> (NOT A & NOT B) holds both in classical, and, more importantly, intuitionistic logics. Our encoding of sums is the straightforward Curry-Howard image of that law.

1 0

HList with new records, in darcs.haskell.org
by oleg＠pobox.com 02 Jul '06

02 Jul '06

The HList library of strongly typed heterogenous lists, records, type-indexed products (TIP) and co-products is now accessible via DARCS http://darcs.haskell.org/HList/ The library contains a new representation for open records. Previously (Record.hs) a record is a Scheme-like heterogenous associative list, that is, the list of pairs of field label and the corresponding field value. The HList library uses the type of the label, therefore, the run-time representation of the label is actually `undefined'. Thus, a record built as rec1 = label1 .=. True .*. lab2 .=. 'c' .*. emptyRecord has the run-time representation HCons (undefined,True) (HCons (undefined,'c) HNil) In the new representation, RecordP.hs in the repository, the record is a heterogeneous list of field values. Label _types_ are also bundled in a heterogenous list of types, which annotate the record type as a phantom type. Thus if we write rec2 = label1 .=. True .*. lab2 .=. 'c' .*. emptyRecordP rec2 now has the run-time representation of HCons True (HCons 'c HNil) That is, labels are nowhere to be found in the run-time representation. Field labels become compile-time-only entity. Of course, by making labels Typeable and using the methods of that class it is possible to access the label information at run-time, if so desired. The new representation of the records supports the old record interface; for example, both (rec1 .!. lab2) and (rec2 .!. lab2) evaluate to 'c', the value of the field lab2. RecordP are similar to TIP; however, the values of RecordP are indexed by the label types rather than by their own types. RecordP have an advantage for representing tables -- homogenous collections of rows, which in turn are records of fields (columns): newtype Table ls vs = Table [RecordP ls vs] All records have exactly the same field types in the same sequence. The run-time representation of the table is just the collection of all the field values. The database schema, labels and the column types, is a compiled-time entity and used for checking and compiling of database operations.

1 0

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

Re: ANNOUNCE: HNOP 0.1
by Paul Johnson 01 Jul '06

01 Jul '06

> One interesting line of development would be to spin off the core > functionality into a separate library, to provide no-op services to > other Haskell applications. Actually this would be useful, and probably belongs in Control.Monad (although I'd call it "noOp" rather than "noop"). I was recently working on code that took monadic actions as parameters, so that under the right circumstances the appropriate action would be executed. On several occasions I had to pass "return ()" as a null action. Having an explicit "noOp :: Monad m => m ()" would have made the code shorter and clearer. Paul.

1 0