- Haskell-Cafe - Haskell.org

Hackage - Machine Learning
by Jeremy Ong 30 Mar '10

30 Mar '10

On a suggestion from Ketil Maede, the listed mentor for the Google Summer of Code Machine Learning Project on Hackage, I am sending this email as an interested student. The listed mentor is busy unfortunately :D. Are there people on the list interested in mentoring this project? Apparently, the project was close to getting funded last time. I am a senior currently studying math and physics with a phd in math being the ultimate (short term?) goal. Contact me if you would like to see more credentials or what have you. cheers, Jeremy -- Jeremy Ong Mathematics Applied & Engineering Physics Cornell University '10 http://www.jeremyong.com Education is the process of casting false pearls before real swine. Prof. Irwin Edman (1896–1954) On Tue, Mar 30, 2010 at 3:35 AM, Ketil Malde <ketil(a)malde.org> wrote: > Jeremy Ong <jco34(a)cornell.edu> writes: > >> haskell-fu although I would love to improve that as well. Let me know >> if any involvement from me is a possibility. > > From you, yes, from me, no. > > I no longer have sufficient time nor interest to pursue this project, > but it did come close to getting funded the last time, so if you're > interested, I suggest sending a message to the haskell-cafe list and see > if you can get somebody to mentor. > > That said, most of the projects that get funded tend to be language > related ones, i.e. development tools or infrastructure or that sort of > thing. > > Good luck! > > -k > -- > If I haven't seen further, it is by standing in the footprints of giants >

1 0

GSOC idea: Haskell JVM bytecode library
by Alexandru Scvortov 30 Mar '10

30 Mar '10

Hi, I've got an idea for a Summer of Code project and I'd really appreciate some feedback on it. If people generally find it interesting, I'll go into more detail. GSoC: Haskell JVM bytecode library ================================== What ---- I'm thinking of writing a library for analyzing/generating/manipulating JVM bytecode. To be clear, this library would allow one to load and work with JVM classfiles; it wouldn't be a compiler, interpretor or a GHC backend. Motivation ---------- Over the past 20 or so years, the JVM has become a very popular platform. It's used in industry, on the web, and on mobile devices. The main programming language used is Java, but recently, quite a few new ones have turned up (including some functional ones): Scala, Clojure, Jython, Rhino, etc. All the languages compile to a single, universal, and very well documented format, namely classfiles. The problem with classfiles is that they're blackboxes. Once written, they can't be modified and they can only be read by the JVM. It's quite a shame, really, since we could do all sorts of interesting things with them. Possible uses ------------- If we had a well-documented and reliable way of working with classfiles, we could: * perform static analysis to identify bottle-necks, common errors, etc. * do further optimization pases over the binary; maybe, we could optimize for size more aggressively (UPX does this for win32 exes, why shouldn't it be done for classfiles?) * generate interfaces for the libraries directly from the binaries * visualize the structure of complex programs * modify existing programs to route-around errors * generate JVM code directly from Haskell programs * etc. This project aims to provide exactly this -- an easy way of working with JVM bytecode. Previous work ------------- Quite a few similar projects have existed in the past, most of them are mentioned on this page: http://www.haskell.org/haskellwiki/GHC:FAQ#Why_isn.27t_GHC_available_for_.N… None of them have tried exactly this (some were more ambitious, some never bothered with providing a library), and most of them are undocumented and unmaintained. References ---------- JVM Spec: http://java.sun.com/docs/books/jvms/second_edition/html/VMSpecTOC.doc.html Cheers, Alex

5 6

Haskell-friendly Linux Distribution
by Chris Dornan 30 Mar '10

30 Mar '10

Hi, I am choosing a Linux distribution for a production Haskell project and would would normally just go with Debian (pedigree, stability, and of course Haskell Platfom included) but CentOS is in the frame. Are there any particularly strong reasons for preferring or avoiding any particular distribution? Chris ------------------------------- Chris Dornan email : chris(a)chrisdornan.com tel : +1 (847) 691 7945

15 25

Haskell at Indian Universities?
by Joachim Breitner 30 Mar '10

30 Mar '10

Hi, I was just about to name this thread “Are there any Indian Haskeller?” but since I want it to be read, I deemed that too risky... I’m a computer science student in Germany and I’d like to spend one semester as an exchange student in India. I have no specific plans yet where I want to go, and I’m wondering if there are universities in India where Haskell is basis for research or at least used as a tool. Haskell and functional programming is quite underrepresented at my university, so maybe this might be a good opportunity for me to combine Haskell and academia. Any other, non-Haskell related hint for someone hoping to spend one semester as an exchange student in India is welcome (but probably better sent off-list). Thanks in advance, Joachim -- Joachim "nomeata" Breitner mail: mail(a)joachim-breitner.de | ICQ# 74513189 | GPG-Key: 4743206C JID: nomeata(a)joachim-breitner.de | http://www.joachim-breitner.de/ Debian Developer: nomeata(a)debian.org

2 1

Fwd: [Haskell-cafe] Are there any female Haskellers?
by Alberto G. Corona 30 Mar '10

30 Mar '10

. 2010/3/29 Jason Dusek <jason.dusek(a)gmail.com> 2010/03/29 Alberto G. Corona <agocorona(a)gmail.com>: > > [...] What we evolved with is a general hability: to play with > > things to achieve what we need from them, (besides other > > abilities). The pleasure to acheve ends by using available > > means. [...] A tool is someting used to solve a class of > > problems. It does not matter if it is something phisical or > > conceptual. [...] The more general is a tool, the more we feel > > pleasure playing with it > > So the adaptation you are saying men have in greater degree > than women is pleasure in "tool using", broadly defined to > include taming animals, debate, programming, sword play, > carpentry and more? What are you attributing to men is not > so much superiority of ability but greater motivation? > > -- > Jason Dusek > n terms of natural selection, greater motivation for and greater innate hability are both positiverly correlated in response to an evolutionary pressure (in beings that have learning capabilities). for example, cats are better at catching mouse, and they enjoy to play catching them. A live being end up developping better innate habilities (and is more motivation) for whatever practises more. This is called baldwin effect (some common general learning for the task end up fixed innately). Motivation match ability and viceversa. This is evolutionarily stable. It makes no evolutionary sense that woman and men have the same abilities and tendencias because they had different activities since before they were even humans. The brain has limited computation resources. The optimal behaviours and strategies are in many cases different for each sex. This happen for almost all the animal kingdom. Why humans would be different?. No matter they are very similar in some aspects, they are different and very different in others (fortunatelly). Nothing that your grandparent didn´t know.

2 1

ICFP 2010 deadline
by Wouter Swierstra 30 Mar '10

30 Mar '10

On behalf of Stephanie Weirich, this year's PC Chair, I would like to emphasize that the deadline for ICFP this year is at *14:00 UTC*. You may want to double check what time this is using the following link: http://www.timeanddate.com/worldclock/fixedtime.html?day=2&month=4&year=201… Submission is already open through: http://icfp2010.seas.upenn.edu/ All the best, Wouter

1 0

Programming with categories
by Francisco Vieira de Souza 30 Mar '10

