April 2009 - Haskell-Cafe

HDBC Oracle bindings(?/!)
by Thiago Arrais 15 Sep '09

15 Sep '09

Are there Oracle bindings for HDBC anywhere? The HDBC project page talks about Oracle backends but there isn't an Oracle-specific driver listed (I assume one can reach an Oracle backend through the ODBC interface?). I started writing Oracle bindings for HDBC based on the Takusen code. It was done mostly for playing than for anything else and certainly isn't production ready, but it is available in a darcs repo at http://thiagoarrais.com/repos/hdbc-oracle in case anyone is interested. This code isn't ready for prime time yet and I'm looking for some that *is*. Is there such a thing already? Cheers, Thiago Arrais -- Enjoy Chaos - http://blog.thiagoarrais.com Thoughts, ideas and useless ranting about software development and technology

4 6

[ANNOUNCE] hgettext 0.1.10 - last major release
by Vasyl Pasternak 10 Aug '09

10 Aug '09

Hello, I've uploaded last (and latest) significant version on hgettext module. Currently it works fine, and has bindings to all gettext functions (from libintl.h). Next versions will be only bug fixes of this version. GNU GetText allows you only to create simple, standalone desktop applications for Linux, to make something complex you should use different trick, fortunately Haskell could do these tricks much easier than other languages (if you want to see, how to build Gtk application, which supports run time language switching, and shows information on two languages simultaneously you could download example from http://hgettext.googlecode.com/files/gtk-hello-0.0.2.tar.gz , or read about it from http://progandprog.blogspot.com/2009/04/multilingual-ui-and-dynamic-languag…) I don't see any strong reasons to write any combinators over this basic bindings. Haskell needs more powerful internationalization library, and I am plan to design it, but it will be completely different from gettext principles, so this library will be released with another name. CHANGELOG: * Added '--version' command line parameter to hgettext tool * Added support for literate haskell files to hgettext tool * Changed all functions to throw IOError when they fails instead of return Nothing * Added bindings for: ngettext, dgettext, dngettext, dcgettext and dcngettext functions -- Best regards, Vasyl Pasternak

3 2

ANNOUNCE: first Grapefruit release
by Wolfgang Jeltsch 17 Jul '09

17 Jul '09

Dear friends of Haskell and Functional Reactive Programming, its my pleasure to announce the first official release of Grapefruit, a library for Functional Reactive Programming (FRP) with a focus on user interfaces. With Grapefruit, you can implement reactive and interactive systems in a declarative style. User interfaces are described as networks of communicating widgets and windows. Communication is done via different kinds of signals which describe temporal behavior. Grapefruit consists of five packages with several interesting features: grapefruit-frp: Functional Reactive Programming core * The FRP implementation uses a hybrid push/pull-based approach. * Signals can be memoized by binding them to variables – like ordinary data structures. * Merging of event streams combines simultaneous events properly. * Signals cannot behave differently by starting them at different times. The type system is used to enforce proper aging of signals. grapefruit-records: A record system for Functional Reactive Programming * Input records can specify fields as being required or optional. * Uninteresting output fields can be ignored. The set of interesting fields is specified by pattern matching. grapefruit-ui: Declarative user interface programming * The interface for UI programming is platform-independent and can be implemented on top of different UI toolkits. * A concrete implementation can be selected at compile time or runtime. grapefruit-ui-gtk: GTK+-based implementation of the general UI interface * Gtk2Hs is used internally. grapefruit-examples: examples demonstrating features of Grapefruit * Circular communication and switching are demonstrated. Support for the following is planned for the future: * signals with incremental updates * user interfaces with changing structure * more kinds of UI components * graphical animations Further information about Grapefruit is available on its wiki page at <http://haskell.org/haskellwiki/Grapefruit>. If you have questions, applause or criticism, please get in touch with me. Wolfgang Jeltsch Principal Grapefruit developer

6 10

Re: [Haskell] ANNOUNCE: first Grapefruit release
by Wolfgang Jeltsch 17 Jul '09

17 Jul '09

[redirecting to haskell-cafe] Am Sonntag, 15. Februar 2009 00:25 schrieben Sie: > Hi Wolfgang, > > I was wondering if I can use FLTK as GUI backend for Grapefruit? This should be possible in principal. It just could be that my assumptions about how widgets are created and composed were too tight so that Grapefruit’s general interface doesn’t fit FLTK. In this case, please just tell me and I will try to make the interface more general. > I believe for this to make it happen, I would have to output FLTK's C++ > into C then create bindings for Haskell (via FFI). Is that doable or an > quite tall order? Recently, a student of mine has written a program which generates a Haskell Qt binding fully automatically from Qt header files. The generated binding consists of three layers. The first layer is C++ code which reexports Qt’s functionality as a pure C interface. The C interface is ugly for humans and not type safe (because C doesn’t know classes). The second layer consists of a couple of FFI declarations. The third layer is Haskell code which provides a nice interface similar to the original C++ interface. I still have to get the source code of the binding generator from that student but I hope this will happen soon. I want to publish it then on the web. It hope that it is possible to reuse this binding generator for other C++ libraries. > Jamie Clark Best wishes, Wolfgang

