August 2010 - Haskell-Cafe

ANNOUNCE: hierarchical-clustering and gsc-weighting
by Felipe Lessa 04 Aug '10

04 Aug '10

Hello! I'm pleased to announce the release of two new packages: http://hackage.haskell.org/package/hierarchical-clustering http://hackage.haskell.org/package/gsc-weighting 'hierarchical-clustering' provides a function to create a dendrogram from a list of items and a distance function between them. The most common linkage types are available: single linkage, complete linkage and UPGMA. An item can be anything, for example a DNA sequence, so this may used to create a phylogenetic tree. Or it may be used with the 'gsc-weighting' package to assign weights to the items. Weights are assigned such that close items get smaller weight than distance items, meaning that the weights try to avoid the over-representation of some closely related items. The package name come from the authors of the algorithm, Gerstein, Sonnhammer and Chothia. Again, this may be used for DNA or protein sequences. Cheers! -- Felipe.

2 3

Maybe to Either -- is there a better way?
by Tom Davies 04 Aug '10

04 Aug '10

I find it convenient sometimes to convert a Maybe value to an Either thus (excuse the syntax, it's CAL, not Haskell): maybeToEither :: a -> Maybe b -> Either a b; maybeToEither errorValue = maybe (Left errorValue) (\x -> Right x); but that seemingly obvious function isn't in Hoogle, AFAICT, so perhaps there's some other approach? Thanks, Tom

9 11

Re: Laziness question
by Janis Voigtländer 04 Aug '10

04 Aug '10

Hi, I am late to reply in this thread, but as I see Stefan has already made what (also from my view) are the main points: - Putting seq in a type class makes type signatures more verbose, which one may consider okay or not. In the past (and, as it seems, again in every iteration of the language development process since then) the majority of the language design decision makers have considered this verbosity non-okay enough, so that they decided to have a fully polymorhpic seq. - Even if putting seq in a type class, problems with parametricity do not simply vanish. The question is what instances there will be for that class. (For example, if there is not instance at all, then no seq-related problems of *any* nature can exist...) - The Haskell 1.3 "solution" was to, among others, have a class instance for functions. As we show in the paper Stefan mentioned, that is not a solution. Some statements claimed by parametricity will then still be wrong due to seq. - If there is no class instance for function types, then those problems go away, of course. But it is doubtful whether that would be a viable solution. Quite a few programs would be rejected as a consequence. (Say, you want to use the strict version of foldl. That will lead to a type class constraint on one of the type variables. Now suppose you actually want to fold in a higher-order fashion, like when expressing efficient reverse via foldr. That would not anymore be possible for the strict version of foldl, as it would require the type-class-constrained variable to be instantiated with a function type.) Two more specific answers to Nicolas' comments: > Actually my point is that if we do not use any polymorphic primitive to > implement a family of seq functions then it cannot be flawed. Indeed > if you read type classes as a way to implicitly pass and pick > functions > then it cannot add troubles. Completely correct. But the point is that without using any polymorphic primitive you won't be able to implement a member of that family for the case of function types (which you do not consider a big restriction, but others do). > However I absolutely do not buy their argument using as example a function > f :: Eval (a -> Int) => (a -> Int) -> (a -> Int) -> Int. They consider as > an issue the fact that the type does not tell us on which argument seq is > used. I think it is fine we may want a more precise type for it to get more > properties out of it but it is not flawed. > As much as we don't know where (==) is used given a function of type > ∀ a. Eq a => [a] -> [a]. I fear you do not buy our argument since you did not fully understand what our argument is, which in all probability is our fault in not explaining it enough. The point is not that we dislike per se that one doesn't know from the type signature how/where exactly methods from a type class are used. In your example ∀ a. Eq a => [a] -> [a] it's alright that we don't know more about where (==) is used. But for a function of type f :: Eval (a -> Int) => (a -> Int) -> (a -> Int) -> Int, in connection with trying to find out whether uses of seq are harmful or not, it is absolutely *essential* to know on which of the two functions (a -> Int) seq is used. The type class approach cannot tell that. Hence, a type class approach is unsuitable for trying to prevent seq from doing parametricity-damage while still allowing to write all the Haskell programs one could before (including ones that use seq on functions). That is the flaw of the type class approach to controlling seq. It is of course no flaw of using type classes in Haskell for other things, and we certainly did not meant to imply such a thing. Best regards, Janis. -- Jun.-Prof. Dr. Janis Voigtländer http://www.iai.uni-bonn.de/~jv/ mailto:jv@iai.uni-bonn.de

4 21

Software architecture
by Charles-Pierre Astolfi 04 Aug '10

04 Aug '10

Hey there, I'm searching for software designs in Haskell ; for example, I have a pretty good ideo of how I would arrange my modules/classes (in ocaml/(java/c++)) and how they would all fit together to create, say, a website aspirator. But I don't have any clue of the right way to do it with Haskell. I don't need a solution for this example, I'd just like to see how to manage non-trivial code. I haven't found any pointers on the interwebs. On an unrelated note, what is the simplest way to get the llvm bitcode? I understand I can compile myself ghc but it there an easier way? Thanks a lot! -- Cp

4 4

Re: [Haskell-cafe] Preview the new haddock look and take a short survey
by Ben 04 Aug '10

04 Aug '10

Great work! I'm sure you're already aware of http://sphinx.pocoo.org/ which is used to generate the Python docs. A lot of good ideas there. One thing which would be great would be to integrate their javascript in-browser text search engine. Obviously not a priority but it might be nice. Best, B > Message: 14 > Date: Wed, 4 Aug 2010 15:56:58 +0100 > From: Thomas Schilling <nominolo(a)googlemail.com> > Subject: Re: [Haskell-cafe] Preview the new haddock look and take a > short survey > To: aditya siram <aditya.siram(a)gmail.com> > Cc: haddock <haddock(a)projects.haskell.org>, haskell-cafe(a)haskell.org > Message-ID: > <AANLkTincL6oUsUJ6hFdi+3-UaO2bqmrX-p8dvRzYME2-(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > On 4 August 2010 15:44, aditya siram <aditya.siram(a)gmail.com> wrote: >> I really like the color scheme and the Javadoc looking frames. >> >> One suggestion I can make is to have the index show all the functions with >> type signatures without having to pick a letter. A lot of times I'll be >> looking for a function of a certain signature as opposed to a name. Indeed >> an index of type signatures would great! I remember wishing I had this when >> trying the understand the Parsec package. >> >> -deech > > Wouldn't hoogle be better for this kind of use case? The index can > become very large already. > > More direct hoogle/hayoo integration (at least on Hackage) sounds like > a worthwhile goal, though. Noted. > >> >> On Wed, Aug 4, 2010 at 8:55 AM, Yitzchak Gale <gale(a)sefer.org> wrote: >>> >>> Mark Lentczner wrote: >>> > The Haddock team... >>> > Please take a look, and then give us your feedback >>> >>> Very very nice. I took the survey, but here are some comments >>> I left out. >>> >>> I like the idea of the Snappy style the best, but there are two >>> serious problems with it, at least in my browser (Safari): >>> >>> 1. The black on dark blue of the "Snap Packages" title makes it >>> nearly unreadable for me. >>> 2. The wide fonts stretch things out so far on my screen that the >>> page becomes almost unusable. >>> >>> The other styles are fine, I would use them instead. >>> >>> Here is a comment I'll repeat from the survey because of its >>> importance: Please add a "collapse all" button for the tree on >>> the contents page. For me, that is perhaps the most urgent >>> thing missing in all of Haddock. It would make that tree so >>> much more usable. >>> >>> Thanks for the great work, >>> Yitz >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe(a)haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe(a)haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > > > > -- > If it looks like a duck, and quacks like a duck, we have at least to > consider the possibility that we have a small aquatic bird of the > family Anatidae on our hands. >

1 0

Arrays and image processing
by kirstin penelope rhys 04 Aug '10

04 Aug '10

Hi! I need to do some image processing for an algorithm. It involves two (well, three) different kinds of arrays. The result array I'm happy to leave as a Data.Array for now, since it tends to be bulk updated, and involves Either with tuples of tuples, and it's easy enough to switch to mutable without a significant impact. So far, using a mutable result array hasn't resulted in a significant speed difference, since it's not directly involved in the inner loops. But the static/immutable input arrays, the source images, are more of a present concern, since they are so directly involved with the inner loops, and are expected to be rather large. Right now, the algorithm is stable enough that it's time to move beyond black and white, which were well enough served by UArray and some ugly optimized inner functions which look rather like C loops, sigh. But now I need a fast multidimensional array which can handle a tuple of primitive types. My options, as far an I can see, are: 1) Add an instance for UArray (Int,Int) (Word16, Word16, Word16) and/or UArray (Int,Int) (Word8, Word8, Word8) 2) Add a multidimensional wrapper for Data.Vector 3) Use Data.Array.Repa. While in the currently released form, as opposed to the paper, it sadly lacks support for pairs, it's not too hard to coerce it into accepting :*:. Though, that seems to involve, for color in this case, three separate lookups. As a note, Repa is really quite lovely, but in my case/opinion, not quite there yet. I need folds/maps from one type to another unfortunately. On the one hand, I might be able to rewrite the statistical functions in a numerically stable integral and repa friendly form with a bit of thought. Though, that sort of feels like I'm programming in APL instead of Haskell, it shouldn't be so headache inducing. On the other hand, I don't really need parallelism, as my development laptop only has one cpu. Though the algorithm is eventually going to be translated to C and OpenCL for use on an embedded device. Still, this now involves even more delving into DPH. 4) Use DPH directly. While I don't really need data parallelism--for the development at least--this seems like the most accommodating option for my needs. But I worry about the stability and correctness. I really like the automatic loop fusion that Repa provides. It really goes a long way toward making the code simple and nice. I'm tempted to just start recoding the algorithm in C. It has to be done eventually, and it's kind of annoying that something which is trivial in C is such a headache here... Thanks for any help/pointers. Cheers, kirstin -- The end move in politics is always to pick up a gun. -- Buckminster Fuller

2 1

Re: [Haskell-cafe] can Haskell do everyting as we want?
by Ivan Lazar Miljenovic 04 Aug '10

04 Aug '10

Marc Weber <marco-oweber(a)gmx.de> writes: > Excerpts from Ivan Lazar Miljenovic's message of Wed Aug 04 12:37:29 +0200 2010: >> functionality in Emacs. > > I know - I patched the py backend for scion. I'm talking about: > > node.getParent().getParent().<tab>Attributes["value"] > > Or (let's talk about a haskell example): > > pkgVersion $ package $ packageDescription > > It feels unnatural to complete this. How should this be done? > I know that you can define your own .dot. operator, so that you can > write it in (let's call it Java style): > > packageDescription .dot. package .dot. pkgVersion I don't get the point of this ".dot." operator (which isn't even a valid operator). > Without completion I have to get the type of packageDescription, then > follow the structure until I find Version. Using tags and Vim that's > fast. Still completion is a lot faster. Not really following your example here: you want something to write your code for you and read your mind to know what that code should be? My understanding of tab-completion in IDEs for Java, etc. is that it just displayed every single possible class method for a particular object value, and then did some kind of matching based upon what you typed to narrow down the list, not that it was type-based. > I'm not talking about the universal "put everything in scope" completion > thing - eg which Vim provides for some languages. I'm talking about > really helpful context sensitive completion. I know its pretty hard to > get this hard for Haskell - because type is determined by things you > use. But the example I gave above is one which could be implemented > easily. How is it easy? How would this mythical completer know which function to use? -- Ivan Lazar Miljenovic Ivan.Miljenovic(a)gmail.com IvanMiljenovic.wordpress.com

