March 2010 - Haskell-Cafe

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

Release: pqueue-1.0.1
by Louis Wasserman 30 Mar '10

30 Mar '10

I've finally released my priority queue package, "pqueue," on Hackage. This is the direct result of my efforts to design a priority queue for containers, but instead, I decided to put together this package and submit it for addition to the Haskell Platform. There's already been a huge discussion about which data structure to use, but I'm definitely sticking with this structure for this major version release. I'm not entirely sure of the process to submit to HP, so if there's something in particular I should do, tell me plz. The hackage link is http://hackage.haskell.org/package/pqueue, the darcs repo is http://code.haskell.org/containers-pqueue/ Louis Wasserman wasserman.louis(a)gmail.com http://profiles.google.com/wasserman.louis

2 1

GSOC Idea: Simple audio interface
by Edward Amsden 30 Mar '10

30 Mar '10

I would like to write an audio interface for haskell for GSoC. The idea is to have a simple frontend (possibly an analog to the IO 'interact' function) that would permit writing simple functions to process audio. The interface would permit easy usage of various audio APIs on various platforms to permit the writing of portable audio programs in Haskell. Initial ideas include interfaces to PortAudio, Jack, ALSA, CoreAudio, and/or SDL. The goal is to lower the barrier to writing audio functions in Haskell and to permit quick experimentation with audio generating or processing functions. I'd love to hear feedback on this idea and to know of anyone would be interested in mentoring.

1 0

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