- Haskell-Cafe - Haskell.org

Shootout update
by Simon Marlow 31 Mar '10

31 Mar '10

The shootout (sorry, Computer Language Benchmarks Game) recently updated to GHC 6.12.1, and many of the results got worse. Isaac Gouy has added the +RTS -qg flag to partially fix it, but that turns off the parallel GC completely and we know that in most cases better results can be had by leaving it on. We really need to tune the flags for these benchmarks properly. http://shootout.alioth.debian.org/u64q/haskell.php It may be that we have to back off to +RTS -N3 in some cases to avoid the last-core problem (http://hackage.haskell.org/trac/ghc/ticket/3553) at least until 6.12.2. Any volunteers with a quad-core to take a look at these programs and optimise them for 6.12.1? Cheers, Simon

5 5

Benchmarking and Garbage Collection
by Neil Brown 31 Mar '10

31 Mar '10

Hi, I'm looking at benchmarking several different concurrency libraries against each other. The benchmarks involve things like repeatedly sending values between two threads. I'm likely to use Criterion for the task. However, one thing I've found is that the libraries have noticeably different behaviour in terms of the amount of garbage created. Criterion has an option to perform GC between each benchmark, but I think that the benchmark is only fair if it takes into account the GC time for each system; it doesn't seem right for two systems to be counted as equal if the times to get the results are the same, but then one has to spend twice as long as the other in GC afterwards. Here's some options I've considered: * I could make a small change to Criterion to include the time for performing GC in each benchmark run, but I worry that running the GC so often is also misrepresentative (might 100 small GCs take a lot longer than one large GC of the same data?) -- it may also add a lot of overhead to quick benchmarks, but I can avoid that problem. * Alternatively, I could run the GC once at the end of all the runs, then apportion the cost equally to each of the benchmark times (so if 100 benchmarks require 0.7s of GC, add 0.007s to each time) -- but if GC is triggered somewhere in the middle of the runs, that upsets the strategy a little. * I guess a further alternative is to make each benchmark a whole program (and decently long), then just time the whole thing, rather than using Criterion. Has anyone run into these issues before, and can anyone offer an opinion on what the best option is? Thanks, Neil.

3 8

Numeric.LinearProgramming - confusion in constructors for bounds
by Ozgur Akgun 31 Mar '10

31 Mar '10

Hi everyone and Alberto, Numeric.LinearProgramming[1] provides a very nice interface for solving LP optimisation problems, and the well-known simplex algorithm itself. I must say I quite liked the interface it provides, simple yet sufficient. But, to my understanding, there is a confusion in the constructor name (symbols actually) for constraints. In LP, one needs to write constraints in the form of ==, <=, or >= only. You *cannot *write a constraint using strict inequalities. The algorithm has nothing wrong, but I guess it would be better to have constructor symbols right. See [2] If this is a design choice, I think it should explicitly be stated. Regards, [1] http://hackage.haskell.org/package/hmatrix-glpk [2] http://hackage.haskell.org/packages/archive/hmatrix-glpk/0.1.0/doc/html/Num… -- Ozgur Akgun

2 2

ANN: Hakyll-2.0
by Jasper Van der Jeugt 31 Mar '10

31 Mar '10

Hello, On this spring day I would like to announce the 2.0 release of Hakyll[1], the static site generator. It is a rewrite, changes the API for the better and introduces some new features. A brief changelog: - Rewrite of the codebase to a clean, arrow based API. - Pagination was added. - Built-in functions to generate RSS and Atom. - Many bugfixes. - New tutorials added. Of course, all feedback is welcome. Kind regards, Jasper Van der Jeugt [1]: http://jaspervdj.be/hakyll

1 0

Are there any female Haskellers?
by Günther Schmidt 31 Mar '10

31 Mar '10

Hi all, from the names of people on the list it seems that all users here are males. Just out of curiosity are there any female users here, or are we guys only at the moment? Günther

37 57

Re: Data Structures GSoC
by John Lato 31 Mar '10

31 Mar '10

> From: Roman Leshchinskiy <rl(a)cse.unsw.edu.au> > > On 31/03/2010, at 18:14, Achim Schneider wrote: > >> We have a lot of useful interfaces (e.g. ListLike, Edison), but they >> don't seem to enjoy wide-spread popularity. > > Perhaps that's an indication that we need different interfaces? IMO, huge classes which generalise every useful function we can think of just isn't the right approach. We need small interfaces between containers and algorithms. In fact, the situation is perhaps somewhat similar to C++ where by providing exactly that the STL has been able to replace OO-style collection libraries which never really worked all that well. Agreed. There should be a hierarchy with multiple interfaces, e.g. Collection, List, Map, Set, etc. I can't speak for Edison, but ListLike only implements the List, and doesn't provide an appropriate base class. I also agree that the STL (as well as the generic collections in C#/ASP.Net) seem to take the best approach here. That being said, I also agree with Darryn Reid that Data.HashTable could use some work as a higher priority. John

1 0

my gsoc project topic
by Csaba Hruska 31 Mar '10

31 Mar '10

