- Haskell-Cafe - Haskell.org

Re: explicit big lambdas
by oleg＠okmij.org 19 Mar '10

19 Mar '10

Paul Brauner wrote: > is there a way in some haskell extension to explicit (system F's) big > lambdas and (term Type) applications in order to help type inference? Actually, yes: newtype constructor introductions may act as a big lambda, with constructor elimination acting as type applications: http://okmij.org/ftp/Haskell/types.html#some-impredicativity Newtypes are also handy for turning type functions (defined by type families) into real lambdas. For example, given the following code > {-# LANGUAGE NoMonomorphismRestriction #-} > {-# LANGUAGE TypeFamilies, EmptyDataDecls #-} > {-# LANGUAGE ScopedTypeVariables #-} > > module S where > > data Z > data S a > > class Nat a where nat :: a -> Int > instance Nat Z where nat _ = 0 > instance Nat n => Nat (S n) where nat _ = succ (nat (undefined::n)) > > type family Add a b > type instance Add Z b = b > type instance Add (S a) b = S (Add a b) we would like to compose the type function Add (S (S Z)) twice. We may first try *> newtype F2 f x = F2{unF2 :: f (f x)} *> tf1 :: F2 (Add (S (S Z))) (S Z) *> tf1 = undefined alas, without success: Type synonym `Add' should have 2 arguments, but has been given 1 In the type signature for `tf1': tf1 :: F2 (Add (S (S Z))) (S Z) Indeed, type functions defined via type families can't be turned into closures. Newtypes help, introducing the needed Lambda behind the scenes: > newtype A2 a = A2{unA2 :: Add (S (S Z)) a} > > appA2 :: x -> A2 x > appA2 = undefined > > -- Now we can compose the type function, many times > tc = unA2 . appA2 . unA2 . appA2 > -- Inferred type: > -- tc :: a -> Add (S (S Z)) (Add (S (S Z)) a) > > tcrun = nat $ tc (undefined::S Z) > -- 5 One can see from the inferred type of tc that the type-checker has composed the partially applied Add function. I'll show a bit more elaborate example next week.

2 1

Why no instance of Happstack.Data.Default.Default for Data.ByteString.Lazy
by Mads Lindstrøm 19 Mar '10

19 Mar '10

Hi Why is that Happstack has: instance Happstack.Data.Default.Default Data.ByteString But not one for: instance Happstack.Data.Default.Default Data.ByteString.Lazy I am trying to make a HTTP proxy using Happstack and the client part with the Network.HTTP (see Hackage). Network.HTTP.simpleHttp returns a lazy Bytestring when given a lazy Bytestring (which makes sense). Happstack on the other hand contains a lazy ByteString in its request type: data Request = Request { ... rqHeaders :: Headers, ... rqBody :: RqBody ... } newtype RqBody = Body Data.ByteString.Lazy.Internal.ByteString which Happstack.Server.SimpleHttp.simpleHTTP feeds into my application. However Happstack.Server.SimpleHttp.simpleHTTP expects something returned which is an instance of Happstack.Data.Default.Default which lazy ByteString is not. Confused? So am I. Who thought String handling could be so complex. Greetings, Mads Lindstrøm

2 1

Trace
by Ben Derrett 19 Mar '10

19 Mar '10

Hi, I'm a new Haskell programmer and am trying to output the values of some of the variables (for debugging) as the program executes. At the moment to output the value of the function I use: f x y z = trace (show moves) moves where moves = [complicated expression of x y z] But really what I want is to be able to write: f x y z = trace2 [complicated expression of x y z] Is there a standard function to do this? I tried: trace2 a = trace (show a) a But I got the error: Couldn't match expected type `t1 -> t' against inferred type `String' In the expression: (show a) a In the definition of `trace2': trace2 a = (show a) a How do I fix it? Thanks, Ben

3 2

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