May 2009 - Haskell-Cafe

Re: [Haskell-cafe] showing a user defined type
by michael rice 19 May '09

19 May '09

Thanks. I had put together something similar to your first suggestion but tried to use PutStrLn(Show...). I'd also thought of your second suggestion about a dummy show for functions. A little further along in "The Little MLer" the ints function is replaced by other functions like primes and fibs, which also return Links: fun primes(n) = if is_prime(n+1) then Link(n+1,primes) else primes(n+1) fun fibs(n)(m) = Link(n+m,fibs(m)) which are passed to chain_item: fun chain_item(n,Link(i,f)) = if eq_int(n,1) then i else chain_item(n-1,f(i)) which can be called to request the nth (12th) prime number beginning at 1. - chain_item(12,primes(1)); GC #0.0.0.1.3.61: (1 ms) val it = 37 : int - So I guess the answer to your question about whether the function is ever called with a different value may be, yes. Michael --- On Mon, 5/18/09, Ryan Ingram <ryani.spam(a)gmail.com> wrote: From: Ryan Ingram <ryani.spam(a)gmail.com> Subject: Re: [Haskell-cafe] showing a user defined type To: "Brandon S. Allbery KF8NH" <allbery(a)ece.cmu.edu> Cc: "michael rice" <nowgate(a)yahoo.com>, haskell-cafe(a)haskell.org Date: Monday, May 18, 2009, 10:02 PM Unfortunately, you can't derive Show on Chain as defined, because it contains a function: > data Chain = Link Int (Int -> Chain) You can write this: > instance Show Chain where > show (Link n _) = "Link " ++ show n ++ " <fn>" Or you can make a dummy "Show" instance for functions: > instance Show (a -> b) where show _ = "<fn>" > data Chain = Link Int (Int -> Chain) deriving Show One question: Do you expect to ever call the function with a different value? For example: otherChain :: Chain otherChain = case (ints 0) of Link _ f -> f 100 If not, you can replace Chain entirely by [Int], due to laziness, something that's not possible in ML. (Although you can get the same result in ML by using (int * (() -> chain)) instead. -- ryan On Mon, May 18, 2009 at 6:36 PM, Brandon S. Allbery KF8NH <allbery(a)ece.cmu.edu> wrote: > On May 18, 2009, at 21:19 , michael rice wrote: > > *Main> :t ints 0 > ints 0 :: Chain > *Main> ints 0 > > <interactive>:1:0: > No instance for (Show Chain) > > In general, you want to append > deriving Show > to your types. You may also want to be able to input them in ghci, so > instead say > deriving (Show, Read) > -- > brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery(a)kf8nh.com > system administrator [openafs,heimdal,too many hats] allbery(a)ece.cmu.edu > electrical and computer engineering, carnegie mellon university KF8NH > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > >

2 1

Re: [Haskell-cafe] showing a user defined type
by michael rice 19 May '09

19 May '09

Cool! Is there *anything* Haskell *can't* do? Michael --- On Mon, 5/18/09, David Menendez <dave(a)zednenem.com> wrote: From: David Menendez <dave(a)zednenem.com> Subject: Re: [Haskell-cafe] showing a user defined type To: "Ryan Ingram" <ryani.spam(a)gmail.com> Cc: haskell-cafe(a)haskell.org Date: Monday, May 18, 2009, 10:26 PM On Mon, May 18, 2009 at 10:02 PM, Ryan Ingram <ryani.spam(a)gmail.com> wrote: > Unfortunately, you can't derive Show on Chain as defined, because it > contains a function: Sure you can. I just tried the following, and it compiled without complaints. > import Text.Show.Functions > > data Chain = Link Int (Int -> Chain) deriving (Show) The usual warnings about orphan instances apply, but the purpose of the Text.Show.Functions module is to provide a standard Show instance for functions so that libraries (e.g., QuickCheck) don't declare conflicting instances. -- Dave Menendez <dave(a)zednenem.com> <http://www.eyrie.org/~zednenem/> _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