30 Mar '10

Hi Haskell-cafe. I'm trying to use Haskell to program with Categories, but I didn't have seeing some works in this area nor references about this. Does someone can help me ins this subject? Thanks in advance, Vieira -- "Para saber quantos amigos você tem, dê uma festa. 'Para saber a qualidade deles, fique doente!"

3 2

Two Google Summer of Code project proposals
by Johan Tibell 30 Mar '10

30 Mar '10

Hi, I'd like to advertise two Google Summer of Code projects that I recently added to the list [1] of proposed projects: Improve Cabal's test support http://hackage.haskell.org/trac/summer-of-code/ticket/1581 Proper test support is essential for good software quality. By improving Cabal's test support we can test all Cabal packages on continuous build machines which should help us detect breakages earlier. Making it easier to run the tests means that more people will run them and those who already do will run the more often. and A high-performance HTML combinator library using Data.Text http://hackage.haskell.org/trac/summer-of-code/ticket/1580 Being both fast and safe, Haskell would make a great replacement for e.g. Python and Ruby for server applications. However, good library support for web applications is sorely missing. To write web applications you need at least three components: a web application server, a data storage layer, and an HTML generation library. The goal of this project is to address the last of the three, as the two are already getting some attention from other Haskell developers. I encourage any interested students to have a look at the two proposals (and the other proposals on the list) and sign up for GSoC on Trac (or with Edward Kmett if Trac is still having issues). 1. http://hackage.haskell.org/trac/summer-of-code/report/1 Cheers, Johan

1 1

Re: building "encoding" on Windows?
by John Lato 30 Mar '10

30 Mar '10

> Message: 20 > Date: Mon, 29 Mar 2010 21:45:49 +0100 > From: > Subject: Re: [Haskell-cafe] building "encoding" on Windows? > To: haskell-cafe(a)haskell.org > Message-ID: <4BB1117D.5090709(a)btinternet.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > wagnerdm(a)seas.upenn.edu wrote: >> Whooo, boy, I sure don't fancy explaining Msys/MinGW or Cygwin to a >> non-technical person and giving sufficiently detailed >> installation/usage instructions. > > I still dislike the idea of needing to install MSYS, MinGW, Cygwin or > similar tools to get anything remotely interesting from Hackage to build > on Windows. I know this is an old topic, and I'm actually sympathetic to your cause, but I really don't think asking Windows developers to install MinGW or Cygwin is a problem. You wouldn't distribute C# source code and expect users to run that without Visual Studio, would you? Packages on Hackage are *source distributions*, so users need a development environment in order to make use of them. Windows doesn't have a built-in development environment, therefore I don't see any reason why developers shouldn't choose the one most convenient to them. The only alternative is to make a binary distribution, which (as you're discovering) has its own problems. John

5 4

Trying to figure out a segfault caused by haskeline.
by ryan winkelmaier 30 Mar '10

30 Mar '10

Hey everyone, I'm looking for help with a seg fault that takes out both my ghci and darcs as well as anything that uses haskeline. A bug on the haskeline trac hasn't gotten any response so I figured I might as well figure this out myself and get ghci up and running again. Using the test program below I get the same segmentation fault, so I run it using gdb and get the following, Program received signal SIGSEGV, Segmentation fault. 0x000000000053fdce in base_ForeignziCziString_zdwa_info () My knowledge of this is very limited from here on out so here is what I was able to get together. On the 20th call of base_ForeignziCziString_zdwa_info r14 is 0 so 0x000000000053fdce <+22>: movsbq (%r14),%rax produces the segfault. >From what I understand this is happening in the Foreign.C.String module but thats as much as I know. Anyone have advice on where to go next? System info: Distribution: gentoo amd64 Ghc version: currently 6.12.1 (though the segfault happends on any of the ones with haskeline) Haskeline version: 0.6.2.2 Here is the test program ---------------------------------------------------------------------------------------------------- module Main where import System.Console.Haskeline import System.Environment {-- Testing the line-input functions and their interaction with ctrl-c signals. Usage: ./Test (line input) ./Test chars (character input) --} mySettings :: Settings IO mySettings = defaultSettings {historyFile = Just "myhist"} main :: IO () main = do args <- getArgs let inputFunc = case args of ["chars"] -> fmap (fmap (\c -> [c])) . getInputChar _ -> getInputLine runInputT mySettings $ withInterrupt $ loop inputFunc 0 where loop inputFunc n = do minput <- handleInterrupt (return (Just "Caught interrupted")) $ inputFunc (show n ++ ":") case minput of Nothing -> return () Just "quit" -> return () Just "q" -> return () Just s -> do outputStrLn ("line " ++ show n ++ ":" ++ s) loop inputFunc (n+1) ------------------------------------------------------------------------------------------------------------------------ Syfran

2 1

Garbage collecting pointers
by Mads Lindstrøm 29 Mar '10

29 Mar '10

Hi 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, but I would love to hear peoples thoughts about it. The short story is, I propose that the garbage collector should not just reclaim unused memory, it should also diminish the need for pointers, by replacing nested data structures with larger chunks of consecutive memory. In other words, I would diminish the need for pointers for arbitrary recursive data types, just as replacing linked lists with arrays eliminate the need for pointers. I will explain my idea by an example of a data type we all know and love: data List a = Cons a (List a) | Nil each Cons cell uses two pointers - one for the element and one for the rest of the list. If we could somehow merge the element and the rest of the list into consecutive memory, we would be able to eliminate the pointer to the rest of list. On 64 bit architectures merging would save us 8 bytes of "wasted" memory. If we could merge n elements together we could save n*8 bytes of memory. 64 bit pointers are wasteful in another way, as nobody has anywhere near 2^64 bytes of memory. And nobody is going to have that much memory for decades to come. Thus, we could use the 8 most significant bits for something besides pointing to memory, without loosing any significant ability to address our memories. This would be similar to how GHC uses some of the least significant bits for pointer tagging. I suggest using the 8 most significant bits for what could be termed the length of the pointer. A length of zero would mean that the pointer, pointed to a Cons-cell just like we have them today. A length of one would mean that one extra element were embedded into the cons cell. That is, we would have this block of consecutive memory: <Cons marker> <pointer to 1. element> <Cons marker> <pointer to 2. element> <pointer to rest of list> We could also call this a chunk of length two. A pointer of length two, would mean two embedded list elements (a chunk of length three). And so on... By embedding the "length" of the list in the pointer, it becomes possible that one pointer could point to the beginning of a chunk of n consecutive elements, while another one could point to the middle of the same chunk (but the pointer would be of a different length). This would enable sharing without having to break up into smaller chunks. How should chunks be created? Or if a functions creates a lot of one long chunks, how are they turned into longer chunks. I imagine that it would be the job of the garbage collector, to merge the different elements in a list into larger chunks. Of cause some code, like reading a file, could create chunks directly. I have used list as an example. But I imagine that GHC could do this for any recursively defined data type. I can see few, but big disadvantages also. Mainly, my scheme would complicate dereferencing a pointer, which make the compiled code larger and it might make branch prediction harder. The latter would only be a problem on architectures that are pipelined, but popular processors from Intel and AMD are both heavily pipelined. /Mads

