May 2009 - Haskell - Haskell.org

[ANN] Safe Lazy IO in Haskell
by Nicolas Pouillard 18 May '09

18 May '09

Hi folks, We have good news (nevertheless we hope) for all the lazy guys standing there. Since their birth, lazy IOs have been a great way to modularly leverage all the good things we have with *pure*, *lazy*, *Haskell* functions to the real world of files. We are happy to present the safe-lazy-io package [1] that does exactly this and is going to be explained and motivated in the rest of this post. === The context === Although these times were hard with the Lazy/IO technique, some people continue to defend them arguing that all discovered problems about it was not that harmful and that taking care was sufficient. Indeed some issues have been discovered about Lazy/IOs, some have been fixed in the underlying machinery, some have just been hidden and some others are still around. == An alternative == An alternative design has been proposed --and is still evolving--, it is called "Iteratee" [2] and has been designed by Oleg Kiselyov. This new design has tons of advantages over standard imperative IOs, and shares some of the goals of Lazy/IOs. Iteratee provides a way to do incremental processing in a high-level style. Indeed both processed data (via enumerators) and processing code (called iteratee) can be modularly composed. The handling of file-system resources is precise and safe. Catching errors can be done precisely and can be interleaved with the processing. In spite of all this, there is an important drawback: a lot of code has to be re-written and thought in another way. Processing becomes explicitly chunked which is not always needed and, even worse, exceptions handling also becomes very explicit. While this makes sense in a wide range of applications it makes things less natural than the general case of pure functions. We think that Iteratee have too be studied more, and we recommend them when you have incrementally react to IO errors. == Issues of Standard Lazy/IO == We think that we can save Lazy/IO cheaply, but before explaining the way we solve such and such issue, let's first expose Lazy/IO and its issues. One of the main Lazy/IO functions is 'readFile': it takes a file path opens it and returns the list of characters until the end of the file is reached. The characteristic of 'readFile' is that only the opening is done strictly, while the reading is performed lazily as much as the output list is processed. Cousins of 'readFile' are 'hGetContents' that takes a file handle and 'getContents' that reads on the standard input. This technique enables to process a file as if the file was completely stored in memory. Because it is read lazily one knows that only the required part of the file will be read. Even better, if the input is consumed to produce a small output or the output is emitted incrementally, then the processing can be done in constant memory space. Examples: -- Prints the number of words read on stdin > countWords = print . length . words =<< getContents -- Prints the length of the longest line > maxLineLen = print . maximum . map length . lines =<< getContents -- Prints in lower case the text read on stdin > lowerText = interact (map toLower) -- Alternatively > lowerText = putStr . map toLower =<< getContents All these examples are pretty idiomatic Haskell code and make a simple use of Lazy/IOs. Each of them runs in constant memory space even if they are declared as if the whole contents were available at once. By using stream fusion or 'ByteString''s one can get even faster code while keeping the code almost the same. Here we will stay with the default list of 'Char''s data type. However one goal of our approach is to be trivially adaptable to those data types. Using our library will be rougly a matter of namespace switch plus a running function: > lowerText = LI.run' (SIO.putStr . map toLower <$> LI.getContents) However we will introducing this library as one goes along. Here is another example where the Lazy/IO are still easy to use but no longer scales well. This program counts the lines of all the files given in arguments: > countLines = print . length . lines . concat =<< mapM readFile =<< getArgs Here the problem is the limitation of simultaneous opened files. Indeed, all the files are opened at the beginning therefore reaching the limit easily. It's time to recall when the files are closed. With standard Lazy/IOs the handle is closed when you reach the end of the file, and so when you've explored the whole list returned by 'readFile'. Note also that if you manually open the file and get a handle, then you can manually close the file, however if by misfortune you close the file and then still consume the lazy list you will get a truncated list, observing how much of the file has been read. This last point is due to the fact that 'readFile' considers the reading error as the end of the file. In particular one can fix this program, by simply counting the number of lines of each file separately and then compute the sum to get the final result. > countLines = print . sum =<< mapM (fmap (length . lines) . readFile) =<< getArgs However once again this program exhausts the handle resources. Trying to close the files will not save us either, one just risks getting truncated files. Indeed the list of intermediate results is produced eagerly but each intermediate result is lazy and then each file is opened but not immediately closed since the computation is delayed. Hopefully adding a bit of strictness cures the problem: > countLines = print . sum =<< mapM ((return' . length . lines =<<) . readFile) =<< getArgs > where return' x = x `seq` return x Until there, we have disclosed three problems: * while reading is lazy, opening is strict, which leads to a less natural processing of multiple files * the closing of files is hard to predict * the errors during reading are silently discarded The last one is a bit trickier and has recently been exposed by Oleg Kiselyov [3]. The problem appears when one gets twice the contents of the same stream---or some kind of inter-dependent streams. Because reading is implicitly driven by the consumer, the interleaving of reading may then depend on the reduction strategy employed. This is the case even if the consumer is a pure function. Basically in this example one can observe different values when using one of these functions: > f1 x y = x `seq` y `seq` x - y > f2 x y = y `seq` x `seq` x - y In this example one reads stdin twice and relies on the error handling to end one stream while keeping the other opened. Moreover there are other ways to achieve this like the use of unix fifo files, or using 'getChanContents' from the "Control.Concurrent.Chan" module. === Our solution === Here we will present another design, based on a very simple idea. Our goal is to provide IO processing in a style very similar to standard Lazy/IO with the following differences: - preservation of the determinism; - a simple control exceptions; - and a precise management of resources. Our solution is made of three key ingredients: a bit of strictness, some predefined schemas to interleave inputs, some scopes and abstract types to delimit lazy input operations from strict IO operations. == Dealing with a single input == Let's present the first ingredient alone through a first example: > mapHandleContents :: NFData sa => Handle -> (String -> sa) -> IO sa > mapHandleContents h f = do > s <- hGetContents h > return' (f s) `finally` hClose h > return' :: (Monad m, NFData sa) => sa -> m sa > return' x = rnf x `seq` return x It implements some combination of 'fmap' and 'hGetContents'. Actually some of our examples fit nicely in that model: > countWords = print =<< mapHandleContents stdin (length . words) > maxLineLen = print =<< mapHandleContents stdin (maximum . map length . lines) > lowerText = putStr =<< mapHandleContents stdin (map toLower) However while the two first examples work well in this setting, the third one tries to allocate the whole result in memory before printing it. Here the ingredient that is used is strictness: the purpose in forcing the result is to be sure that all the needed input is read, before the file is closed. So here we rely on 'NFData' instances to really perform deep forcing---this kind of assumption is a bit like 'Typeable' instances. In particular functions must not be an instance of 'NFData': indeed, we have no way to force lazy values that are stored in the closure of a function. The same remark applies to the 'IO' monad for at least three reasons: 'IO' if often represented by functions; lazy 'IORef''s could be used to hide one input for later use; exceptions with a lazy contents could also be used to make a lazy value escape. Let's now add some more strictness into the meal: the 'SIO' monad! == The 'SIO' monad == The 'SIO' monad is a thin layer over the 'IO' monad, populated only by strict 'IO' operations. In particular these operations are strict in the output, which means that once the output is produced then we know that the given arguments cannot be further evaluated/forced. Here is an example of strict IO using the 'SIO' monad: > import qualified System.IO.Strict as SIO > import System.IO.Strict (SIO) > countWords = SIO.run (SIO.print . length . words =<< SIO.getContents) Of course this function does not scale well since it reads the whole contents in memory before processing it. For now the strict-io [4] package contains wrappers for functions in "System.IO", and strict 'IORef''s. One can now introduce a function in lines of 'mapHandleContents': > withHandleContents :: NFData sa => Handle -> (String -> SIO sa) -> IO sa > withHandleContents h f = do > s <- hGetContents h > SIO.run (f s) `finally` hClose h One can then rewrite 'lowerText' as follow: > lowerText = withHandleContents stdin (SIO.putStr . map toLower) Until there one can deal quite nicely with single input, many outputs processing. Currently the only requirement is to delimit a scope where the resource will be used to return a strict value. Dealing with multiple inputs will lead us to our final design of lazy inputs. == Introducing 'LI', Lazy Inputs == We first introduce a type for these lazy inputs namely 'LI'. This type is abstract and we will progressively introduce functions to build, combine and run them. The 'LI' type is a pointed functor, but not necessarily a monad nor an applicative functor. Therefore one exports the 'pure' function as 'pureLI'. Building primitives allow to read files or handles: > LI.pureLI :: a -> LI a > LI.hGetContents :: Handle -> LI String > LI.getContents :: LI String > LI.readFile :: FilePath -> LI String > LI.getChanContents :: Chan a -> LI [a] Being a functor is important: it allows to wholly transform the underlying input lazily using standard functions about lists for instance: > length <$> LI.readFile "foo" > words <$> LI.readFile "foo" Extracting a final value of a lazy input ('LI' type) is a matter of using: > LI.run :: (NFData sa) => LI sa -> IO sa Or > LI.run' :: (NFData sa) => LI (SIO a) -> IO sa One can therefore re-write our examples using lazy inputs: > -- embedded printing > countWords = LI.run' (SIO.print . length . words <$> LI.getContents) > -- external printing > maxLineLen = print =<< LI.run (maximum . map length . lines <$> LI.getContents) > lowerText = LI.run' (SIO.putStr . map toLower <$> LI.getContents) == Combining inputs == Finally we come to managing multiple inputs. To get both laziness and precise resource management we will provide dedicated combinators. The first one is as simple as appending. > LI.append :: NFData sa => LI [sa] -> LI [sa] -> LI [sa] This one produces a single stream out that sequences the two given streams. It also sequences the usage of resources: the first resource is closed and then the second one is opened. Note that this combinator is still quite general since one can process each input beforehand: > -- one can drop parts of the inputs > (take 100 <$> i1) `LI.append` (drop 100 <$> i2) > -- one can tag each input to know where they come from > Left <$> i1 `LI.append` Right <$> i2 The second one is 'LI.zipWith' which opens the two resources and joins the items into a single stream. Again, since 'LI' is a functor one can join not only characters but also words, lines, chunks... A problem with zipping is that it stops on the shorter input (loosing a part of the other), hopefully one can prolongate them: > zipMaybesWith :: (NFData sa, NFData sb) -> (Maybe sa -> Maybe sb -> c) -> LI [sa] -> LI [sb] -> LI [c] > zipMaybesWith f xs ys = > map (uncurry f) . takeWhile someJust <$> zip (prolongate <$> xs) (prolongate <$> ys) > where someJust (Nothing, Nothing) = False > someJust _ = True > prolongate :: [a] -> [Maybe a] > prolongate zs = map Just zs ++ repeat Nothing The last one is 'LI.interleave': > LI.interleave :: (NFData sa) -> LI [sa] -> LI [sa] -> LI [sa] This function is currently left biased, moreover each resource is closed as soon as we reach its end. However since the inputs are mixed up together one generally prefers a tagged version trivially build upon this one: > interleaveEither :: (NFData sa, NFData sb) => LI [sa] -> LI [sb] -> LI [Either sa sb] > interleaveEither a b = interleave (map Left <$> a) (map Right <$> b) Here are some final programs that scale well with the number of files. > -- number of words in the given files > main = print =<< LI.run . fmap (length . words) . LI.concat . map LI.readFile =<< getArgs > -- almost the same thing but counts words independently in each file > main = print > =<< LI.run . fmap sum . LI.sequence . map (fmap (length . words) . LI.readFile) > =<< getArgs > -- prints to stdout swap-cased concatenation of all input files > main = LI.run' . (fmap (SIO.putStr . fmap swapCase) . LI.concat . map LI.readFile) =<< getArgs > where swapCase c | isUpper c = toLower c > | otherwise = toUpper c > -- sums character code points of inputs > main = print =<< LI.run . fmap (sum . map (toInteger . ord)) . LI.concat . map LI.readFile =<< getArgs Our solution is from now widely available as an Hackage package named "safe-lazy-io" [4]. We hope you will freely enjoy using Lazy/IO again! As usual, criticisms, comments, and help are expected! Finally, I would like to thank Benoit Montagu and Francois Pottier for helping me out to polish this work! [1]: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/safe-lazy-io [2]: http://okmij.org/ftp/Streams.html [3]: http://www.haskell.org/pipermail/haskell/2009-March/021064.html [4]: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/strict-io -- Nicolas Pouillard

2 2

CFT: Haskell Implementers' Workshop 2009 (co-located with ICFP)
by Simon Marlow 18 May '09

18 May '09

Call for Talks ACM SIGPLAN Haskell Implementers' Workshop http://haskell.org/haskellwiki/HaskellImplementorsWorkshop Edinburgh, Scotland, September 3, 2009 The workshop will be held in conjunction with ICFP 2009 http://www.cs.nott.ac.uk/~gmh/icfp09.html Important dates Proposal Deadline: 15 June 2009 Notification: 3 July 2009 The Haskell Implementers Workshop is a new workshop to be held alongside ICFP 2009 this year in Edinburgh, Scotland. There will be no proceedings; it is an informal gathering of people involved in the design and development of Haskell implementations, tools, libraries, and supporting infrastructure. This new workshop reflects the growth of the user community: there is a clear need for a well-supported tool chain for the development, distribution, deployment, and configuration of Haskell software. The aim is for this workshop to give the people involved with building the infrastructure behind this ecosystem an opportunity to bat around ideas, share experiences, and ask for feedback from fellow experts. We intend the workshop to have an informal and interactive feel, with a flexible timetable and plenty of room for ad-hoc discussion, demos, and impromptu short talks. Scope and target audience ------------------------- We feel it's important to clearly distinguish the Haskell Implementers Workshop from the other Haskell-related workshops co-located with ICFP 2009. The Haskell Symposium is for the publication of Haskell-related research. In contrast, the Haskell Implementers' Workshop will have no proceedings - although we will aim to make slides and talk videos available with the consent of the speakers. DEFUN aims to teach how functional programming techniques can be applied in practice. In the Haskell Implementors' Workshop we hope to study the underlying technology that drives this application development. We want to bring together anyone interested in the nitty gritty details necessary to turn a text file into a deployed product. Having said that, members of the wider Haskell community are more than welcome to attend the workshop - we need your feedback to keep the Haskell ecosystem thriving. The scope covers any of the following topics (but there may be some we've missed, so by all means submit a proposal even if it doesn't fit exactly into one of these buckets): * Compilation techniques * Language features and extensions * Type system implementation * Concurrency and parallelism: language design and implementation * Performance, optimisation and benchmarking * Virtual machines and run-time systems * Libraries and Tools for development or deployment Talks ----- At this stage we'd like to invite proposals from potential speakers for a relatively short (20-30 min) talk. Please submit a talk title and abstract of no more than 200 words to simonmar(a)microsoft.com. We want to hear from people writing compilers, tools, or libraries, people with cool ideas for directions in which we should take the platform, proposals for new features to be implemented, and half-baked crazy ideas. We also plan to invite a number of speakers from the community. Organizers ---------- * Duncan Coutts - co-chair (Well-Typed LLP) * Atze Dijkstra (Utrecht University) * Roman Leshchinskiy (University of New South Wales) * Simon Marlow - co-chair (Microsoft Research) * Bryan O'Sullivan (Linden Lab) * Wouter Swierstra (Chalmers University of Technology)

1 1

ANNOUNCE: mathlink-2.0.0.3
by Tracy Wadleigh 18 May '09

18 May '09

All: mathlink is a library for writing Mathematica packages in Haskell. One simply writes some functions of type: (MLGet a, MLPut b) => a -> IO b and provides a package specification in a simple DSL that mimics that of Mathematica's mprep utility. The result is a program that exposes functions that can be called from Mathematica. This is a complete rewrite of my original implementation and more closely captures the functionality I originally intended. I've only tested it on my own platform (64-bit Linux), but I've taken pains to make sure the code should run on any platform. (The only real issue in the code is picking the right functions to call when marshaling Ints.) Please report any tweaks required to get it to work on your platform. (That is, of course, only if, in fact, there are any other users out there. Right now, as far as I know, I'm it.) I'd also just like to hear from any Haskellers out there that also use Mathematica on a regular basis. Ping me if you're one. --Tracy

1 0

Haskell Weekly News: Issue 118 - May 16, 2009
by Brent Yorgey 17 May '09

17 May '09

--------------------------------------------------------------------------- Haskell Weekly News http://sequence.complete.org/hwn/20090516 Issue 118 - May 16, 2009 --------------------------------------------------------------------------- Welcome to issue 118 of HWN, a newsletter covering developments in the [1]Haskell community. Welcome to the Google Summer of Code special edition! I asked each of the five students with accepted GSoC projects to describe what they plan to work on. You'll find their descriptions below, with links to their blogs. And keep watching this space: as I did last summer, I plan to provide readers of the HWN with weekly updates on the progress of the GSoC projects. Google Summer of Code Haddock improvements! Isaac Dupree is [2]working on improvements to [3]Haddock. "Besides the various inevitable small fixes/improvements, my specific projects are to make cross-package documentation work, and to refactor the comment-parsing out of GHC and into the Haddock code-base." EclipseFP. Thomas Ten Cate will be [4]working on EclipseFP: "Compared to more mainstream languages, Haskell has surprisingly poor IDE support, even though its static typing system allows for much more help from the IDE than in the case of dynamic languages. For the Java language, a very mature and powerful IDE exists in the form of Eclipse. A plugin for Haskell support in Eclipse, called EclipseFP, is in the works, but its development has been standing still for some time. I will bring EclipseFP to a more usable state. For this, I will use the Scion IDE library, which interfaces with the GHC API, so that more advanced features like type inference become possible. I will also add support for Cabal. Hopefully, this type of IDE support will lead to greater acceptance and use of Haskell, and be useful for development as well as education." Improving the Haskell space profiling experience. Gergely Patai's [5]project will be focused on space profiling: "At the present moment, heap profiling Haskell programs means analysing logs off-line, using conversion tools to visualise data. However, instead of generating graphs with hp2ps, it should be possible to present the data in a graphical application in real time, which is useful while developing interactive applications, and it should also be made easier to export profiler output in different formats. The aim of the project is to create a set of tools that make heap profiling of Haskell programs easier in various ways. In particular, the following components are planned: a library to process profiler output in an efficient way and make it easily accessible for other tools in the future; a real-time visualiser (most likely using OpenGL); some kind of history manager to keep track of profiling data and make it possible to perform a comparative analysis of performance between different versions of your program; a maintainable and extensible replacement for hp2ps; and converters to provide input for other profiling tools." haskell-src-exts -> haskell-src. Niklas Broberg: "My [6]project, dubbed 'haskell-src-exts -> haskell-src' is really two projects in one wrapping. The first milestone is to bring my haskell-src-exts library to the point where it can supersede the old haskell-src library as the de facto package for haskell source manipulation. The main problem that I need to solve is to implement a scheme that lets the user decide what extensions to recognize when parsing a source document. Currently, haskell-src-exts assumes all extensions are always on, which means that some valid H98 programs will be incorrectly parsed due to stolen syntax by e.g. Template Haskell. The second milestone is to extend the focus from source code to full source documents, and implement a scheme for handling comments as well. The ultimate goal here is to have (pretty . parse) == id, to allow haskell-src-exts to be run on source documents without changing them. This would open up for some really interesting applications, in particular refactoring tools that could automatically apply transformations to a source document while still preserving comments." darcs. Last but not least, Petr Rockai will be [7]working on improvements to [8]darcs: "My project revolves around the idea of fast darcs for medium and large repositories. Three are quite a few haskellers who use darcs in their day to day (haskell) work. A fair number of hackage packages is maintained in darcs. Even though many of these repositories are of a relatively modest size, there is a number of relatively large real-world darcs repositories out there. The primary target of the project is to improve scalability of darcs for large working trees. This should help those users with existing large darcs repositories, as well as encourage people to use darcs for larger projects, whenever the development model fits. I intend to make the darcs working tree handling comparably fast to git. And then, git is written in C, hand-tuned for a specific operating system. And unlike mercurial, I do not plan to introduce a C library for low level routines. So let's prove that Haskell is up to the challenge." Announcements 2009.2.1: version freeze for Haskell Platform approaching on Monday. Don Stewart [9]announced that the last chance to propose bug fix version bumps to be included in the first minor release (2009.2.1) of the [10]Haskell Platform is Monday. Please ensure that, as maintainer for one of the 2009.2.x series of packages, any bug fixes are in place by Monday, or they'll be bumped to the next platform release. OpenGL 2.2.3.0. Sven Panne [11]announced the release of a new version of the [12]OpenGL package. This is a feature release, containing a number of changes and additions. Programming in Haskell -- solutions to exercises. Graham Hutton [13]announced that solutions to the exercises from "Programming in Haskell" are now [14]available online. Bookshelf. Emil Axelsson [15]announced the first release of [16]Bookshelf, a simple document organizer with some wiki functionality. Documents in a directory tree are displayed as a set of HTML pages. Documents in Markdown format are converted to HTML automatically using Pandoc. Request for feedback: HaskellDB + HList. Brian Bloniarz [17]requested feedback on a branch of [18]HaskellDB which replaces the home-grown Record code with HList records. RESTng 0.1 + RedHandlers 0.1 (request handlers) + YuiGrids 0.1 (yahoo grids). Sergio Urinovsky [19]announced the release of three new packages developed for a RESTful web framework called RESTng: [20]RESTng, [21]redHandlers, and [22]yuiGrid. #haskell.pt IRC channel. Marco Túlio Gontijo e Silva [23]announced the formation of the #haskell.pt channel on irc.freenode.net for Portuguese-speaking Haskellers. Fun with type functions. Simon Peyton-Jones [24]requested feedback on a [25]draft tutorial paper about type families (aka associated data types, or type functions). Discussion conflicting variable definitions in pattern. Martin Hofmann [26]asked about the possibility of repeated variables in patterns, resulting in an interesting discussion. Removing mtl from the Haskell Platform. Russell O'Connor began a [27]discussion around the possibility of removing the mtl package from the Haskell Platform, and replacing it with something more modern. Jobs PhD position in Nottingham. vxc [28]announced the availability of a new PhD position in the Functional Programming Laboratory at the University of Nottingham. The topic of research for the project is "Programming and Reasoning with Infinite Structures": it consists in the theoretical study and development of software tools for coinductive types and structured corecursion. Blog noise [29]Haskell news from the [30]blogosphere. Blog posts from people new to the Haskell community are marked with >>>, be sure to welcome them! * Leif Frenzel: [31]EclipseFP is going to be reloaded. * Tom Schrijvers: [32]Dictionaries: Eager or Lazy Type Class Witnesses?. Can type class dictionaries be optimized by treating them strictly? * Real-World Haskell: [33]RWH Now In The Kindle Store. * JP Moresmau: [34]Adding a Writer Monad transformer. * Ketil Malde: [35]Using a phantom type to label different kinds of sequences. * Ivan Lazar Miljenovic: [36]Functions All The Way Down. Ivan's talk on lambda calculus. * Thomas M. DuBuisson: [37]Fun with Distributed Hash Tables. Distributed hash tables in Haskell. * Darcs: [38]darcs joins the Software Freedom Conservancy. * Mark Wassell: [39]Just Grapefruit. Mark's first impressions of the Grapefruit library. * Roman Cheplyaka: [40]LambdaCube accepted to JSSP. Jane Street is funding development of the LambdaCube 3D rendering engine. * >>> Joel Neely: [41]BuilderBuilder: The Model in Haskell. * Brandon Simmons: [42]directory-tree module released. * >>> Sadek Drobi: [43]Paul Hudak on Haskell. An interview with Paul Hudak. * >>> dayvan cowboy: [44]Blast from the past: a stochastic monad in Haskell. * Matthew Podwysocki: [45]Type Classes Are The Secret Sauce . * Remco Niemeijer: [46]Programming Praxis - Priority Queues. A priority queue implementation using a leftist heap. * >>> Y. Liang: [47]A Lambda Calculus Interpreter in Haskell. Quotes of the Week * seydar: what's the nick of the drug addict who wrote learn you a haskell? and i mean that in the best possible way. * roconnor: String is kinda a poor data type for strings. * kyevan: I had a haskell-related dream last night. Sorta. I was beaten up by some kids because I tried to go somewhere my type didn't match, apparently. * edwardk: Haskell 98 is the Windows 98 of standards ;) * PhilipWadler: I'm delighted to learn that "a monad is a monoid in the category of endofunctors"---anyone know where I can find a good tutorial? * David Leimbach: Don't play with your monads... eventually you'll go bind. About the Haskell Weekly News New editions are posted to [48]the Haskell mailing list as well as to [49]the Haskell Sequence and [50]Planet Haskell. [51]RSS is also available, and headlines appear on [52]haskell.org. To help create new editions of this newsletter, please see the information on [53]how to contribute. Send stories to byorgey at cis dot upenn dot edu. The darcs repository is available at darcs get [54]http://code.haskell.org/~byorgey/code/hwn/ . References 1. http://haskell.org/ 2. http://haddock2009.wordpress.com/ 3. http://www.haskell.org/haddock/ 4. http://eclipsefp.wordpress.com/ 5. http://just-bottom.blogspot.com/ 6. http://nibrofun.blogspot.com/ 7. http://web.mornfall.net/tag/darcs.html 8. http://darcs.net/ 9. http://article.gmane.org/gmane.comp.lang.haskell.libraries/11120 10. http://trac.haskell.org/haskell-platform/ 11. http://article.gmane.org/gmane.comp.lang.haskell.general/17194 12. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/OpenGL 13. http://article.gmane.org/gmane.comp.lang.haskell.general/17193 14. http://www.cs.nott.ac.uk/~gmh/book.html 15. http://article.gmane.org/gmane.comp.lang.haskell.general/17182 16. http://www.cs.chalmers.se/~emax/bookshelf/Manual.shelf.html 17. http://article.gmane.org/gmane.comp.lang.haskell.cafe/58615 18. http://haskelldb.sourceforge.net/ 19. http://article.gmane.org/gmane.comp.lang.haskell.cafe/58589 20. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/RESTng 21. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/redHandlers 22. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/yuiGrid 23. http://article.gmane.org/gmane.comp.lang.haskell.cafe/58581 24. http://article.gmane.org/gmane.comp.lang.haskell.cafe/58522 25. http://haskell.org/haskellwiki/Simonpj/Talk:FunWithTypeFuns 26. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/58560 27. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/58430 28. http://article.gmane.org/gmane.comp.lang.haskell.cafe/58526 29. http://planet.haskell.org/ 30. http://haskell.org/haskellwiki/Blog_articles 31. http://cohatoe.blogspot.com/2009/05/eclipsefp-is-going-to-be-reloaded.html 32. http://tomschrijvers.blogspot.com/2009/05/dictionaries-eager-or-lazy-type-c… 33. http://www.realworldhaskell.org/blog/2009/05/15/rwh-now-in-the-kindle-store/ 34. http://jpmoresmau.blogspot.com/2009/05/adding-writer-monad-transformer.html 35. http://blog.malde.org/index.php/2009/05/14/using-a-phantom-type-to-label-di… 36. http://ivanmiljenovic.wordpress.com/2009/05/14/functions-all-the-way-down/ 37. http://tommd.wordpress.com/2009/05/13/fun-with-distributed-hash-tables/ 38. http://blog.darcs.net/2009/05/darcs-joins-software-freedom.html 39. http://www.poundstone.org/blog/?p=165 40. http://physics-dph.blogspot.com/2009/05/lambdacube-accepted-to-jssp.html 41. http://joelneely.wordpress.com/2009/05/09/builderbuilder-the-model-in-haske… 42. http://coder.bsimmons.name/blog/2009/05/directory-tree-module-released/ 43. http://www.infoq.com/interviews/paul-hudak-haskell-Qcon-SF-08 44. http://dayvancowboy.org/2009/05/08/blast-from-the-past-a-stochastic-monad-i… 45. http://codebetter.com/blogs/matthew.podwysocki/archive/2009/05/08/type-clas… 46. http://bonsaicode.wordpress.com/2009/05/05/programming-praxis-priority-queu… 47. http://yiopposite.blogspot.com/2009/05/lambda-calculus-interpreter-in-haske… 48. http://www.haskell.org/mailman/listinfo/haskell 49. http://sequence.complete.org/ 50. http://planet.haskell.org/ 51. http://sequence.complete.org/node/feed 52. http://haskell.org/ 53. http://haskell.org/haskellwiki/HWN 54. http://code.haskell.org/~byorgey/code/hwn/

1 0

ANNOUNCE: OpenGL 2.2.3.0
by Sven Panne 16 May '09

16 May '09

A new version of the OpenGL package has bee uploaded to Hackage. This is a feature release, containing the following changes and additions: * Added support for GL_ARB_copy_buffer, GL_ARB_depth_buffer_float, GL_ARB_half_float_pixel, GL_ARB_texture_rectangle, GL_EXT_packed_float and GL_EXT_texture_shared_exponent extensions. * Added missing parts of GL_ARB_vertex_shader extension. * Announce that we support MESA_ycbcr_texture and APPLE_ycbcr_422 extensions. * Improved generic vertex attribute array API. * Added support for unsigned integral uniforms. * Added more GLSL type tokens. * Added missing query for texture size limits. * Include missing aclocal.m4 and README in source distribution and removed unused Makefiles and prologue.txt. * Added 2 hacks to determine the Haskell equivalents of GLchar/GLintptr/GLsizeiptr with ancient GL headers. * Added Vector1, Vector4 and Vertex1 data types for orthogonality. * Added Functor, Applicative, Foldable , Traversable, Typeable and Typeable1 instances for all vertex attributes plus all possible derivable instances. Cheers, S.

1 0

Programming in Haskell -- solutions to exercises
by Graham Hutton 16 May '09

16 May '09

Dear all, For info, solutions to the exercises from "Programming in Haskell" are now available online, from: http://www.cs.nott.ac.uk/~gmh/book.html Best wishes, Graham +-----------------------------------------------------------------+ | Dr Graham Hutton Email : gmh(a)cs.nott.ac.uk | | Functional Programming Lab | | School of Computer Science Web : www.cs.nott.ac.uk/~gmh | | University of Nottingham | | Jubilee Campus, Wollaton Road Phone : +44 (0)115 951 4220 | | Nottingham NG8 1BB, UK | +-----------------------------------------------------------------+ This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.

1 0

ANN: RESTng 0.1 + RedHandlers 0.1 (request handlers) + YuiGrids 0.1 (yahoo grids)
by Sergio Urinovsky 15 May '09

15 May '09

I'd like to announce the release of 3 new packages in hackage developed for a RESTful web framework called RESTng. They are experimental, the framework is incomplete and we are currently not actively developing it. There are several interesting features so we have decided to release them to share the ideas. *RESTng:* A framework for writing RESTful applications. Features that may be of interest are: * Resource presentation with annotations (implemented with Grids): Resources are annotated with related data and all ends in boxes using grids. i.e., an annotation for a book resource could be its author (the author resource), and also their comments, so the book, the author and their comments are shown in boxes. Annotations can have arbitrary data, but there are some generic ones already available. * Hierarchical URLs are automatically handled. i.e.: Can easily define that a book resource "has many" chapters, then these actions are defined: GET http://site/book/3/chapter/1 (get the chapter 1 of book with id 3) GET http://site/book/3/chapter/new (get a form for filling data for the new chapter for book with id 3) POST http://site/book/3/chapter/new (create a new chapter for the book with id 3) and so on for updates, list and delete actions * ORM generates tables from haskell records (currently only PostgreSQL is supported in the ORM). * Associations "has many" defined for models. Making available functions to query for the parent and children so you don't have to make the SQL query. * Associations can be polymorphic so a comment can be associated to different resources types. A record for a comment on a book, another for a comment on a post. * Tags, Ratings, Comments, Users and login and CMS-like form fields validations supported. *YuiGrids:* * Containers and boxes with layout hints are specified. i.e: - Box A: in left side bar, near the bottom, with this content .... - Container B: in the main part of the page, near the top, with 3 columns and these let's say 14 boxes inside ... (including Box C) - Box C: in the left column of three, with this other content ... * Tries to satisfy the layout hints. Not allways possible, i.e: if every box has layout hint to go near the bottom, some of them will go at the top. * Boxes can have CSS specifications. * All is rendered into Yahoo grids (http://developer.yahoo.com/yui/grids) Currently, the YuiGrids uses own contextual html combinators are also implemented in this package (called CxML here) instead of Text.XHtml for keeping track of html parts like inline CSSs to be rendered at the head. This can be improved to use the standard Text.XHtml library. *RedHandlers:* It is another HTTP request handlers library to build standalone web apps. * They deal with request data as usual. * There are also combinators for mapping part of the URL to public folders in the file system. * And one for sending files efficiently in the response (a fork of the HTTP library was necessary for this, included here).

1 0

TFM09: Last CFP (Formal Methods Week, Eindhoven, November 6th 2009)
by J.N. Oliveira 15 May '09

15 May '09

TFM2009 2nd Int. FME Conference on Teaching Formal Methods "Widening Access to Formal Methods" Friday, November 6th 2009, co-located with FM2009 : 16th International Symposium on Formal Methods Eindhoven, the Netherlands, November 2 - November 6, 2009 CALL FOR PAPERS (URL: http://www.di.uminho.pt/tfm09) 1. About the conference ----------------------- Ten years after the First World Formal Methods Congress (FM'99) in Toulouse, formal methods communities from all over the world will once again have an opportunity to come together. As part of the First Formal Methods Week event surrounding the FM2009 conference in Eindhoven, Formal Methods Europe will be organizing TFM2009, the Second International Conference on Teaching Formal Methods. The conference will serve as a forum to explore the successes and failures of Formal Methods (FM) education, and to promote cooperative projects to further education and training in FMs. We would like to provide a forum for lecturers, teachers, and industrial partners to discuss their experience, present their pedagogical methodologies, and explore best practices. TFM2009 follows in a series of recent events on teaching formal methods, including: two BCS-FACS TFM workshops (Oxford in 2003, and London in 2006), the TFM 2004 conference in Ghent (with proceedings published as Springer LNCS Volume 3294), the FM-Ed 2006 workshop (Hamilton, co-located with FM'06), FORMED (Budapest, at ETAPS 2008), FMET 2008 (Kitakyushu 2008, co-located with ICFEM), etc. 2. Topics of interest --------------------- Formal methods (FM) have an important role to play in the development of complex computing systems - a role acknowledged in industrial standards such as IEC 61508 and ISO/IEC 15408, and in the increasing use of precise modeling notations, semantic markup languages, and model-driven techniques. There is a growing need for software engineers who can work effectively with simple, mathematical abstractions, and with practical notions of inference and proof. However, there is little clear guidance ? for educators, for managers, or for the engineers themselves ? as to what might comprise a basic education in FM. Neither the present IEEE/ACM Software Engineering Body of Knowledge (SWEBOK) nor the forthcoming Graduate Software Engineering Reference Curriculum (GSWERC) provide the kind of specific information that teachers and practitioners need to establish an adequate, balanced programme of learning in FM. Original contributions are solicited that provide insight, opinions, and suggestions for courses of action regarding the teaching FMs, including but not limited to the following aspects: * experiences of teaching FMs, both successful and unsuccessful; * educational resources including the use of books, case studies and the internet; * the education of weak and mathphobic students; * the integration, or otherwise, of FMs into the curriculum, including contributions to the definition of a Formal Methods Body of Knowledge (FMBOK); * the advantages of FM-trained graduates in the workplace; * changing attitudes towards FMs in students, academic staff and practitioners; * the necessary mathematical background. The conference proceedings will be published by Springer-Verlag in the LNCS series. Submissions may be up to 20 pages long using Springer's LNCS format. 3. Important dates ------------------ Please put the following dates in your diary: Submission deadline May 25, 2009 Notification of acceptance July 6, 2009 Final version August 3, 2009 4. How to submit ---------------- Papers for TFM2009 will be processed through the EasyChair conference management system.To submit your paper, please visit: http://www.easychair.org/conferences/?conf=tfm2009 5. Invited speakers ------------------- To be announced 6. Programme Committee ---------------------- Izzat Alsmadi (North Dakota State University, USA) Dines Bjorner (IIMM Institute, Denmark) Eerke Boiten (University of Kent, UK) Raymond Boute (Universiteit Gent, Belgium) Andrew Butterfield (Trinity College, Dublin) Jim Davies (University of Oxford, UK) David Duce (Oxford Brookes University, UK) John Fitzgerald (University of Newcastle upon Tyne, UK) Jeremy Gibbons (University of Oxford, UK) Randolph Johnson (National Security Agency, USA) Michael Mac an Airchinnigh (Trinity College, Dublin) Dino Mandrioli (Politecnico di Milano, Italy) Jose Oliveira (Universidade do Minho, Portugal) Kees Pronk (Technische Universiteit Delft, NL) Bernhard Schaetz (Tecnical University of Munique, Germany) Wolfgang Schreiner (Johannes Kepler University Linz, Austria) Simao Melo de Sousa (Universidade da Beira Interior, Portugal) Kenji Taguchi (National Institute of Informatics, Japan) Jeannette Wing (Carnegie-Mellon University, USA) 7. Sponsorship ---------------------- TFM2009 is supported by FME, the Formal Methods Europe Association

1 0

ICFP09 Accepted Papers
by Matthew Fluet (ICFP Publicity Chair) 15 May '09

15 May '09

Accepted Papers ICFP 2009: International Conference on Functional Programming Edinburgh, Scotland, 31 August - 2 September 2009 http://www.cs.nott.ac.uk/~gmh/icfp09.html The ICFP 2009 Program Chair and Committee are pleased to announce that the following papers have been accepted for the conference. Additional information regarding the final program, invited speakers, and registration will be forthcoming. However, the Local Arrangements Co-Chairs would like to remind participants of the following: * ICFP'09 coincides with the final week of the Edinburgh International Festival, one of the premier arts and cultural festivals in the world. The opportunity to attend the Festival is a plus! Due to the popularity of Edinburgh during the festival period, we recommend booking accommodation early. More details regarding accommodation may be obtained from the ICFP 2009 Local Arrangements webpage: http://www.haskell.org/haskellwiki/ICFP_2009_Local_Arrangements Accepted papers ~~~~~~~~~~~~~~~ A CONCURRENT ML LIBRARY IN CONCURRENT HASKELL Avik Chaudhuri A THEORY OF TYPED COERCIONS AND ITS APPLICATIONS Nikhil Swamy, Michael Hicks and Gavin Bierman A UNIVERSE OF BINDING AND COMPUTATION Daniel Licata and Robert Harper ATTRIBUTE GRAMMARS FLY FIRST-CLASS: HOW TO DO ASPECT ORIENTED PROGRAMMING IN HASKELL Marcos Viera, S. Doaitse Swierstra and Wouter S. Swierstra AUTOMATICALLY RESTFUL WEB APPLICATIONS OR, MARKING MODULAR SERIALIZABLE CONTINUATIONS Jay McCarthy BEAUTIFUL DIFFERENTIATION Conal Elliott BIORTHOGONALITY, STEP-INDEXING AND COMPILER CORRECTNESS Nick Benton and Chung-Kil Hur CAUSAL COMMUTATIVE ARROWS AND THEIR OPTIMIZATION Hai Liu, Eric Cheng and Paul Hudak COMPLETE AND DECIDABLE TYPE INFERENCE FOR GADTS Tom Schrijvers, Simon Peyton Jones, Martin Sulzmann and Dimitrios Vytiniotis CONTROL-FLOW ANALYSIS OF FUNCTION CALLS AND RETURNS BY ABSTRACT INTERPRETATION Jan Midtgaard and Thomas P. Jensen EDUCATIONAL PEARL: FUN FOR FRESHMEN KIDS Matthias Felleisen, Robert Bruce Findler, Matthew Flatt and Shriram Krishnamurthi EFFECTIVE INTERACTIVE PROOFS FOR HIGHER-ORDER IMPERATIVE PROGRAMS Adam Chlipala, Gregory Malecha, Greg Morrisett, Avraham Shinnar and Ryan Wisnesky EXPERIENCE REPORT: EMBEDDED, PARALLEL COMPUTER-VISION WITH A FUNCTIONAL DSL Ryan Newton and Teresa Ko EXPERIENCE REPORT: HASKELL IN THE REALWORLD Curt Sampson EXPERIENCE REPORT: OCAML FOR AN INDUSTRIAL-STRENGTH STATIC ANALYSIS FRAMEWORK Pascal Cuoq and Julien Signoles EXPERIENCE REPORT: OCSIGEN, A WEB PROGRAMMING FRAMEWORK Vincent Balat, Jérôme Vouillon and Boris Yakobowski EXPERIENCE REPORT: SEL4 -- FORMALLY VERIFYING A HIGH-PERFORMANCE MICROKERNEL Gerwin Klein, Philip Derrin and Kevin Elphinstone FINDING RACE CONDITIONS IN ERLANG WITH QUICKCHECK AND PULSE Koen Claessen, Michal Palka, Nicholas Smallbone, John Hughes, Hans Svensson, Thomas Arts and Ulf Wiger FREE THEOREMS INVOLVING TYPE CONSTRUCTOR CLASSES Janis Voigtlaender GENERIC PROGRAMMING WITH FIXED POINTS FOR MUTUALLY RECURSIVE DATATYPES Alexey Rodriguez, Stefan Holdermans, Andres Löh and Johan Jeuring IDENTIFYING QUERY INCOMPATIBILITIES WITH EVOLVING XML SCHEMAS Pierre Geneves, Nabil Layaida and Vincent Quint IMPLEMENTING FIRST-CLASS POLYMORPHIC DELIMITED CONTINUATIONS BY A TYPE-DIRECTED SELECTIVE CPS-TRANSFORM Tiark Rompf, Ingo Maier and Martin Odersky LA TOUR D'HANOï Ralf Hinze NON-PARAMETRIC PARAMETRICITY Georg Neis, Derek Dreyer and Andreas Rossberg OXENSTORED: AN EFFICIENT HIERARCHICAL AND TRANSACTIONAL DATABASE USING FUNCTIONAL PROGRAMMING WITH REFERENCE CELL COMPARISONS Thomas Gazagnaire and Vincent Hanquez PARALLEL CONCURRENT ML John Reppy, Claudio Russo and Yingqi Xiao PARTIAL MEMOIZATION OF CONCURRENCY AND COMMUNICATION Suresh Jagannathan, KC Sivaramakrishnan and Lukasz Ziarek PURELY FUNCTIONAL LAZY NON-DETERMINISTIC PROGRAMMING Sebastian Fischer, Oleg Kiselyov and Chung-chieh Shan RUNTIME SUPPORT FOR MULTICORE HASKELL Simon Marlow, Simon Peyton Jones and Satnam Singh SAFE FUNCTIONAL REACTIVE PROGRAMMING THROUGH DEPENDENT TYPES Neil Sculthorpe and Henrik Nilsson SCRIBBLE: CLOSING THE BOOK ON AD HOC DOCUMENTATION TOOLS Matthew Flatt, Eli Barzilay and Robert Bruce Findler USING OBJECTIVE CAML TO DEVELOP SAFETY-CRITICAL EMBEDDED TOOL IN A CERTIFICATION FRAMEWORK Bruno Pagano, Olivier Andrieu, Thomas Moniot, Benjamin Canou, Emmanuel Chailloux, Philippe Wang, Pascal Manoury and Jean-Louis Colaco

1 0

ANNOUNCE: GHC version 6.10.3
by Ian Lynagh 15 May '09

15 May '09

============================================================== The (Interactive) Glasgow Haskell Compiler -- version 6.10.3 ============================================================== The GHC Team is pleased to announce a new patchlevel release of GHC. This release contains a handful of bugfixes relative to 6.10.2 and better line editing support in GHCi, so we recommend upgrading. Release notes are here: http://haskell.org/ghc/docs/6.10.3/html/users_guide/release-6-10-3.html How to get it ~~~~~~~~~~~~~ The easy way is to go to the web page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~~~~~~~~~ Haskell is a standard lazy functional programming language; the current language version is Haskell 98, agreed in December 1998 and revised December 2002. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces (C, whatever). GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ GHC developers' home page http://hackage.haskell.org/trac/ghc/ Haskell home page http://www.haskell.org/ Supported Platforms ~~~~~~~~~~~~~~~~~~~ The list of platforms we support, and the people responsible for them, is here: http://hackage.haskell.org/trac/ghc/wiki/Contributors Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: http://hackage.haskell.org/trac/ghc/wiki/Building Developers ~~~~~~~~~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by Trac: http://hackage.haskell.org/trac/ghc/ Mailing lists ~~~~~~~~~~~~~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://www.haskell.org/mailman/listinfo/glasgow-haskell-users http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see http://www.haskell.org/mailman/listinfo/ Some GHC developers hang out on #haskell on IRC, too: http://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: http://www.haskell.org/ghc/reportabug

3 3