April 2010 - Haskell-Cafe

Network: buffering troubles
by Yves Parès 07 Apr '10

07 Apr '10

Hello, I have isolated a problem when using (lazy) ByteStrings through the network (GHC 6.12.1, Ubuntu 9.10 32bits): Here is my client: http://old.nabble.com/file/p28162932/Client.hs Client.hs And my server: http://old.nabble.com/file/p28162932/Server.hs Server.hs The server holds until the client closes the connection, even if I flush the handle on the client side after writing or even if I turn off buffering on both sides. ----- Yves Parès Live long and prosper -- View this message in context: http://old.nabble.com/Network%3A-buffering-troubles-tp28162932p28162932.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

1 2

hsql repository
by Daniil Elovkov 07 Apr '10

07 Apr '10

Hello I've looked at hsql-* packages at hackage and found that they have progressed to 1.8.1. However, as always there is no hsql-oracle on hackage. It was usually found in the repository. But I can't find where the repository is. Places, like code.haskell.org and htoolkit.sourceforge.net seem to have the older 1.7 version. Can somebody point me to the repository? Is there any chance that hsql-oracle compiles with new hsql? Thanks Daniil Elovkov

2 1

Break Function Using Lazy Pairs
by aditya siram 07 Apr '10

07 Apr '10

Hi all, For the past couple of weeks I've been trying to understand tying-the-knot style programming in Haskell. A couple of days ago, Heinrich Apfelmus posted the following 'break' function as part of an unrelated thread: break [] = ([],[]) break (x:xs) = if x == '\n' then ([],xs) else (x:ys,zs) where (ys,zs) = Main.break xs I've stepped through the code manually to see if I understand and I'm hoping someone will tell me if I'm on the right track: -- break "hi\nbye" = -- let f1 = (break "i\nbye") -- = let f2 = (break "\nbye") -- = ([],"bye") -- ('i' : fst f2, snd f2) => ('i' : [], "bye") -- ('h' : fst f1, snd f1) => ('h' : 'i' : [], "bye") -- => ("hi","bye") -deech

2 1

Crypto: PC1 - Cipher?
by Günther Schmidt 07 Apr '10

07 Apr '10

Hello, does anyone know what the PC1-cipher is and if there is a Haskell implementation? Günther

1 0

Re: HXT Namespaces and XPath
by Uwe Schmidt 07 Apr '10

07 Apr '10

Hi Mads, > In HXT, namespace prefixes bound by an XML document are valid in the > context of an XPath. How do avoid that? > > An example program will clarify: > > simpleXml :: String > simpleXml = "<soap:Body xmlns:soap=\"http://www.w3.org/2003/05/soap-envelope\"/>" > > nsEnv :: [(String, String)] > nsEnv = [ ("s" , "http://www.w3.org/2003/05/soap-envelope") ] > > evalXPath :: String -> String -> [XmlTree] > evalXPath xpath xml = > runLA ( xread > >>> propagateNamespaces > >>> getXPathTreesWithNsEnv nsEnv xpath > ) xml > > Here: > > evalXPath "//s:Body" simpleXml == > evalXPath "//soap:Body" simpleXml > > Even though I only mentions the prefix "s" (and not "soap") in the > function nsEnv. When working with namespaces in XML, the prefixes are not longer significant. After namespace propagation every name in the XML document is identified by a qualified name. This is a pair consisting of the namespace URI and the local part. The prefixes become irrelevant. A namespace aware XPath expression needs a namespace environment, as given in the example, to construct these qualified names for the names in the XPath expression. So the results of both evalXPath calls in your example must be the same. > I do not want the XPath to see prefixes declared in the xml-document, as > it means that two semantically similar XML documents can get different > results when applied to the same XPath. If you intend, that the prefixes are significant, then you should not work with namespace propagation. If namespaces are not propagated, all names occurring in the document are taken as they are. That means "s:Body" is different from "soap:Body". For solving your tasks there could be 2 ways: 1. don't use namespaces, no propagateNamespaces, no getXPathTreesWithNsEnv, use the prefixes instead. Disadvantage: the prefixes become significant. If prefixes change, the semantics changes. 2. Use propagateNamespaces and getXPathTreesWithNsEnv, but select all nodes via the namespace URIs, not via the prefixes. If you want to output the manipulated XML parts and use standard prefixes for the namespaces, then use the namespace manipulation functions in http://hackage.haskell.org/packages/archive/hxt/latest/doc/html/Text-XML-HX… Cheers, Uwe

3 5

[haskell.org Google Summer of Code] Student Applications Due Friday!
by Edward Kmett 07 Apr '10

07 Apr '10

This is a friendly reminder that student applications for the summer of code are due to Google by Friday, April 9th. http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2010/timel… That is just *3 days* from now! Keep in mind that while we've been tracking general interest in different projects through the trac, the application doesn't count unless you submit it to Google at http://socghop.appspot.com/gsoc/program/home/google/gsoc2010 While all details of the application do not need to be finalized, as much of the information from http://hackage.haskell.org/trac/summer-of-code/wiki/StudApply2010 as possible should probably be included in your application. If you are stuck and having a hard time thinking of ideas, I highly recommend the excellent guide that Don Stewart posted recently: http://donsbot.wordpress.com/2010/04/01/the-8-most-important-haskell-org-gs… I'd also recommend taking a look through the trac at http://hackage.haskell.org/trac/summer-of-code/report/1 to gauge interest. Please email me if you have any questions or concerns. -Edward Kmett