3 6

design question: decision tree from "Programming Collective Intelligence"
by Daniel Lyons 04 Aug '10

04 Aug '10

Hi, I'm having a little trouble figuring out precisely how to port the decision tree code from the book "Programming Collective Intelligence." You can see the code here: http://code.google.com/p/memothing/source/browse/trunk/PCI/ch7/treepredict.… The design issue is that this code depends on dynamic typing pretty heavily. He has a table of heterogenous data. Each column has the same type, but that's implicit, not explicit. He depends on all of the values supporting "==", which he uses to get a list of distinct values from each column. These values are used by the divide set function which takes a column and a value as parameters. Based on the type of the value, he chooses a different partitioning function; for strings, it's just equality again, but for numeric types he uses >=. The decision tree nodes then collect not just the left and right branches but also the column number and value on which the split was performed. I have thought about this for several days and can't seem to come to a design that I like, so I'm wondering how others would approach the problem. I guess you could implement it as a list of lists of some data type that is either a string or numeric, but this feels a bit like a cop-out. How would you support creating a decision tree with different types of data? I imagine possibilities using existential quantification, SYB, Data.Data and other stuff, but I don't know how to make it work. I wonder if there is an obvious functional design hiding in here that doesn't depend on any fancy stuff, but I'm blinded to it by having read and understood the Python version of the code. Anybody have any suggestions? I'd greatly appreciate any help. Thanks, — Daniel Lyons

