- Haskell - Haskell.org

ICFP2008 Call for Papers
by Matthew Fluet (ICFP Publicity Chair) 21 Jan '08

21 Jan '08

Call for Papers ICFP 2008: International Conference on Functional Programming Victoria, BC, Canada, 22-24 September 2008 http://www.icfpconference.org/icfp2008 Submission deadline: 2 April 2008 ICFP 2008 seeks original papers on the art and science of functional programming. Submissions are invited on all topics from principles to practice, from foundations to features, from abstraction to application. The scope includes all languages that encourage functional programming, including both purely applicative and imperative languages, as well as languages with objects and concurrency. Particular topics of interest include * Applications and Domain-Specific Languages: systems programming; scientific and numerical computing; symbolic computing; artificial intelligence; databases; graphical user interfaces; multimedia programming; scripting; system administration; distributed-systems and web programming; XML processing; security * Foundations: formal semantics; lambda calculus; type theory; monads; continuations; control; state; effects * Design: algorithms and data structures; modules; type systems; concurrency and distribution; components and composition; relations to object-oriented or logic programming * Implementation: abstract machines; compile-time and run-time optimization; just-in-time compilers; memory management; parallel hardware; interfaces to foreign functions, services, components or low-level machine resources * Transformation and Analysis: abstract interpretation; partial evaluation; program transformation * Software-development Techniques: design patterns; specification; verification; validation; debugging; test generation; tracing; profiling * Functional Pearls: elegant, instructive, and fun essays on functional programming * Practice and Experience: novel results drawn from experience in education or industry. Experience Reports are also solicited, which are short papers (2-4 pages) that provide evidence that functional programming really works or describe obstacles that have kept it from working in a particular application. Functional Pearls and Experience Reports are separate categories of papers that need not report original research results and must be marked as such at the time of submission. Detailed guidelines on both categories are below. What's different this year? ~~~~~~~~~~~~~~~~~~~~~~~~~~~ * No double blind reviewing. Instructions for authors ~~~~~~~~~~~~~~~~~~~~~~~~ By Wednesday, 2 April 2008, 09:00 AM Apia time, submit an abstract of at most 300 words and a full paper of at most 12 pages (4 pages for an Experience Report), including bibliography and figures. The deadline will be strictly enforced and papers not meeting the page limits are summarily rejected. Authors have the option to attach supplementary material to a submission, on the understanding that reviewers are not expected to read it. A submission will be evaluated according to its relevance, correctness, significance, originality, and clarity. It should explain its contributions in both general and technical terms, clearly identifying what has been accomplished, explaining why it is significant, and comparing it with previous work. The technical content should be accessible to a broad audience. Each submission must adhere to SIGPLAN's republication policy, as explained on the web. Violation risks summary rejection of the offending submission. Proceedings will be published by ACM Press. Authors of accepted submissions are expected to transfer the copyright to ACM. They may have the option to have their presentation videotaped and published along with the conference proceedings in the ACM Digital Library. Video recordings will only be released at the consent of the presenter, which is expressed by signing an additional copyright release/permission form. Formatting ~~~~~~~~~~ Submissions must be in PDF format printable in black and white on US Letter sized paper and interpretable by Ghostscript. If this requirement is a hardship, make contact with the program chair at least one week before the deadline. ICFP proceedings are printed in black and white. It is permissible to include color in a submission, but you risk annoying reviewers who will have to decide if your final paper will be understandable without it. Papers must adhere to the standard ACM conference format: two columns, nine-point font on a ten-point baseline, with columns 20pc (3.33in) wide and 54pc (9in) tall, with a column gutter of 2pc (0.33in). A suitable document template for LaTeX is available from SIGPLAN. Submission ~~~~~~~~~~ Submissions will be accepted electronically; the submission page is not yet ready. The deadline is set at Samoan time, so if your submission is in by 09:00 AM Wednesday according to your local time, wherever you are, the submission will be on time. The world clock (http://www.timeanddate.com/worldclock/fixedtime.html?month=4&day=2&year=200…) can give you the equivalent in your local time, e.g.,1:00 PM Wednesday in Seattle, 4:00 PM Wednesday in New York, and 9:00 PM Wednesday in London. Citation ~~~~~~~~ We recommend (but do not require) that you put your citations into author-date form. This procedure makes your paper easier to review. For example, if you cite a result on testing as ``(Claessen and Hughes 2000)'', many reviewers will recognize the result instantly. On the other hand, if you cite it as ``[4]'', even the best-informed reviewer has to page through your paper to find the reference. By using author-date form, you enable a knowledgeable reviewer to focus on content, not arbitrary numbering of references. LaTeX users can simply use the natbib package along with the plainnat bibliography style. Author response ~~~~~~~~~~~~~~~ You will have a 48-hour period, starting at 09:00 on 21 May 2008 Apia time, to read and respond to reviews. Special categories of papers ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In addition to research papers, ICFP solicits two kinds of papers that do not require original research contributions: Functional Pearls, which are full papers, and Experience Reports, which are limited to four pages. Authors submitting such papers may wish to consider the following advice. Functional Pearls ~~~~~~~~~~~~~~~~~ A Functional Pearl is an elegant essay about something related to functional programming. It might offer: * a new and thought-provoking way of looking at an old idea * an instructive example of program calculation or proof * a nifty presentation of an old or new data structure * an interesting application of functional programming techniques * a novel use or exposition of functional programming in the classroom Functional Pearls are not restricted to the above varieties, however. While pearls often demonstrate an idea through the development of a short program, there is no requirement or expectation that they do so. Thus, they encompass the notions of theoretical and educational pearls. A pearl should be concise, instructive, and entertaining. Your pearl is likely to be rejected if your readers get bored, if the material gets too complicated, if too much specialized knowledge is needed, or if the writing is inelegant. The key to writing a good pearl is polishing. Some advice from Richard Bird: * Throw away the rule book for writing research papers. * Get in quick; get out quick. * Be self-contained; don't go deep into related work, with lengthy references. * You are telling a story, so some element of surprise is welcome. * Above all, be engaging. * Give a talk on the pearl to non-specialists, your students, or your department. If you changed the order of presentation for the talk, consider using the new order in the next draft. * Put the pearl away for a while, then take it out and polish it again. Experience Reports ~~~~~~~~~~~~~~~~~~ ICFP has long solicited submissions on the practice and experience of functional programming. But reports of experience are inherently different from research papers, and when judged by the criteria of scientific merit, novelty, or research contribution, they have not competed well against traditional ICFP submissions. Yet we believe that the functional-programming community would benefit from being able to draw on and cite the experience of others. For this reason, we have introduced the ICFP Experience Report. Unlike a normal ICFP paper, the purpose of an Experience Report is not to add to the body of knowledge of the functional-programming community. Rather, the purpose of an Experience Report is to help create a body of published, refereed, citable evidence that functional programming really works---or to describe what obstacles prevent it from working. An Experience Report is distinguished from a normal ICFP paper by its title, by its length, and by the criteria used to evaluate it. * Both in the proceedings and in any citations, the title of each accepted Experience Report must begin with the words ``Experience Report'' followed by a colon. * An Experience Report is at most 4 pages long. Each accepted Experience Report will be presented at the conference, but depending on the number of Experience Reports and regular papers accepted, authors of Experience reports may be asked to give shorter talks. * Because the purpose of Experience Reports is to enable our community to accumulate a body of evidence about the efficacy of functional programming, an acceptable Experience Report need not present novel results or conclusions. It is sufficient if the Report states a clear thesis and provides supporting evidence. The thesis must be relevant to ICFP, but it need not be novel. The program committee will accept or reject Experience Reports based on whether they judge the evidence to be convincing. Anecdotal evidence will be acceptable provided it is well argued and the author explains what efforts were made to gather as much evidence as possible. Typically, more convincing evidence is obtained from papers which show how functional programming was used than from papers which only say that functional programming was used. The most convincing evidence often includes comparisons of situations before and after the introduction or discontinuation of functional programming. Evidence drawn from a single person's experience may be sufficient, but more weight will be given to evidence drawn from the experience of groups of people. Possible topics for an Experience Report include, but are not limited to * Insights gained from real-world projects using functional programming * Comparison of functional programming with conventional programming in the context of an industrial project or a university curriculum * Project-management, business, or legal issues encountered when using functional programming in a real-world project * Curricular issues encountered when using functional programming in education * Real-world constraints that created special challenges for an implementation of a functional language or for functional programming in general An Experience Report should be short and to the point: make a claim about how well functional programming worked on your project and why, and produce evidence to substantiate your claim. If functional programming worked for you in the same ways it has worked for others, you need only to summarize the results---the main part of your paper should discuss how well it worked and in what context. Most readers will not want to know all the details of your project and its implementation, but please characterize your project and its context well enough so that readers can judge to what degree your experience is relevant to their own projects. Be especially careful to highlight any unusual aspects of your project. Also keep in mind that specifics about your project are more valuable than generalities about functional programming; for example, it is more valuable to say that your team delivered its software a month ahead of schedule than it is to say that functional programming made your team more productive. If your paper not only describes experience but also presents new technical results, or if your experience refutes cherished beliefs of the functional-programming community, you may be better off submitting it as a full paper, which will be judged by the usual criteria of novelty, originality, and relevance. If you are unsure in which category to submit, the program chair will be happy to help you decide. Other information ~~~~~~~~~~~~~~~~~ Conference Chair ~~~~~~~~~~~~~~~~ James Hook (Portland State University) Program Chair ~~~~~~~~~~~~~ Peter Thiemann Albert-Ludwigs-Universität Georges-Köhler-Allee 079 79110 Freiburg, Germany Email: icfp08(a)informatik.uni-freiburg.de Phone: +49 761 203 8051 Fax: +49 761 203 8052 Mail sent to the address above is filtered for spam. If you send mail and do not receive a prompt response, particularly if the deadline is looming, feel free to telephone and reverse the charges. Program Committee ~~~~~~~~~~~~~~~~~ Derek Dreyer (Max Planck Institute for Software Systems) Robert Ennals (Intel Research) Kathleen Fisher (AT&T Research) Zhenjiang Hu (University of Tokyo) Frank Huch (University of Kiel) Andrew Kennedy (Microsoft Research) Kevin Millikin (Google) Henrik Nilsson (University of Nottingham) Chris Okasaki (United States Military Academy) Brigitte Pientka (McGill University) Rinus Plasmeijer (University of Nijmegen) Alan Schmitt (INRIA) Chung-chieh Shan (Rutgers) Mitchell Wand (Northeastern University) Stephen Weeks (Jane Street Capital) Important Dates (at 09:00 Apia time, UTC-11) ~~~~~~~~~~~~~~~ Submission: 2 April 2008 Author response: 21 May 2008 Notification: 16 June 2008 Final papers due: 7 July 2008 ICFP 2008 Web Site ~~~~~~~~~~~~~~~~~~ http://www.icfpconference.org/icfp2008/ Special Journal Issue ~~~~~~~~~~~~~~~~~~~~~ There will be a special journal issue with papers from ICFP 2008. The program committee will invite the authors of select accepted papers to submit a journal version to this issue.

