January 2010 - Haskell-Cafe

I/O performance drop in ghc 6.12.1
by Peter Simons 14 Jan '10

14 Jan '10

Hi, I just updated to GHC 6.12.1, and I noticed a significant drop in I/O performance that I can't explain. The following code is a simple re-implementation of cat(1), i.e. it just echos all data from standard input to standard output: > module Main ( main ) where > > import System.IO > import Foreign ( allocaBytes ) > > bufsize :: Int > bufsize = 4 * 1024 > > catBuf :: Handle -> Handle -> IO () > catBuf hIn hOut = allocaBytes bufsize input > where > input ptr = hGetBuf hIn ptr bufsize >>= output ptr > output _ 0 = return () > output ptr n = hPutBuf hOut ptr n >> input ptr > > main :: IO () > main = do > mapM_ (\h -> hSetBuffering h NoBuffering) [ stdin, stdout ] > catBuf stdin stdout That program used to have exactly the same performance as /bin/cat, but now it no longer does: | $ dd if=/dev/urandom of=test.data bs=1M count=512 | | $ time /bin/cat <test.data >/dev/null | | real 0m1.939s | user 0m0.003s | sys 0m1.923s | | $ time ./cat-hgetbuf <test.data >/dev/null | | real 0m4.327s | user 0m1.967s | sys 0m2.317s I've tested different variants of the program that were built with -O, -O2, and -O2 -funbox-strict-fields, respectively, but it doesn't seem to make a difference. Is there something I'm missing? Any suggestion would be kindly appreciated. Take care, Peter

4 4

wildcards for type variables?
by Evan Laforge 14 Jan '10

14 Jan '10

Occasionally I have a function with an unused argument, whose type I don't want to restrict. Thus: f :: _unused -> A -> B f _ a = b Since it's a little unusual, I try to make it clear that the type is intentionally ignored. But it makes me wonder, would it make sense to allow _ as a type variable name, with the same meaning as in pattern matching?

8 10

Re: [Haskell-cafe] sizeOf on a type
by Henning Thielemann 14 Jan '10

14 Jan '10

On Fri, 25 Dec 2009, Lennart Augustsson wrote: > sizeOfPtr :: Ptr a -> Int > sizeOfPtr = sizeOf . (undefined :: Ptr a -> a) > > No need for scoped type variables. But it does assume sizeOf does not > use its argument. That's even better. I'll add that to the Wiki. http://www.haskell.org/haskellwiki/Scoped_type_variables#Avoiding_Scoped_Ty…

1 0

looking for origin of quote on preprocessors and language design
by Johannes Waldmann 14 Jan '10

14 Jan '10

Dear all, It's not exactly Haskell-specific, but ... I am trying to track down the origin of the proverb "the existence (or: need for) a preprocessor shows omissions in (the design of) a language." I like to think that in Haskell, we don't need preprocessors since we can manipulate programs programmatically, because they are data. In other words, a preprocessor realizes higher order functions, and you only need this if your base language is first-order. Yes, that's vastly simplified, and it does not cover all cases, what about generic programming (but this can be done via Data.Data) and alex/happy (but we have parsec) etc etc. Best regards, J.W.

7 9

ANN: hakyll-1.0
by Jasper Van der Jeugt 14 Jan '10

14 Jan '10

Hello, I have just released hakyll[1] 1.0. It is now available on hackage[2]. This is considered a first stable release (hence 1.0), and pretty it is functional. Hakyll is a Haskell library for generating static sites. It is written in a very configurable way and uses an xmonad-like DSL for configuration. Important changes: - Switched from the template library to a custom template system, because we needed some more flexibility, but not quite as much as something like HStringTemplate would give. - Switched from inconsistent String/ByteString usage to String only for the external API. - Added a $root system so it is easy to work with relative/absolute URL's. - Many bugfixes. - More documentation and a reference are online now. All feedback and questions are welcome. Kind regards, Jasper Van der Jeugt [1]: http://jaspervdj.be/hakyll [2]: http://hackage.haskell.org/package/hakyll

1 0

Re: [Haskell-cafe] Web application interface
by Michael Snoyman 14 Jan '10

14 Jan '10

