- Haskell-Cafe - Haskell.org

Using the ContT monads for early exits of IO ?
by Günther Schmidt 17 Jun '10

17 Jun '10

Hi everyone, I'm about to write a rather lengthy piece of IO code. Depending on the results of some of the IO actions I'd like the computation to stop right there and then. Now I know in general how to write this but I'm wondering if this is one of those occasions where I should make use of the Cont monad to make an early exit. Günther

14 22

Announce: hs2dot 0.1.1 - generate graphviz code by analyzing Haskell source code files
by Oscar Finnsson 16 Jun '10

16 Jun '10

Hi, I've just released hs2dot on hackagedb. It's a small tool that lets you automatically generate graphviz/dot code that visualize the relations between data types, types and type classes. Example usage: > hs2dot Hack.hs | dot -T pdf -o Hack.pdf Multiple files can be analyzed together as in > hs2dot Foo.hs Bar.hs | dot -T png -o FooBar.png so their data types can point to each other. Example diagrams generated using h2dot can be found at http://github.com/finnsson/hs2graphviz/tree/master/Examples/ Examples of real code analyzed: http://github.com/finnsson/hs2graphviz/raw/master/Examples/Control.pdf (from hpage) http://github.com/finnsson/hs2graphviz/raw/master/Examples/Hack.png (from Hack) Example of mock code analyzed: http://github.com/finnsson/hs2graphviz/raw/master/Examples/TestCode.pdf (three files analyzed together) The tool is still far from complete. Better handling of algebraic data types and instance declarations are a must. GADTs, data families and type synonym families are not yet implemented so they wont turn up. -- Oscar

2 4

Announce: hlcm 0.2.2 - Parallel closed frequent itemsets mining
by Alexandre Termier 16 Jun '10

16 Jun '10

Dear all, I'm pleased to announce the release of hlcm on Hackage : http://hackage.haskell.org/package/hlcm-0.2.2 hlcm is data mining tool for computing closed frequent itemsets. This problem is famous as "market basket analysis": - given a list of transactions : [["bread", "butter","chocolate","tomato"] ,["bread","butter"] ,["bread","pencil","butter","chocolate"] ,["bread","butter","book"]] - and a minimal frequency threshold in [1..4], let's say 2: we want items that are sold together in at least 2 transactions hlcm will tell you that ["bread","butter","chocolate"] appears in 3 transactions and that ["bread","butter"] appears in 4 transactions. You can many funnier applications with your own data, for example log analysis, mining words in web pages, etc. You can see details on getting started with the program here: http://membres-liglab.imag.fr/termier/HLCM/hlcm/hlcm/Main.html The library documentation is here : http://membres-liglab.imag.fr/termier/HLCM/hlcm/HLCM.html hlcm is based on the most efficient algorithm for closed frequent itemset mining, LCM, which is much, much faster than the well-known Apriori algorithm (more details when following the pointers from the homepage: http://membres-liglab.imag.fr/termier/HLCM/hlcm.html) hlcm can also exploit parallelism through Strategies, with promising speedups. We still have more work to do in order to beat existing C/C++ implementations, but you can have a look at the paper that we submitted at Haskell Symposium this year for a detailed experimental study: http://membres-liglab.imag.fr/termier/HLCM/hlcm.pdf Don't miss out the section about the influence of RTS parameters on parallel performance. Feel free to send me an e-mail if you have any question about hlcm. Alexandre -- _____________________________________________________________ Alexandre Termier LIG (Laboratoire d'Informatique de Grenoble) Université Joseph Fourier 681 rue de la Passerelle B.P. 72, 38402 Saint Martin d'Hères (FRANCE) Phone: +33 4 76 82 72 07 Fax: +33 4 76 82 72 87 http://membres-liglab.imag.fr/termier/ _____________________________________________________________

1 0

Terminology
by Emmanuel Castro 15 Jun '10

15 Jun '10

I am looking for the name of the property linking two functions f and g when : [f(a),f(b),f(c)] = g([a,b,c]) Is there a standard name? In practice, g is an optimised version of f when working on large amount of elements. Thank you

8 8

learning advanced haskell
by Aran Donohue 15 Jun '10

15 Jun '10

