September 2010 - Haskell-Cafe

Proposal: Form a haskell.org committee
by Ian Lynagh 07 Sep '10

07 Sep '10

Dear Haskellers, In recent years, haskell.org has started to receive assets, e.g. money from Google Summer Of Code, donations for Hackathons, and a Sparc machine for use in GHC development. We have also started spending this money: on the community server, on a server to take over hosting haskell.org itself, and on the haskell.org domain name. There is also interest in running fundraising drives for specific things such as Hackathon sponsorship and hosting fees. However, it is not currently clear who is responsible for determining what the haskell.org money should be spent on, or what are and are not acceptable uses of the domain name and hardware. To fix this problem, we propose that we create a "haskell.org committee", which is responsible for answering these sorts of questions, although for some questions they may choose to poll the community at large if they think appropriate. We suggest that the committee be composed of 5 representatives from the community, with committee members standing down after at most 3 years. Each year the committee will appoint one of their members to be the chair. As membership of "the Haskell community" is not well-defined, and voting would potentially be open to abuse if anyone were able to vote, we propose that the committee should choose their replacements from open nominations. Unfortunately, this gives us a bootstrapping problem, so we suggest that the initial committee be chosen from open nominations by some of the people who currently de-facto end up making the decisions currently: Duncan Coutts, Isaac Jones, Ian Lynagh, Don Stewart and Malcolm Wallace. These 5 would still be elligible to nominate themselves. Two of the initial members will stand down after one year, and two after two years, in order to bootstrap rolling membership turnover. We would love to hear feedback from you about this proposal, so that we can see whether the proposal, or something similar, has consensus amongst the community! A related issue is that haskell.org does not currently exist as a legal entity. We also hope to solve that problem, but we are still gathering information so that the community can make an informed decision, so I won't say more about that for now. Thanks Ian

7 6

Re: [Haskell-cafe] Restricted type classes
by John Lato 07 Sep '10

07 Sep '10

> > > Message: 20 > Date: Sat, 04 Sep 2010 03:40:49 -0400 > From: wren ng thornton <wren(a)freegeek.org> > Subject: Re: [Haskell-cafe] Restricted type classes > To: Haskell Cafe <haskell-cafe(a)haskell.org> > Message-ID: <4C81F801.606(a)freegeek.org> > Content-Type: text/plain; charset=UTF-8; format=flowed > > On 9/3/10 12:16 AM, Ivan Lazar Miljenovic wrote: > > 2) How far should I go? Should I restrict myself to the > > "data-oriented" classes such as Functor, Traversable, etc. or should I > > try to make restricted versions of Applicative and Monad? Assuming I > > should: > > I'd say you should do as much as seems reasonable. I tend to take things > as far as I can, but that'd end up doing a lot of the same work as > category-extras. For a general collections library, I think it'd make > sense to try to keep things simpler than that if possible. The simpler > it is, the better the uptake will be, so long as it's still complex > enough to capture what it needs to. > > I'd say you should include: Functor, Foldable, Traversable, Pointed, > Applicative, Monad, and Monoid (both additive and multiplicative in > separate classes, as in the monoids package). Those eight make for a > really comprehensive toolkit that does most of the things people > frequently need. Of course, not every collection will have instances for > all of them. > Although I agree these do most things that people need, it's very rare that I need a data structure that guarantees *only* these features. Most often I need a map, a queue, etc. because I need either lookup by key, queue properties, etc. I think it's necessary to include classes like Indexable and Queue. Indexable may need to be split into two, one for ordered-Int indexes (i.e. lists) and one for Maps. Just a few days ago I wanted to change the priority queue implementation in some code. This was painful because the different available implementations all have varying APIs, so I couldn't just change the imports. I've wanted to do this in other contexts as well (e.g. maps and tries). The perhaps more important use is for coding algorithms that depend upon map properties, queue properties, etc., but leaving the actual implementation polymorphic so it can be chosen by a higher level. If the purpose of this project is to present a common interface for containers, then I think you should start by seeing what are the most common containers (I would guess lists, sets, maps, and queues) with a goal of providing their specific functionality through classes. Then all the common stuff can be stripped out and provided by superclasses. Of course we already know a great deal of the common operations, e.g. Traversable and Foldable, and we make use of those abstractions. It's this last step of a common map interface, queue interface, etc. that's missing. If you're just going to provide stuff we already have, I don't really see the point. > > > 2c) Should I keep the classes as-is, or should I explicitly put in the > > constraints mentioned in the Typeclassopedia (e.g. make Applicative an > > explicit superclass of Monad, and define return = pure for > > compatability reasons)? If so, should I bring over Pointed, etc. from > > category-extras to round out the set or just stick with classes that > > are already in base? > > If you're defining a new hierarchy, I'd say you should do it correctly, > i.e. > > class Functor where fmap > class Functor => Pointed where unit -- or point > class Pointed => Applicative where (<*>) ; (<*) ; (*>) > class Applicative => Monad where (>>=) ; join > Shouldn't it be: class Functor where fmap class Pointed where point class (Functor f, Pointed f) => PointedFunctor f where class PointedFunctor f => Applicative f where (<*>); --etc. class Applicative f => Monad f where (>>=); --etc. even I might omit PointedFunctor, though, because it doesn't add anything. If it is omitted, that just means your Applicative contexts are slightly longer. But please don't make Pointed depend on Functor - we've already seen that it won't work for Bloom filters. Cheers, John