2 1

RE: [Haskell-cafe] Request for feedback: HaskellDB + HList
by Brian Bloniarz 19 May '09

19 May '09

Hi Justin, I updated my changes to apply against that repo, thanks for the pointer. Cool to see new changes to haskelldb, especially all the new unit tests! You can find my updated repo at: http://patch-tag.com/r/haskelldb-hlist Re-reading your email now, I see you asked for a patch, but seeing patch-tag for the first time I got excited and uploaded a whole new repo, whoops. Anyway, I had to do some minor surgery to update to the new version -- everything compiles, but I haven't tested much beyond that yet. Let me know if you have any questions. Thanks, -Brian > I like the direction you are going. I looked into using HList a year > or so ago and I wasn't quite up to it. The latest (unreleased) > version of HaskellDB is on patch-tag at > http://patch-tag.com/r/haskelldb/snapshot/current/content/pretty. > Would you mind creating a patch file against that for easier review? I > won't commit it until you say its ready but I'd like to see what > changes you have made. > > No announcement has been made but I took over maintainership from > Bjorn a few months ago. I hope to get a 1.0 release of HaskellDB out > this summer, and having something new like this in it would be pretty > sweet. > > On Sat, May 16, 2009 at 3:08 PM, Brian Bloniarz <phunge0(a)hotmail.com> wrote: > > Hi, > > > > It's come time to share something that I've been playing around with > > recently: > > a branch of HaskellDB which replaces the home-grown Record code with HList > > records. It's definitely not ready for primetime, but I thought it'd be a > > good > > time to post the code and solicit some feedback from the community. > > > > HaskellDB the concept is very promising, but IMHO the code still falls short > > of that promise. Hopefully this is a small step in the right direction -- > > the > > advantages of using HList: > > * Shared implementation of extensible records > > * Additional features from HList > > * Better error messages for record misuse > > * "Lacks" predicates > > * Simpler code > > > > As an example of how this can be better, a DB insert looks like so: > >> insert db table $ constantRecord $ > >> film .=. "Munchie" .*. > >> director .=. Just "Jim Wynorski" .*. > >> emptyRecord > > The columns need not appear in the same order as in the database. If you > > forget > > a column, you'll get "error: No instance for (Fail (FieldNotFound (Proxy > > Director)))" > > rather than an opaque error. Using the new "insertOpt" function, Maybe > > columns > > will default to Nothing rather than needing to be specified. > > > > The details: > > > > I haven't updated everything, but there's enough to run test/TestCases.hs > > under Postgresql. TestCases is probably the best place to look for examples > > of > > the new syntax for now. > > > > HList had name conflicts with HaskellDB's SQL expression language > > ((.*.), (.++.), etc.) My temporary band-aid is to move the expression > > functions > > to Database.HaskellDB.SqlExpr, and require people to import qualified. > > > > The Attr type is gone, columns labels are untyped now. I also replaced a > > few instances of primitive type-level recursion with HMap/HMapOut. This > > makes > > the code simpler, and the type signatures more complex -- type families > > would > > help a lot here, I think. > > > > Feedback welcome! You can find my darcs tree at: > > > > http://mysite.verizon.net/vzewxzuh/sitebuildercontent/sitebuilderfiles/hask… > > It also requires minor changes to HList, available at: > > > > http://mysite.verizon.net/vzewxzuh/sitebuildercontent/sitebuilderfiles/hlis… > > I'll talk to the HList people about getting those merged. > > > > Thanks! > > > > Brian Bloniarz > > > > > > ________________________________ > > Hotmail® has a new way to see what's up with your friends. Check it out. > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe(a)haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > _________________________________________________________________ Hotmail® has ever-growing storage! Don’t worry about storage limits. http://windowslive.com/Tutorial/Hotmail/Storage?ocid=TXT_TAGLM_WL_HM_Tutori…

1 0

Re: [Haskell-cafe] fast Eucl. dist. - Haskell vs C
by Daniel Schüssler 19 May '09