4 3

Re: Type Families: deleting from HList
by oleg＠okmij.org 04 Aug '10

04 Aug '10

Serguey Zefirov wrote: > Is it possible to delete an element from heterogenous list using type > families alone? > > I can do it using multiparameter type classes: > class Del a list result > instance Del a (a,list) list > instance Del a list list' => Del a (a',list) list' > instance Del a () () I'm afraid you'll find that class quite difficult to use: lots of type annotations will be required. For example, if we define del :: Del a li lo => a -> li -> lo del = undefined and write test1 = del True ('a',(True,())) the compiler will complain because it doesn't know which instance to choose. BTW, since GHC checks for overlapping lazily, the fact that GHC accepts a set of instance declarations does not tell that the instances `work'. The problems may lurk, becoming apparent when we define values that attempt to use the instances. In order for something like Del to be useful, functional dependencies are needed. It is easy to see that Del uses overlapping instances. That answers the question: since type families do not support overlapping instances, one cannot re-write Del using type families alone. One may ask is it possible to define some sort of type inequality using type families. And the answer is yes, recently discussed at http://www.haskell.org/pipermail/haskell-cafe/2010-July/080473.html

1 0

Error Monad and strings
by Gerald Gutierrez 03 Aug '10

03 Aug '10

Reading the Control.Monad.Error documentation, I see that the Error class has noMsg and strMsg as its only two functions. Now, I understand that you can define your own Error instances such as in example 1 of the documentation, so why the need to always support strings via noMsg/strMsg ? What uses these? And if in my code, I will never throw an error with a string, am I supposed to implement these functions and then ignore them?

6 7