March 2010 - Haskell-Cafe

Template Haskell
by Rafael Almeida 19 Mar '10

19 Mar '10

I was reading the good old template haskell paper by Sheard and Peyton Jones [1]. It looks like some API have changed, but things seems to be more or less the same. I got the printf example to run, and it is an alright example of something to do with template haskell. You lose the ability to use a dynamic generated string for the format, but that's not a practical drawback (I can't think of a practical reason for using anything other than a string literal for format anyway). Anyhow, what is gained by the template programming in that case is really the flexibility in the type system. You can generate the function with the correct type on the fly, during compiling. That's nice enough, but the article keeps saying that templates are nice for implementing your own custom compiler optimizations. I can see that you really can do so, but I fail to think of a good practical example where templates would be hands down the best approach. Perhaps haskellers with more experience have real life examples they've bumped into. So, please, share your experience with us. [1] http://research.microsoft.com/en-us/um/people/simonpj/papers/meta-haskell/m…

3 2

Haskell (Byte)Strings - wrong to separate content from encoding?
by Mads Lindstrøm 19 Mar '10

19 Mar '10

Hi More and more libraries use ByteStrings these days. And it is great that we can get fast string handling in Haskell, but is ByteString the right level of abstractions for most uses? It seems to me that libraries, like the Happstack server, should use a string-type which contains both the content (what ByteString contains today) and the encoding. After all, data in a ByteString have no meaning if we do not know its encoding. An example will illustrate my point. If your web-app, implemented with Happstack, receives a request it looks like http://happstack.com/docs/0.4/happstack-server/Happstack-Server-HTTP-Types.… : data Request = Request { ... rqHeaders :: Headers, ... rqBody :: RqBody ... } newtype RqBody = Body ByteString To actually read the body, you need to find the content-type header, use some encoding-conversion package to actually know what the ByteString means. Furthermore, some other library may need to consume the ByteString. Now you need to know which encoding the consumer expects... But all this seems avoidable if Happstack returned a string-type which included both content and encoding. I could make a similar story about reading text-files. If some data structure contains a lot of small strings, having both encoding and content for each string is wasteful. Thus, I am not suggesting that ByteString should be scraped. Just that ordinarily programmers should not have to think about string encodings. An alternative to having a String type, which contains both content and encoding, would be standardizing on some encoding like UTF-8. I realize that we have the utf8-string package on Hackage, but people (at least Happstack and Network.HTTP) seem to prefer ByteString. I wonder why. Greetings, Mads Lindstrøm

2 1

GLFW on OS X
by Carsten Schultz 19 Mar '10

19 Mar '10

Hi everyone, I am working with MacOS X 10.6.2 ghc 6.12.1 GLFW 0.4.2 OpenGL 2.4.0.1 mkbndl (freshly installed, should be 0.2.1) I have copied sample program from http://www.haskell.org/haskellwiki/GLFW#Sample_Program to a file named GLFWTest.hs. (I had to change some Floats to GLfloats.) No I do: > ghc --make GLFWTest.hs > mkbndl -f GLFWTest > open GLFWTest.app Is that what I am supposed to do? The program window remains white, if I move another window in front of it and away again, it becomes black, but if I draw lines on it (that is the function program) they do not appear. If I move or resize the window, it gets drawn correctly, and I can see that the lines that I had drawn had in fact been registered. From this point on the program works as expected. Is this an OS X specific issue? How do I solve it? Thanks Carsten

2 3

Re: [Haskell-cafe] Iteratee performance
by John Lato 19 Mar '10

19 Mar '10

