January 2009 - Haskell

ANN: curl-1.3.4
by Sigbjorn Finne 19 Jan '09

19 Jan '09

Hi, a new version 'curl', a complete Haskell binding to the libcurl API, is now available and have been uploaded to Hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/curl Git repo at git://code.galois.com/curl.git Appended is the list of changes since the previous release. Most notable is the overloading of representation of response buffers (and headers), allowing for the use of ByteStrings. Speedups might be had as a result... enjoy --sigbjorn Version 1.3.4: released 2009-01-18; changes from 1.3.3 * Overloaded Network.Curl operations over response representation of payloads and headers. Controlled via CurlBuffer and CurlHeader classes. New actions: - curlGetString_, curlGetResponse_, perform_with_response_, do_curl_, curlHead_ * Provided ByteString instances (strict and lazy) * No modification in calling interface to existing exports, so backwards compatible. * Added Show instance for Network.Curl.Opts.CurlOption * curl_version_string, curl_version_number now gives you access to version info of underlying lib you _compiled_ the package with. * Sync'ed wrt libcurl-7.19.2, so bunch of new options added to Network.Curl.Opts. Use version functions to determine if they are supported though.

1 0

ANNOUNCE: Turbinado V0.4
by Alson Kemp 18 Jan '09

18 Jan '09