Hi Cafe, I've been doing Haskell for a few months, and I've written some mid-sized programs and many small ones. I've read lots of documentation and many papers, but I'm having difficulty making the jump into some of the advanced concepts I've read about. How do people build intuitions for things like RankNTypes and arrows? (Is the answer "Get a PhD in type theory?") Normally I learn by coding up little exercise programs, but for these I don't have good intuitions about the kinds of toy problems I ought to try to solve that would lead me to understand these tools better. For systems like Template Haskell and SYB, I have difficulty judging when I should use Haskell's simpler built-in semantic abstractions like functions and typeclasses and when I should look to these other mechanisms. I understand the motivation for other concepts like iteratees, zippers and functional reactive programming, but there seem to be few entry-level resources. John Lato's recent Iteratee article is a notable exception*. Hints? Tips? "Here's how I did it"? _______ is a great program to write to get to learn ______? Thanks in advance, Aran * Even in this article, he busted out (>=>). And it appears that the iteratee library's actual design is more sophisticated than the design presented.

9 9

Re: [Haskell-cafe] Problems with threading?
by Isaac Gouy 15 Jun '10

15 Jun '10

--- On Mon, 6/7/10, Don Stewart <dons(a)galois.com> wrote: > From: Don Stewart <dons(a)galois.com> > Subject: Re: [Haskell-cafe] Problems with threading? > To: "Isaac Gouy" <igouy2(a)yahoo.com> > Cc: "Louis Wasserman" <wasserman.louis(a)gmail.com>, "Haskell Café List" <haskell-cafe(a)haskell.org> > Date: Monday, June 7, 2010, 4:43 PM > igouy2: > > As Louis has already mentioned this to me, I'll take > the opportunity > > to sketch out a simple approach - > > > > > > 1) GHC programs compiled without -threaded and run > without +RTS -N are already shown for x86 and x64 > > > > http://shootout.alioth.debian.org/u32/compare.php?lang=ghc > > > > http://shootout.alioth.debian.org/u64/compare.php?lang=ghc > > > > > > 2) For quad-core, the GHC programs will all be > compiled with -threaded and all run with +RTS -N4 > > > > > > 3) That seems to match the approach taken with Erlang, > where all the > > programs on quad-core run with smp built into the vm, > and all the > > programs on one core run without smp built into the > vm. > > > > Yep, that's fine. All the GHC programs have been re-measured. http://shootout.alioth.debian.org/u64q/compare.php?lang=ghc http://shootout.alioth.debian.org/u32/compare.php?lang=ghc Now how do we get those regex-dna and binary-trees programs to compile? http://shootout.alioth.debian.org/u32/measurements.php?lang=ghc

4 5

Re: [Haskell-cafe] learning advanced haskell
by John Lato 15 Jun '10

15 Jun '10

> Message: 7 > Date: Mon, 14 Jun 2010 20:33:30 +0100 > From: Andrew Coppin <andrewcoppin(a)btinternet.com> > Subject: Re: [Haskell-cafe] learning advanced haskell > To: haskell-cafe(a)haskell.org > Message-ID: <4C16840A.7060700(a)btinternet.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > John Lato wrote: > >> However, there's a lot to be said for both intellectual curiosity and >> learning for the sake of knowledge. Just because you may never need >> to use a feature doesn't mean you shouldn't be able to understand it. > > There is that. However, in my experience, most of the advanced > techniques tend to be described in language beyond my comprehension. > (And most examples seem overly complex - although maybe that's just a > reflection of the fact that simple problems don't require sophisticated > techniques in the first place.) Having a specific problem to solve can > be quite helpful. Unlike an example, you already understand what the > problem is, and why it can't easily be solved any other way. Yes, having a specific problem to solve can be very helpful. The OP requested examples of them. I'd like to see them myself, partially as a reference but mostly to satisfy my own curiosity. More examples please! John

1 0

Re: [Haskell-cafe] learning advanced haskell
by John Lato 15 Jun '10

15 Jun '10

> From: Martijn van Steenbergen <martijn(a)van.steenbergen.nl> > > On 6/14/10 10:39, Ivan Lazar Miljenovic wrote: >> By being told that using them would solve some problem you're >> complaining about on #haskell or the mailing lists, you look at >> examples, read up on them, etc. >> >> Short version: don't worry about advanced concepts until you have to. >> If all else fails, it doesn't hurt to write out the low-level version >> yourself and then get told in a code review that it would be "easier" or >> more elegant with an advanced technique. > > Exactly this. It's happened a few times now that I ran into a problem > and then a bit later found out that feature XYZ was exactly what I > needed. A feature I never understood but now suddenly had a good > intuition for because it is a (or the) solution to a problem I had been > thinking about for a while. I sort of agree with this, with some very large caveats. I would agree that being faced with an actual problem provides a particularly good learning environment for several reasons. For the "pragmatic programmer", this is probably the way to go. However, there's a lot to be said for both intellectual curiosity and learning for the sake of knowledge. Nearly all of us specialize in certain problem domains or areas and will likely never work on certain problems (related to e.g. compilers, web servers, etc.) in anything like a commercial environment. Some of us may never work in a commercial code environment at all. Just because you may never need to use a feature doesn't mean you shouldn't be able to understand it. John

