February 2008 - Haskell-Cafe

anybody can tell me the pronuncation of "haskell"?
by slofslb＠sina.com 01 Feb '08

01 Feb '08

  ------------------------------------------------------------------- 价格服务都要！中小企业如何选商用电脑( http://d1.sina.com.cn/sina/limeng3/mail_zhuiyu/2008/mail_zhuiyu_20080128.ht… ) =================================================================== 还没买到票吗？新浪票务互助平台，帮你搞定！（http://bbs.bj.sina.com.cn/tableforum/App/index.php?bbsid=143&subid=0&ismain=1）

20 39

hxt memory useage
by Matthew Pocock 01 Feb '08

01 Feb '08

Hi, I've been using hxt to process xml files. Now that my files are getting a bit bigger (30m) I'm finding that hxt uses inordinate amounts of memory. I have 8g on my box, and it's running out. As far as I can tell, this memory is getting used up while parsing the text, rather than in any down-stream processing by xpickle. Is this a known issue? Matthew

13 25

Announce: CC-delcont 0.2
by Dan Doel 01 Feb '08

01 Feb '08

Hello all, After much distraction and laziness on my part (my apologies), I have finally gotten around to putting together a new release of the delimited continuations library CC-delcont. It is now available on hackage. Relevant changes include: * Now builds in GHC-6.8.x * Builds with -Wall (and the code was cleaned up to make as little noise as possible) (Thanks to gwern for the above) Also included is a new module, Control.Monad.CC.Cursor, which provides some functions for reifying traversals into cursors that can be passed around and manipulated. It's still in its infancy, but I hope to eventually include generalized zippers and such. GHC 6.8 or greater is required to build, and haddock 2.0 or greater is required to generate the documentation. Links: * hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/CC-delcont-0.2 * darcs: http://code.haskell.org/~dolio/CC-delcont/ * a brief tutorial: http://haskell.org/haskellwiki/Library/CC-delcont (I've not had too much feedback on this, so if anyone has trouble following some sections, or has ideas on how to better explain delimited continuations, changes are welcome.) Once again, if you discover any bugs, or have any suggestions, don't hesitate to let me know. -- Dan Doel

1 0

derive Pretty?
by Greg Fitzgerald 01 Feb '08

01 Feb '08

Is it possible to automatically derive instances of Pretty<http://haskell.org/ghc/docs/latest/html/libraries/haskell-src/Language-Hask…>? If no, what do most do when it comes to pretty-printing large data types? Thanks, Greg

3 2

Fwd: Re: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?)
by Wolfgang Jeltsch 01 Feb '08

01 Feb '08

Hello Ryan, I hope, it’s okay to forward your message to the list: > Date: Freitag, 1. Februar 2008 01:41 > From: "Ryan Ingram" <ryani.spam(a)gmail.com> > To: "Wolfgang Jeltsch" <g9ks157k(a)acme.softbase.org> This representation is not exactly the same when you include _|_. For example: > data None -- only _|_ / undefined are members of this type. > data Pair a b = Pair a b > > -- There are three distinct inhabitants of the type Pair None (Pair None > None): v1, v2, v3 :: Pair None (Pair None None) > v1 = undefined > v2 = Pair undefined undefined > v3 = Pair undefined (Pair undefined undefined) > > -- whereas there are only two inhabitants of (None, None, None): > p1, p2 :: (None, None, None) > p1 = undefined > p2 = (undefined, undefined, undefined) You could solve it this way: > data PairL a b = PairL a !b where (a,b,c) is syntactic sugar for PairL a (PairL b (PairL c ())) Now we are back to only having two inhabitants of the type: > x1, x2 :: PairL None (PairL None (PairL None ())) > x1 = undefined > x2 = PairL undefined (PairL undefined (PairL undefined ())) There are still potential efficiency issues, although this could be worked out in the compiler; right now it's a single operation to get from a tuple to any member, but in PairL it takes n operations to get from the root to the nth elment of the tuple. The "unbox-strict-fields" optimization can fix this. On 1/31/08, Wolfgang Jeltsch <g9ks157k(a)acme.softbase.org> wrote: > Well, the representation (D1,D2,D9) might be considered more readable. It > has the disadvantage of a fixed maximum size for the numbers. Which takes > me to a point I had already considered some time ago: Wouldn't it be good > if we had just a type > > data Pair val1 val2 = Pair val1 val2 > > and if then (val1,val2,…,valn) would just be syntactic sugar for this: > > val1 `Pair` (val2 `Pair` (…(valn `Pair` ())…))

2 1