6 9

swf flv decoder in haskell
by Louis Plissonneau 29 Mar '10

29 Mar '10

Hi, I have to add some monitoring functions to a shockwave/flash decoder: to precisely evaluate the play buffer (the bar showing download information when you watch a YouTube video for example). I wanted to go for either swfdec or gnash, but as I enjoy Haskell so much, I wonder if there is some open source project on this subject? (even if not all features are supported) Thanks in advance for your advices. Louis Plissonneau

2 1

Re: [Haskell-cafe] Are there any female Haskellers?
by Alberto G. Corona 29 Mar '10

29 Mar '10

> IQ tests, for example. google it. > > 2010/3/28 Jochem Berndsen <jochem(a)functor.nl> > > Alberto G. Corona wrote: >> > The reasons for the sexual differences in mathematical abilities are >> > different, because math abilities are not a -primary- reason for >> > survival. Tools engineering and mastering is. If this is politically >> > incorrect I beg you pardon, but this is my honest theory about that. My >> > other hobby is evolution and evolutionary psichology. I really >> > recommend to learn about it. >> >> Could you point us to any evidence that supports your assumption that >> there are "sexual differences in mathematical abilities"? >> >> Thanks, Jochem >> >> -- >> Jochem Berndsen | jochem(a)functor.nl >> > >

3 3

Re: [Haskell-cafe] Re: Are there any female Haskellers?
by Steve Schafer 29 Mar '10

29 Mar '10

On Mon, 29 Mar 2010 17:32:57 +0200, you wrote: >What's evil in being different? The point is that people use _generic_ differences as a rationale for discrimination against _individuals_. For example, in the US, it has, until recently, been used as an argument against female firefighters, because women, in general, have less upper-body strength than men, and are therefore less able to manage the equipment used. But there are, of course, plenty of women who have upper-body strength significantly above average, as well as men whose upper-body strength is well below average. So the appropriate basis for discrimination is, "Do you have the strength to manage the equipment?" rather than "Are you a man or a woman?" So yes, there are generic differences between As and Bs (whatever categories A and B may represent), but that should not be used as a rationale for discrimination against individual As or Bs, because there is nearly always substantial overlap between the categories in whatever criterion it is that you're measuring. -Steve Schafer

1 0

Fwd: [Haskell-cafe] Re: Are there any female Haskellers?
by Alberto G. Corona 29 Mar '10

29 Mar '10

What's evil in being different? I only see here a form of discrimination that i can label as inherentely sexist and/elitist/or racist: the assumption that certain habilities, the normally associated historically whith men are worth to have and good, and whoever hasn´t them is worth to be discriminated. while the traditionally associated with women, some of the unique, are for slaves. 2010/3/29 Steve Schafer <steve(a)fenestra.com> On Sun, 28 Mar 2010 20:38:49 -0700, you wrote: > > > * The difference between genders is smaller than the difference between > >individuals > > If only people would understand and accept the near-universality of > this: > > "The difference between <any group you want to discriminate against> and > <any group you want to discriminate in favor of> is smaller than the > difference between individuals." > > -Steve Schafer > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >

1 0

ANNOUNCE: Haskelloids
by mrehayden＠googlemail.com 29 Mar '10

29 Mar '10

Haskelloids 0.1.0 has just been uploaded to HackageDB, It's a reasonably faithful (but incomplete) reproduction of the Atari classic, written mostly in the Yampa framework. See the wiki for screenshots. Wikipage: http://www.haskell.org/haskellwiki/Haskelloids HackageBD: http://hackage.haskell.org/package/Haskelloids Enjoy, Matthew Hayden

1 0

Fwd: [Haskell-cafe] Graphical representation of Haskell code
by Miguel Vilaca 29 Mar '10

29 Mar '10

Hi all, Concerning INblobs, it's again online; a fire damaged the cable that links the university to the world!! I don't update the tool for a long time... but I'll take a look on that. Concerning visual functional programming, see this small chapter of my thesis about some of the existing languages. There are more subtleties on the visual side than those expected!! If you also consider debugging tools, take a look on Ghood http://hackage.haskell.org/package/GHood best regards Miguel Vilaça A 2010/03/23, às 05:31, Ronald Guida escreveu: > On Mon, Mar 22, 2010 at 7:02 PM, Dupont Corentin > <corentin.dupont(a)gmail.com> wrote: >> Hello, I’m relatively new to Haskell. >> I’m wondering if it exist a tool to graphically represent Haskell code. > ... >> Let’s try to do it on a simple example, as an exercise: >> f = Map (+1) > > Your graphic for "f = map (+1)" seems much more complex than the > corresponding code. I would agree with Ivan Miljenovic: >> I'm of the opinion that unless you just use it on small snippets, >> the generated images will be too large and unwieldy. > > The first question I would ask is /why/ would you like to visualize > some Haskell code? If you want to see the high-level structure of > a complex program, try SourceGraph. (I have never used it though.) > > On the other hand, if you are trying to visualize Haskell as part of > your efforts to learn the language, then I believe it would be best to > draw diagrams by hand, rather than relying on an automated tool. > The kinds of things that you'll want to depict are probably going to > vary considerably, depending on what you're trying to understand. > > Consider a few different implementations of the "map" function: > > -- version 1: recursion > map1 :: (a -> b) -> [a] -> [b] > map1 f [] = [] > map1 f (x:xs) = (f x) : map1 f xs > > -- version 2: fold > map2 :: (a -> b) -> [a] -> [b] > map2 f = foldr ((:) . f) [] > > -- version 3: continuation passing style > map3 :: (a -> b) -> [a] -> [b] > map3 f xs = map' (\x y -> f x : y) xs > where > map' k [] = [] > map' k (y:ys) = k y (map' k ys) > > -- version 4: list comprehension > map4 :: (a -> b) -> [a] -> [b] > map4 f xs = [f x | x <- xs] > > -- version 5: list monad > map5 :: (a -> b) -> [a] -> [b] > map5 f xs = xs >>= (return . f) > > These all do exactly the same thing, but each one uses different > techniques. If I'm trying to learn (or teach) Haskell, I would > probably need a slightly different visual "language" for each one > in order to capture the most relevant concepts in a useful way. > How would you visualize them? > > @Mihai Maruseac: > I think a visual debugger would be a wonderful idea. You may want > to consider how a visual debugger would work with each of these > versions of map. > > :-) You might also consider several versions of factorial :-) > http://www.willamette.edu/~fruehr/haskell/evolution.html > > -- Ron > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe

6 7

Domains and Co-Domains
by Günther Schmidt 29 Mar '10

29 Mar '10

Hi, I can easily see how one identifies the domain and co-domain of a unary function. How would the domain of a function be expressed that takes more than one argument and arguments of different type? Günther

3 3

GHC vs GCC
by Rafael Cunha de Almeida 29 Mar '10

29 Mar '10

