- Haskell-Cafe - Haskell.org

ANN: Lite Haskell IDE
by Mambo Banda 15 Jan '10

15 Jan '10

Hi Just started an open source project called Hoodoo. It is meant to be a Lite IDE for Haskell. I wrote it to learn Haskell, so if you are a beginner (like me) it might interest you. If you're interested follow this link (http://hoodoo.kenai.com/) and if you like what you see, grab the code and add something:) Mambo

1 0

Haskell implementation of ideas from StandardML as a Metaprogramming language
by CK Kashyap 15 Jan '10

15 Jan '10

Hi All, I was just going over the paper titled - "Standard ML as a meta programming language" by Samuel Kamin - It has a few ideas of generating C++ code from ML. The first one being generating C++ top down parser. I wanted to try out the sample in Haskell - I was wondering if anyone's already done that - I could just look at that implementation for reference. Regards, Kashyap

2 2

General Advice Needed ..
by Ian675 15 Jan '10

15 Jan '10

Hi, First of all, sorry if its in the wrong section.. But I'm just having trouble getting to grips with Haskell. I have my functional programming exam tommorow and I'm struggling to understand any of this. We worked through the book The Craft Of Functional Programming and Im trying to work my way through it but still no luck.. I find it really hard to put down code onto paper. I can understand the code in the book I can do the simple simple functions like cube.. cube :: Int -> Int cube n = n*n*n But after that im lost :( Is there any general advice? Just keep reading the book till it drills into my big head? You can make sarcastic n00b jokes if you like.. I'm just a very frustrated student right now! -- View this message in context: http://old.nabble.com/General-Advice-Needed-..-tp27161410p27161410.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

8 10

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