- Haskell - Haskell.org

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

GTTSE 2009 --- First call for participation (06-11 July 2009)
by João Saraiva 16 Jan '09

16 Jan '09

GTTSE 2009, 06-11 July, 2009, Braga, Portugal 3rd International Summer School on Generative and Transformational Techniques in Software Engineering http://gttse.wikidot.com/ SCOPE AND FORMAT The biannual, week-long GTTSE summer school brings together PhD students, lecturers, as well as researchers and practitioners who are interested in the generation and the transformation of programs, data, software models, data models, metamodels, documentation, and entire software systems. The GTTSE school draws from several areas of the broad software engineering and programming language communities, in particular: software reverse and re-engineering, model-driven software development, program calculation, generic language technology, generative programming, aspect-oriented programming, and compiler construction. The GTTSE school presents the state of the art in automated software engineering and software language engineering: foundations, methods, tools, and case studies. The school's scientific program consists of three modules: 8 full tutorials (see below for a list of speakers and topics), 8 short tutorials (see the website for this part; under construction), and a half day-long participants' workshop. Each of the (8) full tutorials takes 3 hours of plenary time of GTTSE's week-long schedule. These tutorials are given by "veterans" of the field. Each of the (8) short(er) tutorials takes 20 mins of plenary time and approximately 90 mins of "parallel" time (with typically 2 sessions in parallel). These tutorials are (also) by invitation only. Most if not all tutorials will be complemented by articles in the proceedings of the school. The participants' workshop features presentations that were selected among the proposals submitted by the participants (who are typically PhD students). The idea is here to provide committed junior researchers with a slot to present their relevant research and to receive highly qualified feedback from the senior researchers at the school. This time, GTTSE features an award, sponsored by SIG (The Software Improvement Group), to be given to the best presenter at the participants' workshop. After the school, all participants of the school can submit an article for peer review to the post-proceedings. In the past, about 25% of these submissions were selected by the scientific committee to be included in the post-proceedings. All material presented at the school will be collected in informal proceedings to be handed out solely to the participants. Formal and public post-proceedings will be compiled after the summer school where all contributions are subjected to reviewing. Subject to Springer's approval, the post-proceedings of the school will be published in a volume of the Lecture Notes in Computer Science series of Springer-Verlag. The post-proceedings of the previous two instances of the summer school (2005 and 2007) were published as LNCS volumes 4143 and 5235. FULL TUTORIALS * Software Product Line Refactoring Paulo Borba, Universidade Federal de Pernambuco, Recife, Brazil * The TXL Source Transformation Cookbook James R. Cordy, Queen's University, Kingston, Canada * Chasing Diagrams in the Mapping Forests of Model Transformations Zinovy Diskin, University of Waterloo and Univ. of Toronto, Canada * Generating Language Tools with JastAdd Görel Hedin, Lund Institute of Technology, Sweden. * Model Driven Language Engineering with Kermeta Jean-Marc Jézéquel, IRISA, Rennes, France * Rascal: Meta-programming Made Easy Paul Klint, CWI and Universiteit van Amsterdam, Netherlands * Sourcerer: Slicing and Dicing Large Amounts of Open Source Code Cristina Videira Lopes, University of California, Irvine, USA * Theory & Practice of Modeling Language Design for Model-Based Engineering Bran Selic, Malina Software Corp., Canada ORGANIZATION COMMITTEE * João M. Fernandes (Program Co-Chair), Universidade do Minho, Portugal * Ralf Lämmel (Program Co-Chair), Universität Koblenz-Landau, Germany * João Saraiva, Universidade do Minho, Portugal * Joost Visser, Software Improvement Group, The Netherlands ADDITIONAL INFORMATION For additional information on the program, venue, and other details of the summer school, please consult the web page: http://gttse.wikidot.com/ Note that registration for the summer school will open in February 2009. Before that time, those who wish to be notified personally when registration opens are welcome to send an expression of interest to gttse2009 AT list.uni-koblenz.de

1 0

IFL 2009: Call for Papers
by IFL 2009 15 Jan '09

15 Jan '09

