April 2008 - Haskell-Cafe

ANNOUNCE: Galois web libraries for Haskell released
by Don Stewart 23 Apr '08

23 Apr '08

Galois, Inc. is pleased to announce the open source release of a suite of web programming libraries for Haskell! The following libraries are available, providing support for a wide range of Haskell web programming scenarios: * json JSON (JavaScript Object Notation) is a lightweight data-interchange format. It is easy for humans to read and write. It is easy for machines to parse and generate. It is based on a subset of the JavaScript Programming Language, Standard ECMA-262 3rd Edition - December 1999. This library provides a validating parser and pretty printer for converting between Haskell values and JSON. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/json * xml A simple, lightweight XML parser/generator. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/xml * utf8-string A UTF8 layer for IO and Strings. The utf8-string package provides operations for encoding UTF8 strings to Word8 lists and back, and for reading and writing UTF8 without truncation. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/utf8-string * selenium Haskell bindings to communicate with a Selenium Remote Control server. This package makes it possible to use Haskell to write test scripts that exercise web applications through a web browser. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/selenium * curl libcurl is a client-side URL transfer library, supporting FTP, FTPS, HTTP, HTTPS, SCP, SFTP, TFTP, TELNET, DICT, LDAP, LDAPS and FILE. libcurl supports SSL certificates, HTTP POST, HTTP PUT, FTP uploading, HTTP form based upload, proxies, cookies, user+password authentication (Basic, Digest, NTLM, Negotiate, Kerberos4), file transfer resume, http proxy tunneling and more! This package provides a Haskell binding to libcurl. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/curl * sqlite Haskell binding to sqlite3 <http://sqlite.org/>, a light, fast database. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/sqlite * feed Interfacing with RSS (v 0.9x, 2.x, 1.0) and Atom feeds http://hackage.haskell.org/cgi-bin/hackage-scripts/package/feed * mime Haskell support for working with MIME types. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/mime Together these fill in a big chunk of the web programming stack for Haskell. Get the code! You can find all the cabalised packages on hackage.haskell.org. About: Galois <http://galois.com> researches, designs and develops high assurance technologies for security-critical systems, networks and applications. We use Haskell as a primary development tool for producing robust components for a diverse range of clients. Web-based technologies are increasingly important in this area, and we believe Haskell has a key role to play in the production of reliable, secure web software. The culture of correctness Haskell encourages is ideally suited to web programming, where issues of security, authentication, privacy and protection of resources abound. In particular, Haskell's type system makes possible strong static guarantees about access to resources, critical to building reliable web applications. We hope that the release of this suite of libraries to the community will push further the adoption of Haskell in the domain of web programming. This release brought to you by: Iavor Diatchki Trevor Elliott Sigbjorn Finne Andy Gill Eric Mertens Isaac Potoczny-Jones Don Stewart Aaron Tomb

7 10

Re: [Haskell-cafe] Processing XML with HXT
by Uwe Schmidt 23 Apr '08

23 Apr '08