1 0

Re: [Haskell] Ancient, but still having fun
by Thorkil Naur 19 Jan '08

19 Jan '08

Young Man, On Saturday 19 January 2008 00:07, Simon Peyton-Jones wrote: > Friends, > > It's Friday 18 January 2008, which makes it my 50th birthday. Congratulations! > ... > Ancient or not, I'm still having a terrific time in this community. When I first became addicted to functional programming, as a result of Arthur Norman's 4-lecture course, and David Turner's SK-combinator papers, I never dreamt of what a wild and fascinating ride it would turn out to be. > > Thank you all! > > Simon > ... Rest assured that there are many of us having a terrific time too. And not least because of your in many ways fabulous presence. Thank you Simon. Best regards Thorkil

1 0

Ancient, but still having fun
by Simon Peyton-Jones 19 Jan '08

19 Jan '08

Friends, It's Friday 18 January 2008, which makes it my 50th birthday. I spent part of the day happily polishing Geoff Mainland's patch that adds quasi-quoting to GHC, and committing it to the GHC HEAD. I'm happy to say that this is increasingly the story: more and more people are getting involved with making GHC into a better compiler. Better still, many more people are involved in making Haskell a successful and increasingly-influential language. I'm boggled by the sheer number of libraries that are announced these days in each issue of the Haskell Weekly (sic) News. And for the first time I'm getting invitations out of the blue to speak about Haskell at mainstream professional-developer conferences. Suddenly Haskell is cool. Ancient or not, I'm still having a terrific time in this community. When I first became addicted to functional programming, as a result of Arthur Norman's 4-lecture course, and David Turner's SK-combinator papers, I never dreamt of what a wild and fascinating ride it would turn out to be. Thank you all! Simon

