- Haskell-Cafe - Haskell.org

how to release (on hackage) a package that needs foreign libs?
by Johannes Waldmann 16 Feb '13

16 Feb '13

What is the recommended approach for publishing (on hackage) a package that depends on external libraries? In my case, the current version of http://hackage.haskell.org/package/satchmo (sources at https://github.com/jwaldmann/satchmo) depends on minisat-haskell-bindings (in Haskell), minisat-c-bindings (in C), and minisat (C++), all from https://github.com/niklasso/ My guess is that this would require that the external libraries are packaged (deb, rpm?), then hackage gods install them, and only then, my package will be built (and docs will be shown)? - J.W.

1 0

optimization of recursive functions
by Andrew Polonsky 16 Feb '13

16 Feb '13

Hello, Is there any difference in efficiency between these two functions, when compiled with all optimizations? map f [] = [] map f (a:as) = f a : map f as and map f x = map' x where map' [] = [] map' (a:as) = f a : map' as Thanks, Andrew

3 3

ANN: rss2irc-1.0, announces RSS/Atom feed updates to IRC
by Simon Michael 15 Feb '13

15 Feb '13

I'm pleased to announce a new release of rss2irc, the software behind hackagebot on #haskell. rss2irc is an IRC bot that polls an RSS or Atom feed and announces updates to an IRC channel, with options for customizing output and behavior. It aims to be an easy-to-use, reliable, well-behaved bot. Release notes: 1.0 (2013/2/15) New: * more robust item detection and duplicate announcement protection, with simpler options * easier irc address syntax, drop -p/--port option * can poll urls with semicolon parameter separator (eg darcsweb's) * can poll https feeds * can poll from stdin (-) * can poll a file containing multiple copies of a feed (eg for testing) * can announce item urls containing percent * `--cache-control` option sets a HTTP Cache-Control header * `--use-actions` announces with CTCP ACTIONs (like the /me command) Fixed: * updated for GHC 7.6 & current libs * initialises http properly on microsoft windows * builds threaded and optimised by default * thread and error handling is more robust, eg don't ignore exceptions in the irc writer thread * no longer adds stray "upload:" to IRC messages * renamed --dupe-descriptions to `--allow-duplicates` * dropped --debug flag * new item detection and announcing is more robust * announcements on console are clearer * a simulated irc connection is not logged unless --debug-irc is used Best, -Simon

1 0

(+) on two lists ?
by sheng chen 15 Feb '13

15 Feb '13

Hi, I was puzzled by the following little program. sum' [] = [] sum' (x:xs) = x + sum' xs I thought the GHC type checker will report a type error. However, the type checker accepts this program and gives the type Num [a] => [[a]] -> [a] When I add type annotation to the program sum' :: Num [a] => [[a]] -> [a] sum' [] = [] sum' (x:xs) = x + sum' xs The GHC asks me to add FlexibleContexts language extension. I would appreciate explanation on this issue. Thanks, Sheng

5 4

How to quantify the overhead?
by Daryoush Mehrtash 15 Feb '13

15 Feb '13

Before I write the code I like to be able to quantify my expected result. But I am having hard time quantifying my expected result for alternative approaches in Haskell. I would appreciate any comments from experienced Haskell-ers on this problem: Suppose I have a big list of integers and I like to find the first two that add up to a number, say 10. One approach is to put the numbers in the map as I read them and each step look for the 10-x of the number before going on to the next value in the list. Alternatively, I am trying to see if I it make sense to covert the list to a series of computations that each is looking for the 10-x in the rest of the list (running them in breath first search). I like to find out sanity of using the Applicative/Alternative class's (<|>) operator to set up the computation. So each element of the list (say x) is recursively converted to a computation to SearchFor (10 - x) that is (<|>)-ed with all previous computation until one of the computations returns the pair that add up to 10 or all computation reach end of the list. Does the approach make any sense? What kind of overhead should I expect if I convert the numbers to a computation on the list? In one case I would have a number in a map and in the other I would have a number in a computation over a list. How do I quantify the overheads? Thanks, Daryoush

2 1

python under attack. ??Haskell??
by Rustom Mody 15 Feb '13

15 Feb '13

Please see http://pyfound.blogspot.in/2013/02/python-trademark-at-risk-in-europe-we.ht… I cannot say that I understand whats really going on The one thing that I get is that there was some minor neglect a decade or more ago. <http://blog.languager.org>Maybe there are things that Haskell needs to beware of?

1 0

performance question
by Nicolas Bock 14 Feb '13

14 Feb '13

Hi list, I wrote a script that reads matrix elements from standard input, parses the input using a regular expression, and then bins the matrix elements by magnitude. I wrote the same script in python (just to be sure :) ) and find that the python version vastly outperforms the Haskell script. To be concrete: $ time ./createMatrixDump.py -N 128 | ./printMatrixDecay real 0m2.655s user 0m2.677s sys 0m0.095s $ time ./createMatrixDump.py -N 128 | ./printMatrixDecay.py - real 0m0.445s user 0m0.615s sys 0m0.032s The Haskell script was compiled with "ghc --make printMatrixDecay.hs". Could you have a look at the script and give me some pointers as to where I could improve it, both in terms of performance and also generally, as I am very new to Haskell. Thanks already, nick

14 34

When the gauge depends on what it measures
by Alexander Bernauer 14 Feb '13

14 Feb '13