2 1

Why does Haskell not infer most general type?
by Job Vranish 06 Apr '10

06 Apr '10

Is haskell supposed to always infer the most general type (barring extensions)? I found a simple case where this is not true: f _ = undefined where _ = y :: Int -> Int y x = undefined where _ = f x Haskell infers the types of 'y' and 'f' as: f :: Int -> a y :: Int -> Int This confused me at first, but after thinking about it a while it seemed to make sense. But then my friend John pointed out that you can add type sigs for 'f' and 'y': f :: a -> b y :: a -> b and have it still typecheck! This thoroughly confused me. Why does haskell not infer the most general type for these functions? Is it a limitation of the algorithm? a limitation of the recursive let binding? Any insight would be appreciated :) - Job

7 9

GSOC Haskell Project
by Mihai Maruseac 06 Apr '10

06 Apr '10

Hi, I'd like to introduce my idea for the Haskell GSOC of this year. In fact, you already know about it, since I've talked about it here on the haskell-cafe, on my blog and on reddit (even on #haskell one day). Basically, what I'm trying to do is a new debugger for Haskell, one that would be very intuitive for beginners, a graphical one. I've given some examples and more details on my blog [0], [1], also linked on reditt and other places. This is not the application, I'm posting this only to receive some kind of feedback before writing it. I know that it seems to be a little too ambitious but I do think that I can divide the work into sessions and finish what I'll start this summer during the next year and following. [0]: http://pgraycode.wordpress.com/2010/03/20/haskell-project-idea/ [1]: http://pgraycode.wordpress.com/2010/03/24/visual-haskell-debugger-part-2/ Thanks for your attention, -- Mihai Maruseac

5 13

HXT error handling
by Mads Lindstrøm 06 Apr '10

06 Apr '10

Hi I am trying to use HXT to evaluate XPath expressions. The XPath expressions are not specified by myself, but by users of my program. However, the idea behind HXT's error handling confuses me. Maybe somebody can enlighten me. This program fragment: evalXPath :: String -> String -> [XmlTree] evalXPath xpath xml = runLA ( xread >>> propagateNamespaces >>> getXPathTrees xpath ) xml seems to work fine, except when it comes to error handling. If the xml-string is malformed, the error is simply ignored and the evalXPath-function just returns an empty list. I can understand what happens. 'getXPathTrees xpath' tries to match the xpath to a XmlTree which represents a parse error, and it therefore never matches anything. What I do not understand, is when this behavior would be desirable. Or why do the error in 'xread' not propagate throughout the arrow, similar to how: foobar :: Either String Int foobar = do _ <- fail "Some failure" return 2 the error in 'foobar' would propagate and 'foobar = Left "Some failure"'. What if the xpath-parameter contains an invalid XPath expression? Well, then the output depends upon both the xpath and the xml -parameters. That is: length (evalXPath "/...../" " <foo/> ") == 3 whereas length (evalXPath "/...../" "<foo/>") == 1 Which just seems strange to me. If we add a getText to evalXPath: evalXPath :: String -> String -> [String] evalXPath xpath xml = runLA ( xread >>> propagateNamespaces >>> getXPathTrees xpath >>> getText -- added here ) xml Then an error in the xpath-parameter will be hidden by the getText function, similar to how 'getXPathTrees xpath' ignores errors in the xread function. Again, I understand what happens, I just cannot see why it is designed as it is. What I really would like was functions like: parseStr :: (Monad m) => String -> m XmlTrees parseStr xml = case Parsec.xread xml of (x:xs) -> if (Dom.isError x) then fail "Could not parse tree" else return (x:xs) [] -> fail "No XML tree resultet from parsing XML" And a similar function for the XPath. This could also speed up my program, as I would not parse the same XPath again and again. A stand-alone function to parse an XPass expression, would also make it easy to create a Template Haskell parse-xpath-function, that gave compile-time error messages and increased performance for XPath expression know at compile-time. Regards, Mads Lindstrøm

2 3

[OT?] Haskell-inspired functions for BASH
by Patrick LeBoutillier 06 Apr '10

06 Apr '10

Hi all, I've been studying Haskell for about a year now, and I've really come to like it. In my daily work I write a lot of BASH shell scripts and I thought I'd try add some of the haskell features and constructs to BASH to make my scripting life a bit easier. So I've been working on a small BASH function library that implements some basic functional programming building blocks. Note: There is no actual Haskell code involved here. I put up the full manpage here: http://hpaste.org/fastcgi/hpaste.fcgi/view?id=24564 Source is here: http://svn.solucorp.qc.ca/repos/solucorp/bashkell/trunk/trunk/ All this is very prototypical, but here is an example of some of the stuff I've got so far (map, filter, foldr): $ ls data 1.txt 2.txt # basic map, argument goes on the command line $ ls -d data/* | map basename 1.txt 2.txt # map with lambda expression $ ls -d data/* | map '\f -> basename $f .txt' 1 2 # simple filter, also works with lambda $ ls -d data/* | map basename | filter 'test 1.txt =' 1.txt # sum $ ls -d data/* | map '\f -> basename $f .txt' | foldr '\x acc -> echo $(($x + $acc))' 0 3 Basically I'm looking for a bit of feedback/info: - Does anyone know if there are already similar projets out there? - Does anyone find this interesting? - Any other comment/suggestion/feedback - Where's a good place to promote such a project? Thanks a lot, Patrick LeBoutillier -- ===================== Patrick LeBoutillier Rosemère, Québec, Canada

9 12