November 2008 - Haskell-Cafe

Control.Exception Funny
by Dominic Steinitz 29 Nov '08

29 Nov '08

I'm probably doing something wrong but this example doesn't compile for me under ghc 6.10.1 (http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Exceptio…) > catch (openFile f ReadMode) > (\e -> hPutStr stderr ("Couldn't open "++f++": " ++ show e)) > Run.hs:77:24: > Couldn't match expected type `Handle' against inferred type `()' > Expected type: IO Handle > Inferred type: IO () > In the expression: > hPutStr stderr ("Couldn't open " ++ d ++ ": " ++ show e) > In the second argument of `CE.catch', namely > `(\ e -> hPutStr stderr ("Couldn't open " ++ d ++ ": " ++ show e))' Fair enough because openFile returns a Handle and hPutStr returns () so they don't match as the compiler says. > CE.catch :: (CE.Exception e) => IO a -> (e -> IO a) -> IO a So if I fix the example thus: > foo d = CE.catch (openFile d ReadMode >> return ()) > (\e -> hPutStr stderr ("Couldn't open "++ d ++": " ++ show e)) I get > Run.hs:70:8: > Ambiguous type variable `e' in the constraint: > `CE.Exception e' > arising from a use of `CE.catch' at Run.hs:(70,8)-(71,78) > Probable fix: add a type signature that fixes these type variable(s) Now I think I never used to get this under 6.8.2 but I don't easily have a 6.8.2 to try it out on. Doing what the compiler suggests doesn't work for obvious reasons: > foo :: CE.Exception e => FilePath -> IO () > foo d = CE.catch (openFile d ReadMode >> return ()) > (\e -> hPutStr stderr ("Couldn't open "++ d ++": " ++ show e)) > Run.hs:69:0: > Ambiguous constraint `CE.Exception e' > At least one of the forall'd type variables mentioned by the constraint > must be reachable from the type after the '=>' > In the type signature for `foo': > foo :: (CE.Exception e) => FilePath -> IO () There seems to be a ticket for it (http://hackage.haskell.org/trac/ghc/ticket/2819) but this doesn't give a suggested example that compiles. Dominic.

2 2

Re: Go Haskell! -> array libraries
by John Lato 29 Nov '08

29 Nov '08

> From: Andrew Coppin <andrewcoppin(a)btinternet.com> > >>> My view would be to let the free market of developers decide what is >>> best. No bottlenecks -- there's too many Haskell libraries already (~1000 now). >>> >>> And this approach has yielded more code than ever before, more libraries >>> than ever before, and library authors are competing. >>> >>> So let the market decide. We're a bazaar, not a cathedral. >>> > > I find this kind of attitude disturbing. > > Are you seriously asserting that it's "bad" for people to stop and think > about their designs before building? That it's "bad" for people to get > together and coordinate their efforts? Would you really prefer each and > every developer to reinvent the wheel until we have 50,000 equivilent > but slightly different wheel implementations? Certainly you seem > obsessed with the notion that "more packages on Hackage == better". Well > in my book, quantity /= quality. (The latter being vastly more important > than the former - while admittedly far harder to measure objectively.) I > would far prefer to see one well-written library that solves the problem > properly than see 25 incompatible libraries that all solve small > fragments of the problem poorly. In the latter case, there will be no > "competition" between libraries; everybody will just give up and not use > *any* of them. You _can_ have too much choice! > > I really hope I'm not the only person here who sees it this way... > I would love to see a perfect, unified array library in Haskell. I think everyone would. However, the problem Don, Roman, and others have raised is that there is no single consensus on what that library would look like, or how it would be implemented. It might be impossible for one library to fill the entire design space. Don's point is that, since this isn't yet a solved problem, having multiple implementations available to see what works well (and what doesn't) is a necessary step in finding a solution. I also think this is a exactly why Hackage needs a way to indicate that packages are deprecated/superceded by other packages. There was some talk about this recently, and IIRC even a submitted patch. I hope that gets adopted soon. John

3 2

GHC 6.10.1 multi-threaded broken?
by Jeroen Baekelandt 29 Nov '08

29 Nov '08

Hi, Since I upgraded from ghc 6.8.3 to 6.10.1, I noticed that my programs do not run multi-threaded anymore. I tried simplifying my code, till I just took one of the par/pseq demo's to verify if it wasn't my fault. When I compile this code on 6.8.3 (both ubuntu and OS X), top shows something like 180% CPU usage and the elapsed time is almost halved. When compiled with 6.10.1, top shows max 100% and no speedup is noticable at all. Sample run: $ ghc --make -threaded paralleltest $ time ./paralleltest +RTS -N1 -RTS 119201850 real 0m26.024s user 0m25.494s sys 0m0.220s $ time ./paralleltest +RTS -N2 -RTS 119201850 real 0m25.770s user 0m25.539s sys 0m0.167s I have the same on OS X and Ubuntu. I even compiled the Ubuntu ghc from source myself and verified that GMP was used. Any ideas? Thanks, Jeroen Here's the code: module Main where import Control.Parallel fib :: Int -> Int fib 0 = 0 fib 1 = 1 fib n = fib (n - 1) + fib (n - 2) mkList :: Int-> [Int] mkList n = [1..n-1] relprime :: Int -> Int -> Bool relprime x y = gcd x y == 1 euler :: Int -> Int euler n = length (filter (relprime n) (mkList n)) sumEuler :: Int -> Int sumEuler = sum . (map euler) . mkList parSumFibEuler :: Int -> Int -> Int parSumFibEuler a b = f `par` (e `pseq` (e + f)) where f = fib a e = sumEuler b main = do print $ parSumFibEuler 40 7450