5 6

circular imports
by Evan Laforge 07 Sep '10

07 Sep '10

Lately I've been spending more and more time trying to figure out how to resolve circular import problems. I add some new data type and suddenly someone has a new dependency and now the modules are circular. The usual solution is to move the mutually dependent definitions into the same module, but sometimes those threaten to drag in a whole zoo of other dependencies, *all* of which would have to go into the same module, which is already quite large anyway. Of course this requires lots of thought and possibly refactoring and is a big pain all around. I feel like the circular imports problem is worse in haskell than other languages. Maybe because there is a tendency to centralize all state, since you need to define it along with your state monad. But the state monad module must be one of the lower level ones, since all modules that use it must import it. However, the tendency for bits of typed data to migrate into the state means it's easy for it to eventually want to import one of its importers. And the state monad module gets larger and larger (the largest modules in my system are those that define state monads: 1186 lines, 706 lines, 1156 lines---the rest tend to be 100--300 lines). I haven't really had this problem in other languages. Maybe it's because I just don't write very big programs in other languages, or maybe because some other languages are dynamically typed and don't make you import a module to use its types, or maybe because some other languages support forward declaration (actually, ghc haskell does support a form of forward declaration in hs-boot files). I have a few techniques to get out: - Replace Things with ThingIds which have no big dependencies, and can then be looked up in a Map later. This replaces direct access with lookup and thows some extra Maybes in there, which is not very nice. - Cleverly use type variables to try to factor out the problematic type. Then I can stitch the data structure back together at a higher level with a type alias. This is sort of complicated and awkward. - Move the declarations that must be moved to the low level module, re-export them from the module that defines their (smart) constructors, and pretend like they belong to that module. This works well when it can work, but makes the code awkward to navigate and doesn't let you hide their implementation unless you give up and move the rest of the code in as well. - Just use an hs-boot. The main problem I've noticed with this so far is that you wind up with a lot of recompilation, since ghc always seems to want to start with the boot files and then recompile the loop. This makes ghci use a little more annoying. Actually, sometimes :r simply reloads the changed module, but sometimes it wants to start again at the hs-boots and recompiles a whole pile, I'm not sure what makes the difference. Probably making the loop as small as possible would help here. Is this a problem others have noticed? Any other ideas or solutions? thanks!

11 18

random-fu confusion
by Alex Rozenshteyn 07 Sep '10

07 Sep '10