3 2

Reactive and 'real live' problem
by Maciej Piechotka 15 Jun '10

15 Jun '10

I tried to experiment with reactive[1] and rewrite NeHe tutorials using reactive-glut. However I run into problems. I tried to write first tutorial and exit on escape. However there were 2 problems: 1. Optimized constant functions 2. Continuous behaviour In reactive the final step is Behaviour which is 'function' from time to something a. Here a = IO (). The problem is that it is not indifferent how many time the same IO () was returned (we don't want to write to file twice etc.). I tried to workaround it in various ways but all I came up to was to switch after switch with time + * where * is the difference between times (unfortunately there is no function which give the next float). As with every tick everything is executed -- unless everything gets optimized to constant function. Am I failing to find proper docs? How solve those problems? If they are not easily solvable is there any general-purpose FRP library that allows to use IO inside? Regards [1] http://hackage.haskell.org/package/reactive

1 0

Possible solution to the FGL naming/compatability issue
by Ivan Miljenovic 15 Jun '10

15 Jun '10

Last night (AEST), Edward Kmett semi-convinced (in the sense that I'm not sure whether his examples are really those that someone would want/need or just thinking of possible future problems) me that some users may have a need for FGL to keep having explicit graphs with kind * -> * -> *. With his prompting, I may have a possible solution: duplicate the classes. We would have an InductiveGraph class (call it the parametric version) that requires graphs to have kind * -> * -> *, and then another class (call it the extended version) that removes this restriction. The parametric version would be closer to a drop-in replacement to the current FGL setup (see below for more details) and the extended one would provide all of the functionality requested, with some kind of semi-automatic lifting/unlifting for graph types that are instances of both. Now, this parametric version will still not be a drop-in for the current FGL, for several reasons: * I want to have one overall InductiveGraph class rather than two separate Graph and DynGraph classes * Context will still be an actual data type rather than a 4-tuple and LEdge would be come (Edge, Label) rather than (Node, Node, Label) [I'm still debating whether to keep Edge as a datatype as needed for the Type Familiy version or if it should just be a tuple). * Some function names will be changed (e.g. fromContexts rather than buildGr). * The Data.Graph.Inductive.Query stuff is going to be split out into its own separate library, the Data.Graph.Inductive.Graphviz stuff is going to be removed, etc. * With the removal of the sub-libraries, I'm seriously considering moving the class definitions from Data.Graph.Inductive.Graph to just Data.Graph.Inductive. There are also some caveats/design decisions with this solution: * There will obviously be duplication. With that said, do we try to make the two classes semi-drop-ins (same class name, methods, etc. but with different types) or think up new method names for the extended version? * How transparently can/will we make the lifting/unlifting? * If we want the parametric version to still have the ability to specify a custom node type, then it will still need either MPTCs + fundeps or Type Families (i.e. extensions); otherwise we stick with the current "type Node = Int" (or maybe replace it with some opaque abstract type down the track as suggested by Heinrich Apfelmus). * If we want to provide the ability to restrict the types of the labels in the parametric version, then we would need MPTCs (Type Families won't work since the label types won't be part of the class definition then unless we use MPTCs, and in that case there's not really any point in using Type Families). Thus we once again need extensions. * My semi-end goal is to build a proper hierarchy of graph types/libraries, such that the only thing FGL provides is the extra aspect/concept of inductive graphs. If we extend this parametric vs extended split down to the set of base graph classes, then we're going to have even more duplication and this kind of setup (where "Foo depends on Bar" means "class (Bar a) => Foo a where ..."): - fgl-parametric will depend on graph-parametric - fgl-extended will depend on graph-extended - There will be lifting/unlifting between graph-parametric and graph-extended - There will be lifting/unlifting between fgl-parametric and fgl-extended As such, an FGL graph of kind * -> * -> * being treated as an extended graph will have two possible ways (depending on the function in question) will have two graph hierarchies two choose from, and two possible points at which it can be lifted/unlifted (at the graph level and the fgl level). This could get confusing. That said, there is one other benefit of this parametric vs extended split: the types of the mapping functions in http://code.haskell.org/FGL/fgl/Data/Graph/Inductive/Graph.hs won't be as weird... So, what are people's thoughts/opinions on this kind of setup? Note that I haven't started coding it yet, so I'm not sure how well it will work in practice... -- Ivan Lazar Miljenovic Ivan.Miljenovic(a)gmail.com IvanMiljenovic.wordpress.com

1 0