- Haskell-Cafe - Haskell.org

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