I seem to be having confusion at the runRVar level of random-fu. I can't figure out how to use the Data.Random.Source.PureMT module to get a meaningful random source (I can't get my code to type-check). I wrote a [trivial] flipCoin function > flipCoin = uniform False True and am trying to fill in the final place of runRVar > :t runRVar (replicateM 20 flipCoin) runRVar (replicateM 20 flipCoin) :: (RandomSource m s) => s -> m [Bool] -- Alex R

2 3

Paralelism and Distribution in Haskell
by Ivan S. Freitas 07 Sep '10

07 Sep '10

Hi fellow haskellers, I'm interested in the performance of parallel and/or distributed implementations in haskell language. For example, supose I want to develop an application that distributes a computation between many multicore computers, what are the advantages I can take from haskell in that? Anyone who has experience doing distributed computing with haskell, and could point some diferences between haskell and other languages? Any feedback is very much apreciated. Thanks. Regards. -- ============================================== Ivan Sichmann Freitas Engenharia de Computação 2009 UNICAMP http://identi.ca/ivansichmann Grupo Pró Software Livre UNICAMP - GPSL ==============================================

8 15

local-search
by R Senington 07 Sep '10

07 Sep '10

I was recently at IFL2010, where I gave a short presentation on my the attempts to put together a local search library for Haskell. This was reasonably well received, and I had a couple of requests for a library. After a couple of days sanitizing the code, and learning a bit about how to package libraries for Hackage I am now announcing that the library has been uploaded, version 0.0.1. Of course I managed to make an error in the summary so it start "AA first...." rather than just "A first". I hope that people find this interesting and I look forward to feedback. http://hackage.haskell.org/package/local-search RS

1 0

Fwd: Searching for Haskell (was: [Haskell-cafe] Slightly humorous: Headhunters toolbox (example for Germany))
by Alberto G. Corona 07 Sep '10

07 Sep '10

Ooops Just after sending this I relized that it is possible to narrow the search using categories. Using the category programming: http://www.google.com/insights/search/?hl=en-US#&cat=31&q=haskell&cmpt=q <http://www.google.com/insights/search/?hl=en-US#&cat=31&q=haskell&cmpt=q>it is even possible to compare the evolution of the term against the whole category. Both go down with time (because technical people dominate less and less the wen searches) . But the slope of "Haskell" is lesser than the one of "programming". By the way, it is possible to compare two or more search terms. Within the category programming, monad, and "type class" are scarce compared with "object" but the slope of the former ones are clearly up while object is down. (press "growth compared with the programing category"). What happened in the first half of 2006? monads were high there!. An further example is lazy versus strict. Both are comparable in percentage, but lazy is scandalously up while strict is down at the same rate. http://www.google.com/insights/search/?hl=en-US#cat=31&q=lazy%2Cstrict%2C&c… By the way, the term "tired" has increasing share in the programming category ;) 2010/8/31 Henk-Jan van Tuyl <hjgtuyl(a)chello.nl> On Tue, 31 Aug 2010 13:57:42 +0200, Alberto G. Corona <agocorona(a)gmail.com> > wrote: > > Entering "haskell language" instead of "haskell" the ambiguity >> dissapears. Then, Jamaica no longer appears in the crude reality . The >> weigth of USA is hides all other country here. >> >> I think that a more appropriate term to look for haskell interest is >> "monad" although it may catch some crazy philosophers too. The result is >> interesting, >> >> > You can still get things like a page titled "Ben Haskell - Language > Technologies Institute - Carnegie Mellon", and of course, not all pages > about the programming language contain the word "language". To get proper > results you would need a good semantic search engine, but these search > engines seem to be in early research stage. > > Regards, > Henk-Jan van Tuyl > > > -- > http://Van.Tuyl.eu/ > http://members.chello.nl/hjgtuyl/tourdemonad.html > -- >

2 1

ghc HEAD
by Johannes Waldmann 07 Sep '10

07 Sep '10