2 2

[Haskell] ANNOUNCE: ChristmasTree 0.1 (excuses for second attempt)
by S.Doaitse Swierstra 07 Jul '09

07 Jul '09

We are pleased to announce the availability of the package "ChristmasTree", which contains the code associated with our paper at the last Haskell symposium: @inproceedings{1411296, author = {Marcos Viera and S. Doaitse Swierstra and Eelco Lempsink}, title = {Haskell, do you read me?: constructing and composing efficient top-down parsers at runtime}, booktitle = {Haskell '08: Proceedings of the first ACM SIGPLAN symposium on Haskell}, year = {2008}, isbn = {978-1-60558-064-7}, pages = {63--74}, location = {Victoria, BC, Canada}, doi = {http://doi.acm.org/10.1145/1411286.1411296}, publisher = {ACM}, address = {New York, NY, USA}, } The name of the package stands for: "Changing Haskell's Read Implementation Such That by Manipulating Abstract Syntax Trees it Reads Expressions Efficiently" which, given the time of year, seems appropriate. Feel free to download and unpack this "present" at what for the Dutch is called "Sinterklaasavond" (http://en.wikipedia.org/wiki/Sinterklaas) Arthur Baars Marcos Viera Eelco Lempsink Doaitse Swierstra PS: the package uses our library supporting transformation of typed abstract syntax, which we placed in a separate package TTTAS

2 1

Haskell EDSL to generate SQL?
by Günther Schmidt 14 Jun '09

14 Jun '09

Hi, I tried to solve some large data processing solely in Haskell so I could avoid lots of eventually very long and complex SQL statements. Unfortunately, as was to be expected, that approach doesn't scale. So I do need an SQL backend. But I hope to be able to use an DSL from which I can automatically generate SQL-Strings instead of writing the SQL statements literally. Has anyone else taken a similar approach? Günther

3 5

I love purity, but it's killing me.
by Tom Hawkins 09 Jun '09

09 Jun '09

I've been programming with Haskell for a few years and love it. One of my favorite applications of Haskell is using for domain specific languages. However, after designing a handful of DSLs, I continue to hit what appears to be a fundamental hurdle -- or at least I have yet to find an adequate solution. My DSLs invariably define a datatype to capture expressions; something like this: data Expression = Add Expression Expression | Sub Expression Expression | Variable String | Constant Int deriving Eq Using the datatype Expression, it is easy to mass a collections of functions to help assemble complex expressions, which leads to very concise programs in the DSL. The problem comes when I want to generate efficient code from an Expression (ie. to C or some other target language). The method I use invovles converting the tree of subexpressions into an acyclic graphic to eliminate common subexpressions. The nodes are then topologically ordered and assigned an instruction, or statement for each node. For example: let a = Add (Constant 10) (Variable "i1") b = Sub (Variable "i2") (Constant 2) c = Add a b would compile to a C program that may look like this: a = 10 + i1; b = i2 - 2; c = a + b; The process of converting an expression tree to a graph uses either Eq or Ord (either derived or a custom instance) to search and build a set of unique nodes to be ordered for execution. In this case "a", then "b", then "c". The problem is expressions often have shared, equivalent subnodes, which dramatically grows the size of the tree. For example: let d = Add c c e = Add d d -- "e" now as 16 leaf nodes. As these trees grow in size, the equality comparison in graph construction quickly becomes the bottleneck for DSL compilation. What's worse, the phase transition from tractable to intractable is very sharp. In one of my DSL programs, I made a seemingly small change, and compilation time went from milliseconds to not-in-a-million-years. Prior to Haskell, I wrote a few DSLs in OCaml. I didn't have this problem in OCaml because each "let" expression was mutable, and I could use the physical equality operator to perform fast comparisons. Unfortunately, I have grown to love Haskell's type system and its lack of side effects, and could never go back. Is there anything that can be done to dramatically speed up comparisons, or is there a better approach I can take to extract common subexpressions? I should point out I have an opportunity to get Haskell on a real industrial application. But if I can't solve this problem, I may have to resort to far less eloquent languages. :-( Thanks for any and all help. -Tom

17 36

Strange type error with associated type synonyms
by Peter Berry 28 May '09

28 May '09

> {-# LANGUAGE TypeFamilies, TypeSynonymInstances, ScopedTypeVariables #-} The following is a class of memo tries indexed by d: > class Fun d where > type Memo d :: * -> * > abst :: (d -> a) -> Memo d a > appl :: Memo d a -> (d -> a) > -- Law: abst . appl = id > -- Law: appl . abst = id (denotationally) Any such type Memo d is naturally a functor: > memo_fmap f x = abst (f . appl x) The type of memo_fmap (as given by ghci) is (Fun d) => (a -> c) -> Memo d a -> Memo d c. (Obviously this would also be the type of fmap for Memo d, so we could declare a Functor instance in principle.) If we add this signature: > memo_fmap' :: Fun d => (a -> b) -> Memo d a -> Memo d b > memo_fmap' f x = abst (f . appl x) it doesn't type check: TypeSynonymTest.hs:14:17: Couldn't match expected type `Memo d1 b' against inferred type `Memo d b' In the expression: abst (f . appl x) In the definition of `memo_fmap'': memo_fmap' f x = abst (f . appl x) TypeSynonymTest.hs:14:32: Couldn't match expected type `Memo d a' against inferred type `Memo d1 a' In the first argument of `appl', namely `x' In the second argument of `(.)', namely `appl x' In the first argument of `abst', namely `(f . appl x)' Failed, modules loaded: none. As I understand it, the type checker's thought process should be along these lines: 1) the type signature dictates that x has type Memo d a. 2) appl has type Memo d1 a -> d1 -> a for some d1. 3) we apply appl to x, so Memo d1 a = Memo d a. unify d = d1 But for some reason, step 3 fails. If we annotate appl with the correct type (using scoped type variables), it type checks: > -- thanks to mmorrow on #haskell for this > memo_fmap'' :: forall a b d. Fun d => (a -> b) -> Memo d a -> Memo d b > memo_fmap'' f x = abst (f . (appl :: Memo d a -> d -> a) x) My ghc is 6.8.2, but apparently this happens in 6.10 as well. -- Peter Berry <pwberry(a)gmail.com> Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html

11 26

Template Haskell very wordy w/r/t Decs and Types
by Ross Mellgren 28 May '09

28 May '09

Hi all, I'm writing a small module that exposes a template haskell splice that takes a (very simplified) C struct definition and builds: - A data type definition, - an instance for Data.Binary.Binary, - and optionally a pretty print function for it However, it seems to do this I have to write a bunch of really ugly code that builds up the TH data structures "by hand" because quoting only works with splices for expressions, or so it seems. For example, to generate the binary instance I have this code: import qualified Language.Haskell.TH as TH -- tyname is the name of the data type I've already created, as a TH.Name -- tempnames is a list of temporary variable names that are used in lambda patterns -- fields is a list of tuples describing each field -- makeGetExp recursively builds a monadic computation consisting mostly of Binary.getWord32be >>= \ tempvar -> ... binaryInstDec <- liftM (TH.InstanceD [] (TH.AppT (TH.ConT $ TH.mkName "Data.Binary.Binary") (TH.ConT tyname))) [d| get = $(makeGetExp (reverse $ zip fields tempnames) returnExp) put = undefined |] I'd really rather write: binaryInstDec <- [d| instance Binary.Binary $(tyname) where get = $(makeGetExp (reverse $ zip fields tempnames) returnExp) put = undefined |] But GHC gives me a syntax error on the tyname splice. The docs seem to indicate this is the way it is -- that splices in type locations is plain not implemented. My question is whether or not this is just the way it is, and people writing TH declaration splices tend to have to start manually assembling a bunch of it, or is there some trick I've missed? Perhaps even better are there some tricks that people tend to use to make this less painful? I did try using some of the lowercased monadic constructors in Language.Haskell.TH.Lib but I didn't seem to get anything more succint out of it. -Ross P.S. This is for a one-off weekend project, and the code is fugly, so I'm not posting it in its entirety here. If you want the whole module and are willing not to laugh, I'd be glad to send it along ;-) Background: I'm doing this because I'm writing a tool to snoop around the filesystem structures of HFS+ to try and help a friend recover some data off a sufficiently dead drive that fsck doesn't want to touch it, and I don't want to pay money just to find out the drive is too toasty to pull out the data. In any case, the HFS+ docs have a bunch of C struct definitions that comprise the structures, and I got tired of hand-writing data definitions and binary instances, so I figured I'd make TH do it for me.

4 4

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

19 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

9 25