November 2009 - Haskell-Cafe

Fwd: [BostonHaskell] Next meeting: November 24th at MIT (32-G882)
by Ravi Nanavati 20 Nov '09

20 Nov '09

---------- Forwarded message ---------- From: Ravi Nanavati <ravi_n(a)alum.mit.edu> Date: Fri, Nov 20, 2009 at 4:00 PM Subject: Next meeting: November 24th at MIT (32-G882) To: bostonhaskell(a)googlegroups.com I'm pleased to announce the November meeting of the Boston Area Haskell Users' Group. Based on the available days remaining in November, the meeting has been scheduled for Tuesday, November 24th from 6:30pm to 8:30pm. Like recent meetings, it will be held in the MIT CSAIL Reading Room (32-G882, i.e. a room on the 8th floor of the Gates Tower of the MIT's Stata Center at 32 Vassar St in Cambridge, MA). Based on the response to my previous message, I'm developing a QuickCheck-focused joint programming exercise. If anyone wants to help with that, I'd appreciate it (since I'm trying to pull this together at the last minute). My plan is to introduce QuickCheck and start with a couple of warm-up exercises before our traditional break. After the break I'd like to use QuickCheck to find a subtle bug or two in some interesting, nontrivial (but not too large or complicated) Haskell program. I've found some introductory material to use as a starting point, but I don't have the right sort of Haskell program handy. If anyone has an interesting Haskell program they can share that is a good fit for this exercise, please let me know (the sooner the better). Since the meeting is going to be focused on a programming exercise, I don't think we'll have room for any larger presentations (at least based on our experience at the September meeting), but I'm there will be room for lightning talks or other advertisements if anyone has an interest in doing that. The November attendance poll is at: http://doodle.com/hyv5a76ib6untwtp As always, responding to this poll will help with two things: 1. Getting an idea of what fraction of the Boston-area Haskell community can and can't attend this meeting (to help with future scheduling). 2. Giving me an estimated count of attendees, since I have talked my wife into baking some more goodies and bringing drinks again. Helping with BostonHaskell (besides volunteering to speak at future meetings): 1. Sponsorship of refreshments is still being eagerly solicited (especially as, for personal reasons, the Cupcake Fund is running low). 2. Please let me know if you're willing to arrive early (6pm) to stand by the door and let people into the 8th floor. I'm guessing 1 or 2 volunteers is enough here. 3. If someone is willing to edit the HaskellWiki page, post to reddit or otherwise publicize the meeting please just go ahead and do that (especially as I'm sending this out a bit later than intended). If you have any questions about the meeting please send them to them BostonHaskell mailing list: bostonhaskell(a)googlegroups.com or contact me directly. I look forward to seeing many Boston-area Haskellers at the November meeting! Thank you, - Ravi Nanavati

1 0

Applicative Functor or Idiom?
by David Sankel 20 Nov '09

20 Nov '09

After reading several recent papers I came to the understanding that there isn't consensus on the name of Applicative Functors. Several prefer to call them idioms: "'Idiom' was the name McBride originally chose, but he and Paterson now favour the less evocative term `applicative functor'. We have a slight preference for the former, not least because it lends itself nicely to adjectival uses, as in `idiomatic traversal'"[1] I also noticed use of the term Idiom in [2], [3], and [4]. I'm writing a set of classes that includes AF's and I'm trying to decide whether to call the class Idiom. Anyone have more information on this question? David [1] Gibbons, J. and Oliveira, B. c. 2009. The essence of the iterator pattern. J. Funct. Program. 19, 3-4 (Jul. 2009), 377-402. DOI= http://dx.doi.org/10.1017/S0956796809007291 [2] RALF HINZE (2009). The Bird Tree. Journal of Functional Programming, 19 , pp 491-508 doi:10.1017/S0956796809990116 [3] S. Lindley, P. Wadler, and J. Yallop. Idioms are oblivious, arrows are meticulous, monads are promiscuous. In Proc. of MSFP, 2008. [4] The Arrow Calculus, Sam Lindley, Philip Wadler, and Jeremy Yallop. Tech report, 2008. -- David Sankel Sankel Software www.sankelsoftware.com

2 2

ANNOUNCE: gnome-keyring 0.1 (bindings to libgnome-keyring)
by John Millikin 20 Nov '09

20 Nov '09

The GNOME Keyring is a service for securely storing per-user secret information, such as passwords and encryption keys, on the GNOME desktop. This library is a binding to the libgnome-keyring C library. The API is still a bit too slave-ish to the original for my taste, some modules will be changing/merging in the next version. The innards are an absolute horror -- don't look too close if you're one of those people who faint at rampant unsafe casting. That said, it works surprisingly well for a first-release FFI binding -- mostly due to the excellent design of libgnome-keyring and c2hs. So if any Linux/BSD/OpenSolaris/etc users have needed secure password storage in Haskell, please try it out and let me know if you encounter any problems. Download: http://hackage.haskell.org/package/gnome-keyring/ API docs (copy of original library docs): https://dl.dropbox.com/u/1947532/gnome-keyring_0.1/index.html

3 4

Iteratee question
by Valery V. Vorotyntsev 20 Nov '09

20 Nov '09

I am writing a binary data parser and use `iteratee' package. The following pattern appears quite often in my code: > results <- map someConversion `liftM` replicateM nbytes Iter.head The meaning is: take `nbytes' from stream, apply `someConversion' to every byte and return the list of `results'. But there's more than one way to do it[1]: > i1, i2, i3 :: Monad m => Int -> IterateeG [] Word8 m [String] > i1 n = map conv `liftM` replicateM n Iter.head > i2 n = map conv `liftM` joinI (Iter.take n stream2list) > i3 n = joinI $ Iter.take n $ joinI $ mapStream conv stream2list [1] http://en.wikipedia.org/wiki/There's_more_than_one_way_to_do_it If you try the program[2] I've hpasted, you will see that these three iteratees have equal results. [2] http://hpaste.org/fastcgi/hpaste.fcgi/view?id=12464#a12464 Of those i1, i2, i3 which one is "better" and why? Or is there another - preferable - way of applying iteratees to this task? My naïve guess is that i1 will have worse performance with big n's. It looks like `i1' is reading bytes one by one, while `i2' takes whole chunks of data... I'm not sure though. I would appreciate it a lot if you improve my understanding. -- vvv