Turbinado (http://www.turbinado.com) is an easy to use Model-View-Controller-ish web framework for Haskell. The source for the framework can be found at: http://github.com/alsonkemp/turbinado The source for the website turbinado.org can be found at: http://github.com/alsonkemp/turbinado-website (see the /App directory for the code for www.turbinado.org) Release 0.4 contains: * A dramatically improved ORM (or Type-Relation Mapper) which handles foreign keys. Still PostgreSQL only at this point. * All dependencies in tmp/dependencies to ease building the application. * In code documentation (not complete, but starting). * Documentation (see http://turbinado.org/Architecture) Release 0.5 will focus on: * Ease of installation! * Moving to GHC 6.10 (whenever Debian shifts). Diego Eche provided a port from plugins to ghc-api. * Additional functionality (e.g. sessions, authentication, etc). * Tutorials.

2 2

ICLP 2009: Call for workshop proposals
by cfp＠clip.dia.fi.upm.es 18 Jan '09

18 Jan '09

*** CALL FOR WORKSHOP PROPOSALS *** ICLP 2009 25th International Conference on Logic Programming Pasadena, California, USA July 14-17, 2009 URL: http://www.ist.unomaha.edu/iclp2009/ ICLP 2009, the 25th International Conference on Logic Programming, will be held in Pasadena (USA), from July 14 to 17, 2009. Workshops co-located with international conferences are one of the best venue for the presentation and discussion of preliminary work, novel ideas, and new open problems to a wide and interested audience. Co-located workshops also provide an opportunity for presenting specialized topics and opportunities for intensive discussions and project collaboration. The topics of the workshops co-located with ICLP 2009 can cover any areas related to logic programming, (e.g., theory, implementation, environments, language issues, alternative paradigms, applications), including cross-disciplinary areas. However, any workshop proposal will be considered. The format of the workshop will be decided by the workshop organizers, but ample time must be allowed for general discussion. Workshops can vary in length, but the optimal duration will be half a day or a full day. Workshop Proposal: ================== Those interested in organizing a workshop at ICLP 2009 are invited to submit a workshop proposal. Proposals should be in English and about two pages in length. They should contain: * The title of the workshop. * A brief technical description of the topics covered by the workshop. * A discussion of the timeliness and relevance of the workshop. * A list of some related workshops held in the last years. * The (preliminary) required number of half-days allotted to the workshop and an estimate of the number of expected attendees. * The names, affiliation, and contact details (email, web page, phone, fax) of the workshop organizer(s) together with a designated contact person. * The previous experience of the workshop organizing committee in workshop/conference organization. Proposals are expected in ASCII or PDF format. All proposals should be submitted to the Workshop Chair (Manuel Carro) by email by February 9th, 2009. Reviewing Process: ================== Each submitted proposal is reviewed by the Workshops Chair and the Conference Program Chairs. Proposals that appear well-organized and that fit the goals and scope of ICLP will be selected. The decision will be notified by email to the responsible organizer by February 23rd, 2009. The definitive length of the workshop will be planned according to the number of submissions received by the different workshops. For every accepted workshop, the ICLP local organizers will prepare a meeting place and arrange the distribution of the workshop proceedings, whose preparation is however in charge to the workshop organizers. The workshop registration fees will be handled together with the conference fees. Workshop Organizers' Tasks: =========================== * Producing a "Call for Papers" for the workshop and posting it on the net and/or other means. Please provide a web page URL which can be linked into the ICLP 2009 home page by March 9th, 2009. * Providing a brief description of the workshop for the conference program. * Reviewing/accepting submitted papers. * Scheduling workshop activities in collaboration with the local organizers and the workshop chair. * Sending workshop program and workshop proceedings in pdf format to the workshop chair for distribution at the conference. * The use of the Computing Research Repository (CoRR) for the workshop proceedings is strongly suggested. See http://www.logicprogramming.org/ for guidelines. We encourage reading these instructions in advance so that you can ask paper authors to prepare accordingly the final versions of their papers. Location: ========= All workshops will take place in Pasadena at the site of the main conference. See the ICLP 2009 web site for location details. Important Dates: ================ February 9, 2009: Proposal submission deadline. February 23, 2009: Notification. March 9, 2009: Deadline to receive the CFP and URL for the web page of the workshop June 1, 2009: Deadline for preliminary proceedings. July 14-17, 2009: ICLP 2009 workshops. Workshop Chair: =============== Manuel Carro [mcarro AT fi dot upm dot es] (www.clip.dia.fi.upm.es/~mcarro)

1 0

How to define gunfold on List?
by haihualin 18 Jan '09

18 Jan '09

Hi, Does some one know how to define gunfold on recursive data struction like List? The ghc doc only give the example for non-recursive data like below. data T a b = C1 a b | C2 deriving (Typeable, Data) GHC will generate an instance that is equivalent to instance (Data a, Data b) => Data (T a b) where gfoldl k z (C1 a b) = z C1 `k` a `k` b gfoldl k z C2 = z C2 gunfold k z c = case constrIndex c of 1 -> k (k (z C1)) 2 -> z C2 toConstr (C1 _ _) = con_C1 toConstr C2 = con_C2 dataTypeOf _ = ty_T con_C1 = mkConstr ty_T "C1" [] Prefix con_C2 = mkConstr ty_T "C2" [] Prefix ty_T = mkDataType "Module.T" [con_C1, con_C2]

2 1

Re: [Haskell] An Alternative Data.List.Zipper
by Jeff Wheeler 18 Jan '09

18 Jan '09

On Sat, 2009-01-17 at 21:55 +0100, Jean-Philippe Bernardy wrote: > I think it should admit empty, and the traversable instance should > traverse the first list in reverse. I fixed the latter issue so that the behavior is correct (I think). I tested it like this: > forM (next $ next $ fromList [1..5]) $ \i -> do { print i; return i } 1 2 3 4 5 [1,2] 3 [4,5] which I believe is proper. I'm undecided about allowing them to be empty. I don't know the theory or math behind zippers (I'm sure there are some papers written about it), but it doesn't make much sense to be empty. I got that impression from #haskell, also. Thanks for the comments. :) Jeff Wheeler

3 5

Hackage about to reach 1000 releases
by Don Stewart 18 Jan '09

18 Jan '09

Hackage is about to reach the 1000 release mark, 2 years after it went live. That's right: in 2 years we've gone from having only a handful of released projects, to one thousand! Well done everyone! I did some quick visualisation of the rate of new releses, diversity of packages, and community growth over the period: http://archhaskell.wordpress.com/2009/01/18/open-source-haskell-releases-an… I'm very happy about the diversity of hackage apps, and the pleasing rate of growth of new releases. None of this would have been possible with out thousands of hours of work from the Cabal and Hackage hackers, the compiler teams, and the developers themselves. Keep churning out new and intresting code everyone! -- Don P.S. cabal install

1 0

Teach theory then Haskell as example
by Andrzej Jaworski 18 Jan '09

18 Jan '09

Hi, Although it will not help you to know who your grandparent was it is always better to know what reason is behind particular formalism that you use. And the better you know it the further you go with it. So after seeing reappearing questions on the nature and role of fundamental concepts in Haskell I came to a belief that Haskell should be taught via stressing abstract concepts and explaining them rather than downplaying or postponing the explanation. It may look like asking to further expand Haskell's learning curve but I will argue that half learned concepts haunt Haskellers for ever. So, if you teach Haskell as a tool it will always remain a mystery and haunt. My argument is that vice versa should be true: if you explain fundamental concepts in their own right the programmer will gain insight and be able to navigate by power of his own judgment and not by following alchemical recipes. What is more Haskell should be taught on most abstract terms in a framework of higher order logic, types and CT right from the start. Not that it is so different but because: (0) it can afford it (1) it is conductive to abstract thinking by giving more control in structuring the code (2) it matters in what language you think and you cannot think in formalism (you need to root it in models) (3) abstract thinking is more effective (than thinking by example) and is the only way to produce non-trivial solutions. Just browsing book titles in mathematical literature like "The Concept of Number: From Quaternions to Monads and Topological Fields","Monads and automata", "Monads and graphs" should bring confidence that there is deep universe behind Haskell's abstract stuff. So, why try to hide this instead of making direct reference to that unique legacy? Explaining wide roots of Haskell should motivate and disinfect narrow mindedness injected by regular CS courses. Programmers learning Haskell should forget that they are programmers and try to think mathematically. First few years of CS history belonged to mathematicians that for amusement created Fortran and Lisp. Then John McCarthy tried to warn guys proclaiming themselves programmers that to build their skills they should study logic rather than programming. Obviously they haven't listen;-) If abstraction has deep natural roots sooner or later it will unleash its power. Just one funny example: Till 70s the language of category theory was ridiculed even buy guys who used it, like omnipresent Serge Lange. One of the exercises in his "Algebra" (1966) was: "take any book on Homological Algebra and prove all its theorems" (in elementary way). The categories and functors were then used only for the fashion introduced by Bourbaki with their terse and purist writing style. But then surprise, surprise and true reason for homological algebra was discovered - sheaves - which with schemes dramatically extended the horizon for Algebraic Geometry. The irony is that most algebraic geometrists were brought up on Lange's "Algebra":-) Believing that an abstract concept is good for us is not enough however. It must be brought to us with some intuition, otherwise it will be a cumbersome formalism allowing at most to understand someone else ideas dressed in such a language. Intuition is however difficult to upgrade and the strongest your intuition is the most difficult it is to modify it. Albert Einstein was the greatest man of intuition of all time and he had always had very vivid mental model of a theory before dressing it up in mathematics. But it took him 15 years of agonizing struggle to come to general relativity formulae. The same task took Henri Poincare less then a week. Yes, and Poincare published it! But this great guy gave full credit to Einstein on the merit of him originating the problem. There are couple of lessons here: (0) separating formalism from intuition can kill you even if you sit on a solution (2) big things need more than one kind of intuition (3) complex problems can be solved only by abstract concepts (4) nothing is sufficiently abstract, it is an unending race. (it was Grassmann who referred Einstein to tensors and Riemannian geometry but the irony is that General Relativity would look much better in Grassmann algebra. Grassmann however was completely uninterested in making use of his discovery, when he was done with algebra he turned to ... Linguistics where he received his doctorate) (5) abstract thinking is not and cannot be motivated bay practical issues. GR may look abstract but for Poincare it was only another exercise in tensor analysis. So, when he was done with it he was happy to return to abstract issues:-) [that might explain why there are more Haskell theoreticians than real apps;-) ] I dedicate this to those who theach these who will teach the rest:-) -Andrzej