On Thu, Jan 14, 2010 at 1:58 PM, Alberto G. Corona <agocorona(a)gmail.com>wrote: > > > 2010/1/14 Michael Snoyman <michael(a)snoyman.com> > >> >> >> On Thu, Jan 14, 2010 at 1:20 PM, Alberto G. Corona <agocorona(a)gmail.com>wrote: >> >>> >>> >>> 2010/1/14 Michael Snoyman <michael(a)snoyman.com> >>> >>> >>>> >>>> Well, for one thing, you'd need to use lazy IO to achieve your goal, >>>> which has some safety issues. As things get more and more complex, the >>>> requirements of lazy IO will continue to grow. This also has implications >>>> for number of open file handles and deterministic space usage. Given the >>>> fact that a lazy bytestring and easily be converted to an enumerator, I >>>> think it makes sense to start a new package using this approach. >>>> >>>> These must be issues of base library developers, not application >>> developpers. TIme ago a guy said me that using an standard library like >>> malloc for memory allocation where not the optimum. And he was right. >>> Fortunately things went in the "non-optimum" direction. You can make the >>> application faster by using your own plumbing code instead of standard >>> libraries provided that you have enough time and knowledge. Because I don´t >>> have neither of the two :-) (nor have the people that read my code and >>> maintain the application), I really like the laziness of haskell and the >>> lazy bytestring interface. >>> >>> Lazy bytestring interface is one thing; lazy IO is another. If you have >> pure code generating a lazy bytestring, Hack will work fine for you. Try >> this one however: take a 10MB YAML file, reformat it using something in the >> IO monad (for example, look up values from a database) and produce HTML >> output. Hack will *not* allow you to run in constant space without >> significant usageof unsafe functions. >> >> Michael >> > > So there are memory leaks somewhere in the lazy bytestring IO libraries > (not in hack neither is an inherent problem in the lazy bytestring design, > the lazy IO concept or laziness as such). > > I did''t take a look, but surely a lazy bytestring IO read is composed of > an iteration of strict block reads that present a lazy bytestring interface. > It must be essentially the same than a iteratee IO, but with a higher level > interface (at least higher from my point of view). > > I like haskell for Internet applications because streaming is the essence > of communications and function call is the building block of programming. > Haskell deals with both with zero impedance because its laziness. Don't > break this!! > > > No, that's not the way it works. Lazy IO requires the use of unsafeInterleaveIO, which is, well, unsafe. Pure functions in Haskell can safely be lazy, not so with IO. If you don't believe me, you can read more about it here: http://okmij.org/ftp/Streams.html#iteratee Michael

1 0

Re: [Haskell-cafe] Web application interface
by Pasqualino "Titto" Assini 14 Jan '10

14 Jan '10

Hi Michael, no, the message was not meant to be off-list, that was just me pressing the wrong button :-) Regarding happstack, I do not believe that there is a contrast with your effort, the core of happstack is in its persistency mechanism not in its http interface so I think it would be great to engage the happstack community in this effort. We have so many half-baked and dispersed attempts in the web area that any attempt at consolidation can only be welcome. Personally I have been using happstack for a few years though now I am running it behind a nginx server because of its known deficiencies (no HTTPS etc). titto P.S. I will be away for a few days and unable to answer my email 2010/1/13 Michael Snoyman <michael(a)snoyman.com>: > Not sure if you replied off-list on purpose or not, but I'll continue this > off list for the moment. I think we have a bit of a problem in the Haskell > web community: you've got the Happstack camp and then the rest of us. "The > rest of us" need to rally around *something*, and it seems that Hack didn't > get people's attention for some reason. > > I'm happy to write WAI, but I'd like more to make it a community effort. You > have any thoughts on this? My first stab at the idea is to create a github > repo, write the code, and then try to get people to comment on it. However, > I also want to give it at least a day so I can get people's feedback on this > e-mail. > > What have you been using for Haskell web development until now? It seems > like each non-Happstack person has a totally different approach, and I'd > like to try and consolidate this together somehow. > > Michael > > On Wed, Jan 13, 2010 at 11:12 PM, Pasqualino "Titto" Assini > <tittoassini(a)gmail.com> wrote: >> >> A unified web app interface would be a God-sent, please please go ahead. >> >> Regarding point 1, I find hack interface nice and clean and would like >> to see something similar. >> >> Regarding point 2 I vote for correctness/performance vs convenience. >> >> titto >> >> 2010/1/13 Michael Snoyman <michael(a)snoyman.com>: >> > Hi, >> > >> > I recently read (again) the wiki page on a web application interface[1] >> > for >> > Haskell. It seems like this basically works out to Hack[2], but using an >> > enumerator instead of lazy bytestring in the response type. Is anyone >> > working on implementing this? If not, I would like to create the >> > package, >> > though I wouldn't mind some community input on some design decisions: >> > >> > * Hack has been fairly well-tested in the past year and I think it >> > provides >> > the features that people want. Therefore, I would want to model the >> > Environment variable for WAI from Hack. I *could* just import Hack in >> > WAI >> > and use the exact same Environment data type. Thoughts? >> > >> > * If using a different data type for Environment, should I replace the >> > String parts with ByteStrings? On the one hand, ByteStrings are the >> > "correct" data type since the HTTP protocol does not specify a character >> > encoding; on the other hand, Strings are easier to deal with. >> > >> > * It's simple to write a function to convert between a lazy bytestring >> > and >> > an enumerator, meaning it would be very easy to write conversion >> > functions >> > between Hack and WAI applications. This would make it simpler for people >> > to >> > use either backend. >> > >> > If someone else is already working on WAI, please let me know, I don't >> > want >> > to have duplicate implementations. The idea here is to consolidate, not >> > split the community. I have a few Hack handlers (simpleserver, cgi, >> > fastcgi) >> > that I would happily convert to WAI handlers as well. >> > >> > Michael >> > >> > [1] http://www.haskell.org/haskellwiki/WebApplicationInterface >> > [2] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hack >> > >> > _______________________________________________ >> > Haskell-Cafe mailing list >> > Haskell-Cafe(a)haskell.org >> > http://www.haskell.org/mailman/listinfo/haskell-cafe >> > >> > >> >> >> >> -- >> Pasqualino "Titto" Assini, Ph.D. >> http://quicquid.org/ > > -- Pasqualino "Titto" Assini, Ph.D. http://quicquid.org/

