June 2010 - Haskell-Cafe

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 14 Jun '10

14 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 14 Jun '10

14 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

Heist template splice functions and custom monad
by Kevin Jardine 14 Jun '10

14 Jun '10

I'd like to run Heist template splice functions in my own custom monad. I can define a splice function as: mySplice :: Splice MyMonad However, when I try to call functions that return values in my monad in mySplice, I get a compile error: Couldn't match expected type TemplateMonad MyMonad a against inferred type MyMonad () I've seen an example in the Heist documentation where the inner MyMonad is accessed using lift. But when I try that, I get another compile error: No instance for (Monad Trans TemplateMonad) arising from the use of 'lift' What do I do to get this to work? Kevin

2 1

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

14 Jun '10

> From: Neil Brown <nccb2(a)kent.ac.uk> > > For example, if you find yourself writing the Nth boilerplate function > that pattern-matches all cases in your ADT just to apply a function in > its sub-types, that's when you'll want some form of generic programming > like SYB. And by that point you'll understand one of the problems that > generic programming solves, which is halfway towards understanding the > techniques themselves. This is probably the most approachable description of generic programming I've seen. Every generic framework should have a paragraph like this on the front page of the docs. John

1 0

Re: Iteratee rest and monad instance
by John Lato 14 Jun '10

14 Jun '10

> From: Tilo Wiklund <noteventime(a)gmail.com> > > I am probably missing something obvious or something relating to > optimisation/server software but defining iteratees as "Iteratee s a = > Cont (s -> Either (s, a) (Iteratee s a))" seems to lead to a more > natural monad instance, and does not suffer from (what seems to me to > be an issue) having to make predictions about the stream it will be > passed. > > My question is thus, why the "rest" stream has to be carried by an > Iteratee constructor, rather then be part of the value of the > continuation function. Bas's reply is spot-on. To directly answer your question, there is no technical reason and both implementations are possible (among others). The reasons for the choice (at least in the iteratee library) have to do with the types that arise for enumerators and iteratee combinators for a given implementation. There is a good discussion of this in the comments in Oleg's source code. Currently I prefer the CPS-style. It looks more complicated, and it can't be written in Haskell-98, but otherwise it seems easier to use with comparable (or better) performance. Other factors (chunk size, chunk type) seem to have a much more significant effect on performance than this. There are performance differences between the two IterateeG/IterGV implementations, but as far as I know neither one is better overall. John

1 0

Re: learning advanced haskell
by John Lato 14 Jun '10

14 Jun '10

> From: Aran Donohue <aran.donohue(a)gmail.com> > > 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. I read as much as I can. On the cafe, Planet Haskell, papers, whatever. If I don't understand a paper, I leave it be for a while then come back to it in a few weeks/months. Usually I'll be able to make further headway. Also don't try to read too much at once. The literature is quite dense and I find it useful to let things sit and percolate for a while. For the specific cases of RankNTypes and arrows I had nearly opposite experiences. I understood RankNTypes immediately, in that I expected higher-rank behavior and was surprised when code didn't work that way. Arrows were particularly difficult for me (for much the same reason as the Monoid class, incidentally). I understood the concept of arrows, but was unable to figure out how to actually *do* anything with them for some time. I'm still not sure that I have a great idea of when arrows are useful as a computational abstraction; they seem to be used more for the notation and convenience functions than anything else. > 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*. This is exactly what I was aiming for, so I really appreciate hearing your comments. I'm a beginner in many areas as well, so I also would like to see more entry-level resources. > > Hints? Tips? "Here's how I did it"? _______ is a great program to write to > get to learn ______? > Stuff I have a decent understanding of: RankNTypes - Look at this function > makeString :: (Show b, Show c) => (a -> a) -> b -> c -> String > makeString f b c = show (f b) ++ show (f c) If you try to call it as e.g. > makeString id 0 "foo" GHC provides a type error. This doesn't work because when GHC unifies the types, it does something like this: 1) the first argument, f, is a function with type a -> a 2) the function f is applied to an Integer, so f :: Integer -> Integer 3) the function f is applied to a String, so f :: String -> String 4) there are conflicting types for f, so bail out Even though you declare f :: a -> a, that 'a' must be set to exactly *one* value within the call, where makeString tries to apply it to values with different types. This is rank-1 polymorphism. RankNTypes fixes this by allowing us to specify that the "f" function is supposed to be polymorphic within the makeString function (rank-2 polymorphism) as opposed to the standard rank-1 polymorphism: > makeString2 :: (Show b, Show c) => (forall a. a -> a) -> b -> c -> String calling makeString2 does the right thing. That's pretty much the whole story of Rank2Polymorphism. RankNPolymorphism is exactly the same with nested levels of forall's. One really useful feature of this is that it provides a sort of inversion-of-control for polymorphism. Typically the caller has the ability to define the types when a function is called, as happens with the b and c parameters to makeString2. But in the first argument the *callee* determines the type values of the function! The caller knows only that the function must take one argument and return a result of the same type (which also means "id" is the only interesting function of the appropriate type). The callee is free to instantiate the given function with *any types it wants*. This is also what makes the ST monad safe incidentally. Arrows - Toy project: write a small program and use arrow notation to combine functions. Write the zipWith version of the "fib" function with arrows. Most of the stuff on the web is pretty readable IMHO. Yampa is a good place to move beyond "Arrow" and into "ArrowLoop". Zippers - Toy project: anything that keeps track of decisions in a tree. Mapping a path as in Theseus and the Zipper seems good. I learned it by implementing a user history function. Template Haskell - Toy project: programatically generating data declarations seems like a good starting point because it's relatively simple and can't be done with normal code. Instances are a good follow-up. Of course this is only a small portion of what TH can do, but it's a start. Bulat's tutorials are the best on this topic I'm aware of. I left out a lot of stuff that I'm still working with myself (SYB, Finally Tagless, category-extras, ...). > 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. Well, yes. If the library implementation (or Oleg's examples) were the same as the implementation I presented, there probably would have been no need for the article! John

1 0

parsec: how to get end location
by Roman Cheplyaka 14 Jun '10

14 Jun '10

Suppose I have some parser 'p'. I want to parse it as well as get its span in the text. So I could write \begin{code] pWithLocation = do loc_start <- getPosition pval <- p loc_end <- getPosition return (pval,loc_start,loc_end) \end{code} except that loc_end gives me the location _after_ 'p'. In case when 'p' has consumed trailing newline I see no way to recover the end location of 'p' (it is the last column of the previous line). So, can I do anything with this without patching parsec? I use parsec3 if it matters. -- Roman I. Cheplyaka :: http://ro-che.info/ "Don't let school get in the way of your education." - Mark Twain

5 5