- Haskell-Cafe - Haskell.org

Rewrite rules not firing for rules matching multiple instance methods
by Acshi Haggenmiller 22 Mar '12

22 Mar '12

Hi, I have some rewrite rules set up and am finding that in the case where my rule pattern matches to instance methods and there are more than one of them, my rules do not fire. If they are simply taken out from being instance methods, they match just fine. I have posted more details and a code example to http://stackoverflow.com/questions/9811294/rewrite-rules-not-firing-for-rul… I appreciate the help, Acshi

1 0

MSIL manipulation libraries
by ARJANEN Loïc Jean David 21 Mar '12

21 Mar '12

Hello, Someone knows of a good MSIL library, to manipulate and output MSIL ? Regards, ARJANEN Loïc

2 1

Quickest way to pass Text to C code
by Yves Parès 21 Mar '12

21 Mar '12

Hello, I have to interact with a C++ library that accepts as string types (putting c++ strings aside) pointers of wchar_t (CWString in Haskell) or unsigned 32-bit int (Ptr Word32 for UTF-32 codepoints). I have read what text, bytestring and base provide, but Text can only be directly converted to (Ptr Word16), and if I use encodeUTF32 to get a ByteString, then I only get useAsCString, no direct conversion to CWString or Ptr WordXX is possible. Not to mention the extra memory allocations due to intermediate conversions. base provides Foreign.C.String.useAsCWString, but it requires that either I use simple Strings at the first place or (same thing than before) I convert from Text to String before passing to C. Is there something I'm missing or isn't this kind of conversion that easy?

3 4

ANN: Haskell Platform Versions Comparison Chart
by Simon Hengel 21 Mar '12

21 Mar '12

Hi, I compiled a chart that gives a side-by-side comparison of package versions in various Haskell Platform releases. http://sol.github.com/haskell-platform-versions-comparison-chart/ This includes both, packages that come with ghc and platform packages. Source is on GitHub[1]. Cheers, Simon [1] https://github.com/sol/haskell-platform-versions-comparison-chart

6 11

Are there arithmetic composition of functions?
by sdiyazg＠sjtu.edu.cn 21 Mar '12

21 Mar '12

By arithmetic I mean the everyday arithmetic operations used in engineering. In signal processing for example, we write a lot of expressions like f(t)=g(t)+h(t)+g'(t) or f(t)=g(t)*h(t). I feel it would be very natural to have in haskell something like g::Float->Float --define g here h::Float->Float --define h here f::Float->Float f = g+h --instead of f t = g t+h t --Of course, f = g+h is defined as f t = g t+h t I guess as long as all operands have the same number of arrows in there types then they should have the potential to be composed like this. Or g::Float->Float->Float --define g here h::Float->Float->Float --define h here f::Float->Float->Float f = g+h --means f x y = g x y + h x y -- f = g+h is defined as f x = g x+h x which in turn is defined as f x y = g x y+h x y This should be easy to implement, with TH perhaps. And I thought there would be a library (not in the language itself, of course) for this, but I haven't find one. Can someone tell me whether there is some implementation of such composition? If there isn't then I may build one.

15 25

good lightweight web-framework like sinatra?
by Greg Weber 21 Mar '12

21 Mar '12

WAI has CGI handlers, so you should be able to deploy a WAI-based framework like Yesod to CGI. If you want a simple framework, you can just use WAI directly. Scotty is a WAI framework that mimics Sinatra. Greg Weber

2 1

ANN: doctest-0.6.0 (support for ghc-7.4, please test)
by Simon Hengel 21 Mar '12

21 Mar '12

Hi, I just uploaded a new version of Doctest that adds support for ghc-7.4. http://hackage.haskell.org/package/doctest Doctest now comes with it's own parser and does not depend on Haddock anymore. This is a quite involved change, and it may still have issues. So pleases test, and do not be shy in reporting any bugs (either as a reply to this post or on [1]). Cheers, Simon [1] https://github.com/sol/doctest-haskell/issues

1 0

scoutess & Google Summer of Code project ideas for prospective students
by Alp Mestanogullari 21 Mar '12

21 Mar '12

Hi, I have written a blog post about potential GSoC projects that revolve around the scoutess project [1] and would, I believe, be useful to the Haskell community: http://alpmestan.wordpress.com/2012/03/21/scoutess-continuous-integration-c… Feel free to give your opinion and ask questions, in particular if you're a student interested in working on this. There also is a ticket on the Haskell GSoC trac [2]. [1] http://patch-tag.com/r/alpmestan/scoutess/wiki/ [2] http://hackage.haskell.org/trac/summer-of-code/ticket/1612 -- Alp Mestanogullari

1 0

struggling with blocking shell cmd when using System.Process
by Rouan van Dalen 20 Mar '12