1 0

Name overloading
by Cristiano Paris 14 Jan '10

14 Jan '10

Hi, these days I'm thinking about name scoping in Haskell and a question built up silently but steadily in my mind. Many times I see code like this: data Foo = { fooBar :: Int, fooSay :: String, fooClose :: String } which reminds me of "Ye Olde Times" of C where you prepend the structure name (or an abbreviation) to the structure's fields so as to avoid clashes with other (possibly included) structures (here Haskell qualified imports don't help as they just let you cut down the size of the prefix which is still present though and is module-scoped anyway). One of the most appreciated (at least by me) features of OOP languages like C++, Java, Python and co. is the possibility to name instance methods the same in different classes and have the compiler resolve to the correct implementation (at least indirectly through a virtual table when inheritance is in place) simply looking at the type of the variable which "->" is applied to. The most fulgid example of this is the "open" method, which is likely to be present in lots of classes. Now, in Haskell we have type inference, which is "The Good Thing" as it allows to "validate" your program at compile time. Hence, the idea coming up to my mind is that type inference actually forbids a type-directed resolution of names as in C++ or Java. Is this correct? Think about this piece of code: data DB = { open :: DBHandle } data FS = { open :: File } foo x = open x or, worse: foo x = open (open x) if the result of the first "open" application should typecheck with the second. Notice that, in my understanding, adding a signature doesn't help as the type checker must guarantee that "foo" code complies with its signature, which is actually impossible if open is left undetermined in its type. Thank you for any comment. Cristiano

5 7

Strategies
by Alexei Kitaev 14 Jan '10

14 Jan '10

Dear Ryan, Thanks a lot for your support and for pointing out a problem with my approach to forcing the state. I was aware of this issue but I didn't know there was a standard solution. It is indeed very natural to let each type specify how to evaluate itself. I will try this technique on the nearest occasion. Incidentally, the link to Control.Parallel.Strategies from the latest GHC User Guide is broken... --Alexei Ryan Ingram wrote: > On Sat, Jan 9, 2010 at 2:23 AM, Alexei Kitaev <kitaev(a)iqi.caltech.edu> wrote: >> Reading the discussion related to your blog, I >> realized that strict State is different in that it does not actually >> force the state. But forcing can be achieved by wrapping all actions >> with the following function: >> >> sState :: (s -> (a,s)) -> State s a >> sState f = State $ \s -> case f s of >> (a,s') -> s' `seq` (a,s') >> >> I hope that somebody will answer my other questions about the >> operational semantics and optimizations. > > Hi Alexei, you have a ton of great points but I wanted to discuss an > issue with this one. > > It's unusual that this is what you want either; since it only reduces > the state to WHNF. For example, if your state is a string, this only > evaluates enough to know whether or not the string is empty at each > step, and you can still get into trouble with code like this: > > put ("xxx" ++ some_bad_computation) > > which leave bottoms inside of your state which won't show up until later. > > Several attempts to solve this problem exist, but the most commonly > used one is the "rnf" strategy from Control.Parallel.Strategies, which > uses a typeclass to allow each type to specify how to evaluate itself > completely. > > -- ryan

1 0

How to fulfill the "code-reuse" destiny of OOP?
by Magicloud Magiclouds 13 Jan '10

13 Jan '10

Hi, I think when people talk about OOP, especially the inheriting, their focus mainly is on functions (methods). My concern here is about the data member inheriting. In OOP, when I inherit a class, I also got the members of it. But in haskell, how to inherit a "data"? -- 竹密岂妨流水过山高哪阻野云飞

19 27