Hi, I am currently working on benchmarking the pretty library. Pretty itself has no non-trivial dependencies. But criterion and language-c, which I use to perform the benchmarks, directly and/or indirectly depend on pretty. Everything is configured in one Cabal file via library and benchmark sections. Now, whenever I modify pretty and want to rebuild the bench executable, things become messy. Either I rebuild criterion et al. as well, or the bench executable ends up with two different pretty version built in - if this is even possible. Until now I could not find a robust workflow for this scenario. At some point pretty "shadows" itself and the build fails (c.f. my previous caffee post). What is the right way to handle this scenario? Confused greetings, Alex

4 3

Why isn't "Program Derivation" a first class citizen?
by Nehal Patel 14 Feb '13

14 Feb '13

A few months ago I took the Haskell plunge, and all goes well... -- but I really want to understand the paradigms as fully as possible, and as it stands, I find myself with three or four questions for which I've yet to find suitable answers. I've picked one to ask the cafe -- like my other questions, it's somewhat amorphous and ill posed -- so much thanks in advance for any thoughts and comments! ---- Why isn't "Program Derivation" a first class citizen? --- (Hopefully the term "program derivation" is commonly understood? I mean it in the sense usually used to describe the main motif of Bird's "The Algebra of Programming." Others seem to use it as well...) For me, it has come to mean solving problems in roughly the following way 1) Defining the important functions and data types in a pedantic way so that the semantics are clear as possible to a human, but possibly "inefficient" (I use quotes because one of my other questions is about whether it is really possible to reason effectively about program performance in ghc/Haskell…) 2) Work out some proofs of various properties of your functions and data types 3) Use the results from step 2 to provide an alternate implementation with provably same semantics but possibly much better performance. To me it seems that so much of Haskell's design is dedicated to making steps 1-3 possible, and those steps represent for me (and I imagine many others) the thing that makes Haskell (and it cousins) so beautiful. And so my question is, that in 2013, why isn't this process a full fledged part of the language? I imagine I just don't know what I'm talking about, so correct me if I'm wrong, but this is how I understand the workflow used in practice with program derivation: 1) state the problem pedantically in code, 2) work out a bunch of proofs with pen and paper, 3) and then translate that back into code, perhaps leaving you with function_v1, function_v2, function_v3, etc -- that seems fine for 1998, but why is it still being done this way? What I'm asking about might sound related to theorem provers, -- but if so ,I feel like what I'm thinking about is not so much the very difficult problem of automated proofs or even proof assistants, but the somewhat simpler task of proof verification. Concretely, here's a possibility of how I imagine the workflow could be: ++ in code, pedantically setup the problem. ++ in code, state a theorem, and prove it -- this would require a revision to the language (Haskell 201x) and perhaps look like Isabella's ISAR -- a -structured- proof syntax that is easy for humans to construct and understand -- in particular it would possible to easily reuse previous theorems and leave out various steps. At compile time, the compiler would check that the proof was correct, or perhaps complain that it can't see how I went from step 3 to step 4, in which case I might have to add in another step (3b) to help the compiler verify the proof. ++ afterwards, I would use my new theorems to create semantically identical variants of my original functions (again this process would be integrated into the language) While I feel like theorem provers offer some aspects of this workflow (in particular with the ability to export scala or haskell code when you are done), I feel that in practice it is only useful for modeling fairly technically things like protocols and crypto stuff -- whereas if this existed within haskell proper it would find much broader use and have greater impact. I haven't fully fleshed out all the various steps of what exactly it would mean to have program derivation be a first class citizen, but I'll pause here and followup if a conversation ensues. To me, it seems that something like this should be possible -- am i being naive? does it already exist? have people tried and given up? is it just around the corner? can you help me make sense of all of this? thanks! nehal

7 6

ANNOUNCE: graphviz-2999.16.0.0
by Ivan Lazar Miljenovic 14 Feb '13

14 Feb '13

I'm pleased to announce that I've finally tracked down all the pesky little bugs that prevented me from releasing version 2999.16.0.0 of my graphviz library, that helps you use the Graphviz suite of tools to visualise graphs. The important changes are: * Add support for Graphviz-2.30.0: - New attributes: + `Area` + `Head_LP` + `LayerListSep` + `LayerSelect` + `Tail_LP` + `XLP` - `BgColor`, `Color` and `FillColor` now take a list of colors with optional weightings. - Layer handling now supports layer sub-ranges. - Added the voronoi-based option to `Overlap`. - Added the `Striped` and `Wedged` styles. * Updates to attributes and their values: - The following attributes have had their values changed to better reflect what they represent: + `FontPath` takes a `Path` value. + `Layout` takes a `GraphvizCommand` (and thus `GraphvizCommand` has been moved to `Data.GraphViz.Attributes.Complete`). - Added `MDS` to `Model` (which had somehow been overlooked). - Various attributes now have defaults added/updated/removed if wrong. - Removed the following deprecated attributes: + `ShapeFile` + `Z` * Now any value that has a defined default can be parsed when the Dot code just has `attribute=""` (which `dot -Tcanon` is fond of doing to "reset" attributes). * `GraphvizCommand` now defines `Sfdp` (which had somehow been overlooked up till now). * The `canonicalise` and related functions have been re-written; whilst there might be some cases where their behaviour does not fully match how `dot -Tcanon` and `tred` behave (due to the interaction of various attributes), the new implementation is much more sane. * Use temporary files rather than pipes when running dot, etc. Makes it more portable, and also avoids issues where dot, etc. use 100% CPU when a graph is passed in via stdin. Original patch by Henning Thielemann. -- Ivan Lazar Miljenovic Ivan.Miljenovic(a)gmail.com http://IvanMiljenovic.wordpress.com

1 0