I was compiling ghc-6.13.20100831 from source (*) and then compiling repa-examples with that, and the generated executable says (when called with +RTS -N2): Most RTS options are disabled. Link with -rtsopts to enable them. Where? How? When? (Did I make some error earlier?) (*) that's the latest available src snapshot? (Sadly, it does not contain containers-0.4) How come there are binaries without sources at: http://www.haskell.org/ghc/dist/current/dist/ While "cabal install repa-examples" works nicely, it is still way too easy to break the system, since cabal install will happily (and silently) destroy ghc's libraries. (e.g. happens for me after installing syb) unfortunately, this means I cannot easily test ghc HEAD and/or containers-0.4 on my sources. J.W.

2 1

generating foreign Code (Java, C++, PHP)?
by Günther Schmidt 07 Sep '10

07 Sep '10

Hi list, I noticed that there are some libs / packages like atom and HJscript which allow you to write a program in a haskell EDSL and that then actually generates valid source code in another language. In the above example that would be JavaScript and C. I sure would love to be able to write PHP for instance like that but I cannot even fathom how a EDSL would have to be designed for it. Could someone here point me to literature on the topic? Günther

3 2

Re: [Haskell-cafe] Re: Fwd: Semantics of iteratees, enumerators, enumeratees?
by John Lato 07 Sep '10

07 Sep '10

At first I regarded this as simply a bug in the Iteratee.map definition, but like Ben, it's started to bother me a lot. I think this is precisely the sort of issue a proper denotational semantics would fix. Unfortunately the only general solution I see is to abandon chunking and work strictly element-wise. I say unfortunately because my current best implementation is about 5 times slower than the main tree. I'm open to ideas. John > From: Ben <midfield(a)gmail.com> > > Sorry to be late coming into this conversation..... > > Something that has bothered me (which I have mentioned to John Lato > privately) is that it is very easy to write non-compositional code due > to the chunking. For example, there is a standard function > > map :: (a -> b) -> Enumeratee a b c > > whose meaning I hope is clear : use the function to transform the type > of a stream and pass it to an iteratee. However last I checked the > versions provided in both the iteratee and enumerator packages fail to > satisfy the equation > > map f (it1 >> it2) == (map f it1) >> (map f it 2) > > because of chunking, essentially. You can check this with f == id and > it1 and it2 are head: > > let r = runIdentity . runIteratee > > runIdentity $ run $ enumList 10 [1..100] $ r $ joinI $ map id $ r (head >> > head) > --> Right (Just 2) > > runIdentity $ run $ enumList 10 [1..100] $ r $ joinI $ (map id $ r > head) >> (map id $ r head) > --> Right (Just 11) > > It is possible to fix this behavior, but it complicates the "obvious" > definitions a lot. > > B > > On Wed, Sep 1, 2010 at 5:10 AM, Heinrich Apfelmus > <apfelmus(a)quantentunnel.de> wrote: > > Tilo Wiklund wrote: > >> > >> Daniel Fischer wrote: > >>> > >>> [...] > >>> Well, I just gave an example where one would want chunking for reasons > >>> other than performance. That iteratees don't provide the desired > >>> functionality is a different matter. > >>> [...] > >> > >> In the case of hashing, wouldn't it be more reasonable to consider > >> iterators over streams of fixed (or at least predictable) sized chunks > >> (where a set of chunks can themselves be chunked), with the chunking > >> behaviour being given by another iteratee over the original stream? > >> > >> It seems to me that one of the major points of iteratees is to provide > >> an abstraction from the kind of chunking irrelevant to the parsing > >> logic, otherwise I fail to see any difference (at least relevant to > >> chunking) to plain strict IO. > > > > I thought so, too, but I was informed[1] that iteratees are just a small > > step up the abstraction ladder. The difference compared to an ordinary > file > > Handle is that you can now reuse one and the same iteratee for reading > > from a String , for instance, without changing the source code of the > > iteratee. > > > > Furthermore, iteratees can be suspended, which facilities resource > > management like closing files handles after they've been read. > > > > [1]: > > > http://www.reddit.com/r/haskell/comments/ar4wb/understanding_iteratees/c0j0… > > > > > > > > Regards, > > Heinrich Apfelmus > > > > -- > > http://apfelmus.nfshost.com > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe(a)haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > >

1 0