Hello, During a talk with a friend I came up with two programs, one written in C and another in haskell. Haskell main :: IO () main = print $ rangeI 0 0 rangeK :: Int -> Int -> Int -> Int -> Int rangeK i j k acc | k < 1000 = if i * i + j * j + k * k `mod` 7 == 0 then rangeK i j (k+1) (acc+1) else rangeK i j (k+1) acc | otherwise = acc rangeJ :: Int -> Int -> Int -> Int rangeJ i j acc | j < 1000 = rangeJ i (j+1) (acc + rangeK i j 0 0) | otherwise = acc rangeI :: Int -> Int -> Int rangeI i acc | i < 1000 = rangeI (i+1) (acc + (rangeJ i 0 0)) | otherwise = acc C main() { printf("%d\n", rangeI(0, 0)); return 0; } rangeK(i, j, k, acc) { if (k < 1000) { if (i * i + j * j + k * k % 7 == 0) return rangeK(i, j, k+1, acc+1); else return rangeK(i, j, k+1, acc); } else return acc; } rangeJ(i, j, acc) { if (j < 1000) return rangeJ(i, j+1, acc + rangeK(i, j, 0, 0)); else return acc; } rangeI(i, acc) { if (i < 1000) return rangeI(i+1, acc + rangeJ(i, 0, 0)); else return acc; } I tried to keep both programs as similar as possible. I'm pretty confident that the algorithm being executed are exactly the same. That is, there's no lists being used vs. arrays or anything like that. I even used Int instead of Integer to make sure an equivalent version of +, * and mod are called (perhaps that was what I did wrong?) I compiled the haskell code with ghc -O3 and I compiled the C code with gcc -O3. The execution time of the programs were dramatically different. You can test it yourselves, but here is the time I've got in my system: The Haskell version: real 0m45.335s user 0m45.275s sys 0m0.004s against the C version: real 0m6.021s user 0m6.004s sys 0m0.004s Also, I found it interesting that a iterative version of that algorithm in C ran in the same time as the recursive version. So it seems like gcc was successfuly able to make those tail recursive functions into iterations. It strikes me as surprising that Haskell would perform so much slower in that example. I was expecting maybe a few seconds due to the garbage collector or something like that, but not more than 7 times slower.

18 31

parsec and multiple simultaneous token types
by Jeremy Shaw 29 Mar '10

29 Mar '10

Hello, I have some input which is divided up into segments like this: ["foo", "hi", "there", "world"] And I want to use parsec to parse the segments. I am looking for a way to be able to use Char parsers on each segment, but also parse the list of segments as a whole. I have an implementation which works, but I am not feeling that satisfied with it. An example parser looks like this: testp :: GenParser String () (Char, String, String) testp = do segment "foo" st <- p2u (char 'h' >> char 'o') sg <- anySegment sg' <- anySegment return (st,sg, sg') If you use it to parse ["foo", "hi", "there", "world"] you get: *Main> test ["foo","hi","there","world"] (segment 2 character 2): unexpected "i" expecting "o" This is good -- the error tells you the segment and the offset. The combinators, segment and anySegment match on String tokens. The p2u function converts a Char parser into a String parser. The primary issue is that I can not figure out how to implement p2u so that it works under Parsec 2 and 3 with out changes. The secondary issue is that I feel like the DSL is not that great. I would rather write the above parser like this: testp :: GenParser String () (Char, String, String) testp = do string "foo" nextSegment char 'h' >> char 'o' nextSegment sg <- many anyChar nextSegment sg' <- many anyChar return (st,sg, sg') so, the combinators like 'many' would only see to the end of the current segment. nextSegment would bring the next segment into context (or possibly fail if the current segment was not completely consumed). I could also, perhaps, reimplement anySegment as: anySegment = do s <- many anyChar nextSegment return s and write: testp :: GenParser String () (Char, String, String) testp = do string "foo" nextSegment char 'h' >> char 'o' nextSegment sg <- anySegment sg' <- anySegment return (st,sg, sg') I don't see a way to implement this on top of parsec though. Am I missing some clever ideas here? I have attached my code that implements the first method. Any ideas how to make it parsec 2/3 agnostic ? The primary issue is that if I use runParser on the inner Char parser, I need some way to stick a ParseError back into the parent context (with out just converting it to a String and calling fail). I can see how to get/set the inputState, etc, in a portable way, but I don't see how to set the ParseError in a portable way.The attached code requires 3.1.0 because it uses mkPT / runParsecT :( thanks! - jeremy

2 1

How can I parameterize the Candidate?
by Duane Johnson 29 Mar '10

29 Mar '10

Hello, How can I parameterize the type of the following data class so that any type can be a Candidate? type Candidate = String data Poll = Poll [Candidate] [Ballot] My initial thought was to simply put a type variable in place of Candidate, but that clearly won't work: data Poll = Poll [a] [Ballot] >> Not in scope: type variable `a' For context: I am building a voting library that addresses the issue of polarized American politics by implementing the Virtual Round Robin electoral method with a Maximum Majority Voting algorithm for breaking cycles. The beginnings of the library are available at http://github.com/canadaduane/votelib/blob/master/vote.hs What is a good approach to the parameterized type issue? Thank you, Duane Johnson

2 2

Are there any gay haskelleres?
by Günther Schmidt 29 Mar '10

29 Mar '10

Hi guys, are there any gay haskellers? ... Since the first one was so much fun ;) Günther

10 16

Can everyone please update your code to the latest QuickCheck, Parsec, and HaXml this week? Thanks!
by Jeremy Shaw 29 Mar '10

29 Mar '10

Hello, I keep running into issues where I want to use some version of parsec, quickcheck, haxml, etc, in my code, but my code links against a different third party library (e.g. network) which uses a different version of the library (e.g., parsec) than what I want to use, and that makes cabal unhappy. If I use, runhaskell Setup.hs configure, I get warnings like: ~/n-heptane/projects/haskell/web-routes/web-routes-happstack $ runhaskell Setup.hs configure --user Configuring web-routes-happstack-0.18... Warning: This package indirectly depends on multiple versions of the same package. This is highly likely to cause a compile failure. package network-2.2.1.7 requires parsec-2.1.0.1 package hsemail-1.3 requires parsec-2.1.0.1 package happstack-util-0.4.3 requires parsec-2.1.0.1 package happstack-server-0.4.3 requires parsec-2.1.0.1 package web-routes-0.18 requires parsec-3.1.0 Now, the project actually builds and runs fine, because the code in network that uses parsec and the code in my library that uses parsec do not interact at the parsec-level at all. But, cabal install can not handle this, because it (currently) can't *know* that it's actually going to work. Now, parsec and quickcheck are in the haskell platform. So, that should drive a lot of packages to use the same versions. But what about libraries such as HaXml which are not in the platform? Or what about this case where I want parsec 3, even though parsec 2 is in the haskell platform? Any ideas about what should be done? We have this problem with QuickCheck and happstack when people try to cabal install gitit. And I am running into the problem again with the urlt / web-routes library. - jeremy

3 3

Sugar for function application
by Ertugrul Soeylemez 28 Mar '10

28 Mar '10

