- Haskell-Cafe - Haskell.org

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

Difficulties with tagless - create "primitives" or compose them
by Günther Schmidt 14 Jun '10

14 Jun '10

Hi list, there is one thing about the "Finally tagless" EDSL approach that really confuses me: (Well more than one actually but this one more so) When to decide to introduce a term as a primitive in the syntax class and when to define it from primitives already defined. For example this one here: type Arr exp a b = exp a -> exp b class EDSL exp where lam :: (exp a -> exp b) -> exp (Arr exp a b) app :: exp (Arr exp a b) -> exp a -> exp b int :: Int -> exp Int -- Integer literal add :: exp Int -> exp Int -> exp Int sub :: exp Int -> exp Int -> exp Int mul :: exp Int -> exp Int -> exp Int Let's take "mul" here, defined as a "primitive", in other words defined in the EDSL class. Technically, with lam, app and add already defined, I could have defined "mul" outside the EDSL class, just built from the 3 primitive operators. Of course doing so then does not give me the possibility to choose alternative evaluation strategies for "mul" itself, only for lam, app and add. So what is a good measure for deciding when to define a term primitive or not? Günther

3 4

How to "Show" an Operation?
by Martin Drautzburg 14 Jun '10

14 Jun '10

Dear all, If I have a problem where I have to select from a set of operations, how would I print the result? Example: If I can chose from (x+y), (x*y), (x^2+y)... and I feed them all into my problem solver and it finds that "(x*y) is right", how can I print that string? -- Martin

6 7

GeneralizedNewtypeDeriving and TypeFamilies
by Max Cantor 14 Jun '10

14 Jun '10

So I understand from http://hackage.haskell.org/trac/ghc/ticket/4083 that GeneralizedNewtypeDeriving doesn't play well with TypeFamilies. But, if a typeclass is only using type synonyms, is there any reason why newtype deriving would not work? For a toy example: class Cls a where type MyType a foo :: MyType a -> in this case, if you have something like: instance Cls () where type MyType () = () foo = id would: newtype Bar = Bar () deriving (Cls) be well defined? Thanks, Max

1 0

Graph type
by C K Kashyap 14 Jun '10

14 Jun '10

Hi, I am trying to write a routine that would generate a graph - where each vertex would be a string. type Graph v = [(v,[v])] -- list of tuples of vertices and adjacent vertices list addEdgeToGraph :: Graph -> String -> String -> Graph I am having trouble coming up with the body of this function - that takes the original graph, and an edge (string -> string) and the produces the new graph. -- Regards, Kashyap

3 4

Announce: Properties-0.0.2
by Alberto G. Corona 13 Jun '10

13 Jun '10

http://hackage.haskell.org/package/properties-0.0.2 <http://hackage.haskell.org/package/properties-0.0.2>Properties can use QuickCheck properties in the same way than assertions are used, for causal debugging of real programs. It also add an human readable structure for grouping properties for classes or libraries. The properties can then be tested in the instance´s body or in programs as if they were assertions. The main advantage is that the compliance of properties can be done with the complete data range that the real application generates (hopefully, with an pleasant separation of real code and debug code). This is a simple example: stringProperty= [Property <http://hackage.haskell.org/packages/archive/properties/0.0.2/doc/html/Test-…> "length" (\(x, y)-> length (x++y)== length x + length y)] main= do let s= "hello " let s2= "world" print $ s++ s2 `verify <http://hackage.haskell.org/packages/archive/properties/0.0.2/doc/html/Test-…>` stringProperty `with <http://hackage.haskell.org/packages/archive/properties/0.0.2/doc/html/Test-…>`(s,s2) print "that's all!" It is possible to check quickCheck style properties. The same example with a quickCheck-style property: quickCheckProperty x y= length (x++y)== length x + length y main= do let s= "hello " let s2= "world" print $ s++ s2 `verify <http://hackage.haskell.org/packages/archive/properties/0.0.2/doc/html/Test-…>` [Property "stringSumLength" $ uncurry quickCheckProperty] `with <http://hackage.haskell.org/packages/archive/properties/0.0.2/doc/html/Test-…>`(s,s2) print "that's all!" The package include a more sophisticated example. I Hope that this would be useful Alberto

1 0