- Haskell-Cafe - Haskell.org

Haskell Weekly News: Issue 161 - December 08, 2010
by Daniel Santa Cruz 09 Dec '10

09 Dec '10

Welcome to issue 161 of the HWN, a newsletter covering developments in the [1]Haskell community in the week of November 28 - December 04. Jan Snajder [2]announced the release of genprog, a genetic programming library. Ian Lynagh informed us that the haskell.org server migration is now complete. There might still be some issues lying around, if you happen to spot one, please let the admins know. The biggest announcement this week came from Galois, Inc. on the [3]immediate release of the Haskell Lightweight Virtual Machine. "The HaLVM is a port of the GHC runtime system to the Xen hypervisor, allowing programmers to create Haskell programs that run directly on Xen's "bare metal."" Isabelle Perseil informed us that there is an [4]extension to the submission deadline for papers for International Conference on the Engineering of Complex Computer Systems (ICECCS) until December 15th. Gregory D. Weber [5]informed us of an update to his Sifflet tool, and sifflet-lib. "Sifflet is a visual, functional programming language and support system for students learning about recursion." This week we had 48 new StackOverflow questions, and 33 new Reddit stories. Hackage saw 108 uploads/updates from 59 distinct contributors. Most active uploaders to hackage were Michael Snoyman (16 uploads) and Andy Stewart (13 uploads). Big note of thanks to Janis Voigtländer and to Benjamin L. Russell for sending in bits for this newsletter. So, what went on this week? Top Reddit Stories * Galois releases the Haskell Lightweight Virtual Machine (HaLVM) Domain: galois.com, Score: 105, Comments: 26 On Reddit: http://www.reddit.com/r/haskell/comments/ee4ve/galois_releases_the_haskell_… Original: http://www.galois.com/blog/2010/11/30/galois-releases-the-haskell-lightweig… * Steve Yegge: Haskell Researchers Announce Discovery of Industry Programmer Who Gives a @#!& Domain: steve-yegge.blogspot.com, Score: 54, Comments: 42 On Reddit: http://www.reddit.com/r/haskell/comments/eeqw9/steve_yegge_haskell_research… Original: http://steve-yegge.blogspot.com/2010/12/haskell-researchers-announce-discov… * Fun with monad comprehensions Domain: blog.n-sch.de, Score: 35, Comments: 9 On Reddit: http://www.reddit.com/r/haskell/comments/ecu0w/fun_with_monad_comprehension… Original: http://blog.n-sch.de/2010/11/27/fun-with-monad-comprehensions/ * The Arrow Calculus Domain: wadler.blogspot.com, Score: 34, Comments: 2 On Reddit: http://www.reddit.com/r/haskell/comments/ee0ux/the_arrow_calculus/ Original: http://wadler.blogspot.com/2010/11/arrow-calculus.html * My strings can beat up your string Domain: finger-tree.blogspot.com, Score: 32, Comments: 13 On Reddit: http://www.reddit.com/r/haskell/comments/eecw2/my_strings_can_beat_up_your_… Original: http://finger-tree.blogspot.com/2010/11/my-strings-can-beat-up-your-strings… * Haskell Package Layout: a proposal Domain: mtnviewmark.wordpress.com, Score: 27, Comments: 8 On Reddit: http://www.reddit.com/r/haskell/comments/efhde/haskell_package_layout_a_pro… Original: http://mtnviewmark.wordpress.com/2010/12/02/haskell-package-layout/ * Real World Haskell ebook today: 60% off. Use code DDF2H Domain: oreil.ly, Score: 25, Comments: 16 On Reddit: http://www.reddit.com/r/haskell/comments/edexw/real_world_haskell_ebook_tod… Original: http://oreil.ly/free2choose * Comprehensive Monad Notation Domain: zenzike.com, Score: 23, Comments: On Reddit: http://www.reddit.com/r/haskell/comments/ef5rf/comprehensive_monad_notation/ Original: http://zenzike.com/posts/2010-12-02-comprehensive-monad-notation/ * Google AI Challenge: Languages Used by the Best Programmers Domain: r-bloggers.com, Score: 23, Comments: 13 On Reddit: http://www.reddit.com/r/haskell/comments/efrfv/google_ai_challenge_language… Original: http://www.r-bloggers.com/google-ai-challenge-languages-used-by-the-best-pr… * A small matter of illegal characters Domain: serpentine.com, Score: 22, Comments: 2 On Reddit: http://www.reddit.com/r/haskell/comments/edkhz/a_small_matter_of_illegal_ch… Original: http://www.serpentine.com/blog/2010/11/29/a-small-matter-of-illegal-charact… Top StackOverflow Questions * Whats really more performant? Haskell or OCaml votes: 12, answers: 4 Read on SO: http://stackoverflow.com/questions/4308137/whats-really-more-performant-has… * Problems on migrating from functional to OO votes: 10, answers: 5 Read on SO: http://stackoverflow.com/questions/4348788/problems-on-migrating-from-funct… * Getting a list of all possible data type values in Haskell votes: 8, answers: 3 Read on SO: http://stackoverflow.com/questions/4299319/getting-a-list-of-all-possible-d… * Haskell: Want a better way of doing: value == x || value == y || … votes: 6, answers: 1 Read on SO: http://stackoverflow.com/questions/4294652/haskell-want-a-better-way-of-doi… * Is/Should wrapping functions into a monad transformer be considered bad practice? votes: 6, answers: 3 Read on SO: http://stackoverflow.com/questions/4317101/is-should-wrapping-functions-int… * Trick for “reusing” arguments in Haskell? votes: 5, answers: 2 Read on SO: http://stackoverflow.com/questions/4333864/trick-for-reusing-arguments-in-h… * How to write common “if” branching in Haskell votes: 4, answers: 5 Read on SO: http://stackoverflow.com/questions/4296887/how-to-write-common-if-branching… * Comparing functions in Haskell votes: 4, answers: 4 Read on SO: http://stackoverflow.com/questions/4328620/comparing-functions-in-haskell * Encapsulating a list of functions in haskell in a single one votes: 4, answers: 2 Read on SO: http://stackoverflow.com/questions/4343951/encapsulating-a-list-of-function… * Can I have a value constructor named “/”"? votes: 4, answers: 3 Read on SO: http://stackoverflow.com/questions/4348605/can-i-have-a-value-constructor-n… Quotes from the Week * camccann: A humor monad? So basically that's a model where jokes about something are equivalent to jokes about jokes about something. In other words, meta-humor in-jokes. * djahandarie: I'm like a massively parallel but slow clocked processor * wlangstroth: It's disgusting hom much talent there is at galois About the Haskell Weekly News New editions are posted to [6]the Haskell mailing list as well as to [7]the Haskell Sequence and [8]Planet Haskell. [9]RSS is also available, and headlines appear on [10]haskell.org. To help create new editions of this newsletter, please send stories to dstcruz * at * gmail * dot * com. The code used to produce this version of the newsletter is not yet publicly available, as it is a complete hack designed to get things started again. Until next time, Daniel Santa Cruz References 1. http://haskell.org/ 2. http://article.gmane.org/gmane.comp.lang.haskell.general/18322 3. http://article.gmane.org/gmane.comp.lang.haskell.general/18328 4. http://article.gmane.org/gmane.comp.lang.haskell.general/18339 5. http://article.gmane.org/gmane.comp.lang.haskell.general/18344 6. http://www.haskell.org/mailman/listinfo/haskell 7. http://sequence.complete.org/ 8. http://planet.haskell.org/ 9. http://sequence.complete.org/node/feed 10. http://haskell.org/