1 0

ANN: bindings-SDL 1.0.2, the domain specific language for FFI description
by Maurício CA 20 Nov '09

20 Nov '09

Hi, This package is to be used with hsc2hs. (hsc2hs is called automatically if you use Cabal.) It's a self-contained set of macros used to create a Haskell wrap for a C interface. They follow the idea that it's better to have a C-like wrap code first and then write Haskell-like code on top of that than going directly from C to Haskell style. Hackage link: http://hackage.haskell.org/package/bindings-DSL Wiki documentation: http://bitbucket.org/mauricio/bindings-dsl The fancy 'domain specific language' comes from 'binding-SDL' macros hability to describe a C interface. Instead of writing Haskell or preprocessor code, you can use 'bindings-DSL' macros to describe the interface you want to wrap without knowledge of how that description translates to preprocessor or Haskell code. Suppose, for instance, you have the following C struct: struct example_struct{ int n; struct example_struct *p; } It will be described like this: #starttype struct example_struct #field n , CInt #field p , Ptr <example_struct> #stoptype and this gives you a Haskell data type (automatically named C'example_struct) with the same fields and Storable instantiation. Here is a bigger example, with structs, macros, functions and global variables. Suppose you want to wrap this: http://git.savannah.gnu.org/cgit/gsl.git/tree/multimin/gsl_multimin.h Then this is how your 'bindings-DSL' code will look like: http://bitbucket.org/mauricio/bindings-gsl/src/tip/src/Bindings/Gsl/Multidi… That code translates to these Haskell declarations: http://hackage.haskell.org/packages/archive/bindings-gsl/0.1.1.6/doc/html/B… 'bindings-DSL' came from previous 'bindings-common' package. It started as an effort to have many Haskell interfaces to good libraries available on Hackage, and came to be a language to support writing such interfaces easily and reliably. Hope it's usefull to you. Best, Maurício

2 5

ANNOUNCE: Haskell Communities and Activities Report (17th ed., November 2009)
by Janis Voigtländer 20 Nov '09

20 Nov '09

