- Haskell-Cafe - Haskell.org

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 20 Nov '09

20 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

(possibly) a list comprehensions question
by Ozgur Akgun 19 Nov '09

19 Nov '09

Hi Cafe! I am struggling with an interesting problem while defining a function. It looks quite easy to me, but I couldn't manage to have a proper implementation yet. To illustrate what I'm trying to achive, I'll introduce special cases of the desired function, and hopefully build towards a solution step by step. -- simplest case, taking 2 lists as parameters and returning a list of list containing every possible pair (but represented as lists) allPossibilities2 :: [a] -> [a] -> [[a]] allPossibilities2 listX listY = [ [x,y] | x <- listX, y <- listY] -- sample output -- allPossibilities2 [1,2,3] [7,8,9] -- [[1,7],[1,8],[1,9],[2,7],[2,8],[2,9],[3,7],[3,8],[3,9]] -- simplest case with 3 parameters instead of 2 allPossibilities3 :: [a] -> [a] -> [a] -> [[a]] allPossibilities3 listX listY listZ = [ [x,y,z] | x <- listX, y <- listY, z <- listZ] -- allPossibilities3 [1,2] [3,4,5] [6,7] -- [[1,3,6],[1,3,7],[1,4,6],[1,4,7],[1,5,6],[1,5,7],[2,3,6],[2,3,7],[2,4,6],[2,4,7],[2,5,6],[2,5,7]] These are easy and work just fine. All I want to do is to generalize this function receiving n lists as parameters and doing the simple action described above. Since I cannot pass variable number of parameters to a function, I'll use list of lists from now on. Following are the implementations of the same functions with different types (instead of two lists, a list of lists assumed to caontain those 2 elements) allPossibilities2' :: [[a]] -> [[a]] allPossibilities2' list = [ [x,y] | x <- list !! 0, y <- list !! 1] -- allPossibilities2' [[1,2,3],[7,8,9]] -- [[1,7],[1,8],[1,9],[2,7],[2,8],[2,9],[3,7],[3,8],[3,9]] allPossibilities3' :: [[a]] -> [[a]] allPossibilities3' list = [ [x,y,z] | x <- list !! 0, y <- list !! 1, z <- list !! 2] -- allPossibilities3' [[1,2],[3,4,5],[6,7]] -- [[1,3,6],[1,3,7],[1,4,6],[1,4,7],[1,5,6],[1,5,7],[2,3,6],[2,3,7],[2,4,6],[2,4,7],[2,5,6],[2,5,7]] This is ugly! Anyway, just forget the fact that these funstions do not do a check on the length of the input list for a moment. My question is, how can I generalize this function to accept a list of lists of arbitrary length, and produce the required result. I hope I managed to make my point clear enough. Waiting for suggestions. Regards, -- Ozgur Akgun

4 5