1 0

ANNOUNCE: packdeps 0.0.0
by Michael Snoyman 08 Dec '10

08 Dec '10

Hi all, I'm happy to announce the first release of packdeps[1]. This is a library and executable containing the same functionality as the original packdeps website[2], namely letting you know when your version bounds exclude the use of the newest version of a library available. While the website is very useful for keeping you up-to-date on your already released packages, it does not help you during the development phase, or for packages not released on Hackage. The executable (packdeps) should be a good fit here. Its usage is very simple: simply pass it a list of cabal files, and it will check each one of them against your 00-index.tar file. (In other words, make sure to run a cabal update before relying on its results too much.) The library, frankly, is a mess: the naming is bad, the performance tradeoffs were chosen for a long-running web application instead of a short-lived console app, and it eats a baby panda each time you run it. I'm more than happy to accept patches on this. Nonetheless, I'm not aware of any bugs in the code, and I think it will be generally useful in its current state. Cheers, Michael [1] http://hackage.haskell.org/package/packdeps [2] http://packdeps.haskellers.com/

1 0

hackage dependencies for cabal setup scripts
by Sönke Hahn 08 Dec '10

08 Dec '10

Hi! If you write a cabal setup script with user hooks, is there a way to tell cabal-install that the setup script itself depends on some package from hackage? (The dependency would be cabal-macosx in my case.) Thanks, Sönke