Hello cafe, I have just had a discussion on #haskell about whether it would be useful to have syntactic sugar for exception handling. This and syntactic sugar in general is a very controversial topic, seeing that 'do' notation is used a lot, where applicative/combinator style would be more appropriate. Some people would call this "abuse". Let me tell you why I would like syntactic sugar, first. Haskell is in many regards very beautiful and the layout of code expresses its structure. However, when it comes to exception handling I have two options: use either parentheses or infix operator style. For my taste both get ugly, as soon as you have more than just an action and its small exception handler. At some point you end up using 'let' and/or 'where' to introduce extra names, something which you would want to avoid in general, unless it really adds value to your code. Currently you introduce names just to make the code look nicer. I find this very unfortunate. However, because it is such a controversial topic whether or not to add syntactic sugar for exceptions, I'm proposing an alternative, which seems to be nicer, because it doesn't introduce extra syntax for specific things (like exceptions) and even has the potential to get rid of some keywords (most notably 'if', 'then' and 'else') without making code look worse: layout-style syntactic sugar for function application. Here is an example of what it might look like: function $$ anArgument sin (x^2) anotherArgument f $ x + 3 printf $$ "%s: %s" key values ! key -- Assuming that 'if' is just a function: -- if :: Bool -> a -> a -> a if $$ even x x^2 (x - 1)^2 catch $$ do someOperation someOtherOperation yetAnotherOperation \exception -> putStrLn "Error:" >> print exception bracket $$ openFile "blah" ReadMode \h -> hClose h >> putStrLn "File closed." \h -> do putStrLn "File opened." doSomethingWithHandle h Instead of the symbolic ($$) I could also think of 'with' or 'of' as appropriate keywords, although 'of' would be ambiguous: catch with do someOperation someOtherOperation yetAnotherOperation \exception -> putStrLn "Error:" >> print exception Also you should be able to use do-style semicolons: printf with "%s: %s"; key; values ! key What do you think? I would love to see this '$$' or 'with' construct as a GHC extension. Greets Ertugrul -- nightmare = unsafePerformIO (getWrongWife >>= sex) http://blog.ertes.de/

5 5

which version is in the platform
by S. Doaitse Swierstra 28 Mar '10

28 Mar '10

On the page: http://hackage.haskell.org/platform/ I am told that the platform includes ghc-6.10.4, but if I click there on the "Haskell:batteries included" link to get to the page: http://hackage.haskell.org/platform/contents.html its states there that I get 6.12.1? Doaitse

5 10

darcs hacking sprint 4 report
by Eric Y. Kow 28 Mar '10

28 Mar '10