Hi Rodrigo, > Just one more question, I didn't find any example describing how to get the > text information of a XML element in the picklers tutorial. So, if the use case > element is described as follwing: > ... here is a complete example for your use case. Take the following XML data in file "uc.xml" ------------------------ <useCaseModel name="firstUseCaseModel"> <useCase> <id>UC_01</id> <name>Opening ...</name> <description>This use case describes how...</description> </useCase> </useCaseModel> ------------------------ and the following picker and test ------------------------ module Main where import Text.XML.HXT.Arrow type Id = String type Name = String type Description = String data UseCaseModel = UCM Name [UseCase] deriving (Show) data UseCase = UseCase Id Name Description deriving (Show) instance XmlPickler UseCase where xpickle = xpUseCase xpUseCaseModel :: PU UseCaseModel xpUseCaseModel = xpElem "useCaseModel" $ xpWrap ( uncurry UCM , \ (UCM n ucs) -> (n, ucs) ) $ xpPair ( xpAttr "name" xpText ) ( xpList xpUseCase ) xpUseCase :: PU UseCase xpUseCase = xpElem "useCase" $ xpWrap ( uncurry3 UseCase , \ (UseCase i n d) -> (i, n, d) ) $ xpTriple (xpElem "id" xpText) (xpElem "name" xpText) (xpElem "description" xpText) main :: IO () main = do runX ( xunpickleDocument xpUseCaseModel [ (a_validate,v_0) , (a_trace, v_1) , (a_remove_whitespace,v_1) -- !!!!!!!!!! throw away whitespace , (a_preserve_comment, v_0) -- !!!!!!!!!! throw away comments ] "uc.xml" >>> processUseCaseModel >>> xpickleDocument xpUseCaseModel [ (a_indent, v_1) ] "new-uc.xml" ) return () -- the dummy for processing the unpickled data processUseCaseModel :: IOSArrow UseCaseModel UseCaseModel processUseCaseModel = arrIO ( \ x -> do {print x ; return x}) ----------------------- This program will print the internal haskell value and writes the data to "new-uc.xml" Cheers Uwe -- Uwe Schmidt Web: http://www.fh-wedel.de/~si/

1 0

Re: [Haskell] ANNOUNCE: Generic Haskell 1.80 (Emerald)
by Thomas van Noort 23 Apr '08

23 Apr '08

Hello, I took the liberty to move this discussion to the Haskell-Cafe mailing list. Adrian Hey wrote: > Thomas van Noort wrote: >> Pleasant programming, > > Hello, > > This looks like good stuff. But having done all this work it seems > a pity not to go the extra mm and cabalise this and make it buildable > on all platforms (at least ghc supported platforms). You are right, cabalizing the Makefiles implies that Generic Haskell can be build on any platform that is supported by GHC. However, this requires a tremendous amount of effort since the Makefiles of Generic Haskell are enormous. > > The reason I'm interested is this may be useful for the GSoC project > I'm mentoring.. > > http://code.google.com/soc/2008/haskell/about.html > > But as things are, I'd be unlikely to consider introducing a dependency > on this. Even if it built "out of the box" with cygwin (which it > doesn't BTW) I don't really think many windows users will be keen to > install cygwin and learn how to use it just so they can build GH. As you already noticed, there is no Windows binary available for the Emerald release. However, there is one for the Coral release, available from: http://www.generic-haskell.org Although this is an old release of Generic Haskell, this release already supports generic types, which is what you need for your project probably. In the user's guide, there is a small example available which defines a generic type to represent tries. The latest release of Generic Haskell supports generic views for generic types. This allows you to define a generic type that generates efficient balanced tries, as you can read in my Master's thesis :) This requires the use of the balanced view on the type level. Unfortunately, this generic view is not implemented in the Generic Haskell compiler... > > Thanks > -- > Adrian Hey Regards, Thomas

3 2

Laziness and Either
by John Goerzen 23 Apr '08

23 Apr '08

Back when I was working on the logic for the bin-packing solver that I added to MissingH (for use with datapacker), I had a design decision to make: do I raise runtime errors with the input using error, or do I use an Either type to return errors? Initially, for simplicity, I just used error. But when I did a simple refactoring to use Either, it occurred to me that this switch likely had a negative impact on laziness. In this particular algorithm, we cannot tell for sure that we have no errors until we have consumed all items of the input list. This is unlike, say, a safe version of "head" where you can tell whether you have an error just by whether you have an empty list or not. In the case of using "error", we can happily process the data assuming everything will be fine, and raise an error if and when it is encountered. By using Either, however, any pattern match on the Left/Right result is going to force the entire input to be evaluated so that we can know whether or not it had any error. Is this analysis sensible? If so, are there better solutions? BTW, here are links to the code I'm talking about: http://git.complete.org/datapacker?a=blob;f=Scan.hs;h=d4e8ac8d6e883f342096a… line 32-43 -- version that uses error http://git.complete.org/datapacker?a=blob;f=Scan.hs;h=acd53739f5d871a3ce7ae… line 32-46 -- version that uses Either http://git.complete.org/datapacker?a=commitdiff;h=0d4e3ee6c4e5c780009ad5c09… -- diff between them -- John