19 May '09

Hello! On Monday 18 May 2009 14:37:51 Kenneth Hoste wrote: > I'm mostly interested in the range 10D to 100D is the dimension known at compile-time? Then you could consider Template Haskell. I wrote up some code for generating the vector types and vector subtraction/inner product below, HTH. One problem is that I'm using a typeclass and apparently you can't make {-# SPECIALISE #-} pragmas with TH, so let's hope it is automatically specialised by GHC. Greetings, Daniel TH.hs ------------------ {-# LANGUAGE TemplateHaskell #-} {-# OPTIONS -fglasgow-exts #-} module TH where import Language.Haskell.TH import Control.Monad -- Non-TH stuff class InnerProductSpace v r | v -> r where innerProduct :: v -> v -> r class AbGroup v where minus :: v -> v -> v euclidean x y = case minus x y of z -> sqrt $! innerProduct z z -- TH noContext :: Q Cxt noContext = return [] strict :: Q Type -> StrictTypeQ strict = liftM ((,) IsStrict) makeVectors :: Int -- ^ Dimension -> Q Type -- ^ Component type, assumed to be a 'Num' -> String -- ^ Name for the generated type -> Q [Dec] makeVectors n ctyp name0 = do -- let's assume ctyp = Double, name = Vector for the comments -- generate names for the variables we will need xs <- replicateM n (newName "x") ys <- replicateM n (newName "y") let name = mkName name0 -- shorthands for arithmetic expressions; the first takes expressions, -- the others take variable names sumE e1 e2 = infixE (Just e1) [|(+)|] (Just e2) varDiffE e1 e2 = infixE (Just (varE e1)) [|(-)|] (Just (varE e2)) varProdE e1 e2 = infixE (Just (varE e1)) [|(*)|] (Just (varE e2)) conPat vars = conP name (fmap varP vars) -- > data Vector = Vector !Double ... !Double theDataD = dataD noContext name [] -- no context, no params [normalC name (replicate n (strict ctyp))] [''Eq,''Ord,''Show] -- 'deriving' clause innerProdD = -- > instance InnerProductSpace Vector Double where ... instanceD noContext ( conT ''InnerProductSpace `appT` conT name `appT` ctyp) -- > innerProduct = ... [valD (varP 'innerProduct) (normalB -- \(Vector x1 x2 ... xn) (Vector y1 y2 ... yn) -> (lamE [conPat xs, conPat ys] -- x1*y1 + .... + xn*yn + 0 (foldl sumE [|0|] $ zipWith varProdE xs ys) )) [] -- no 'where' clause ] abGroupD = instanceD noContext ( conT ''AbGroup `appT` conT name) -- > minus = ... [valD (varP 'minus) (normalB -- \(Vector x1 x2 ... xn) (Vector y1 y2 ... yn) -> (lamE [conPat xs, conPat ys] -- Vector (x1-y1) ... (xn-yn) (foldl appE (conE name) $ zipWith varDiffE xs ys) )) [] -- no 'where' clause ] sequence [theDataD,innerProdD,abGroupD] Main.hs ------------------ {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE MultiParamTypeClasses #-} module Main where import TH $(makeVectors 3 [t|Double|] "Vec3") main = print $ euclidean (Vec3 1 1 1) (Vec3 0 0 0)

2 2

fast Eucl. dist. - Haskell vs C
by Kenneth Hoste 19 May '09

19 May '09

Hello, For a while now, I've been trying to come up with a fast Haskell-only function which implements Euclidean distance in n-dimensional space. So far, I've been disappointed by the performance of my best effort in Haskell, compared to C. I'm hoping some of the Haskell experts and/or performance gurus on this list can help me out on resolving this, and also maybe shed some light on some strange (imho) things I've run into. My current best try uses the uvector package, has two 'vectors' of type (UArr Double) as input, and relies on the sumU and zipWithU functions which use streaming to compute the result: dist_fast :: UArr Double -> UArr Double -> Double dist_fast p1 p2 = sumDs `seq` sqrt sumDs where sumDs = sumU ds ds = zipWithU euclidean p1 p2 euclidean x y = d*d where d = x-y I've been benchmarking this function against various alternatives using the MicroBench [1] package, which allows to get accurate timings of single function calls. I've also mimicked the MicroBench approach in pure C, to get comparable timings for a C-only implementation. The C-only function is quite straightforward: double dist(int dim, double* p1, double* p2){ int i; double d = 0.0; for(i=0; i < dim; i++){ d += (p1[i] - p2[i])*(p1[i] - p2[i]); } return sqrt(d); } (Note that the optimizer takes care of the p1-p2 operation appearing twice in the code). All code is attached if you'd like to play around with it. All numbers reported below are using GHC 6.10.2 and gcc 4.3.3 on Linux/x86. The compilation details can be found in the Makefile attached, but in short, I'm using -O2 -fexcess-precision or -O2 -fexcess-precision -fvia-C -optc-O3 with GHC, and -O3 with gcc. Now the bad news: for small dimensions, e.g. 2D/3D-space, the dist_fast function is 70-240x slower than a pure C implementation, depending on the architecture. For example, in 2D-space on an Intel Pentium 4 (3.0GHz, 1M L2 cache), a single call to dist_fast takes about 1.75 microseconds (or 0.00000175s), while a call to dist_c (C implementation of Eucl. dist), takes about 0.025 microseconds (70x slowdown). On a Core 2 2.5GHz with 6MB L2 this maps to 1.9 and 0.008 microseconds, resp. (i.e. 240x slower), while on a Core i7 2.66GHz with 8MB L2 the numbers are 1.53 and 0.011 microseconds (i.e. 140x slower). For larger dimensions, the gap becomes less big, but is still worrying: 10D: 40-110x; 100D: 10-17x; >1kD: 2.5x-6x. I'm mostly interested in the range 10D to 100D, so seeing that Haskell is over 10x and up to 100x slower than C is kind of making me cry. I've tried some things to improve on this without much luck, on the contrary: *) Marking dist_fast for inlining makes things worse; in general the inlined version is 2x slower for low dimensionality, and even 5x slower for larger dimensionality. This was somewhat surprising to me... *) In a moment of weakness, I used the Foreign Function Interface to call the dist_c C-only implementation from Haskell. Unfortunately, there seems to be a lot of overhead in calling dist_c from Haskell. Most of the performance gain from using C melts away, and sometimes the performance of the FFI'd dist_c is 15-30% worse than the native dist_fast version (especially at low dimensionality). Only for the largest dimensionalities (10k-100kD), the FFI'd version reaches the performance of the native C approach. But, since I'm mostly interested in the 10-100D range, this is of little use to me. One thing I noticed is that compiling through C using -fvia-C -optc-O3 might be a bad idea, depending on your system. On an Intel Pentium 4 system, -fvia-C -optc-O3 was giving me a speedup of up 70% (large dim.), while on Core 2 and Core i7 it resulted in a slowdown of 15-20% ! I was using roughly equal versions of GCC with this, i.e. a self-bootstrapped GCC 4.3.x. So, my question to the list if simple: how can I get better performance out of a Haskell-only approach? Any comments/suggestions are highly appreciated. I'd prefer a Haskell-only approach, but my main concern is speed. The Euclidean distance function will be used quite heavily in various tools. I currently have a C-version of some of the tools, but the amount of code that is needed for those tools is becoming ridiculously big. I believe using Haskell will allow me to come up with a more easy to maintain code base. However, I don't want to pay a huge price for this in terms of performance. greetings, Kenneth [1] MicroBench: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/microbench -- Kenneth Hoste Paris research group - ELIS - Ghent University, Belgium email: kenneth.hoste(a)elis.ugent.be website: http://www.elis.ugent.be/~kehoste blog: http://boegel.kejo.be