I think this is a bit easier to write with iteratee-HEAD. There are some significant changes from the 0.3 version, and not all the old functions are implemented yet, however the "cnt" iteratee can be written as: cnt :: Monad m => I.Iteratee S.ByteString m Int cnt = I.liftI (step 0) where step acc (I.Chunk bs) | S.null bs = I.icont (step acc) Nothing step acc (I.Chunk bs) = let acc' = acc + S.count '\n' bs in acc' `seq` I.icont (step acc') Nothing step acc str = I.idone acc str One significant change is that the kind of the first parameter to the Iteratee type has changed, so now it should be a fully-applied type instead of a type function. This means that ByteString can be used directly. "idone", "icont", and "liftI" simplify creation of iteratees, and it's usually not necessary to pattern match on the EOF constructor any more. The first "step" definition above can be left out for a small performance penalty. I wouldn't recommend basing any production code on iteratee-HEAD, as the interface isn't quite finalized yet. With this version of "cnt" and iteratee-HEAD, the iteratee version runs in about 2.2 seconds for the same tests as I used below. Changing the enumFd buffer size to 32K gives the following results: a 460MB input file (generated by cp Tiff.hs long.txt; cat long.txt >> long.txt): MusDept-MacBook-1:Examples johnlato$ time wc -l long.txt 12024249 long.txt real 0m0.997s MusDept-MacBook-1:Examples johnlato$ time ./test_bs < long.txt 12024249 real 0m1.161s MusDept-MacBook-1:Examples johnlato$ time ./test_iter long.txt 12024249 real 0m1.154s All time values are averages of 3 runs. The first run for the bytestring version was a bit long, otherwise run times were very consistent, within 0.004s for each executable. I don't see any reason the buffer size needs to be fixed at compile time. I'll make this change in the next major release. John > From: Vasyl Pasternak <vasyl.pasternak(a)gmail.com> > Subject: Re: [Haskell-cafe] Iteratee performance > To: Gregory Collins <greg(a)gregorycollins.net> > > Gregory, > > Thank you, your code helps, now my it runs in the speed of lazy > bytestring test but uses less memory with it. > > I've only added to your code more strictness in the recursion, my > version is below. > > BTW, I think it is more useful to let user set the chunk size for > reading, so I'd like to see this possibility in the iteratee package.

1 0

Intermediate type variables
by Giuseppe Maggiore 19 Mar '10

19 Mar '10

Hi! How can I specify intermediate type variables to help the compiler do its job? The following, simple, code does not compile because the compiler cannot infer that the type variable a' is CInt; this makes sense, because finding that out would be quite hard. How can I tell the compiler that a' is CInt? {-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies, FlexibleInstances, UndecidableInstances, FlexibleContexts, EmptyDataDecls, ScopedTypeVariables, TypeOperators, TypeSynonymInstances #-} class C a a' where convert :: a -> a' class F a b where apply :: a -> b class S s a where select :: s -> a data CInt = CInt Int instance S (Int,String) Int where select (i,_) = i instance C Int CInt where convert = CInt instance F CInt Int where apply (CInt i) = i + 1 f :: forall s a a' b . (S s a, C a a', F a' b) => s -> b f s = let v = select s :: a v' = convert v :: a' y = apply v' :: b in y x :: Int x = f (10,"foo") Thanks

1 0

stuck with a sample of "programming in haskell"
by 国平张 19 Mar '10

19 Mar '10

Hi, I am a beginner for haskell. I was stuck with a sample of "programming in haskell". Following is my code: --------------------------------------------------------------------- import Prelude hiding (return, fail) type Parser a = (String->[(a,String)]) return :: a -> Parser a return v = (\inp->[(v,inp)]) item :: Parser Char item = \inp -> case inp of [] -> [] (x:xs) -> [(x,xs)] failure :: Parser a failure = \inp -> [] parse :: Parser a->(String->[(a,String)]) parse p inp = p inp (>>=) :: Parser a -> (a -> Parser b) -> Parser b p >>= f = (\inp -> case parse p inp of [] -> [] [(v,out)]->parse (f v) out) p :: Parser (Char,Char) p = do x <- item item y <- item return (x,y) --------------------------------------------------------------------- But it cannot be loadded by Hug, saying: Couldn't match expected type `Char' against inferred type `[(Char, String)]' Expected type: [((Char, Char), String)] Inferred type: [(([(Char, String)], [(Char, String)]), String)] In the expression: return (x, y) In the expression: do x <- item item y <- item return (x, y) ------------------------------------------------------------------- I googled and tried a few days still cannot get it compiled, can someone do me a favor to point out what's wrong with it :-) ?

5 10

ANNOUNCE: direct-fastcgi 1.0
by Dan Knapp 19 Mar '10

19 Mar '10

Yay! This was a week of hard work. I hope that somebody finds it valuable. This package is a native implementation of the FastCGI protocol, allowing Haskell to work with any webserver that supports it. It makes no attempt to imitate the interface of the cgi-3000 and fastcgi-3000 packages, because that API is tied too heavily to legacy interfaces, as with its handling of exceptions, logging, and time. Its advantage over those packages is primarily in the area of clean exception management and better control structure which allows more versatility in processing requests which are not simple GETs. In particular, POST of large files should be possible, as should server-push responses which return content a piece at a time. Also, of course, as a native implementation, there is no dependency on a C library, which simplifies the install process. http://hackage.haskell.org/package/direct-fastcgi -- Dan Knapp "An infallible method of conciliating a tiger is to allow oneself to be devoured." (Konrad Adenauer)

2 1

little help please
by Roderick Ford 19 Mar '10

19 Mar '10

this will be EASY for you to fix, I am sure... what the heck am I doing wrong: import System.Environment(getArgs)import System.Process(readProcessWithExitCode)import System.Exit(exitWith) main = do args <- getArgs (ecode,out,err) <- readProcessWithExitCode "c:\\Perl64\\bin\\perl.exe" ("C:\\Program Files\\MySQL\\scripts\\mysql_config.pl" : args) "" if ecode == System.Exit.ExitCode.ExitSuccess then return out else return err exitWith ecode

3 3

Abstraction in data types
by Darrin Chandler 19 Mar '10

19 Mar '10

Hi, Trying to get up to speed in Haskell, I'm playing with doing some abstraction in data types. Specifically, I have this: type Cartesian_coord = Float type Latitude = Float type Longitude = Float data Point = Cartesian (Cartesian_coord, Cartesian_coord) | Spherical (Latitude, Longitude) type Center = Point type Radius = Float data Shape = Circle Center Radius | Polygon [Point] This obviously stinks since a Polygon could contain mixed Cartesian and Spherical points. Polygon needs to be one or the other, but not mixed. I could define seperate types for Cartesian and Spherical and seperate CartesianPoly and SphericalPoly, but that doesn't seem very elegant and also increases as I add more coordinate systems and shapes. I read a little on GADTs, et al, but I'm not sure if that's what I want for this or not. Any help appreciated! -- Darrin Chandler | Phoenix BSD User Group | MetaBUG dwchandler(a)stilyagin.com | http://phxbug.org/ | http://metabug.org/ http://www.stilyagin.com/ | Daemons in the Desert | Global BUG Federation

10 18

searching a function by providing examples of input/ouput pairs
by Paul Brauner 18 Mar '10

18 Mar '10

Hi, I was looking at hoogle documentation when I remembered that there is some nice, but quite unusable, feature of squeak (smalltalk) which allows you to search function in the library by giving a list of pairs of inputs/ouputs. When I'm saying that it is quite unusable, I mean that squeak has to try _every_ function, some of which may be very slow to deliver a result, or require some side effects. But, piggibacking such a feature on top of hoogle would surely be more efficient: 1. infer types for arguments and outout 2. look for matching functions using google 3. test them Has anyone tried that before? If not I would be glad to. Paul

5 4