9 9

Re: [Haskell-cafe] Processing XML with HXT
by rodrigo.bonifacio 23 Apr '08

23 Apr '08

Hi Uwe Schmidt, thanks a lot. Just one more question, I didn't find any example describing how to get the text information of a XML element in the picklers tutorial. So, if the use case element is described as follwing: <useCase> <id>UC_01</id> <name>Opening ...</name> <description>This use case describes how...</description> </useCase> How can I set the id, name and desription of a use case? -- use case data type data UseCaseModel = UCM Name [UseCase] data UseCase = UseCase Id Name Description deriving (Show) -- I tried the following picler implementation -- but I think that it is not correct. instance XmlPickler UseCase where xpickle = xpUseCase xpUseCase :: PU UseCase xpUseCase = xpElem "useCase" $ xpWrap ( \ (i, n, d) -> UseCase i n d, \t -> (ucId t, name t, description t)) $ (xpTriple (xpElem "id" xpText) (xpElem "name" xpText) (xpElem "description" xpText)) > Hi Rodrigo, > > > I´m just starting with HXT. My question is, how can I expose a "use case" from the main function below (the XmlPickler for UseCase has been already defined): > > > > main :: IO () > > main = do > > runX ( xunpickleDocument xpUseCase [ (a_validate,v_0) ], "uc.xml" ) > > return () > > > > For example, if I just want to show the use case contents, how can I call "show" for a retrived use case. > > ------------------------------------- > > 1. version > > main :: IO () > main = do > [x] <- runX ( xunpickleDocument xpUseCase [ (a_validate,v_0) ], "uc.xml" ) > print x > return () > > x is processed outside the arrow > > ------------------------------------- > 2. version > > main :: IO () > main = do > runX ( xunpickleDocument xpUseCase [ (a_validate,v_0) ], "uc.xml" > >>> > arrIO print > ) > return () > > x is processed within an arrow by lifting the print function to then arrow level. > > ------------------------------------ > > There is a new wiki page about picklers > http://www.haskell.org/haskellwiki/HXT/Conversion_of_Haskell_data_from/to_X… > > Cheers, > > Uwe > > -- > > Uwe Schmidt > Web: http://www.fh-wedel.de/~si/ > ----------------------------------- Rodrigo Bonifácio de Almeida Universidade Católica de Brasília - Grupo de Engenharia de Software - JavaComBr (www.ucb.br/java)

1 0

Storable class?
by Galchin, Vasili 23 Apr '08

23 Apr '08

Hello, Examples of instances of the Storable class please. Thank you, Vasili

5 7

Processing XML with HXT
by rodrigo.bonifacio 23 Apr '08

23 Apr '08

Hi all, I´m just starting with HXT. My question is, how can I expose a "use case" from the main function below (the XmlPickler for UseCase has been already defined): main :: IO () main = do runX ( xunpickleDocument xpUseCase [ (a_validate,v_0) ], "uc.xml" ) return () For example, if I just want to show the use case contents, how can I call "show" for a retrived use case. Thanks in advance. Rodrigo.

3 2

(flawed?) benchmark : sort
by Krzysztof Skrzętnicki 23 Apr '08

23 Apr '08