20 Mar '12

Hi Everyone, I am strugling to get the following code to work correctly and I'm hoping someone will be able to shed some light as to why the code is behaving as it does: {-| runs the supplied command and args as a SHELL command -} runShell :: String -> IO (String, ExitCode) runShell shellCmd = do (_, Just hOut, Just hErr, hProcess) <- createProcess (shell shellCmd) { std_out = CreatePipe, std_err = CreatePipe } exitCode <- waitForProcess hProcess outTxt <- hGetContents hOut errTxt <- hGetContents hErr return $ (outTxt ++ errTxt, exitCode) If I try to su the runShell function with the following command, it simply blocks forever: git --no-pager blame <your git file here> but if I do: git status The runShell function works as expected. Can someone shed some light on why the 'git blame' command blocks? Interrestingly enough, if I remove the waitForProcess action, the 'git blame' command starts working as expected, but I no longer have my blocking behaviour, waiting for the command to finish and return the ExitCode. Regards Rouan

2 2

HughesPJ vs. Wadler-Leijen
by Evan Laforge 20 Mar '12

20 Mar '12

I've been trying to get my head around the Wadler-Leijen pretty printing combinators for a while now and having some trouble. Specifically, I have trouble getting them to pick optimal line breaks. The existing combinators like 'sep' (and everything built from it) merge all elements with <$> and then 'group' the whole thing, with the result that they either all go on one line, or get one line each. This is quite ugly for large lists of small elements. The other alternative is 'fillSep', which does a separate 'group' on each element. Unfortunately, it then tends to make very bad line wrapping decisions, e.g. you get: Rec { hi = "there" } Rec { hi = "there", hi = "there" , hi = "there" } Rec { lab = "short", label = [ 0, 1, 2 , 3, 4, 5 , 6, 7, 8 , 9, 10 , 11, 12 ] } No matter how much fancy 'group's and 'nest's and whatnot I threw in, it was always a choice between forcing wrapping on every element and looking ugly for many small elements, or trying to fit more into one line and having it wrap in the wrong place and wind up scrunched up on the right margin. Here's my latest attempt: list = commas PP.lbracket PP.rbracket . map format commas :: Doc -> Doc -> [Doc] -> Doc commas left right xs = PP.group $ left <+> punctuate (\x -> PP.group (x <$$> PP.comma <> PP.space)) xs <$> right punctuate :: (Doc -> Doc) -> [Doc] -> Doc punctuate f [] = mempty punctuate f [x] = x punctuate f (x:xs) = f x <> punctuate f xs record :: Doc -> [(String, Doc)] -> Doc record title fields = PP.group $ PP.hang 2 $ title <$> (commas PP.lbrace PP.rbrace (map f fields)) where f (label, field) = PP.hang 2 $ PP.group $ PP.text label <+> PP.equals <$> field But the thing is, the HughesPJ-using Language.Haskell.Pretty in haskell-src gets the line wrapping just right. So I investigated how it works, and it's very simple, here's the reduced version: class Pretty a where format :: a -> Doc list :: (Pretty a) => [a] -> Doc list = bracket_list . PP.punctuate PP.comma . map format fsep' :: [Doc] -> Doc fsep' [] = PP.empty fsep' (d:ds) = PP.nest 2 (PP.fsep (PP.nest (-2) d:ds)) bracket_list :: [Doc] -> Doc bracket_list = PP.brackets . PP.fsep brace_list :: [Doc] -> Doc brace_list = PP.braces . PP.fsep record :: Doc -> [(String, Doc)] -> Doc record title fields = title <> (brace_list (map field fields)) where field (name, val) = fsep' [PP.text name, PP.equals, val] ---- This formats records like so: Rec{hi = "there"} Rec{hi = "there" hi = "there" hi = "there"} Rec{label = [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30] label = [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30]} Rec{lab = "short" label = [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30]} Much better, even if it's not my preferred style! Of course WL doesn't have fsep or the negative nest craziness (I don't even know what it's doing there), but it has the more general 'group'. However, no matter how complicated I got with WL it just never came out right. In contrast, a very simple HughesPJ implementation gets it right. The thing is, when trying to figure out which pretty print library to use, the consensus is that WL is just all around better, even though HughesPJ is somewhat standard (but there are 6 WL variants on hackage, and no (?) HughesPJ ones). So am I just using it wrong? If I translate the HughesPJ one over directly into LW, here's what I get: Rec{hi = "there"} Rec{hi = "there", hi = "there", hi = "there"} Rec{label = [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30], label = [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30]} Rec{lab = "short", label = [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30]} So is WL really all it's cracked up to be? Am I using it wrong? I was going to suggest some consolidation in the pretty printing library packages, but now I'm not even sure which style should "win"...

3 6