3 2

Re: [Haskell-cafe] ANN: hledger 0.13
by Simon Michael 08 Dec '10

08 Dec '10

On Dec 8, 2010, at 5:58 AM, Peter Simons wrote: > do you by any chance remember which dependency that was? I wonder, > because I had no trouble compiling hledger 0.13's dependencies on a > standard GHC 6.12.3 system -- only hledger itself fails the "cabal > configure" stage --, so it seems to me like all dependencies work > fine with process 1.0.1.3. Is there something I miss? Hi Peter.. I haven't been able to track it down yet. If I wasn't clear before, hledger-lib and hledger-lib build fine with process-1.0.1.3, but my recollection was that one of hledger-{chart,vty,web} did not. However I might have been outwitted by cabal again. If it turns out we actually can cabal install all five packages with process-1.0.1.3, I'll make a bugfix release.

1 0

LLVM, type-level?
by Lally Singh 08 Dec '10

08 Dec '10

Hey all, I'm generating a structure definition from input, and would like to generate some LLVM code that can use it. I see an 'alloca' function in LLVM.Core that may do the trick, but takes a static type (Ptr a), which I wouldn't have. Is there a dynamic variant? I'm currently generating a TypeDesc Struct type. Also, is everything under LLVM.Core.* private (not LLVM.Core, but LLVM.Core.Util,etc)? I saw from some blog posts that Core.Util has a function for (I think) getting the a function's parameters, but I can't seem to find a way to access it. Is there another way to get the arguments to a function? Thanks for your help, -Lally

2 3

Re: [Haskell-cafe] [Haskell] ANNOUNCE: genprog-0.1
by Alberto G. Corona 08 Dec '10

08 Dec '10