7 7

Re: [Haskell-cafe] ANNOUNCE: Coadjute 0.0.1, generic build tool
by Don Stewart 18 Jan '09

18 Jan '09

matti.niemenmaa+news: > Announcing the release of Coadjute, version 0.0.1! > > Web site: http://iki.fi/matti.niemenmaa/coadjute/ > Hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Coadjute > Here's an Arch Linux package for it, http://aur.archlinux.org/packages.php?ID=23237

1 0

An Alternative Data.List.Zipper
by Jeff Wheeler 17 Jan '09

17 Jan '09

Hi, (I also sent this to libraries@, but without response; I'm posting here for a wider audience.) I'm somewhat of a beginner in Haskell, so take what I say with a grain of salt, please. The ListZipper implementation seems very odd to me, and #haskell seemed to agree with me. The current package implements a Zipper with > data Zipper = Zipper ![a] ![a] which allows for empty zippers, among other things. Very strange to me. It also seems unnecessarily strict. There are also no expected typeclasses implemented, like Foldable or Traversable. I thought it would be interesting to try fixing these problems with a much cleaner design, and I'd like to share what I came up with: http://hpaste.org/14030 I'd very much appreciate some criticism of the code so that I can improve it. I'm not sure how best to provide this alternative on Hackage; should we make this merely a newer version of the old library, provide it in a conflicting package, or find a new namespace for it and provide it there? Thanks, Jeff Wheeler

2 2

ANN: leapseconds-announced-2009
by Bjorn Buckwalter 17 Jan '09

17 Jan '09

Dear all, I'm pleased to announce the upload of the leapseconds-announced package[1] to Hackage. leapseconds-announced contains a single module and a single function implementing the Data.Time.Clock.TAI.LeapSecondTable interface (type). The documentation[2] for Data.Time.Clock.TAI.LeapSecondTable says "No table is provided, as any program compiled with it would become out of date in six months" and with that I have no objections. However, I frequently find myself needing a LeapSecondTable for a quick-and-dirty one-off analysis or simulation of the present or past. In these cases I've lazily used "(const 33)" (or more recently: "(const 34)") as my LeapSecondTable. leapseconds-announced is a pragmatic, if imperfect, improvement over my past practices. It provides a LeapSecondTable with all leap seconds announced to date (hence the name). Once the IERS announces[3] another leap second the package will need an update and all code using it a recompile. While this precludes its use in long-running production applications it is eminently adequate for my one-off uses or for applications that can afford to recompile infrequently. While, in the words of the Data.Time.Clock.TAI documentation, "most people won't need this module" I hope it can be of utility to someone. Thanks, Bjorn Buckwalter [1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/leapseconds-anno… [2] http://www.haskell.org/ghc/docs/latest/html/libraries/time/Data-Time-Clock-… [3] http://hpiers.obspm.fr/eoppc/bul/bulc/bulletinc.dat

1 0