Hi everybody, Here's our report from ZuriHac. It's been also posted to the Darcs blog with a couple of photos stolen from Johan's blog, some Darcs rebase scribbling and a screenshot of Darcsden's intriguing fork-tracking feature... http://blog.darcs.net/2010/03/darcs-hacking-sprint-4-report.html The Fourth Darcs Hacking Sprint took place last weekend (19 to 21 March) as part of the Zurich Haskell Hackathon. We had a very productive sprint, a bit of code written, polished off many key discussions, had a little beer and a lot of fun. Overview ====================================================================== In this sprint, we worked on finishing some performance work for the upcoming Darcs 2.5 release this summer (hashed storage, patch index, global caches, inventory hashing); planning our work for the Darcs 2.6 release next year (smart servers, cache cleanup, darcs rebase) and working with new users of the Darcs library. Issues resolved --------------- * issue643 darcs send -o output - Guillaume Hoffmann * issue1473 annotate command line - Stefan Wehr * issue1456 portable darcs dist - Guillaume Hoffmann New Darcs Hackers ====================================================================== We're always happy to work with new Darcs developers. At this sprint, we were joined by four new contributors. Guillaume Hoffmann ------------------ Guillaume has been writing our Darcs Weekly News articles for a year now. Over the weekend he got his first taste of Darcs hacking, knocking out three ProbablyEasy bugs (darcs dist internals, darcs send -o UI, darcs apply with gzipped patch bundles). Guillaume reports that he can see himself doing more of this in the future! Steven Keuchel -------------- Steven worked on a new feature to display the file contents hashed associated with any patch. This makes it easier for third party tools to inspect the patch files behind Darcs. Stefan Wehr and David Leuschner -------------------------------- Stefan and David mostly worked on the Darcs Patch Manager, but to warm up, they tackled a couple of ProbablyEasy bugs, particularly a bug in darcs annotate that was affecting Redmine Hacking continued... ====================================================================== Bugfix: Darcs on Windows shares ------------------------------- Salvatore tracked down the Windows regression on 2.4 that make Darcs not work on windows shares. Performance: Fast darcs annotate -------------------------------- Benedikt Schmidt continued his work on the patch index (formerly known as the filecache). The patch index keeps track of which patches affect which files. This index will bring a big boost to darcs annotate performance, particularly for files which are affected by relative small number of patches. Performance: Global cache ------------------------- Luca continued his work on breaking up the global cache ($HOME/.darcs/cache) into buckets for faster access. Working with Reinier and Petr, Luca has developed an approach to migrating from old style caches to the new style bucketed ones. He has also improved the implementation to use hard links, to avoid disk space doubling and to preserve backwards compatibility with prior versions of Darcs. Windows installer ----------------- Salvatore put together a nice Windows installer using the `bamse package <http://hackage.haskell.org/package/bamse>`_. It looks like we will be able to use this for the planned Darcs 2.5 release this summer. This work will also open the door to nicer integration with Windows tools, for example, using a bundled Tortoise SSH for better experience working with SSH passphrases. Interactive cherry picking -------------------------- Florent improved the quality of the Darcs cherry picking code, making it easier to fine tune our user interface and some day support graphical interfaces via the Darcs library. Witnessed list zippers for the win? Interactive diff ---------------- Florent also started work on adding Darcs's interactive cherry picking to darcs diff, making it possible to choose a set of patches to view as a diff. Performance: Hashed storage completion -------------------------------------- Darcs has a representation of file and directory trees called slurpies. Petr polished off his work to replace the slurpies with his more efficient, general purpose hashed-storage library. Slurpies are going away, and Darcs will be faster for it. He and Ganesh also discussed how to gracefully transition from repositories created before the hashed-storage refactor. Performance: Using tags when writing patches -------------------------------------------- Petr ported work by David Roundy to solve a `scalability regression <http://bugs.darcs.net/issue1106>`_ in hashed repositories. For darcs commands that write out patches, we had a naive hashing operation that does not account for the fact that patches behind tags cannot be modified. Darcs was unnecessarily traversing the entire sequence of patches (ie. O(n) time) when it could easily have been just traversing the sequence since the last tag. UTF-8 metadata -------------- Reinier continued to improve the encoding of Darcs patch metadata. Darcs is completely agnonstic with respect to the encoding of your files. Unfortunately, this agnostism extends to patch metadata (patch name, patch author), making it difficult for people to collaborate across different locales. To address this problem, Reinier has been working to make Darcs store its patch metadata in a single encoding (UTF-8) while gracefully supporting older patches (with metadata in potentially any encoding). Discussions ====================================================================== Release process --------------- The Darcs 2.4 release was quite a tricky one to navigate. We found that bugs were only being flushed out on release candidate time and sometimes after the release proper. We would like to encourage more people to try out Darcs work in progress and give us feedback early in the release process. After chatting about this, Reinier (with Ganesh, Eric and Petr) decided that as Release Manager, he would put out a Darcs alpha every 4 weeks. In the future we may investigate automatic nightly builds via the buildbot and a platform support policy such as the one used by Tahoe. Darcs patch index (fast darcs annotate) --------------------------------------- Benedikt updated us on the recent status of his ongoing patch index work (formerly known as the filecache). We discussed the things that make the patch index convincing (permanant, repo-local, unique identifiers for files) the interaction between the patch index and the type witnesses and also ways of tuning the patch index performance and keeping it small. We're looking forward to sharing the new patch index optimisation with you in upcoming releases. Darcs annotate may become a lot more useful in the next couple of releases! Readable darcs annotate ----------------------- Fast darcs annotate won't be useful if nobody can read it. Benedikt and Eric worked on designing a better output format darcs annotate. Taking a page from git blame, there will be one line per source file line, with columns for patch identifier, author name, date and finally the line. One of the design questions was how we should best refer to darcs patches, the current best candidate being a prefix of the darcs patch metadata hash. Fast darcs over networks ------------------------ Darcs get over networks is slow, painfully slow. Petr has suggested two priorities for improving the performance of network operations. The first would be to introduce a `darcs optimize --http <http://bugs.darcs.net/issue1771>`_ feature which would optimise the Darcs repository for fetching over a network (for example, by creating a "snapshot" of the pristine cache to be fetched in one go). The second priority would be develop a `smart server <http://bugs.darcs.net/issue1773>`_ that would provide darcs clients with only the files they need and in the optimal number of chunks. The two ideas combined would make an excellent Google Summer of Code project. Darcs rebase ------------ Prior to the sprint, Ganesh has been working on a `darcs rebase <http://wiki.darcs.net/Ideas/RebaseDesign>`_ feature which will help Darcs users work with long term branches, and other cases where patch commutation by itself is not enough. At the sprint, Ganesh explained his work to everyone interested. Together we settled on a rough plan for the user interface. It looks like our new rebase command will offer a typically Darcs-ish twist: interactive cherry picking. Darcs library ------------- Ganesh and Florent talked with three teams building software in the Darcs ecosystem (DPM: Stephan Wehr and David Leuschner, Mac Darcs record GUI: Benedikt Huber and David Markvica, DarcsDen: Alex Suraci). There was a surprising degree of commonality. The conversations have given us a much stronger sense of direction with the Darcs library. In particular, Ganesh is convinced that we should commit to our use witnesses - at the very least getting them completely finished so we can run with them, probably turning them on by default, and quite possibly dropping the non-witnesses builds. Default switches ---------------- We held a quick roundtable discussion to settle some decisions on Darcs default switches that have been hanging in the air. Our decisions for Darcs 2.5: * --no-set-scripts-executable [unchanged] * pull/push/send --no-set-default * send --edit-description * record --no-test * check --no-test Performance presentations ------------------------- Petr and Benedkit gave lighting talks, showing some of our recent performance work to the Haskell community. Some exciting numbers from Benedikt's work (`notes <http://wiki.darcs.net/Ideas/PatchIndex>`_) include a 6 second darcs annotate on a file in the GHC repository (previously this did not complete within a half hour). With Petr's work, we are able to [TODO numbers]. Google Summer of Code ---------------------- We discussed our priorities for this year's Google Summer of Code. We have decided that we would focus our attention on performance issues. If we had two GSoC students this year, we would be mainly interested in dividing them between network performance developing a smart server for much faster darcs get and pull over a network local performance performing a comprehensive overhaul of the Darcs hashed file cache handling We also discussed ways to make the best use of our students' time. The Darcs team has participated in GSoC twice and learning a lot from the experience. This year we would like to see if we could publish some clear guidelines both on what we expect from GSoC students and what they can expect from us. Watch the mailing list for more discussion on this topic. Budding Ecosystem ====================================================================== We were pleasantly suprised to find ourselves with users of the (still unstable) Darcs API. These new arrivals give us the feeling that the collection of `related software <http://wiki.darcs.net/RelatedSoftware>`_ is coalescing into a new Darcs ecosystem. Darcs Patch Manager ------------------- David Leuschner and Stefan Wehr worked on an exciting new patch management program for project maintainers. The Darcs Patch Manager (DPM) offers a new way for repository maintainers to keep track of incoming Darcs patches, including their amendements and dependencies. :: $ dpm -r MAIN_REPO -s DPM_DB list very cool feature [State: OPEN] 2481 Tue Mar 16 17:50:23 2010 Dave Devloper <dave(a)example.com> State: UNDECIDED, Reviewed: no added 7861 Tue Mar 16 17:20:45 2010 Dave Devloper <dave(a)example.com> State: REJECTED, Reviewed: yes marked as rejected: one minor bug some other patch [State: OPEN] 7631 Tue Mar 16 13:15:20 2010 Eric E. <eric(a)example.com> State: REJECTED, Reviewed: yes added ... Towards the end of the hackathon, David gave a nice short demo of DPM in action and deftly avoided the wrath of the demo Gods. MacOS X GUI for Darcs record ---------------------------- Benedikt Huber and David Markvica started work on a graphical interface to the Darcs record command. One key twist is that they make use of the Darcs API to get the kind of dependency-tracking interactiveness goodness that Darcs offers. Bendedikt and Huber report that they have spent most of the hackathon getting to grips with the library. Darcs type witnesses were very helpful for avoiding errors, but they also impose a steep learning curve. Darcsden -------- Alex Suraci and Simon Michael made several improvements to `Darcsden <http://darcsden.com/>`_, an open source hosting solution (akin to Github and Patch-tag). Some recent changes were Atom feeds, the ability to view forks of your repository and cherry-pick patches from them (work in progress). Darcsden also makes use of the Darcs API. Want to host Darcs Hacking Sprint 2010-10? ====================================================================== The Darcs Team would like to hold hacking sprints twice a year. These sprints are an important occassion for us to hold design discussions, hack some code, train new Darcs hackers and generally bond as a team. Do you think you can help? Please get in touch with me if you think you may be able to host a group of around 20 Darcs hackers one of these October or November weekends. Thanks! ====================================================================== Getting over 75 Haskell hackers into Zürich and having them up and running on arrival (Swiss power plugs notwithstanding) was no easy task! We'd like to thank Johan Tibell, David Anderson and the rest of the Google Crew for their hard work organising this hackathon. Thanks also to the generous donors who chipped into our 2010 Darcs Travel Fund. We'll be looking forward to using the leftover cash for the upcoming 5th Darcs Hacking Sprint in October or November. Finally here are some words from happy Darcs hackers: The sprint was a wonderful social occasion, and it was great meeting most of the Darcs hackers, and also seeing other Haskell hackers interested in working in the Darcs ecosystem. I especially enjoyed teaching them how to use our API. -- Florent The atmosphere was wonderful and I consider the sprint to have been very productive overall. -- Petr This is coolest thing I ever did -- Luca See you in half a year! Participants ====================================================================== We had ten Darcs hackers in Zürich along with four Haskellers using the Darcs API to do awesome things (plus two more on IRC). - Florent Becker - Guillaume Hoffmann - Eric Kow - Reinier Lamers - Ganesh Sittampalam - Petr Rockai - Salvatore Insalaco - Luca Molteni - Benedikt Schmidt - Steve Keuchel - Benedikt Huber - David Markvica - Stefan Wehr - David Leuschner - Simon Michael [IRC] - Darcsden - Alex Suraci [IRC] - Darcsden -- Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow> PGP Key ID: 08AC04F9