Off topic I was deeply involved in genetic programming in the past (in fact I discovered Haskell on looking for a functional language for genetic programing with better syntax than LISP). But I soon realized that GP was not the holy grial after all. The problem with evolving arbitrary programming code is the fitness landscape<http://www.google.com/search?hl=en&q=fitness+landscape>. Any evolutionary process needs a way to produce small changes that produces small increases or decreases of fitness (parsimony). This is why it is relatively easy to evolve a continuous function towards a desired value. A smal change in a parameter has a small effect in the resulting fitness, so the algoritm can step up trough the smooth fitness landscape upto a local maximum. But programs are non lineal. If I change the expression in a conditional, the flow of the program becomes radically different, so the fitness landscape, instead of a smoth continuous surface is a fractal where there are no way to climb up the mount improbable (Dawkins dixit). http://www.google.com/search?hl=en&q=mount+improbable+dawkins The only way to overcome this is to indentify the smooth parts of the fitness landscape and restrict the exploration to them trough some techniques such is the use of rules, division of the problem in subproblems and ...well any trick programmers use in their ordinary work to restrict and direct the program mutations. It is theoretically possilble to define metalevels of genetic algoritms where rules and strategies are selected by extracting sucessful patterns after evolving a big number of sucessful programs, These metaleves can discover from simple rules such are "if a push is inserted, a pop must be inserted somewhere else (push-pop gene mutation rule), upto the re-discovery of complex rules above mentioned. These rules later would be used to restrict the mutations of the lower levels. Finally the rules could become so accurate that no mutation at the lower level is necessary because the evolved higuer level rules give the solution at the first try. So the genetic algoritms have the potential to design arbitrary complex programs right from scratch, but it may require a few billion years of computing. Anyway this stuff is really interesting and I suspect that the combination of rules and metalevels has some future, at least for helping programmers with intelligent IDEs. 2010/12/8 Kenneth Hoste <kenneth.hoste(a)ugent.be> > Hi Jan, > > Hi Jan, > > On 11/29/2010 12:55 PM, Jan Snajder wrote: > > Dear Haskellers, > > > > I am pleased to announce the release of genprog-0.1, a genetic > > programming library. > > > > (snip) > > Very interesting, and nice job on the code (elegant, well-structured, > well-documented, ...)! > > Genetic programming recently got my attention because one of the bots in > the Google AI contest was built using this technique (see > http://ai-contest.com/forums/viewtopic.php?f=17&t=1136) and it > performed really well (way better than my hand-crafted bot). > > I have a bit of experience with genetic algorithms, on a practical and > pragmatic level. The field of genetic programming is something I hope to > look at and play with in the upcoming months (just for fun). > > I was kind of planning to implement my own genetic programming library > in Haskell as I became familiar with the field, but after diving into > your code it quickly became clear to me you've done a way better job > than I would have. > > I really like the example you provided for evolving an expression that > computes a specified integer value. I plan to start playing with that > and improve the example (faster convergence to a perfect solution, and > also tweaking the current GP config to obtain smaller solutions). > > > A couple of questions (some fairly unrelated to Haskell): > > How hard would it be to extend the current version to support the > evolution of actual Haskell programs? As far as I can tell, the current > version has support for (simple?) self-defined expressions, but this > seems like a long way from supporting Haskell programs with > multi-argument functions that operate on lists, etc., even if you just > limit it to non-monadic Haskell98 code. > > Have you considered playing with dynamic values for the various > parameters that steer the evolution, i.e. population size, > crossover/mutation probabilities, etc.? > One thing I've always wanted to try (but never really got to it) is e.g. > increasing the mutation probability as the evolution seems to be getting > stuck in a (local?) optimum. Also, shrinking the population size if > enough progress is being made could be interesting, to speed up the > evolutionary process. Are you aware of studies that do such a thing? > > Are you planning to actively maintain and extend this library? Are you > using it for research purposes, or did you hack this together just for > fun (if so, nice job!). What do you plan to use it for? > > > Anyway, great job, I hope I'll find the time to play around with this. > > _______________________________________________ > Haskell mailing list > Haskell(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell >

2 1

Location of .cabal folder
by Michael Snoyman 08 Dec '10

08 Dec '10

Hi all, I'm trying to figure out how to determine the location of the .cabal folder. I'm trying to release the code powering the package dependency site[1] as a standalone library/application, but currently I've simply hardcoded the path to my 00-index.tar file. Thanks, Michael [1] http://packdeps.haskellers.com/

2 2

Question: mime-mail and base64 encoding
by Michael Snoyman 08 Dec '10

08 Dec '10

Hi all, I've gotten a request for the mime-mail package that I'd like some input on. Right now, there's the ability to fully specify whether or not to base64-encode each part in a message, but the included simpleMail function defaults to non-encoded parts for both its HTML and plain text alternatives. This has apparently caused some issues where long HTML strings have been word-wrapped at bad locations, causing breakage in the meaning of the markup. The request is to make both the HTML and plain text parts use base64 encoding by default. This *seems* to me to make a lot of sense, since it will ensure that your message arrives exactly as you intended it, and will ensure that any non-ASCII code points don't get killed somewhere along the way. On the other hand, I'm not sure what client support is like for base-64 encoding. Don't we need to leave *some* form of non-encoded data for less sophisticated email clients? Thanks, Michael

