March 2010 - Haskell-Cafe

Are there any male haskellers?
by Günther Schmidt 28 Mar '10

28 Mar '10

Hi everyone, are there any male haskellers? I hope this question is not considered inappropriate .... Günther

2 1

chp-plus doesn't install
by Colin Paul Adams 28 Mar '10

28 Mar '10

I'm getting these errors (ghc 6.10.4 on Linux x86_64): Building chp-plus-1.1.0... [1 of 9] Compiling Control.Concurrent.CHP.Test ( Control/Concurrent/CHP/Test.hs, dist/build/Control/Concurrent/CHP/Test.o ) [2 of 9] Compiling Control.Concurrent.CHP.Console ( Control/Concurrent/CHP/Console.hs, dist/build/Control/Concurrent/CHP/Console.o ) [3 of 9] Compiling Control.Concurrent.CHP.Connect ( Control/Concurrent/CHP/Connect.hs, dist/build/Control/Concurrent/CHP/Connect.o ) Control/Concurrent/CHP/Connect.hs:146:67: Couldn't match expected type `ChanOpts a' against inferred type `ConnectableParam (Chanout a)' In the first argument of `oneToOneChannel'', namely `o' In the second argument of `(<$>)', namely `oneToOneChannel' o' In the first argument of `(>>=)', namely `((writer &&& reader) <$> oneToOneChannel' o)' Control/Concurrent/CHP/Connect.hs:152:67: Couldn't match expected type `ChanOpts a' against inferred type `ConnectableParam (Chanin a)' In the first argument of `oneToOneChannel'', namely `o' In the second argument of `(<$>)', namely `oneToOneChannel' o' In the first argument of `(>>=)', namely `((reader &&& writer) <$> oneToOneChannel' o)' etc. -- Colin Adams Preston Lancashire

2 3

Internet game servers in Haskell?
by Colin Paul Adams 28 Mar '10

28 Mar '10

Has anyone ever written a server in Haskell for managing live game-playing (any game) across the internet? -- Colin Adams Preston Lancashire

3 2

Testing for valid data
by michael rice 28 Mar '10

28 Mar '10

When I'm learning a new language I like to translate old programs into the new language as a test of my understanding. However, many of the old programs are from old programming texts, many written in the time of punch-cards for batch processing, and many containing significant amounts of code that only tests for valid data. Should we still be writing programs in this fashion, or acknowledge the fact that better tools for pre-screening data are now available and code only for the problem at hand? Michael

3 3

Why is it so different between 6.12.1 and 6.10.4_1 ?
by zaxis 27 Mar '10

27 Mar '10

In 6.12.1 under archlinux >let f x y z = x + y + z > :t f f :: (Num a) => a -> a -> a -> a > :t (>>=) . f (>>=) . f :: (Num a) => a -> ((a -> a) -> a -> b) -> a -> b > ((>>=) . f) 1 (\f x -> f x) 2 5 In 6.10.4_1 under freebsd > let f x y z = x + y + z *Money> :t f f :: (Num a) => a -> a -> a -> a > :t (>>=) . f (>>=) . f :: (Monad ((->) a), Num a) => a -> ((a -> a) -> a -> b) -> a -> b > ((>>=) . f) 1 (\f x -> f x) 2 <interactive>:1:1: No instance for (Monad ((->) a)) arising from a use of `>>=' at <interactive>:1:1-5 Possible fix: add an instance declaration for (Monad ((->) a)) In the first argument of `(.)', namely `(>>=)' In the expression: ((>>=) . f) 1 (\ f x -> f x) 2 In the definition of `it': it = ((>>=) . f) 1 (\ f x -> f x) 2 Sincerely! ----- fac n = let { f = foldr (*) 1 [1..n] } in f -- View this message in context: http://old.nabble.com/Why-is-it-so-different-between-6.12.1-and-6.10.4_1---… Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

6 17

Randomized N-Queens
by Ronald Guida 27 Mar '10

27 Mar '10

Hi, I'm trying to solve the N-queens problem, but with a catch: I want to generate solutions in a random order. I know how to solve the N-queens problem; my solver (below) generates all possible solutions. What I am trying to do is generate solutions in a random order by somehow randomizing the order in which "nextRow" considers the unused columns. I tried adding a random number generator to the solution state; the problem with this approach is that whenever the solver backtracks, the state of the random number generator backtracks along with it. In effect, I am selecting a random, but fixed, permutation for each row, and then I am applying that same set of permutations along all computational paths. Whenever I consider row R, regardless of which path I have taken, I am applying row R's permutation to the unused columns. This is not the behavior I want. I want each computational path to use a new, different permutation for each row. On the other hand I also want to be able to take the first few solutions without waiting for all possible solutions to be generated. How might I go about doing this? -- Ron ------------------------------------------------------------ module Main where import Control.Monad.State import Data.List import System.Environment import System.Random import System.Random.Shuffle -- from package random-shuffle newtype Location = Location {unLocation :: (Int, Int)} deriving (Show) isAttacked :: Location -> Location -> Bool isAttacked (Location (row1, column1)) (Location (row2, column2)) = or [ (row1 == row2) , (column1 == column2) , ((row1 - row2) == (column1 - column2)) , ((row1 - row2) == (column2 - column1)) ] newtype Board = Board {unBoard :: [Location]} deriving (Show) data (RandomGen g) => SolutionState g = SolutionState { solnBoard :: Board , solnUnusedColumns :: [Int] , solnRandomGen :: g } nextRow :: (RandomGen g) => Int -> Int -> StateT (SolutionState g) [] () nextRow n row = do (SolutionState (Board locs) unusedColumns gen) <- get let (ps, gen') = randShuffleSeq (length unusedColumns) gen column <- lift $ shuffle unusedColumns ps let loc = Location (row, column) guard $ all (not . isAttacked loc) locs let remainingCols = unusedColumns \\ [column] put $ (SolutionState (Board (loc : locs)) remainingCols gen') randShuffleSeq :: (RandomGen g) => Int -> g -> ([Int], g) randShuffleSeq 0 g = ([], g) randShuffleSeq 1 g = ([], g) randShuffleSeq n g = (x:xs, g2) where (x, g1) = randomR (0, n-1) g (xs, g2) = randShuffleSeq (n-1) g1 allRows :: (RandomGen g) => Int -> StateT (SolutionState g) [] () allRows n = mapM_ (nextRow n) [1..n] solve :: (RandomGen g) => Int -> g -> [Board] solve n gen = map solnBoard $ execStateT (allRows n) (SolutionState (Board []) [1..n] gen) formatSolution :: Board -> String formatSolution = show . map unLocation . unBoard main :: IO () main = do args <- getArgs let boardSize = read $ args !! 0 maxSolns = if length args > 1 then read (args !! 1) else 10 allSolns = solve boardSize (mkStdGen 42) putStrLn $ unlines $ map formatSolution $ take maxSolns allSolns

2 1

Garbage collecting pointers
by Max Rabkin 26 Mar '10

26 Mar '10

On Fri, Mar 26, 2010 at 11:21 PM, Brandon S. Allbery KF8NH <allbery(a)ece.cmu.edu> wrote: > On Mar 26, 2010, at 16:28 , Mads Lindstrøm wrote: >> >> For some time I have been thinking about an idea, which could limit >> Haskell's memory footprint. I don't know if the idea is crazy or clever, > > This is called pointer tagging. The original STG design avoided it because > of the perceived performance loss in removing the tags before using the > pointer, but as I understand it the current GHC design uses limited tagging. I'd say it's really CDR coding -- http://en.wikipedia.org/wiki/CDR_coding -- pointer tagging is just a part of it. [Sorry, Brandon, my reply all button seems elusive these days] --Max

1 0

Re: Patch for library (new feature) - how to deal with it
by Maciej Piechotka 26 Mar '10

26 Mar '10

On Fri, 2010-03-26 at 17:06 +0000, Duncan Coutts wrote: > On Fri, 2010-03-26 at 16:50 +0000, Maciej Piechotka wrote: > > On Fri, 2010-03-26 at 13:29 +0000, Duncan Coutts wrote: > > > On Fri, 2010-03-26 at 02:11 +0000, Maciej Piechotka wrote: > > > > Hello, > > > > > > > > I have written patch (attached) which introduce new API for zlib - > > > > personally I wrote it to have easy implementation of > > > > compression/decompression in iteratee (example file - no yet working > > > > -attached). > > > > > > > > Earlier version of patch I tried to sent to maintainer of zlib. However > > > > I received no response (possibly I get into spam folder by helpful > > > > spamassassin or something like that). I definitely don't want to fork > > > > this library - especially that it is in haskell platform. > > > > > > Ivan is right :-) > > > > > > > I understand. However given the last update of zlib it could be that the > > address is no longer valid. > > > > > I've discussed iterator approaches with zlib before. Tibbe and I > > > discussed it in the context of web servers that want precise control > > > over outputting blocks. > > > > > > I'm not happy however that something that is essentially pure > > > (compression/decompression) should have to have be in IO just to fit the > > > iterator pattern. That seems wrong. I could tolerate ST however. > > > > > > > Well. Iteration can be made pure again iff: > > 1. It will be possible to copy the z_stream. Currently it is not > > possible with zlib. > > It is in principle possible, however it is rather expensive. You would > not want to copy it in practise. > I know. It is a list why I put it in IO monad. (The same for point 3) > > 2. It is deal with great care in iteration. It is possible to use safely > > unsafePerformIO and seq. Iteratee can be pure as it have no copy of the > > context. Existsing compress/decompress functions as well are 'safe' for > > the same reason. > > I'm not quite sure I follow what you're referring to. > While the iterating API is in IO monad you can have something like. > > > I think that it is possible for you to construct the impure interface > > > you want on top of the existing pure interface, using threads and MVars. > > > It is a general pattern, to transform a lazy [a] -> [a] function into an > > > imperative "push block / pull block" interface. You connect up the lazy > > > function to an input channel and an output MVar (running in a new > > > thread). Then externally you push blocks into the input channel and wait > > > for blocks on the output channel. If benchmarks prove that to have too > > > high an overhead then we might consider doing something lower level. > > > > > > > 1. That was my first approach. It was so horribly complicated that I > > gave up. Especially if you wanted any level of error handling. > > On the plus side you would only have to do it once and it would let you > wrap any lazy [a] -> [a] function into the iterator stuff. > If you consider the error handling and/or trailing data it is not so nice and for sure not general. > > 3. If anyone is going to write such function - I'm fine. I just chosen > > what I believe it is a simpler and more correct approach. > > I understand it was easier to write it that way, however it is not a > nice general API to expose from the zlib package I tried to be as close as possible to Data.Digest.Pure.MD5[1]. However due to mentioned above problems with z_stream it cannot. > and it messes with the > layering of the library. > Could you explain? > > > Another alternative that I would be satisfied with would be a lower > > > level interface using the ST monad. That should allow the existing pure > > > interface to be implemented safely on top, and hopefully would allow the > > > kind of impure interface you're after. > > > > > > > As the function have side effects I have chosen IO. > > Right but they only have local side effects. As such IO is overkill and > it forces users to use unsafePerformIO/unsafeIOToST which means they > need to know about the library internals to know if that is safe. > If they would be prefixed with unsafePerformIO/unsafeIOToST user still would have to know something about internals of library but he would have no visual clue. > > The patch was intended as a low-level interface for specific > > applications. > > Sure, but I'm convinced that it is possible to make a low level ST > interface that is not ugly and that the rest of the library can be based > upon too. > The rest of library can be based onto this (if you want I can prove it by providing patch). Also I'm not quite sure what you mean by ugly. > Duncan > Regards [1] http://hackage.haskell.org/packages/archive/pureMD5/1.1.0.0/doc/html/Data-D…

1 0

Re: Patch for library (new feature) - how to deal with it
by Maciej Piechotka 26 Mar '10

26 Mar '10

On Fri, 2010-03-26 at 13:29 +0000, Duncan Coutts wrote: > On Fri, 2010-03-26 at 02:11 +0000, Maciej Piechotka wrote: > > Hello, > > > > I have written patch (attached) which introduce new API for zlib - > > personally I wrote it to have easy implementation of > > compression/decompression in iteratee (example file - no yet working > > -attached). > > > > Earlier version of patch I tried to sent to maintainer of zlib. However > > I received no response (possibly I get into spam folder by helpful > > spamassassin or something like that). I definitely don't want to fork > > this library - especially that it is in haskell platform. > > Ivan is right :-) > I understand. However given the last update of zlib it could be that the address is no longer valid. > I've discussed iterator approaches with zlib before. Tibbe and I > discussed it in the context of web servers that want precise control > over outputting blocks. > > I'm not happy however that something that is essentially pure > (compression/decompression) should have to have be in IO just to fit the > iterator pattern. That seems wrong. I could tolerate ST however. > Well. Iteration can be made pure again iff: 1. It will be possible to copy the z_stream. Currently it is not possible with zlib. 2. It is deal with great care in iteration. It is possible to use safely unsafePerformIO and seq. Iteratee can be pure as it have no copy of the context. Existsing compress/decompress functions as well are 'safe' for the same reason. 3. It is implemented in pure haskell. > Secondly we cannot have the zlib package depend on the iteratee package. > Though we can expose interfaces that allow you to construct the iterator > stuff. > Hmm. Have you seen the patch? It does not change any dependencies. It just adds 6 functions and 3 data structures for API (+ helper functions). It DOES NOT remove any currently existing function (or even change them). it is just additional interface defined. It could be a separate package if it hasn't use Stream. I have never imagined to add dependency of iteratee. > I think that it is possible for you to construct the impure interface > you want on top of the existing pure interface, using threads and MVars. > It is a general pattern, to transform a lazy [a] -> [a] function into an > imperative "push block / pull block" interface. You connect up the lazy > function to an input channel and an output MVar (running in a new > thread). Then externally you push blocks into the input channel and wait > for blocks on the output channel. If benchmarks prove that to have too > high an overhead then we might consider doing something lower level. > 1. That was my first approach. It was so horribly complicated that I gave up. Especially if you wanted any level of error handling. 2. To fully handle the iterator API the decompress would have to be: ... -> (L.ByteString, L.ByteString) Where first is decompressed string and second a rest of input. 3. If anyone is going to write such function - I'm fine. I just chosen what I believe it is a simpler and more correct approach. > Another alternative that I would be satisfied with would be a lower > level interface using the ST monad. That should allow the existing pure > interface to be implemented safely on top, and hopefully would allow the > kind of impure interface you're after. > As the function have side effects I have chosen IO. The patch was intended as a low-level interface for specific applications. If application ensure that computation is done in proper way it may convert it into ST/pure easily. I think that adding unsafePerformIO/unsafeIOToST misses the point. If computation is pure it can probably use compress/decompress. If not then IO/ST monad does not impose additional restrictions > Duncan > Regards PS. I would like to underline that it DOES NOT add dependency on iteratee or any other package and it DOES NOT intend to replace/change an existing API. It is a simply new even-lower-level API for special situation like iteratee (web servers etc.).

1 0

Patch for library (new feature) - how to deal with it
by Maciej Piechotka 26 Mar '10

26 Mar '10

Hello, I have written patch (attached) which introduce new API for zlib - personally I wrote it to have easy implementation of compression/decompression in iteratee (example file - no yet working -attached). Earlier version of patch I tried to sent to maintainer of zlib. However I received no response (possibly I get into spam folder by helpful spamassassin or something like that). I definitely don't want to fork this library - especially that it is in haskell platform. What should I do with the patch? Regards

3 2