1 0

Has "Try Haskell! An interactive tutorial in your browser" been announced yet?
by DekuDekuplex＠Yahoo.com 28 Mar '10

28 Mar '10

There is a link to "Try Haskell! -- an interactive, online Haskell interpreter" (see http://tryhaskell.org/) under "February 2010" under "1 Headlines" on the "Haskell - HaskellWIki" Web page (see http://www.haskell.org/) While I could be mistaken, there do not seem to be any announcements for February 2010 concerning this interactive tutorial on either the Haskell or Haskell-Cafe mailing lists. Has it been announced yet? If not, can I go ahead and announce it on the Haskell mailing list? -- Benjamin L. Russell -- Benjamin L. Russell / DekuDekuplex at Yahoo dot com http://dekudekuplex.wordpress.com/ Translator/Interpreter / Mobile: +011 81 80-3603-6725 "Furuike ya, kawazu tobikomu mizu no oto." -- Matsuo Basho^

6 7

Fwd: [Haskell-cafe] Re: Are there any gay haskelleres?
by Alberto G. Corona 28 Mar '10

28 Mar '10

Also some operators are clearly sexist >>=, -> => etc etc. I don´t kmow if the lack of female haskellers is due to this inpudic exhibition of male domination ;) 2010/3/28 Ertugrul Soeylemez <es(a)ertes.de> Fraser Wilson <blancolioni(a)gmail.com> wrote: > > > I'm sure there's some theory about fags being unable to use tools and > > stuff. > > It certainly cannot be anything to do with cultural pressure. > > Perhaps it is easy to mistake a male-dominated field for one that > > males are intrinsically good at, but really, have a look at the Y > > chromosome, it does nobody any favours. Gender is hormonal. > > I'd rather look at the Y combinator, which kind of resembles a penis: > > Y = \ > f > -> (\x -> f (x x)) (\x -> > f > (x x)) > > > Greets, > Ertugrul > > > -- > nightmare = unsafePerformIO (getWrongWife >>= sex) > http://blog.ertes.de/ > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >

1 0

is anyone familiar with "Comprehending Queries" by Torsten Grust?
by Günther Schmidt 28 Mar '10

28 Mar '10

Hi all, is anyone here familiar with the paper "Comprehending Queries" by Thorsten Grust? http://kops.ub.uni-konstanz.de/volltexte/1999/312/pdf/312_1.pdf As the paper dates from 1999 I wonder if its content may have been "obsoleted" by later works or if it still is pretty much current. I ask this because I'm still struggling to put my program with lots of queries on a more sound code base. Günther

2 2

First Ghent FPG Meeting on April 1, 19h: Program and Final Details
by Jeroen Janssen 28 Mar '10

28 Mar '10

Dear all, We are nearing the First Ghent Functional Programming Group (Ghent FPG) Meeting, and, judging by the number of people that registered on the google form (28!), it will be quite crowded! The final formal program is as follows: 1. Jeroen Janssen - Welcome and short introduction to FP 2. Jasper Van der Jeugt - "BlazeHtml: a blazingly fast Html generator in Haskell" 3. Tom Schrijvers - "Functional Pearl: The Monad Zipper" 4. Romain Slootmaekers - "Functional Programming at Amplidata" (not yet fully confirmed) 5. Denis Defreyne, Pieter De Baets - "An introduction to Phunctional Programming" 6. Short discussion on the direction of the Ghent Functional Programming Group The meeting takes place on Thursday, April 1, starting at 19h, in meeting room "Shannon" of the Technicum Building of Ghent University (Sint-Pietersnieuwstraat 41, 9000 Gent). Since the automatic sliding doors will be closed, we will put up a note on the sliding doors on the front left, with a phone number you can call to get in. If you are uncertain whether you'll be able to find the venue, just ask for our cellphone number by e-mail, so you can call us if you get lost. Hope to see you all on Thursday, Bart Coppens (Bart.Coppens(a)elis.ugent.be) Jeroen Janssen (jejansse(a)gmail.com) The Ghent FPG organizing committee.

1 0

Refactoring of OAuth Library - Need Review
by Diego Souza 28 Mar '10

28 Mar '10

Hi, I've done a complete refactoring of oauth library. This new version is incompatible (in terms of interface) with the previous one. An example of use is available here: http://projects.bitforest.org/hoauth/dist/doc/html/hoauth/Network-OAuth.html Probably the major change is that, along the functions that deal with oauth authentication, there is now an HttpClient typeclass. The library now is able to perform http requests and fully deal with the oauth protocol. I'm planning to upload to hackage soon enough, but before that I'd like to ask if someone could review it and send feedbacks. That would be much appreciated. To get the code: $ darcs get http://projects.bitforest.org/hoauth/ To run tests: $ haskell -isrc/main/haskell -isrc/test/haskell src/test/haskell/Tests.hs Thanks in advance, ~dsouza

1 1

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 28 Mar '10

28 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

Takusen sqlite3 insert is very slow
by Vasyl Pasternak 26 Mar '10

26 Mar '10

Hi Cafe, I have another problem, please look at code: storeInDb = withSession (connect "test.db") (do execDDL (sql "create table x (y int)") forM_ ([1..10000] :: [Int]) (\x -> do execDML (cmdbind ("insert into x (y) values (?);") [bindP x]) return ())) This code runs 16 seconds which is very slow for this simple task. RTS output is below. After profiling this program I found that 85% of its time it spends in 'Database.Sqlite.SqliteFunctions.stmtFetch'. Currently I don't know how to make it faster, maybe anyone had this problem later? HDBC inserts very fast, so this is not sqlite error. RTS output: 156,195,264 bytes allocated in the heap 591,280 bytes copied during GC 3,952 bytes maximum residency (1 sample(s)) 10,968 bytes maximum slop 1 MB total memory in use (0 MB lost due to fragmentation) Generation 0: 295 collections, 0 parallel, 0.00s, 0.01s elapsed Generation 1: 1 collections, 0 parallel, 0.00s, 0.02s elapsed INIT time 0.00s ( 0.03s elapsed) MUT time 0.87s ( 16.09s elapsed) GC time 0.00s ( 0.02s elapsed) RP time 0.00s ( 0.00s elapsed) PROF time 0.00s ( 0.00s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 0.88s ( 16.14s elapsed) %GC time 0.5% (0.1% elapsed) Alloc rate 179,111,917 bytes per MUT second Productivity 99.5% of total user, 5.4% of total elapsed Regards, Vasyl

4 4