5 5

Fwd: second call for papers: LDTA 2011 / ETAPS
by Paul Brauner 07 Dec '10

07 Dec '10

---------- Forwarded message ---------- From: Emilie Balland <emilie.balland(a)inria.fr> Date: Tue, Dec 7, 2010 at 10:35 PM Subject: second call for papers: LDTA 2011 / ETAPS To: "Paul.Brauner" <Paul.Brauner(a)loria.fr> LDTA 2011 Call for Papers and Tool Challenge Submissions 11th International Workshop on Language Descriptions, Tools, and Applications www.ldta.info Saarbrucken, Germany March 26 & 27, 2011 an ETAPS workshop LDTA is an application and tool-oriented workshop focused on grammarware - software based on grammars in some form. Grammarware applications are typically language processing applications and traditional examples include parsers, program analyzers, optimizers and translators. A primary focus of LDTA is grammarware that is generated from high-level grammar-centric specifications and thus submissions on parser generation, attribute grammar systems, term/graph rewriting systems, and other grammar-related meta-programming tools, techniques, and formalisms are encouraged. LDTA is also a forum in which theory is put to the test, in many cases on real-world software engineering challenges. Thus, LDTA also solicits papers on the application of grammarware to areas including, but not limited to, the following: - program analysis, transformation, generation, and verification, - implementation of Domain-Specific Languages, - reverse engineering and re-engineering, - refactoring and other source-to-source transformations, - language definition and language prototyping, and - debugging, profiling, IDE support, and testing. This year LDTA will also be putting theory, as well as techniques and tools, to the test in a new way - in the LDTA Tool Challenge. Tool developers are invited to participate in the Challenge by developing solutions to a range of language processing tasks over a simple but evolving set of imperative programming languages. Tool challenge participants will present highlights of their solution during a special session of the workshop and contribute to a joint paper on the Tool Challenge and proposed solutions to be co-authored by all participants after the workshop. Note that LDTA is a well-established workshop similar to other conferences on (programming) language engineering topics such as SLE and GPCE, but is solely focused on grammarware. Paper Submission ---------------- LDTA solicits papers in the following categories. - research papers: original research results within the scope of LDTA with a clear motivation, description, analysis, and evaluation. - short research papers: new innovative ideas that have not been completely fleshed out. As a workshop, LDTA strongly encourages these types of submissions. - experience report papers: description of the use of a grammarware tool or technique to solve a non-trivial applied problem with an emphasis on the advantages and disadvantages of the chosen approach to the problem. - tool demo papers: discussion of a tool or technique that explains the contributions of the tool and what specifically will be demonstrated. These papers should describe tools and applications that do not fit neatly into the specific problems in the Tool Challenge. Each submission must clearly state in which of these categories it falls and not be published or submitted elsewhere. Papers are to use the standard LaTeX article style and the authblk style for affiliations; a sample of which is provided at www.ldta.info. Research and experience papers are limited to 15 pages, tool demonstration papers are limited to 10 pages, and short papers are limited to 6 pages. The final version of the accepted papers will, pending approval, be published in the ACM Digital Library and will also be made available during the workshop. Please submit your abstract and paper using EasyChair at http://www.easychair.org/conferences/?conf=ldta2011. The authors of each submission are required to give a presentation at LDTA 2011 and tool demonstration paper presentations are intended to include a significant live, interactive demonstration. The authors of the best papers will be invited to write a journal version of their paper which will be separately reviewed and, assuming acceptance, be published in journal form. As in past years this will be done in a special issue of the journal Science of Computer Programming (Elsevier Science). Invited Speaker --------------- Rinus Plasmeijer, Radboud University Nijmegen, The Netherlands Important Dates --------------- Abstract submission: Dec. 15, 2010 Full paper submission: Dec. 22, 2010 Author notification: Feb. 01, 2011 Camera-ready papers due: TBD LDTA Workshop: March 26-27, 2011 LDTA Tool Challenge ------------------- The aim of the LDTA Tool Challenge is to foster a better understanding, among tool developers and tool users, of relative strengths and weaknesses of different language processing tool techniques as well as different implementations and realizations of those techniques. Tool developers are invited to participate in the Tool Challenge and demonstrate their solution to the problems during a special session of LDTA 2011. The problems in the LDTA Tool Challenge Problem Set can be viewed as points in a two dimensional space: one dimension specifying language processing tasks and the second dimension specifying the set of languages to which these tasks are to be applied. Along the task dimension are several traditional language processing tasks such as parsing, pretty printing, semantic analysis, optimization, and code generation. The language dimension is comprised of a simple, but evolving, suite of imperative programming languages. These two dimensions form a problem space in which various techniques and implementations will find problems in which they excel and others in which they find some challenges; no single technique or tool is expected to be optimal for all problems. Thus, this is a challenge and not a competition; no winner is declared. The full description of the problem set can be found in the LDTA Tool Challenge Problem Set document on the LDTA web page at ( http://www.ldta.info ). The Tool Challenge is open to developers of all kinds of grammarware tools and techniques. To participate, tool developers must submit the following by March 5, 2011. Names of participants and the name of their tool or technique. Presentation title and abstract. The short abstract should specify on what aspects of the problem set the tool was applied, where it excelled and where no solution was offered and/or the solution was considered less than optimal. We expect these to be only a few paragraphs in length. This information is used for scheduling purposes only and is not used for evaluation; as all tool developers interested in participating are welcome and will be given an opportunity to present their solution at the workshop. Submission of this information indicates a commitment to attend LDTA and to participate in the workshop. This information will be listed in the program. Authors of submissions that appear to be outside of the scope of LDTA will be contacted to discuss the relevance of their work to the workshop. Of course tool developers who question whether their work falls with the scope of LDTA are encouraged to contact the PC chairs early on for clarification. After the workshop a joint paper will be written by participants and submitted to a journal, most likely Science of Computer Programming. It is separate from the proceedings of the workshop and any special journal issue for the workshop. Program Committee ----------------- Emilie Balland, INRIA, France Anya Helene Bagge, University of Bergen, Norway, Paulo Borba, Federal University of Pernambuco, Brazil John Boyland, University of Wisconsin, USA Claus Brabrand, IT University of Copenhagen, Denmark, (co-chair), brabrand(a)itu.dk Jim Cordy, Queen's University, Canada Kyung-Goo Doh, Hanyang University, Ansan, South Korea Giorgios Robert Economopoulos, University of Southampton, UK Laurie Hendren, McGill University, Canada Nigel Horspool, University of Victoria, Canada Roberto Ierusalimschy, Pontifícia Universidade Católica do Rio de Janeiro, Brazil Johan Jeuring, Utrecht University, The Netherlands Shane Markstrum, Bucknell University, USA Sukyoung Ryu, Korea Advanced Institute of Science and Technology, Korea Joao Saraiva, Universidade do Minho, Portugal Sylvain Schmitz, Ecole Normale Superieure de Cachan, France Sibylle Schupp, Hamburg University of Technology, Germany Eli Tilevich, Virginia Tech, USA Eric Van Wyk, University of Minnesota, USA (co-chair), evw(a)cs.umn.edu Eelco Visser, Delft University of Technology, The Netherlands Organizing Committee -------------------- Emilie Balland, INRIA, France Giorgios Robert Economopoulos, University of Southampton, UK

1 0

An Haskell implementation of a sweep line algorithm for the detection of segments intersection
by vince vegga 07 Dec '10

07 Dec '10

Hi, Here is my Haskell implementation of the Shamos and Hoey algorithm for detecting segments intersection in the plane: http://neonstorm242.blogspot.com/2010/12/sweep-line-algorithm-for-detection… I'm new to Haskell, so any useful comments will be appreciated. - Eran

3 2