Call for Papers IFL 2009 Seton Hall University SOUTH ORANGE, NJ, USA http://tltc.shu.edu/blogs/projects/IFL2009/ The 21st IFL symposium, IFL 2009, will be held for the first time in the USA. The hosting institution is Seton Hall University in South Orange, NJ, USA and the symposium dates are September 23-25, 2009. It is our goal to make IFL a regular event held in the USA. The goal of the IFL symposia is to bring together researchers actively engaged in the implementation and application of functional and function-based programming languages. IFL 2009 will be a venue for researchers to present and discuss new ideas and concepts, work in progress, and publication-ripe results related to the implementation and application of functional languages and function-based programming. Following the IFL tradition, IFL 2009 will use a post-symposium review process to produce a formal proceedings which we expect to be published by Springer in the Lecture Notes in Computer Science series. All participants in IFL 2009 are invited to submit either a draft paper or and extended abstract describing work to be presented at the symposium. These submissions will be screened by the program committee chair to make sure they are within the scope of IFL and will appear in the draft proceedings distributed at the symposium. Submissions appearing in the draft proceedings are not peer-reviewed publications. After the symposium, authors will be given the opportunity to incorporate the feedback from discussions at the symposium and will be invited to submit a revised full arcticle for the formal review process. These revised submissions will be reviewed by the program committee using prevailing academic standards to select the best articles that will appear in the formal proceedings. TOPICS IFL welcomes submissions describing practical and theoretical as well as submissions describing applications and tools. If you are not sure if your work is appropriate for IFL 2009, please contact the PC chair at ifl2009(a)shu.edu. Topics of interest include, but are not limited to: language concepts type checking contracts compilation techniques staged compilation runtime function specialization runtime code generation partial evaluation (abstract) interpretation generic programming techniques automatic program generation array processing concurrent/parallel programming concurrent/parallel program execution functional programming and embedded systems functional programming and web applications functional programming and security novel memory management techniques runtime profiling and performance measurements debugging and tracing virtual/abstract machine architectures validation and verification of functional programs tools and programming techniques PAPER SUBMISSIONS Prospective authors are encouraged to submit papers or extended abstracts to be published in the draft proceedings and to present them at the symposium. All contributions must be written in English, conform to the Springer-Verlag LNCS series format and not exceed 16 pages. The draft proceedings will appear as a technical report of the Department of Mathematics and Computer Science of Seton Hall University. IMPORTANT DATES Registration deadline August 15, 2009 Presentation submission deadline August 15, 2009 IFL 2009 Symposium September 23-25, 2009 Submission for review process deadline November 1, 2009 Notification Accept/Reject December 22, 2009 Camera ready version January 15, 2010 PROGRAM COMMITTEE Peter Achten University of Nijmegen, The Netherlands Jost Berthold Philipps-Universität Marburg, Germany Andrew Butterfield University of Dublin, Ireland Robby Findler Northwestern University, USA Kathleen Fisher AT&T Research, USA Cormac Flanagan University of California at Santa Cruz, USA Matthew Flatt University of Utah, USA Matthew Fluet Toyota Technological Institute at Chicago, USA Daniel Friedman Indiana University, USA Andy Gill University of Kansas, USA Clemens Grelck University of Amsterdam/Hertfordshire, The Netherlands/UK Jurriaan Hage Utrecht University, The Netherlands Ralf Hinze Oxford University, UK Paul Hudak Yale University, USA John Hughes Chalmers University of Technology, Sweden Patricia Johann University of Strathclyde, UK Yukiyoshi Kameyama University of Tsukuba, Japan Marco T. Morazán (Chair) Seton Hall University, USA Rex Page University of Oklahoma, USA Fernando Rubio Universidad Complutense de Madrid, Spain Sven-Bodo Scholz University of Hertfordshire, UK Manuel Serrano INRIA Sophia-Antipolis, France Chung-chieh Shan Rutgers University, USA David Walker Princeton University, USA Viktória Zsók Eötvös Loránd University, Hungary PETER LANDIN PRIZE The Peter Landin Prize is awarded to the best paper presented at the symposium every year. The honored article is selected by the program committee based on the submissions received for the formal review process. The prize carries a cash award equivalent to 150 euros.

1 0

writing a shell in Haskell
by nr＠cs.tufts.edu 14 Jan '09

14 Jan '09

As a demo for the first day of class, I thought I'd try to write a simple shell in Haskell, in part so I can show algebraic data types and monads on the first day, but also to convince potential skeptics that functional languages can do systemsy things. All the usual functional stuff is going very nicely, but I don't seem to be able to get my hands on pipe(2) at all, and the language in the documentation for fork() and exec() might as well read Here Be Dragons. Looking for ways to fork, it appears that I have a wealth of abstractions to choose from: System.Process System.Posix.Process IO The 'new' System.Process on the web appears to have some very nice facilities, although it is still not strong enough to do what I want cleanly (capture the output from a command that might be internal or might require me to fork an external process). However, the question is moot because my system seems to have a consistent set of libraries coordinate with the release of GHC 6.8, and I don't know how to put together a consistent set of 'new' libraries to go with 6.10. (I don't even know if such a set exists.) Please advise me: should I give up the idea of writing a shell using GHC and the classic Unix system calls fork/exec/close/pipe? Or if it is possible after all, in what module should I be looking for the proper abstractions? Norman

2 1

Help : data & concurrent packages
by bft 13 Jan '09

13 Jan '09

Hi ! Can someone tell me where to download the *data* and *concurrent *packages. I need them to build FranTk1.1 package ( http://www.dcs.gla.ac.uk/~meurig/FranTk/news.html) Thanks in advance! BFT frantk.conf file : Package {name = "FranTk", import_dirs = ["/local/www.people/personal/meurig/haskell/built/frantk/imports"], source_dirs = [], library_dirs = ["/local/www.people/personal/meurig/haskell/built/frantk"], hs_libraries = ["HSFranTk"], extra_libraries = ["tcl8.3","tk8.3"], include_dirs = [], c_includes = [], *package_deps = [ "concurrent", "data" ],* extra_ghc_opts = [ "-fvia-C", "-fallow-overlapping-instances", "-fallow-undecidable-instances" ], extra_cc_opts = [], extra_ld_opts = ["-lncurses"] }

2 1