Hi I was playing with various versions of sorting algorithms. I know it's very easy to create flawed benchmark and I don't claim those are good ones. However, it really seems strange to me, that sort - library function - is actually the worse measured function. I can hardly belive it, and I'd rather say I have made a mistake preparing it. The overall winner seems to be qsort_iv - which is nothing less but old sort replaced by mergesort now. Any clues? Regards Christopher Skrzętnicki --- cut here --- [Tener@laptener haskell]$ ghc -O2 --make qsort.hs && ./qsort +RTS -sstderr -RTS > /dev/null [1 of 1] Compiling Main ( qsort.hs, qsort.o ) Linking qsort ... ./qsort +RTS -sstderr (1.0,"iv") (1.1896770400256864,"v") (1.3091609772011856,"treeSort") (1.592515715933153,"vii") (1.5953543402198838,"vi") (1.5961286512637272,"iii") (1.8175480563244177,"i") (1.8771604568641642,"ii") (2.453160634439497,"mergeSort") (2.6627090768870216,"sort") 26,094,674,624 bytes allocated in the heap 12,716,656,224 bytes copied during GC (scavenged) 2,021,104,592 bytes copied during GC (not scavenged) 107,225,088 bytes maximum residency (140 sample(s)) 49773 collections in generation 0 ( 21.76s) 140 collections in generation 1 ( 23.61s) 305 Mb total memory in use INIT time 0.00s ( 0.00s elapsed) MUT time 20.39s ( 20.74s elapsed) GC time 45.37s ( 46.22s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 65.76s ( 66.96s elapsed) %GC time 69.0% (69.0% elapsed) Alloc rate 1,279,723,644 bytes per MUT second Productivity 31.0% of total user, 30.5% of total elapsed --- cut here --- {-# OPTIONS_GHC -O2 #-} module Main where import System.CPUTime import System.IO import System.Environment import System.Random import Data.List( partition, sort ) data Tree a = Node (Tree a) a (Tree a) | Leaf qsort_i [] = [] qsort_i (x:xs) = qsort_i (filter (< x) xs) ++ [x] ++ qsort_i (filter (>= x) xs) qsort_ii [] = [] qsort_ii (x:xs) = let (ls,gt) = partition (< x) xs in qsort_ii ls ++ [x] ++ qsort_ii gt qsort_iii xs = qsort_iii' [] xs qsort_iii' acc [] = acc qsort_iii' acc (x:xs) = let (ls,gt) = partition (< x) xs in let acc' = (x:(qsort_iii' acc gt)) in qsort_iii' acc' ls qsort_v [] = [] qsort_v (x:xs) = let (xlt, xgt ) = foldl (\ (lt,gt) el -> case compare x el of GT -> (el:lt, gt) _ -> (lt, el:gt) ) ([],[]) xs in qsort_v xlt ++ [x] ++ qsort_v xgt -- zmodyfikowany i qsort_vi [] = [] qsort_vi (x:xs) = qsort_vi (filter (\y-> compare x y == GT) xs) ++ [x] ++ qsort_vi (filter (\y-> compare x y /= GT) xs) -- zmodyfikowany iii qsort_vii xs = qsort_vii' [] xs qsort_vii' acc [] = acc qsort_vii' acc (x:xs) = let (ls,gt) = partition (\y-> compare x y == GT) xs in let acc' = (x:(qsort_vii' acc gt)) in qsort_vii' acc' ls -- qsort is stable and does not concatenate. qsort_iv xs = qsort_iv' (compare) xs [] qsort_iv' _ [] r = r qsort_iv' _ [x] r = x:r qsort_iv' cmp (x:xs) r = qpart cmp x xs [] [] r -- qpart partitions and sorts the sublists qpart cmp x [] rlt rge r = -- rlt and rge are in reverse order and must be sorted with an -- anti-stable sorting rqsort_iv' cmp rlt (x:rqsort_iv' cmp rge r) qpart cmp x (y:ys) rlt rge r = case cmp x y of GT -> qpart cmp x ys (y:rlt) rge r _ -> qpart cmp x ys rlt (y:rge) r -- rqsort is as qsort but anti-stable, i.e. reverses equal elements rqsort_iv' _ [] r = r rqsort_iv' _ [x] r = x:r rqsort_iv' cmp (x:xs) r = rqpart cmp x xs [] [] r rqpart cmp x [] rle rgt r = qsort_iv' cmp rle (x:qsort_iv' cmp rgt r) rqpart cmp x (y:ys) rle rgt r = case cmp y x of GT -> rqpart cmp x ys rle (y:rgt) r _ -> rqpart cmp x ys (y:rle) rgt r -- code by Orcus -- Zadanie 9 - merge sort mergeSort :: Ord a => [a] -> [a] mergeSort [] = [] mergeSort [x] = [x] mergeSort xs = let(l, r) = splitAt (length xs `quot` 2) xs in mergeSortP (mergeSort l) (mergeSort r) -- funkcja pomocnicza scalajÄ…ca dwie listy uporzÄ…dkowane w jednÄ… mergeSortP :: Ord a => [a] -> [a] -> [a] mergeSortP xs [] = xs mergeSortP [] ys = ys mergeSortP (x:xs) (y:ys) | x <= y = x:(mergeSortP xs (y:ys)) | otherwise = y:(mergeSortP (x:xs) ys) -- Zadanie 10 - tree sort treeSort :: Ord a => [a] -> [a] -- pointless po raz drugi treeSort = (treeSortInorder . treeSortToTree) treeSortToTree :: Ord a => [a] -> Tree a treeSortToTree [] = Leaf treeSortToTree (x:xs) = let (xlt, xgt) = foldl (\ (lt,gt) el -> case compare x el of GT -> (el:lt, gt) _ -> (lt, el:gt) ) ([],[]) xs in Node (treeSortToTree xlt) x (treeSortToTree xgt) treeSortInorder :: Ord a => Tree a -> [a] treeSortInorder Leaf = [] treeSortInorder (Node l x r) = (treeSortInorder l) ++ [x] ++ (treeSortInorder r) -- end code by Orcus -- big_number = 1000000 :: Int main = do gen <- getStdGen let xs' = randomRs (1::Int, big_number) gen xs <- return (take big_number xs') t1 <- getCPUTime print (qsort_i xs) -- i t2 <- getCPUTime print (qsort_ii xs) -- ii t3 <- getCPUTime print (qsort_iii xs) -- iii t4 <- getCPUTime print (qsort_iv xs) -- iv t5 <- getCPUTime print (qsort_v xs) -- v t6 <- getCPUTime print (qsort_vi xs) -- vi t7 <- getCPUTime print (qsort_vii xs) -- vii t8 <- getCPUTime print (sort xs) -- sort t9 <- getCPUTime print (mergeSort xs) -- mergeSort t10 <- getCPUTime print (treeSort xs) -- treeSort t11 <- getCPUTime let getTimes xs = zipWith (-) (tail xs) xs let timers = [t1,t2,t3,t4,t5,t6,t7,t8,t9,t10,t11] let times = getTimes timers let table = zip times ["i","ii","iii","iv", "v", "vi", "vii", "sort","mergeSort","treeSort"] let sorted = sort table let scaled = map (\(x,n) -> (((fromIntegral x / (fromIntegral $ fst (head sorted)))::Double),n)) sorted let toShow = concatMap (\x-> show x ++ "\n") scaled hPutStr stderr toShow main_small = do gen <- getStdGen let xs' = randomRs (1::Int, 100000) gen xs <- return (take big_number xs') t1 <- getCPUTime print (qsort_iv xs) -- iv t2 <- getCPUTime print (sort xs) -- sort t3 <- getCPUTime print (mergeSort xs) -- mergeSort t4 <- getCPUTime print (treeSort xs) -- treeSort t5 <- getCPUTime let getTimes xs = zipWith (-) (tail xs) xs let timers = [t1,t2,t3,t4,t5] let times = getTimes timers let table = zip times ["iv", "sort","mergeSort","treeSort"] let sorted = sort table let scaled = map (\(x,n) -> (((fromIntegral x / (fromIntegral $ fst (head sorted)))::Double),n)) sorted let toShow = concatMap (\x-> show x ++ "\n") scaled hPutStr stderr toShow hPrint stderr times --- cut here ---