5 14

Re: Haskell-Cafe Digest, Vol 69, Issue 38
by Tom Lokhorst 19 May '09

19 May '09

These QuickCheck properties don't really test your sort function. The `a' type variable will be instantiated to (). So you will test with lists of units, like so: ghci> quickCheck (\xs -> isSorted (reverse xs)) OK, passed 100 tests. This can be simply solved by added a more specific type signature: isSorted :: [Int] -> Bool Surly, if the sort function works for Ints, it'll work for any Ord a. - Tom > ---------- Forwarded message ---------- > From: Ryan Ingram <ryani.spam(a)gmail.com> > To: Eugene Kirpichov <ekirpichov(a)gmail.com> > Date: Mon, 18 May 2009 13:57:04 -0700 > Subject: Re: [Haskell-cafe] Haskell in 3 Slides > On Mon, May 18, 2009 at 11:33 AM, Eugene Kirpichov <ekirpichov(a)gmail.com> wrote: >> The main bullet point is missing: Correctness. >> >> How could we have forgotten quickcheck? >> >>> quickCheck (\xs -> sort (sort xs) == sort xs) >> OK, 100 tests passed. > > I like this, but given that you have a whole slide, I might write this: > > isSorted :: Ord a => [a] -> Bool > isSorted [] = True > isSorted [x] = True > isSorted (x:y:rest) = x <= y && isSorted (y:rest) > >> quickCheck (\xs -> isSorted (sort xs)) > OK, 100 tests passed. > > Or, if you want to lead into a talk about fusion and/or higher order functions: > > isSorted [] = True > isSorted (x:xs) = snd $ foldl' check (head x, True) xs where > check (prevElem, restSorted) thisElem = (thisElem, prevElem <= > thisElem && restSorted) > > -- ryan >