Windows version of Haskell Platform containing ghc 6.12
by Han Joosten 26 Mar '10

26 Mar '10

Last weekend a new version of the haskell platform has been released. I was expecting that also for windows the ghc 6.12 would be in it. However, when I follow the link: http://hackage.haskell.org/platform/windows.html I still get the 'old' version (2009.2.0.2) which contains ghc 6.10 Is this intentional? If so, is there anything to say when a windows version of the platform will become available that contains ghc 6.12? Thanks! Han -- View this message in context: http://old.nabble.com/Windows-version-of-Haskell-Platform-containing-ghc-6.… Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

2 1

sendfile leaking descriptors on Linux?
by Bardur Arantsson 26 Mar '10

26 Mar '10

Hi all, I've been using the sendfile package off Hackage, but it seems to be leaking file descriptors when using the Linux-native build. What's happening in my specific case is the following: 1) client requests a range of a file 2) server starts sending the range 3) client disconnects before receiving the whole file This happens over and over with the client requesting different ranges of the file (so the client does make progress). If I use the portable build of the sendfile package, everything works fine for hours and hours of this happening. If I use the Linux-native build of the sendfile package, the server will eventually run out of file descriptors. According to "lsof" the files that are being kept open are the data files being sent in 2) above. This is on GHC 6.10.x (Ubuntu). Is anyone else seeing this? Anyone got any idea what's going on? Cheers,

10 62

Is hGetLine lazy like hGetContents? And what about this todo item?
by Jason Dagit 25 Mar '10

25 Mar '10

Hello, I was trying to figure out if hGetLine is safe to use inside of withFile. Specifically, I want to return the line I read and use it later, without inspecting it before withFile calls hClose. If you want to understand the concern I have, look here: http://www.haskell.org/haskellwiki/Maintaining_laziness#Input_and_Output There is a bit of explanation showing that hGetContents can be problematic with withFile. I can tell from reading the source of hGetContents that it uses unsafeInterleaveIO so this make sense to me why that wiki page talks about hGetContents: http://www.haskell.org/ghc/docs/latest/html/libraries/base/src/GHC-IO-Handl… When I read the source of hGetLine, it is less clear to me if I need to be concerned. I believe it is not lazy in the sense of lazy IO above. Could someone else please comment? http://www.haskell.org/ghc/docs/latest/html/libraries/base/src/GHC-IO-Handl… Then I notice this 'todo' item in the description: -- ToDo: the unbuffered case is wrong: it doesn't lock the handle for -- the duration. The code itself looks to me like it only handles the buffered case. Perhaps this todo is obsolete and needs to be removed? If it's not obsolete, do we need to create a ticket for this? Thanks, Jason

3 5

HLIst - how to use TIPTransform with functions that run in the IO monad?
by Andrew U. Frank 25 Mar '10

25 Mar '10

i use the TIPTransform module that Oleg has provided - very nice and easy to use! Thank you Oleg!! now i run into a problem, i seem not to be able to resolve: how to use TIPTransform with functions that use the IO monad? considering the example tip5 in Olegs communiation, where he uses a function with three arguments from the TIP (HList) and producing a result in the HList. i would like to use a similar functionality, getting the arguments from the HList and producing a result which is again stored in the HList - but the function has a signature like f :: Int -> String -> IO String. the resulting string should go int the HList. i assume i need a function like ttip: ttipM :: op -> db -> IO db? can somebody help me with this? i appreciate any help! andrew

1 0

ANNOUNCE: cuboid 0.12: 3D Yampa/GLUT Puzzle Game
by Pedro Martins 25 Mar '10

25 Mar '10

Hi all, Recently, I have been playing around a bit with Yampa and GLUT, integrating them and trying to develop a simple 3D game within the framework. As it involved quite a bit of source code reading from Yampa and Frag (thanks to both!), I have decided to upload the game to Hackage, to help other people interested in using AFRP for game development. Overall, the experience of using Yampa was very pleasing, as it allowed me to describe the logic of the game in a more declarative fashion than usual. However, because there aren't many tutorials/examples on using Yampa for games, it involved a fair amount of experimentation and so my code might not be very idiomatic for Yampa. Please tell me if so and I'll fix it so this can be a good example. For playing instructions, see the Hackage description [1]. It currently only has 3 hardcoded easy levels, but the level definition is a simple Haskell ADT definition (Game.hs), and I plan on placing it in a separate data file in the future. This is my first upload to Hackage, so any comments or suggestions are welcome. Thanks, Pedro [1] http://hackage.haskell.org/package/cuboid

1 0

existentially quantified data types - restrictions
by Ozgur Akgun 25 Mar '10

25 Mar '10

Dear Cafe, I need to use a language feature which is explicitly documented to be a restriction, and -even worse- I think I reasonably need to use it. f2 (Baz1 a b) (Baz1 p q) = a==q > It's ok to say a==b or p==q, but a==q is wrong because it equates the two > distinct types arising from the two Baz1 constructors. > [from *7.4.4.4. Restrictions* at > http://www.haskell.org/ghc/docs/latest/html/users_guide/data-type-extension… > ] > To simplify, let's say Baz is the only constructor of a data type, data Baz = forall a. Eq a => Baz a -- | this cannot be done: instance Eq (Baz a) where (Baz x) == (Baz y) = x == y I am quite tempted to use show functions for this equality comparison, but after trying to have a nicely type framework I really don't want to do that. What I simply want is, haskell to be able to compare them if they belong to the same type, and return False otherwise. (not that haskelly way of doing things, I know.) Any suggestions better than the following are very welcome: (==) = (==) `on` show Regards, -- Ozgur Akgun

3 4

double existential type
by Ozgur Akgun 25 Mar '10

25 Mar '10

Hello all, I have a syntax issue (hopefully!) -- this is perfectly fine: data Unary = forall a. Unary a -- this one as well: data Binary = forall a. Binary a a -- but not this one -- parse error on input forall :( data Binary' = forall a. forall b. Binary' a b I tried different kinds of bracketings and orderings but no luck... Best, -- Ozgur Akgun

3 4

Re: [Haskell-cafe] phonetic dictionnary
by Dupont Corentin 25 Mar '10

25 Mar '10

Thanks, this dictionnary is exactly what i wanted! Too bad it doesn't exists in French! On 3/25/10, Max Rabkin <max.rabkin(a)gmail.com> wrote: > There is the CMU phonetic dictionary for English at > http://www.speech.cs.cmu.edu/cgi-bin/cmudict but I know of nothing for > French. Perhaps there is an open-source text-to-speech engine that has > a free French pronouncing dictionary. > > --Max > > On Thu, Mar 25, 2010 at 2:59 PM, Dupont Corentin > <corentin.dupont(a)gmail.com> wrote: >> Hello, >> sorry if i ask a lot of questions these days! >> Do you know of a phonetic dictionnary? >> >> i'm very fond of enigmas. To solve certain enigmas, i've made a little >> program that search into a french dictionnary. >> But it would be much better if i could search into a phonetic >> dictionnary... >> The goal is to answer questions like "Wich word would rhyme with >> aligator?" >> >> Corentin >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe(a)haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >

1 0