Hi! I'm wondering about the topic of my gsoc project. I'm interested in these areas: - improving cabal (more sophisticated dependency, multi version, compiler support, etc) This could be useful from practical view. - Another idea is to improve GHC's new LLVM backend. (eg: support cross module optimization, integrate with llvm-gcc or clang to support full project link time optimization, even using FFI) I'm really keen on compiler technology, and i know llvm for 3 years. (and i'm familiar with clang too) I also have a perspective to GHC's compile stages and intermediate languages. But I've seen that other people are interested in LLVM backend gsoc project too. - Another LLVM related idea is to create a framework to support writing llvm passes in haskell, this should be based on existing llvm haskell binding. - I'm also interested in computer graphics. While this kind of project could look really good, the community could not benefit from it. eg: *write a pure FRP based 3D game, withs existing haskell libs *improve lambdacube 3D engine, etc IMO the big thing will come in these area when DPH and GPGPU will be stable and supported. What do you think about these? Cheers, Csaba Hruska

7 7

ANN: data-category, restricted categories
by Sjoerd Visscher 31 Mar '10

31 Mar '10

Hi everybody, At ZuriHac I released data-category. It is an implementation of several category-theoretical constructions. I started this library to learn about both category theory and type level programming, so I wanted to implement the CT concepts as directly as possible. This in contrast to the excellent category-extras library, which (I think) also tries to be as useful as possible. CT is about studying categories, so for data-category I wanted to implement all kinds of categories. The Control.Category module unfortunately requires you to implement id :: cat a a (for all a), which means it only supports categories that have exactly the same objects as Hask. So Data.Category contains an implementation of restricted categories, using inspiration from Oleg's restricted monads. It is well known that the Functor class also is a bit limited, as it only supports endofunctors in Hask. But there's another problem, if you want to define the identity functor, or the composition of 2 functors, then you have to use newtype wrappers, which can get in the way. Data.Category has an implementation of functors which solves this by using type families. Functors are represented by labels, and the type family F turns the label into the actual functor. F.e. type instance F List a = [a], type instance F Id a = a. The current version contains: - categories - Void, Unit, Pair (discrete categories with 0, 1 and 2 objects respectively) - Boolean - Omega, the natural numbers as an ordered set (ω) - Monoid - Functor, the category of functors from one category to another - Hask - Kleisli - Alg, the category of F-Algebras - functors - the identity functor - functor composition - the constant functor - the co- and contravariant Hom-functors - the diagonal functor - natural transformations - universal arrows - limits and colimits (as universal arrows from/to the diagonal functor) - using Void as index category this gives initial and terminal objects - f.e. in Alg the arrows from the initial object are catamorphisms - using Pair as index category this gives products and coproducts - f.e. in Omega they are the minimum and maximum and in Boolean and and or. - adjunctions Of course the are still a lot of things missing, especially in the details. And I'm a category theory beginner, so there will probably be some mistakes in there as well. F.e. Edward Kmett doesn't like () being the terminal object in Hask, which I thought I understood, but after thinking about it a bit more I don't. You can find data-category on hackage and on github: http://hackage.haskell.org/package/data-category http://github.com/sjoerdvisscher/data-category greetings, Sjoerd Visscher

10 17

More Language.C work for Google's Summer of Code
by Aaron Tomb 31 Mar '10

31 Mar '10

Hello, I'm wondering whether there's anyone on the list with an interest in doing additional work on the Language.C library for the Summer of Code. There are a few enhancements that I'd be very interested seeing, and I'd love be a mentor for such a project if there's a student interested in working on them. The first is to integrate preprocessing into the library. Currently, the library calls out to GCC to preprocess source files before parsing them. This has some unfortunate consequences, however, because comments and macro information are lost. A number of program analyses could benefit from metadata encoded in comments, because C doesn't have any sort of formal annotation mechanism, but in the current state we have to resort to ugly hacks (at best) to get at the contents of comments. Also, effective diagnostic messages need to be closely tied to original source code. In the presence of pre-processed macros, column number information is unreliable, so it can be difficult to describe to a user exactly what portion of a program a particular analysis refers to. An integrated preprocessor could retain comments and remember information about macros, eliminating both of these problems. The second possible project is to create a nicer interface for traversals over Language.C ASTs. Currently, the symbol table is built to include only information about global declarations and those other declarations currently in scope. Therefore, when performing multiple traversals over an AST, each traversal must re-analyze all global declarations and the entire AST of the function of interest. A better solution might be to build a traversal that creates a single symbol table describing all declarations in a translation unit (including function- and block-scoped variables), for easy reference during further traversals. It may also be valuable to have this traversal produce a slightly-simplified AST in the process. I'm not thinking of anything as radical as the simplifications performed by something like CIL, however. It might simply be enough to transform variable references into a form suitable for easy lookup in a complete symbol table like I've just described. Other simple transformations such as making all implicit casts explicit, or normalizing compound initializers, could also be good. A third possibility, which would probably depend on the integrated preprocessor, would be to create an exact pretty-printer. That is, a pretty-printing function such that pretty . parse is the identity. Currently, parse . pretty should be the identity, but it's not true the other way around. An exact pretty-printer would be very useful in creating rich presentations of C source code --- think LXR on steroids. If you're interested in any combination of these, or anything similar, let me know. The deadline is approaching quickly, but I'd be happy to work together with a student to flesh any of these out into a full proposal. Thanks, Aaron -- Aaron Tomb Galois, Inc. (http://www.galois.com) atomb(a)galois.com Phone: (503) 808-7206 Fax: (503) 350-0833

10 13

How to use unsafePerformIO properly (safely?)
by Ivan Miljenovic 31 Mar '10

31 Mar '10

I use the dreaded unsafePerformIO for a few functions in my graphviz library ( http://hackage.haskell.org/packages/archive/graphviz/2999.8.0.0/doc/html/sr… ). However, a few months ago someone informed me that the documentation for unsafePerformIO had some steps that should be followed whenever it's used: http://www.haskell.org/ghc/docs/latest/html/libraries/base-4.2.0.0/System-I… . Looking through this documentation, I'm unsure on how to deal with the last two bullet points (adding NOINLINE pragmas is easy). The code doesn't combine IO actions, etc. and I don't deal with mutable variables, so do I have to worry about them? -- Ivan Lazar Miljenovic Ivan.Miljenovic(a)gmail.com IvanMiljenovic.wordpress.com

2 1