1 0

[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

GUIs, FRP, (Delimited) Continuations and Zippers
by Günther Schmidt 19 May '09

19 May '09

Hi all, In my app, there is one part which has a rather complicated GUI logic, it involves n drop downs with n choices each. Whenever the current selection in one of the drop downs changes by user interaction, the other (n-1) drop downs need to be notified and their item list need to possible change too. Now I have managed to code all this and it actually behaves correctly. But I'm also using tons of IORefs and tons of bookkeeping code for it. While I'd not be ashamed to show any other part of my code to another Haskeller, this part of the code is the most clumsiest I've ever written. And I have no clue if that piece of code *can* be written in any other way, ie. without the tons of IORefs and bookkeeping. The GUI library is WXHaskell. In the last few days I read up on Conal Elliotts FRP stuff (reactive) but also on Olegs ZFS (Zippers, Delimited Continuations), the latter leaving me totally baffled. Could either of those approaches (FRP / Delimited Continuations) be a solution for implementing complex GUI code? Günther

2 1

GUIs, FRP, (Delimited) Continuations and Zippers
by oleg＠okmij.org 19 May '09

19 May '09

> Could either of those approaches (FRP / Delimited Continuations) be a > solution for implementing complex GUI code? I think the answer is generally yes; I have tried writing a user interface which has a form with several controls; a change in one control may affect all other controls on the form (or change the form). I have tried it for a particular GUI: the web page -- displayed in a browser interacting with a CGI script. The choice of CGI was deliberate because it is harder than FastCGI: it requires the ability to save the state of the interaction. The continuation must outlive its process. The point I was trying to make is that the GUI is programmed as if it were a uncursed console application: you send one question, get a reply, send another question, etc. With a GUI, questions are sent in parallel and answers are delivered in any order; yet the programmer can still think he deals with a regular console application; as if the interaction never happens and the program merely reads the data from a file. http://okmij.org/ftp/Computation/Continuations.html#shift-cgi It was done in OCaml though (because OCaml has native persistent delimited continuations).

1 0

Lawvere papers
by Vasili I. Galchin 19 May '09

19 May '09

Hello, I know that some Lawvere papers are available on TAC, but is there a list of all Lawvere papers online and where? Kind regards, Vasili

1 0