On behalf of the many, many contributors, I am pleased to announce that the Haskell Communities and Activities Report (17th edition, November 2009) http://www.haskell.org/communities/ is now available from the Haskell Communities home page in PDF and HTML formats. Many thanks go to all the people that contributed to this report, both directly, by sending in descriptions, and indirectly, by doing all the interesting things that are reported. I hope you will find it as interesting a read as I did. If you have not encountered the Haskell Communities and Activities Reports before, you may like to know that the first of these reports was published in November 2001. Their goal is to improve the communication between the increasingly diverse groups, projects, and individuals working on, with, or inspired by Haskell. The idea behind these reports is simple: Every six months, a call goes out to all of you enjoying Haskell to contribute brief summaries of your own area of work. Many of you respond (eagerly, unprompted, and sometimes in time for the actual deadline ;-) to the call. The editor collects all the contributions into a single report and feeds that back to the community. When I try for the next update, six months from now, you might want to report on your own work, project, research area or group as well. So, please put the following into your diaries now: ---------------------------------------- End of April 2010: target deadline for contributions to the May 2010 edition of the HC&A Report ---------------------------------------- Unfortunately, many Haskellers working on interesting projects are so busy with their work that they seem to have lost the time to follow the Haskell related mailing lists and newsgroups, and have trouble even finding time to report on their work. If you are a member, user or friend of a project so burdened, please find someone willing to make time to report and ask them to "register" with the editor for a simple e-mail reminder in October (you could point me to them as well, and I can then politely ask if they want to contribute, but it might work better if you do the initial asking). Of course, they will still have to find the ten to fifteen minutes to draw up their report, but maybe we can increase our coverage of all that is going on in the community. Feel free to circulate this announcement further in order to reach people who might otherwise not see it. Enjoy! Janis Voigtlaender <hcar at haskell.org> -- Jun.-Prof. Dr. Janis Voigtländer http://www.iai.uni-bonn.de/~jv/ mailto:jv@iai.uni-bonn.de

1 0

Fwd: [Haskell-cafe] ANNOUNCE: feldspar-language
by Tom Hawkins 20 Nov '09

20 Nov '09

---------- Forwarded message ---------- From: Tom Hawkins <tomahawkins(a)gmail.com> Date: Thu, Nov 19, 2009 at 9:31 PM Subject: Re: [Haskell-cafe] ANNOUNCE: feldspar-language To: Emil Axelsson <emax(a)chalmers.se> On Thu, Nov 19, 2009 at 5:58 PM, Emil Axelsson <emax(a)chalmers.se> wrote: > Hi Tom, thanks for the code! > > Is my understanding correct that `filter` in the C code performs evaluation > of one cycle, and someone else will take care of calling it repeatedly on > the input stream? This is correct. In our application there is no buffered steam. Instead this code is processing data immediately after it is sampled by the ADCs; in our case once every 1ms. > > Is there a way to avoid rolling out the summation loops fully? Yes, but only by creating a custom primitive (see 'action'). But then you're writing in C, not Atom.

2 2

community.haskell.org is down
by Neil Mitchell 19 Nov '09

19 Nov '09

Hi, community.haskell.org isn't responding, I get connection failures. Thanks, Neil

2 1

prologue junk on ppc (debian)
by Brian Denheyer 19 Nov '09

19 Nov '09

Got the following: Building uvector-0.1.0.5... [ 1 of 13] Compiling Data.Array.Vector.Prim.Text ( Data/Array/Vector/Prim/Text.hs, dist/build/Data/Array/Vector/Prim/Text.o ) Prologue junk?: .type sD7_entry, @function sD7_entry: # 25 "/tmp/ghc14266_0/ghc14266_0.hc" 1 That seems bad... The Glorious Glasgow Haskell Compilation System, version 6.10.4 This is the deb ghc6 package for unstable. Cabal was installed using ghc 6.8.x. I tried re-installing a couple of other cabal packages, including hps and bytestring, and they went through without a hitch. Brian

1 0

Literate refactoring?
by Jacques Carette 19 Nov '09

19 Nov '09

I'd like to ask the cafe's advice on how to 'do this right'. The situation is that we've got 2 literate Haskell programs which we would like to refactor. In fact, this refactoring will ultimately unify these 2 separate programs into a single framework. Every refactoring step is well-defined and induces a discrete modification. These programs also come with tests of their own, which we would like to refactor along with the code. In the end, we would like to obtain: 1. For each discrete step, full working programs, with tests and literate comments 2. A technical report which describes all the steps from #1 above, as a literate Haskell document. For the TechReport, we don't need to be able to extract working code from it, but the code which is in it should be chunks of the working programs, not 'independent'. Especially as some of the 'discrete steps' will result in dead ends, which we want to document, but not otherwise pursue. In other words, the set of "discrete programs" do not form a total linear order, but is more like a linear order with a few short branches hanging off of it. We were thinking that using some combination of scripts, 'patches', features from subversion and literate Haskell documents should allow us to do this. In an ideal world, it would be nice if what we stored was only (generalized) patches, and we could generate #1 and #2 above from that. [These patches would be generalized because they would contain descriptions of what the patch is about, as well as actual patches; though perhaps that description is really just a patch to the TechReport, we're not sure]. We were able to envision a number of different partial solutions, but somehow none of them 'came together' well enough to feel satisfactory. Instead of biasing the cafe's thinking by laying those pieces out, I figured I would lay out the high-level requirements, and let creative solutions come in. Jacques

1 0