33 117

semi-closed handles
by Abhay Parvate 22 Apr '08

22 Apr '08

Hello, In describing the Handle type, the GHC documentation says (in the System.IO documentation): GHC note: a Handle will be automatically closed when the garbage collector detects that it has become unreferenced by the program. However, relying on this behaviour is not generally recommended: the garbage collector is unpredictable. If possible, use explicit an explicit hClose to close Handles when they are no longer required. GHC does not currently attempt to free up file descriptors when they have run out, it is your responsibility to ensure that this doesn't happen. But one cannot call hClose on Handles on which something like hGetContents has been called; it just terminates the character list at the point till which it has already read. Further the manual says that hGetContents puts the handle in the semi-closed state, and further, A semi-closed handle becomes closed: - if hClose is applied to it; - if an I/O error occurs when reading an item from the handle; - or once the entire contents of the handle has been read. So do I safely assume here, according to the third point above, that it's fine if I do not call hClose explicitly as far as I am consuming all the contents returned by hGetContents? Thanks, Abhay

5 7

Anyone mind proofing a short monad transformers explanation?
by Jack Kelly 22 Apr '08

22 Apr '08

I sent this to a friend who asked me about monad transformers and he reckons it should be saved somewhere. If anyone feels up to giving it a quick fact-check, that'd be great. I'm not sure what to do with it, though. It doesn't seem to be made of the right stuff for a tutorial but I'm not sure what to do with it. --- SNIP --- Basically it's like making a double, triple, quadruple, ... monad by wrapping around existing monads that provide wanted functionality. You have an innermost monad (usually Identity or IO but you can use any monad). You then wrap monad transformers around this monad to make bigger, better monads. Concrete example: Suppose I was writing a server. Each client thread must be of type IO () (that's because forkIO :: IO () -> IO ThreadID)). Suppose also that this server has some configuration that (in an imperative program) would be global that the clients all need to query. > data Config = Config Foo Bar Baz One way of doing this is to use currying and making all the client threads of type Config -> IO (). Not too nice because any functions they call have to be passed the Config parameter manually. The Reader monad solves this problem but we've already got one monad. We need to wrap IO in a ReaderT. The type constructor for ReaderT is ReaderT r m a, with r the shared environment to read from, m the inner monad and a the return type. Our client_func becomes: > client_func :: ReaderT Config IO () We can then use the ask, asks and local functions as if Reader was the only Monad: (these examples are inside do blocks) > p <- asks port (Assuming some function port :: Config -> Int or similar.) To do stuff in IO (or in the general case any inner monad) the liftIO function is used to make an IO function work in this wrapped space: (given h :: Handle, the client's handle) > liftIO $ hPutStrLn h "You lose" > liftIO $ hFlush h IO is once again special. For other inner monads, the lift function does the same thing. Note also that IO has no transformer and must therefore always be the innermost monad. This is all well and good, but the client_func now has type ReaderT Config IO () and forkIO needs a function of type IO (). The escape function for Reader is runReader :: Reader r a -> r -> a and similarly for ReaderT the escape function is runReaderT :: ReaderT r m a -> r -> m a: (Given some c :: Config that's been assembled from config files or the like) > forkIO (runReaderT client_func c) Will do the trick. Monad transformers are like onions. They make you cry but you learn to appreciate them. Like onions, they're also made of layers. Each layer is the functionality of a new monad, you lift monadic functions to get into the inner monads and you have transformerised functions to unwrap each layer. They're also like a present in that regard: in this example we unwrapped the outer wrapping paper to get to the present: an object of type IO (), which lets us make haskell do something.

3 2