2 1

Extensible Exceptions
by David F. Place 29 Nov '08

29 Nov '08

Hi, All. I am trying to understand the new exceptions package in base-4 Control.Exceptions. The documentation for catchJust is the same as in Control.OldException including this example: result <- catchJust errorCalls thing_to_try handler Control.OldException provides the predicate errorCalls, but the new one does not. I don't see how to write it. Thanks for reading. Cheers, David

6 11

Using Parsec with other monads
by Roly Perera 28 Nov '08

28 Nov '08

Hi, I've spent some time writing a parser using the Parsec library and was looking forward to being able to plug in some side-behaviour once I'd got the parser working. Now it seems I can't actually do that in a nice way because Parsec appears to be "fixed" to a simple State monad. I found this mentioned in the Cafe archives, but not much discussion. Is there a reason Parsec wasn't implemented using the monad transformer approach? Are there any plans to open it up? It's a nice powerful library and a natural thing to want to do for example would be to plug in something like a Reader to track a variable context. I guess one could abuse the State monad to achieve the goal but that feels like the wrong tool for the job. Any insights appreciated. thanks, Roly

3 2

definitive list of editline bindings anywhere?
by Paul Brown 28 Nov '08

28 Nov '08

All -- Anyone have a definitive list of editline keybindings available? I find myself missing some of the capabilities of readline, and there doesn't seem to be documentation. -- Paul

2 1

Question about fastcgi
by Mauricio 28 Nov '08

28 Nov '08

Hi, I'm learnng to use fastcgi and, reading the examples, I see the main "loop" is like this: main = runFastCGI my_work However, isn't a fastcgi program supposed to choose a port where to listen to calls? For instance, in this C example: xzdev.com/nginx_fastcgi.html doesn't the line listen_socket = FCGX_OpenSocket(":8002", 2000); says it's listening to port 8002? I read the code for fastcgi, from hackage, and I can't find anything related to ports like, for instance, a default port. Am I understanding something the wrong way? Thanks, Maurício

3 4

Shared modification inside lambdas
by Andrew Hunter 28 Nov '08

28 Nov '08

I'm developing an embedded DSL in Haskell (for exact real arithmetic work, but that's irrelevant right now.) Among other things, the language contains functions and application, as well as various terms. In one iteration, the abstract syntax looked kinda like this (in spirit, don't worry about the actually available terms...) data Expr = Var String | Const Int | Plus Expr Expr | Quantified Range String Expr | Lambda String Expr | App Expr Expr Here, lambda-terms just have the name of their bound variable and the RHS. Quantified terms are much like specialized lambdas; one note is that you *will* have to evaluate the RHS of the quantified term with many values for the argument. It's obvious how to write an evaluator on these--just keep an environment, etc. All well and good, but it seems to me that if I'm embedding the DSl, shouldn't I be able to use the host language's facilities--for example, function abstractions and applications--directly? Well, I tried this, and it seems it works OK, like so: data Expr = Var String | Const Int | Plus Expr Expr | Quantified Range (Int -> Expr) I replaced Lambda terms and applications with Haskell-level functions. Note that my quantifiers still need internal functions, but I replaced them in the same fashion. However, I have a problem; one thing I often have to do with expressions is refine them, where refine has type: refine :: Expr -> Expr and transforms expressions into more interesting ones via certain, mostly simple rules. The problem comes with functions, either just plain lambdas or quantified ones. The rule for refining functions boils down to just refining (recursively) the RHS; in the old version, that was easy! refine (Lambda var rhs) = Lambda var (refine rhs) I only refine while evaluating terms of type Expr, so top level functions aren't important--by the time I'm evaluating them, I've applied them to arguments--but quantified terms are a problem. I could write something like: refine (Quantified range pred) = Quantified range pred' where pred' = \c -> refine (pred c) But the problem is that this refines the term, again, every time I apply an argument to pred': I know I'm going to apply arguments many times to that new pred, and I want to refine it /once/: refinement is argument-agnostic, it only rearranges the structure of the AST, so in theory it'd be nice if I could refine that structure, just duplicating references to the appropriate free variable where I would have duplicated refences to the appropriate (Var String) before. Am I sore out of luck here? Is there a reasonable way I can implement my internal functions via Haskell functions, but apply argument-agnostic transformations to the RHS in a shared fashion? Or, is there some optimization in GHC that means I don't need to worry about this? Thanks, AHH

2 1

Re: Suggestion: Syntactic sugar for Maps!
by Don Stewart 28 Nov '08

28 Nov '08

bulat.ziganshin: > Hello circ, > > Thursday, November 27, 2008, 9:59:08 PM, you wrote: > > So why not {"hello": 1, "there": 2} ? > > mymap "hello:1 there:2" > > where mymap implementation is left to the reader :) Hey, well, even easier: {-# LANGUAGE OverloadedStrings #-} {-# LANGUAGE FlexibleInstances #-} import Data.Map import Data.String import Text.JSON instance IsString (Map Int Bool) where fromString = fromList . read -- or, say, JSON syntax for assoc lists. {- fromString s = case resultToEither (decode s) of Right a -> a Left s -> error s -} test :: Map Int Bool test = "[(7, True), (1, False)]" main = print test -- Don

4 3

I have forgotten .. ghci question
by Galchin, Vasili 28 Nov '08

28 Nov '08

Hello, I have an experimental version of a package ~/FTP/Haskell/blah. Who I "point" ghci ath this experimental package version so I can poke around? Kind regards, Vasili

1 0