1 0

Re: [Haskell-cafe] ANNOUNCE: HStringTemplate -- An Elegant, Functional, Nifty Templating Engine for Haskell
by Sterling Clover 18 Jan '08

18 Jan '08

Graham, I'm sort of playing fast and loose with referential transparency here, as I actually am with stringTemplateFileGroup as well. They both use unsafeIO to do what they want, and in corner cases could give silly, though not dangerous results (i.e., in the sense of being hazardous to your program, these calls are substantially less worrisome than head). stringTemplateFileGroup could conceivably be in IO, if it was strict in reading all the files in the directory it was passed, but cacheSTGroup would force every access to a group to take place in IO, which would make the library somewhat of a pain to work with. My semi-justification for this is that its referentially- transparent-enough for most use cases, in that just about the only thing one would be doing with a StringTemplate result would be outputting it again in some form anyway. In my experience, being able to "hot-edit" templates for a live app is a key benefit of a templating system, and forcing everything into IO to get that seems like an undue burden on end-users. On the other hand, I'm also open to implementing an IO API that's safe and renaming the current functions to something somewhat scarier, or moving both them and their IO equivs to distinct modules so that end users could choose which to import. A number of options seem reasonable here. --Sterl. (btw, I fixed the typo you emailed me about in the repo, and also made a few other changes I documented at http:// fmapfixreturn.wordpress.com/) On Jan 16, 2008, at 8:19 PM, Graham Fawcett wrote: > On Jan 14, 2008 2:47 AM, Sterling Clover <s.clover(a)gmail.com> wrote: >> HStringTemplate is a port of Terrence Parr's lovely StringTemplate >> (http://www.stringtemplate.org) engine to Haskell. > > This is very cool. > > Your docs describe a function, cacheSTGroup: > > cacheSTGroup :: Int -> STGen a -> STGen a > Given an integral amount of seconds and a group, returns a group > cached for that span of time. Does not cache "misses." > > How does this work without breaking referential transparency? > Shouldn't it be in the IO monad if it is time-dependent? > > Graham

1 0

PAPP 2008 - Deadline Extension
by Clemens Grelck 17 Jan '08

17 Jan '08

*** DEADLINE EXTENSION *** Papers now due: January 20, 2008 ===================================================== PAPP 2008 Fifth International Workshop on aPpplications of declArative and object-oriented Parallel Programming part of The International Conference on Computational Science June 23-25, 2008, Krakow, Poland http://f.loulergue.free.fr/PAPP2008 ===================================================== AIMS AND SCOPE Computational Science applications are more and more complex to develop and require more and more computing power. Parallel and grid computing are solutions to the increasing need for computing power. High level languages offer a high degree of abstraction which ease the development of complex systems. Moreover, being based on formal semantics, it is possible to certify the correctness of critical parts of the applications. Algorithmic skeletons, parallel extensions of functional languages such as Haskell and ML, parallel logic and constraint programming, parallel execution of declarative programs such as SQL queries, genericity and meta-programming in object-oriented languages, etc. have produced methods and tools that improve the price/performance ratio of parallel software, and broaden the range of target applications. The PAPP workshop focuses on practical aspects of high-level parallel programming: design, implementation and optimization of high-level programming languages, libraries, middlewares and tools (performance predictors working on high-level parallel/grid source code, visualisations of abstract behaviour, automatic hotspot detectors, high-level GRID resource managers, compilers, automatic generators, etc.), applications in all fields of computational science, benchmarks and experiments. Research on high-level grid programming is particularly relevant as well as domain specific parallel software. The aim of all these languages and tools is to improve and ease the development of applications. Thus the Fifth PAPP workshop focuses on applications. The PAPP workshop is aimed both at researchers involved in the development of high level approaches for parallel and grid computing and computational science researchers who are potential users of these languages and tools. Topics We welcome submission of original, unpublished papers in English on topics including: * applications in all fields of high-performance computing and visualisation (using high-level tools) * high-level models (CGM, BSP, MPM, LogP, etc.) and tools for parallel and grid computing * high-level parallel language design, implementation and optimisation * modular, object-oriented, functional, logic, constraint programming for parallel, distributed and grid computing systems * algorithmic skeletons, patterns and high-level parallel libraries * generative (e.g. template-based) programming with algorithmic skeletons, patterns and high-level parallel libraries * benchmarks and experiments using such languages and tools All the contributions should illustrate the proposed techniques on a significant application. PAPER SUBMISSION AND PUBLICATION Prospective authors are invited to submit full papers in English presenting original research. Submitted papers must be unpublished and not submitted for publication elsewhere. Papers will go through a rigorous reviewing process. Each paper will be reviewed by at least three referees. The accepted papers will be published in the Springer-Verlag Lecture Notes in Computer Science (LNCS) series, as part of the ICCS proceedings. Submission must be done through the ICCS website: http://www.iccs-meeting.org/iccs2008/papers/upload.php. We invite you to submit a full paper of 8 pages formatted according to the rules of LNCS, describing new and original results, no later than January 20, 2008. Submission implies the willingness of at least one of the authors to register and present the paper. An early email to papp at free.fr with your intention to submit a paper would be greatly appreciated (especially if you have doubts about the relevance of your paper). Accepted papers Accepted papers should be presented at the workshop. Authors will be invited to submit extended and revised versions of their papers. Accepted manuscripts will be published in a special issue of Scalable Computing: Practice and Experience. Important Dates * January 20, 2008 - Full paper due * March 1, 2008 - Notification * March 15, 2008 - Camera-ready paper due * September 15, 2008 - Journal version due PROGRAMME COMMITTEE * Marco Aldinucci (University of Pisa, Italy) * Anne Benoit (ENS Lyon, France) * Umit V Catalyurek (The Ohio State University, USA) * Manuel Chakravarty (University of New South Wales, Australia) * Frédéric Gava (University Paris XII Val de Marne, France) * Alexandros Gerbessiotis (NJIT, USA) * Clemens Grelck (University of Luebeck, Germany) * Iwasaki Hideya (The University of Electro-communications, Japan) * Paul H J Kelly (Imperial College London, UK) * Christoph Kessler (Linköpings Universitet, Sweden) * Rita Loogen (University of Marburg, Germany) * Frédéric Loulergue (The University of Orléans, France) * Kiminori Matsuzaki (The University of Tokyo, Japan) * Samuel Midkiff (Purdue University, USA) * Susanna Pelagatti (University of Pisa, Italy) * Bruno Raffin (INRIA, France) * Casiano Rodriguez Leon (University La Laguna, Spain) ORGANIZERS * Dr. Anne BENOIT Laboratoire d'Informatique du Parallelisme Ecole Normale Supérieure de Lyon 46 Allée d'Italie 69364 Lyon Cedex 07 - France * Pr. Frederic LOULERGUE Laboratoire d'Informatique Fondamentale d'Orléans Université d'Orléans Batiment IIIA - Rue Léonard de Vinci - BP6759 45067 Orléans Cedex 2 - France

1 0

Should the following program be accepted by ghc?
by Bruno Oliveira 17 Jan '08

17 Jan '08

Hello, I have been playing with ghc6.8.1 and type families and the following program is accepted without any type-checking error: > data a :=: b where > Eq :: a :=: a > decomp :: f a :=: f b -> a :=: b > decomp Eq = Eq However, I find this odd because if you interpret "f" as a function and ":=:" as equality, then this is saying that if f a = f b then a = b but clearly this does not hold in general. For example: f 1 = 0 f 2 = 0 So, we have that "f 1 = f 2" but this does not imply that "1 = 2". Ofcourse, that before ghc6.8, we add no type-level functions so maybe it was ok to consider the program above. However, with open type functions the following program is problematic and crashes ghc in style: > type family K a > c :: K a :=: K b -> a :=: b > c Eq = Eq with the following error message: ghc-6.8.1: panic! (the 'impossible' happened) (GHC version 6.8.1 for i386-apple-darwin): Coercion.splitCoercionKindOf base:GHC.Prim.sym{(w) tc 34v} co_aoW{tv} [tv] <pred>main:Bug.K{tc rom} a{tv aoS} [sk] ~ main:Bug.K{tc rom} b{tv aoT} [sk] It seems to me that the "decomp" should be rejected in the first place? Maybe the fact that "decomp" is accepted is a bug in the compiler? Any comments? Cheers, Bruno Oliveira

8 8

ANN: 16 updated packages: HDBC, ConfigFile, MissingH, and more
by John Goerzen 16 Jan '08

16 Jan '08

Hi folks, I've made new releases of a number of my packages. Rather than flood the list with individual announcements, I've consolidated them here. Many of these packages have only GHC 6.8 compatibility updates, but a fair number also have more significant changes. Detailed changes lists are below. These packages have been updated: anydbm ConfigFile darcs-buildpackage dfsbuild HDBC HDBC-odbc HDBC-postgresql HDBC-sqlite3 hg-buildpackage HSH hslogger LDAP ListLike magic MissingH srcinst These have not yet been updated: arch2darcs (no longer maintained) gtkrsync (pending newer GTK upload in Debian) hpodder (pending newer haxml upload in Debian) missingpy (pending available time) All packages have been uploaded to: * Hackage * Debian sid * Their software.complete.org site, if any * Their darcs or Mercurial repository anydbm 1.0.5 ------------ A generic interface library for DBM-like databases Update for GHC 6.8.x. Homepage: http://software.complete.org/anydbm ConfigFile 1.0.4 ---------------- Library for reading/writing human-editable configuration files Updated for GHC 6.8 compatibility and the new MissingH Homepage: http://software.complete.org/configfile darcs-buildpackage 0.5.12 ------------------------- Tools for building Debian packages with source stored in Darcs Updated for GHC 6.8 compatibility and the new MissingH Homepages: Darcs repo: http://darcs.complete.org/darcs-buildpackage Debian: http://packages.qa.debian.org/darcs-buildpackage dfsbuild 1.0.2 -------------- Tool for building Debian From Scratch bootable ISO images * Update for GHC 6.8.x Homepage: http://people.debian.org/~jgoerzen/dfs HDBC 1.1.4 ---------- Haskell DataBase Connectivity, generic RDBMS access * Update cabal for GHC 6.8 thanks to Paulo Tanimoto Homepage: http://software.complete.org/hdbc HDBC-odbc 1.1.4.0 ----------------- HDBC driver for ODBC connectivity * Updates for GHC 6.8 thanks to Bjorn Bringert and John Goerzen Homepage: http://software.complete.org/hdbc-odbc HDBC-postgresql 1.1.4.0 ----------------------- HDBC driver for PostgreSQL * Make sure Hackage tarball gets all files in package * Update for GHC 6.8 thanks to Duncan Coutts * Now use pg_config to find PostgreSQL library locations automatically thanks to Duncan Coutts Homepage: http://software.complete.org/hdbc-postgresql HDBC-sqlite3 1.1.4.0 -------------------- HDBC driver for Sqlite v3 * Cabal updates for GHC 6.8 thanks to Duncan Coutts and Paulo Tanimoto * Allow statements to remain prepared after execution has finished thanks to Toby Allsopp Homepage: http://software.complete.org/hdbc-sqlite3 hg-buildpackage 1.0.4 --------------------- Tools for building Debian packages with source in Mercurial Updates for compatibility with GHC 6.8, newest MissingH and HSH Homepages: Mercurial repo: http://hg.complete.org/hg-buildpackage Hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hg-buildpackage-… Debian: http://packages.debian.org/hg-buildpackage [ no trac instance ] HSH 1.2.5 --------- Library for easy shell-like scripting in Haskell * Clean ups and doc updates [jgoerzen] * Update for newer MissingH [jgoerzen] * Update .cabal for GHC 6.8 thanks to gwern0 * Various cleanups and reorgs thanks to gwern0 * New wcW (wc word count) in ShellEquivs thanks to gwern0 Homepage: http://software.complete.org/hsh hslogger 1.0.4 -------------- Library providing logging infrastructure * Updated for GHC 6.8 compatibility * Removed Setup.hs hooks in favor of Cabal configurations * Thanks to patches from Shae Erisson and Spencer Janssen contributing to the GHC 6.8 compatibility. Homepage: http://software.complete.org/hslogger LDAP 0.6.3 ---------- Haskell bindings for LDAP * GHC 6.8.x compatibility fixes * Updated homepage in .cabal file Homepage: http://software.complete.org/ldap-haskell ListLike 1.0.1 -------------- Library providing generic operations over list-like types * GHC 6.8.x compatibility fixes to .cabal file Homepage: http://software.complete.org/listlike magic 1.0.7 ----------- Binding for Magic, the file type identification library * Updates for GHC 6.8 compatibility Homepages: Hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/magic-1.0.7 Darcs tree: http://darcs.complete.org/magic-haskell MissingH 1.0.0 -------------- Library of many useful functions * Poof, this is 1.0! * GHC 6.8 compatibility fixes: + GHC 6.8 introduced Data.String. Renamed the MissingH Data.String to Data.String.Utils + doc string tweaks for new haddock + cabal and build system updates thanks to Duncan Coutts * -Wall compatibility improvements throughout. Patches from gwern0 * Data.List.Utils.uniq efficiency improved thanks to Martin Huschenbett * New Data.Tuple.Utils from Neil Mitchell Homepage: http://software.complete.org/missingh srcinst 0.8.10 -------------- Tool to install Debian packages using only source, Gentoo-style * Updated for GHC 6.8.x and new MissingH

1 0

ANN: GLFW-0.3 released
by Paul L 16 Jan '08

16 Jan '08

GLFW is a Haskell module for GLFW OpenGL framework. It provides an alternative to GLUT for OpenGL based Haskell programs. The current 0.3 version is for download from hackageDB at: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/GLFW-0.3 Same as the previous 0.2 version it requires Cabal 1.2 or later for installation (which comes as default in GHC 6.8 or later). The installation is now conforming to the standard Cabal steps. New addition is the Haddock documentation for all interface functions. There is also a sample program to demonstrate its usage on the Haskell wiki site for GLFW: http://haskell.org/haskellwiki/GLFW Any feedbacks is welcome! I've only tested it on a limited number of platforms + GHC combinations, so if you have installation issue, please let me know. Thank you! -- Regards, Paul Liu Yale Haskell Group http://www.haskell.org/yale

1 0

Simulating client server communication with recursive monads
by Jan Stranik 16 Jan '08

16 Jan '08

Hello, I am trying to simulate a client server traffic using recursive lazy evaluation. I am trying to do that in a recursive writer monad. Following code is my attempt to simulate client server interaction and collect its transcript: {-# OPTIONS -fglasgow-exts #-} module Main where import Control.Monad.Writer.Lazy simulation:: Writer [String] () simulation = mdo a <- server cr cr <- client $ take 10 a return () server:: [Integer] -> Writer [String] [Integer] server (a:as) = do tell ["server " ++ show a] rs <- server as return ((a*2):rs) server [] = return [] client:: [Integer] -> Writer [String] [Integer] client as = do dc <- doClient as return (0:dc) where doClient (a:as) = do tell ["Client " ++ show a] as' <- doClient as return ((a+1):as') doClient [] = return [] main = return $ snd $ runWriter simulation The problem that I see is that the transcript collected contains first all output from the server, and then output from the client. Here is an example of output that I see: :["server 0","server 1","server 3","server 7","server 15","server 31","server 63","server 127","server 255","server 511","server 1023","Client 0","Client 2","Client 6","Client 14","Client 30","Client 62","Client 126","Client 254","Client 510","Client 1022"] I would like to collect the output like: :["client 0","server 0", "client 1",.] This would allow me to remove the ending condition in simulation (take 10), and instead rely fully on lazy evaluation to collect as many simulation steps as needed by my computation. I am still relatively new to the concepts of recursive monadic computations, so I would appreciate any suggestions from experts on this mailing list. Thank you Jan

3 4

hbeat: a rhythm sequencer
by Tim Docker 15 Jan '08

15 Jan '08

I've just uploaded to hackage a step-based music sequencer, called "hbeat". It's little more than a toy, but it's fun. It ought to be cross platform, though has been built and tested solely on linux. Given that it's only 400 or so lines, it may be a useful example for anyone wanting to combine OpenGL graphics, interaction, and sound via the SDL libraries. It's also interesting that more than half of the code is "pure" (ie outside the IO monad), despite the fact that this is a stateful app with real time interaction with the real world. Further details here: http://dockerz.net/software/hbeat.html Thanks to lemmih for the SDL bindings that made this possible. Tim

1 0