From adam.smyczek at gmail.com Thu May 1 02:28:50 2008 From: adam.smyczek at gmail.com (Adam Smyczek) Date: Thu May 1 02:23:17 2008 Subject: [Haskell-cafe] ANN: ReviewBoard 0.1 bindings Message-ID: This package is part of a development tool designed to monitor code changes, analyze dependencies etc. Actually, we are still in process to develop the tool and this binding is the first functional ready package others might be interested in as well. The package contains a basic set of API calls to ReviewBoard server and a small demo app, a command line tool that makes submitting new code review requests as easy as: svn diff | mkrr -r [reviewers] (ReviewBoard does not support darcs) :( For details see haddock documentation. The ReviewBoard project page: http://code.google.com/p/reviewboard/ And the bindings on hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/ ReviewBoard-0.1 A thanks to this list for help with this project and help in getting started with Haskell by following many good threads. Adam From devriese at cs.tcd.ie Thu May 1 08:09:32 2008 From: devriese at cs.tcd.ie (Edsko de Vries) Date: Thu May 1 08:04:01 2008 Subject: [Haskell-cafe] Understanding tail recursion and trees Message-ID: <20080501120932.GB29147@netsoc.tcd.ie> Hi, I am writing a simple compiler for a small DSL embedded in Haskell, and am struggling to identify and remove the source of a stack error when compiling larger examples. To understand the issues better, I was playing around with tail recursion on trees when I came across the following problem. Suppose we want to count the number of leaves in a tree. The obvious naive (non tail-recursive) will run out of stack space quickly on larger trees. To test this, I defined a function that generates left (gentreeL, code below) or right (gentreeR) biased trees, that look like * * / \ / \ * * * * / \ / \ * * * * . . . . n n respectively; that is, a tree of depth n, with on the right (or the left) leaves only). Now, we can define define two traversals: one that has a tail call for the left subtree, after having traversed the right (acountL, below); and one that has a tail call for the right subtree, after having traversed the left (acountR). I was expecting acountL to work on the left biased tree but not on the right biased tree -- and that assumption turned out to be correct. However, I was also expecting (by "duality" :) acountR to work on the right biased tree, but not on the left biased tree, whereas in fact it works on both! (Indeed, it works on reallybigtree3, which combines the left and right biased trees, as well.) Can anyone explain why this is happening? Why is acountR not running out of stack space on the left biased tree? Also, if this is quirk rather than something I can rely on, is there a way to write a function that can count the number of leaves in reallybigtree3 without running out of stack space? Thanks (code follows), Edsko > data Tree = Leaf Integer | Branch Tree Tree > -- naive count > ncount :: Tree -> Integer > ncount (Leaf _) = 1 > ncount (Branch t1 t2) = ncount t1 + ncount t2 > -- generate left-biased tree (right nodes are always single leaves) > gentreeL :: Integer -> Tree > gentreeL 0 = Leaf 0 > gentreeL n = Branch (gentreeL (n-1)) (Leaf 0) > > -- generate right-based tree (left nodes are always single leaves) > gentreeR :: Integer -> Tree > gentreeR 0 = Leaf 0 > gentreeR n = Branch (Leaf 0) (gentreeR (n-1)) > > -- test examples > reallybigtree1 = gentreeL 2000000 > reallybigtree2 = gentreeR 2000000 > reallybigtree3 = Branch (gentreeL 2000000) (gentreeR 2000000) > > -- count with tail calls for the left subtree > acountL :: Tree -> Integer -> Integer > acountL (Leaf _) acc = acc + 1 > acountL (Branch t1 t2) acc = acountL t1 $! (acountL t2 acc) > > -- count with tail calls for the right subtree > acountR :: Tree -> Integer -> Integer > acountR (Leaf _) acc = acc + 1 > acountR (Branch t1 t2) acc = acountR t2 $! (acountL t1 acc) From miguelimo38 at yandex.ru Thu May 1 08:24:29 2008 From: miguelimo38 at yandex.ru (Miguel Mitrofanov) Date: Thu May 1 08:19:02 2008 Subject: [Haskell-cafe] Understanding tail recursion and trees In-Reply-To: <20080501120932.GB29147@netsoc.tcd.ie> References: <20080501120932.GB29147@netsoc.tcd.ie> Message-ID: <3C1C20E0-6619-4A87-9326-B45E0CBE74AB@yandex.ru> Copy-paste approach's failed you. Hint: try removing acountL definition and compiling everything else. >> -- count with tail calls for the left subtree >> acountL :: Tree -> Integer -> Integer >> acountL (Leaf _) acc = acc + 1 >> acountL (Branch t1 t2) acc = acountL t1 $! (acountL t2 acc) >> >> >> -- count with tail calls for the right subtree >> acountR :: Tree -> Integer -> Integer >> acountR (Leaf _) acc = acc + 1 >> acountR (Branch t1 t2) acc = acountR t2 $! (acountL t1 acc) > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From devriese at cs.tcd.ie Thu May 1 08:32:37 2008 From: devriese at cs.tcd.ie (Edsko de Vries) Date: Thu May 1 08:27:03 2008 Subject: [Haskell-cafe] Re: Understanding tail recursion and trees Message-ID: <20080501123236.GC29147@netsoc.tcd.ie> Hi, Thanks to Miguel for pointing out my silly error. So at least my understanding of tail recursion is correct :) So then the question becomes: what *is* the best way to write this function? One version I can think of is > ecount :: [Tree] -> Integer -> Integer > ecount [] acc = acc > ecount (Leaf _ : ts) acc = ecount ts $! (acc + 1) > ecount (Branch t1 t2 : ts) acc = ecount (t1 : t2 : ts) acc which essentially maintains an explicit stack and runs on all trees. Are there better ways to do this? Thanks again and sorry for my mistake, Edsko From felipe.lessa at gmail.com Thu May 1 08:44:43 2008 From: felipe.lessa at gmail.com (Felipe Lessa) Date: Thu May 1 08:39:09 2008 Subject: [Haskell-cafe] Re: Understanding tail recursion and trees In-Reply-To: <20080501123236.GC29147@netsoc.tcd.ie> References: <20080501123236.GC29147@netsoc.tcd.ie> Message-ID: On Thu, May 1, 2008 at 9:32 AM, Edsko de Vries wrote: > So then the question becomes: what *is* the best way to write this function? I guess it would be simpler to have the counter on the data type and a smart branch constructor: > data Tree = Leaf Integer | Branch Integer Tree Tree > > count :: Tree -> Integer > count (Leaf _) = 1 > count (Branch c _ _) = c > > branch :: Tree -> Tree -> Tree > branch left right = Branch (count left + count right) left right > > gentreeL :: Integer -> Tree > gentreeL 0 = Leaf 0 > gentreeL n = branch (gentreeL (n-1)) (Leaf 0) etc. -- Felipe. From david.waern at gmail.com Thu May 1 09:42:19 2008 From: david.waern at gmail.com (David Waern) Date: Thu May 1 09:36:42 2008 Subject: [Haskell-cafe] ANN: Haddock version 2.1.0 Message-ID: Hi everyone, I'm pleased to announce Haddock 2.1.0. Hackage page: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/haddock-2.1.0 Changes since last version: * Fix a bug that made links point to the defining module instead of the "best" one (e.g Int pointing to GHC.Base instead of Data.Int) * Fix a couple of smaller bugs * The representation of DocName was changed in the library * Add a flag --no-warnings for turning off warnings David From wss at cs.nott.ac.uk Thu May 1 10:54:43 2008 From: wss at cs.nott.ac.uk (Wouter Swierstra) Date: Thu May 1 10:49:10 2008 Subject: [Haskell-cafe] Couple of formal questions In-Reply-To: <814617240804292014td3d79f9ve9f0e2345b851e2@mail.gmail.com> References: <814617240804292014td3d79f9ve9f0e2345b851e2@mail.gmail.com> Message-ID: <9729FF97-57A8-4B58-8447-4B78FFCEEE6B@cs.nott.ac.uk> Hi Creighton, > Where could I find a good treatment on data vs. codata & the > difference between well-founded recursion & well-founded(?) > corecursion? Bart Jacobs has some good papers on the subject. I found the draft of his book "Introduction to Coalgebra" quite good: http://www.cs.ru.nl/B.Jacobs/CLG/JacobsCoalgebraIntro.pdf > Where could I find a proof that the initial algebras & final > coalgebras of CPO coincide? I saw this referenced in the > "Bananas.." paper as a fact, but am not sure where this comes from. I couldn't find the statement you are referring to in "Functional Programming with Bananas, Lenses, Envelopes, and Barbed Wire" - but I'm not sure if this holds for every CPO. Having data and codata coincide is quite a curious property (I think it's sometimes called "algebraic compactness" - but don't quote me on this). Hope this helps, Wouter From matt at immute.net Thu May 1 11:10:55 2008 From: matt at immute.net (Matt Hellige) Date: Thu May 1 11:05:20 2008 Subject: [Haskell-cafe] Couple of formal questions In-Reply-To: <9729FF97-57A8-4B58-8447-4B78FFCEEE6B@cs.nott.ac.uk> References: <814617240804292014td3d79f9ve9f0e2345b851e2@mail.gmail.com> <9729FF97-57A8-4B58-8447-4B78FFCEEE6B@cs.nott.ac.uk> Message-ID: <5959041b0805010810k4eefaab2k172db83ae4a58627@mail.gmail.com> On Thu, May 1, 2008 at 9:54 AM, Wouter Swierstra wrote: > > > Where could I find a good treatment on data vs. codata & the difference > between well-founded recursion & well-founded(?) corecursion? > > > > Bart Jacobs has some good papers on the subject. I found the draft of his > book "Introduction to Coalgebra" quite good: > > http://www.cs.ru.nl/B.Jacobs/CLG/JacobsCoalgebraIntro.pdf > Indeed. I'd also recommend Varmo Vene's thesis, Categorical Programming with Inductive and Coinductive Types: http://www.cs.ut.ee/~varmo/papers/thesis.pdf Matt -- Matt Hellige / matt@immute.net http://matt.immute.net From adam.smyczek at gmail.com Thu May 1 11:34:44 2008 From: adam.smyczek at gmail.com (Adam Smyczek) Date: Thu May 1 11:29:12 2008 Subject: [Haskell-cafe] Haskell Web server In-Reply-To: <1ff5dedc0804250728y7c128270v23ecf62ad8c39ef7@mail.gmail.com> References: <1ff5dedc0804250728y7c128270v23ecf62ad8c39ef7@mail.gmail.com> Message-ID: <1841B69F-64FB-4C96-9421-EF06CE995914@gmail.com> A great step by step introduction: http://mult.ifario.us/p/wiring-haskell-into-a-fastcgi-web-server On Apr 25, 2008, at 7:28 AM, Cetin Sert wrote: > Hi, > > What is the fastest way to set up a web server that can redirect > requests to a haskell application and serve results returned by it? > > I need to demonstrate a simple visualization tool I have written > for analytic tableaux on Monday and need something easy and simple. > > Best Regards, > Cetin Sert > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From felipe.lessa at gmail.com Thu May 1 11:43:46 2008 From: felipe.lessa at gmail.com (Felipe Lessa) Date: Thu May 1 11:38:10 2008 Subject: [Haskell-cafe] Re: Understanding tail recursion and trees In-Reply-To: References: <20080501123236.GC29147@netsoc.tcd.ie> Message-ID: On Thu, May 1, 2008 at 9:44 AM, Felipe Lessa wrote: > On Thu, May 1, 2008 at 9:32 AM, Edsko de Vries wrote: > > So then the question becomes: what *is* the best way to write this function? > > I guess it would be simpler to have the counter on the data type and a > smart branch constructor: Under more careful analysis, it seems I just moved the stack overflow from the counter function to the generator =). Modifying the data type to > data Tree = Leaf Integer | Branch !Integer Tree Tree also won't work in this example (although it seems to fail earlier). However, I'd expect the data type above to work nicely with most real applications (that doesn't construct the entire tree in one go), such as Data.Map[1]. But the answer to your original question really seems to be using an explicit stack created in the heap. This technique is used in Data.Map in a certain case[2] and, although has received a lot of attention on a thread that sparked some time ago (I think it was [3]) for being merely a workaround over the limited stack, it seems to me it's a compulsory workaround for the time being when working with problems like yours. HTH, [1] http://haskell.org/ghc/docs/latest/html/libraries/containers/src/Data-Map.html#Map [2] http://haskell.org/ghc/docs/latest/html/libraries/containers/src/Data-Map.html#fromDistinctAscList [3] http://www.haskell.org/pipermail/haskell-cafe/2008-February/039104.html -- Felipe. From usenet at mkarcher.dialup.fu-berlin.de Thu May 1 11:58:43 2008 From: usenet at mkarcher.dialup.fu-berlin.de (Michael Karcher) Date: Thu May 1 11:53:29 2008 Subject: [Haskell-cafe] Re: Couple of formal questions References: <814617240804292014td3d79f9ve9f0e2345b851e2@mail.gmail.com> <9729FF97-57A8-4B58-8447-4B78FFCEEE6B@cs.nott.ac.uk> Message-ID: Wouter Swierstra wrote: > Hi Creighton, > > Where could I find a proof that the initial algebras & final > > coalgebras of CPO coincide? I saw this referenced in the > > "Bananas.." paper as a fact, but am not sure where this comes from. > I couldn't find the statement you are referring to in "Functional > Programming with Bananas, Lenses, Envelopes, and Barbed Wire" - but > I'm not sure if this holds for every CPO. Probably he was referring to the last paragraph of the introduction: Working in CPO has the advantage that the carriers of intial algebras and final co-algebras coincide, thus there is a single data type that comprises both finite and infinite elements. Regards, Michael Karcher From gwern0 at gmail.com Thu May 1 15:06:25 2008 From: gwern0 at gmail.com (Gwern Branwen) Date: Thu May 1 15:02:54 2008 Subject: [Haskell-cafe] ANN: Haddock version 2.1.0 In-Reply-To: References: Message-ID: <20080501190625.GB474@localhost> On 2008.05.01 15:42:19 +0200, David Waern scribbled 0.5K characters: > Hi everyone, > > I'm pleased to announce Haddock 2.1.0. > > Hackage page: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/haddock-2.1.0 > > Changes since last version: > > * Fix a bug that made links point to the defining module instead > of the "best" one (e.g Int pointing to GHC.Base instead of Data.Int) > > * Fix a couple of smaller bugs > > * The representation of DocName was changed in the library > > * Add a flag --no-warnings for turning off warnings > > David Out of curiosity: does this release fix the 'type'/--^ bug? I know I kept running into it on well-documented projects. -- gwern package Yakima Tzvrif Knife Tony Weekly Bob HRT TOS DJC -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080501/d4121dd6/attachment.bin From daniil.elovkov at googlemail.com Thu May 1 16:10:50 2008 From: daniil.elovkov at googlemail.com (Daniil Elovkov) Date: Thu May 1 16:05:16 2008 Subject: [Haskell-cafe] Re: Understanding tail recursion and trees In-Reply-To: References: <20080501123236.GC29147@netsoc.tcd.ie> Message-ID: <481A23CA.3020903@gmail.com> Felipe Lessa wrote: > On Thu, May 1, 2008 at 9:44 AM, Felipe Lessa wrote: >> On Thu, May 1, 2008 at 9:32 AM, Edsko de Vries wrote: >> > So then the question becomes: what *is* the best way to write this function? >> >> I guess it would be simpler to have the counter on the data type and a >> smart branch constructor: > > Under more careful analysis, it seems I just moved the stack overflow > from the counter function to the generator =). Modifying the data type > to > >> data Tree = Leaf Integer | Branch !Integer Tree Tree > > also won't work in this example (although it seems to fail earlier). > However, I'd expect the data type above to work nicely with most real > applications (that doesn't construct the entire tree in one go), such > as Data.Map[1]. > > But the answer to your original question really seems to be using an > explicit stack created in the heap. This technique is used in Data.Map > in a certain case[2] and, although has received a lot of attention on > a thread that sparked some time ago (I think it was [3]) for being > merely a workaround over the limited stack, it seems to me it's a > compulsory workaround for the time being when working with problems > like yours. > I think that consuming heap instead of stack is the best we can do. I may be wrong, but it seems to be more or less impossible to traverse a tree in constant memory. Well, if the tree structure doesn't have back links (apart from left, right). The thing is we have to remember nodes to return and remember if we went to the left or to the right. The left or right biased tree is just a list-like structure, where we don't have to remember anything, we can just proceed. That's why it easy to traverse them in constant memory. Maybe, in a C program we could traverse a tree without back links in constant memory by XORing pointers and left-right booleans. That would employ the property of xor that (a xor b) xor a = b. But I'm not sure. Well, anyway, that's not about Haskell. From graham.fawcett at gmail.com Thu May 1 16:40:13 2008 From: graham.fawcett at gmail.com (Graham Fawcett) Date: Thu May 1 16:34:38 2008 Subject: [Haskell-cafe] Writing an 'expect'-like program with runInteractiveCommand Message-ID: Hi folks, I would like to communicate with an external, line-oriented process, which takes a sequence of one-line commands, each returning an arbitrary number of lines, and waits for another command after each response. So, something like: sendCmd :: (Handle, Handle) -> String -> IO [String] ... main = do handles <- connectToExternalProcess sendCmd handles "do something" resp <- sendCmd "get results" -- needs strict I/O, before "quit"? sendCmd "quit" mapM_ putStrLn resp I've tried using runInteractiveCommand, and several combinations of hFlush, hWaitForInput, etc., but I can't find a combination that actually works. I know this is a sketchy description, but can anyone offer some sample code, or point me toward a program that has similar behaviour? Thanks, Graham From david.waern at gmail.com Thu May 1 16:43:45 2008 From: david.waern at gmail.com (David Waern) Date: Thu May 1 16:38:11 2008 Subject: [Haskell-cafe] ANN: Haddock version 2.1.0 In-Reply-To: <20080501190625.GB474@localhost> References: <20080501190625.GB474@localhost> Message-ID: No it doesn't, but it's on the TODO list. It needs a fix in GHC. By the way, I'm going to experiment with doing the parsing of comments on the Haddock side instead of in GHC. If that works out, we won't have to fix these things in GHC anymore. If anyone wants to help out with Haddock, the darcs repository is at http://code.haskell.org/haddock David 2008/5/1 Gwern Branwen : > On 2008.05.01 15:42:19 +0200, David Waern scribbled 0.5K characters: > > > > Hi everyone, > > > > I'm pleased to announce Haddock 2.1.0. > > > > Hackage page: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/haddock-2.1.0 > > > > Changes since last version: > > > > * Fix a bug that made links point to the defining module instead > > of the "best" one (e.g Int pointing to GHC.Base instead of Data.Int) > > > > * Fix a couple of smaller bugs > > > > * The representation of DocName was changed in the library > > > > * Add a flag --no-warnings for turning off warnings > > > > David > > Out of curiosity: does this release fix the 'type'/--^ bug? I know I kept running into it on well-documented projects. > > -- > gwern > package Yakima Tzvrif Knife Tony Weekly Bob HRT TOS DJC > From tmorris at tmorris.net Thu May 1 17:18:50 2008 From: tmorris at tmorris.net (Tony Morris) Date: Thu May 1 17:13:19 2008 Subject: [Haskell-cafe] Test.QuickCheck.Gen Message-ID: <481A33BA.1050304@tmorris.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I am trying to understand the QuickCheck source in a bit of depth and I have noted that a Gen x is a function Int -> StdGen -> x, however, some of the combinators can at times, fail to ever produce a result by throwing an error. I include an example using ghci: *Test.QuickCheck> (f 0 (mkStdGen 0)) :: Int *** Exception: Prelude.(!!): negative index It seems this can be alleviated by changing Gen x to Int -> StdGen -> Maybe x and having the generator produce Nothing when a combinator fails. However, now the function promote cannot be written (I have tried and run into the conundrum of writing the function (a -> Maybe b) -> Maybe (a -> b)), which is used to generate functions. So, I'm caught on the fence about whether there is a possible improvement here (for example, should the elements function throw the error?), or if the current scenario is acceptable. I'm seeking comments about this, thanks! - -- Tony Morris http://tmorris.net/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIGjO6mnpgrYe6r60RAtohAKCBsl1lHxuNrBaLHuqwCN58PBHCIACbBALk YWkBkw9o9NUQbr+lgo0rXE0= =JQlH -----END PGP SIGNATURE----- From haskell at list.mightyreason.com Thu May 1 18:29:31 2008 From: haskell at list.mightyreason.com (ChrisK) Date: Thu May 1 18:24:12 2008 Subject: [Haskell-cafe] Re: Writing an 'expect'-like program with runInteractiveCommand In-Reply-To: References: Message-ID: <481A444B.7030409@list.mightyreason.com> Are you adjusting 'System.IO.hSetBuffering' to NoBuffering for those handles? Graham Fawcett wrote: > Hi folks, > > I would like to communicate with an external, line-oriented process, > which takes a sequence of one-line commands, each returning an > arbitrary number of lines, and waits for another command after each > response. So, something like: > > sendCmd :: (Handle, Handle) -> String -> IO [String] > ... > > main = do > handles <- connectToExternalProcess > sendCmd handles "do something" > resp <- sendCmd "get results" -- needs strict I/O, before "quit"? > sendCmd "quit" > mapM_ putStrLn resp > > I've tried using runInteractiveCommand, and several combinations of > hFlush, hWaitForInput, etc., but I can't find a combination that > actually works. > > I know this is a sketchy description, but can anyone offer some sample > code, or point me toward a program that has similar behaviour? > > Thanks, > Graham From vigalchin at gmail.com Thu May 1 20:42:37 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Thu May 1 20:37:00 2008 Subject: [Haskell-cafe] elementary Maybe Monad problem .. sigh Message-ID: <5ae4f2ba0805011742j5f5d99e8gb1b7c85e5b6b5b57@mail.gmail.com> data Bozo = Bozo { id :: Int } bonzo :: Maybe Bozo -> IO () bonzo maybe_bozo = do if maybe_bozo == (Just (Bozo x)) then return () else return () ~ I want "x" to be a pattern that matches "id" .... ?? Kind regards, Vasili -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080501/27fc2e83/attachment.htm From claudiusmaximus at goto10.org Thu May 1 20:48:59 2008 From: claudiusmaximus at goto10.org (Claude Heiland-Allen) Date: Thu May 1 20:43:25 2008 Subject: [Haskell-cafe] elementary Maybe Monad problem .. sigh In-Reply-To: <5ae4f2ba0805011742j5f5d99e8gb1b7c85e5b6b5b57@mail.gmail.com> References: <5ae4f2ba0805011742j5f5d99e8gb1b7c85e5b6b5b57@mail.gmail.com> Message-ID: <481A64FB.4000407@goto10.org> Galchin, Vasili wrote: > > data Bozo = > Bozo { > id :: Int > } > > bonzo :: Maybe Bozo -> IO () > bonzo maybe_bozo = do > if maybe_bozo == (Just (Bozo x)) > then > return () > else > return () > ~ > > I want "x" to be a pattern that matches "id" .... ?? Try: bonzo (Just (Bozo x)) = return () bonzo Nothing = return () > Kind regards, Vasili Claude -- http://claudiusmaximus.goto10.org From lrpalmer at gmail.com Thu May 1 20:50:54 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Thu May 1 20:45:16 2008 Subject: [Haskell-cafe] elementary Maybe Monad problem .. sigh In-Reply-To: <5ae4f2ba0805011742j5f5d99e8gb1b7c85e5b6b5b57@mail.gmail.com> References: <5ae4f2ba0805011742j5f5d99e8gb1b7c85e5b6b5b57@mail.gmail.com> Message-ID: <7ca3f0160805011750k85e5c72y7336f6301e89abb9@mail.gmail.com> 2008/5/2 Galchin, Vasili : > > data Bozo = > Bozo { > id :: Int > } > > bonzo :: Maybe Bozo -> IO () > bonzo maybe_bozo = do > if maybe_bozo == (Just (Bozo x)) > then > return () > else > return () bonzo maybe_bozo = case maybe_bozo of Just (Bozo x) -> return () _ -> return () Or equivalently: bonzo (Just (Bozo x)) = return () bonzo _ = return () You should watch out for your use of id as a field name, since id is a builtin function and you will get ambiguity errors. Luke From vigalchin at gmail.com Thu May 1 21:18:43 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Thu May 1 21:13:13 2008 Subject: [Haskell-cafe] elementary Maybe Monad problem .. sigh In-Reply-To: <7ca3f0160805011750k85e5c72y7336f6301e89abb9@mail.gmail.com> References: <5ae4f2ba0805011742j5f5d99e8gb1b7c85e5b6b5b57@mail.gmail.com> <7ca3f0160805011750k85e5c72y7336f6301e89abb9@mail.gmail.com> Message-ID: <5ae4f2ba0805011818y2fb6ec38y53e4d46614076449@mail.gmail.com> Sorry .. my example was bad. I want to use "x" .. in then branch where it occur ... e.g. bonzo :: Maybe Bozo -> IO () bonzo maybe_bozo = do case maybe_bozo of Just (Bozo x) -> x ........ _ -> ......... ?? Thanks, V. On Thu, May 1, 2008 at 7:50 PM, Luke Palmer wrote: > 2008/5/2 Galchin, Vasili : > > > > data Bozo = > > Bozo { > > id :: Int > > } > > > > bonzo :: Maybe Bozo -> IO () > > bonzo maybe_bozo = do > > if maybe_bozo == (Just (Bozo x)) > > then > > return () > > else > > return () > > bonzo maybe_bozo = > case maybe_bozo of > Just (Bozo x) -> return () > _ -> return () > > Or equivalently: > > bonzo (Just (Bozo x)) = return () > bonzo _ = return () > > You should watch out for your use of id as a field name, since id is a > builtin function and you will get ambiguity errors. > > Luke > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080501/d727c001/attachment.htm From vigalchin at gmail.com Thu May 1 21:27:21 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Thu May 1 21:21:44 2008 Subject: [Haskell-cafe] elementary Maybe Monad problem .. sigh In-Reply-To: <5ae4f2ba0805011818y2fb6ec38y53e4d46614076449@mail.gmail.com> References: <5ae4f2ba0805011742j5f5d99e8gb1b7c85e5b6b5b57@mail.gmail.com> <7ca3f0160805011750k85e5c72y7336f6301e89abb9@mail.gmail.com> <5ae4f2ba0805011818y2fb6ec38y53e4d46614076449@mail.gmail.com> Message-ID: <5ae4f2ba0805011827t23f6cd9i7c3ea58e82a04482@mail.gmail.com> Here is a simpler case of what I want to do .. 1) To function1 pass in (Maybe Int). 2) If "Nothing" then pass nullPtr to C function. 3) If "Just 1", then pass a pointer to a "1" to teh same C function. Thanks, Vasili On Thu, May 1, 2008 at 8:18 PM, Galchin, Vasili wrote: > Sorry .. my example was bad. I want to use "x" .. in then branch where > it occur ... > > e.g. > bonzo :: Maybe Bozo -> IO () > bonzo maybe_bozo = do > case maybe_bozo of > Just (Bozo x) -> x ........ > _ -> ......... > > ?? > > Thanks, V. > > > On Thu, May 1, 2008 at 7:50 PM, Luke Palmer wrote: > > > 2008/5/2 Galchin, Vasili : > > > > > > data Bozo = > > > Bozo { > > > id :: Int > > > } > > > > > > bonzo :: Maybe Bozo -> IO () > > > bonzo maybe_bozo = do > > > if maybe_bozo == (Just (Bozo x)) > > > then > > > return () > > > else > > > return () > > > > bonzo maybe_bozo = > > case maybe_bozo of > > Just (Bozo x) -> return () > > _ -> return () > > > > Or equivalently: > > > > bonzo (Just (Bozo x)) = return () > > bonzo _ = return () > > > > You should watch out for your use of id as a field name, since id is a > > builtin function and you will get ambiguity errors. > > > > Luke > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080501/f10b6a6e/attachment.htm From dons at galois.com Thu May 1 21:48:57 2008 From: dons at galois.com (Don Stewart) Date: Thu May 1 21:43:21 2008 Subject: [Haskell-cafe] Announce: ghc-core, command line pager for reading GHC Core Message-ID: <20080502014857.GA1722@scytale.galois.com> Just a quick announcement, I've uploaded to hackage 'ghc-core' , a wrapper over ghc for displaying the optimised core and assembly language ghc produces from your programs. The code is colourised by hscolour, and displayed in a pager, git-log style. This will be useful for those who like looking at optimised Haskell. You can quickly get an idea of what kind of core and assembly your code is turning into, and the effect of various flags on the result. Usage: $ ghc-core Foo.hs $ ghc-core Foo.hs -optc-O2 -fvia-C Get it here, http://hackage.haskell.org/cgi-bin/hackage-scripts/package/ghc-core Screenshot, http://galois.com/~dons/images/ghc-core.png Cheers, Don From qdunkan at gmail.com Thu May 1 22:12:06 2008 From: qdunkan at gmail.com (Evan Laforge) Date: Thu May 1 22:06:31 2008 Subject: [Haskell-cafe] elementary Maybe Monad problem .. sigh In-Reply-To: <5ae4f2ba0805011827t23f6cd9i7c3ea58e82a04482@mail.gmail.com> References: <5ae4f2ba0805011742j5f5d99e8gb1b7c85e5b6b5b57@mail.gmail.com> <7ca3f0160805011750k85e5c72y7336f6301e89abb9@mail.gmail.com> <5ae4f2ba0805011818y2fb6ec38y53e4d46614076449@mail.gmail.com> <5ae4f2ba0805011827t23f6cd9i7c3ea58e82a04482@mail.gmail.com> Message-ID: <2518b95d0805011912v6a73d208mc4acf8753469035d@mail.gmail.com> 2008/5/1 Galchin, Vasili : > Here is a simpler case of what I want to do .. > > 1) To function1 pass in (Maybe Int). > > 2) If "Nothing" then pass nullPtr to C function. > > 3) If "Just 1", then pass a pointer to a "1" to teh same C function. Check out Foreign.maybeWith. From donn at avvanta.com Fri May 2 00:16:29 2008 From: donn at avvanta.com (Donn Cave) Date: Fri May 2 00:11:01 2008 Subject: [Haskell-cafe] Re: Writing an 'expect'-like program with runInteractiveCommand In-Reply-To: <481A444B.7030409@list.mightyreason.com> References: <481A444B.7030409@list.mightyreason.com> Message-ID: <8C5358FD-9099-432B-AEFD-3C4889EFA69C@avvanta.com> Graham Fawcett wrote: > I would like to communicate with an external, line-oriented process, > which takes a sequence of one-line commands, each returning an > arbitrary number of lines, and waits for another command after each > response. So, something like: > sendCmd :: (Handle, Handle) -> String -> IO [String] You may need to make some compromises to get this within the realm of the possible, if I understand your objective. - There is no way (at least on UNIX) to know when a read has been posted on the other end of your pipe/socket/pty/whatever. So you can't tell in this way when the external process has sent the last of the arbitrary number of lines and is now waiting for another command. If you have another way to know, or it doesn't really matter, then fine. - The vast majority of `line-oriented' software are actually going to block buffer their output when writing to a pipe, because that's what C I/O does. If you're lucky, the program you're dealing with here will flush its output before it reads, but if it doesn't, you're hosed - there isn't any way to talk to this program `interactively' on a pipe. In this case, you need a pseudotty device, a sort of pipe that supports tty device ioctls. - Buffering on your side of the I/O is of course also worse than useless. I see the GHC 6.8 library supports pseudottys, so for general amusement I submit below a small demonstration program. Unfortunately it doesn't entirely work. The pseudotty works, but I'm unable to turn off ECHO on the slave. So each master line yields two slave lines, and my program expects only one and gets behind on that account. So the command has to include its own "stty -echo". The commented lines attempt to turn of ECHO, but on MacOS X that causes the program to fail mysteriously. Donn Cave, donn@avvanta.com -------------------------------------------------- import System.Posix.Terminal (TerminalMode(..), TerminalState(..), withoutMode, getTerminalAttributes, setTerminalAttributes, openPseudoTerminal, getSlaveTerminalName) import System (getArgs) import System.Posix.Types (Fd, ProcessID) import System.Posix.Process (forkProcess, executeFile) import System.Posix.IO (stdInput, stdOutput, closeFd, dupTo, fdWrite, fdRead) pchild :: Fd -> IO () -> IO () pchild slaveFd exec = do dupTo slaveFd stdInput dupTo slaveFd stdOutput closeFd slaveFd exec ptyOpen :: IO () -> IO (ProcessID, Fd) ptyOpen exec = do (master, slave) <- openPseudoTerminal -- tc <- getTerminalAttributes slave -- let tc = withoutMode tc EchoLF -- setTerminalAttributes slave tc WhenDrained pid <- forkProcess (pchild slave exec) closeFd slave return (pid, master) ioact p0 p1 m0 m1 = do (d, n) <- fdRead m0 512 fdWrite p1 d (e, n) <- fdRead p0 512 fdWrite m1 e ioact p0 p1 m0 m1 main = do (cmd:args) <- getArgs (pid, fd) <- ptyOpen (executeFile cmd True args Nothing) ioact fd fd stdInput stdOutput From derek.a.elkins at gmail.com Fri May 2 01:12:19 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Fri May 2 01:06:46 2008 Subject: [Haskell-cafe] Re: Understanding tail recursion and trees In-Reply-To: <481A23CA.3020903@gmail.com> References: <20080501123236.GC29147@netsoc.tcd.ie> <481A23CA.3020903@gmail.com> Message-ID: <1209705139.5514.3.camel@derek-laptop> On Fri, 2008-05-02 at 00:10 +0400, Daniil Elovkov wrote: > Felipe Lessa wrote: > > On Thu, May 1, 2008 at 9:44 AM, Felipe Lessa wrote: > >> On Thu, May 1, 2008 at 9:32 AM, Edsko de Vries wrote: > >> > So then the question becomes: what *is* the best way to write this function? > >> > >> I guess it would be simpler to have the counter on the data type and a > >> smart branch constructor: > > > > Under more careful analysis, it seems I just moved the stack overflow > > from the counter function to the generator =). Modifying the data type > > to > > > >> data Tree = Leaf Integer | Branch !Integer Tree Tree > > > > also won't work in this example (although it seems to fail earlier). > > However, I'd expect the data type above to work nicely with most real > > applications (that doesn't construct the entire tree in one go), such > > as Data.Map[1]. > > > > But the answer to your original question really seems to be using an > > explicit stack created in the heap. This technique is used in Data.Map > > in a certain case[2] and, although has received a lot of attention on > > a thread that sparked some time ago (I think it was [3]) for being > > merely a workaround over the limited stack, it seems to me it's a > > compulsory workaround for the time being when working with problems > > like yours. > > > > I think that consuming heap instead of stack is the best we can do. > > I may be wrong, but it seems to be more or less impossible to traverse a > tree in constant memory. Well, if the tree structure doesn't have back > links (apart from left, right). > > The thing is we have to remember nodes to return and remember if we went > to the left or to the right. The left or right biased tree is just a > list-like structure, where we don't have to remember anything, we can > just proceed. That's why it easy to traverse them in constant memory. > > Maybe, in a C program we could traverse a tree without back links in > constant memory by XORing pointers and left-right booleans. That would > employ the property of xor that (a xor b) xor a = b. But I'm not sure. > > Well, anyway, that's not about Haskell. http://www.cs.indiana.edu/~jsobel/Recycling/recycling.html From ndmitchell at gmail.com Fri May 2 03:33:31 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Fri May 2 03:27:53 2008 Subject: [Haskell-cafe] Announce: ghc-core, command line pager for reading GHC Core In-Reply-To: <20080502014857.GA1722@scytale.galois.com> References: <20080502014857.GA1722@scytale.galois.com> Message-ID: <404396ef0805020033q74dfbad4qfb5bf1a425c3fa03@mail.gmail.com> Hi Don, > Just a quick announcement, I've uploaded to hackage 'ghc-core' , a > wrapper over ghc for displaying the optimised core and assembly language > ghc produces from your programs. This is cool, but it still lags behind the facilities found in yhc-core. http://yhc06.blogspot.com/2006/12/yhccorehtml.html I have found that any effort put into improving Core viewing tools repays itself rather quickly, and that HTML output with hyperlinks is incredibly handy! Thanks Neil From prstanley at ntlworld.com Fri May 2 03:43:34 2008 From: prstanley at ntlworld.com (PR Stanley) Date: Fri May 2 03:38:00 2008 Subject: [Haskell-cafe] Re: Function Type Calculation (Take 2) Message-ID: <7.0.1.0.0.20080502084159.01d2a3e0@ntlworld.com> Just in case anyone missed this: [1] funk f x = f (funk f) x f :: a x :: b funk f x :: c therefore funk :: a -> b -> c RHS f (funk f) x :: c f (funk f) :: d -> c x :: d f :: e -> d -> c funk :: h -> e f :: h unification f :: a = h = (e -> d -> c) x b = d No. x :: b = d (a typo?) Paul: What's wrong with x being of type b and of type d? Could you perhaps explain the error please? Don't forget also that funk :: a -> b -> c = h -> e, which means that e = b -> c Paul: is that something to do with partial application? (funk f) is a partially applied function, correct? Again an explanation would be appreciated. therefore funk :: ((h -> e) -> b -> c) -> b -> c No. I don't understand where you've got this expression from. It's funk :: a -> b -> c = (e -> d -> c) -> b -> c = ((b -> c) -> b -> c) - > b -> c According to GHCi: Prelude> let funk f x = f (funk f) x Prelude> :t funk funk :: ((t1 -> t) -> t1 -> t) -> t1 -> t which is about the same. Thanks Paul From thomas at 0xc29.net Fri May 2 05:58:54 2008 From: thomas at 0xc29.net (Thomas Girod) Date: Fri May 2 05:53:26 2008 Subject: [Haskell-cafe] sound synthesis Message-ID: <481AE5DE.2020003@0xc29.net> Hi there. Following this advice (http://reddit.com/info/6hknz/comments/c03vdc7), I'm posting here. Recently, I read a few articles about Haskell (and FP in general) and music/sound. I remember an article ranting about how lazy evaluation would be great to do signal processing, but it was lacking real world example. I tried to do a little something about it, even though I'm still an haskell apprentice. So, here I come with a small bit of code, waiting for your insights to improve it. The task is to generate a sine wave and pipe it to /dev/dsp on my linux box. There is probably a nicer way to make some noise, like using SDL audio API bindings, but I didn't take the time to poke around this yet. So here it is : > module Main where > import qualified Data.ByteString as B > import Data.Word > import IO (stdout) > rate = 44100 > sinusFloat :: [Float] > sinusFloat = map (\t -> (1 + sin (t*880*2*pi/rate)) / 2) [0..44099] > sinusWord :: [Word8] > sinusWord = map (\s -> floor (s * max)) sinusFloat > where max = 255 > byte = B.pack sinusWord > main = B.hPut stdout byte It is supposed to generate a 880hz sine wav playing for one second, by typing ./bin > /dev/dsp, assuming your soundcard has a 44100hz samplingrate. /dev/dsp is supposed to receive its audio flux as an unsigned byte stream, that's why I'm converting my sine from [-1;1] to [0;1] and then to [0;255] Word8. However, I must miss something because the sound does not have the right frequency and is played too long. I guess the default sound format is 44100hz 16bits stereo, which would explain why it doesn't behave as expected. I'm wondering how I could convert a [Word16] to ByteString, and how I could use lazy evaluation to generate an infinite sine that stops with the interupt. Thomas From lemming at henning-thielemann.de Fri May 2 06:22:22 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri May 2 06:15:20 2008 Subject: [Haskell-cafe] sound synthesis In-Reply-To: <481AE5DE.2020003@0xc29.net> References: <481AE5DE.2020003@0xc29.net> Message-ID: On Fri, 2 May 2008, Thomas Girod wrote: > Hi there. Following this advice > (http://reddit.com/info/6hknz/comments/c03vdc7), I'm posting here. > > > Recently, I read a few articles about Haskell (and FP in general) and > music/sound. > > I remember an article ranting about how lazy evaluation would be great to do > signal processing, but it was lacking real world example. There are some 'real world examples', however speed is currently the factor which limits the fun. Currently you get immediate results with the SuperCollider interface or with the CSound interface of Haskore: http://www.haskell.org/haskellwiki/Applications_and_libraries/Music_and_sound Cf. Haskell Art mailing list: http://lists.lurk.org/mailman/listinfo/haskell-art > I tried to do a little something about it, even though I'm still an haskell > apprentice. So, here I come with a small bit of code, waiting for your > insights to improve it. > > The task is to generate a sine wave and pipe it to /dev/dsp on my linux box. > There is probably a nicer way to make some noise, like using SDL audio API > bindings, but I didn't take the time to poke around this yet. > > So here it is : > >> module Main where > >> import qualified Data.ByteString as B >> import Data.Word >> import IO (stdout) > >> rate = 44100 > >> sinusFloat :: [Float] >> sinusFloat = map (\t -> (1 + sin (t*880*2*pi/rate)) / 2) [0..44099] > >> sinusWord :: [Word8] >> sinusWord = map (\s -> floor (s * max)) sinusFloat >> where max = 255 > >> byte = B.pack sinusWord > >> main = B.hPut stdout byte > > It is supposed to generate a 880hz sine wav playing for one second, by typing > ./bin > /dev/dsp, assuming your soundcard has a 44100hz samplingrate. > > /dev/dsp is supposed to receive its audio flux as an unsigned byte stream, > that's why I'm converting my sine from [-1;1] to [0;1] and then to [0;255] > Word8. > > However, I must miss something because the sound does not have the right > frequency and is played too long. I guess the default sound format is 44100hz > 16bits stereo, which would explain why it doesn't behave as expected. > > I'm wondering how I could convert a [Word16] to ByteString, With Data.Binary. > and how I could use lazy evaluation to generate an infinite sine that > stops with the interupt. So far I used a really silly way, but it worked for me so far: I start 'play' from SOX package and pipe my signal into it: http://darcs.haskell.org/synthesizer/src/Sox/Play.hs From claudiusmaximus at goto10.org Fri May 2 06:21:25 2008 From: claudiusmaximus at goto10.org (Claude Heiland-Allen) Date: Fri May 2 06:15:53 2008 Subject: [Haskell-cafe] sound synthesis In-Reply-To: <481AE5DE.2020003@0xc29.net> References: <481AE5DE.2020003@0xc29.net> Message-ID: <481AEB25.3050904@goto10.org> Thomas Girod wrote: > Hi there. Following this advice > (http://reddit.com/info/6hknz/comments/c03vdc7), I'm posting here. > > > Recently, I read a few articles about Haskell (and FP in general) and > music/sound. > > I remember an article ranting about how lazy evaluation would be great > to do signal processing, but it was lacking real world example. > > I tried to do a little something about it, even though I'm still an > haskell apprentice. So, here I come with a small bit of code, waiting > for your insights to improve it. > > The task is to generate a sine wave and pipe it to /dev/dsp on my linux > box. There is probably a nicer way to make some noise, like using SDL > audio API bindings, but I didn't take the time to poke around this yet. > > So here it is : > >> module Main where > >> import qualified Data.ByteString as B >> import Data.Word >> import IO (stdout) > >> rate = 44100 > >> sinusFloat :: [Float] >> sinusFloat = map (\t -> (1 + sin (t*880*2*pi/rate)) / 2) [0..44099] > >> sinusWord :: [Word8] >> sinusWord = map (\s -> floor (s * max)) sinusFloat >> where max = 255 > >> byte = B.pack sinusWord > >> main = B.hPut stdout byte > > It is supposed to generate a 880hz sine wav playing for one second, by > typing ./bin > /dev/dsp, assuming your soundcard has a 44100hz > samplingrate. > > /dev/dsp is supposed to receive its audio flux as an unsigned byte > stream, that's why I'm converting my sine from [-1;1] to [0;1] and then > to [0;255] Word8. > > However, I must miss something because the sound does not have the right > frequency and is played too long. I guess the default sound format is > 44100hz 16bits stereo, which would explain why it doesn't behave as > expected. Nope: The default is 8-bit unsigned samples, using one channel (mono), and an 8 kHz sampling rate. http://www.oreilly.de/catalog/multilinux/excerpt/ch14-05.htm Changing to rate = 8000 and sinusFloat = ... [0..rate-1] gives the expected output. > I'm wondering how I could convert a [Word16] to ByteString, and how I > could use lazy evaluation to generate an infinite sine that stops with > the interupt. > > Thomas Claude -- http://claudiusmaximus.goto10.org From jerzy.karczmarczuk at info.unicaen.fr Fri May 2 06:25:52 2008 From: jerzy.karczmarczuk at info.unicaen.fr (jerzy.karczmarczuk@info.unicaen.fr) Date: Fri May 2 06:20:14 2008 Subject: [Haskell-cafe] sound synthesis In-Reply-To: <481AE5DE.2020003@0xc29.net> References: <481AE5DE.2020003@0xc29.net> Message-ID: Thomas Girod: > Recently, I read a few articles about Haskell (and FP in general) and > music/sound. > > I remember an article ranting about how lazy evaluation would be great to > do signal processing, but it was lacking real world example. Check (e.g. through Google) what Henning Thielemann wrote about. I can offer you something written not in Haskell, but in Clean (the conversion to Haskell is largely trivial), see e.g. this PADL paper, I have it on-line: http://users.info.unicaen.fr/~karczma/arpap/cleasyn.pdf > The task is to generate a sine wave and pipe it to /dev/dsp on my linux > box. There is probably a nicer way to make some noise, like using SDL > audio API bindings, but I didn't take the time to poke around this yet. > I'm wondering how I could convert a [Word16] to ByteString, and how I > could use lazy evaluation to generate an infinite sine that stops with the > interupt. "Infinite sine that stops" is a bit contradictory. In my view the solution is the following. You generate your infinite whatever. Sine, Karplus-Strong sound, flute, whatever, you combine all in one infinite stream, and you don't care at all about stopping. [In Clean I used unboxed, spine-lazy, but head-strict lists. The format was floating-point]. THEN, during the conversion, piping, construction of a .wav table (vector) you think about the time-limitation of the stream. I played with static constraints (concrete number of converted samples). If you want to do it dynamically, then, either you know how to interrupt *any* infinite process within Haskell, or you have to learn how to do it... Here people more competent than myself will surely help you. Good luck, and thanks for your interest in a this fabulous field. Jerzy Karczmarczuk From david.waern at gmail.com Fri May 2 09:48:05 2008 From: david.waern at gmail.com (David Waern) Date: Fri May 2 09:42:26 2008 Subject: [Haskell] Re: [Haskell-cafe] ANN: Haddock version 2.1.0 In-Reply-To: <481A46C0.3050209@gmail.com> References: <20080501190625.GB474@localhost> <481A46C0.3050209@gmail.com> Message-ID: 2008/5/2 Simon Marlow : > David Waern wrote: > > > No it doesn't, but it's on the TODO list. It needs a fix in GHC. > > > > By the way, I'm going to experiment with doing the parsing of comments > > on the Haddock side instead of in GHC. > > If that works out, we won't have to fix these things in GHC anymore. > > > > Sounds great - along the lines that we discussed on cvs-ghc a while back? Yes, something along the lines of separately parsing the comments and recording their source locations, and then trying to match them with the source locations of the AST nodes. I don't think there are any lexical rules for where Haddock comments can exist, so it should work. David From graham.fawcett at gmail.com Fri May 2 09:55:28 2008 From: graham.fawcett at gmail.com (Graham Fawcett) Date: Fri May 2 09:49:50 2008 Subject: [Haskell-cafe] Re: Writing an 'expect'-like program with runInteractiveCommand In-Reply-To: <8C5358FD-9099-432B-AEFD-3C4889EFA69C@avvanta.com> References: <481A444B.7030409@list.mightyreason.com> <8C5358FD-9099-432B-AEFD-3C4889EFA69C@avvanta.com> Message-ID: On Fri, May 2, 2008 at 12:16 AM, Donn Cave wrote: > Graham Fawcett wrote: > > > > I would like to communicate with an external, line-oriented process, > > which takes a sequence of one-line commands, each returning an > > arbitrary number of lines, and waits for another command after each > > response. So, something like: > > sendCmd :: (Handle, Handle) -> String -> IO [String] > You may need to make some compromises to get this within the realm > of the possible, if I understand your objective. > - There is no way (at least on UNIX) to know when a read has been posted > on the other end of your pipe/socket/pty/whatever... Yes, and I should have realized this. After my post, I tried writing the same program in another language, and ran into the same problems. Thanks very much for the response. I'm going to play with your example, and see if I can make it work in this case (and if not, I will still learn from studying it!). In case it's of interest, I see that E.W. Karlsen wrote a series of articles (ten years ago!) on using Haskell to manage asynchronous processes, and included an "expect-like" tool in his UniForM Workbench: http://www.informatik.uni-bremen.de/~ewk/WB.html By the way, what I'm trying to do is to interact with a Berkeley XML database; there's no existing Haskell wrapper for its API, and for this particular task the cost of writing one is too high. I was going to interact with the 'dbxml' command-line utility as a poor-man's FFI. Given the issues you've raised, instead I might use a language that has an existing DBXML interface, and call that from Haskell (e.g. Python via MissingPy). Thanks again, Graham > So you can't tell in this > way when the external process has sent the last of the arbitrary number > of > lines and is now waiting for another command. If you have another way to > know, or it doesn't really matter, then fine. > > - The vast majority of `line-oriented' software are actually going to block > buffer > their output when writing to a pipe, because that's what C I/O does. If > you're > lucky, the program you're dealing with here will flush its output before > it reads, > but if it doesn't, you're hosed - there isn't any way to talk to this > program > `interactively' on a pipe. In this case, you need a pseudotty device, a > sort of > pipe that supports tty device ioctls. > > - Buffering on your side of the I/O is of course also worse than useless. > > I see the GHC 6.8 library supports pseudottys, so for general amusement > I submit below a small demonstration program. Unfortunately it doesn't > entirely work. The pseudotty works, but I'm unable to turn off ECHO on the > slave. So each master line yields two slave lines, and my program expects > only one and gets behind on that account. So the command has to include > its own "stty -echo". The commented lines attempt to turn of ECHO, but on > MacOS X that causes the program to fail mysteriously. > > Donn Cave, donn@avvanta.com > -------------------------------------------------- > import System.Posix.Terminal (TerminalMode(..), TerminalState(..), > withoutMode, getTerminalAttributes, setTerminalAttributes, > openPseudoTerminal, getSlaveTerminalName) > import System (getArgs) > import System.Posix.Types (Fd, ProcessID) > import System.Posix.Process (forkProcess, executeFile) > import System.Posix.IO (stdInput, stdOutput, closeFd, dupTo, fdWrite, > fdRead) > > pchild :: Fd -> IO () -> IO () > pchild slaveFd exec = do > dupTo slaveFd stdInput > dupTo slaveFd stdOutput > closeFd slaveFd > exec > > ptyOpen :: IO () -> IO (ProcessID, Fd) > ptyOpen exec = do > (master, slave) <- openPseudoTerminal > -- tc <- getTerminalAttributes slave > -- let tc = withoutMode tc EchoLF > -- setTerminalAttributes slave tc WhenDrained > pid <- forkProcess (pchild slave exec) > closeFd slave > return (pid, master) > > ioact p0 p1 m0 m1 = do > (d, n) <- fdRead m0 512 > fdWrite p1 d > (e, n) <- fdRead p0 512 > fdWrite m1 e > ioact p0 p1 m0 m1 > > main = do > (cmd:args) <- getArgs > (pid, fd) <- ptyOpen (executeFile cmd True args Nothing) > ioact fd fd stdInput stdOutput > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From a.biurvOir4 at asuhan.com Fri May 2 10:19:53 2008 From: a.biurvOir4 at asuhan.com (Kim-Ee Yeoh) Date: Fri May 2 10:14:14 2008 Subject: [Haskell-cafe] Couple of formal questions In-Reply-To: References: <814617240804292014td3d79f9ve9f0e2345b851e2@mail.gmail.com> <9729FF97-57A8-4B58-8447-4B78FFCEEE6B@cs.nott.ac.uk> Message-ID: <17020475.post@talk.nabble.com> I'm not sure there's a proof as such, more like a definitional absence of distinction between initiality and finality. In other words, the CPO framework is orthogonal to such extremality considerations. Perhaps someone here knows about work enriching CPOs in that direction. -- Kim-Ee Michael Karcher-7 wrote: > > Wouter Swierstra wrote: >> Hi Creighton, >> > Where could I find a proof that the initial algebras & final >> > coalgebras of CPO coincide? I saw this referenced in the >> > "Bananas.." paper as a fact, but am not sure where this comes from. > > Probably he was referring to the last paragraph of the introduction: > > Working in CPO has the advantage that the carriers of intial algebras > and final co-algebras coincide, thus there is a single data type that > comprises both finite and infinite elements. > -- View this message in context: http://www.nabble.com/Couple-of-formal-questions-tp16974927p17020475.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. From claus.reinke at talk21.com Fri May 2 10:35:37 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Fri May 2 10:30:06 2008 Subject: [Haskell] Re: [Haskell-cafe] ANN: Haddock version 2.1.0 References: <20080501190625.GB474@localhost><481A46C0.3050209@gmail.com> Message-ID: <012e01c8ac61$cc2f0d60$bf078351@cr3lt> > 2008/5/2 Simon Marlow : >> David Waern wrote: >> >> > No it doesn't, but it's on the TODO list. It needs a fix in GHC. >> > >> > By the way, I'm going to experiment with doing the parsing of comments >> > on the Haddock side instead of in GHC. >> > If that works out, we won't have to fix these things in GHC anymore. >> > >> >> Sounds great - along the lines that we discussed on cvs-ghc a while back? > > Yes, something along the lines of separately parsing the comments and > recording their source locations, and then > trying to match them with the source locations of the AST nodes. yay!-) i hope that the haddock-independent part (parsing, preserving, and accessing comments) becomes part of the GHC API in a form that would fix trac ticket #1886, then we could finally start writing (ghc) haskell source-to-source transformations without losing pragmas or comments! losing layout would still be a pain, but that could be dealt with later - at least the code would remain functional under some form of (pretty . id . parse). please keep us posted about your experiments, claus From qdunkan at gmail.com Fri May 2 11:22:21 2008 From: qdunkan at gmail.com (Evan Laforge) Date: Fri May 2 11:16:42 2008 Subject: [Haskell-cafe] sound synthesis In-Reply-To: <481AE5DE.2020003@0xc29.net> References: <481AE5DE.2020003@0xc29.net> Message-ID: <2518b95d0805020822u21870bf0u56a94e6ac93e7f83@mail.gmail.com> > I remember an article ranting about how lazy evaluation would be great to > do signal processing, but it was lacking real world example. The nyquist language does this. It's not haskell, but it does use lazy evaluation for signals. From david.waern at gmail.com Fri May 2 11:37:59 2008 From: david.waern at gmail.com (David Waern) Date: Fri May 2 11:32:19 2008 Subject: [Haskell] Re: [Haskell-cafe] ANN: Haddock version 2.1.0 In-Reply-To: <012e01c8ac61$cc2f0d60$bf078351@cr3lt> References: <20080501190625.GB474@localhost> <481A46C0.3050209@gmail.com> <012e01c8ac61$cc2f0d60$bf078351@cr3lt> Message-ID: 2008/5/2 Claus Reinke : > > > 2008/5/2 Simon Marlow : > > > > > David Waern wrote: > > > > > > > No it doesn't, but it's on the TODO list. It needs a fix in GHC. > > > > > > > > By the way, I'm going to experiment with doing the parsing of comments > > > > on the Haddock side instead of in GHC. > > > > If that works out, we won't have to fix these things in GHC anymore. > > > > > > > > > > Sounds great - along the lines that we discussed on cvs-ghc a while > back? > > > > > > > Yes, something along the lines of separately parsing the comments and > > recording their source locations, and then > > trying to match them with the source locations of the AST nodes. > > > > yay!-) i hope that the haddock-independent part (parsing, preserving, > and accessing comments) becomes part of the GHC API in a form that would > fix trac ticket #1886, then we could finally start writing (ghc) haskell > source-to-source transformations without losing pragmas or comments! > losing layout would still be a pain, but that could be dealt with > later - at least the code would remain functional under some > form of (pretty . id . parse). Hmm. When it comes Haddock, things are simpler than in a refactoring situation, since we don't need to know exactly where the comments appear in the concrete syntax. The original Haddock parser is very liberal in where you can place comments. For example, it doesn't matter if you place a comment before or after a comma in a record field list, it is still attached to the previous (or next, depending on the type of comment) field. I need to take another look at the grammar to confirm that this is true in general, though. But anyway, my plan was to do this entirely in Haddock, not do the "preserving" part that you mention, and not do anything to GHC. David David From byorgey at gmail.com Fri May 2 11:38:06 2008 From: byorgey at gmail.com (Brent Yorgey) Date: Fri May 2 11:32:27 2008 Subject: [Haskell-cafe] elementary Maybe Monad problem .. sigh In-Reply-To: <5ae4f2ba0805011818y2fb6ec38y53e4d46614076449@mail.gmail.com> References: <5ae4f2ba0805011742j5f5d99e8gb1b7c85e5b6b5b57@mail.gmail.com> <7ca3f0160805011750k85e5c72y7336f6301e89abb9@mail.gmail.com> <5ae4f2ba0805011818y2fb6ec38y53e4d46614076449@mail.gmail.com> Message-ID: <22fcbd520805020838v1a0264adtb99676b72ded8d5c@mail.gmail.com> 2008/5/1 Galchin, Vasili : > Sorry .. my example was bad. I want to use "x" .. in then branch where > it occur ... > > e.g. > bonzo :: Maybe Bozo -> IO () > bonzo maybe_bozo = do > case maybe_bozo of > Just (Bozo x) -> x ........ > _ -> ......... > > ?? > Sure, after pattern-matching on the x (using a case, or a top-level pattern match), you are free to use x in the resulting branch. For example: bonzo (Just (Bozo x)) = print (show x) >> return x -- or whatever bonzo Nothing = return () -Brent -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080502/d68c8d11/attachment.htm From byorgey at gmail.com Fri May 2 11:45:21 2008 From: byorgey at gmail.com (Brent Yorgey) Date: Fri May 2 11:39:40 2008 Subject: [Haskell-cafe] Re: Function Type Calculation (Take 2) In-Reply-To: <7.0.1.0.0.20080502084159.01d2a3e0@ntlworld.com> References: <7.0.1.0.0.20080502084159.01d2a3e0@ntlworld.com> Message-ID: <22fcbd520805020845m64057ed4gd15340c370209fdb@mail.gmail.com> > unification > f :: a = h = (e -> d -> c) > x b = d > > No. x :: b = d (a typo?) > Paul: What's wrong with x being of type b and of type d? > Could you perhaps explain the error please? > Nothing's wrong, you just forgot a ::, that is, you wrote x b = d instead of x :: b = d. > > > Don't forget also that > > funk :: a -> b -> c = h -> e, > > which means that e = b -> c > Paul: is that something to do with partial application? > (funk f) is a partially applied function, correct? Again an explanation > would be appreciated. > It's because function arrows associate to the right, so a -> b -> c is really shorthand for (a -> (b -> c)). If (a -> (b -> c)) = h -> e, then a = h and (b -> c) = e. -Brent -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080502/32e97ed3/attachment.htm From antonmuhin at gmail.com Fri May 2 14:00:28 2008 From: antonmuhin at gmail.com (anton muhin) Date: Fri May 2 13:54:52 2008 Subject: [Haskell-cafe] Understanding tail recursion and trees In-Reply-To: <20080501120932.GB29147@netsoc.tcd.ie> References: <20080501120932.GB29147@netsoc.tcd.ie> Message-ID: <5953a1d00805021100h4d00633en24b06842eaf2b5be@mail.gmail.com> Well, if you could change your data structure, probably something like this could work (in spirit of Daniil's response): module Main where data Tree = Tree { parent :: Maybe (Either Tree Tree) , left :: Maybe Tree , right :: Maybe Tree } buildTree :: (a -> (Maybe a, Maybe a)) -> a -> Tree buildTree f = buildTree' Nothing where buildTree' p a = let t = Tree { parent = p, left = mkP Left t l, right = mkP Right t r } in t where (l, r) = f a mkP f t v = fmap (buildTree' (Just $ f t)) v leftmost :: Tree -> Tree leftmost tree = maybe tree leftmost (left tree) up :: Tree -> Maybe Tree up tree = maybe Nothing (either Just up) (parent tree) next :: Tree -> Maybe Tree next tree = maybe (up tree) (Just . leftmost) (right tree) nodes :: Tree -> Int nodes = f 0 . Just . leftmost where f n = maybe n ((f $! (n + 1)) . next) mkBalanced :: Int -> Tree mkBalanced = buildTree f where f 0 = (Nothing, Nothing) f n = (Just (n - 1), Just (n - 1)) mkLeftist :: Int -> Tree mkLeftist = buildTree f where f 0 = (Nothing, Nothing) f n = (Just (n - 1), Nothing) mkRightist :: Int -> Tree mkRightist = buildTree f where f 0 = (Nothing, Nothing) f n = (Nothing, Just (n - 1)) test v = do putStrLn "..." print $ nodes v main = do test $ mkLeftist 2000000 test $ mkRightist 2000000 test $ mkBalanced 20 yours, anton. On Thu, May 1, 2008 at 4:09 PM, Edsko de Vries wrote: > Hi, > > I am writing a simple compiler for a small DSL embedded in Haskell, and > am struggling to identify and remove the source of a stack error when > compiling larger examples. To understand the issues better, I was > playing around with tail recursion on trees when I came across the > following problem. > > Suppose we want to count the number of leaves in a tree. The obvious > naive (non tail-recursive) will run out of stack space quickly on larger > trees. To test this, I defined a function that generates left (gentreeL, > code below) or right (gentreeR) biased trees, that look like > > * * > / \ / \ > * * * * > / \ / \ > * * * * > . . > . . > n n > > respectively; that is, a tree of depth n, with on the right (or the > left) leaves only). > > Now, we can define define two traversals: one that has a tail call for > the left subtree, after having traversed the right (acountL, below); and > one that has a tail call for the right subtree, after having traversed > the left (acountR). > > I was expecting acountL to work on the left biased tree but not on the > right biased tree -- and that assumption turned out to be correct. > However, I was also expecting (by "duality" :) acountR to work on the > right biased tree, but not on the left biased tree, whereas in fact it > works on both! (Indeed, it works on reallybigtree3, which combines the > left and right biased trees, as well.) > > Can anyone explain why this is happening? Why is acountR not running out > of stack space on the left biased tree? > > Also, if this is quirk rather than something I can rely on, is there a > way to write a function that can count the number of leaves in > reallybigtree3 without running out of stack space? > > Thanks (code follows), > > Edsko > > > data Tree = Leaf Integer | Branch Tree Tree > > > -- naive count > > ncount :: Tree -> Integer > > ncount (Leaf _) = 1 > > ncount (Branch t1 t2) = ncount t1 + ncount t2 > > > -- generate left-biased tree (right nodes are always single leaves) > > gentreeL :: Integer -> Tree > > gentreeL 0 = Leaf 0 > > gentreeL n = Branch (gentreeL (n-1)) (Leaf 0) > > > > -- generate right-based tree (left nodes are always single leaves) > > gentreeR :: Integer -> Tree > > gentreeR 0 = Leaf 0 > > gentreeR n = Branch (Leaf 0) (gentreeR (n-1)) > > > > -- test examples > > reallybigtree1 = gentreeL 2000000 > > reallybigtree2 = gentreeR 2000000 > > reallybigtree3 = Branch (gentreeL 2000000) (gentreeR 2000000) > > > > -- count with tail calls for the left subtree > > acountL :: Tree -> Integer -> Integer > > acountL (Leaf _) acc = acc + 1 > > acountL (Branch t1 t2) acc = acountL t1 $! (acountL t2 acc) > > > > -- count with tail calls for the right subtree > > acountR :: Tree -> Integer -> Integer > > acountR (Leaf _) acc = acc + 1 > > acountR (Branch t1 t2) acc = acountR t2 $! (acountL t1 acc) > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From keith at oreilly.com Fri May 2 16:00:44 2008 From: keith at oreilly.com (Keith Fahlgren) Date: Fri May 2 15:55:05 2008 Subject: [Haskell-cafe] [ANN] Next Bay FP Meeting: Bryan O'Sullivan on Concurrent and multicore programming in Haskell Message-ID: <481B72EC.3070502@oreilly.com> Hi, Our next BayFP meeting will be this Thursday, May 8th, 2008 at 7:30pm. We'll feature Bryan O'Sullivan on Concurrent and multicore programming in Haskell. Bryan is a co-author of the upcoming O'Reilly book Real World Haskell [http://book.realworldhaskell.org/]. (among all sorts of other snazzy endeavors) Talking about multicore is all the rage, so I expect folks to bring a lot of people! :-) Details here: http://www.bayfp.org/blog/2008/05/02/may-8th-meeting-bryan-osullivan-on-concurrent-and-multicore-programming-in-haskell/ Many thanks to Alex Payne at Twitter for hosting this month's meeting. They've been very supportive of BayFP and we appreciate their continued hosting. Twitter's address is: 164 South Park St San Francisco, CA 94107 Alex says: It's a building with a dark green door. People can just come on in and walk to their right to a large conference room. We'll start at 7:30pm. As always, this is a free event. If you want pizza, please select which type here (and bring a few $$s): Pizza Selection Form [http://bayfp.wufoo.com/forms/bryan-osullivan-bay-fp/] Keith From mads_lindstroem at yahoo.dk Fri May 2 16:31:59 2008 From: mads_lindstroem at yahoo.dk (Mads =?ISO-8859-1?Q?Lindstr=F8m?=) Date: Fri May 2 16:29:16 2008 Subject: [Haskell-cafe] Using Template Haskell to make type-safe database access Message-ID: <1209760319.4242.4.camel@localhost.localdomain> Hi, I was wondering if anybody had experimented with using Template Haskell (TH) and ordinary SQL to make type-safe database access? To clarify what I am thinking about I will sketch how it could be done. The TH function should take two inputs. SQL (as a string) and a database source name (DSN). It should return an IO action as output. The TH-function should: 1. Connect to the database using the DSN 2. Ask the database which types will be returned from the expression 3. Build an IO action which can be used to execute the SQL at run-time. The action could return the result as a (lazy) list. Due to step two we can make the returned values type-safe. Greetings, Mads Lindstr?m From midfield at gmail.com Fri May 2 21:13:48 2008 From: midfield at gmail.com (Ben) Date: Fri May 2 21:08:08 2008 Subject: [Haskell-cafe] castIOUArray and hPutArray redux Message-ID: <9157df230805021813lee5ddf1la5755eb7d128d537@mail.gmail.com> hi haskellers, have the issues with castIOUArray (and thus hGetArray, hPutArray) in Data.Array.IO discussed below been resolved? http://www.haskell.org/pipermail/libraries/2003-January/thread.html here is a (trivial) program which has rather unexpected behavior. (i'm switching to Data.Binary in the meantime.) import Data.Array.IO import System.IO (IOMode(..), openBinaryFile, hClose) dumpArray arr name = do h <- openBinaryFile name WriteMode w <- castIOUArray arr (l,u) <- getBounds w let len = u-1+1 hPutArray h w len hClose h return len loadArray name num = do arr <- newArray_ (1, num) h <- openBinaryFile name ReadMode read <- hGetArray h arr num if not(read == num) then error "Incorrect number of bytes read in from array!" else return arr len = 20 main = do arr <- newArray (1, len) 1::IO(IOUArray Int Int) size <- dumpArray arr "foo" arr2' <- loadArray "foo" size arr2 <- (castIOUArray arr2')::IO(IOUArray Int Int) e1 <- getElems arr e2 <- getElems arr2 print e1 print e2 print size print $ show (arr == arr2) best, b From dons at galois.com Fri May 2 21:16:32 2008 From: dons at galois.com (Don Stewart) Date: Fri May 2 21:10:55 2008 Subject: [Haskell-cafe] castIOUArray and hPutArray redux In-Reply-To: <9157df230805021813lee5ddf1la5755eb7d128d537@mail.gmail.com> References: <9157df230805021813lee5ddf1la5755eb7d128d537@mail.gmail.com> Message-ID: <20080503011632.GA17863@scytale.galois.com> midfield: > hi haskellers, > > have the issues with castIOUArray (and thus hGetArray, hPutArray) in > Data.Array.IO discussed below been resolved? > > http://www.haskell.org/pipermail/libraries/2003-January/thread.html > > here is a (trivial) program which has rather unexpected behavior. > (i'm switching to Data.Binary in the meantime.) Could you clarify what benefit the low level direct array IO has over Data.Binary? -- Don (thinking about how to best do IO for a new arrays library) From midfield at gmail.com Fri May 2 21:39:41 2008 From: midfield at gmail.com (Ben) Date: Fri May 2 21:34:01 2008 Subject: [Haskell-cafe] castIOUArray and hPutArray redux In-Reply-To: <20080503011632.GA17863@scytale.galois.com> References: <9157df230805021813lee5ddf1la5755eb7d128d537@mail.gmail.com> <20080503011632.GA17863@scytale.galois.com> Message-ID: <9157df230805021839x644fd2fan546cfeae36525acd@mail.gmail.com> hi there, i assume you're asking about benefits with respect to serialization? other than some performance hacks, probably none. there was no good reason for me to use hPutArray and the like, i just saw them in the API docs and decided to try them out -- and got burned! Data.Binary has worked great for me so far. take care, ben On 5/2/08, Don Stewart wrote: > midfield: > > > hi haskellers, > > > > have the issues with castIOUArray (and thus hGetArray, hPutArray) in > > Data.Array.IO discussed below been resolved? > > > > http://www.haskell.org/pipermail/libraries/2003-January/thread.html > > > > here is a (trivial) program which has rather unexpected behavior. > > (i'm switching to Data.Binary in the meantime.) > > > Could you clarify what benefit the low level direct array IO has over Data.Binary? > > -- Don (thinking about how to best do IO for a new arrays library) > From j.vimal at gmail.com Fri May 2 23:50:52 2008 From: j.vimal at gmail.com (Vimal) Date: Fri May 2 23:45:17 2008 Subject: [Haskell-cafe] [ANN] Next Bay FP Meeting: Bryan O'Sullivan on Concurrent and multicore programming in Haskell In-Reply-To: <481B72EC.3070502@oreilly.com> References: <481B72EC.3070502@oreilly.com> Message-ID: On 03/05/2008, Keith Fahlgren wrote: > Hi, > > > Our next BayFP meeting will be this Thursday, May 8th, 2008 at 7:30pm. > We'll feature Bryan O'Sullivan on Concurrent and multicore programming > in Haskell. Bryan is a co-author of the upcoming O'Reilly book Real Cant wait for the video! How long before the video comes up on the website? -- Vimal From bulat.ziganshin at gmail.com Sat May 3 01:31:44 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sat May 3 01:34:28 2008 Subject: [Haskell-cafe] castIOUArray and hPutArray redux In-Reply-To: <9157df230805021813lee5ddf1la5755eb7d128d537@mail.gmail.com> References: <9157df230805021813lee5ddf1la5755eb7d128d537@mail.gmail.com> Message-ID: <1637126257.20080503093144@gmail.com> Hello Ben, Saturday, May 3, 2008, 5:13:48 AM, you wrote: > have the issues with castIOUArray (and thus hGetArray, hPutArray) in > Data.Array.IO discussed below been resolved? there is alternative arrays library [1], where bounds are recalculated when casting [1] http://haskell.org/haskellwiki/Library/ArrayRef -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From dave at zednenem.com Sat May 3 02:21:40 2008 From: dave at zednenem.com (David Menendez) Date: Sat May 3 02:15:58 2008 Subject: [Haskell-cafe] Re: Understanding tail recursion and trees In-Reply-To: <481A23CA.3020903@gmail.com> References: <20080501123236.GC29147@netsoc.tcd.ie> <481A23CA.3020903@gmail.com> Message-ID: <49a77b7a0805022321w76935b0bl5be07e24d4441b46@mail.gmail.com> On Thu, May 1, 2008 at 4:10 PM, Daniil Elovkov wrote: > Felipe Lessa wrote: > > > On Thu, May 1, 2008 at 9:44 AM, Felipe Lessa > wrote: > > > > > On Thu, May 1, 2008 at 9:32 AM, Edsko de Vries > wrote: > > > > So then the question becomes: what *is* the best way to write this > function? > > > > > > I guess it would be simpler to have the counter on the data type and a > > > smart branch constructor: > > > > > > > Under more careful analysis, it seems I just moved the stack overflow > > from the counter function to the generator =). Modifying the data type > > to > > > > > > > data Tree = Leaf Integer | Branch !Integer Tree Tree > > > > > > > also won't work in this example (although it seems to fail earlier). > > However, I'd expect the data type above to work nicely with most real > > applications (that doesn't construct the entire tree in one go), such > > as Data.Map[1]. > > > > But the answer to your original question really seems to be using an > > explicit stack created in the heap. This technique is used in Data.Map > > in a certain case[2] and, although has received a lot of attention on > > a thread that sparked some time ago (I think it was [3]) for being > > merely a workaround over the limited stack, it seems to me it's a > > compulsory workaround for the time being when working with problems > > like yours. > > > > > > I think that consuming heap instead of stack is the best we can do. > > I may be wrong, but it seems to be more or less impossible to traverse a > tree in constant memory. Well, if the tree structure doesn't have back links > (apart from left, right). I think Huet's Zipper is intended to solve this sort of problem. data Path = Top | BranchL Path Tree | BranchR Tree Path type Zipper = (Path, Tree) openZipper :: Tree -> Zipper openZipper t = (Top, t) Conceptually the zipper is a tree with one subtree selected. You can move the selection point with the (partial) functions defined below. downL, downR, up :: Zipper -> Zipper downL (p, Branch l r) = (BranchL p r, l) downR (p, Branch l r) = (BranchR l p, r) up (BranchL p r, l) = (p, Branch l r) up (BranchR l p, r) = (p, Branch l r) Note that these functions just shuffle existing subtrees around. Depending on your traversal pattern, these can run in roughly constant space. Using the zipper, we can define functions that traverse the entire tree and return a new tree: number :: Tree -> Tree number t = down Top t 0 where down p (Leaf _) n = up p (Leaf n) $! n + 1 down p (Branch l r) n = down (BranchL p r) l n up Top t n = t up (BranchL p r) l n = down (BranchR l p) r n up (BranchR l p) r n = up p (Branch l r) n For something like counting, we can simplify considerably because we don't need to retain the already-traversed portion of the tree. acountZ :: Tree -> Integer acountZ t = down t [] 0 where down (Branch l r) p i = down l (r:p) i down (Leaf _) (p:ps) i = down p ps $! i + 1 down (Leaf _) [] i = i + 1 -- Dave Menendez From bd at fushizen.net Sat May 3 05:19:17 2008 From: bd at fushizen.net (Bryan Donlan) Date: Sat May 3 05:13:40 2008 Subject: [Haskell-cafe] Control.Exception.evaluate - 'correct definition' not so correct Message-ID: <20080503091917.GA5333@shion.is.fushizen.net> Hi all, After some discussion on #haskell I decided to bring this issue to haskell-cafe. GHC's documentation for Control.Exception.evaluate states: evaluate :: a -> IO a Forces its argument to be evaluated when the resultant IO action is executed. It can be used to order evaluation with respect to other IO operations; its semantics are given by evaluate x `seq` y ==> y evaluate x `catch` f ==> (return $! x) `catch` f evaluate x >>= f ==> (return $! x) >>= f Note: the first equation implies that (evaluate x) is not the same as (return $! x). A correct definition is evaluate x = (return $! x) >>= return However, if >>= is strict on its first argument, then this definition is no better than (return $! x). One might next consider: evaluate x = (return x) >>= (return $!) However, according to the monad laws, this is equivalent to: evaluate x = return $! x and we're back to where we started. Although GHC's implementation of IO is somewhat more relaxed about this, there is no guarentee that this will be the case in all IO implementations, or future versions of GHC, or different optimization flags, or... The best I've come up with so far is: evaluate x = newIORef (return $! x) >>= join . readIORef In any case, if >>= is to be guarenteed lazy, this ought to be documented somewhere (or is it?). Otherwise Control.Exception's docs should be updated to provide a more correct example and/or the caveat that >>= must not be left-strict for the example implementation to be correct. Thanks, Bryan Donlan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080503/c8447352/attachment.bin From apfelmus at quantentunnel.de Sat May 3 06:56:38 2008 From: apfelmus at quantentunnel.de (apfelmus) Date: Sat May 3 06:51:15 2008 Subject: [Haskell-cafe] Re: Control.Exception.evaluate - 'correct definition' not so correct In-Reply-To: <20080503091917.GA5333@shion.is.fushizen.net> References: <20080503091917.GA5333@shion.is.fushizen.net> Message-ID: Bryan Donlan wrote: > > evaluate x = (return $! x) >>= return > > However, if >>= is strict on its first argument, then this definition is > no better than (return $! x). According to the monad law f >>= return = f every (>>=) ought to be strict in its first argument, so it indeed seems that the implementation given in the documentation is wrong. Regards, apfelmus From jules at jellybean.co.uk Sat May 3 07:21:40 2008 From: jules at jellybean.co.uk (Jules Bean) Date: Sat May 3 07:16:02 2008 Subject: [Haskell-cafe] Re: Control.Exception.evaluate - 'correct definition' not so correct In-Reply-To: References: <20080503091917.GA5333@shion.is.fushizen.net> Message-ID: <481C4AC4.1000909@jellybean.co.uk> apfelmus wrote: > Bryan Donlan wrote: >> >> evaluate x = (return $! x) >>= return >> >> However, if >>= is strict on its first argument, then this definition is >> no better than (return $! x). > > According to the monad law > > f >>= return = f > > every (>>=) ought to be strict in its first argument, so it indeed seems > that the implementation given in the documentation is wrong. But it is known that the monad laws only apply up to some weaker equivalence than 'seq-equivalence'. This has been discussed here countless times by people who understand it better than me. As I understand the summary the "=" sign in the monad laws mean "represent identical actions, in terms of the effects produced and the result returned". A kind of observational-equivalence for monad execution, but weaker than direct equational equivalence in the presence of seq. (Some people view this as more of a bug in "seq" than in the monad laws) Jules From devriese at cs.tcd.ie Sat May 3 12:30:01 2008 From: devriese at cs.tcd.ie (Edsko de Vries) Date: Sat May 3 12:24:22 2008 Subject: [Haskell-cafe] Re: Understanding tail recursion and trees In-Reply-To: <49a77b7a0805022321w76935b0bl5be07e24d4441b46@mail.gmail.com> References: <20080501123236.GC29147@netsoc.tcd.ie> <481A23CA.3020903@gmail.com> <49a77b7a0805022321w76935b0bl5be07e24d4441b46@mail.gmail.com> Message-ID: <20080503163000.GA2192@netsoc.tcd.ie> Hi, > I think Huet's Zipper is intended to solve this sort of problem. > > data Path = Top | BranchL Path Tree | BranchR Tree Path > type Zipper = (Path, Tree) > > openZipper :: Tree -> Zipper > openZipper t = (Top, t) > > Conceptually the zipper is a tree with one subtree selected. You can > move the selection point with the (partial) functions defined below. > > downL, downR, up :: Zipper -> Zipper > downL (p, Branch l r) = (BranchL p r, l) > downR (p, Branch l r) = (BranchR l p, r) > up (BranchL p r, l) = (p, Branch l r) > up (BranchR l p, r) = (p, Branch l r) > > Note that these functions just shuffle existing subtrees around. > Depending on your traversal pattern, these can run in roughly constant > space. > > Using the zipper, we can define functions that traverse the entire > tree and return a new tree: > > number :: Tree -> Tree > number t = down Top t 0 > where > down p (Leaf _) n = up p (Leaf n) $! n + 1 > down p (Branch l r) n = down (BranchL p r) l n > > up Top t n = t > up (BranchL p r) l n = down (BranchR l p) r n > up (BranchR l p) r n = up p (Branch l r) n Please correct me if I'm wrong, but doesn't the the size of the zipper grow every time we move down the left branch? I.e., by the time we reach the leaf, we'll have a zipper (BranchL (BranchL ..)) of size the depth of the tree? Or am I missing something? Edsko From dave at zednenem.com Sat May 3 14:20:59 2008 From: dave at zednenem.com (David Menendez) Date: Sat May 3 14:15:17 2008 Subject: [Haskell-cafe] Re: Understanding tail recursion and trees In-Reply-To: <20080503163000.GA2192@netsoc.tcd.ie> References: <20080501123236.GC29147@netsoc.tcd.ie> <481A23CA.3020903@gmail.com> <49a77b7a0805022321w76935b0bl5be07e24d4441b46@mail.gmail.com> <20080503163000.GA2192@netsoc.tcd.ie> Message-ID: <49a77b7a0805031120r29ab2521m3160156c1f18b33@mail.gmail.com> On Sat, May 3, 2008 at 12:30 PM, Edsko de Vries wrote: > > > I think Huet's Zipper is intended to solve this sort of problem. > > > > data Path = Top | BranchL Path Tree | BranchR Tree Path > > type Zipper = (Path, Tree) > > > > openZipper :: Tree -> Zipper > > openZipper t = (Top, t) > > > > Conceptually the zipper is a tree with one subtree selected. You can > > move the selection point with the (partial) functions defined below. > > > > downL, downR, up :: Zipper -> Zipper > > downL (p, Branch l r) = (BranchL p r, l) > > downR (p, Branch l r) = (BranchR l p, r) > > up (BranchL p r, l) = (p, Branch l r) > > up (BranchR l p, r) = (p, Branch l r) > > > > Note that these functions just shuffle existing subtrees around. > > Depending on your traversal pattern, these can run in roughly constant > > space. > > > > Using the zipper, we can define functions that traverse the entire > > tree and return a new tree: > > > > number :: Tree -> Tree > > number t = down Top t 0 > > where > > down p (Leaf _) n = up p (Leaf n) $! n + 1 > > down p (Branch l r) n = down (BranchL p r) l n > > > > up Top t n = t > > up (BranchL p r) l n = down (BranchR l p) r n > > up (BranchR l p) r n = up p (Branch l r) n > > Please correct me if I'm wrong, but doesn't the the size of the zipper > grow every time we move down the left branch? I.e., by the time we reach > the leaf, we'll have a zipper (BranchL (BranchL ..)) of size the depth > of the tree? Or am I missing something? If there are no other references to the tree, then each time a new node in the zipper is created, the corresponding node in the original tree can be discarded. Typically, the garbage won't be collected immediately, so there will be some growth in actual memory usage, but this will be bounded. If there are other references to the tree, then the nodes in the original tree cannot be reclaimed. Even so, the zipper never grows in size beyond the longest path from root to leaf in the tree. -- Dave Menendez From keith at oreilly.com Sat May 3 14:43:37 2008 From: keith at oreilly.com (Keith Fahlgren) Date: Sat May 3 14:37:56 2008 Subject: [Haskell-cafe] [ANN] Next Bay FP Meeting: Bryan O'Sullivan on Concurrent and multicore programming in Haskell In-Reply-To: References: <481B72EC.3070502@oreilly.com> Message-ID: <481CB259.5030002@oreilly.com> On 5/2/08 8:50 PM, Vimal wrote: > On 03/05/2008, Keith Fahlgren wrote: >> Hi, >> >> >> Our next BayFP meeting will be this Thursday, May 8th, 2008 at 7:30pm. >> We'll feature Bryan O'Sullivan on Concurrent and multicore programming >> in Haskell. Bryan is a co-author of the upcoming O'Reilly book Real > > Cant wait for the video! How long before the video comes up on the website? We've typically been able to get videos up after about a week. Keith From nahuelrullo at gmail.com Sun May 4 02:12:41 2008 From: nahuelrullo at gmail.com (Nahuel Rullo) Date: Sun May 4 02:07:01 2008 Subject: [Haskell-cafe] Haskell PNG Writer Message-ID: Hi list, i am new in Haskell. I need to make images (PNG, JPEG) with haskell, if you can give me a tutorial, thanks! -- Nahuel Rullo From andrewcoppin at btinternet.com Sun May 4 04:47:31 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Sun May 4 04:41:47 2008 Subject: [Haskell-cafe] Haskell PNG Writer In-Reply-To: References: Message-ID: <481D7823.9010306@btinternet.com> Nahuel Rullo wrote: > Hi list, i am new in Haskell. I need to make images (PNG, JPEG) with > haskell, if you can give me a tutorial, thanks! > Gtk2hs has the ability to read and write PNG and JPEG images. Have a look at the Graphics.UI.Gtk.Gdk.Pixbuf module: http://www.haskell.org/gtk2hs/docs/gtk2hs-docs-0.9.12/Graphics-UI-Gtk-Gdk-Pixbuf.html Specifically, look at pixbufNewFromFile and pixbufSave. If you then take a look at the Graphics.UI.Gtk.Gdk.Drawable module, you'll see a bunch of functions for drawing onto a Pixbuf. (Alternatively you can use Cairo.) However, if you're trying to draw an algorithmically generated set of pixels, you'll probably want to manipulate the underlying bitmap directly. This is Not Fun. Take a look at the QuickDraw demo to see how it's done... HTH. From lrpalmer at gmail.com Sun May 4 05:03:26 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Sun May 4 04:57:44 2008 Subject: [Haskell-cafe] Haskell PNG Writer In-Reply-To: References: Message-ID: <7ca3f0160805040203yaf9217ch85fc2b1fbad7379@mail.gmail.com> SDL-image (http://hackage.haskell.org/cgi-bin/hackage-scripts/package/SDL-image-0.5.2) also supports this. Luke On Sun, May 4, 2008 at 12:12 AM, Nahuel Rullo wrote: > Hi list, i am new in Haskell. I need to make images (PNG, JPEG) with > haskell, if you can give me a tutorial, thanks! > > -- > Nahuel Rullo > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From hthiel.char at zonnet.nl Sun May 4 07:46:51 2008 From: hthiel.char at zonnet.nl (Hans van Thiel) Date: Sun May 4 07:43:09 2008 Subject: [Haskell-cafe] Haskell PNG Writer In-Reply-To: References: Message-ID: <1209901611.2792.3.camel@localhost.localdomain> On Sun, 2008-05-04 at 03:12 -0300, Nahuel Rullo wrote: > Hi list, i am new in Haskell. I need to make images (PNG, JPEG) with > haskell, if you can give me a tutorial, thanks! I don't know about jpeg, but for png (with Cairo) see: http://darcs.haskell.org/gtk2hs/docs/tutorial/Tutorial_Port/app1.xhtml Regards, Hans van Thiel From byorgey at gmail.com Sun May 4 07:57:12 2008 From: byorgey at gmail.com (Brent Yorgey) Date: Sun May 4 07:51:27 2008 Subject: [Haskell-cafe] Haskell PNG Writer In-Reply-To: References: Message-ID: <22fcbd520805040457o2e11b22cgfbb285879f3e5c6d@mail.gmail.com> On Sun, May 4, 2008 at 2:12 AM, Nahuel Rullo wrote: > Hi list, i am new in Haskell. I need to make images (PNG, JPEG) with > haskell, if you can give me a tutorial, thanks! > What kind of images do you need to make? -Brent -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080504/db27ec57/attachment.htm From amarquaye.ivan at hotmail.com Sun May 4 08:24:04 2008 From: amarquaye.ivan at hotmail.com (Ivan Amarquaye) Date: Sun May 4 08:18:19 2008 Subject: [Haskell-cafe] really difficult for a beginner like me... In-Reply-To: References: Message-ID: Hi everyone, this is my first posting on here and this was what drove me here and the quest to know more as i anticipate a lot of help and direction in this quite new and different environment haskell.I have this paper that i'm working on and need to solve these scenarios/ cases based on some sample codes: Scenarios/cases: 1) Allow words to be hyphenated and treat the hyphenated word as a single word (including the hyphen). 2) As for no. 2 but if the hyphen is the last character on a line treat the hyphenated word as a single word without the hyphen. 3) Treat a capitalised word (one or more capital letters) the same as lower case, i.e. only the lower case word appears in the index. 4) Treat a word ending in an ?s? as a plural and thus the same as the singular, i.e. only the singular appears in the index. 5) As for no. 5 but (a) treat suffix ?ss? as not a plural; and (b) treat the plural suffixes ?sses?, ?zzes?, ?oes?, ?xes?, ?shes?, ?ches? the same as the singular, i.e. without the ?es?, e.g. ?branches? (except for 4- and 5-letter plurals with suffices ?oes? and ?ches?, e.g. ?floes?, and 4-letter plural suffix ?xes?); and (c) treat the plural suffix ?ies? (except for 4-letter plurals, e.g. ?pies?) as the singular suffix ?y?. 6) Make the output more readable in the form of an index table. 7) Use an output file 8) Include a user-friendly menu by which the user can choose input and output file names. This is the code i'm supposed tomodify and in some cases create new functions to support.I also need some explanation as the various approaches in solving them.............................................................................................. The function makeIndex given a document produces a list of entries. Each entry is a word and a list of line numbers (for words > 4 letters) Type definitions: import Prelude -- hiding (Word) -- predefined Word hidden, so we can define ours -- type String = [Char] defined in Prelude type Doc = String type Line = String type Word = String -- our version makeIndex :: Doc -> [ ([Int], Word) ] A data-directed design considers a sequence of functions (i.e using composition operator ?.?) to transform the document of type, Doc, into an index of type, [ ([Int], Word) ]. splitUp the document, doc, into a list of lines, [Line]. numLines pairs each line with a line number, [(Int, Line)]. allNumWords splits lines into words and line no., [(Int, Word)]. sortLs sorts words into alphabetical order, [(Int, Word)]. makeLists makes a list for each line number, [([Int], Word)]. amalgamate nos. into a list of nos. for each word, [([Int], Word)]. shorten into a list for words > 4 letters, [([Int], Word)]. makeIndex = shorten . -- [([Int], Word)] -> [([Int], Word)] amalgamate . -- [([Int], Word)] -> [([Int], Word)] makeLists . -- [(Int, Word)] -> [([Int], Word)] sortLs . -- [(Int, Word)] -> [(Int, Word)] allNumWords . -- [(Int, Line)] -> [(Int, Word)] numLines . -- [Line] -> [(Int, Line)] splitUp -- Doc -> [Line] Last -- [a] -> [a ] splitUp function splitUp :: Doc -> [Line] splitUp [] = [] splitUp text = takeWhile (/='\n') text : -- first line (splitUp . -- splitup other lines dropWhile (==?\n?) . -- delete 1st newline(s) dropWhile (/='\n')) text -- other lines Example: splitUp ?hello world\n\nnext world? => [?hello world?, ?next world?] numLines function: numLines :: [Line] -> [(Int, Line)] numLines lines -- list of pairs of = zip [1 .. length lines] lines -- line no. & line Example: numLines [?hello world?, ?next world?] => [(1, ?hello world?), (2, ?next world?)] splitWords function: -- for each line -- a) split into words -- b) attach line no. to each word splitWords :: Line -> [Word] -- a) splitWords [ ] = [ ] splitWords line = takeWhile isLetter line : -- first word in line (splitWords . -- split other words dropWhile (not.isLetter && Last ==?-?) . -- delete separators dropWhile isLetter) line -- other words where isLetter ch = (?a?<=ch) && (ch<=?z?) || (?A?<=ch) && (ch<=?Z?) Example: splitWords ?hello world? => [?hello?, ?world?] allNumWords function: numWords :: (Int, Line) -> [(Int, Word)] -- b) numWords (number, line) = map addLineNum ( splitWords line) -- all line pairs where addLineNum word = (number, word) -- a pair allNumWords :: [(Int, Line)] -> [(Int, Word)] allNumWords = concat . map numWords -- doc pairs Examples: addLineNum ?hello? => (1, ?hello?) numWords (1, ?hello world?) => [(1, ?hello?), (1, ?world?)] allNumWords [(1, ?hello world?), (2, ?next world?)] => [(1, ?hello?), (1, ?world?), (2, ?next?), (2, ?world?)] SortLs function: sortLs :: [(Int, Word)] -> [(Int, Word)] sortLs [ ] = [ ] sortLs (a:x) = sortLs [b | b <- x, compare b a] -- sort 1st half ++ [a] ++ -- 1st in middle sortLs [b | b <- x, compare a b] -- sort 2nd half where compare (n1, w1) (n2, w2) = (w1 < w2) -- 1st word less || (w1 == w2 && n1 < n2) -- check no. Example: sortLs [(1, ?hello?), (1, ?world?), (2, ?next?), (2, ?world?)] => [(1, ?hello?), (2, ?next?), (1, ?world?), (2, ?world?)] makeLists function: makeLists :: [(Int, Word)] -> [([Int], Word)] makeLists = map mk -- all pairs where mk (num, word) = ([num], word) -- list of single no. Examples: mk (1, ?hello?) => ([1], ?hello?) makeLists [(1, ?hello?), (2, ?next?), (1, ?world?), (2, ?world?)] => [([1], ?hello?), ([2], ?next?), ([1], ?world?), ([2], ?world?)] Amalgamate function: amalgamate :: [([Int], Word)] -> [([Int], Word)] amalgamate [ ] = [ ] amalgamate [a] = [a] amalgamate ((n1, w1) : (n2, w2) : rest) -- pairs of pairs | w1 /= w2 = (n1, w1) : amalgamate ((n2, w2) : rest) | otherwise = amalgamate ((n1 ++ n2, w1) : rest) -- if words are same grow list of numbers Example: amalgamate [([1], ?hello?), ([2], ?next?), ([1], ?world?), ([2], ?world?)] => [([1], ?hello?), ([2], ?next?), ([1, 2], ?world?)] Shorten function: shorten :: [([Int], Word)] -> [([Int], Word)] shorten = filter long -- keep pairs >4 where long (num, word) = length word > 4 -- check word >4 Example: shorten [([1], ?hello?), ([2], ?next?), ([1, 2], ?world?)] => [([1], ?hello?), ([1, 2], ?world?)] _________________________________________________________________ Connect to the next generation of MSN Messenger? http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source=wlmailtagline -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080504/6d99c75c/attachment.htm From lrpalmer at gmail.com Sun May 4 08:53:24 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Sun May 4 08:47:42 2008 Subject: [Haskell-cafe] really difficult for a beginner like me... In-Reply-To: References: Message-ID: <7ca3f0160805040553m34cc441ekaf8a1d5feb82c@mail.gmail.com> 2008/5/4 Ivan Amarquaye : > Hi everyone, > > this is my first posting on here and this was what drove me here and the > quest to know more as i anticipate a lot of help and direction in this quite > new and different environment haskell.I have this paper that i'm working on > and need to solve these scenarios/ cases based on some sample codes: You might receive better help if you asked smaller, more specific questions. This looks like homework, and even if it's not, we are a homework-friendly crowd, meaning: nobody is going to write code for you. We will answer questions in words, point you to useful library functions, give you feedback on approaches you outline to us, etc. So break up the problem. Try no. 1 by yourself, and if you can't do it, then describe what you tried and how it didn't work. Giving an outline of how you think you should approach the problem from a purely functional perspective will help, so we can help you modify and correct that idea. The more thought you put in by yourself before asking us, the more you will get out of our responses. But be much more specific. I cannot answer a question this large. Luke From amarquaye.ivan at hotmail.com Sun May 4 09:36:25 2008 From: amarquaye.ivan at hotmail.com (Ivan Amarquaye) Date: Sun May 4 09:30:40 2008 Subject: [Haskell-cafe] really difficult for a beginner like me... In-Reply-To: <7ca3f0160805040553m34cc441ekaf8a1d5feb82c@mail.gmail.com> References: <7ca3f0160805040553m34cc441ekaf8a1d5feb82c@mail.gmail.com> Message-ID: thanks for the tip there....its been four gruesome days and i just don't seem to make any understanding of how to implement some changes or create some new functions due to the fact that im so new to Haskell and functional programming. For the very first case of allowing hyphenated words to be treated as single words i manged to successfully do that by adding to the definition of the splitWords function to also accept characters such as "-" and it worked perfectly after running it. The next case posed a headache for me as i have been on it for 3 days now. >From my understanding, it means in situations where your writing a sentence and you get to the end of the line while writing a word, you decide to put a hyphen there and continue on the other line. So the case demands that i allow sentences that end with hyphens and continue on the next line to drop the hyphen and be a single word on that same line without having to continue on the next line so this was how i foresee the input it in hugs: Input: makeIndex "these are the very same stuff they tell each-\nother" output: should be this: [[1]these],[[1]eachother]. 1 indicates they are on the same line and the others are left out as the index takes words greater than 4 characters and i have been struggling with this since. i tried on several counts to include in the splitwords function to dropWhile "-" is found in the words but it turned out an error.I also tried creating a new function to do that didnt succeed either can anybody help me out in this regard..... _________________________________________________________________ Explore the seven wonders of the world http://search.msn.com/results.aspx?q=7+wonders+world&mkt=en-US&form=QBRE -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080504/b6d55880/attachment.htm From prstanley at ntlworld.com Sun May 4 11:33:34 2008 From: prstanley at ntlworld.com (PR Stanley) Date: Sun May 4 11:27:46 2008 Subject: [Haskell-cafe] unapplying function definitions? Message-ID: <7.0.1.0.0.20080504163109.01d06a38@ntlworld.com> Hi What on earth is unapplying function definitions? The following is taken from chapter 13 of the Hutton book: "...when reasoning about programs, function definitions can be both applied from left to right and unapplied from right to left." Cheers Paul From tom.davie at gmail.com Sun May 4 11:52:50 2008 From: tom.davie at gmail.com (Thomas Davie) Date: Sun May 4 11:47:08 2008 Subject: [Haskell-cafe] unapplying function definitions? In-Reply-To: <7.0.1.0.0.20080504163109.01d06a38@ntlworld.com> References: <7.0.1.0.0.20080504163109.01d06a38@ntlworld.com> Message-ID: On 4 May 2008, at 17:33, PR Stanley wrote: > Hi > What on earth is unapplying function definitions? > The following is taken from chapter 13 of the Hutton book: > "...when reasoning about programs, function definitions can be both > applied from left to right and unapplied from right to left." Well, because of referential transparency, we can say that the left hand side of a function is exactly equal to the right hand side. Thus, we can instead of applying functions, and making progress towards a normal form, unapply them and get further away from a normal form... for example: 5 = head [5,6,7,8,9] = head ([5,6] ++ [7] ++ [8,9]) = head (([] ++ [5] ++ [6]) ++ [7] ++ [8,9]) ....... There are of course an infinite number of ways of doing this, so it's usually only interesting, if we have some reason for applying a specific expansion. Bob From prstanley at ntlworld.com Sun May 4 12:48:58 2008 From: prstanley at ntlworld.com (PR Stanley) Date: Sun May 4 12:43:09 2008 Subject: [Haskell-cafe] unapplying function definitions? In-Reply-To: References: <7.0.1.0.0.20080504163109.01d06a38@ntlworld.com> Message-ID: <7.0.1.0.0.20080504174712.01d13c50@ntlworld.com> >>Hi >>What on earth is unapplying function definitions? >>The following is taken from chapter 13 of the Hutton book: >>"...when reasoning about programs, function definitions can be both >>applied from left to right and unapplied from right to left." > >Well, because of referential transparency, we can say that the left >hand side of a function is exactly equal to the right hand side. >Thus, we can instead of applying functions, and making progress >towards a normal form, unapply them and get further away from a normal >form... for example: > >5 = head [5,6,7,8,9] = head ([5,6] ++ [7] ++ [8,9]) = head (([] ++ [5] >++ [6]) ++ [7] ++ [8,9]) ....... > >There are of course an infinite number of ways of doing this, so it's >usually only interesting, if we have some reason for applying a >specific expansion. > >>What is the normal form? From byorgey at gmail.com Sun May 4 13:03:18 2008 From: byorgey at gmail.com (Brent Yorgey) Date: Sun May 4 12:57:34 2008 Subject: [Haskell-cafe] unapplying function definitions? In-Reply-To: <7.0.1.0.0.20080504174712.01d13c50@ntlworld.com> References: <7.0.1.0.0.20080504163109.01d06a38@ntlworld.com> <7.0.1.0.0.20080504174712.01d13c50@ntlworld.com> Message-ID: <22fcbd520805041003v53b4d2fdne38795c8b42596e2@mail.gmail.com> On Sun, May 4, 2008 at 12:48 PM, PR Stanley wrote: > > Hi >>> What on earth is unapplying function definitions? >>> The following is taken from chapter 13 of the Hutton book: >>> "...when reasoning about programs, function definitions can be both >>> applied from left to right and unapplied from right to left." >>> >> >> Well, because of referential transparency, we can say that the left >> hand side of a function is exactly equal to the right hand side. >> Thus, we can instead of applying functions, and making progress >> towards a normal form, unapply them and get further away from a normal >> form... for example: >> >> 5 = head [5,6,7,8,9] = head ([5,6] ++ [7] ++ [8,9]) = head (([] ++ [5] >> ++ [6]) ++ [7] ++ [8,9]) ....... >> >> There are of course an infinite number of ways of doing this, so it's >> usually only interesting, if we have some reason for applying a >> specific expansion. >> >> What is the normal form? >>> >> Essentially, a normal form is an expression where there are no more function applications that can be evaluated. For example, the expression '5' is a normal form; 'succ 5' is not a normal form since the succ can be applied to the 5, producing the normal form 6. To give another example of what Hutton means, suppose we are given the function definition head (x:xs) = x Then if we have the expression 'head (1:2:[])', noting that this matches the left-hand side of the definition of head, we can apply that definition to produce the equivalent expression '1'. Given the expression '2', on the other hand, and noting that this matches the *right*-hand side of the definition of head, we can *unapply* the definition to produce the equivalent expression 'head (2:[4,5,6])' (for example). Applying a function definition (moving from the left side of the definition to the right side) brings us closer to a normal form, since there's one less function application. "Unapplying" a function definition (moving from the right side to the left side) moves us further away from normal form since we have introduced another function application. Of course, you would never want an evaluator to "unapply" functions in this way, but when reasoning about programs as humans, it can sometimes be useful in proving things. Does that help clear things up? -Brent -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080504/0a5c7959/attachment.htm From sebastian.sylvan at gmail.com Sun May 4 13:17:58 2008 From: sebastian.sylvan at gmail.com (Sebastian Sylvan) Date: Sun May 4 13:12:14 2008 Subject: [Haskell-cafe] really difficult for a beginner like me... In-Reply-To: References: <7ca3f0160805040553m34cc441ekaf8a1d5feb82c@mail.gmail.com> Message-ID: <3d96ac180805041017k15974ffeua2185a76c83ba7e4@mail.gmail.com> 2008/5/4 Ivan Amarquaye : > thanks for the tip there....its been four gruesome days and i just don't > seem to make any understanding of how to implement some changes or create > some new functions due to the fact that im so new to Haskell and functional > programming. > > For the very first case of allowing hyphenated words to be treated as > single words i manged to successfully do that by adding to the definition of > the splitWords function to also accept characters such as "-" and it worked > perfectly after running it. > > The next case posed a headache for me as i have been on it for 3 days now. > >From my understanding, it means in situations where your writing a > sentence and you get to the end of the line while writing a word, you > decide to put a hyphen there and continue on the other line. So the case > demands that i allow sentences that end with hyphens and continue on the > next line to drop the hyphen and be a single word on that same line without > having to continue on the next line so this was how i foresee the input it > in hugs: > > Input: > makeIndex "these are the very same stuff they tell each-\nother" > > output: > should be this: [[1]these],[[1]eachother]. 1 indicates they are on the > same line and the others are left out as the index takes words greater than > 4 characters and i have been struggling with this since. i tried on several > counts to include in the splitwords function to dropWhile "-" is found in > the words but it turned out an error.I also tried creating a new function to > do that didnt succeed either can anybody help me out in this regard..... > > There are many ways of doing this of course. Perhaps you need to write a function like so: -- fixes up hyphenated words fixupHyphens :: [ (Int, Word) ] -> [ (Int, Word ) ] fixupHyphens ( (line1, word1):(line2:word2):xs ) | ... check if word1 ends with hyphen and line2 /= line1 ... = ( line1, ... something .. ) : fixupHyphens xs | otherwise = (line1, word1):(line2:word2): fixupHyphens xs fixupHyphens xs = xs Then you can insert this function in the appropriate place in the makeIndex function (probably before sorting, as you depend on the words showing up in order). -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080504/c95c0f4e/attachment-0001.htm From iavor.diatchki at gmail.com Sun May 4 20:30:37 2008 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Sun May 4 20:24:52 2008 Subject: [Haskell-cafe] Re: Control.Exception.evaluate - 'correct definition' not so correct In-Reply-To: References: <20080503091917.GA5333@shion.is.fushizen.net> Message-ID: <5ab17e790805041730o33b378e4u74f4f1f9e813e72b@mail.gmail.com> Hello, On Sat, May 3, 2008 at 3:56 AM, apfelmus wrote: > Bryan Donlan wrote: > > > > > evaluate x = (return $! x) >>= return > > > > However, if >>= is strict on its first argument, then this definition is > > no better than (return $! x). > > > > According to the monad law > > f >>= return = f > > every (>>=) ought to be strict in its first argument, so it indeed seems > that the implementation given in the documentation is wrong. >From the monad law we can conclude only that "(>>= return)" is strict, not (>>=) in general. For example, (>>=) for the reader monad is not strict in its first argument: m >>= f = \r -> f (m r) r So, "(undefined >> return 2) = (return 2)" -Iavor From waterson at maubi.net Sun May 4 23:40:08 2008 From: waterson at maubi.net (Chris Waterson) Date: Sun May 4 23:34:56 2008 Subject: [Haskell-cafe] sound synthesis In-Reply-To: <481AE5DE.2020003@0xc29.net> References: <481AE5DE.2020003@0xc29.net> Message-ID: <5963FB45-9EE9-470D-AB38-17F20CC95436@maubi.net> On May 2, 2008, at 2:58 AM, Thomas Girod wrote: > I remember an article ranting about how lazy evaluation would be > great to do signal processing, but it was lacking real world example. I did something similar a few weeks ago. I used libmad to lazily decode an MP3 file and play it using OS/X's core audio. Here's that post, with links to the libmad bindings (which might be useful for you, even if the CoreAudio isn't.) chris http://www.haskell.org/pipermail/haskell-cafe/2008-March/040796.html From RossBoylan at stanfordalumni.org Sun May 4 23:40:47 2008 From: RossBoylan at stanfordalumni.org (Ross Boylan) Date: Sun May 4 23:44:17 2008 Subject: [Haskell-cafe] Parsec on TeX Message-ID: I am new to Haskell and Parsec, and am trying to understand both. I tried to follow the example of how to use Parsec to parse TeX begin/end groups, but can't get it to run. I'm using HUGS -98 on Debian. When I copied the code I got errors about unknown terms (reserved and braces). I've tried to get them from the lexer, but now get this error :load grammar.hsl ERROR "grammar.hsl":21 - Type error in explicitly typed binding *** Term : envEnd *** Type : String -> GenParser Char a [Char] *** Does not match : String -> Parser () Can anyone help me understand what the problem is? Here's the code the caused the above error; I believe the part after --TeX example is verbatim from the Parsec documentation. I picked haskell as the language for to lexer "arbitrarily." import Text.ParserCombinators.Parsec import qualified Text.ParserCombinators.Parsec.Token as P import Text.ParserCombinators.Parsec.Language(haskell) reserved = P.reserved haskell braces = P.braces haskell -- TeX example environment = do{ name <- envBegin ; environment ; envEnd name } <|> return () envBegin :: Parser String envBegin = do{ reserved "\\begin" ; braces (many1 letter) } envEnd :: String -> Parser () envEnd name = do{ reserved "\\end" ; braces (string name) } From allbery at ece.cmu.edu Sun May 4 23:58:52 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sun May 4 23:53:07 2008 Subject: [Haskell-cafe] Parsec on TeX In-Reply-To: References: Message-ID: <56D0B8BD-1E2A-450F-9B5E-9CCDB3C4C94A@ece.cmu.edu> On 2008 May 4, at 23:40, Ross Boylan wrote: > ERROR "grammar.hsl":21 - Type error in explicitly typed binding > *** Term : envEnd > *** Type : String -> GenParser Char a [Char] > *** Does not match : String -> Parser () Hugs is prone to error messages that obscure the problem. The trick here is to realize that the type "Parser ()" is the same as "GenParser Char a ()"; this then tells you that you have used a function that returns a [Char] (aka String) where a type () (Haskell's version of (void)) is expected. > envEnd :: String -> Parser () > envEnd name = do{ reserved "\\end" > ; braces (string name) > } Line 21 is "; braces (string name)"; it is producing a String, when you need a (). One fix is to add one more line: > envEnd :: String -> Parser () > envEnd name = do reserved "\\end" > braces (string name) > return () Another possible fix is to change the type of "envEnd" to "String -> Parser String"; this may depend on how it's used. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From dons at galois.com Mon May 5 00:00:44 2008 From: dons at galois.com (Don Stewart) Date: Sun May 4 23:55:01 2008 Subject: [Haskell-cafe] Parsec on TeX In-Reply-To: <56D0B8BD-1E2A-450F-9B5E-9CCDB3C4C94A@ece.cmu.edu> References: <56D0B8BD-1E2A-450F-9B5E-9CCDB3C4C94A@ece.cmu.edu> Message-ID: <20080505040044.GB15367@scytale.galois.com> allbery: > > On 2008 May 4, at 23:40, Ross Boylan wrote: > > >ERROR "grammar.hsl":21 - Type error in explicitly typed binding > >*** Term : envEnd > >*** Type : String -> GenParser Char a [Char] > >*** Does not match : String -> Parser () > > Hugs is prone to error messages that obscure the problem. The trick > here is to realize that the type "Parser ()" is the same as "GenParser > Char a ()"; this then tells you that you have used a function that > returns a [Char] (aka String) where a type () (Haskell's version of > (void)) is expected. Yeah, if you're on Debian it would make sense to install GHC -- its much more active, much faster, and supports more things. It's well maintained on Debian too. -- Don From derek.a.elkins at gmail.com Mon May 5 00:02:35 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Sun May 4 23:56:53 2008 Subject: [Haskell-cafe] Parsec on TeX In-Reply-To: References: Message-ID: <1209960155.5514.11.camel@derek-laptop> On Sun, 2008-05-04 at 20:40 -0700, Ross Boylan wrote: > I am new to Haskell and Parsec, and am trying to understand both. I tried > to follow the example of how to use Parsec to parse TeX begin/end groups, > but can't get it to run. I'm using HUGS -98 on Debian. > > When I copied the code I got errors about unknown terms (reserved and > braces). I've tried to get them from the lexer, but now get this error > :load grammar.hsl > ERROR "grammar.hsl":21 - Type error in explicitly typed binding > *** Term : envEnd > *** Type : String -> GenParser Char a [Char] > *** Does not match : String -> Parser () > > Can anyone help me understand what the problem is? > > Here's the code the caused the above error; I believe the part after --TeX > example is verbatim from the Parsec documentation. I picked haskell as the > language for to lexer "arbitrarily." > > import Text.ParserCombinators.Parsec > import qualified Text.ParserCombinators.Parsec.Token as P > import Text.ParserCombinators.Parsec.Language(haskell) > reserved = P.reserved haskell > braces = P.braces haskell > > > -- TeX example > environment = do{ name <- envBegin > ; environment > ; envEnd name > } > <|> return () > > envBegin :: Parser String > envBegin = do{ reserved "\\begin" > ; braces (many1 letter) > } > > envEnd :: String -> Parser () > envEnd name = do{ reserved "\\end" > ; braces (string name) > } braces returns, in this case, a string, so the type of envEnd is String -> Parser String. You can either change the type and add a return () to environment after envEnd or add a return () to envEnd. From RossBoylan at stanfordalumni.org Mon May 5 00:33:08 2008 From: RossBoylan at stanfordalumni.org (Ross Boylan) Date: Mon May 5 00:27:31 2008 Subject: [Haskell-cafe] Parsec on TeX In-Reply-To: <56D0B8BD-1E2A-450F-9B5E-9CCDB3C4C94A@ece.cmu.edu> References: <56D0B8BD-1E2A-450F-9B5E-9CCDB3C4C94A@ece.cmu.edu> Message-ID: <1209960860.8213.14.camel@corn.betterworld.us> On Sun, 2008-05-04 at 23:58 -0400, Brandon S. Allbery KF8NH wrote: > On 2008 May 4, at 23:40, Ross Boylan wrote: > > > ERROR "grammar.hsl":21 - Type error in explicitly typed binding > > *** Term : envEnd > > *** Type : String -> GenParser Char a [Char] > > *** Does not match : String -> Parser () > > Hugs is prone to error messages that obscure the problem. The trick > here is to realize that the type "Parser ()" is the same as "GenParser > Char a ()"; this then tells you that you have used a function that > returns a [Char] (aka String) where a type () (Haskell's version of > (void)) is expected. > > > envEnd :: String -> Parser () > > envEnd name = do{ reserved "\\end" > > ; braces (string name) > > } > > > Line 21 is "; braces (string name)"; it is producing a String, when > you need a (). One fix is to add one more line: > > > envEnd :: String -> Parser () > > envEnd name = do reserved "\\end" > > braces (string name) > > return () > > Another possible fix is to change the type of "envEnd" to "String -> > Parser String"; this may depend on how it's used. First, I'm really impressed with the fast and helpful responses from several people! So the example is wrong? What inference should I draw about the state of Parsec and its documentation? I was thinking of trying Frost et al's X-SAIGA, but that the better documentation for parsec would be a plus. I had thought HUGS made more sense for fiddling around, but it seems all I'm doing is loading files anyway. What is the style people use for this exploratory work? I've already installed haskell-mode for emacs and ghc6, but it's not clear to me to what extent the former servers as a development environment rather than just a language formatter. Thanks. From dons at galois.com Mon May 5 00:38:06 2008 From: dons at galois.com (Don Stewart) Date: Mon May 5 00:32:21 2008 Subject: [Haskell-cafe] Parsec on TeX In-Reply-To: <1209960860.8213.14.camel@corn.betterworld.us> References: <56D0B8BD-1E2A-450F-9B5E-9CCDB3C4C94A@ece.cmu.edu> <1209960860.8213.14.camel@corn.betterworld.us> Message-ID: <20080505043806.GC15367@scytale.galois.com> > I had thought HUGS made more sense for fiddling around, but it seems all > I'm doing is loading files anyway. What is the style people use for > this exploratory work? I've already installed haskell-mode for emacs > and ghc6, but it's not clear to me to what extent the former servers as > a development environment rather than just a language formatter. GHCi makes a great exploratory tool (and then you have the option of compiling the code as well). There are some nice integration tools with emacs and vim, but its also good to gain familiarity with ghci, the online documentation on haskell.org, and perhaps even drop by the #haskell IRC channel. Cheers, Don From allbery at ece.cmu.edu Mon May 5 00:52:20 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Mon May 5 00:46:34 2008 Subject: [Haskell-cafe] Parsec on TeX In-Reply-To: <1209960860.8213.14.camel@corn.betterworld.us> References: <56D0B8BD-1E2A-450F-9B5E-9CCDB3C4C94A@ece.cmu.edu> <1209960860.8213.14.camel@corn.betterworld.us> Message-ID: On 2008 May 5, at 0:14, Ross Boylan wrote: > So the example is wrong? What inference should I draw about the state > of Parsec and its documentation? I was thinking of trying Frost et > al's > X-SAIGA, but that the better documentation for parsec would be a plus. The original documentation which you will probably find via Google is several years out of date; unfortunately, nobody has updated it and the newer API documentation lacks most of the actual details of how to *use* Parsec --- so really you need to have daan's Parsec paper and the Haskell library API documentation ( http://www.haskell.org/ghc/docs/latest/html/libraries/parsec/Text-ParserCombinators-Parsec.html ) open at the same time to see how things have changed. I will note that a newer version of Parsec is in development; I am hoping it will have somewhat better documentation (preferably an updated version of the original Parsec paper). > I had thought HUGS made more sense for fiddling around, but it seems > all > I'm doing is loading files anyway. What is the style people use for > this exploratory work? I've already installed haskell-mode for emacs > and ghc6, but it's not clear to me to what extent the former servers > as > a development environment rather than just a language formatter. ghci (the interpreter component of GHC) works much like hugs but is much more up to date; there are a number of useful libraries which either haven't been ported to or simply don't work with Hugs. (The new Parsec is one of these, as it works with the ByteString library (much faster than standard Strings, which are naive linked lists of characters); ByteString really needs to be compiled and Hugs is only an interpreter.) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From allbery at ece.cmu.edu Mon May 5 00:57:10 2008 From: allbery at ece.cmu.edu (Brandon S.Allbery KF8NH) Date: Mon May 5 00:51:23 2008 Subject: [Haskell-cafe] Parsec on TeX In-Reply-To: References: <56D0B8BD-1E2A-450F-9B5E-9CCDB3C4C94A@ece.cmu.edu> <1209960860.8213.14.camel@corn.betterworld.us> Message-ID: <70F727F0-8E86-492C-938A-24E2F36A04B9@ece.cmu.edu> I will add one more comment: perhaps the biggest thing Haskell has going for it has nothing to do with the language itself; as you noticed, it's the community. One might expect to find crusty mathematicians and dubiously social geeks(*), but in fact the Haskell community is one of the friendliest and most helpful I've encountered anywhere. (*) ironically, the person saying this is both dubiously social and an even crustier system administrator :) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From derek.a.elkins at gmail.com Mon May 5 00:59:14 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Mon May 5 00:53:34 2008 Subject: [Haskell-cafe] Parsec on TeX In-Reply-To: <1209960860.8213.14.camel@corn.betterworld.us> References: <56D0B8BD-1E2A-450F-9B5E-9CCDB3C4C94A@ece.cmu.edu> <1209960860.8213.14.camel@corn.betterworld.us> Message-ID: <1209963555.5514.27.camel@derek-laptop> On Sun, 2008-05-04 at 21:33 -0700, Ross Boylan wrote: > On Sun, 2008-05-04 at 23:58 -0400, Brandon S. Allbery KF8NH wrote: > > On 2008 May 4, at 23:40, Ross Boylan wrote: > > > > > ERROR "grammar.hsl":21 - Type error in explicitly typed binding > > > *** Term : envEnd > > > *** Type : String -> GenParser Char a [Char] > > > *** Does not match : String -> Parser () > > > > Hugs is prone to error messages that obscure the problem. The trick > > here is to realize that the type "Parser ()" is the same as "GenParser > > Char a ()"; this then tells you that you have used a function that > > returns a [Char] (aka String) where a type () (Haskell's version of > > (void)) is expected. > > > > > envEnd :: String -> Parser () > > > envEnd name = do{ reserved "\\end" > > > ; braces (string name) > > > } > > > > > > Line 21 is "; braces (string name)"; it is producing a String, when > > you need a (). One fix is to add one more line: > > > > > envEnd :: String -> Parser () > > > envEnd name = do reserved "\\end" > > > braces (string name) > > > return () > > > > Another possible fix is to change the type of "envEnd" to "String -> > > Parser String"; this may depend on how it's used. > > First, I'm really impressed with the fast and helpful responses from > several people! > > So the example is wrong? What inference should I draw about the state > of Parsec and its documentation? I was thinking of trying Frost et al's > X-SAIGA, but that the better documentation for parsec would be a plus. Parsec is currently maintained, but wasn't maintained for quite a while (admittedly, it didn't really require much maintenance; it was certainly rampantly used during that time.) Daan's paper on Parsec that you are reading/read is probably the best tutorial-like introduction. The reference documentation has been Haddock-ed for the newer version of Parsec (which you are almost certainly not using, but it is still very similar.) http://hackage.haskell.org/packages/archive/parsec/3.0.0/doc/html/Text-Parsec.html Unfortunately, Daan seems to have disappeared off of the face of the internet so there isn't anything that can be done about fixing that documentation (and likely that is in large part why this error is still there.) From lrpalmer at gmail.com Mon May 5 01:22:51 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Mon May 5 01:17:03 2008 Subject: [Haskell-cafe] Parsec on TeX In-Reply-To: References: Message-ID: <7ca3f0160805042222u8d7bf85yd7a6b11d93f992c1@mail.gmail.com> On Mon, May 5, 2008 at 3:40 AM, Ross Boylan wrote: > I am new to Haskell and Parsec, and am trying to understand both. I tried > to follow the example of how to use Parsec to parse TeX begin/end groups, > but can't get it to run. I'm using HUGS -98 on Debian. > > When I copied the code I got errors about unknown terms (reserved and > braces). I've tried to get them from the lexer, but now get this error > :load grammar.hsl > ERROR "grammar.hsl":21 - Type error in explicitly typed binding > *** Term : envEnd > *** Type : String -> GenParser Char a [Char] > *** Does not match : String -> Parser () > > Can anyone help me understand what the problem is? > > Here's the code the caused the above error; I believe the part after --TeX > example is verbatim from the Parsec documentation. I picked haskell as the > language for to lexer "arbitrarily." > > import Text.ParserCombinators.Parsec > import qualified Text.ParserCombinators.Parsec.Token as P > import Text.ParserCombinators.Parsec.Language(haskell) > reserved = P.reserved haskell > braces = P.braces haskell > > > -- TeX example > environment = do{ name <- envBegin > ; environment > ; envEnd name > } > <|> return () > > envBegin :: Parser String > envBegin = do{ reserved "\\begin" > ; braces (many1 letter) > } > > envEnd :: String -> Parser () > envEnd name = do{ reserved "\\end" > ; braces (string name) > } My guess is the following: string :: String -> Parser String braces :: Parser a -> Parser a Meaning braces (string name) :: Parser String Which is not the same as your declared return type Parser (). Add a return () at the end of envEnd. > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From RossBoylan at stanfordalumni.org Mon May 5 02:57:23 2008 From: RossBoylan at stanfordalumni.org (Ross Boylan) Date: Mon May 5 02:51:46 2008 Subject: [Haskell-cafe] Parsec on TeX In-Reply-To: <1209963555.5514.27.camel@derek-laptop> References: <56D0B8BD-1E2A-450F-9B5E-9CCDB3C4C94A@ece.cmu.edu> <1209960860.8213.14.camel@corn.betterworld.us> <1209963555.5514.27.camel@derek-laptop> Message-ID: <1209970643.8213.18.camel@corn.betterworld.us> On Sun, 2008-05-04 at 23:59 -0500, Derek Elkins wrote: > Unfortunately, Daan seems to have disappeared off of the face of the > internet so there isn't anything that can be done about fixing that > documentation (and likely that is in large part why this error is > still > there.) > http://research.microsoft.com/users/daan/index.html ? From bit at mutantlemon.com Mon May 5 03:00:00 2008 From: bit at mutantlemon.com (Bit Connor) Date: Mon May 5 02:54:13 2008 Subject: [Haskell-cafe] Ann: Win32-notify 0.1 In-Reply-To: References: <480B6DBD.9030609@serpentine.com> Message-ID: <6205bd290805050000i2c6ce1c6n61fd0f2834423a9e@mail.gmail.com> > Factor has a file system notification API that wraps windows, linux > and mac ones. It might be worth taking a look at that to see what it > does. Mono also has such an API and I've heard very good things about it. It would also be worth looking at. From bit at mutantlemon.com Mon May 5 03:05:50 2008 From: bit at mutantlemon.com (Bit Connor) Date: Mon May 5 03:00:03 2008 Subject: [Haskell-cafe] Haskell PNG Writer In-Reply-To: References: Message-ID: <6205bd290805050005x7bf26ce6uea5dffcc3afd4d75@mail.gmail.com> It would be nice to have haskell bindings to the libpng C library. I had trouble calling libpng functions since it uses setjmp for error handling, and it wasn't clear that haskell could handle this. I ended up writing a few wrapper functions in C. An alternative more ambitious project would be a pure haskell PNG implementation. On Sat, May 3, 2008 at 11:12 PM, Nahuel Rullo wrote: > Hi list, i am new in Haskell. I need to make images (PNG, JPEG) with > haskell, if you can give me a tutorial, thanks! > > -- > Nahuel Rullo > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From bjorn at bringert.net Mon May 5 03:10:25 2008 From: bjorn at bringert.net (Bjorn Bringert) Date: Mon May 5 03:04:38 2008 Subject: [Haskell-cafe] Haskell PNG Writer In-Reply-To: <6205bd290805050005x7bf26ce6uea5dffcc3afd4d75@mail.gmail.com> References: <6205bd290805050005x7bf26ce6uea5dffcc3afd4d75@mail.gmail.com> Message-ID: The libgd bindings can be used to create PNG images. See http://hackage.haskell.org/cgi-bin/hackage-scripts/package/gd /Bj?rn On Mon, May 5, 2008 at 9:05 AM, Bit Connor wrote: > It would be nice to have haskell bindings to the libpng C library. I > had trouble calling libpng functions since it uses setjmp for error > handling, and it wasn't clear that haskell could handle this. I ended > up writing a few wrapper functions in C. An alternative more ambitious > project would be a pure haskell PNG implementation. > > > > On Sat, May 3, 2008 at 11:12 PM, Nahuel Rullo wrote: > > Hi list, i am new in Haskell. I need to make images (PNG, JPEG) with > > haskell, if you can give me a tutorial, thanks! > > > > -- > > Nahuel Rullo From andrewcoppin at btinternet.com Mon May 5 03:59:59 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Mon May 5 03:54:14 2008 Subject: [Haskell-cafe] A common pattern Message-ID: <481EBE7F.9070802@btinternet.com> I've found myself writing code like this several times now. Is there a better way? read_args h = do line <- hGetLine h case line of "." -> return [] ('#':y) -> do ys <- read_args h return (y:ys) From ndmitchell at gmail.com Mon May 5 04:11:23 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon May 5 04:05:34 2008 Subject: [Haskell-cafe] A common pattern In-Reply-To: <481EBE7F.9070802@btinternet.com> References: <481EBE7F.9070802@btinternet.com> Message-ID: <404396ef0805050111oa663859r988414cb67642c53@mail.gmail.com> Hi > I've found myself writing code like this several times now. Is there a > better way? hGetContents might be a different way to write a similar thing: read_args h = do src <- hGetContents h let (has,rest) = span ("#" `isPrefixOf`) $ lines src return (map tail has) Of course, depending on exactly the kind of IO control you need to do, it may not work. Thanks Neil From andrewcoppin at btinternet.com Mon May 5 04:11:46 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Mon May 5 04:06:02 2008 Subject: [Haskell-cafe] Parsec on TeX In-Reply-To: <1209960860.8213.14.camel@corn.betterworld.us> References: <56D0B8BD-1E2A-450F-9B5E-9CCDB3C4C94A@ece.cmu.edu> <1209960860.8213.14.camel@corn.betterworld.us> Message-ID: <481EC142.3070500@btinternet.com> Ross Boylan wrote: > First, I'm really impressed with the fast and helpful responses from > several people! > Ask an easy question and you'll get at least a dozen people tripping over each other in their rush to offer you useful advice. Ask a hard question, or an uninteresting question, and enjoy the utter silence... :-( Still, I suppose that's not *too* surprising. > I had thought HUGS made more sense for fiddling around, but it seems all > I'm doing is loading files anyway. What is the style people use for > this exploratory work? I've already installed haskell-mode for emacs > and ghc6, but it's not clear to me to what extent the former servers as > a development environment rather than just a language formatter. > I used to use Hugs as well. Then I updated to the newest version, and found it horrifically buggy. That's when I moved over to GHC. As Don said, GHCi doesn't let you define new functions like Hugs does, but other than that it's far more useful. (And actually, you *can* define small functions using 'let'. It's just awkward.) Best thing is, you can compile your code with GHC, and then load that compiled code into GHCi so it runs at near-native speed. And of course, the latest version of GHCi now comes with an actual debugger. And GHC-compiled binaries have a profiler. And... [This was a while ago; maybe Hugs has been updated again since I last looked. Certainly Hugs is smaller to download, and more friendly to use than GHC. But it just doesn't have the same power...] From andrewcoppin at btinternet.com Mon May 5 04:15:08 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Mon May 5 04:09:22 2008 Subject: [Haskell-cafe] A common pattern In-Reply-To: <404396ef0805050111oa663859r988414cb67642c53@mail.gmail.com> References: <481EBE7F.9070802@btinternet.com> <404396ef0805050111oa663859r988414cb67642c53@mail.gmail.com> Message-ID: <481EC20C.5080603@btinternet.com> Neil Mitchell wrote: > Hi > > >> I've found myself writing code like this several times now. Is there a >> better way? >> > > hGetContents might be a different way to write a similar thing: > > read_args h = do > src <- hGetContents h > let (has,rest) = span ("#" `isPrefixOf`) $ lines src > return (map tail has) > > Of course, depending on exactly the kind of IO control you need to do, > it may not work. > Yeah, I was thinking about that. I'm not sure if I could get it to work. It's reading from a network socket, not a file, and I think I might need to be able to explicitly close it. (What happens if the other end closes? Do I get an exception or just the end of the string?) I might possibly be able to just use hGetContents and run a parser lazily over the result, we'll see. I know there's a few monad-related functions that I don't know about. I was curios to see if any of them help in this instance... From johan.tibell at gmail.com Mon May 5 05:03:17 2008 From: johan.tibell at gmail.com (Johan Tibell) Date: Mon May 5 04:57:29 2008 Subject: [Haskell-cafe] ANN: ReviewBoard 0.1 bindings In-Reply-To: References: Message-ID: <90889fe70805050203v81d02c9hf9c8a8c5a7d08d70@mail.gmail.com> On Thu, May 1, 2008 at 8:28 AM, Adam Smyczek wrote: > This package is part of a development tool designed to monitor code changes, > analyze dependencies etc. Actually, we are still in process to develop the > tool > and this binding is the first functional ready package others might be Cool! I've been planning to start using reviewboard for a while now so this is a nice addition to my tool chain for when I do. -- Johan From abhay.parvate at gmail.com Mon May 5 05:24:51 2008 From: abhay.parvate at gmail.com (Abhay Parvate) Date: Mon May 5 05:19:05 2008 Subject: [Haskell-cafe] A common pattern In-Reply-To: <481EC20C.5080603@btinternet.com> References: <481EBE7F.9070802@btinternet.com> <404396ef0805050111oa663859r988414cb67642c53@mail.gmail.com> <481EC20C.5080603@btinternet.com> Message-ID: <3c4d5adf0805050224mdfcb8an3d264b2c05f9a573@mail.gmail.com> Hi Andrew, I don't know whether it's intentional, but the patterns for "case line of" are not exaustive. Are you sure you do not expect anything else apart from a single "." or a line starting with '#'? More below: On Mon, May 5, 2008 at 1:45 PM, Andrew Coppin wrote: > Neil Mitchell wrote: > > > hGetContents might be a different way to write a similar thing: > > > > read_args h = do > > src <- hGetContents h > > let (has,rest) = span ("#" `isPrefixOf`) $ lines src > > return (map tail has) > > > > Of course, depending on exactly the kind of IO control you need to do, > > it may not work. > > > > Please correct me if I am wrong; but the rest of the contents from the handle h will be unavailable after the evaluation of this function: it goes into a semi-closed state. (Correctly so: 'src' is supposed to have the entire contents obtained from h if needed.) Another minor observation: if the partial pattern in the original code was intentional, then this is not exactly the same. what about read_args' :: [String] -> ([String],[String]) read_args' src = span ("#" `isPrefixOf`) $ lines src and then using s <- hGetContents let (arg, rest) = read_args' $ lines s ... So that you can get both the result and the remaining list of lines, in case you need them. Again, this does not exactly stop where there is a "." on a single line; it stops as soon as it gets a line without a '#'. Abhay -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080505/18359abc/attachment.htm From apfelmus at quantentunnel.de Mon May 5 06:17:13 2008 From: apfelmus at quantentunnel.de (apfelmus) Date: Mon May 5 06:11:43 2008 Subject: [Haskell-cafe] Re: Parsec on TeX In-Reply-To: <20080505040044.GB15367@scytale.galois.com> References: <56D0B8BD-1E2A-450F-9B5E-9CCDB3C4C94A@ece.cmu.edu> <20080505040044.GB15367@scytale.galois.com> Message-ID: Don Stewart wrote: > Yeah, if you're on Debian it would make sense to install GHC -- its much > more active, much faster, and supports more things. [than Hugs] Except for compile and load time, Hugs is really fast there. Regards, apfelmus From andrewcoppin at btinternet.com Mon May 5 06:29:04 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Mon May 5 06:23:14 2008 Subject: [Haskell-cafe] A common pattern In-Reply-To: <3c4d5adf0805050224mdfcb8an3d264b2c05f9a573@mail.gmail.com> References: <481EBE7F.9070802@btinternet.com> <404396ef0805050111oa663859r988414cb67642c53@mail.gmail.com> <481EC20C.5080603@btinternet.com> <3c4d5adf0805050224mdfcb8an3d264b2c05f9a573@mail.gmail.com> Message-ID: <481EE170.1030000@btinternet.com> Abhay Parvate wrote: > Hi Andrew, > > I don't know whether it's intentional, but the patterns for "case line > of" are not exaustive. Are you sure you do not expect anything else > apart from a single "." or a line starting with '#'? It's reading a wire protocol, so if you hit anything else there's been a protocol error. Arguably I should probably catch this case and report it gracefully. But really, there isn't much you could usefully do in this situation. > Please correct me if I am wrong; but the rest of the contents from the > handle h will be unavailable after the evaluation of this function: it > goes into a semi-closed state. (Correctly so: 'src' is supposed to > have the entire contents obtained from h if needed.) > Quite so. If I was going with this approach, I'd have to call hGetContents and then parse the entire stream and act on it. For my current application, which is basically a server that receives requests and then replies to them, I *think* you could possibly do that. If, however, there were to be some command that said "hey, disregard everything I just said, and switch to this new parsing mode..." then I'd have a problem implementing that this way. From andrewcoppin at btinternet.com Mon May 5 06:30:50 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Mon May 5 06:25:00 2008 Subject: [Haskell-cafe] Re: Parsec on TeX In-Reply-To: References: <56D0B8BD-1E2A-450F-9B5E-9CCDB3C4C94A@ece.cmu.edu> <20080505040044.GB15367@scytale.galois.com> Message-ID: <481EE1DA.60608@btinternet.com> apfelmus wrote: > Don Stewart wrote: >> Yeah, if you're on Debian it would make sense to install GHC -- its much >> more active, much faster, and supports more things. [than Hugs] > > Except for compile and load time, Hugs is really fast there. Mmm, possibly. I seem to recall it being instantaneous on my old AMD K6 500MHz with both Hugs and GHCi. But it was a while ago... Certainly only Hugs as the nice feature of automatically reloading your source every time you hit save. I really miss that in GHCi. [OTOH, if you're going to do this, expect lots of "hey, this doesn't parse!" type messages. undefined is your friend!] From barsoap at web.de Mon May 5 07:39:20 2008 From: barsoap at web.de (Achim Schneider) Date: Mon May 5 07:33:44 2008 Subject: [Haskell-cafe] Grokking monads by not overlooking concatMap Message-ID: <20080505133920.5d0f26bc@solaris> guard True = return () guard False = [] -- the textbook example f = do x <- [1..4] y <- [2..8] guard (x*y==8) return (x,y) -- the translation. f' = [1..4] >>= (\x -> [2..8] >>= (\y -> (if (x*y == 8) then return () else []) >> return (x,y))) -- another one. note that we can move the final -- return out of the parens. It would even work without it, but we'd -- get a list containing many empty lists: concat fixes that. f'' = [1..4] >>= (\x -> [2..8] >>= (\y -> if (x*y == 8) then [(x,y)] else [] >>= return )) -- bind desugared. Actually, it seems to be impossible to -- write this in monadic notation and I'm getting quite confused. f''' = concatMap (\x -> concatMap (\y -> if x*y == 8 then [(x,y)] else []) [2..8]) [1..4] -- That's the one I've been looking for. Remember that -- return e = [e] f'''' = concatMap (\x -> concatMap (\y -> concatMap (\_ -> [(x,y)]) (if x*y == 8 then [()] else [])) [2..8]) [1..4] Morale: Premature term elimination is the root of all misunderstanding. Haskell wins the wickedness of design contest by using [()] and [] as truth values. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. From barsoap at web.de Mon May 5 07:43:58 2008 From: barsoap at web.de (Achim Schneider) Date: Mon May 5 07:39:15 2008 Subject: [Haskell-cafe] Re: A common pattern References: <481EBE7F.9070802@btinternet.com> <404396ef0805050111oa663859r988414cb67642c53@mail.gmail.com> <481EC20C.5080603@btinternet.com> Message-ID: <20080505134358.23a30740@solaris> Andrew Coppin wrote: > Do I get an exception or just the end of the > string?) I might possibly be able to just use hGetContents and run a > parser lazily over the result, we'll see. > You get an exception. I used this scheme for a toy http server using lazy Bytestrings, and it worked well, even with connection persistence and everything. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. From Patrick.Surry at portraitsoftware.com Mon May 5 08:26:35 2008 From: Patrick.Surry at portraitsoftware.com (Patrick Surry) Date: Mon May 5 08:20:55 2008 Subject: [Haskell-cafe] Data structure to manage collection of sets with efficient lookup, intersection? Message-ID: <93BECC602E286B499D5443ECB850D2FF012C81C1@newman.usa.aitgroupad.com> New to Haskell, with a mental block about how to represent this situation efficiently: I have an unknown function f which is defined on subsets of some universal set (say integers 1...N). I know the values of f for some subsets, and using those can infer values on other subsets. So what I need is a way to manage a collection of subsets s_i (and the associated values f(s_i)) so that I can efficiently (a) check whether a subset s is already 'known' in my collection, and (b) find all subsets t in the collection that intersect s. In a "traditional" language, I'd likely create a dictionary with keys s_i containing the f(s_i) as values, along with a separate dictionary keyed on the elements of the universal set (1...N) in which each entry is a list of all s_i containing the given element of the universal set. Together they let me check, given a subset s, whether I know f(s), and also get the list of all known subsets intersecting s (by the union of the lists of sets containing each element of s). I can't quite wrap my head around how to do this efficiently in Haskell, maybe because of the way the above is duplicating information about the subsets across two different data structures? Any thoughts? Thanks, Patrick ________________________________________________________________________ DISCLAIMER: This e-mail is intended only for the addressee named above. As this e-mail may contain confidential or privileged information, if you are not the named addressee, you are not authorised to retain, read, copy or disseminate this message or any part of it. If you received this email in error, please notify the sender and delete the message from your computer. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080505/496ee6b1/attachment-0001.htm From derek.a.elkins at gmail.com Mon May 5 08:56:09 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Mon May 5 08:50:24 2008 Subject: [Haskell-cafe] Parsec on TeX In-Reply-To: <1209970643.8213.18.camel@corn.betterworld.us> References: <56D0B8BD-1E2A-450F-9B5E-9CCDB3C4C94A@ece.cmu.edu> <1209960860.8213.14.camel@corn.betterworld.us> <1209963555.5514.27.camel@derek-laptop> <1209970643.8213.18.camel@corn.betterworld.us> Message-ID: <1209992169.5514.33.camel@derek-laptop> On Sun, 2008-05-04 at 23:57 -0700, Ross Boylan wrote: > On Sun, 2008-05-04 at 23:59 -0500, Derek Elkins wrote: > > Unfortunately, Daan seems to have disappeared off of the face of the > > internet so there isn't anything that can be done about fixing that > > documentation (and likely that is in large part why this error is > > still > > there.) > > > http://research.microsoft.com/users/daan/index.html ? I'm not sure that he is still at Microsoft; I've heard tell that he is off on another pursuit. At any rate, I've tried three different email addresses including the one listed there and have not gotten a response and others have had trouble getting in touch with him as well. I guess I could try calling that number and see what happens... From barsoap at web.de Mon May 5 09:01:14 2008 From: barsoap at web.de (Achim Schneider) Date: Mon May 5 08:55:35 2008 Subject: [Haskell-cafe] Re: Data structure to manage collection of sets with efficient lookup, intersection? References: <93BECC602E286B499D5443ECB850D2FF012C81C1@newman.usa.aitgroupad.com> Message-ID: <20080505150114.5bfe121a@solaris> "Patrick Surry" wrote: > New to Haskell, with a mental block about how to represent this > situation efficiently: > > > > I have an unknown function f which is defined on subsets of some > universal set (say integers 1...N). I know the values of f for some > subsets, and using those can infer values on other subsets. > > > > So what I need is a way to manage a collection of subsets s_i (and the > associated values f(s_i)) so that I can efficiently (a) check whether > a subset s is already 'known' in my collection, and (b) find all > subsets t in the collection that intersect s. > > > > In a "traditional" language, I'd likely create a dictionary with keys > s_i containing the f(s_i) as values, along with a separate dictionary > keyed on the elements of the universal set (1...N) in which each entry > is a list of all s_i containing the given element of the universal > set. Together they let me check, given a subset s, whether I know > f(s), and also get the list of all known subsets intersecting s (by > the union of the lists of sets containing each element of s). > > > > I can't quite wrap my head around how to do this efficiently in > Haskell, maybe because of the way the above is duplicating > information about the subsets across two different data structures? > > > > Any thoughts? > > Look at Data.Map and start coding instead of prematurely optimising. Haskell allows you to express this purely algorithmic, there's no need for data structures in the traditional sense: You can build in memoisation afterwards. http://haskell.org/ghc/docs/latest/html/libraries/containers/Data-Map.html -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. From mblazevic at stilo.com Mon May 5 09:57:15 2008 From: mblazevic at stilo.com (Mario Blazevic) Date: Mon May 5 09:51:27 2008 Subject: [Haskell-cafe] A Cabal problem Message-ID: <481F123B.4060303@stilo.com> I have a problem with Cabal: it doesn't seem to pick up the "Main-is:" option from the configuration file. Here's my "scc.cabal" file. Note the "Main-is:" line: > Name: scc > Version: 0.1 > Cabal-Version: >= 1.2 > Build-Type: Simple > License: GPL > License-file: LICENSE.txt > Copyright: (c) 2008 Mario Blazevic > Author: Mario Blazevic > Maintainer: blamario@yahoo.com > Synopsis: Streaming component combinators > > Executable shsh > Main-is: Shell.hs > Other-Modules: Foundation, ComponentTypes, Components, Combinators > Build-Depends: base, containers, process, readline, parsec > > Library > Exposed-Modules: Foundation, ComponentTypes, Components, Combinators > Build-Depends: base, containers And below are the outputs of Cabal configure and build commands. Note the absence of "--main-is" ghc command-line option. I'm doing this on Ubuntu 8.04 Linux, but I get the same problem with Gentoo. Is there something wrong with my configuration file, or is this a bug in Cabal? > ~/scc/pipe$ runhaskell Setup.lhs configure --verbose --prefix=~ > Configuring scc-0.1... > Dependency base-any: using base-3.0.1.0 > Dependency containers-any: using containers-0.1.0.1 > Dependency process-any: using process-1.0.0.0 > Dependency readline-any: using readline-1.0.1.0 > Dependency parsec-any: using parsec-2.1.0.0 > Using compiler: ghc-6.8.2 > Using install prefix: ~ > Binaries installed in: ~/bin > Libraries installed in: ~/lib/scc-0.1/ghc-6.8.2 > Private binaries installed in: ~/libexec > Data files installed in: ~/share/scc-0.1 > Documentation installed in: ~/share/doc/scc-0.1 > No alex found > Using ar found on system at: /usr/bin/ar > No c2hs found > No cpphs found > No ffihugs found > Using ghc version 6.8.2 found on system at: /usr/bin/ghc > Using ghc-pkg version 6.8.2 found on system at: /usr/bin/ghc-pkg > No greencard found > Using haddock version 0.8 found on system at: /usr/bin/haddock > No happy found > No hmake found > Using hsc2hs version 0.66-ghc found on system at: /usr/bin/hsc2hs > No hscolour found > No hugs found > No jhc found > Using ld found on system at: /usr/bin/ld > No nhc98 found > No pfesetup found > Using pkg-config version 0.22 found on system at: /usr/bin/pkg-config > Using ranlib found on system at: /usr/bin/ranlib > Using tar found on system at: /bin/tar > > ~/scc/pipe$ runhaskell Setup.lhs build --verbose > Creating dist/build (and its parents) > Creating dist/build/autogen (and its parents) > Preprocessing library scc-0.1... > Preprocessing executables for scc-0.1... > Building scc-0.1... > Building library... > Creating dist/build (and its parents) > Creating dist/build (and its parents) > /usr/bin/ghc -package-name scc-0.1 --make -hide-all-packages -i > -idist/build/autogen -idist/build -i. -Idist/build -odir dist/build > -hidir dist/build -stubdir dist/build -package base-3.0.1.0 -package > containers-0.1.0.1 -package process-1.0.0.0 -package readline-1.0.1.0 > -package parsec-2.1.0.0 -O Foundation ComponentTypes Components Combinators > [1 of 4] Compiling Foundation ( Foundation.hs, > dist/build/Foundation.o ) > [2 of 4] Compiling ComponentTypes ( ComponentTypes.hs, > dist/build/ComponentTypes.o ) > [3 of 4] Compiling Components ( Components.hs, > dist/build/Components.o ) > [4 of 4] Compiling Combinators ( Combinators.hs, > dist/build/Combinators.o ) > Linking... > /usr/bin/ar q dist/build/libHSscc-0.1.a dist/build/Foundation.o > dist/build/ComponentTypes.o dist/build/Components.o dist/build/Combinators.o > /usr/bin/ar: creating dist/build/libHSscc-0.1.a > /usr/bin/ld -x -r -o dist/build/HSscc-0.1.o.tmp dist/build/Foundation.o > dist/build/ComponentTypes.o dist/build/Components.o dist/build/Combinators.o > Building executable: shsh... > Creating dist/build/shsh (and its parents) > Creating dist/build/shsh/shsh-tmp (and its parents) > Creating dist/build/shsh/shsh-tmp (and its parents) > /usr/bin/ghc -o dist/build/shsh/shsh --make -hide-all-packages -i > -idist/build/autogen -idist/build/shsh/shsh-tmp -i. > -Idist/build/shsh/shsh-tmp -odir dist/build/shsh/shsh-tmp -hidir > dist/build/shsh/shsh-tmp -stubdir dist/build/shsh/shsh-tmp -package > base-3.0.1.0 -package containers-0.1.0.1 -package process-1.0.0.0 > -package readline-1.0.1.0 -package parsec-2.1.0.0 -O ./Shell.hs > [1 of 5] Compiling Foundation ( Foundation.hs, > dist/build/shsh/shsh-tmp/Foundation.o ) > [2 of 5] Compiling ComponentTypes ( ComponentTypes.hs, > dist/build/shsh/shsh-tmp/ComponentTypes.o ) > [3 of 5] Compiling Components ( Components.hs, > dist/build/shsh/shsh-tmp/Components.o ) > [4 of 5] Compiling Combinators ( Combinators.hs, > dist/build/shsh/shsh-tmp/Combinators.o ) > [5 of 5] Compiling Shell ( ./Shell.hs, > dist/build/shsh/shsh-tmp/Shell.o ) > Warning: output was redirected with -o, but no output will be generated > because there is no Main module. -------------- next part -------------- Name: scc Version: 0.1 Cabal-Version: >= 1.2 Build-Type: Simple License: GPL License-file: LICENSE.txt Copyright: (c) 2008 Mario Blazevic Author: Mario Blazevic Maintainer: blamario@yahoo.com Synopsis: Streaming component combinators Executable shsh Main-is: Shell.hs Other-Modules: Foundation, ComponentTypes, Components, Combinators Build-Depends: base, containers, process, readline, parsec Library Exposed-Modules: Foundation, ComponentTypes, Components, Combinators Build-Depends: base, containers -------------- next part -------------- A non-text attachment was scrubbed... Name: Setup.lhs Type: text/x-literate-haskell Size: 81 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080505/72edd664/Setup.bin From wss at Cs.Nott.AC.UK Mon May 5 10:49:48 2008 From: wss at Cs.Nott.AC.UK (Wouter Swierstra) Date: Mon May 5 10:44:03 2008 Subject: [Haskell-cafe] Using Template Haskell to make type-safe database access In-Reply-To: <1209760319.4242.4.camel@localhost.localdomain> References: <1209760319.4242.4.camel@localhost.localdomain> Message-ID: Hi Mads, > I was wondering if anybody had experimented with using Template > Haskell > (TH) and ordinary SQL to make type-safe database access? I know HaskellDB, for example, does something quite similar. There's a preprocessor that generates a Haskell file with a Haskell representation of the types of the database's tables. You could of course replace this with a TH function. There are two very nice papers about the design of HaskellDB: http://research.microsoft.com/users/daan/download/papers/dsec.ps http://haskelldb.sourceforge.net/haskelldb.pdf I think there may a bit of problem with the approach you suggest: as the type returned by the query is computed by the SQL server (if I understand you correctly), it's very hard to do anything with the result of the query - the Haskell compiler has no idea what type the result has, so you can't do anything with it. I think it makes much more sense to bookkeep type information on the Haskell side. Hope this helps, Wouter -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080505/0996682a/attachment.htm From wss at cs.nott.ac.uk Mon May 5 10:53:55 2008 From: wss at cs.nott.ac.uk (Wouter Swierstra) Date: Mon May 5 10:48:06 2008 Subject: [Haskell-cafe] Re: Couple of formal questions In-Reply-To: References: <814617240804292014td3d79f9ve9f0e2345b851e2@mail.gmail.com> <9729FF97-57A8-4B58-8447-4B78FFCEEE6B@cs.nott.ac.uk> Message-ID: On 1 May 2008, at 16:58, Michael Karcher wrote: > Wouter Swierstra wrote: >> Hi Creighton, >>> Where could I find a proof that the initial algebras & final >>> coalgebras of CPO coincide? I saw this referenced in the >>> "Bananas.." paper as a fact, but am not sure where this comes from. >> I couldn't find the statement you are referring to in "Functional >> Programming with Bananas, Lenses, Envelopes, and Barbed Wire" - but >> I'm not sure if this holds for every CPO. > > Probably he was referring to the last paragraph of the introduction: > > Working in CPO has the advantage that the carriers of intial algebras > and final co-algebras coincide, thus there is a single data type that > comprises both finite and infinite elements. Ah - thanks for pointing that out. According to my more categorically inclined office mates, Marcelo Fiore's thesis is a good reference: https://www.lfcs.inf.ed.ac.uk/reports/94/ECS-LFCS-94-307/ Hope that answers your question, Wouter From prstanley at ntlworld.com Mon May 5 10:58:53 2008 From: prstanley at ntlworld.com (PR Stanley) Date: Mon May 5 10:53:20 2008 Subject: [Haskell-cafe] Non-Overlapping Patterns Message-ID: <7.0.1.0.0.20080505154849.01d1e070@ntlworld.com> Hi isZero :: Int -> Bool isZero 0 = True isZero n | n /= 0 = False The order in which the above equations appear makes no difference to the application of isZero. Does the Haskell interpreter rewrite patterns into one single definition using some sort of switch or if construct? Why does an equation without a guard have to be placed after the more specific cases?To put it another way, why doesn't the interpreter identify the more specific cases and put them before the general ones. Cheers Paul From andrewcoppin at btinternet.com Mon May 5 11:07:46 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Mon May 5 11:01:55 2008 Subject: [Haskell-cafe] Non-Overlapping Patterns In-Reply-To: <7.0.1.0.0.20080505154849.01d1e070@ntlworld.com> References: <7.0.1.0.0.20080505154849.01d1e070@ntlworld.com> Message-ID: <481F22C2.4060802@btinternet.com> PR Stanley wrote: > To put it another way, why doesn't the interpreter identify the more > specific cases and put them before the general ones. I'm guessing because determining which equation is the "most general" is equivilent to the Halting Problem in the general case. (Notice that Mathematica does almost exactly the same thing: it has a few heuristics for figuring out what is more general, but beyond that it uses the order you specify.) As to how function application is actually implemented - well, that depends on what you're using to run your Haskell. ;-) I believe GHC uses pointer blocks rather than switch blocks (loosely speaking). From barsoap at web.de Mon May 5 11:42:36 2008 From: barsoap at web.de (Achim Schneider) Date: Mon May 5 11:37:05 2008 Subject: [Haskell-cafe] Re: Non-Overlapping Patterns References: <7.0.1.0.0.20080505154849.01d1e070@ntlworld.com> Message-ID: <20080505174236.6268bac9@solaris> PR Stanley wrote: > Hi > isZero :: Int -> Bool > isZero 0 = True > isZero n | n /= 0 = False > > The order in which the above equations appear makes no difference to > the application of isZero. Does the Haskell interpreter rewrite > patterns into one single definition using some sort of switch or if > construct? Why does an equation without a guard have to be placed > after the more specific cases?To put it another way, why doesn't the > interpreter identify the more specific cases and put them before the > general ones. > Cheers > Paul > For completeness' sake: isZero 0 = True isZero _ = False works, and, contrary to your example, requires an order to have a well defined meaning. It's equivalent[1] to isZero n = case n of 0 -> True _ -> False , and yours to isZero n = case n of 0 -> True n -> if n /= 0 then False else undefined I'll leave the last question unanswered, just try to write such a beast. PS: I prefer isZero = (==) 0 [1] which doesn't mean that one is reduced to the other. It just means they're semantically identical. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. From usenet at mkarcher.dialup.fu-berlin.de Mon May 5 11:47:09 2008 From: usenet at mkarcher.dialup.fu-berlin.de (Michael Karcher) Date: Mon May 5 11:41:32 2008 Subject: [Haskell-cafe] Re: Non-Overlapping Patterns References: <7.0.1.0.0.20080505154849.01d1e070@ntlworld.com> Message-ID: PR Stanley wrote: > after the more specific cases?To put it another way, why doesn't the > interpreter identify the more specific cases and put them before the > general ones. Given the function foo below, which of the first lines is more specific? No reordering means, that it is obvious that (foo 0 1) results in one. foo :: Int -> Int -> Bool foo x 1 = 1 foo 0 y = 0 foo x y = 2 Regards, Michael Karcher From barsoap at web.de Mon May 5 11:48:56 2008 From: barsoap at web.de (Achim Schneider) Date: Mon May 5 11:43:21 2008 Subject: [Haskell-cafe] Re: Non-Overlapping Patterns References: <7.0.1.0.0.20080505154849.01d1e070@ntlworld.com> <20080505174236.6268bac9@solaris> Message-ID: <20080505174856.1db2c488@solaris> Achim Schneider wrote: > isZero n = case n of > 0 -> True > n -> if n /= 0 > then False > else undefined > You can't exchange the order, here, of course, the semantics of this and a guard-version would differ. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. From saihemanth at gmail.com Mon May 5 11:52:29 2008 From: saihemanth at gmail.com (Sai Hemanth K) Date: Mon May 5 11:46:42 2008 Subject: [Haskell-cafe] Question related to Multi Param Type Classes Message-ID: <650778a70805050852kfbdd299q2263b95da673fd43@mail.gmail.com> Hi, I declared a multi param type class as below: *class MyString m c where zIndex :: m -> Int -> c zLength :: m -> Int zPack :: [c] -> m zEquals :: c ->c -> Bool zWrap :: [c] -> (m,AnExistingDataType)* In the end I did not needed it for my program, but for those few minutes I played with the idea, I came across a zillion questions. Can some body help me here please? When I defined a function like below, \begin{code} compareStr::(MyString m c) => (m,Int) ->(m,Int)->Int->Int compareStr (s1,pos1) (s2,pos2) soFar | (pos1 < zLength s1) && (pos2 < zLength s2) = let c1 = zIndex s1 pos1 c2 = zIndex s2 pos2 in if(zEquals c1 c2) then compareStr (s1,(pos1 + 1)) (s2, (pos2 + 1)) (soFar + 1) else soFar | otherwise = soFar \end{code} when I loaded it on ghci ( invoked with -XMultiParamTypeClasses ), I got an essay in greek (or is it latin?), which started something like below: Could not deduce (MyString m c) from the context (MyString m c4) arising from a use of `zLength' at GenericZAlgo.lhs:42:21-31 Possible fix: add (MyString m c) to the context of the type signature for `compareStr' In the second argument of `(<)', namely `zLength s1' In the first argument of `(&&)', namely `(pos1 < zLength s1)' In a pattern guard for the definition of `compareStr': (pos1 < zLength s1) && (pos2 < zLength s2) And if I let the type inference run the show, the type it shows is : compareStr :: (MyString t c2, MyString m c2, Num a, MyString t1 c2, MyString t c, MyString t1 c1) => (t, Int) -> (t1, Int) -> a -> a And puzzlingly, if I try the same thing myself and reload it on the ghci,I still get similar error. I can go on about other 'puzzles'. Can some one please tell me whats going on here? Apologies, if it is something that's been documented left to right, top to bottom, but I could not get anywhere readily. Any pointers to the right documentation will be much appreciated. On the surface it looks like something that n00bs like yours truly better stay away. But I have a feeling that this one may throw some more light on type inference. Many thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080505/3fecb106/attachment.htm From bulat.ziganshin at gmail.com Mon May 5 12:07:03 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Mon May 5 12:03:12 2008 Subject: [Haskell-cafe] Question related to Multi Param Type Classes In-Reply-To: <650778a70805050852kfbdd299q2263b95da673fd43@mail.gmail.com> References: <650778a70805050852kfbdd299q2263b95da673fd43@mail.gmail.com> Message-ID: <5452568.20080505200703@gmail.com> Hello Sai, Monday, May 5, 2008, 7:52:29 PM, you wrote: > class MyString m c? where it should be class MyString m c?| m->c where so ghc will realize that same m means the same c. read about "functional dependencies" in ghc user manual -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From alfonso.acosta at gmail.com Mon May 5 12:13:23 2008 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Mon May 5 12:07:35 2008 Subject: [Haskell-cafe] Question related to Multi Param Type Classes In-Reply-To: <650778a70805050852kfbdd299q2263b95da673fd43@mail.gmail.com> References: <650778a70805050852kfbdd299q2263b95da673fd43@mail.gmail.com> Message-ID: <6a7c66fc0805050913j4cc07a02p5003b07b2aaa3207@mail.gmail.com> 2008/5/5 Sai Hemanth K : > Hi, > > I declared a multi param type class as below: > class MyString m c where > zIndex :: m -> Int -> c > zLength :: m -> Int > zPack :: [c] -> m > zEquals :: c ->c -> Bool > zWrap :: [c] -> (m,AnExistingDataType) I infer from your questions that you probably missed setting a functional dependency, that is > class MyString m c | m -> c where > zIndex :: m -> Int -> c > zLength :: m -> Int > zPack :: [c] -> m > zEquals :: c ->c -> Bool > zWrap :: [c] -> (m,AnExistingDataType) which means, "c is univocaly determined by m". You'll need -XFunctionalDependencies to make it work in GHC. From kirill.kuvaldin at gmail.com Mon May 5 11:57:51 2008 From: kirill.kuvaldin at gmail.com (Kirill Kuvaldin) Date: Mon May 5 12:18:55 2008 Subject: [Haskell-cafe] Help me speed up my program... or back to the issue of memoization Message-ID: <2d42915c0805050857tcc43ce6x76a661b801cb6575@mail.gmail.com> Hello, I wrote a program in haskell that works with lattice finite automata (the generalization of notion of finite state automata). Let me post the source code as it is not that long... The problem is that my algorithm that computes the run (see function fun) of an automaton on the given word is not very optimal and takes a loooong time as the input word gets larger... (e.g. try this one "run m3 "11101101110001010101" ") Due to the nature of every haskell function being a referentially transparent, I think I could have speeded up its performance using memoization. I've read the page on haskell wiki (http://www.haskell.org/haskellwiki/Memoization) but it didn't help me because it looks I have to modify the actual function source code to make use of memoized values. What I'm looking for is a kind of a general solution (say, silver bullet :) ) so that I will be able to use my function like > new_run = memoize run and the results of the "new_run" get automatically memoized. Probably it makes sense to memoize deltaext func as well. Is that possible to do that in Haskell?? Thanks a lot! Kirill ======= SOURCE CODE ===== -- data type for lattice data Lattice l = Lattice [l] -- set of lattice elements (l -> l -> l) -- supremum operation (l -> l -> l) -- infimum operation -- returns the lowest lattice element lattice0 (Lattice l s i) = l !! 0 -- returns the greatest lattice element lattice1 (Lattice l s i) = l !! ((length l)-1) -- supremum of 2 lattice elements sup (Lattice l s i) x y = s x y -- infimum of 2 lattice elements inf (Lattice l s i) x y = i x y supremum (Lattice l sup inf) [] = lattice0 (Lattice l sup inf) supremum (Lattice l sup inf) (x:xs) = sup x (supremum (Lattice l sup inf) xs) infimum (Lattice l sup inf) [] = lattice1 (Lattice l sup inf) infimum (Lattice l sup inf) (x:xs) = inf x (infimum (Lattice l sup inf) xs) inf3 (Lattice l s i) x y z = infimum (Lattice l s i) [x,y,z] --- data type for Lattice Automata (LA) data LA l state sym = LA (Lattice l) -- lattice [state] -- set of states [sym] -- alphabet (state -> sym -> state -> l) -- fuzzy transition function (state -> l) -- fuzzy initial state (state -> l) -- fuzzy final state --- extended transition function deltaext :: (Eq state) => (LA l state sym) -> state -> [sym] -> state -> l deltaext (LA l states chars delta sigma0 sigma1) x [] y = if x == y then (lattice1 l) else (lattice0 l) deltaext la@(LA l states chars delta sigma0 sigma1) x (a:w) y = supremum l [ inf l (delta x a z) (deltaext la z w y) | z <- states] -- runs the Lattice Automaton on the given word run la@(LA l states chars delta sigma0 sigma1) w = supremum l [ inf3 l (sigma0 x) (deltaext la x w y) (sigma1 y) | x <- states, y <- states] --- --- examples --- l3 = Lattice [0.0, 0.5, 1.0] max min where max x y = if x > y then x else y min x y = if x < y then x else y m3 = LA l3 ['a', 'b'] ['0', '1'] delta sigma0 sigma1 where delta 'a' '0' 'a' = 1 delta 'a' '0' 'b' = 0.5 delta 'b' '0' 'a' = 0.5 delta 'b' '0' 'b' = 1 delta 'a' '1' 'a' = 0 delta 'a' '1' 'b' = 1 delta 'b' '1' 'a' = 1 delta 'b' '1' 'b' = 1 sigma0 'a' = 1 sigma0 'b' = 0.5 sigma1 'a' = 0.5 sigma1 'b' = 1 From phercek at gmail.com Mon May 5 12:55:21 2008 From: phercek at gmail.com (Peter Hercek) Date: Mon May 5 12:51:35 2008 Subject: [Haskell-cafe] Re: Grokking monads by not overlooking concatMap In-Reply-To: <20080505133920.5d0f26bc@solaris> References: <20080505133920.5d0f26bc@solaris> Message-ID: Achim Schneider wrote: > -- That's the one I've been looking for. Remember that > -- return e = [e] > f'''' = concatMap > (\x -> concatMap > (\y -> concatMap > (\_ -> [(x,y)]) > (if x*y == 8 then [()] else [])) > [2..8]) > [1..4] > > Morale: Premature term elimination is the root of all misunderstanding. > > Haskell wins the wickedness of design contest by using [()] and [] as > truth values. Maybe you wanted to say: "... by using [()] as True value and [] as False value" ... which does not seem that wicked (at least to me). Peter. From phercek at gmail.com Mon May 5 13:01:15 2008 From: phercek at gmail.com (Peter Hercek) Date: Mon May 5 12:56:13 2008 Subject: [Haskell-cafe] Re: Grokking monads by not overlooking concatMap In-Reply-To: References: <20080505133920.5d0f26bc@solaris> Message-ID: Peter Hercek wrote: > Achim Schneider wrote: >> Haskell wins the wickedness of design contest by using [()] and [] as >> truth values. > > Maybe you wanted to say: "... by using [()] as True value and [] as > False value" ... which does not seem that wicked (at least to me). Oops sorry, missed you say "truth" and not "true" :-D Still not more wicked as 0 meaning False and non-zero meaning True in C. From barsoap at web.de Mon May 5 13:04:49 2008 From: barsoap at web.de (Achim Schneider) Date: Mon May 5 12:59:11 2008 Subject: [Haskell-cafe] Re: Grokking monads by not overlooking concatMap References: <20080505133920.5d0f26bc@solaris> Message-ID: <20080505190449.29da13f9@solaris> Peter Hercek wrote: > Achim Schneider wrote: > > -- That's the one I've been looking for. Remember that > > -- return e = [e] > > f'''' = concatMap > > (\x -> concatMap > > (\y -> concatMap > > (\_ -> [(x,y)]) > > (if x*y == 8 then [()] else [])) > > [2..8]) > > [1..4] > > > > Morale: Premature term elimination is the root of all > > misunderstanding. > > > > Haskell wins the wickedness of design contest by using [()] and [] > > as truth values. > > Maybe you wanted to say: "... by using [()] as True value and [] as > False value" ... which does not seem that wicked (at least to me). > Strangely enough, it reads exactly the same to me. IMHO, not working like filter is the thing that makes this wicked: guard doesn't care about what is returned, you could as well say (\_ -> [("foo","bar")]) -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. From trevor at galois.com Mon May 5 13:10:32 2008 From: trevor at galois.com (Trevor Elliott) Date: Mon May 5 13:06:11 2008 Subject: [Haskell-cafe] A Cabal problem In-Reply-To: <481F123B.4060303@stilo.com> References: <481F123B.4060303@stilo.com> Message-ID: <20080505101032.22e04edc@trogdor> Hi Mario, Is the name of the module within the Shell.hs file Main? If not, that could be your problem. --trevor On Mon, 05 May 2008 09:57:15 -0400 Mario Blazevic wrote: > I have a problem with Cabal: it doesn't seem to pick up the > "Main-is:" option from the configuration file. > > Here's my "scc.cabal" file. Note the "Main-is:" line: > > > Name: scc > > Version: 0.1 > > Cabal-Version: >= 1.2 > > Build-Type: Simple > > License: GPL > > License-file: LICENSE.txt > > Copyright: (c) 2008 Mario Blazevic > > Author: Mario Blazevic > > Maintainer: blamario@yahoo.com > > Synopsis: Streaming component combinators > > > > Executable shsh > > Main-is: Shell.hs > > Other-Modules: Foundation, ComponentTypes, Components, > > Combinators Build-Depends: base, containers, process, readline, > > parsec > > > > Library > > Exposed-Modules: Foundation, ComponentTypes, Components, > > Combinators Build-Depends: base, containers > > > And below are the outputs of Cabal configure and build > commands. Note the absence of "--main-is" ghc command-line option. > I'm doing this on Ubuntu 8.04 Linux, but I get the same problem with > Gentoo. Is there something wrong with my configuration file, or is > this a bug in Cabal? > > > > ~/scc/pipe$ runhaskell Setup.lhs configure --verbose --prefix=~ > > Configuring scc-0.1... > > Dependency base-any: using base-3.0.1.0 > > Dependency containers-any: using containers-0.1.0.1 > > Dependency process-any: using process-1.0.0.0 > > Dependency readline-any: using readline-1.0.1.0 > > Dependency parsec-any: using parsec-2.1.0.0 > > Using compiler: ghc-6.8.2 > > Using install prefix: ~ > > Binaries installed in: ~/bin > > Libraries installed in: ~/lib/scc-0.1/ghc-6.8.2 > > Private binaries installed in: ~/libexec > > Data files installed in: ~/share/scc-0.1 > > Documentation installed in: ~/share/doc/scc-0.1 > > No alex found > > Using ar found on system at: /usr/bin/ar > > No c2hs found > > No cpphs found > > No ffihugs found > > Using ghc version 6.8.2 found on system at: /usr/bin/ghc > > Using ghc-pkg version 6.8.2 found on system at: /usr/bin/ghc-pkg > > No greencard found > > Using haddock version 0.8 found on system at: /usr/bin/haddock > > No happy found > > No hmake found > > Using hsc2hs version 0.66-ghc found on system at: /usr/bin/hsc2hs > > No hscolour found > > No hugs found > > No jhc found > > Using ld found on system at: /usr/bin/ld > > No nhc98 found > > No pfesetup found > > Using pkg-config version 0.22 found on system > > at: /usr/bin/pkg-config Using ranlib found on system > > at: /usr/bin/ranlib Using tar found on system at: /bin/tar > > > > ~/scc/pipe$ runhaskell Setup.lhs build --verbose > > Creating dist/build (and its parents) > > Creating dist/build/autogen (and its parents) > > Preprocessing library scc-0.1... > > Preprocessing executables for scc-0.1... > > Building scc-0.1... > > Building library... > > Creating dist/build (and its parents) > > Creating dist/build (and its parents) > > /usr/bin/ghc -package-name scc-0.1 --make -hide-all-packages -i > > -idist/build/autogen -idist/build -i. -Idist/build -odir dist/build > > -hidir dist/build -stubdir dist/build -package base-3.0.1.0 > > -package containers-0.1.0.1 -package process-1.0.0.0 -package > > readline-1.0.1.0 -package parsec-2.1.0.0 -O Foundation > > ComponentTypes Components Combinators [1 of 4] Compiling > > Foundation ( Foundation.hs, dist/build/Foundation.o ) > > [2 of 4] Compiling ComponentTypes ( ComponentTypes.hs, > > dist/build/ComponentTypes.o ) > > [3 of 4] Compiling Components ( Components.hs, > > dist/build/Components.o ) > > [4 of 4] Compiling Combinators ( Combinators.hs, > > dist/build/Combinators.o ) > > Linking... > > /usr/bin/ar q dist/build/libHSscc-0.1.a dist/build/Foundation.o > > dist/build/ComponentTypes.o dist/build/Components.o > > dist/build/Combinators.o /usr/bin/ar: creating > > dist/build/libHSscc-0.1.a /usr/bin/ld -x -r -o > > dist/build/HSscc-0.1.o.tmp dist/build/Foundation.o > > dist/build/ComponentTypes.o dist/build/Components.o > > dist/build/Combinators.o Building executable: shsh... Creating > > dist/build/shsh (and its parents) Creating dist/build/shsh/shsh-tmp > > (and its parents) Creating dist/build/shsh/shsh-tmp (and its > > parents) /usr/bin/ghc -o dist/build/shsh/shsh --make > > -hide-all-packages -i -idist/build/autogen > > -idist/build/shsh/shsh-tmp -i. -Idist/build/shsh/shsh-tmp -odir > > dist/build/shsh/shsh-tmp -hidir dist/build/shsh/shsh-tmp -stubdir > > dist/build/shsh/shsh-tmp -package base-3.0.1.0 -package > > containers-0.1.0.1 -package process-1.0.0.0 -package > > readline-1.0.1.0 -package parsec-2.1.0.0 -O ./Shell.hs [1 of 5] > > Compiling Foundation ( Foundation.hs, > > dist/build/shsh/shsh-tmp/Foundation.o ) [2 of 5] Compiling > > ComponentTypes ( ComponentTypes.hs, > > dist/build/shsh/shsh-tmp/ComponentTypes.o ) [3 of 5] Compiling > > Components ( Components.hs, > > dist/build/shsh/shsh-tmp/Components.o ) [4 of 5] Compiling > > Combinators ( Combinators.hs, > > dist/build/shsh/shsh-tmp/Combinators.o ) [5 of 5] Compiling > > Shell ( ./Shell.hs, dist/build/shsh/shsh-tmp/Shell.o ) > > Warning: output was redirected with -o, but no output will be > > generated because there is no Main module. > > > > From phercek at gmail.com Mon May 5 13:23:46 2008 From: phercek at gmail.com (Peter Hercek) Date: Mon May 5 13:18:06 2008 Subject: [Haskell-cafe] Re: Grokking monads by not overlooking concatMap In-Reply-To: <20080505190449.29da13f9@solaris> References: <20080505133920.5d0f26bc@solaris> <20080505190449.29da13f9@solaris> Message-ID: Achim Schneider wrote: > Peter Hercek wrote: >>> Haskell wins the wickedness of design contest by using [()] and [] >>> as truth values. >> Maybe you wanted to say: "... by using [()] as True value and [] as >> False value" ... which does not seem that wicked (at least to me). >> > Strangely enough, it reads exactly the same to me. IMHO, not working > like filter is the thing that makes this wicked: guard doesn't care > about what is returned, you could as well say (\_ -> [("foo","bar")]) Right, should be a list with one element in it to represent True. So maybe it is a bit worse than C since list with two elements gives you two True values :-D On the other side it is nice that guard works the expected way (using the same implementation) with other MonadPlus-es too. From mblazevic at stilo.com Mon May 5 13:37:12 2008 From: mblazevic at stilo.com (Mario Blazevic) Date: Mon May 5 13:31:23 2008 Subject: [Haskell-cafe] A Cabal problem In-Reply-To: <20080505101032.22e04edc@trogdor> References: <481F123B.4060303@stilo.com> <20080505101032.22e04edc@trogdor> Message-ID: <481F45C8.1070702@stilo.com> Trevor Elliott wrote: > Hi Mario, > > Is the name of the module within the Shell.hs file Main? If not, that > could be your problem. You may be right, the module's name is Shell, not Main. GHC does not have problem with that when "--main-is Shell" option is specified on the command line. Is Cabal different? Is this documented somewhere? From trevor at galois.com Mon May 5 13:40:20 2008 From: trevor at galois.com (Trevor Elliott) Date: Mon May 5 13:35:55 2008 Subject: [Haskell-cafe] A Cabal problem In-Reply-To: <481F45C8.1070702@stilo.com> References: <481F123B.4060303@stilo.com> <20080505101032.22e04edc@trogdor> <481F45C8.1070702@stilo.com> Message-ID: <20080505104020.3e5d40bb@trogdor> On Mon, 05 May 2008 13:37:12 -0400 Mario Blazevic wrote: > Trevor Elliott wrote: > > Hi Mario, > > > > Is the name of the module within the Shell.hs file Main? If not, > > that could be your problem. > > You may be right, the module's name is Shell, not Main. GHC > does not have problem with that when "--main-is Shell" option is > specified on the command line. Is Cabal different? Is this documented > somewhere? Cabal doesn't pass the --main-is option, I believe because it is specific to GHC. What you could do is add this flag in the ghc-options field of your executable in the cabal file, like this: ghc-options: --main-is Shell --trevor From barsoap at web.de Mon May 5 13:52:24 2008 From: barsoap at web.de (Achim Schneider) Date: Mon May 5 13:46:54 2008 Subject: [Haskell-cafe] Re: Grokking monads by not overlooking concatMap References: <20080505133920.5d0f26bc@solaris> <20080505190449.29da13f9@solaris> Message-ID: <20080505195224.4ad5ac2c@solaris> Peter Hercek wrote: > Achim Schneider wrote: > > Peter Hercek wrote: > >>> Haskell wins the wickedness of design contest by using [()] and [] > >>> as truth values. > >> Maybe you wanted to say: "... by using [()] as True value and [] as > >> False value" ... which does not seem that wicked (at least to > >> me). > >> > > Strangely enough, it reads exactly the same to me. IMHO, not working > > like filter is the thing that makes this wicked: guard doesn't care > > about what is returned, you could as well say (\_ -> > > [("foo","bar")]) > > Right, should be a list with one element in it to represent True. > So maybe it is a bit worse than C since list with two elements > gives you two True values :-D > On the other side it is nice that guard works the expected way > (using the same implementation) with other MonadPlus-es too. > Yes ;) You can actually do stuff like f'''' = concatMap (\x -> concatMap (\y -> concatMap (\_ -> [(x,y)]) (if x*y == 8 then replicate (x+y) () else [])) [2..8]) [1..4] , resulting in [(1,8),(1,8),(1,8),(1,8),(1,8),(1,8),(1,8),(1,8),(1,8),(2,4),(2,4), (2,4),(2,4),(2,4),(2,4),(4,2),(4,2),(4,2),(4,2),(4,2),(4,2)] or Prelude> "Hello World" >>= (\c -> if (c == 'o') then replicate 10 c else [c]) "Helloooooooooo Woooooooooorld" -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. From allbery at ece.cmu.edu Mon May 5 14:03:30 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Mon May 5 13:57:41 2008 Subject: [Haskell-cafe] Question related to Multi Param Type Classes In-Reply-To: <650778a70805050852kfbdd299q2263b95da673fd43@mail.gmail.com> References: <650778a70805050852kfbdd299q2263b95da673fd43@mail.gmail.com> Message-ID: On May 5, 2008, at 11:52 , Sai Hemanth K wrote: > when I loaded it on ghci ( invoked with -XMultiParamTypeClasses ), > I got an essay in greek (or is it latin?), which started something > like below: > Could not deduce (MyString m c) from the context (MyString m c4) > arising from a use of `zLength' at GenericZAlgo.lhs:42:21-31 Other people gave you the "how"; here's the why. The problem is that, with the information available to ghc from your definitions, there is no way to fix a type for "c". It can't use the instances it knows about because type classes are open; that is, someone could add another instance in a different source file (or even later in the existing one) and suddenly "c" would not be determinable. This is considered a bad thing. What this means in practice is that when GHC tries to type "compareStr", because "c" is never used in the function, it can fix "m" but it can't fix "MyString m c". Therefore it can't prove that the same "MyString m c" applies to both arguments that refer to "m" --- which is what that error quoted above means. The functional dependency "MyString m c | m -> c" tells GHC that any specific "m" determines a specific "c". It doesn't matter what the type is here, since it's not used in the definition of compareStr; but it must be possible to know that the same "c" is being used in both arguments. Given this, it can fix "MyString m c" knowing only "m" and as a result the function typechecks. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From RossBoylan at stanfordalumni.org Mon May 5 14:19:17 2008 From: RossBoylan at stanfordalumni.org (Ross Boylan) Date: Mon May 5 14:13:40 2008 Subject: [Haskell-cafe] Parsec on TeX In-Reply-To: <1209992169.5514.33.camel@derek-laptop> References: <56D0B8BD-1E2A-450F-9B5E-9CCDB3C4C94A@ece.cmu.edu> <1209960860.8213.14.camel@corn.betterworld.us> <1209963555.5514.27.camel@derek-laptop> <1209970643.8213.18.camel@corn.betterworld.us> <1209992169.5514.33.camel@derek-laptop> Message-ID: <1210011557.8213.20.camel@corn.betterworld.us> On Mon, 2008-05-05 at 07:56 -0500, Derek Elkins wrote: > On Sun, 2008-05-04 at 23:57 -0700, Ross Boylan wrote: > > On Sun, 2008-05-04 at 23:59 -0500, Derek Elkins wrote: > > > Unfortunately, Daan seems to have disappeared off of the face of the > > > internet so there isn't anything that can be done about fixing that > > > documentation (and likely that is in large part why this error is > > > still > > > there.) > > > > > http://research.microsoft.com/users/daan/index.html ? > > I'm not sure that he is still at Microsoft; I've heard tell that he is > off on another pursuit. At any rate, I've tried three different email > addresses including the one listed there and have not gotten a response > and others have had trouble getting in touch with him as well. I guess > I could try calling that number and see what happens... > The last publication listed is March 2008, so it looks pretty current. Ross From ryani.spam at gmail.com Mon May 5 14:51:41 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Mon May 5 14:45:53 2008 Subject: [Haskell-cafe] Question related to Multi Param Type Classes In-Reply-To: References: <650778a70805050852kfbdd299q2263b95da673fd43@mail.gmail.com> Message-ID: <2f9b2d30805051151y3c50da38m84622c187c897ac3@mail.gmail.com> On 5/5/08, Brandon S. Allbery KF8NH wrote: > The functional dependency "MyString m c | m -> c" tells GHC that any > specific "m" determines a specific "c". It doesn't matter what the type is > here, since it's not used in the definition of compareStr; but it must be > possible to know that the same "c" is being used in both arguments. Given > this, it can fix "MyString m c" knowing only "m" and as a result the > function typechecks. Although this still makes it impossible to call zEquals for the same reason; you need a dependency in both directions for it to make sense. -- ryan From ryani.spam at gmail.com Mon May 5 14:59:25 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Mon May 5 14:53:38 2008 Subject: [Haskell-cafe] Re: Control.Exception.evaluate - 'correct definition' not so correct In-Reply-To: <5ab17e790805041730o33b378e4u74f4f1f9e813e72b@mail.gmail.com> References: <20080503091917.GA5333@shion.is.fushizen.net> <5ab17e790805041730o33b378e4u74f4f1f9e813e72b@mail.gmail.com> Message-ID: <2f9b2d30805051159vf5e84c0q7b1cab4037a69ae9@mail.gmail.com> On 5/4/08, Iavor Diatchki wrote: > >From the monad law we can conclude only that "(>>= return)" is strict, > not (>>=) in general. > For example, (>>=) for the reader monad is not strict in its first argument: > > m >>= f = \r -> f (m r) r > > So, "(undefined >> return 2) = (return 2)" That's not even true here, though, with regards to seq. undefined >>= return = \r -> return (undefined r) r = \r -> const (undefined r) r = \r -> undefined r But seq undefined 0 = _|_ seq (undefined >>= return) 0 = seq (\r -> undefined r) 0 = 0 The monad laws just aren't true for many monads once seq is a possibility. -- ryan From westondan at imageworks.com Mon May 5 15:28:52 2008 From: westondan at imageworks.com (Dan Weston) Date: Mon May 5 15:23:04 2008 Subject: [Haskell-cafe] unapplying function definitions? In-Reply-To: <7.0.1.0.0.20080504163109.01d06a38@ntlworld.com> References: <7.0.1.0.0.20080504163109.01d06a38@ntlworld.com> Message-ID: <481F5FF4.8040306@imageworks.com> Hi Paul! I'm not sure about the context of Hutton, but maybe "unapplying functions" refers to the principle of extensionality. Leibnitz' rule of the "indiscernibility of identicals" [1] says that if two functions are equal, then the respective results of applying each to *any* value of their common domain are equal: f, g :: a -> b and f = g ==> forall (x :: a) . f x = g x Since Haskell contains the undefined value in every type, this applies as well to undefined: f x and g x must either both be undefined or equal. We can keep going from left to right, so that for any validly typed y, f x y = g x y, f x y z = g x y z, etc. The converse of this is also true, and called the principle of extensionality: Two functions can be considered equal if they have a common domain (type) and if, for each value in that domain (type), which in Haskell includes undefined, they give the same result. So if we have two functions f and g, and we know [2] that for *every* z (i.e. z is a free variable or a universally quantified variable) that f x y z = g x y z ==> f x y = g x y We can keep going from right to left: if in addition, this is true for all y, then f x = g x. And finally, if this is true for all x, then f = g. Note that Leibnitz allows for "any" argument, extensionality requires equality for "every" argument. Dan Weston [1] http://en.wikipedia.org/wiki/Identity_of_indiscernibles#Identity_and_indiscernibility [2] We know this because e.g. there is some definition or theorem saying so. We cannot compute this (even for finite domains) by trying each value. They need to give the same result even for undefined arguments, so that you cannot give a computable extensional definition of function equality even for finite domains, since if one function doesn't halt when applied to 3, the other must also not halt, and you can't wait for ever to be sure this is true. PR Stanley wrote: > Hi > What on earth is unapplying function definitions? > The following is taken from chapter 13 of the Hutton book: > "...when reasoning about programs, function definitions can be both > applied from left to right and unapplied from right to left." > > Cheers > Paul From mads_lindstroem at yahoo.dk Mon May 5 16:02:24 2008 From: mads_lindstroem at yahoo.dk (Mads =?ISO-8859-1?Q?Lindstr=F8m?=) Date: Mon May 5 15:59:42 2008 Subject: [Haskell-cafe] Using Template Haskell to make type-safe database access In-Reply-To: References: <1209760319.4242.4.camel@localhost.localdomain> Message-ID: <1210017744.4300.30.camel@localhost.localdomain> Hi, Wouter Swierstra wrote: > Hi Mads, > > > I was wondering if anybody had experimented with using Template > > Haskell > > (TH) and ordinary SQL to make type-safe database access? > > > > > I know HaskellDB, for example, does something quite similar. There's a > preprocessor that generates a Haskell file with a Haskell > representation of the types of the database's tables. You could of > course replace this with a TH function. There are two very nice papers > about the design of HaskellDB: > > > http://research.microsoft.com/users/daan/download/papers/dsec.ps > > > http://haskelldb.sourceforge.net/haskelldb.pdf > Thanks. > > I think there may a bit of problem with the approach you suggest: as > the type returned by the query is computed by the SQL server (if I > understand you correctly), it's very hard to do anything with the > result of the query - the Haskell compiler has no idea what type the > result has, so you can't do anything with it. I think it makes much > more sense to bookkeep type information on the Haskell side. But you can ask the SQL server for the type of the result. In the TH function you could: 1) Call ODBC function SQLPrepare (http://msdn.microsoft.com/en-us/library/ms710926(VS.85).aspx) . This just prepares a statement. It do _not_ execute it. 2) Call ODBC function SQLNumParams (http://msdn.microsoft.com/en-us/library/ms715409(VS.85).aspx) . This returns the number of parameters. 3) Call ODBC function SQLDescribeParam (http://msdn.microsoft.com/en-us/library/ms710188(VS.85).aspx) for each parameter to get type information. I imagine that this would all be done at compile time by the TH function. At run time we would call SQLPrepare (again) and SQLExecute. We obtained type information at compile time, so it should all be quite type safe. HDBC almost supports this with describeResult (http://software.complete.org/static/hdbc/doc/Database-HDBC.html#v% 3AdescribeResult ) and prepare (http://software.complete.org/static/hdbc/doc/Database-HDBC.html#v% 3Aprepare ), except that we need to execute a prepared SQL statement before calling describeResult (see link to describeResult). Calling functions that could potentially change data at compile time seems like a bad idea. For some people, maybe even a deal breaker. HSQL has similar functions. But I have not got it to work yet, so that I could test it. We would of cause need to map the type information returned by SQLDescribeParam to Haskell data types. But is seems to me that HSQL and HDBC can already do that. Of cause it all requires that the database have identical metadata at run and compile -time. Either using the same database or a copy. Though one should note that HaskellDB has the same disadvantage. Actually it do not seem much of a disadvantage it all, as most code accessing SQL databases depends on database metadata anyway. Greetings, Mads Lindstr?m > > > Hope this helps, > > > Wouter From jake.mcarthur at gmail.com Mon May 5 16:44:12 2008 From: jake.mcarthur at gmail.com (Jake Mcarthur) Date: Mon May 5 16:38:27 2008 Subject: [Haskell-cafe] Help me speed up my program... or back to the issue of memoization In-Reply-To: <2d42915c0805050857tcc43ce6x76a661b801cb6575@mail.gmail.com> References: <2d42915c0805050857tcc43ce6x76a661b801cb6575@mail.gmail.com> Message-ID: <27D449B0-EF9A-43C7-9DE4-E80BD73B01DD@gmail.com> This is only a guess, but an educated guess: there is no silver bullet for memoization in Haskell. There are, however, some somewhat more general approaches you may be interested in. I think this hasn't been researched extremely throughly yet, but see http://www.cs.utexas.edu/~wcook/Drafts/2006/MemoMixins.pdf for an example. - Jake McArthur From ben.franksen at online.de Mon May 5 16:51:30 2008 From: ben.franksen at online.de (Ben Franksen) Date: Mon May 5 16:51:51 2008 Subject: [Haskell-cafe] Re: Cabalizing darcs References: <20080423185549.GA21309@localhost> Message-ID: Gwern Branwen wrote: > (If yes, any suggestions for a package name? 'darcs' is out, but > 'darcs-cb' and 'darcs-cabalized' strike me as horribly clunky or obscure.) barcs :-) Cheers Ben From dons at galois.com Mon May 5 17:22:37 2008 From: dons at galois.com (Don Stewart) Date: Mon May 5 17:16:52 2008 Subject: [Haskell-cafe] Data structure to manage collection of sets with efficient lookup, intersection? In-Reply-To: <93BECC602E286B499D5443ECB850D2FF012C81C1@newman.usa.aitgroupad.com> References: <93BECC602E286B499D5443ECB850D2FF012C81C1@newman.usa.aitgroupad.com> Message-ID: <20080505212237.GD15146@scytale.galois.com> Patrick.Surry: > In a "traditional" language, I'd likely create a dictionary with keys s_i > containing the f(s_i) as values, along with a separate dictionary keyed on The usual dictionary type to use is Data.Map, you might also try Data.IntMap if your keys are word-sized integers. > the elements of the universal set (1...N) in which each entry is a list of > all s_i containing the given element of the universal set. Together they So that sounds like another Map. > let me check, given a subset s, whether I know f(s), and also get the list > of all known subsets intersecting s (by the union of the lists of sets > containing each element of s). > > I can't quite wrap my head around how to do this efficiently in Haskell, > maybe because of the way the above is duplicating information about the > subsets across two different data structures? Seems like you'd do it much the same way -- with a pair of dictionaries (in this case, purely functional finite maps, defined in: http://haskell.org/ghc/docs/latest/html/libraries/containers/Data-Map.html An example, Prelude Data.Map> let m = fromList (zip [1..10] (repeat "haskell")) :: Map Int String Prelude Data.Map> Data.Map.lookup 4 m "haskell" Cheers, Don From dons at galois.com Mon May 5 18:02:20 2008 From: dons at galois.com (Don Stewart) Date: Mon May 5 17:56:39 2008 Subject: [Haskell-cafe] Parsec on TeX In-Reply-To: <481EC142.3070500@btinternet.com> References: <56D0B8BD-1E2A-450F-9B5E-9CCDB3C4C94A@ece.cmu.edu> <1209960860.8213.14.camel@corn.betterworld.us> <481EC142.3070500@btinternet.com> Message-ID: <20080505220220.GG15146@scytale.galois.com> andrewcoppin: > Ross Boylan wrote: > >First, I'm really impressed with the fast and helpful responses from > >several people! > > > > Ask an easy question and you'll get at least a dozen people tripping > over each other in their rush to offer you useful advice. Ask a hard > question, or an uninteresting question, and enjoy the utter silence... > :-( Still, I suppose that's not *too* surprising. > > >I had thought HUGS made more sense for fiddling around, but it seems all > >I'm doing is loading files anyway. What is the style people use for > >this exploratory work? I've already installed haskell-mode for emacs > >and ghc6, but it's not clear to me to what extent the former servers as > >a development environment rather than just a language formatter. > > > > I used to use Hugs as well. Then I updated to the newest version, and > found it horrifically buggy. That's when I moved over to GHC. As Don > said, GHCi doesn't let you define new functions like Hugs does, but Other way around, GHCi lets you define new functions, unlike Hugs :) $ ghci Prelude> let f x = x ^ 2 Prelude> f 2 4 And: $ hugs Type :? for help Hugs.Base> let f x = x ^ 2 ERROR - Syntax error in expression (unexpected end of input) Hugs.Base> [Leaving Hugs] From duncan.coutts at worc.ox.ac.uk Mon May 5 18:37:31 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon May 5 18:30:39 2008 Subject: [Haskell-cafe] A Cabal problem In-Reply-To: <481F45C8.1070702@stilo.com> References: <481F123B.4060303@stilo.com> <20080505101032.22e04edc@trogdor> <481F45C8.1070702@stilo.com> Message-ID: <1210027051.30059.303.camel@localhost> On Mon, 2008-05-05 at 13:37 -0400, Mario Blazevic wrote: > Trevor Elliott wrote: > > Hi Mario, > > > > Is the name of the module within the Shell.hs file Main? If not, that > > could be your problem. > > You may be right, the module's name is Shell, not Main. GHC does not > have problem with that when "--main-is Shell" option is specified on the > command line. Is Cabal different? Is this documented somewhere? The ghc flag and the cabal field happen to have the same name but they do not mean quite the same thing. The ghc flag means "this *module* is the Main module, despite whatever the real name of the module might be" while the cabal flag means "this *file* is the Main module". The cabal concept is portable between all supported Haskell implementations and the ghc flag is ghc-specific. For the moment we have decided not to provide any support for this ghc-specific feature: http://hackage.haskell.org/trac/hackage/ticket/179 Do please add your comments/opinions to that ticket. Duncan From s.clover at gmail.com Mon May 5 19:21:22 2008 From: s.clover at gmail.com (Sterling Clover) Date: Mon May 5 19:15:32 2008 Subject: [Haskell-cafe] Help me speed up my program... or back to the issue of memoization In-Reply-To: <2d42915c0805050857tcc43ce6x76a661b801cb6575@mail.gmail.com> References: <2d42915c0805050857tcc43ce6x76a661b801cb6575@mail.gmail.com> Message-ID: I actually suspect that your "supremum" and "infimum" functions are the problem here -- they look like they might be accumulating thunks and blowing your stack. But beyond this, they're also o(n) for what could be effectively an o(log n) operation at the least, if you used ordered sets. I'd start improving performance here with some profiling, and then some strictness annotations, and then go from there. See http://www.haskell.org/haskellwiki/Performance for a whole bunch of good tips. --Sterl On Mon, May 5, 2008 at 11:57 AM, Kirill Kuvaldin wrote: > Hello, > > I wrote a program in haskell that works with lattice finite automata > (the generalization of notion of finite state automata). Let me post > the source code as it is not that long... > > The problem is that my algorithm that computes the run (see function > fun) of an automaton on the given word is not very optimal and takes a > loooong time as the input word gets larger... (e.g. try this one "run > m3 "11101101110001010101" ") > > Due to the nature of every haskell function being a referentially > transparent, I think I could have speeded up > its performance using memoization. > > I've read the page on haskell wiki > (http://www.haskell.org/haskellwiki/Memoization) but it didn't help me > because it looks I have to modify the actual function source code to > make use of memoized values. > What I'm looking for is a kind of a general solution (say, silver > bullet :) ) so that I will be able to use my function like > > > new_run = memoize run > > and the results of the "new_run" get automatically memoized. Probably > it makes sense to memoize deltaext func as well. > > Is that possible to do that in Haskell?? > > Thanks a lot! > Kirill > > > ======= SOURCE CODE ===== > > -- data type for lattice > data Lattice l = Lattice > [l] -- set of lattice elements > (l -> l -> l) -- supremum operation > (l -> l -> l) -- infimum operation > > -- returns the lowest lattice element > lattice0 (Lattice l s i) = l !! 0 > -- returns the greatest lattice element > lattice1 (Lattice l s i) = l !! ((length l)-1) > > -- supremum of 2 lattice elements > sup (Lattice l s i) x y = s x y > -- infimum of 2 lattice elements > inf (Lattice l s i) x y = i x y > > > supremum (Lattice l sup inf) [] = lattice0 (Lattice l sup inf) > supremum (Lattice l sup inf) (x:xs) = sup x (supremum (Lattice l sup inf) > xs) > > infimum (Lattice l sup inf) [] = lattice1 (Lattice l sup inf) > infimum (Lattice l sup inf) (x:xs) = inf x (infimum (Lattice l sup inf) > xs) > inf3 (Lattice l s i) x y z = infimum (Lattice l s i) [x,y,z] > > --- data type for Lattice Automata (LA) > data LA l state sym = LA > (Lattice l) -- lattice > [state] -- set of states > [sym] -- alphabet > (state -> sym -> state -> l) -- fuzzy transition function > (state -> l) -- fuzzy initial state > (state -> l) -- fuzzy final state > > --- extended transition function > deltaext :: (Eq state) => (LA l state sym) -> state -> [sym] -> state -> l > deltaext (LA l states chars delta sigma0 sigma1) x [] y = > if x == y then (lattice1 l) else (lattice0 l) > deltaext la@(LA l states chars delta sigma0 sigma1) x (a:w) y = > supremum l > [ inf l > (delta x a z) > (deltaext la z w y) > | z <- states] > > -- runs the Lattice Automaton on the given word > run la@(LA l states chars delta sigma0 sigma1) w = > supremum l > [ inf3 l > (sigma0 x) > (deltaext la x w y) > (sigma1 y) | x <- states, y <- states] > > --- > --- examples > --- > > l3 = Lattice [0.0, 0.5, 1.0] max min where > max x y = if x > y then x else y > min x y = if x < y then x else y > > m3 = LA l3 ['a', 'b'] ['0', '1'] delta sigma0 sigma1 where > delta 'a' '0' 'a' = 1 > delta 'a' '0' 'b' = 0.5 > delta 'b' '0' 'a' = 0.5 > delta 'b' '0' 'b' = 1 > delta 'a' '1' 'a' = 0 > delta 'a' '1' 'b' = 1 > delta 'b' '1' 'a' = 1 > delta 'b' '1' 'b' = 1 > sigma0 'a' = 1 > sigma0 'b' = 0.5 > sigma1 'a' = 0.5 > sigma1 'b' = 1 > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080505/ba460b37/attachment.htm From jules at jellybean.co.uk Tue May 6 02:02:20 2008 From: jules at jellybean.co.uk (Jules Bean) Date: Tue May 6 01:56:32 2008 Subject: [Haskell-cafe] Non-Overlapping Patterns In-Reply-To: <7.0.1.0.0.20080505154849.01d1e070@ntlworld.com> References: <7.0.1.0.0.20080505154849.01d1e070@ntlworld.com> Message-ID: <481FF46C.2000106@jellybean.co.uk> PR Stanley wrote: > Hi > isZero :: Int -> Bool > isZero 0 = True > isZero n | n /= 0 = False > > The order in which the above equations appear makes no difference to the > application of isZero. Does the Haskell interpreter rewrite patterns > into one single definition using some sort of switch or if construct? Something a bit like that. > Why does an equation without a guard have to be placed after the more > specific cases? It doesn't. You could write the above the other way around if you wished. > To put it another way, why doesn't the interpreter > identify the more specific cases and put them before the general ones. Because it general it's convenient to have overlapping cases, where the order matters, and be able to choose the order. Jules From apfelmus at quantentunnel.de Tue May 6 04:50:20 2008 From: apfelmus at quantentunnel.de (apfelmus) Date: Tue May 6 04:44:43 2008 Subject: [Haskell-cafe] Re: Control.Exception.evaluate - 'correct definition' not so correct In-Reply-To: <5ab17e790805041730o33b378e4u74f4f1f9e813e72b@mail.gmail.com> References: <20080503091917.GA5333@shion.is.fushizen.net> <5ab17e790805041730o33b378e4u74f4f1f9e813e72b@mail.gmail.com> Message-ID: Iavor Diatchki wrote: > apfelmus wrote: > >> According to the monad law >> >> f >>= return = f >> >> every (>>=) ought to be strict in its first argument, so it indeed >> seems that the implementation given in the documentation is wrong. > > From the monad law we can conclude only that "(>>= return)" is > strict, not (>>=) in general. Yes, I was too eager :) > For example, (>>=) for the reader monad is not strict in its first > argument: > > m >>= f = \r -> f (m r) r > > So, "(undefined >> return 2) = (return 2)" In other words, we have undefined >>= const (return x) = return x in the reader monad. Concerning the folklore that seq destroys the monad laws, I would like to remark that as long as we don't apply seq to arguments that are functions, everything is fine. When seq is applied to functions, already simple laws like f . id = f are trashed, so it's hardly surprising that the monad laws are broken willy-nilly. That's because seq can be used to distinguish between _|_ :: A -> B and \x -> _|_ :: A -> B although there shouldn't be a semantic difference between them. But it's true that in the case of evaluate , the monad laws are screwed up. The third equivalence would give evaluate _|_ >>= return ==> (return $! _|_) >>= return ==> _|_ >>= return and hence evaluate _|_ = _|_ which contradicts the first equivalence. In other words, it seems that in the presence of evaluate , the monad laws for IO are broken if we allow seq on values of type IO . Regards, apfelmus From wss at Cs.Nott.AC.UK Tue May 6 05:30:57 2008 From: wss at Cs.Nott.AC.UK (Wouter Swierstra) Date: Tue May 6 05:27:33 2008 Subject: [Haskell-cafe] Using Template Haskell to make type-safe database access In-Reply-To: <1210017744.4300.30.camel@localhost.localdomain> References: <1209760319.4242.4.camel@localhost.localdomain> <1210017744.4300.30.camel@localhost.localdomain> Message-ID: <6A286E8D-2C96-4E77-9FA3-077702204CBE@Cs.Nott.AC.UK> Hi Mads, >> I think there may a bit of problem with the approach you suggest: as >> the type returned by the query is computed by the SQL server (if I >> understand you correctly), it's very hard to do anything with the >> result of the query - the Haskell compiler has no idea what type the >> result has, so you can't do anything with it. I think it makes much >> more sense to bookkeep type information on the Haskell side. > > But you can ask the SQL server for the type of the result. In the TH > function you could: Thanks for your interesting reply. I'd forgotten that you can do I/O in TH's quotation monad. I agree that you can ask the database server for the type that an SQL expression will return. I don't understand metaprogramming enough to see how computing types with TH effects the rest of your program. Here's a concrete example. Suppose you have a query q that, when performed, will return a table storing integers. I can see how you can ask the SQL server for the type of the query, parse the response, and compute the Haskell type "[Int]". I'm not sure how to sum the integers returned by the query *in Haskell* (I know SQL can sum numbers too, but this is a simple example). What would happen when you apply Haskell's sum function to the result of the query? Does TH do enough compile time execution to see that the result is well-typed? Having the SQL server compute types for you does have other drawbacks, I think. For example, suppose your query projects out a field that does not exist. An error like that will only get caught once you ask the server for the type of your SQL expression. If you keep track of the types in Haskell, you can catch these errors earlier; Haskell's type system can pinpoint which part of the query is accessing the wrong field. I feel that if you really care about the type of your queries, you should guarantee type correctness by construction, rather than check it as an afterthought. > Of cause it all requires that the database have identical metadata at > run and compile -time. Either using the same database or a copy. > Though > one should note that HaskellDB has the same disadvantage. Actually > it do > not seem much of a disadvantage it all, as most code accessing SQL > databases depends on database metadata anyway. Perhaps I should explain my own thoughts on the subject a bit better. I got interested in this problem because I think it makes a nice example of dependent types "in the real world" - you really want to compute the *type* of a table based on the *value* of an SQL DESCRIBE. Nicolas Oury and I have written a draft paper describing some of our ideas: http://www.cs.nott.ac.uk/~wss/Publications/ThePowerOfPi.pdf Any comments are very welcome! Our proposal is not as nice as it could be (we would really like to have quotient types), but I hope it hints at what is possible. Wouter This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. From prstanley at ntlworld.com Tue May 6 05:34:54 2008 From: prstanley at ntlworld.com (PR Stanley) Date: Tue May 6 05:28:59 2008 Subject: [Haskell-cafe] Induction (help!) Message-ID: <7.0.1.0.0.20080506095651.01d0edb8@ntlworld.com> Hi I don't know what it is that I'm not getting where mathematical induction is concerned. This is relevant to Haskell so I wonder if any of you gents could explain in unambiguous terms the concept please. The wikipedia article offers perhaps the least obfuscated definition I've found so far but I would still like more clarity. The idea is to move onto inductive proof in Haskell. First, however, I need to understand the general mathematical concept. Top marks for clarity and explanation of technical terms. Thanks Paul From barsoap at web.de Tue May 6 06:53:46 2008 From: barsoap at web.de (Achim Schneider) Date: Tue May 6 06:48:12 2008 Subject: [Haskell-cafe] Re: Induction (help!) References: <7.0.1.0.0.20080506095651.01d0edb8@ntlworld.com> Message-ID: <20080506125346.2cbe2540@solaris> PR Stanley wrote: > Hi > I don't know what it is that I'm not getting where mathematical > induction is concerned. This is relevant to Haskell so I wonder if > any of you gents could explain in unambiguous terms the concept > please. The wikipedia article offers perhaps the least obfuscated > definition I've found so far but I would still like more clarity. > The idea is to move onto inductive proof in Haskell. First, however, > I need to understand the general mathematical concept. > > Top marks for clarity and explanation of technical terms. > Thanks > Paul > Induction -> from the small picture, extrapolate the big Deduction -> from the big picture, extrapolate the small Thus, in traditional logic, if you induce "all apples are red", simple observation of a single non-red apple quickly reduces your result to "at least one apple is not red on one side, all others may be red", i.e, you can't deduce "all apples are red" with your samples anymore. As used in mathematical induction, deductionaly sound: 1) Let "apple" be defined as being of continuous colour. 2) All "apples" are of the same colour 3) One observed "apple" is red Ergo: All "apples" are red Q.E.D. The question that is left is what the heck an "apple" is, and how it differs from these things you see at a supermarket. It could, from the above proof, be a symbol for "red rubberband". The samples are defined by the logic. Proposition 2 should be of course inferable from looking at one single apple, or you're going to look quite silly. It only works in mathematics, where you can have exact, either complete or part-wise, "copies" of something. If you can think of a real-world example where this works, please speak up. That's it. Aristotlean logic sucks. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. From matthew at wellquite.org Tue May 6 08:04:28 2008 From: matthew at wellquite.org (Matthew Sackman) Date: Tue May 6 07:58:52 2008 Subject: [Haskell-cafe] ANNOUNCE: Sessions 2008.5.2 Message-ID: <20080506120428.GC27635@arkansas.doc.ic.ac.uk> Howdy, I'm pleased to announce the general availability of Session Types for Haskell, version 2008.5.2. It is available from my website[0], Hackage[1][2] and I've just updated the online tutorial[3] to take into account the recent changes and new features. [0] http://wellquite.org/non-blog/sessions-2008.5.2.tar.gz [1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/sessions-2008.5.2 [2] http://hackage.haskell.org/ [3] http://wellquite.org/sessions/tutorial_1.html Session types are a means of describing communication between multiple threads, and statically verifying that the communication being performed is safe and conforms to the specification. The library supports multiple, concurrent channels being open and actions upon those channels being interleaved; forking new threads; the communication of process IDs, allowing threads to establish new channels between each other; higher-order channels, allowing an established channel to be sent over a channel to another process; and many other features common to session type systems. The significant new changes in this version are: a) an entirely new means to specify session types. This removes the old absolute indexing, is composeable and far more flexible and powerful than the old system. b) support for higher-order channels and session types allowing channels to be sent and received. This permits additional communication patterns such as two threads which are otherwise unaware of each other being able to communicate with one another by sending and receiving a channel via a common third party - delegation. Tests[4] and an example application[5] are available which should, in combination with the tutorial[6], explain how session types can be used. As ever, any feedback is very gratefully received. [4] http://wellquite.org/non-blog/sessions-browseable/Control/Concurrent/Session/Tests.hs [5] http://wellquite.org/non-blog/sessions-browseable/Control/Concurrent/Session/Queens.hs [6] http://wellquite.org/sessions/tutorial_1.html Matthew From patrik.osgnach at gmail.com Tue May 6 08:20:04 2008 From: patrik.osgnach at gmail.com (patrik osgnach) Date: Tue May 6 08:14:18 2008 Subject: [Haskell-cafe] help in tree folding Message-ID: <48204CF4.2040808@gmail.com> Hi. I'm learning haskell but i'm stuck on a generic tree folding exercise. i must write a function of this type treefoldr::(Eq a,Show a)=>(a->b->c)->c->(c->b->b)->b->Tree a->c Tree has type data (Eq a,Show a)=>Tree a=Void | Node a [Tree a] deriving (Eq,Show) as an example treefoldr (:) [] (++) [] (Node '+' [Node '*' [Node 'x' [], Node 'y' []], Node 'z' []]) must return "+?xyz" any help? (sorry for my bad english) From prstanley at ntlworld.com Tue May 6 08:37:03 2008 From: prstanley at ntlworld.com (PR Stanley) Date: Tue May 6 08:31:02 2008 Subject: [Haskell-cafe] Re: Induction (help!) In-Reply-To: <20080506125346.2cbe2540@solaris> References: <7.0.1.0.0.20080506095651.01d0edb8@ntlworld.com> <20080506125346.2cbe2540@solaris> Message-ID: <7.0.1.0.0.20080506131831.01d1eb50@ntlworld.com> > > Hi > > I don't know what it is that I'm not getting where mathematical > > induction is concerned. This is relevant to Haskell so I wonder if > > any of you gents could explain in unambiguous terms the concept > > please. The wikipedia article offers perhaps the least obfuscated > > definition I've found so far but I would still like more clarity. > > The idea is to move onto inductive proof in Haskell. First, however, > > I need to understand the general mathematical concept. > > > > Top marks for clarity and explanation of technical terms. > > Thanks > > Paul > > >Induction -> from the small picture, extrapolate the big >Deduction -> from the big picture, extrapolate the small > >Thus, in traditional logic, if you induce "all apples are red", simple >observation of a single non-red apple quickly reduces your result to >"at least one apple is not red on one side, all others may be red", >i.e, you can't deduce "all apples are red" with your samples anymore. Paul: surely, you wouldn't come up with an incorrect premise like "all apples are red" in the first place. Sorry, still none the wiser Cheers, Paul From matthew at wellquite.org Tue May 6 08:55:25 2008 From: matthew at wellquite.org (Matthew Sackman) Date: Tue May 6 08:50:00 2008 Subject: [Haskell-cafe] Re: ANNOUNCE: Sessions 2008.5.6 In-Reply-To: <20080506120428.GC27635@arkansas.doc.ic.ac.uk> References: <20080506120428.GC27635@arkansas.doc.ic.ac.uk> Message-ID: <20080506125525.GE27635@arkansas.doc.ic.ac.uk> On Tue, May 06, 2008 at 01:04:28PM +0100, Matthew Sackman wrote: > I'm pleased to announce the general availability of Session Types for > Haskell, version 2008.5.2. It is available from my website[0], > Hackage[1][2] and I've just updated the online tutorial[3] to take into > account the recent changes and new features. In an unforgettable act of incompetance, I forgot to check the package was actually usable and sadly it was missing a module. Thus 2008.5.6 is now released which I have verified builds and is usable. Apologies. http://wellquite.org/non-blog/sessions-2008.5.6.tar.gz http://hackage.haskell.org/cgi-bin/hackage-scripts/package/sessions-2008.5.6 Matthew From daniel.is.fischer at web.de Tue May 6 09:15:28 2008 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Tue May 6 09:07:51 2008 Subject: [Haskell-cafe] Induction (help!) In-Reply-To: <7.0.1.0.0.20080506095651.01d0edb8@ntlworld.com> References: <7.0.1.0.0.20080506095651.01d0edb8@ntlworld.com> Message-ID: <200805061515.28550.daniel.is.fischer@web.de> Am Dienstag, 6. Mai 2008 11:34 schrieb PR Stanley: > Hi > I don't know what it is that I'm not getting where mathematical > induction is concerned. This is relevant to Haskell so I wonder if > any of you gents could explain in unambiguous terms the concept please. > The wikipedia article offers perhaps the least obfuscated definition > I've found so far but I would still like more clarity. > The idea is to move onto inductive proof in Haskell. First, however, > I need to understand the general mathematical concept. > > Top marks for clarity and explanation of technical terms. > Thanks > Paul > Mathematical induction is a method to prove that some proposition P holds for all natural numbers. The principle of mathematical induction says that if 1) P(0) holds and 2) for every natural number n, if P(n) holds, then also P(n+1) holds, then P holds for all natural numbers. If you choose another base case, say k instead of 0, so use 1') P(k) holds, then you can deduce that P holds for all natural numbers greater than or equal to k. You can convince yourself of the validity of the principle the following ways: Direct: By 1), P(0) is true. Specialising n to 0 in 2), since we already know that P(0) holds, we deduce that P(1) holds, too. Now specialising n to 1 in 2), since we already know that P(1) is true, we deduce that P(2) is also true. And so on ... after k such specialisations we have found that P(k) is true. Indirect: Suppose there is an n1 such that P(n1) is false. Let n0 be the smallest number for which P doesn't hold (there is one because there are only finitely many natural numbers less than or equal to n1. Technical term: the set of natural numbers is well-ordered, which means that every non-empty subset contains a smallest element). If n0 = 0, 1) doesn't hold, otherwise there is a natural number n (namely n0-1), for which P(n) holds but not P(n+1), so 2) doesn't hold. Example: The sum of the first n odd numbers is n^2, or 1 + 3 + ... + 2*n-1 = n^2. 1) Base case: a) n = 0: the sum of the first 0 odd numbers is 0 and 0^2 = 0. b) n = 1: the sum of the first 1 odd numbers is 1 and 1^2 = 1. 2) Let n be an arbitrary natural number. We prove that if the induction hypothesis - 1 + 3 + ... + 2*n-1 = n^2 - holds, then 1 + 3 + ... + 2*(n+1)-1 = (n+1)^2 holds, too. 1 + 3 + ... + 2*(n+1)-1 = (1 + 3 + ... + 2*n-1) + 2*(n+1)-1 = n^2 + 2*(n+1) -1 -- by the induction hypothesis = n^2 + 2*n + 1 = (n+1)^2 cqfd. Hope this helps, Daniel From barsoap at web.de Tue May 6 09:27:27 2008 From: barsoap at web.de (Achim Schneider) Date: Tue May 6 09:21:53 2008 Subject: [Haskell-cafe] Re: Induction (help!) References: <7.0.1.0.0.20080506095651.01d0edb8@ntlworld.com> <20080506125346.2cbe2540@solaris> <7.0.1.0.0.20080506131831.01d1eb50@ntlworld.com> Message-ID: <20080506152727.451d5771@solaris> PR Stanley wrote: > > > > Hi > > > I don't know what it is that I'm not getting where mathematical > > > induction is concerned. This is relevant to Haskell so I wonder if > > > any of you gents could explain in unambiguous terms the concept > > > please. The wikipedia article offers perhaps the least obfuscated > > > definition I've found so far but I would still like more clarity. > > > The idea is to move onto inductive proof in Haskell. First, > > > however, I need to understand the general mathematical concept. > > > > > > Top marks for clarity and explanation of technical terms. > > > Thanks > > > Paul > > > > >Induction -> from the small picture, extrapolate the big > >Deduction -> from the big picture, extrapolate the small > > > >Thus, in traditional logic, if you induce "all apples are red", > >simple observation of a single non-red apple quickly reduces your > >result to "at least one apple is not red on one side, all others may > >be red", i.e, you can't deduce "all apples are red" with your > >samples anymore. > > Paul: surely, you wouldn't come up with an incorrect premise > like "all apples are red" in the first place. > Sorry, still none the wiser > Cheers, > Paul well, "all 'apples' are 'red'" is the proof you want to make. And it can be correctly induced, if and only if you can prove that a) all 'apples' share the same behaviour regarding the property 'colour' b) one 'apple''s colour property is 'red' which leads you directly to c) every 'apple' (that is, potentially infinite many) 'apples' are 'red'. if b) concludes that one 'apples''s colour property is not 'red', of course, you can't say "all 'apples' are 'red'" and still write QED beneath your proof without having to admit that that wasn't what you wanted to demonstrate. As an example, you might construct a proof that every faculty of any number is positive: fac 0 = 1 fac n | n > 0 = n * (fac (n-1)) fac _ = undefined You don't have to go on to proving an infinite number of possible inputs, you only have to prove 1) that 1 is positive (by definition) 2) that any number greater than 0 is positive (by definition) 3) that multiplication of two positive numbers results in a positive number (by definition) 4) that only positive numbers get multiplicated (by analysing haskell's semantics, read: data flow). So, as soon as you have proved the properties of the fixed point, the whole, infinite set is proven. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. From mblazevic at stilo.com Tue May 6 09:43:23 2008 From: mblazevic at stilo.com (Mario Blazevic) Date: Tue May 6 09:37:37 2008 Subject: [Haskell-cafe] A Cabal problem In-Reply-To: <20080505104020.3e5d40bb@trogdor> References: <481F123B.4060303@stilo.com> <20080505101032.22e04edc@trogdor> <481F45C8.1070702@stilo.com> <20080505104020.3e5d40bb@trogdor> Message-ID: <4820607B.4090002@stilo.com> Trevor Elliott wrote: > On Mon, 05 May 2008 13:37:12 -0400 > Mario Blazevic wrote: > >> Trevor Elliott wrote: >>> Hi Mario, >>> >>> Is the name of the module within the Shell.hs file Main? If not, >>> that could be your problem. >> You may be right, the module's name is Shell, not Main. GHC >> does not have problem with that when "--main-is Shell" option is >> specified on the command line. Is Cabal different? Is this documented >> somewhere? > > Cabal doesn't pass the --main-is option, I believe because it is > specific to GHC. What you could do is add this flag in the ghc-options > field of your executable in the cabal file, like this: > > ghc-options: --main-is Shell That worked like charm, except the two dashes should be one (my mistake). Thank you. From lrpalmer at gmail.com Tue May 6 10:27:26 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Tue May 6 10:21:34 2008 Subject: [Haskell-cafe] Re: Control.Exception.evaluate - 'correct definition' not so correct In-Reply-To: References: <20080503091917.GA5333@shion.is.fushizen.net> <5ab17e790805041730o33b378e4u74f4f1f9e813e72b@mail.gmail.com> Message-ID: <7ca3f0160805060727n52bbe96fracd3d9a303f61ba3@mail.gmail.com> On Tue, May 6, 2008 at 2:50 AM, apfelmus wrote: > Concerning the folklore that seq destroys the monad laws, I would like > to remark that as long as we don't apply seq to arguments that are > functions, everything is fine. When seq is applied to functions, > already simple laws like > > f . id = f > > are trashed, so it's hardly surprising that the monad laws are broken > willy-nilly. That's because seq can be used to distinguish between > > _|_ :: A -> B and \x -> _|_ :: A -> B > > although there shouldn't be a semantic difference between them. It seems that there is a culture developing where people intentionally ignore the existence of seq when reasoning about Haskell. Indeed I've heard many people argue that it shouldn't be in the language as it is now, that instead it should be a typeclass. I wonder if it's possible for the compiler to do more aggressive optimizations if it, too, ignored the existence of seq. Would it make it easier to do various sorts of lambda lifting, and would it make strictness analysis easier? Luke From allbery at ece.cmu.edu Tue May 6 10:28:23 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Tue May 6 10:22:43 2008 Subject: [Haskell-cafe] Re: Induction (help!) In-Reply-To: <7.0.1.0.0.20080506131831.01d1eb50@ntlworld.com> References: <7.0.1.0.0.20080506095651.01d0edb8@ntlworld.com> <20080506125346.2cbe2540@solaris> <7.0.1.0.0.20080506131831.01d1eb50@ntlworld.com> Message-ID: <977A1A3B-2B00-406E-B56D-CE23279B03C2@ece.cmu.edu> On 2008 May 6, at 8:37, PR Stanley wrote: >> Thus, in traditional logic, if you induce "all apples are red", >> simple >> observation of a single non-red apple quickly reduces your result to >> "at least one apple is not red on one side, all others may be red", >> i.e, you can't deduce "all apples are red" with your samples anymore. > > Paul: surely, you wouldn't come up with an incorrect premise > like "all apples are red" in the first place. You could come up with it as a hypothesis, if you've never seen a green or golden apple. This is all that's needed; induction starts with "*if* P". However, the real world is a really lousy way to understand inductive logic: you can come up with hypotheses (base cases), but figuring out *what* the inductive step is is difficult at best --- never mind the impossibility of *proving* such. Here's what we're trying to assert: IF... you have a red apple AND YOU CAN PROVE... that another related apple is also red THE YOU CAN CONCLUDE... that all such related apples are red From a mathematical perspective this is impossible; we haven't defined "apple", much less "related apple". In other words, we can't assert either a hypothesis or an inductive case! So much for the real world. This only provides a way to construct if-thens, btw; it's easy to construct such that are false. In mathematics you can sometimes resolve this by constructing a new set for which the hypothesis does hold: for example, if you start with a proposition `P(n) : n is a natural number' and use the inductive case `P(n-1) : n-1 is a natural number', you run into trouble with n=0. If you add the concept of negative numbers, you come up with a new proposition: `P(n): n is an integer'. This is more or less how the mathematical notion of integer came about, as naturals came from whole numbers (add 0) and complex numbers came from reals (add sqrt(-1)). -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From lrpalmer at gmail.com Tue May 6 10:31:26 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Tue May 6 10:25:35 2008 Subject: [Haskell-cafe] help in tree folding In-Reply-To: <48204CF4.2040808@gmail.com> References: <48204CF4.2040808@gmail.com> Message-ID: <7ca3f0160805060731t78bf5573ld97c1c4f2f15da5e@mail.gmail.com> On Tue, May 6, 2008 at 6:20 AM, patrik osgnach wrote: > Hi. I'm learning haskell but i'm stuck on a generic tree folding exercise. i > must write a function of this type > treefoldr::(Eq a,Show a)=>(a->b->c)->c->(c->b->b)->b->Tree a->c > Tree has type > data (Eq a,Show a)=>Tree a=Void | Node a [Tree a] deriving (Eq,Show) > as an example treefoldr (:) [] (++) [] (Node '+' [Node '*' [Node 'x' [], > Node 'y' []], Node 'z' []]) > must return "+?xyz" > any help? > (sorry for my bad english) Functions like this are very abstract, but are also quite nice in that there's basically only one way to write them given the types. What have you tried so far? This function needs to be recursive, so what arguments should it give to its recursive calls, and where should it plug the results? It also helps, as you're writing, to keep meticulous track of the the types of everything you have and the type you need, and that will tell you what you need to write next. Luke From ekmett at gmail.com Tue May 6 10:34:12 2008 From: ekmett at gmail.com (Edward Kmett) Date: Tue May 6 10:28:38 2008 Subject: [Haskell-cafe] ANNOUNCE: category-extras 0.44.2 Message-ID: <7fb8f82f0805060734x4e682afcm7a5412ce08d58ffc@mail.gmail.com> Dan Doel asked me to roll category-extras into my nascent comonad transformer library, and the result is category-extras 0.44.2! So since Dan's release a couple of weeks ago ( http://www.haskell.org/pipermail/haskell-cafe/2008-April/042240.html) we have added: * Comonad Transformers. Context/ContextT, Reader/ReaderT. * A suite of Bifunctors and combinators in Control.Bifunctor.* -- we attach most of the logic usually associated with a monoidal/comonoidal category to the individual Bifunctor since Hask is a rich category to begin with. * A suite of Functors and combinators in Control.Functor.* * Pointed and copointed functors. * Control.Recursion has been broken out into a Control.Morphism.* and recoded to use a simpler distributive law. * Type Indexed versions of Applicatives, Monads, and Comonads (including Diatchki's Indexed State and Wadler's Delimited Continuation Parameterized Monad) * Parameterized Monads a la Ghani and Johann's paper ICFP 07 paper, and their Applicative and comonadic dual. * Higher-order hylo-, cata- and ana- morphisms. * Higher-order Monads a la Ghani and Johann and their comonadic equivalents. * Kan extensions. * BiKleisli arrows as seen in Uustalu and Vene's Signals and Comonads and SIGFPE's recent posts * The Pointer comonad * Grabbed Iavor Diatchki's value-supply and rolled it in as Control.Comonad.Supply to make it clearer that it is a comonad, and pave the way towards a Supply comonad transformer * A richer set of compositions to allow for construction of comonads and monads not only from adjunctions, but also from pre-composition or post-composition of a monad with a pointed functor, and similarly pre-composition and post-composition of a comonad with a copointed functor. * Generic functor zapping, zipping, unzipping, and cozipping as mentioned recently on http://comonad.com/reader There is still a lot to do in terms of adding back a lot of the documentation from the original, documenting the extensions and fleshing out all of the definable instances as the concepts have grown exceptionally fine-grained. I definitely welcome feedback and additions. In particular if you were using a feature that was supported by the old library or is unnatural to program in the current one, let me know. My goal is to gather a lot of this esoterica into one place and integrate it into something cohesive. HEAD: haddock http://comonad.com/haskell/category-extras/dist/doc/html/category-extras/ darcs http://comonad.com/haskell/category-extras/ Release: package http://hackage.haskell.org/cgi-bin/hackage-scripts/package/category-extras-0.44.2 -Edward Kmett -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080506/22408887/attachment-0001.htm From lrpalmer at gmail.com Tue May 6 10:36:07 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Tue May 6 10:30:23 2008 Subject: [Haskell-cafe] Re: Induction (help!) In-Reply-To: <20080506125346.2cbe2540@solaris> References: <7.0.1.0.0.20080506095651.01d0edb8@ntlworld.com> <20080506125346.2cbe2540@solaris> Message-ID: <7ca3f0160805060736g180c84e6te792f9c9048dc93d@mail.gmail.com> On Tue, May 6, 2008 at 4:53 AM, Achim Schneider wrote: > PR Stanley wrote: > > > Hi > > I don't know what it is that I'm not getting where mathematical > > induction is concerned. This is relevant to Haskell so I wonder if > > any of you gents could explain in unambiguous terms the concept > > please. The wikipedia article offers perhaps the least obfuscated > > definition I've found so far but I would still like more clarity. > > The idea is to move onto inductive proof in Haskell. First, however, > > I need to understand the general mathematical concept. > > > > Top marks for clarity and explanation of technical terms. > > Thanks > > Paul > > > Induction -> from the small picture, extrapolate the big > Deduction -> from the big picture, extrapolate the small Induction has two meanings in mathematics, and I don't believe this is the type of induction the OP was asking about. See Daniel Fischer's response for the type you are asking about, and try not to be confused by the irrelevant discussion about inductive logic. Luke > Thus, in traditional logic, if you induce "all apples are red", simple > observation of a single non-red apple quickly reduces your result to > "at least one apple is not red on one side, all others may be red", > i.e, you can't deduce "all apples are red" with your samples anymore. > > As used in mathematical induction, deductionaly sound: > > 1) Let "apple" be defined as being of continuous colour. > 2) All "apples" are of the same colour > 3) One observed "apple" is red > Ergo: All "apples" are red > > Q.E.D. > > > The question that is left is what the heck an "apple" is, and how it > differs from these things you see at a supermarket. It could, from the > above proof, be a symbol for "red rubberband". The samples are defined > by the logic. > > Proposition 2 should be of course inferable from looking at one single > apple, or you're going to look quite silly. It only works in > mathematics, where you can have exact, either complete or part-wise, > "copies" of something. If you can think of a real-world example where > this works, please speak up. > > That's it. Aristotlean logic sucks. > > -- > (c) this sig last receiving data processing entity. Inspect headers for > past copyright information. All rights reserved. Unauthorised copying, > hiring, renting, public performance and/or broadcasting of this > signature prohibited. > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From byorgey at gmail.com Tue May 6 10:38:41 2008 From: byorgey at gmail.com (Brent Yorgey) Date: Tue May 6 10:32:52 2008 Subject: [Haskell-cafe] Induction (help!) In-Reply-To: <7.0.1.0.0.20080506095651.01d0edb8@ntlworld.com> References: <7.0.1.0.0.20080506095651.01d0edb8@ntlworld.com> Message-ID: <22fcbd520805060738x4be0a941r452f86426dcf0f9d@mail.gmail.com> On Tue, May 6, 2008 at 5:34 AM, PR Stanley wrote: > Hi > I don't know what it is that I'm not getting where mathematical induction > is concerned. This is relevant to Haskell so I wonder if any of you gents > could explain in unambiguous terms the concept please. > The wikipedia article offers perhaps the least obfuscated definition I've > found so far but I would still like more clarity. > The idea is to move onto inductive proof in Haskell. First, however, I need > to understand the general mathematical concept. > > Top marks for clarity and explanation of technical terms. > Thanks > Paul > For a more intuitive view, mathematical induction (at least, induction over the integers) is like knocking over a chain of dominoes. To knock over the whole (possibly infinite!) chain, you need two things: 1. You need to make sure that each domino is close enough to knock over the next. 2. You need to actually knock over the first domino. Relating this to proving a proposition P for all nonnegative integers, step 1 is like proving that P(k) implies P(k+1) -- IF the kth domino gets knocked over (i.e. if P(k) is true), then it will also knock over the next one (P(k) implies P(k+1)). Step 2 is like proving the base case -- P(0) is true. Hopefully this helps you get a more intuitive view of what induction is all about; you can use some of the other responses to fill in more details. -Brent -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080506/2eaf5009/attachment.htm From byorgey at gmail.com Tue May 6 10:42:56 2008 From: byorgey at gmail.com (Brent Yorgey) Date: Tue May 6 10:37:06 2008 Subject: [Haskell-cafe] help in tree folding In-Reply-To: <48204CF4.2040808@gmail.com> References: <48204CF4.2040808@gmail.com> Message-ID: <22fcbd520805060742ked232cate31e436e21c9ee68@mail.gmail.com> On Tue, May 6, 2008 at 8:20 AM, patrik osgnach wrote: > Hi. I'm learning haskell but i'm stuck on a generic tree folding exercise. > i must write a function of this type > treefoldr::(Eq a,Show a)=>(a->b->c)->c->(c->b->b)->b->Tree a->c > Tree has type > data (Eq a,Show a)=>Tree a=Void | Node a [Tree a] deriving (Eq,Show) > as an example treefoldr (:) [] (++) [] (Node '+' [Node '*' [Node 'x' [], > Node 'y' []], Node 'z' []]) > must return "+?xyz" > any help? > (sorry for my bad english) > Having a (Tree a) parameter, where Tree is defined as an algebraic data type, also immediately suggests that you should do some pattern-matching to break treefoldr down into cases: treefoldr f y g z Void = ? treefoldr f y g z (Node x t) = ? -Brent -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080506/b395260e/attachment.htm From lrpalmer at gmail.com Tue May 6 10:56:19 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Tue May 6 10:50:26 2008 Subject: [Haskell-cafe] Induction (help!) In-Reply-To: <200805061515.28550.daniel.is.fischer@web.de> References: <7.0.1.0.0.20080506095651.01d0edb8@ntlworld.com> <200805061515.28550.daniel.is.fischer@web.de> Message-ID: <7ca3f0160805060756j42408484s85f82513a983febb@mail.gmail.com> After you grok induction over the naturals, you can start to think about structural induction, which is usually what we use in programming. They are related, and understanding one will help you understand the other (structural induction actually made more sense to me when I was learning, because I started as a programmer and then became a mathematician, so I thought in terms of data structures). So let's say you have a tree, and we want to count the number of leaves in the tree. data Tree = Leaf Int | Branch Tree Tree countLeaves :: Tree -> Int countLeaves (Leaf _) = 1 countLeaves (Branch l r) = countLeaves l + countLeaves r We want to prove that countLeaves is correct. So P(x) means "countLeaves x == the number of leaves in x". First we prove P(Leaf i), since leaves are the trees that have no subtrees. This is analogous to proving P(0) over the naturals. countLeaves (Leaf i) = 1, by definition of countLeaves. "Leaf i" has exactly one leaf, obviously. So countLeaves (Leaf i) is correct. Now to prove P(Branch l r), we get to assume that P holds for all of its subtrees, namely we get to assume P(l) and P(r). You can think of this as constructing an algorithm to prove P for any tree, and we have "already proved" it for l and r in our algorithm. This is analogous to proving P(n) => P(n+1) in the case of naturals. So: Assume P(l) and P(r). P(l) means "countLeaves l == the number of leaves in l" P(r) means "countLeaves r == the number of leaves in r" countLeaves (Branch l r) = countLeaves l + countLeaves r, by definition. And that is the number of leaves in "Branch l r", the sum of the number of leaves in its two subtress. Therefore P(Branch l r). Now that we have those two cases, we are done; P holds for any Tree whatsoever. In general you will have to do one such proof for each case of your data structure in order to prove a property for the whole thing. At each case you get to assume the property holds for all substructures. Generally not so many steps are written down. In fact in this example, most people who do this kind of thing a lot would write "straightforward induction", and that would be the whole proof :-) The analogy between structural induction and induction over the naturals is very strong; in fact induction over the naturals is just induction over this data structure: data Nat = Zero | Succ Nat Hope this helps. Luke On Tue, May 6, 2008 at 7:15 AM, Daniel Fischer wrote: > Am Dienstag, 6. Mai 2008 11:34 schrieb PR Stanley: > > > Hi > > I don't know what it is that I'm not getting where mathematical > > induction is concerned. This is relevant to Haskell so I wonder if > > any of you gents could explain in unambiguous terms the concept please. > > The wikipedia article offers perhaps the least obfuscated definition > > I've found so far but I would still like more clarity. > > The idea is to move onto inductive proof in Haskell. First, however, > > I need to understand the general mathematical concept. > > > > Top marks for clarity and explanation of technical terms. > > Thanks > > Paul > > > > Mathematical induction is a method to prove that some proposition P holds for > all natural numbers. > > The principle of mathematical induction says that if > 1) P(0) holds and > 2) for every natural number n, if P(n) holds, then also P(n+1) holds, > then P holds for all natural numbers. > > If you choose another base case, say k instead of 0, so use > 1') P(k) holds, > then you can deduce that P holds for all natural numbers greater than or equal > to k. > > You can convince yourself of the validity of the principle the following ways: > Direct: > By 1), P(0) is true. > Specialising n to 0 in 2), since we already know that P(0) holds, we deduce > that P(1) holds, too. > Now specialising n to 1 in 2), since we already know that P(1) is true, we > deduce that P(2) is also true. > And so on ... after k such specialisations we have found that P(k) is true. > > Indirect: > Suppose there is an n1 such that P(n1) is false. > Let n0 be the smallest number for which P doesn't hold (there is one because > there are only finitely many natural numbers less than or equal to n1. > Technical term: the set of natural numbers is well-ordered, which means that > every non-empty subset contains a smallest element). > If n0 = 0, 1) doesn't hold, otherwise there is a natural number n (namely > n0-1), for which P(n) holds but not P(n+1), so 2) doesn't hold. > > > Example: > The sum of the first n odd numbers is n^2, or > 1 + 3 + ... + 2*n-1 = n^2. > > 1) Base case: > a) n = 0: the sum of the first 0 odd numbers is 0 and 0^2 = 0. > b) n = 1: the sum of the first 1 odd numbers is 1 and 1^2 = 1. > > 2) Let n be an arbitrary natural number. We prove that if the induction > hypothesis - 1 + 3 + ... + 2*n-1 = n^2 - holds, then > 1 + 3 + ... + 2*(n+1)-1 = (n+1)^2 holds, too. > > 1 + 3 + ... + 2*(n+1)-1 > = (1 + 3 + ... + 2*n-1) + 2*(n+1)-1 > = n^2 + 2*(n+1) -1 -- by the induction hypothesis > = n^2 + 2*n + 1 > = (n+1)^2 > cqfd. > > Hope this helps, > Daniel > > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From hferreiro at udc.es Tue May 6 11:30:29 2008 From: hferreiro at udc.es (Henrique Ferreiro =?ISO-8859-1?Q?Garc=EDa?=) Date: Tue May 6 11:24:41 2008 Subject: [Haskell-cafe] license question Message-ID: <1210087829.6649.8.camel@macbook> Hello everybody, I have one question regarding a licensing issue. I am developing a library to parse and pretty-print the Core Erlang language and it is heavily based on the modules included in haskell-src. What I want to know is if I have to reproduce all of the LICENSE file included in that package with my name included in the copyright notice or what other thing do I have to do. Thanks in advance. -- Henrique Ferreiro Garc?a From barsoap at web.de Tue May 6 11:38:19 2008 From: barsoap at web.de (Achim Schneider) Date: Tue May 6 11:32:42 2008 Subject: [Haskell-cafe] Re: Induction (help!) References: <7.0.1.0.0.20080506095651.01d0edb8@ntlworld.com> <20080506125346.2cbe2540@solaris> <7ca3f0160805060736g180c84e6te792f9c9048dc93d@mail.gmail.com> Message-ID: <20080506173819.367e1acc@solaris> "Luke Palmer" wrote: > On Tue, May 6, 2008 at 4:53 AM, Achim Schneider > wrote: > > PR Stanley wrote: > > > > > Hi > > > I don't know what it is that I'm not getting where mathematical > > > induction is concerned. This is relevant to Haskell so I wonder > > > if any of you gents could explain in unambiguous terms the > > > concept please. The wikipedia article offers perhaps the least > > > obfuscated definition I've found so far but I would still like > > > more clarity. The idea is to move onto inductive proof in > > > Haskell. First, however, I need to understand the general > > > mathematical concept. > > > > > > Top marks for clarity and explanation of technical terms. > > > Thanks > > > Paul > > > > > Induction -> from the small picture, extrapolate the big > > Deduction -> from the big picture, extrapolate the small > > Induction has two meanings in mathematics, and I don't believe this is > the type of induction the OP was asking about. > > See Daniel Fischer's response for the type you are asking about, and > try not to be confused by the irrelevant discussion about inductive > logic. > I was referring to traditional logic in the aristotlean sense, I should have been more explicit there. The key difference is really whether you define (or proof) the big picture by the small picture, or try to make deductions about some already-existant big thing by the small picture you already have. The method is the same, but the intent and awareness of the model characteristic of your reasoning differ, thus leading to results that are either valid or invalid. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. From alfonso.acosta at gmail.com Tue May 6 12:34:36 2008 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Tue May 6 12:29:08 2008 Subject: [Haskell-cafe] Figuring out if an algebraic type is enumerated through Data.Generics? Message-ID: <6a7c66fc0805060934x68881110hf28622adaf843703@mail.gmail.com> Hi all, I'm writing a Hardware-oriented DSL deep-embedded in Haskell (similar to Lava, for those familiar with it). One of the goals of the language is to support polymorphic signals (i.e. we would like to allow signals to carry values of any type, including user-defined types) The embedded compiler has different backends: simulation, VHDL, graphical representation in GraphML ... The simulation backend manages to support polymorphic signals by forcing them to be Typeable. In that way, circuit functions, no matter what signals they process, can be transformed to Dynamic and included in the AST for later simulation. The situation is more complicated for the VHDL backend. The Typeable trick works just fine for translating a limited set of predefined types (e.g. tuples) but not for user-defined types, since the embedded-compiler doesn't have access to the user-defined type declarations. One possible solution to access the type-definition of signal values would be constraining them to instances of Data. Then, we could use dataTypeOf to get access to the type representation. (Another option would be using template Haskell's reify, but I would like to avoid that by now) It would certainly be difficult map any Haskell type to VHDL, so, by now we would be content to map enumerate algebraic types (i.e. algebraic types whose all data constructors have arity zero, e.g. data Colors = Green | Blue | Red) So, the question is. Is there a way to figure out the arity of data constructors using Data.Generics ? I'm totally new to generics, but (tell me if I'm wrong) it seems that Constr doesn't hold any information about the data-constructor arguments. Why is it so? Do you think there is a workoaround for this problem? (maybe using some other function from Data.Generics different to dataTypeOf?) Thanks in advance, Alfonso Acosta From RossBoylan at stanfordalumni.org Tue May 6 12:52:11 2008 From: RossBoylan at stanfordalumni.org (Ross Boylan) Date: Tue May 6 12:46:30 2008 Subject: [Haskell-cafe] Still no joy with parsec Message-ID: <1210092731.8213.62.camel@corn.betterworld.us> I kept getting parse failures when I ran my little Parsec TeX snippet on a sample code. Seeing that ghc6.8 had debugging, I upgraded to it, only to discover that I can't even get the code to compile. $ ghci GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Prelude> :load g [1 of 1] Compiling Main ( g.hs, interpreted ) g.hs:11:19: Couldn't match expected type `t1 -> GenParser Char () t' against inferred type `CharParser st ()' In the expression: reserved "\\begin" 1 In a 'do' expression: reserved "\\begin" 1 In the expression: do reserved "\\begin" 1 braces (many1 letter) Failed, modules loaded: none. Do parsec and 6.8 just not get along? More generally, how can I go about diagnosing such problems? Since I can't load it, I can't debug it or get :info on the types. It looks as if maybe it's expecting a Monad, but getting a parser. But I don't know why that would have changed vs using 6.6. More questions about the error messages. Where is the expected type, and where is the inferred type, coming from? I'm guessing the expected type is from the function signature and the position inside a do (or perhaps from the argument following the ; in the do?) and the inferred type is what I would just call the type of reserved "begin". And what is the 1 that appears after 'reserved "\\begin"'? An indicator that all occurrences of the text refer to the same spot in the program? Nesting level? Thanks. Ross P.S. There have been some issues with the Debian packaging of ghc6.8, so it's possible I'm bumping into them. I thought/hoped the problems were limited to non i386 architectures. Also, I'm pretty sure that the parsec code used by ghc6.6, ghc6.8, and hugs is all in different files. So conceivably the parsec source differs. I have ghc6 6.8.2-5 and libghc6-parsec-dev 2.1.0.0-2. Source: import Text.ParserCombinators.Parsec import qualified Text.ParserCombinators.Parsec.Token as P import Text.ParserCombinators.Parsec.Language(haskell) reserved = P.reserved haskell braces = P.braces haskell -- TeX example envBegin :: Parser String envBegin = do{ reserved "\\begin" 1 ; braces (many1 letter) } From ekmett at gmail.com Tue May 6 13:42:33 2008 From: ekmett at gmail.com (Edward Kmett) Date: Tue May 6 13:36:41 2008 Subject: [Haskell-cafe] Figuring out if an algebraic type is enumerated through Data.Generics? In-Reply-To: <7fb8f82f0805061041k12b7c86dr470723577addcb3@mail.gmail.com> References: <6a7c66fc0805060934x68881110hf28622adaf843703@mail.gmail.com> <7fb8f82f0805061041k12b7c86dr470723577addcb3@mail.gmail.com> Message-ID: <7fb8f82f0805061042v2d4045d0rccbcd556b97676f8@mail.gmail.com> On Tue, May 6, 2008 at 12:34 PM, Alfonso Acosta wrote: | So, the question is. Is there a way to figure out the arity of data | constructors using Data.Generics ? | I'm totally new to generics, but (tell me if I'm wrong) it seems that | Constr doesn't hold any information about the data-constructor | arguments. Why is it so? Hmrmm, Playing around with it, I was able to abuse gunfold and the reader comonad to answer the problem : fst $ (gunfold (\(i,_) -> (i+1,undefined)) (\r -> (0,r)) (toConstr "Hello") :: (Int,String)) returns 2, the arity of (:), the outermost constructor in "Hello" A longer version which does not depend on undefined would be to take and define a functor that discarded its contents like: > module Args where > import Data.Generics > newtype Args a = Args { runArgs :: Int } deriving (Read,Show) > tick :: Args (b -> r) -> Args r > tick (Args i) = Args (i + 1) > tock = const (Args 0) > argsInCons = runArgs $ (gunfold tick tock (toConstr "Hello") :: (Args String) Basically all I do is rely on the fact that gunfold takes the 'tick' argument and calls it repeatedly for each argument after a 'tock' base case. The use of the reader comonad or functor is to give gunfold a 'functor-like' argument to meet its type signature. -Edward Kmett From daniel.is.fischer at web.de Tue May 6 13:46:21 2008 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Tue May 6 13:38:44 2008 Subject: [Haskell-cafe] Still no joy with parsec In-Reply-To: <1210092731.8213.62.camel@corn.betterworld.us> References: <1210092731.8213.62.camel@corn.betterworld.us> Message-ID: <200805061946.21523.daniel.is.fischer@web.de> Am Dienstag, 6. Mai 2008 18:52 schrieb Ross Boylan: > > Source: > import Text.ParserCombinators.Parsec > import qualified Text.ParserCombinators.Parsec.Token as P > import Text.ParserCombinators.Parsec.Language(haskell) > reserved = P.reserved haskell > braces = P.braces haskell > > > -- TeX example > > envBegin :: Parser String > envBegin = do{ reserved "\\begin" > 1 ; braces (many1 letter) ^^^^^ > } Right there appears the '1' that irritated you. Remove it from the source file, and ghc is happy. From derek.a.elkins at gmail.com Tue May 6 13:44:50 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Tue May 6 13:39:05 2008 Subject: [Haskell-cafe] Still no joy with parsec In-Reply-To: <1210092731.8213.62.camel@corn.betterworld.us> References: <1210092731.8213.62.camel@corn.betterworld.us> Message-ID: <1210095890.5514.35.camel@derek-laptop> On Tue, 2008-05-06 at 09:52 -0700, Ross Boylan wrote: > I kept getting parse failures when I ran my little Parsec TeX snippet on > a sample code. Seeing that ghc6.8 had debugging, I upgraded to it, only > to discover that I can't even get the code to compile. > > $ ghci > GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help > Loading package base ... linking ... done. > Prelude> :load g > [1 of 1] Compiling Main ( g.hs, interpreted ) > > g.hs:11:19: > Couldn't match expected type `t1 -> GenParser Char () t' > against inferred type `CharParser st ()' > In the expression: reserved "\\begin" 1 > In a 'do' expression: reserved "\\begin" 1 > In the expression: > do reserved "\\begin" 1 > braces (many1 letter) > Failed, modules loaded: none. Look at the expression. > Do parsec and 6.8 just not get along? > > More generally, how can I go about diagnosing such problems? Since I > can't load it, I can't debug it or get :info on the types. > > It looks as if maybe it's expecting a Monad, but getting a parser. But > I don't know why that would have changed vs using 6.6. > > More questions about the error messages. Where is the expected type, > and where is the inferred type, coming from? I'm guessing the expected > type is from the function signature and the position inside a do (or > perhaps from the argument following the ; in the do?) and the inferred > type is what I would just call the type of reserved "begin". > > And what is the 1 that appears after 'reserved "\\begin"'? An indicator > that all occurrences of the text refer to the same spot in the program? > Nesting level? Look at your code. > Source: > import Text.ParserCombinators.Parsec > import qualified Text.ParserCombinators.Parsec.Token as P > import Text.ParserCombinators.Parsec.Language(haskell) > reserved = P.reserved haskell > braces = P.braces haskell > > > -- TeX example > > envBegin :: Parser String > envBegin = do{ reserved "\\begin" > 1 ; braces (many1 letter) > } From RossBoylan at stanfordalumni.org Tue May 6 13:52:00 2008 From: RossBoylan at stanfordalumni.org (Ross Boylan) Date: Tue May 6 13:46:17 2008 Subject: [Haskell-cafe] Still no joy with parsec In-Reply-To: <200805061946.21523.daniel.is.fischer@web.de> References: <1210092731.8213.62.camel@corn.betterworld.us> <200805061946.21523.daniel.is.fischer@web.de> Message-ID: <1210096320.2494.1.camel@corn.betterworld.us> On Tue, 2008-05-06 at 19:46 +0200, Daniel Fischer wrote: > Am Dienstag, 6. Mai 2008 18:52 schrieb Ross Boylan: > > > > Source: > > import Text.ParserCombinators.Parsec > > import qualified Text.ParserCombinators.Parsec.Token as P > > import Text.ParserCombinators.Parsec.Language(haskell) > > reserved = P.reserved haskell > > braces = P.braces haskell > > > > > > -- TeX example > > > > envBegin :: Parser String > > envBegin = do{ reserved "\\begin" > > 1 ; braces (many1 letter) > ^^^^^ > > } > > Right there appears the '1' that irritated you. Remove it from the source > file, and ghc is happy. Ouch! I can't believe I missed that. Thank you. I'm still interested in some of the more general questions I had, if anyone on the list can help. Ross From patrik.osgnach at gmail.com Tue May 6 16:38:21 2008 From: patrik.osgnach at gmail.com (patrik osgnach) Date: Tue May 6 14:32:34 2008 Subject: [Haskell-cafe] help in tree folding In-Reply-To: <7ca3f0160805060731t78bf5573ld97c1c4f2f15da5e@mail.gmail.com> References: <48204CF4.2040808@gmail.com> <7ca3f0160805060731t78bf5573ld97c1c4f2f15da5e@mail.gmail.com> Message-ID: <4820C1BD.2000405@gmail.com> Luke Palmer ha scritto: > On Tue, May 6, 2008 at 6:20 AM, patrik osgnach wrote: >> Hi. I'm learning haskell but i'm stuck on a generic tree folding exercise. i >> must write a function of this type >> treefoldr::(Eq a,Show a)=>(a->b->c)->c->(c->b->b)->b->Tree a->c >> Tree has type >> data (Eq a,Show a)=>Tree a=Void | Node a [Tree a] deriving (Eq,Show) >> as an example treefoldr (:) [] (++) [] (Node '+' [Node '*' [Node 'x' [], >> Node 'y' []], Node 'z' []]) >> must return "+?xyz" >> any help? >> (sorry for my bad english) > > Functions like this are very abstract, but are also quite nice in that > there's basically only one way to write them given the types. > > What have you tried so far? This function needs to be recursive, so > what arguments should it give to its recursive calls, and where should > it plug the results? > > It also helps, as you're writing, to keep meticulous track of the the > types of everything you have and the type you need, and that will tell > you what you need to write next. > > Luke so far i have tried this treefoldr f x g y Void = x treefoldr f x g y (Node a []) = f a y treefoldr f x g y (Node a (t:ts)) = treefoldr f x g (g (treefoldr f x g y t) y) (Node a ts) but it is clearly incorrect. this functions takes as arguments two functions and two zeros (one for the empty tree and one for the empty tree list). thanks for the answer Patrik From patrik.osgnach at gmail.com Tue May 6 16:40:59 2008 From: patrik.osgnach at gmail.com (patrik osgnach) Date: Tue May 6 14:35:13 2008 Subject: [Haskell-cafe] help in tree folding In-Reply-To: <22fcbd520805060742ked232cate31e436e21c9ee68@mail.gmail.com> References: <48204CF4.2040808@gmail.com> <22fcbd520805060742ked232cate31e436e21c9ee68@mail.gmail.com> Message-ID: <4820C25B.3080906@gmail.com> Brent Yorgey ha scritto: > On Tue, May 6, 2008 at 8:20 AM, patrik osgnach > wrote: > >> Hi. I'm learning haskell but i'm stuck on a generic tree folding exercise. >> i must write a function of this type >> treefoldr::(Eq a,Show a)=>(a->b->c)->c->(c->b->b)->b->Tree a->c >> Tree has type >> data (Eq a,Show a)=>Tree a=Void | Node a [Tree a] deriving (Eq,Show) >> as an example treefoldr (:) [] (++) [] (Node '+' [Node '*' [Node 'x' [], >> Node 'y' []], Node 'z' []]) >> must return "+?xyz" >> any help? >> (sorry for my bad english) >> > > Having a (Tree a) parameter, where Tree is defined as an algebraic data > type, also immediately suggests that you should do some pattern-matching to > break treefoldr down into cases: > > treefoldr f y g z Void = ? > treefoldr f y g z (Node x t) = ? > > -Brent so far i have tried treefoldr f x g y Void = x treefoldr f x g y (Node a []) = f a y treefoldr f x g y (Node a (t:ts)) = treefoldr f x g (g (treefoldr f x g y t) y) (Node a ts) but it is incorrect. i can't figure out how to build the recursive call thanks for the answer Patrik From daniel.is.fischer at web.de Tue May 6 14:58:22 2008 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Tue May 6 14:50:43 2008 Subject: [Haskell-cafe] Still no joy with parsec In-Reply-To: <1210092731.8213.62.camel@corn.betterworld.us> References: <1210092731.8213.62.camel@corn.betterworld.us> Message-ID: <200805062058.22189.daniel.is.fischer@web.de> Am Dienstag, 6. Mai 2008 18:52 schrieb Ross Boylan: > > g.hs:11:19: > Couldn't match expected type `t1 -> GenParser Char () t' > against inferred type `CharParser st ()' > In the expression: reserved "\\begin" 1 > In a 'do' expression: reserved "\\begin" 1 > In the expression: > do reserved "\\begin" 1 > braces (many1 letter) > Failed, modules loaded: none. > > More generally, how can I go about diagnosing such problems? Since I > can't load it, I can't debug it or get :info on the types. > > It looks as if maybe it's expecting a Monad, but getting a parser. But (GenParser tok st) is a monad. GenParser tok st a is the type of parsers which parse lists of tok, using a state of type st and returning a value of type a. There are two type synonyms I remember, type CharParser st a = GenParser Char st a and type Parser a = GenParser Char () a Now let's look at what ghc does with the code envBegin :: Parser String envBegin = do reserved "\\begin" 1 braces (many1 letter) which you had (btw, had you used layout instead of explicit braces, the 1 in the first column of the line would have led to a parse error and been more obvious). From the last expression, braces (many1 letter), which has type CharParser st [Char], the type checker infers that the whole do-expression has the same type. So the first expression in the do-block must have type CharParser st a, or, not using the type synonym, GenParser Char st a. The type signature says that the user state st is actually (), which is okay, because it's a more specific type. Now that first expression is parsed (reserved "\\begin") 1 , so the subexpression (reserved "\\begin") is applied to an argument and has to return a value of type GenParser Char st a, hence the type checker expects the type t1 -> GenParser Char st t for (reserved "\\begin"). That is the expected type from the error message, with st specialised to () due to the type signature. Next, the type of the expression (reserved "\\begin") is inferred. 'reserved' is defined as P.reserved haskell, P.reserved has type P.TokenParser st -> String -> CharParser st () haskell has type P.TokenParser st , so reserved has type String -> CharParser st () and hence (reserved "\\begin") has type CharParser st () , that is the inferred type of the error message. Since one of the two is a function type and the other not, these types do not match. The error message Couldn't match expected type `thing' against inferred type `umajig' In the expression: foo bar oops tells you that from the use of (foo bar) in that expression, the type checker expects it to have type `thing', but the type inference of the expression (foo bar), without surrounding context, yields type `umajig', which can't be matched (or unified) with `thing'. HTH, Daniel > I don't know why that would have changed vs using 6.6. > > More questions about the error messages. Where is the expected type, > and where is the inferred type, coming from? I'm guessing the expected > type is from the function signature and the position inside a do (or > perhaps from the argument following the ; in the do?) and the inferred > type is what I would just call the type of reserved "begin". > > And what is the 1 that appears after 'reserved "\\begin"'? An indicator > that all occurrences of the text refer to the same spot in the program? > Nesting level? > > Thanks. > Ross > > P.S. There have been some issues with the Debian packaging of ghc6.8, > so it's possible I'm bumping into them. I thought/hoped the problems > were limited to non i386 architectures. Also, I'm pretty sure that the > parsec code used by ghc6.6, ghc6.8, and hugs is all in different files. > So conceivably the parsec source differs. I have ghc6 6.8.2-5 and > libghc6-parsec-dev 2.1.0.0-2. > > Source: > import Text.ParserCombinators.Parsec > import qualified Text.ParserCombinators.Parsec.Token as P > import Text.ParserCombinators.Parsec.Language(haskell) > reserved = P.reserved haskell > braces = P.braces haskell > > > -- TeX example > > envBegin :: Parser String > envBegin = do{ reserved "\\begin" > 1 ; braces (many1 letter) > } > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From daniel.is.fischer at web.de Tue May 6 15:16:00 2008 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Tue May 6 15:08:20 2008 Subject: [Haskell-cafe] help in tree folding In-Reply-To: <4820C25B.3080906@gmail.com> References: <48204CF4.2040808@gmail.com> <22fcbd520805060742ked232cate31e436e21c9ee68@mail.gmail.com> <4820C25B.3080906@gmail.com> Message-ID: <200805062116.00279.daniel.is.fischer@web.de> Am Dienstag, 6. Mai 2008 22:40 schrieb patrik osgnach: > Brent Yorgey ha scritto: > > On Tue, May 6, 2008 at 8:20 AM, patrik osgnach > > > > wrote: > >> Hi. I'm learning haskell but i'm stuck on a generic tree folding > >> exercise. i must write a function of this type > >> treefoldr::(Eq a,Show a)=>(a->b->c)->c->(c->b->b)->b->Tree a->c > >> Tree has type > >> data (Eq a,Show a)=>Tree a=Void | Node a [Tree a] deriving (Eq,Show) > >> as an example treefoldr (:) [] (++) [] (Node '+' [Node '*' [Node 'x' [], > >> Node 'y' []], Node 'z' []]) > >> must return "+?xyz" > >> any help? > >> (sorry for my bad english) > > > > Having a (Tree a) parameter, where Tree is defined as an algebraic data > > type, also immediately suggests that you should do some pattern-matching > > to break treefoldr down into cases: > > > > treefoldr f y g z Void = ? > > treefoldr f y g z (Node x t) = ? > > > > -Brent > > so far i have tried > treefoldr f x g y Void = x Yes, nothing else could be done. > treefoldr f x g y (Node a []) = f a y Not bad. But actually there's no need to treat nodes with and without children differently. Let's see: treefoldr f x g y (Node v ts) should have type c, and it should use v. We have f :: a -> b -> c x :: c g :: c -> b -> b y :: b v :: a. The only thing which produces a value of type c using a value of type a is f, so we must have treefoldr f x g y (Node v ts) = f v someExpressionUsing'ts' where someExpressionUsing'ts' :: b. The only thing we have which produces a value of type b is g, so someExpressionUsing'ts' must ultimately be g something somethingElse. Now take a look at the code and type of foldr, that might give you the idea. Cheers, Daniel > treefoldr f x g y (Node a (t:ts)) = treefoldr f x g (g (treefoldr f x g > y t) y) (Node a ts) > but it is incorrect. i can't figure out how to build the recursive call > thanks for the answer > Patrik From duncan.coutts at worc.ox.ac.uk Tue May 6 16:05:42 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue May 6 15:58:44 2008 Subject: [Haskell-cafe] A Cabal problem In-Reply-To: <4820607B.4090002@stilo.com> References: <481F123B.4060303@stilo.com> <20080505101032.22e04edc@trogdor> <481F45C8.1070702@stilo.com> <20080505104020.3e5d40bb@trogdor> <4820607B.4090002@stilo.com> Message-ID: <1210104342.30059.366.camel@localhost> On Tue, 2008-05-06 at 09:43 -0400, Mario Blazevic wrote: > Trevor Elliott wrote: > > Cabal doesn't pass the --main-is option, I believe because it is > > specific to GHC. What you could do is add this flag in the ghc-options > > field of your executable in the cabal file, like this: > > > > ghc-options: --main-is Shell > > That worked like charm, except the two dashes should be one (my > mistake). Thank you. Note that hackage will reject packages that use "ghc-options: -main-is" with the message that it is not portable. The rationale is that unlike other non-portable extensions, it is easy to change to make it portable: http://hackage.haskell.org/trac/hackage/ticket/179 If you want to argue for supporting this ghc extension and/or implement support (possibly with workaround support for the other haskell implementations) then please do comment on the above ticket. Duncan From prstanley at ntlworld.com Tue May 6 17:34:44 2008 From: prstanley at ntlworld.com (PR Stanley) Date: Tue May 6 17:28:45 2008 Subject: [Haskell-cafe] Induction (help!) In-Reply-To: <7ca3f0160805060756j42408484s85f82513a983febb@mail.gmail.co m> References: <7.0.1.0.0.20080506095651.01d0edb8@ntlworld.com> <200805061515.28550.daniel.is.fischer@web.de> <7ca3f0160805060756j42408484s85f82513a983febb@mail.gmail.com> Message-ID: <7.0.1.0.0.20080506223340.01dc88a0@ntlworld.com> After you grok induction over the naturals, you can start to think about structural induction, which is usually what we use in programming. They are related, and understanding one will help you understand the other (structural induction actually made more sense to me when I was learning, because I started as a programmer and then became a mathematician, so I thought in terms of data structures). Paul: I was hoping that understanding the classic mathematical concept would help me appreciate the structural computer science) variation better. I don't know what it is about induction that I'm not seeing. It's so frustrating! Deduction in spite of the complexity in some parts makes perfect sense. This, however, is a different beast! So let's say you have a tree, and we want to count the number of leaves in the tree. data Tree = Leaf Int | Branch Tree Tree countLeaves :: Tree -> Int countLeaves (Leaf _) = 1 countLeaves (Branch l r) = countLeaves l + countLeaves r We want to prove that countLeaves is correct. So P(x) means "countLeaves x == the number of leaves in x". Paul: By 'correct' presumably you mean sound. First we prove P(Leaf i), since leaves are the trees that have no subtrees. This is analogous to proving P(0) over the naturals. Paul: I'd presume 'proof' here means applying the function to one leaf to see if it returns 1. If I'm not mistaken this is establishing the base case. countLeaves (Leaf i) = 1, by definition of countLeaves. "Leaf i" has exactly one leaf, obviously. So countLeaves (Leaf i) is correct. Now to prove P(Branch l r), we get to assume that P holds for all of its subtrees, namely we get to assume P(l) and P(r). Paul: How did you arrive at this decision? Why can we assume that P holds fr all its subtrees? You can think of this as constructing an algorithm to prove P for any tree, and we have "already proved" it for l and r in our algorithm. Paul: Is this the function definition for countLeaves? This is analogous to proving P(n) => P(n+1) in the case of naturals. Paul:I thought P(n) was the induction hypothesis and P(n+1) was the proof that the formula/property holds for the subsequent element in the sequence if P(n) is true. I don't see how countLeaves l and countLeaves r are analogous to P(n) and P(n+1). So: Assume P(l) and P(r). P(l) means "countLeaves l == the number of leaves in l" P(r) means "countLeaves r == the number of leaves in r" countLeaves (Branch l r) = countLeaves l + countLeaves r, by definition. And that is the number of leaves in "Branch l r", the sum of the number of leaves in its two subtress. Therefore P(Branch l r). Now that we have those two cases, we are done; P holds for any Tree whatsoever. In general you will have to do one such proof for each case of your data structure in order to prove a property for the whole thing. At each case you get to assume the property holds for all substructures. Generally not so many steps are written down. In fact in this example, most people who do this kind of thing a lot would write "straightforward induction", and that would be the whole proof :-) The analogy between structural induction and induction over the naturals is very strong; in fact induction over the naturals is just induction over this data structure: data Nat = Zero | Succ Nat Hope this helps. Luke From vigalchin at gmail.com Tue May 6 18:01:34 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Tue May 6 17:55:46 2008 Subject: [Haskell-cafe] TimeSpec Message-ID: <5ae4f2ba0805061501j73d05cdbwf3409a2b61b9529d@mail.gmail.com> Hello, I checked Hoogle for the POSIX data type TimeSpec. Nada. Does anybody know where the definition is? Thanks, Vasili -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080506/76269fdf/attachment.htm From daniel.is.fischer at web.de Tue May 6 18:51:25 2008 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Tue May 6 18:43:48 2008 Subject: [Haskell-cafe] Induction (help!) In-Reply-To: <7.0.1.0.0.20080506223340.01dc88a0@ntlworld.com> References: <7.0.1.0.0.20080506095651.01d0edb8@ntlworld.com> <7ca3f0160805060756j42408484s85f82513a983febb@mail.gmail.com> <7.0.1.0.0.20080506223340.01dc88a0@ntlworld.com> Message-ID: <200805070051.25953.daniel.is.fischer@web.de> Am Dienstag, 6. Mai 2008 23:34 schrieb PR Stanley: > After you grok induction over the naturals, you can start to think > about structural induction, which is usually what we use in > programming. They are related, and understanding one will help you > understand the other (structural induction actually made more sense to > me when I was learning, because I started as a programmer and then > became a mathematician, so I thought in terms of data structures). > Paul: I was hoping that understanding the classic mathematical > concept would help me appreciate the structural computer science) > variation better. Understanding either will help understanding the other, they're the same idea in different guise. > I don't know what it is about induction that I'm > not seeing. It's so frustrating! Deduction in spite of the complexity > in some parts makes perfect sense. This, however, is a different beast! > > So let's say you have a tree, and we want to count the number of > leaves in the tree. > > data Tree = Leaf Int | Branch Tree Tree > > countLeaves :: Tree -> Int > countLeaves (Leaf _) = 1 > countLeaves (Branch l r) = countLeaves l + countLeaves r > > We want to prove that countLeaves is correct. So P(x) means > "countLeaves x == the number of leaves in x". > Paul: By 'correct' presumably you mean sound. > > First we prove P(Leaf i), since leaves are the trees that have no > subtrees. This is analogous to proving P(0) over the naturals. > Paul: I'd presume 'proof' here means applying the function to one > leaf to see if it returns 1. If I'm not mistaken this is establishing > the base case. Yes, right. > > countLeaves (Leaf i) = 1, by definition of countLeaves. > "Leaf i" has exactly one leaf, obviously. > So countLeaves (Leaf i) is correct. > > Now to prove P(Branch l r), we get to assume that P holds for all of > its subtrees, namely we get to assume P(l) and P(r). > Paul: How did you arrive at this decision? Why can we assume that P > holds fr all its subtrees? It's the induction hypothesis. We could paraphrase the induction step as "If P holds for all cases of lesser complexity than x, then P also holds for x". In this example, the subtrees have lesser complexity than the entire tree (you could define complexity as depth). The induction step says "assuming P(l) and P(r), we can deduce P(Branch l r)", or, as a formula, forall l, r. ([P(l) and P(r)] ==> P(Branch l r)). > > You can think of this as constructing an algorithm to prove P for > any tree, and we have > "already proved" it for l and r in our algorithm. > Paul: Is this the function definition for countLeaves? > > This is analogous to proving P(n) => P(n+1) in the case of naturals. > Paul:I thought P(n) was the induction hypothesis and P(n+1) was the > proof that the formula/property holds for the subsequent element in > the sequence if P(n) is true. I don't see how countLeaves l and > countLeaves r are analogous to P(n) and P(n+1). (countLeaves l == number of leaves in l) and (countLeaves r == number of leaves in r) together are analogous to P(n). Proving forall l, r. ([P(l) and P(r)] ==> P(Branch l r)) is analogous to proving forall n. [P(n) ==> P(n+1)]. Let me phrase mathematical induction differently. To prove forall natural numbers n. P(n) , it is sufficient to prove 1) P(0) and 2) forall n. [P(n) implies P(n+1)] . And structural induction for lists: To prove forall (finite) lists l . P(l) , you prove 1L) P([ ]) -- the base case is the empty list 2L) forall x, l. [P(l) ==> P(x:l)] and for trees: to prove forall trees t. P(t) , you prove 1T) forall i. P(Leaf i) 2T) forall l, r. ([P(l) and P(r)] ==> P(Branch l r)). In all three cases, the pattern is the same. The key thing is number 2, which says if P holds for one level of complexity, then it also holds for the next level of complexity. In the domino analogy, 2) says that the dominos are placed close enough, so that a falling domino will tip its neighbour over. Then 1) is tipping the first domino over. > > So: > > Assume P(l) and P(r). > P(l) means "countLeaves l == the number of leaves in l" > P(r) means "countLeaves r == the number of leaves in r" > countLeaves (Branch l r) = countLeaves l + countLeaves r, by > definition. And that is the number of leaves in "Branch l r", the sum of > the number of leaves in its two subtress. > Therefore P(Branch l r). > > Now that we have those two cases, we are done; P holds for any Tree > whatsoever. > > In general you will have to do one such proof for each case of your > data structure in order to prove a property for the whole thing. At > each case you get to assume the property holds for all substructures. > > Generally not so many steps are written down. In fact in this > example, most people who do this kind of thing a lot would write > "straightforward induction", and that would be the whole proof :-) > > The analogy between structural induction and induction over the > naturals is very strong; in fact induction over the naturals is just > induction over this data structure: > > data Nat = Zero | Succ Nat > > Hope this helps. > > Luke > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From vigalchin at gmail.com Tue May 6 20:17:13 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Tue May 6 20:11:21 2008 Subject: [Haskell-cafe] Haddock and upload questions? Message-ID: <5ae4f2ba0805061717r31b3602ex3999071c7a04b554@mail.gmail.com> Hello, 1) Can I set up Haddock to run everytime I do a build? 2) http://hackage.haskell.org/packages/upload.html .... - do I have to set up my .cabal in a special way to run "dist"? - once I checked that my Cabal package is "compliant" on this page, how do I get a username and password? Kind regards, Vasili -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080506/241ba582/attachment.htm From ryani.spam at gmail.com Tue May 6 20:21:23 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Tue May 6 20:15:30 2008 Subject: [Haskell-cafe] Induction (help!) In-Reply-To: <200805070051.25953.daniel.is.fischer@web.de> References: <7.0.1.0.0.20080506095651.01d0edb8@ntlworld.com> <7ca3f0160805060756j42408484s85f82513a983febb@mail.gmail.com> <7.0.1.0.0.20080506223340.01dc88a0@ntlworld.com> <200805070051.25953.daniel.is.fischer@web.de> Message-ID: <2f9b2d30805061721g2185f976r9b783457cb2eb9bf@mail.gmail.com> Another way to look at it is that induction is just a way to abbreviate proofs. Lets say you have a proposition over the natural numbers that may or may not be true; P(x). If you can prove P(0), and given P(x) you can prove P(x+1), then for any given natural number n, you can prove P(n): P(1) here> P(1). -- from P(0) and P(0) => P(1) P(2)> P(2). -- from P(1) and P(1) => P(2) ... P(n-1). -- from P(n-2) and P(n-2) => P(n-1). P(n)> P(n). -- from P(n-1) and P(n-1) => P(n) The magic thing about induction is that it gives you a unifying principle that allows you to skip these steps and prove an -infinite- number of hypotheses; even though the natural numbers is an infinite set, each number is still finite and therefore is subject to the same logic above. One point to remember is that structural induction fails to hold on infinite data structures: data Nat = Zero | Succ Nat deriving (Eq, Show) Take P(x) to be (x /= Succ x). P(0): Zero /= Succ Zero. (trivial) P(x) => P(Succ x) So, given P(x) which is: (x /= Succ x), we have to prove P(Succ x): (Succ x /= Succ (Succ x)) In the derived Eq typeclass: Succ a /= Succ b = a /= b Taking "x" for a and "Succ x" for b: Succ x /= Succ (Succ x) = x /= Succ x which is P(x). Now, consider the following definition: infinity :: Nat infinity = Succ infinity infinity /= Succ infinity == _|_; and if you go by definitional equality, infinity = Succ infinity, so even though P(x) holds on all natural numbers due to structural induction, it doesn't hold on this infinite number. -- ryan From westondan at imageworks.com Tue May 6 21:30:08 2008 From: westondan at imageworks.com (Dan Weston) Date: Tue May 6 21:24:17 2008 Subject: [Haskell-cafe] Induction (help!) In-Reply-To: <2f9b2d30805061721g2185f976r9b783457cb2eb9bf@mail.gmail.com> References: <7.0.1.0.0.20080506095651.01d0edb8@ntlworld.com> <7ca3f0160805060756j42408484s85f82513a983febb@mail.gmail.com> <7.0.1.0.0.20080506223340.01dc88a0@ntlworld.com> <200805070051.25953.daniel.is.fischer@web.de> <2f9b2d30805061721g2185f976r9b783457cb2eb9bf@mail.gmail.com> Message-ID: <48210620.3080300@imageworks.com> Ryan Ingram wrote: > > One point to remember is that structural induction fails to hold on > infinite data structures: As I understand it, structural induction works even for infinite data structures if you remember that the base case is always _|_. [1] Let the initial algebra functor F = const Zero | Succ We have to prove that: P(_|_) holds if P(X) holds then P(F(X)) holds Here, we see that for P(x) = (x /= Succ x), since infinity = Succ infinity = _|_ then P(_|_) does not hold (since _|_ = Succ _|_ = _|_) As a counterexample, we can prove e.g. that length (L ++ M) = length L + length M See [2] for details, except that they neglect the base case P(_|_) and start instead with the F^1 case of P([]), so their proof is valid only for finite lists. We can include the base case too: length (_|_ ++ M) = length _|_ + length M length (_|_ ) = _|_ + length M _|_ = _|_ and similarly for M = _|_ and both _|_. So this law holds even for infinite lists. [1] Richard Bird, "Introduction to Functional Programming using Haskell", p. 67 [2] http://en.wikipedia.org/wiki/Structural_induction Also note that > > data Nat = Zero | Succ Nat deriving (Eq, Show) > > Take P(x) to be (x /= Succ x). > > P(0): > Zero /= Succ Zero. (trivial) > > P(x) => P(Succ x) > > So, given P(x) which is: (x /= Succ x), > we have to prove P(Succ x): (Succ x /= Succ (Succ x)) > > In the derived Eq typeclass: > Succ a /= Succ b = a /= b > Taking "x" for a and "Succ x" for b: > Succ x /= Succ (Succ x) = x /= Succ x > which is P(x). > > Now, consider the following definition: > infinity :: Nat > infinity = Succ infinity > > infinity /= Succ infinity == _|_; and if you go by definitional > equality, infinity = Succ infinity, so even though P(x) holds on all > natural numbers due to structural induction, it doesn't hold on this > infinite number. > > -- ryan > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From alfonso.acosta at gmail.com Tue May 6 22:01:14 2008 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Tue May 6 21:55:23 2008 Subject: [Haskell-cafe] Figuring out if an algebraic type is enumerated through Data.Generics? In-Reply-To: <7fb8f82f0805061042v2d4045d0rccbcd556b97676f8@mail.gmail.com> References: <6a7c66fc0805060934x68881110hf28622adaf843703@mail.gmail.com> <7fb8f82f0805061041k12b7c86dr470723577addcb3@mail.gmail.com> <7fb8f82f0805061042v2d4045d0rccbcd556b97676f8@mail.gmail.com> Message-ID: <6a7c66fc0805061901j7f5b9c6au46ebc03037ab4db2@mail.gmail.com> Thanks a lot for your answer, it was exactly what I was looking for. Just for the record, based on your solution I can now easily code a function to check if a Data value belongs to an enumerated algebraic type (as I defined it in my first mail). {-# LANGUAGE DeriveDataTypeable, ScopedTypeVariables #-} import Data.Generics newtype Arity a = Arity Int deriving (Show, Eq) consArity :: Data a => Constr -> Arity a consArity = gunfold (\(Arity n) -> Arity (n+1)) (\_ -> Arity 0) belongs2EnumAlg :: forall a . Data a => a -> Bool belongs2EnumAlg a = case (dataTypeRep.dataTypeOf) a of AlgRep cons -> all (\c -> consArity c == ((Arity 0) :: Arity a )) cons _ -> False -- tests data Colors = Blue | Green | Red deriving (Data, Typeable) test1 = belongs2EnumAlg 'a' -- False test2 = belongs2EnumAlg Red -- True test3 = belongs2EnumAlg "a" -- False On Tue, May 6, 2008 at 7:42 PM, Edward Kmett wrote: > > On Tue, May 6, 2008 at 12:34 PM, Alfonso Acosta > wrote: > > | So, the question is. Is there a way to figure out the arity of data > | constructors using Data.Generics ? > > | I'm totally new to generics, but (tell me if I'm wrong) it seems that > | Constr doesn't hold any information about the data-constructor > | arguments. Why is it so? > > > Hmrmm, > > Playing around with it, I was able to abuse gunfold and the reader > comonad to answer the problem : > > fst $ (gunfold (\(i,_) -> (i+1,undefined)) (\r -> (0,r)) (toConstr > "Hello") :: (Int,String)) > > returns 2, the arity of (:), the outermost constructor in "Hello" > > A longer version which does not depend on undefined would be to take > and define a functor that discarded its contents like: > > > module Args where > > > import Data.Generics > > > newtype Args a = Args { runArgs :: Int } deriving (Read,Show) > > > tick :: Args (b -> r) -> Args r > > tick (Args i) = Args (i + 1) > > > tock = const (Args 0) > > > argsInCons = runArgs $ (gunfold tick tock (toConstr "Hello") :: (Args String) > > Basically all I do is rely on the fact that gunfold takes the 'tick' > argument and calls it repeatedly for each argument after a 'tock' base > case. > > The use of the reader comonad or functor is to give gunfold a > 'functor-like' argument to meet its type signature. > > -Edward Kmett > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From dekudekuplex at yahoo.com Wed May 7 01:46:02 2008 From: dekudekuplex at yahoo.com (Benjamin L. Russell) Date: Wed May 7 01:40:10 2008 Subject: [Haskell-cafe] license question In-Reply-To: <1210087829.6649.8.camel@macbook> Message-ID: <197596.91876.qm@web30205.mail.mud.yahoo.com> Hello Henrique, That license, The Glasgow Haskell Compiler License, available at http://darcs.haskell.org/ghc-hashedrepo/libraries/haskell-src/LICENSE, reads as follows: ----- license text follows immediately after this line ----- The Glasgow Haskell Compiler License Copyright 2004, The University Court of the University of Glasgow. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: - Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. - Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. - Neither name of the University nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE UNIVERSITY COURT OF THE UNIVERSITY OF GLASGOW AND THE CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE UNIVERSITY COURT OF THE UNIVERSITY OF GLASGOW OR THE CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. ----- license text ends immediately before this line ----- According to the above conditions, the following conditions hold: * In redistributions of source code, you are required to retain the above copyright notice, the above list of conditions, and the above disclaimer. * In restributions in binary form, you are required to retain the above copyright notice, the above list of conditions, and the above disclaimer in the documentation and/or other materials provided with your distribution. However, according to the above conditions, in neither case are you necessarily required to include your name in the copyright notice. Benjamin L. Russell --- On Wed, 5/7/08, Henrique Ferreiro Garc?a wrote: > Hello everybody, > > I have one question regarding a licensing issue. I am > developing a > library to parse and pretty-print the Core Erlang language > and it is > heavily based on the modules included in haskell-src. > > What I want to know is if I have to reproduce all of the > LICENSE file > included in that package with my name included in the > copyright notice > or what other thing do I have to do. > > Thanks in advance. > > -- > Henrique Ferreiro Garc?a > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From jules at jellybean.co.uk Wed May 7 01:47:27 2008 From: jules at jellybean.co.uk (Jules Bean) Date: Wed May 7 01:41:36 2008 Subject: [Haskell-cafe] Figuring out if an algebraic type is enumerated through Data.Generics? In-Reply-To: <6a7c66fc0805060934x68881110hf28622adaf843703@mail.gmail.com> References: <6a7c66fc0805060934x68881110hf28622adaf843703@mail.gmail.com> Message-ID: <4821426F.7000208@jellybean.co.uk> Alfonso Acosta wrote: > It would certainly be difficult map any Haskell type to VHDL, so, by > now we would be content to map enumerate algebraic types (i.e. > algebraic types whose all data constructors have arity zero, e.g. > data Colors = Green | Blue | Red) Wouldn't it be much simpler to use the standard deriveable classes Bounded and Enum, instead of an admittedly very clever trick using Data? Metaprogramming comes in many shapes and sizes, and even the humble deriving (Show,Enum,Bounded,Ord,Eq) gives you quite some leverage.. Jules From vigalchin at gmail.com Wed May 7 03:48:31 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Wed May 7 03:42:40 2008 Subject: [Haskell-cafe] who maintains the POSIX/Unix Unistd.hs? Message-ID: <5ae4f2ba0805070048k51769399yefb7c2d47a75a91d@mail.gmail.com> Hello, I am trying to find the definition for the data type "TimeSpec"/"CTimeSpec". thanks, Vasili -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080507/2ded1d54/attachment.htm From apfelmus at quantentunnel.de Wed May 7 05:18:50 2008 From: apfelmus at quantentunnel.de (apfelmus) Date: Wed May 7 05:13:15 2008 Subject: [Haskell-cafe] Re: Control.Exception.evaluate - 'correct definition' not so correct In-Reply-To: <7ca3f0160805060727n52bbe96fracd3d9a303f61ba3@mail.gmail.com> References: <20080503091917.GA5333@shion.is.fushizen.net> <5ab17e790805041730o33b378e4u74f4f1f9e813e72b@mail.gmail.com> <7ca3f0160805060727n52bbe96fracd3d9a303f61ba3@mail.gmail.com> Message-ID: Luke Palmer wrote: > It seems that there is a culture developing where people intentionally > ignore the existence of seq when reasoning about Haskell. Indeed I've > heard many people argue that it shouldn't be in the language as it is > now, that instead it should be a typeclass. > > I wonder if it's possible for the compiler to do more aggressive > optimizations if it, too, ignored the existence of seq. Would it make > it easier to do various sorts of lambda lifting, and would it make > strictness analysis easier? The introduction of seq has several implications. The first problem is that parametricity would dictate that the only functions of type forall a,b. a -> b -> b are const id const _|_ _|_ Since seq is different from these, giving it this polymorphic type weakens parametricity. This does have implications for optimizations, in particular for fusion, see also http://www.haskell.org/haskellwiki/Correctness_of_short_cut_fusion Parametricity can be restored with a class constraint seq :: Eval a => a -> b -> b In fact, that's how Haskell 1.3 and 1.4 did it. The second problem are function types. With seq on functions, eta-expansion is broken, i.e. we no longer have f = \x.f x because seq can be used to distinguish _|_ and \x. _|_ One of the many consequences of this is that simple laws like f = f . id no longer hold, which is a pity. But then again, _|_ complicates reasoning anyway and we most often pretend that we are only dealing with total functions. Unsurprisingly, this usually works. This can even be justified formally to some extend, see also N.A.Danielsson, J.Hughes, P.Jansson, J.Gibbons. Fast and Loose Reasoning is Morally Correct. http://www.comlab.ox.ac.uk/people/jeremy.gibbons/publications/fast+loose.pdf Regards, apfelmus From patrik.osgnach at gmail.com Wed May 7 06:28:02 2008 From: patrik.osgnach at gmail.com (patrik osgnach) Date: Wed May 7 06:22:15 2008 Subject: [Haskell-cafe] help in tree folding In-Reply-To: <200805062116.00279.daniel.is.fischer@web.de> References: <48204CF4.2040808@gmail.com> <22fcbd520805060742ked232cate31e436e21c9ee68@mail.gmail.com> <4820C25B.3080906@gmail.com> <200805062116.00279.daniel.is.fischer@web.de> Message-ID: <48218432.9020201@gmail.com> Daniel Fischer ha scritto: > Am Dienstag, 6. Mai 2008 22:40 schrieb patrik osgnach: >> Brent Yorgey ha scritto: >>> On Tue, May 6, 2008 at 8:20 AM, patrik osgnach >>> >>> wrote: >>>> Hi. I'm learning haskell but i'm stuck on a generic tree folding >>>> exercise. i must write a function of this type >>>> treefoldr::(Eq a,Show a)=>(a->b->c)->c->(c->b->b)->b->Tree a->c >>>> Tree has type >>>> data (Eq a,Show a)=>Tree a=Void | Node a [Tree a] deriving (Eq,Show) >>>> as an example treefoldr (:) [] (++) [] (Node '+' [Node '*' [Node 'x' [], >>>> Node 'y' []], Node 'z' []]) >>>> must return "+?xyz" >>>> any help? >>>> (sorry for my bad english) >>> Having a (Tree a) parameter, where Tree is defined as an algebraic data >>> type, also immediately suggests that you should do some pattern-matching >>> to break treefoldr down into cases: >>> >>> treefoldr f y g z Void = ? >>> treefoldr f y g z (Node x t) = ? >>> >>> -Brent >> so far i have tried >> treefoldr f x g y Void = x > > Yes, nothing else could be done. > >> treefoldr f x g y (Node a []) = f a y > > Not bad. But actually there's no need to treat nodes with and without children > differently. > Let's see: > > treefoldr f x g y (Node v ts) > > should have type c, and it should use v. We have > f :: a -> b -> c > x :: c > g :: c -> b -> b > y :: b > v :: a. > > The only thing which produces a value of type c using a value of type a is f, > so we must have > > treefoldr f x g y (Node v ts) = f v someExpressionUsing'ts' > > where > > someExpressionUsing'ts' :: b. > > The only thing we have which produces a value of type b is g, so > someExpressionUsing'ts' must ultimately be > g something somethingElse. > Now take a look at the code and type of foldr, that might give you the idea. > > Cheers, > Daniel > > >> treefoldr f x g y (Node a (t:ts)) = treefoldr f x g (g (treefoldr f x g >> y t) y) (Node a ts) >> but it is incorrect. i can't figure out how to build the recursive call >> thanks for the answer >> Patrik > > thanks for the tip. so, if i have understood correctly i have to wirite something like: treefoldr f x g y (Node a ts) = f a (g (treefoldr f x g y (head ts)) (g (treefoldr f x g y (head (tail ts)) (g ... it looks like a list foldr so... treefoldr f x g y Void = x treefoldr f x g y (Node a ts) = f a (foldr (g) y (map (treefoldr f x g y) ts)) it seems to work. i'm not yet sure it is correct but is better than nothing thanks to you all. now i will try to write a treefoldl From wss at Cs.Nott.AC.UK Wed May 7 06:42:22 2008 From: wss at Cs.Nott.AC.UK (Wouter Swierstra) Date: Wed May 7 06:38:51 2008 Subject: [Haskell-cafe] The Monad.Reader (11) - Call for Copy Message-ID: Call for Copy The Monad.Reader - Issue 11 Please consider writing something for the next issue of The Monad.Reader. The deadline for Issue 11 is ** August 1, 2008 ** It doesn't matter if you're a respected researcher or if you have only just started learning Haskell, get your thoughts together and write an article for The Monad.Reader! The Monad.Reader is a electronic magazine about all things Haskell. It is less formal than journal, but more enduring than a wiki-page or blog. There have been a wide variety of articles, including: exciting code fragments, intriguing puzzles, book reviews, tutorials, and even half-baked research ideas. * Submission Details * Get in touch with me if you intend to submit something -- the sooner you let me know what you're up to, the better. Please submit articles for the next issue to me by e-mail (wss at cs.nott.ac.uk). Articles should be written according to the guidelines available from http://www.haskell.org/haskellwiki/The_Monad.Reader Please submit your article in PDF, together with any source files you used. The sources will be released together with the magazine under a BSD license. If you would like to submit an article, but have trouble with LaTeX please let me know and we'll sort something out. All the best, Wouter This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. From abhay.parvate at gmail.com Wed May 7 07:12:50 2008 From: abhay.parvate at gmail.com (Abhay Parvate) Date: Wed May 7 07:06:56 2008 Subject: [Haskell-cafe] Re: Control.Exception.evaluate - 'correct definition' not so correct In-Reply-To: References: <20080503091917.GA5333@shion.is.fushizen.net> <5ab17e790805041730o33b378e4u74f4f1f9e813e72b@mail.gmail.com> <7ca3f0160805060727n52bbe96fracd3d9a303f61ba3@mail.gmail.com> Message-ID: <3c4d5adf0805070412x376ab151sda733cfed3947acd@mail.gmail.com> Just for curiocity, is there a practically useful computation that uses 'seq' in an essential manner, i.e. apart from the efficiency reasons? Abhay On Wed, May 7, 2008 at 2:48 PM, apfelmus wrote: > Luke Palmer wrote: > > > It seems that there is a culture developing where people intentionally > > ignore the existence of seq when reasoning about Haskell. Indeed I've > > heard many people argue that it shouldn't be in the language as it is > > now, that instead it should be a typeclass. > > > > I wonder if it's possible for the compiler to do more aggressive > > optimizations if it, too, ignored the existence of seq. Would it make > > it easier to do various sorts of lambda lifting, and would it make > > strictness analysis easier? > > > > The introduction of seq has several implications. > > The first problem is that parametricity would dictate that the only > functions of type > > forall a,b. a -> b -> b > > are > > const id > const _|_ > _|_ > > Since seq is different from these, giving it this polymorphic type > weakens parametricity. This does have implications for optimizations, in > particular for fusion, see also > > http://www.haskell.org/haskellwiki/Correctness_of_short_cut_fusion > > Parametricity can be restored with a class constraint > > seq :: Eval a => a -> b -> b > > In fact, that's how Haskell 1.3 and 1.4 did it. > > > The second problem are function types. With seq on functions, > eta-expansion is broken, i.e. we no longer have > > f = \x.f x > > because seq can be used to distinguish > > _|_ and \x. _|_ > > One of the many consequences of this is that simple laws like > > f = f . id > > no longer hold, which is a pity. > > > But then again, _|_ complicates reasoning anyway and we most often pretend > that we are only dealing with total functions. Unsurprisingly, this usually > works. This can even be justified formally to some extend, see also > > N.A.Danielsson, J.Hughes, P.Jansson, J.Gibbons. > Fast and Loose Reasoning is Morally Correct. > > http://www.comlab.ox.ac.uk/people/jeremy.gibbons/publications/fast+loose.pdf > > > Regards, > apfelmus > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080507/b2d5d68e/attachment.htm From apfelmus at quantentunnel.de Wed May 7 07:35:40 2008 From: apfelmus at quantentunnel.de (apfelmus) Date: Wed May 7 07:29:53 2008 Subject: [Haskell-cafe] Re: Control.Exception.evaluate - 'correct definition' not so correct In-Reply-To: <3c4d5adf0805070412x376ab151sda733cfed3947acd@mail.gmail.com> References: <20080503091917.GA5333@shion.is.fushizen.net> <5ab17e790805041730o33b378e4u74f4f1f9e813e72b@mail.gmail.com> <7ca3f0160805060727n52bbe96fracd3d9a303f61ba3@mail.gmail.com> <3c4d5adf0805070412x376ab151sda733cfed3947acd@mail.gmail.com> Message-ID: Abhay Parvate wrote: > Just for curiocity, is there a practically useful computation that uses > 'seq' in an essential manner, i.e. apart from the efficiency reasons? I don't think so because you can always replace seq with const id . In fact, doing so will get you "more" results, i.e. a computation that did not terminate may do so now. In other words, we have seq _|_ = _|_ seq x = id for x > _|_ but (const id) _|_ = id (const id) x = id for x > _|_ So, (const id) is always more defined (">") than seq . For more about _|_ and the semantic approximation order, see http://en.wikibooks.org/wiki/Haskell/Denotational_semantics Regards, apfelmus From harri.kiiskinen at utu.fi Wed May 7 10:42:45 2008 From: harri.kiiskinen at utu.fi (Harri Kiiskinen) Date: Wed May 7 10:36:51 2008 Subject: [Haskell-cafe] runInteractiveProcess and hGetLine on Windows Message-ID: <4821BFE5.5090605@utu.fi> Hello all, I bumped into a "feature" which might be a bug, but to be certain, I'd like to hear your opinion. I'm running ghc 6.8.2 on Windows XP, and with ghci I do the following: Prelude System.Process System.IO> (inp,outp,err,ph) <- runInteractiveProcess "kpsewhich" ["testfile.txt"] Nothing Nothing ('kpsewhich' is a simple path searching utility used by web2c TeX system, returns the full path to the file if found in the system defined search path, but you all probably know that.) and then: Prelude System.Process System.IO> hGetLine outp which gives me: "./testfile.txt\r" as opposed to "./testfile.txt" which I get on my Linux box. Is the "\r" supposed to be at the end? I thought it is part of the line separator in Windows, and as such, should not be part of the line retrieved? Same thing happens when compiled with ghc. Best Wishes, Harri K. From dbueno at gmail.com Wed May 7 11:19:34 2008 From: dbueno at gmail.com (Denis Bueno) Date: Wed May 7 11:13:48 2008 Subject: [Haskell-cafe] Haddock and upload questions? In-Reply-To: <5ae4f2ba0805061717r31b3602ex3999071c7a04b554@mail.gmail.com> References: <5ae4f2ba0805061717r31b3602ex3999071c7a04b554@mail.gmail.com> Message-ID: <6dbd4d000805070819k5ed8c5b3pe31bc06683f32a14@mail.gmail.com> 2008/5/6 Galchin, Vasili : > 2) http://hackage.haskell.org/packages/upload.html .... > > - do I have to set up my .cabal in a special way to run "dist"? I believe it works automatically, using the values of the fields you set, e.g. Exposed-modules and Other-modules. > - once I checked that my Cabal package is "compliant" on this > page, how do I get a username and password? http://hackage.haskell.org/packages/accounts.html Linked from the front page of hackage: http://hackage.haskell.org/packages/hackage.html -- Denis From droundy at darcs.net Wed May 7 11:21:03 2008 From: droundy at darcs.net (David Roundy) Date: Wed May 7 11:15:08 2008 Subject: [Haskell-cafe] runInteractiveProcess and hGetLine on Windows In-Reply-To: <4821BFE5.5090605@utu.fi> References: <4821BFE5.5090605@utu.fi> Message-ID: <20080507152102.GG23619@darcs.net> On Wed, May 07, 2008 at 04:42:45PM +0200, Harri Kiiskinen wrote: > Prelude System.Process System.IO> (inp,outp,err,ph) <- > runInteractiveProcess "kpsewhich" ["testfile.txt"] Nothing > Nothing ... > Prelude System.Process System.IO> hGetLine outp > > which gives me: > > "./testfile.txt\r" > > as opposed to "./testfile.txt" which I get on my Linux box. > > Is the "\r" supposed to be at the end? I thought it is part of the line > separator in Windows, and as such, should not be part of the line > retrieved? Same thing happens when compiled with ghc. This is the correct behavior (although it's debatable whether kpsewhich should be outputting in text mode). In order to get windows-style line handling, a file handle needs to be opened in text mode, which is certainly not the correct behavior for runInteractiveProcess, which has no knowledge about the particular behavior of the program it's running. "\r\n" as newline should die a rapid death... windows is hard enough without maintaining this sort of stupidity. -- David Roundy Department of Physics Oregon State University From bos at serpentine.com Wed May 7 11:33:23 2008 From: bos at serpentine.com (Bryan O'Sullivan) Date: Wed May 7 11:27:28 2008 Subject: [Haskell-cafe] runInteractiveProcess and hGetLine on Windows In-Reply-To: <20080507152102.GG23619@darcs.net> References: <4821BFE5.5090605@utu.fi> <20080507152102.GG23619@darcs.net> Message-ID: <4821CBC3.4000604@serpentine.com> David Roundy wrote: > This is the correct behavior (although it's debatable whether kpsewhich > should be outputting in text mode). I think it would be more accurate to say that runInteractiveProcess has an inadequate API, since you can't indicate whether the interaction with the other process should happen in text or binary mode. Simon: do the new entry points in System.Process take line ending conventions into account? References: <4821BFE5.5090605@utu.fi> <20080507152102.GG23619@darcs.net> <4821CBC3.4000604@serpentine.com> Message-ID: <20080507154609.GI23619@darcs.net> On Wed, May 07, 2008 at 08:33:23AM -0700, Bryan O'Sullivan wrote: > David Roundy wrote: > > This is the correct behavior (although it's debatable whether kpsewhich > > should be outputting in text mode). > > I think it would be more accurate to say that runInteractiveProcess has > an inadequate API, since you can't indicate whether the interaction with > the other process should happen in text or binary mode. I don't see any reason to support text mode. It's easy to filter by hand if you absolutely have to deal with ugly applications on ugly platforms. -- David Roundy Department of Physics Oregon State University From bulat.ziganshin at gmail.com Wed May 7 11:48:45 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed May 7 11:42:57 2008 Subject: [Haskell-cafe] runInteractiveProcess and hGetLine on Windows In-Reply-To: <20080507154609.GI23619@darcs.net> References: <4821BFE5.5090605@utu.fi> <20080507152102.GG23619@darcs.net> <4821CBC3.4000604@serpentine.com> <20080507154609.GI23619@darcs.net> Message-ID: <1138672165.20080507194845@gmail.com> Hello David, Wednesday, May 7, 2008, 7:46:11 PM, you wrote: > I don't see any reason to support text mode. It's easy to filter by hand > if you absolutely have to deal with ugly applications on ugly platforms. you mean unix, of course? ;) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From droundy at darcs.net Wed May 7 12:06:24 2008 From: droundy at darcs.net (David Roundy) Date: Wed May 7 12:00:30 2008 Subject: [Haskell-cafe] runInteractiveProcess and hGetLine on Windows In-Reply-To: <1138672165.20080507194845@gmail.com> References: <4821BFE5.5090605@utu.fi> <20080507152102.GG23619@darcs.net> <4821CBC3.4000604@serpentine.com> <20080507154609.GI23619@darcs.net> <1138672165.20080507194845@gmail.com> Message-ID: <20080507160623.GJ23619@darcs.net> On Wed, May 07, 2008 at 07:48:45PM +0400, Bulat Ziganshin wrote: > Hello David, Hi Bulat! > Wednesday, May 7, 2008, 7:46:11 PM, you wrote: > > I don't see any reason to support text mode. It's easy to filter by hand > > if you absolutely have to deal with ugly applications on ugly platforms. > > you mean unix, of course? ;) Maybe I should have said "if you don't care what the actual output of the programs you run is"? Then it would have been clear that I was talking about Windows... David From donn at avvanta.com Wed May 7 12:12:42 2008 From: donn at avvanta.com (Donn Cave) Date: Wed May 7 12:06:48 2008 Subject: [Haskell-cafe] runInteractiveProcess and hGetLine on Windows In-Reply-To: <20080507154609.GI23619@darcs.net> References: <4821BFE5.5090605@utu.fi> <20080507152102.GG23619@darcs.net> <4821CBC3.4000604@serpentine.com> <20080507154609.GI23619@darcs.net> Message-ID: On May 7, 2008, at 8:46 AM, David Roundy wrote: > On Wed, May 07, 2008 at 08:33:23AM -0700, Bryan O'Sullivan wrote: >> David Roundy wrote: >>> This is the correct behavior (although it's debatable whether >>> kpsewhich >>> should be outputting in text mode). >> >> I think it would be more accurate to say that >> runInteractiveProcess has >> an inadequate API, since you can't indicate whether the >> interaction with >> the other process should happen in text or binary mode. > > I don't see any reason to support text mode. Doesn't hGetLine imply text mode? What does "Line" mean, otherwise? Donn Cave, donn@avvanta.com From droundy at darcs.net Wed May 7 12:41:11 2008 From: droundy at darcs.net (David Roundy) Date: Wed May 7 12:37:30 2008 Subject: [Haskell-cafe] runInteractiveProcess and hGetLine on Windows In-Reply-To: References: <4821BFE5.5090605@utu.fi> <20080507152102.GG23619@darcs.net> <4821CBC3.4000604@serpentine.com> <20080507154609.GI23619@darcs.net> Message-ID: <117f2cc80805070941j3feb9769gac89c1894ac391f2@mail.gmail.com> On Wed, May 7, 2008 at 9:12 AM, Donn Cave wrote: > Doesn't hGetLine imply text mode? What does "Line" mean, otherwise? On normal operating systems, "line" means until you reach a '\n' character. In fact, that's also what it means when reading in text mode, it's just that when in text mode on DOS-descended systems, the character sequence "\r\n" is converted to "\n" by the operating system. David From alfonso.acosta at gmail.com Wed May 7 13:09:00 2008 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Wed May 7 13:03:24 2008 Subject: [Haskell-cafe] Figuring out if an algebraic type is enumerated through Data.Generics? In-Reply-To: <4821426F.7000208@jellybean.co.uk> References: <6a7c66fc0805060934x68881110hf28622adaf843703@mail.gmail.com> <4821426F.7000208@jellybean.co.uk> Message-ID: <6a7c66fc0805071009s240428aat3188299930346fb9@mail.gmail.com> On Wed, May 7, 2008 at 7:47 AM, Jules Bean wrote: > Alfonso Acosta wrote: > > > It would certainly be difficult map any Haskell type to VHDL, so, by > > now we would be content to map enumerate algebraic types (i.e. > > algebraic types whose all data constructors have arity zero, e.g. > > data Colors = Green | Blue | Red) > > > > Wouldn't it be much simpler to use the standard deriveable classes Bounded > and Enum, instead of an admittedly very clever trick using Data? No, for the reasons explained in the probably_unnnecesary_background I don't see how those instantiations would help. From jason.dusek at gmail.com Wed May 7 13:20:53 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Wed May 7 13:14:59 2008 Subject: [Haskell-cafe] runInteractiveProcess and hGetLine on Windows In-Reply-To: <117f2cc80805070941j3feb9769gac89c1894ac391f2@mail.gmail.com> References: <4821BFE5.5090605@utu.fi> <20080507152102.GG23619@darcs.net> <4821CBC3.4000604@serpentine.com> <20080507154609.GI23619@darcs.net> <117f2cc80805070941j3feb9769gac89c1894ac391f2@mail.gmail.com> Message-ID: <42784f260805071020p5e98cc81pafe7b10842dad587@mail.gmail.com> David Roundy wrote: > ...when in text mode on DOS-descended systems, the > character sequence "\r\n" is converted to "\n" by the operating > system. So basically, Windows supports both the "\n" convention and the "\r\n" convention by making a distinction between "text" and "binary" read modes. No other major operating system requires this distinction -- they are all *nixen -- so it seems reasonable to just punt on it. It would be too bad, though, if this resulted in a lot of Windows specific code getting written -- there are a lot of Windows users and eventually they'll unionize or something. People will throw together System.Win32.TextMode or something like that and then projects will be littered with platform specific code, though they needn't be. If we just put up a `textMode` filter, then everyone will have to throw that in front of their reads/writes to guard against corruption on Windows. We'll have verbose, silly looking code. If, on the other hand, we just give in to Windows, then some things are good and some are bad. First of all, if hGetLine has Windows behaviour on Windows and Unix behaviour on Unix, then any data files shipped with Cabal packages will likely need to be newline transformed. That is annoying. On the other hand, the semantics of 'getting a line' will be maintained across platforms, and the Windows users will be pacified (for a time). We all know what appeasement got the British... -- _jsn From andrewcoppin at btinternet.com Wed May 7 14:54:42 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Wed May 7 14:48:45 2008 Subject: [Haskell-cafe] runInteractiveProcess and hGetLine on Windows In-Reply-To: <20080507152102.GG23619@darcs.net> References: <4821BFE5.5090605@utu.fi> <20080507152102.GG23619@darcs.net> Message-ID: <4821FAF2.2050608@btinternet.com> David Roundy wrote: > "\r\n" as newline should die a rapid death... windows is hard enough > without maintaining this sort of stupidity. > Windows *does* do a number of very silly things. However, Windows isn't going away any time soon. And personally, I'd prefer it if we could make it easier to support it in Haskell. I think a pure function that takes text formatted in any way and transforms it into some kind of "canonical" form would be a useful starting point. You'd probably want a platform-specific inverse function too. (I notice that FilePath manages to work differently on different platforms, so it's possible.) Currently the only way to do these transformations is to set the right channel mode at the instant you read the text. If we had a set of pure functions, you could transform the text after it's read - even if it's read in the wrong file mode, or you don't know whether it's text or binary until later. From andrewcoppin at btinternet.com Wed May 7 14:56:23 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Wed May 7 14:50:23 2008 Subject: [Haskell-cafe] The Monad.Reader (11) - Call for Copy In-Reply-To: References: Message-ID: <4821FB57.3010808@btinternet.com> Wouter Swierstra wrote: > Please consider writing something for the next issue of The Monad.Reader. You know, I'm actually tempted to do just that... > It doesn't matter if you're a respected researcher or if you have only > just started learning Haskell, get your thoughts together and write an > article for The Monad.Reader! It probably *does* matter, however, that I don't have anything interesting to say. :-( Ah well. From duncan.coutts at worc.ox.ac.uk Wed May 7 16:17:09 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed May 7 16:10:06 2008 Subject: [Haskell-cafe] runInteractiveProcess and hGetLine on Windows In-Reply-To: <4821CBC3.4000604@serpentine.com> References: <4821BFE5.5090605@utu.fi> <20080507152102.GG23619@darcs.net> <4821CBC3.4000604@serpentine.com> Message-ID: <1210191429.30059.403.camel@localhost> On Wed, 2008-05-07 at 08:33 -0700, Bryan O'Sullivan wrote: > David Roundy wrote: > > > This is the correct behavior (although it's debatable whether kpsewhich > > should be outputting in text mode). > > I think it would be more accurate to say that runInteractiveProcess has > an inadequate API, since you can't indicate whether the interaction with > the other process should happen in text or binary mode. > > Simon: do the new entry points in System.Process take line ending > conventions into account? It doesn't require any new api: (inh,outh,errh,pid) <- runInteractiveProcess path args Nothing Nothing -- We want to process the output as text. hSetBinaryMode outh False As of a couple weeks ago the docs for runInteractiveProcess even say: -- The 'Handle's are initially in binary mode; if you need them to be -- in text mode then use 'hSetBinaryMode'. Duncan From duncan.coutts at worc.ox.ac.uk Wed May 7 16:21:09 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed May 7 16:14:01 2008 Subject: [Haskell-cafe] runInteractiveProcess and hGetLine on Windows In-Reply-To: <42784f260805071020p5e98cc81pafe7b10842dad587@mail.gmail.com> References: <4821BFE5.5090605@utu.fi> <20080507152102.GG23619@darcs.net> <4821CBC3.4000604@serpentine.com> <20080507154609.GI23619@darcs.net> <117f2cc80805070941j3feb9769gac89c1894ac391f2@mail.gmail.com> <42784f260805071020p5e98cc81pafe7b10842dad587@mail.gmail.com> Message-ID: <1210191669.30059.405.camel@localhost> On Wed, 2008-05-07 at 10:20 -0700, Jason Dusek wrote: > If, on the other hand, we just give in to Windows, then some > things are good and some are bad. First of all, if hGetLine > has Windows behaviour on Windows and Unix behaviour on Unix, > then any data files shipped with Cabal packages will likely > need to be newline transformed. That is annoying. Cabal already does deal with both (and mixed) conventions because people make files on one system and transfer them to the other. Duncan From duncan.coutts at worc.ox.ac.uk Wed May 7 16:24:46 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed May 7 16:17:50 2008 Subject: [Haskell-cafe] runInteractiveProcess and hGetLine on Windows In-Reply-To: <20080507154609.GI23619@darcs.net> References: <4821BFE5.5090605@utu.fi> <20080507152102.GG23619@darcs.net> <4821CBC3.4000604@serpentine.com> <20080507154609.GI23619@darcs.net> Message-ID: <1210191886.30059.410.camel@localhost> On Wed, 2008-05-07 at 08:46 -0700, David Roundy wrote: > On Wed, May 07, 2008 at 08:33:23AM -0700, Bryan O'Sullivan wrote: > > David Roundy wrote: > > > This is the correct behavior (although it's debatable whether kpsewhich > > > should be outputting in text mode). > > > > I think it would be more accurate to say that runInteractiveProcess has > > an inadequate API, since you can't indicate whether the interaction with > > the other process should happen in text or binary mode. > > I don't see any reason to support text mode. It's easy to filter by hand > if you absolutely have to deal with ugly applications on ugly platforms. If it was only Windows' silly line ending convention I'd be tempted to agree but we probably want to distinguish text and binary handles anyway. You get Chars out of a text handle (with some string ed/decoding) and bytes out of a binary handle. In that case, default line ending convention is just another thing to throw in with the text encoding conversion. Duncan From droundy at darcs.net Wed May 7 16:38:20 2008 From: droundy at darcs.net (David Roundy) Date: Wed May 7 16:32:25 2008 Subject: [Haskell-cafe] runInteractiveProcess and hGetLine on Windows In-Reply-To: <1210191886.30059.410.camel@localhost> References: <4821BFE5.5090605@utu.fi> <20080507152102.GG23619@darcs.net> <4821CBC3.4000604@serpentine.com> <20080507154609.GI23619@darcs.net> <1210191886.30059.410.camel@localhost> Message-ID: <20080507203819.GP23619@darcs.net> On Wed, May 07, 2008 at 09:24:46PM +0100, Duncan Coutts wrote: > On Wed, 2008-05-07 at 08:46 -0700, David Roundy wrote: > > On Wed, May 07, 2008 at 08:33:23AM -0700, Bryan O'Sullivan wrote: > > > David Roundy wrote: > > > > This is the correct behavior (although it's debatable whether kpsewhich > > > > should be outputting in text mode). > > > > > > I think it would be more accurate to say that runInteractiveProcess has > > > an inadequate API, since you can't indicate whether the interaction with > > > the other process should happen in text or binary mode. > > > > I don't see any reason to support text mode. It's easy to filter by hand > > if you absolutely have to deal with ugly applications on ugly platforms. > > If it was only Windows' silly line ending convention I'd be tempted to > agree but we probably want to distinguish text and binary handles > anyway. You get Chars out of a text handle (with some string > ed/decoding) and bytes out of a binary handle. In that case, default > line ending convention is just another thing to throw in with the text > encoding conversion. But that's a feature that was only added in a very recent ghc, right? I consider it an ugly hack to work around the fact that we have no system for dealing with file encodings. I'd rather consider text mode handles to be an ugly workaround for an ugly system, and have a clean solution for unicode (e.g. one that allows for the reading of files that are not in the locale encoding). I certainly wouldn't want to be forced to live with DOS line endings just to generate unicode output. Fortunately, darcs doesn't do unicode (or need to) or text mode, so I personally am pretty safe from this feature. David From mads_lindstroem at yahoo.dk Wed May 7 17:24:05 2008 From: mads_lindstroem at yahoo.dk (Mads =?ISO-8859-1?Q?Lindstr=F8m?=) Date: Wed May 7 17:21:23 2008 Subject: [Haskell-cafe] Using Template Haskell to make type-safe database access In-Reply-To: <6A286E8D-2C96-4E77-9FA3-077702204CBE@Cs.Nott.AC.UK> References: <1209760319.4242.4.camel@localhost.localdomain> <1210017744.4300.30.camel@localhost.localdomain> <6A286E8D-2C96-4E77-9FA3-077702204CBE@Cs.Nott.AC.UK> Message-ID: <1210195445.4192.54.camel@localhost.localdomain> Hi Wouter Wouter Swierstra wrote: > Here's a concrete example. Suppose you have a query q that, when > performed, will return a table storing integers. I can see how you can > ask the SQL server for the type of the query, parse the response, and > compute the Haskell type "[Int]". I'm not sure how to sum the integers > returned by the query *in Haskell* (I know SQL can sum numbers too, > but this is a simple example). What would happen when you apply > Haskell's sum function to the result of the query? Does TH do enough > compile time execution to see that the result is well-typed? Not only pictures, but also code can say more than a thousands words. Therefore, I have been implementing a proof of concept. The code is attached in two files - SqlExpr.hs and UseSqlExpr.hs. The former contains two SQL expressions + Haskell code. The latter is the Template Haskell (TH) code that makes it possible to type-safely access the database. UseSqlExpr.hs is a lot easier to understand than SqlExpr.hs. So if you only have time to look at one of them, look at UseSqlExpr.hs. The reason SqlExpr.hs is harder to understand is not just because it is longer, but also because TH is difficult. At least TH was difficult for me. It might just be because I have never worked with anything like TH before (have not learned Lisp yet :( ). It remained me of going from OO to FP. You have to change how you think. Your example of fetching a [Int] and take there sum is shown in UseSqlExpr.hs. The output from running UseSqlExpr.hs (on my computer) is: [1,2,3,4] [(1,"WikiSysop",""),(2,"Mads","Mads Lindstr\195\184m"),(3,"Madstest","Bob"),(4,"Test2","Test 2")] Sum is: 10 > > Having the SQL server compute types for you does have other drawbacks, > I think. For example, suppose your query projects out a field that > does not exist. An error like that will only get caught once you ask > the server for the type of your SQL expression. If you keep track of > the types in Haskell, you can catch these errors earlier; Haskell's > type system can pinpoint which part of the query is accessing the > wrong field. I feel that if you really care about the type of your > queries, you should guarantee type correctness by construction, rather > than check it as an afterthought. But the SQL database will output a meaningful error message. And TH is asking the server at compile time. Thus, the user can also get the error message at compile time. TH is used as part of the compilation process. I _think_ it would be fair to say it occurs concurrently with type checking (or maybe intermittently). Thus the user do not get the error message later than with a type based approach. If you, with the currently implemented proof of concept, name a non-existing field in your SQL you get: UseSqlExpr.hs:22:6: Exception when trying to run compile-time code: Exception when trying "executing prepared statement" : execute execute: ["1054: [MySQL][ODBC 3.51 Driver][mysqld-5.0.32-Debian_7etch5-log]Unknown column 'duser_id' in 'field list'"] Code: compileSql "DSN=MySQL_DSN;USER=StocksDaemon;" "SELECT duser_id FROM user;" In the expression: $[splice](compileSql "DSN=MySQL_DSN;USER=StocksDaemon;" "SELECT duser_id FROM user;") c In the definition of `selectIntegerList': selectIntegerList c = $[splice](compileSql "DSN=MySQL_DSN;USER=StocksDaemon;" "SELECT duser_id FROM user;") c make: *** [all] Fejl 1 ok, there is some noise. But at the end of line three it says "Unknown column 'duser_id'". Also with a little more work I could properly improve the output. > Perhaps I should explain my own thoughts on the subject a bit better. > I got interested in this problem because I think it makes a nice > example of dependent types "in the real world" - you really want to But won't you end up implementing all the functionality of an SQL parser? While possible, it does seem like a huge job. With a TH solution you will safe a lot of work. Also, almost every software developer already knows SQL. And the few that do not, will likely have to learn SQL if they are to do substantial work with databases. Whereas if you implement a type based solution a developer will have to learn how to use your library. A library that will be a lot more complex to learn than what I am proposing (assuming the developer already knows SQL). > compute the *type* of a table based on the *value* of an SQL DESCRIBE. > Nicolas Oury and I have written a draft paper describing some of our > ideas: > > http://www.cs.nott.ac.uk/~wss/Publications/ThePowerOfPi.pdf > I have not read the paper yet, as I have been busy coding. Plus I have a day job. But I did read the first couple of pages and so far the paper seems very interesting. When time permits I will read the rest. Hopefully this weekend. > Any comments are very welcome! Our proposal is not as nice as it could > be (we would really like to have quotient types), but I hope it hints > at what is possible. Greetings, Mads Lindst?rm -------------- next part -------------- A non-text attachment was scrubbed... Name: SqlExpr.hs Type: text/x-haskell Size: 2119 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080507/6d89c7cf/SqlExpr-0001.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: UseSqlExpr.hs Type: text/x-haskell Size: 797 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080507/6d89c7cf/UseSqlExpr-0001.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: makefile Type: text/x-makefile Size: 99 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080507/6d89c7cf/makefile-0001.bin From prstanley at ntlworld.com Wed May 7 17:27:55 2008 From: prstanley at ntlworld.com (PR Stanley) Date: Wed May 7 17:21:52 2008 Subject: [Haskell-cafe] Induction (help!) In-Reply-To: <48210620.3080300@imageworks.com> References: <7.0.1.0.0.20080506095651.01d0edb8@ntlworld.com> <7ca3f0160805060756j42408484s85f82513a983febb@mail.gmail.com> <7.0.1.0.0.20080506223340.01dc88a0@ntlworld.com> <200805070051.25953.daniel.is.fischer@web.de> <2f9b2d30805061721g2185f976r9b783457cb2eb9bf@mail.gmail.com> <48210620.3080300@imageworks.com> Message-ID: <7.0.1.0.0.20080507222730.01d86ec0@ntlworld.com> Hi One of you chaps mentioned the Nat data type data Nat = Zero | Succ Nat Let's have add :: Nat -> Nat -> Nat add Zero n = n add (Succ m)n = Succ (add m n) Prove add m Zero = m I'm on the verge of giving up on this. :-( Cheers Paul From bulat.ziganshin at gmail.com Wed May 7 17:34:40 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed May 7 17:28:50 2008 Subject: [Haskell-cafe] Using Template Haskell to make type-safe database access In-Reply-To: <1210195445.4192.54.camel@localhost.localdomain> References: <1209760319.4242.4.camel@localhost.localdomain> <1210017744.4300.30.camel@localhost.localdomain> <6A286E8D-2C96-4E77-9FA3-077702204CBE@Cs.Nott.AC.UK> <1210195445.4192.54.camel@localhost.localdomain> Message-ID: <1977299030.20080508013440@gmail.com> Hello Mads, Thursday, May 8, 2008, 1:24:05 AM, you wrote: > also because TH is difficult. At least TH was difficult for me. It might > just be because I have never worked with anything like TH before (have no, TH is dificult by itself. if you have spare time - read about metalua, which implements the same idea in Lua environment. it's simple and straightforward, and even allows to easily change syntax. one possible reason of TH difficulty may be that Haskell is strict-typed language -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From daniel.is.fischer at web.de Wed May 7 17:39:43 2008 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Wed May 7 17:32:52 2008 Subject: [Haskell-cafe] Induction (help!) In-Reply-To: <7.0.1.0.0.20080507222730.01d86ec0@ntlworld.com> References: <7.0.1.0.0.20080506095651.01d0edb8@ntlworld.com> <48210620.3080300@imageworks.com> <7.0.1.0.0.20080507222730.01d86ec0@ntlworld.com> Message-ID: <200805072339.43514.daniel.is.fischer@web.de> Am Mittwoch, 7. Mai 2008 23:27 schrieb PR Stanley: > Hi > One of you chaps mentioned the Nat data type > data Nat = Zero | Succ Nat > > Let's have > add :: Nat -> Nat -> Nat > add Zero n = n > add (Succ m) n = Succ (add m n) > > Prove > add m Zero = m > > I'm on the verge of giving up on this. :-( > Cheers > Paul > Proposition: forall n. P(n) , where P(n): add n Zero = n Base case: P(Zero) add Zero Zero = Zero by definition of add (first clause). Induction step: Induction hypothesis is P(n) for some arbitrary, but fixed, n. Then: add (Succ n) Zero = Succ (add n Zero) -- by the second clause of add = Succ (n) -- by the induction hypothesis qed From andrewcoppin at btinternet.com Wed May 7 17:41:52 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Wed May 7 17:35:57 2008 Subject: [Haskell-cafe] Induction (help!) In-Reply-To: <7.0.1.0.0.20080507222730.01d86ec0@ntlworld.com> References: <7.0.1.0.0.20080506095651.01d0edb8@ntlworld.com> <7ca3f0160805060756j42408484s85f82513a983febb@mail.gmail.com> <7.0.1.0.0.20080506223340.01dc88a0@ntlworld.com> <200805070051.25953.daniel.is.fischer@web.de> <2f9b2d30805061721g2185f976r9b783457cb2eb9bf@mail.gmail.com> <48210620.3080300@imageworks.com> <7.0.1.0.0.20080507222730.01d86ec0@ntlworld.com> Message-ID: <48222220.1050804@btinternet.com> PR Stanley wrote: > add Zero n = n So this function takes the left argument, and replaces Zero with n. Well if n = Zero, this clearly leaves the left argument unchanged... From lrpalmer at gmail.com Wed May 7 17:43:58 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Wed May 7 17:38:02 2008 Subject: [Haskell-cafe] Induction (help!) In-Reply-To: <7.0.1.0.0.20080507222730.01d86ec0@ntlworld.com> References: <7.0.1.0.0.20080506095651.01d0edb8@ntlworld.com> <7ca3f0160805060756j42408484s85f82513a983febb@mail.gmail.com> <7.0.1.0.0.20080506223340.01dc88a0@ntlworld.com> <200805070051.25953.daniel.is.fischer@web.de> <2f9b2d30805061721g2185f976r9b783457cb2eb9bf@mail.gmail.com> <48210620.3080300@imageworks.com> <7.0.1.0.0.20080507222730.01d86ec0@ntlworld.com> Message-ID: <7ca3f0160805071443k254fa5d1n340b4d81e0c171b0@mail.gmail.com> On Wed, May 7, 2008 at 9:27 PM, PR Stanley wrote: > Hi > One of you chaps mentioned the Nat data type > > data Nat = Zero | Succ Nat > > Let's have > add :: Nat -> Nat -> Nat > add Zero n = n > add (Succ m)n = Succ (add m n) > > Prove > add m Zero = m To prove this by induction on m, you would need to show: 1) add Zero Zero = Zero 2) If "add m Zero = m", then "add (Succ m) Zero = Succ m" Number (1) is completely trivial, nothing more needs to be said. (2) is easy, after expanding the definition. Here the P I used was P(x) := add m Zero = m, the thing we were trying to prove. (1) is a base case, P(Zero). (2) is the inductive step, "If P(m) then P(Succ m)". Hoping I don't sound patronizing: if you're still having trouble, then I suspect you haven't heard what it means to prove an "if-then" statement. Here's a silly example. We want to prove: If y = 10, then y - 10 = 0. First we *assume* the condition of the if. We can consider it true. Assume y = 10. Show y - 10 = 0. Well, y = 10, so that's equivalent to 10 - 10 = 0, which is true. Luke From harkiisk at utu.fi Wed May 7 18:12:28 2008 From: harkiisk at utu.fi (Harri Kiiskinen) Date: Wed May 7 18:07:18 2008 Subject: [Haskell-cafe] runInteractiveProcess and hGetLine on Windows In-Reply-To: <1210191429.30059.403.camel@localhost> References: <4821BFE5.5090605@utu.fi> <20080507152102.GG23619@darcs.net> <4821CBC3.4000604@serpentine.com> <1210191429.30059.403.camel@localhost> Message-ID: <1210198348.17348.12.camel@localhost.localdomain> Thank You all for the lively discussion, and of course, a nice and simple answer to my problem: On Wed, 2008-05-07 at 21:17 +0100, Duncan Coutts wrote: > (inh,outh,errh,pid) <- runInteractiveProcess path args Nothing Nothing > -- We want to process the output as text. > hSetBinaryMode outh False As to the following claim: > As of a couple weeks ago the docs for runInteractiveProcess even say: > > -- The 'Handle's are initially in binary mode; if you need them to be > -- in text mode then use 'hSetBinaryMode'. At least the haskell.org standard library reference does not say this (http://haskell.org/ghc/docs/latest/html/libraries/process/System-Process.html), but the information can be found on the System.IO reference page. As a general comment to this feature, I find it quite acceptable, as on non-Windows systems it does no harm, and on Windows, you get the desired behaviour. Seems to reflect closely the practice and distinction in C (http://en.wikipedia.org/wiki/Newline), too. Harri K. From agl at imperialviolet.org Wed May 7 18:29:27 2008 From: agl at imperialviolet.org (Adam Langley) Date: Wed May 7 18:23:35 2008 Subject: [Haskell-cafe] who maintains the POSIX/Unix Unistd.hs? In-Reply-To: <5ae4f2ba0805070048k51769399yefb7c2d47a75a91d@mail.gmail.com> References: <5ae4f2ba0805070048k51769399yefb7c2d47a75a91d@mail.gmail.com> Message-ID: <396556a20805071529u765e1f95t34b881b0f35aeeab@mail.gmail.com> 2008/5/7 Galchin, Vasili : > Hello, > > I am trying to find the definition for the data type > "TimeSpec"/"CTimeSpec". http://www.haskell.org/ghc/docs/latest/html/libraries/unix/src/System-Posix-Unistd.html Doesn't look like it's exported from anywhere, just used internally for c_nanosleep AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org From duncan.coutts at worc.ox.ac.uk Wed May 7 18:31:04 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed May 7 18:23:55 2008 Subject: [Haskell-cafe] runInteractiveProcess and hGetLine on Windows In-Reply-To: <1210198348.17348.12.camel@localhost.localdomain> References: <4821BFE5.5090605@utu.fi> <20080507152102.GG23619@darcs.net> <4821CBC3.4000604@serpentine.com> <1210191429.30059.403.camel@localhost> <1210198348.17348.12.camel@localhost.localdomain> Message-ID: <1210199464.30059.416.camel@localhost> On Thu, 2008-05-08 at 00:12 +0200, Harri Kiiskinen wrote: > Thank You all for the lively discussion, and of course, a nice and > simple answer to my problem: > > On Wed, 2008-05-07 at 21:17 +0100, Duncan Coutts wrote: > > (inh,outh,errh,pid) <- runInteractiveProcess path args Nothing Nothing > > -- We want to process the output as text. > > hSetBinaryMode outh False > > As to the following claim: > > > As of a couple weeks ago the docs for runInteractiveProcess even say: > > > > -- The 'Handle's are initially in binary mode; if you need them to be > > -- in text mode then use 'hSetBinaryMode'. > > At least the haskell.org standard library reference does not say this > (http://haskell.org/ghc/docs/latest/html/libraries/process/System-Process.html) Sorry, I wasn't clear. I meant that it was added in the development branch a couple weeks ago. http://darcs.haskell.org/libraries/process/System/Process.hs Duncan From westondan at imageworks.com Wed May 7 19:20:34 2008 From: westondan at imageworks.com (Dan Weston) Date: Wed May 7 19:17:56 2008 Subject: [Haskell-cafe] Induction (help!) In-Reply-To: <7.0.1.0.0.20080507222730.01d86ec0@ntlworld.com> References: <7.0.1.0.0.20080506095651.01d0edb8@ntlworld.com> <7ca3f0160805060756j42408484s85f82513a983febb@mail.gmail.com> <7.0.1.0.0.20080506223340.01dc88a0@ntlworld.com> <200805070051.25953.daniel.is.fischer@web.de> <2f9b2d30805061721g2185f976r9b783457cb2eb9bf@mail.gmail.com> <48210620.3080300@imageworks.com> <7.0.1.0.0.20080507222730.01d86ec0@ntlworld.com> Message-ID: <48223942.2010005@imageworks.com> Paul, Sometimes it helps to go exhaustively through every detail to be sure there is no magic going on. Proceed only if you want exhaustive detail... If it seems that people are skipping some steps in their argument, it is because they are! They already understand it so well that they forgot to add them. Here is what I believe is an excruciatingly complete proof, to assure you that no handwaving is going on. The values of Nat are defined inductively on their structure, using its initial algebra. Take the data type definition data Nat = Zero | Succ Nat There is actually an implied undefined as well, so this is really Nat = undefined | Zero | Succ Nat Just as 3 = const 3 x for any x, we can convert from pointed to pointfree notation (i.e. go from a recursive definition to a least-defined fixed point definition): f = const undefined | const Zero | Succ Nat = LFP (m -> infinity) ( f^m undefined ) [ For the notationally picky, I am using | instead of + in the functor for clarity, which causes no ambiguity.] Because we are overachievers, we will prove our theorem not just for the least-defined fixed point of f, but change the limit to a union and prove it for (f^m undefined) for every m, which includes the fixed point. Why the extra work? Because now we have an inductive argument. The base case is undefined, and each step is another application of f. DEFINITION: add Zero n = n -- Line 1 add (Succ m) n = Succ (add m n) -- Line 2 THEOREM: forall x :: Nat, add x Zero = x PROOF: By induction BASE CASE: x = f^0 undefined = undefined add undefined Zero = undefined { Line 1, strict pattern match failure in first arg } STEP CASE: Assume add x Zero = x, Prove add y Zero = y where y in f x What y are in f x? f x = (const undefined | const Zero | Succ) x = const undefined x | const Zero x | Succ x = undefined | Zero | Succ x We have to consider each of these possibilities for y. 1) add undefined Zero = undefined { Base case } 2) add Zero Zero = Zero { Def. line 1 } 3) add (Succ x) Zero = Succ (add x Zero) { Def. line 2 } = Succ x { Step case assumption } This exhausts the three cases for y. Therefore, by induction add x Zero = x for all x :: Nat Note how structural induction maps to induction over integers. You do not have to enumerate some flattened form of the domain and do induction over their enumerated order. Indeed, some domains (like binary trees) are not even countably infinite, so the induction hypothesis would not be valid when used in this way. Instead you rely on the fact that all algebraic data types already have an (at most countably infinite) complete partial order based on constructor application (or eqivalently, initial algebra composition) [and always remembering that there is an implied union in | with undefined], grounded at undefined, and that consequently you can do induction over constructor application. I hope that there are no errors in the above and that I have not left out even the smallest detail. You should be able to see from the above that structural induction works on any algebraic data type. Obviously, after the first time only a masochist would be so verbose. But the induction hypothesis does after all require a first time! :) Dan Weston PR Stanley wrote: > Hi > One of you chaps mentioned the Nat data type > data Nat = Zero | Succ Nat > > Let's have > add :: Nat -> Nat -> Nat > add Zero n = n > add (Succ m)n = Succ (add m n) > > Prove > add m Zero = m > > I'm on the verge of giving up on this. :-( > Cheers > Paul From prstanley at ntlworld.com Wed May 7 20:01:26 2008 From: prstanley at ntlworld.com (PR Stanley) Date: Wed May 7 19:55:18 2008 Subject: [Haskell-cafe] Induction (help!) In-Reply-To: <7ca3f0160805071443k254fa5d1n340b4d81e0c171b0@mail.gmail.co m> References: <7.0.1.0.0.20080506095651.01d0edb8@ntlworld.com> <7ca3f0160805060756j42408484s85f82513a983febb@mail.gmail.com> <7.0.1.0.0.20080506223340.01dc88a0@ntlworld.com> <200805070051.25953.daniel.is.fischer@web.de> <2f9b2d30805061721g2185f976r9b783457cb2eb9bf@mail.gmail.com> <48210620.3080300@imageworks.com> <7.0.1.0.0.20080507222730.01d86ec0@ntlworld.com> <7ca3f0160805071443k254fa5d1n340b4d81e0c171b0@mail.gmail.com> Message-ID: <7.0.1.0.0.20080508010106.01d9cd40@ntlworld.com> So, when you apply the function to the first element in the set - e.g. Zero or Nil in the case of lists - you're actually testing to see the function works. Then in the inductive step you base everything on the assumption that p holds for some n and of course if that's true then p must hold for Succ n but you have to prove this by taking Succ from n and thus going bakc to its predecessor which is also the hypothesis p(n). So, to reiterate assumption: if hypothesis then conclusion if p(n) then p(Succ n) proof of assumption if p(Succ n) = Succ(p(n)) then we've won. If pn+1) = p(n) + p(1) then we have liftoff! I'm not going to go any further in case I'm once again on the wrong track. Cheers Paul At 22:43 07/05/2008, you wrote: >On Wed, May 7, 2008 at 9:27 PM, PR Stanley wrote: > > Hi > > One of you chaps mentioned the Nat data type > > > > data Nat = Zero | Succ Nat > > > > Let's have > > add :: Nat -> Nat -> Nat > > add Zero n = n > > add (Succ m)n = Succ (add m n) > > > > Prove > > add m Zero = m > >To prove this by induction on m, you would need to show: > >1) add Zero Zero = Zero >2) If "add m Zero = m", then "add (Succ m) Zero = Succ m" > >Number (1) is completely trivial, nothing more needs to be said. (2) >is easy, after expanding the definition. > >Here the P I used was P(x) := add m Zero = m, the thing we were trying >to prove. (1) is a base case, P(Zero). (2) is the inductive step, >"If P(m) then P(Succ m)". > >Hoping I don't sound patronizing: if you're still having trouble, then >I suspect you haven't heard what it means to prove an "if-then" >statement. Here's a silly example. > >We want to prove: If y = 10, then y - 10 = 0. > >First we *assume* the condition of the if. We can consider it true. > >Assume y = 10. >Show y - 10 = 0. >Well, y = 10, so that's equivalent to 10 - 10 = 0, which is true. > >Luke From barsoap at web.de Wed May 7 20:29:38 2008 From: barsoap at web.de (Achim Schneider) Date: Wed May 7 20:23:59 2008 Subject: [Haskell-cafe] Re: Induction (help!) References: <7.0.1.0.0.20080506095651.01d0edb8@ntlworld.com> <7ca3f0160805060756j42408484s85f82513a983febb@mail.gmail.com> <7.0.1.0.0.20080506223340.01dc88a0@ntlworld.com> <200805070051.25953.daniel.is.fischer@web.de> <2f9b2d30805061721g2185f976r9b783457cb2eb9bf@mail.gmail.com> <48210620.3080300@imageworks.com> <7.0.1.0.0.20080507222730.01d86ec0@ntlworld.com> Message-ID: <20080508022938.12bf17eb@solaris> PR Stanley wrote: > Hi > One of you chaps mentioned the Nat data type > data Nat = Zero | Succ Nat > > Let's have > add :: Nat -> Nat -> Nat > add Zero n = n > add (Succ m)n = Succ (add m n) > > Prove > add m Zero = m > > I'm on the verge of giving up on this. :-( > The important point is to learn to regard an infinite number of terms as one term, and how to mess with it without allowing individual terms to escape or dangle around. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. From ok at cs.otago.ac.nz Wed May 7 21:57:34 2008 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Wed May 7 21:51:47 2008 Subject: [Haskell-cafe] runInteractiveProcess and hGetLine on Windows In-Reply-To: <4821FAF2.2050608@btinternet.com> References: <4821BFE5.5090605@utu.fi> <20080507152102.GG23619@darcs.net> <4821FAF2.2050608@btinternet.com> Message-ID: <42DFA956-8798-4BB9-8EDA-55D94F2194B0@cs.otago.ac.nz> Windows: end of line is \r\n Unix: end of line is \n BUT, these days Windows programs have to deal with text files written on Unix, and Unix programs have to deal with text files written on Windows, especially when mounting networked file systems using things like NFS and Samba. Even when working with local files, there isn't any way for a program on either system to tell where a text file originally came from. So programs on BOTH systems really need to deal with BOTH conventions. We can go further: the Internet convention for end of line is, sadly, and somewhat accidentally, the same as the Windows convention. It's a right pain sometimes having to remember to stuff \r into things on UNIX so that it will go the right way down the wire (according to the strict protocol) to a program on the other end whose designer really wished the \r weren't there, but that's the world we live in. According to the ASCII standard, it was fully legitimate to use backspace and carriage return to get over-striking (which is why ASCII includes oddities such as ^ and ` : they really are for accents, and , did double duty as cedilla, ' as acute accent, =\b/ really was not-equals (as was /\b=), &c). According the the ISO 8859 standard, that's not kosher any more. So there are (on Windows and Unix) no known uses for isolated \r characters. Accordingly, a text mode that simply throws away every \r it comes across will not just be useful on Windows, it will be useful on Unix as well. The old DOS Ctrl-Z convention hasn't been recommended practice on Windows for years, so there's not much point bothering with that. From dons at galois.com Wed May 7 23:30:13 2008 From: dons at galois.com (Don Stewart) Date: Wed May 7 23:24:17 2008 Subject: [Haskell-cafe] Interesting critique of OCaml Message-ID: <20080508033013.GA29498@scytale.galois.com> An interesting critique of OCaml. http://enfranchisedmind.com/blog/2008/05/07/why-ocaml-sucks/ One phrase that stood out, regarding GHC's support for deforestation transformations like build/foldr and stream fusion: "Haskell is doing data structure level optimizations with the ease that most other compiler do peephole instruction optimization. This is a non-trivial result." Which I think really captures the joy of being able to write algebraic and data structure transformations, via rewrite rules, without having to extend the compiler -- all thanks to purity, laziness, and static typing. -- Don From bhargava.ambrish at gmail.com Thu May 8 00:37:31 2008 From: bhargava.ambrish at gmail.com (Ambrish Bhargava) Date: Thu May 8 00:31:37 2008 Subject: [Haskell-cafe] I am new to haskell Message-ID: Hi All, I am new to Haskell. Can anyone guide me how can I start on it (Like getting binaries, some tutorials)? Thanks in advance. -- Regards, Ambrish Bhargava -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080508/5732f253/attachment.htm From bhargava.ambrish at gmail.com Thu May 8 00:39:44 2008 From: bhargava.ambrish at gmail.com (Ambrish Bhargava) Date: Thu May 8 00:33:48 2008 Subject: [Haskell-cafe] How can see old threads. Message-ID: Hi, I want to know, how can see old threads (may be I can get my answers from there itself)? -- Regards, Ambrish Bhargava -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080508/5ece1f61/attachment.htm From derek.a.elkins at gmail.com Thu May 8 00:47:51 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Thu May 8 00:41:58 2008 Subject: [Haskell-cafe] I am new to haskell In-Reply-To: References: Message-ID: <1210222071.5514.41.camel@derek-laptop> On Thu, 2008-05-08 at 10:07 +0530, Ambrish Bhargava wrote: > Hi All, > > I am new to Haskell. Can anyone guide me how can I start on it (Like > getting binaries, some tutorials)? All of this is on haskell.org. I'm kind of curious how you know about this mailing list without going to haskell.org or seeing all the resources on it. From dons at galois.com Thu May 8 00:56:47 2008 From: dons at galois.com (Don Stewart) Date: Thu May 8 00:50:55 2008 Subject: [Haskell-cafe] How can see old threads. In-Reply-To: References: Message-ID: <20080508045647.GB29498@scytale.galois.com> bhargava.ambrish: > Hi, > > I want to know, how can see old threads (may be I can get my answers from > there itself)? > You can search the list here: http://dir.gmane.org/gmane.comp.lang.haskell.cafe And find more information about all the lists and other resources at: http://haskell.org -- Don From bhargava.ambrish at gmail.com Thu May 8 00:58:32 2008 From: bhargava.ambrish at gmail.com (Ambrish Bhargava) Date: Thu May 8 00:52:37 2008 Subject: [Haskell-cafe] How can see old threads. In-Reply-To: <20080508045647.GB29498@scytale.galois.com> References: <20080508045647.GB29498@scytale.galois.com> Message-ID: Thanks.. On Thu, May 8, 2008 at 10:26 AM, Don Stewart wrote: > bhargava.ambrish: > > Hi, > > > > I want to know, how can see old threads (may be I can get my answers > from > > there itself)? > > > > You can search the list here: > > http://dir.gmane.org/gmane.comp.lang.haskell.cafe > > And find more information about all the lists and other resources at: > > http://haskell.org > > -- Don > -- Regards, Ambrish Bhargava -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080508/3fbe1262/attachment.htm From ketil at malde.org Thu May 8 01:20:50 2008 From: ketil at malde.org (Ketil Malde) Date: Thu May 8 01:14:45 2008 Subject: [Haskell-cafe] runInteractiveProcess and hGetLine on Windows In-Reply-To: <42DFA956-8798-4BB9-8EDA-55D94F2194B0@cs.otago.ac.nz> (Richard A. O'Keefe's message of "Thu\, 8 May 2008 13\:57\:34 +1200") References: <4821BFE5.5090605@utu.fi> <20080507152102.GG23619@darcs.net> <4821FAF2.2050608@btinternet.com> <42DFA956-8798-4BB9-8EDA-55D94F2194B0@cs.otago.ac.nz> Message-ID: <87prrxgyml.fsf@nmd9999.imr.no> "Richard A. O'Keefe" writes: > According to the ASCII standard, it was fully legitimate to use > backspace and carriage return to get over-striking (which is why ASCII > includes oddities such as ^ and ` : they really are for accents, and , > did double duty as cedilla, ' as acute accent, =\b/ really was > not-equals (as was /\b=), &c). According the the ISO 8859 standard, > that's not kosher any more. So there are (on Windows and Unix) no > known uses for isolated \r characters. Say what? I use \r when generating output to a terminal when I want to update the current line of output instead of writing a new line. E.g. for tracking progress in my programs. (As a line terminator followed by \n, it would have no effect though.) -k -- If I haven't seen further, it is by standing in the footprints of giants From abhay.parvate at gmail.com Thu May 8 02:16:16 2008 From: abhay.parvate at gmail.com (Abhay Parvate) Date: Thu May 8 02:10:19 2008 Subject: [Haskell-cafe] Re: Control.Exception.evaluate - 'correct definition' not so correct In-Reply-To: References: <20080503091917.GA5333@shion.is.fushizen.net> <5ab17e790805041730o33b378e4u74f4f1f9e813e72b@mail.gmail.com> <7ca3f0160805060727n52bbe96fracd3d9a303f61ba3@mail.gmail.com> <3c4d5adf0805070412x376ab151sda733cfed3947acd@mail.gmail.com> Message-ID: <3c4d5adf0805072316y3233ec6ak6170063f3a46bea2@mail.gmail.com> Thanks both for the the explanation and the link. The wikibook is really growing fast! Abhay On Wed, May 7, 2008 at 5:05 PM, apfelmus wrote: > Abhay Parvate wrote: > > > Just for curiocity, is there a practically useful computation that uses > > 'seq' in an essential manner, i.e. apart from the efficiency reasons? > > > > I don't think so because you can always replace seq with const id . > In fact, doing so will get you "more" results, i.e. a computation that > did not terminate may do so now. > > In other words, we have > > seq _|_ = _|_ > seq x = id for x > _|_ > > but > > (const id) _|_ = id > (const id) x = id for x > _|_ > > So, (const id) is always more defined (">") than seq . > > > For more about _|_ and the semantic approximation order, see > > http://en.wikibooks.org/wiki/Haskell/Denotational_semantics > > > > Regards, > apfelmus > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080508/f5e79fe5/attachment.htm From dekudekuplex at yahoo.com Thu May 8 02:59:37 2008 From: dekudekuplex at yahoo.com (Benjamin L. Russell) Date: Thu May 8 02:53:38 2008 Subject: [Haskell-cafe] I am new to haskell In-Reply-To: Message-ID: <211207.79205.qm@web30202.mail.mud.yahoo.com> One hint that is not (at least to my knowledge) listed on haskell.org is that, according to at least one user (see "The Programmers? Stone ? Blog Archive ? A First Haskell Experience" at http://the-programmers-stone.com/2008/03/04/a-first-haskell-experience/), the online tutorials can "confuse more than they illuminate." Personally, I would recommend starting with one of the available books (see "Books - HaskellWiki" at http://haskell.org/haskellwiki/Books), instead. In particular, I would recommend one of the following titles: * Paul Hudak: The Haskell School of Expression: Learning Functional Programming through Multimedia, Cambridge University Press, New York, 2000, 416 pp, 15 line diagrams, 75 exercises, Paperback $29.95, ISBN 0521644089, Hardback $74.95, ISBN 0521643384. (See http://www.haskell.org/soe/.) - This book uses multimedia examples to motivate learning Haskell, and is extremely interesting to read. The one drawback I discovered was that some of the exercises assume trigonometry, which I had learned long ago but forgotten by the time I started reading this book. In my opinion, this book is to Haskell as SICP is to Scheme (i.e., it is the authoritative textbook on this subject). * Kees Doets and Jan van Eijck: The Haskell Road to Logic, Maths and Programming, King's College Publications, London, 2004, 14.00 pounds or $25.00, ISBN 0-9543006-9-6. (See http://homepages.cwi.nl/~jve/HR/.) - While this book approaches Haskell from a proof-oriented, mathematical perspective guided toward proving program correctness, it assumes only elementary mathematics and is very easy to approach. Personally, I found it much easier to follow than any of the existing online tutorials. Another tip is to write your own version of Towers of Hanoi (see http://en.wikipedia.org/wiki/Tower_of_Hanoi) in Haskell. Writing your own original programs is usually a much quicker road to mastering a programming language than just reading books, because it forces you to think in the target programming language. Benjamin L. Russell --- On Thu, 5/8/08, Ambrish Bhargava wrote: > From: Ambrish Bhargava > Subject: [Haskell-cafe] I am new to haskell > To: haskell-cafe@haskell.org > Date: Thursday, May 8, 2008, 1:37 PM > Hi All, > > I am new to Haskell. Can anyone guide me how can I start on > it (Like getting > binaries, some tutorials)? > > Thanks in advance. > > -- > Regards, > Ambrish > Bhargava_______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From wss at Cs.Nott.AC.UK Thu May 8 03:52:16 2008 From: wss at Cs.Nott.AC.UK (Wouter Swierstra) Date: Thu May 8 03:48:02 2008 Subject: [Haskell-cafe] The Monad.Reader (11) - Call for Copy In-Reply-To: <4821FB57.3010808@btinternet.com> References: <4821FB57.3010808@btinternet.com> Message-ID: On 7 May 2008, at 19:56, Andrew Coppin wrote: > Wouter Swierstra wrote: >> Please consider writing something for the next issue of The >> Monad.Reader. > > You know, I'm actually tempted to do just that... Please do! We've had lots of excellent articles written by people who were just learning Haskell. Sometimes a beginner's perspective can be quite refreshing. Feel free to contact me personally if you have any questions. All the best, Wouter This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. From noteed at gmail.com Thu May 8 04:00:23 2008 From: noteed at gmail.com (minh thu) Date: Thu May 8 03:54:37 2008 Subject: [Haskell-cafe] I am new to haskell In-Reply-To: <211207.79205.qm@web30202.mail.mud.yahoo.com> References: <211207.79205.qm@web30202.mail.mud.yahoo.com> Message-ID: <40a414c20805080100i32df31a8kb334c896dbea4138@mail.gmail.com> Hi, Personnaly, I started to learn Haskell with A Gentle Introduction and (from what I recall) really enjoyed it. I find The Haskell School of Expression a bit problematic because it interleaves information about the language with (although nice) large running-through-all-the-chapter examples. Anyway, welcome ! Thu 2008/5/8, Benjamin L. Russell : > One hint that is not (at least to my knowledge) listed on haskell.org is > that, according to at least one user (see "The Programmers' Stone ? Blog > Archive ? A First Haskell Experience" at > http://the-programmers-stone.com/2008/03/04/a-first-haskell-experience/), > the online tutorials can "confuse more than they illuminate." > > Personally, I would recommend starting with one of the available books (see > "Books - HaskellWiki" at http://haskell.org/haskellwiki/Books), instead. In > particular, I would recommend one of the following titles: > > * Paul Hudak: The Haskell School of Expression: Learning Functional > Programming through Multimedia, Cambridge University Press, New York, 2000, > 416 pp, 15 line diagrams, 75 exercises, Paperback $29.95, ISBN 0521644089, > Hardback $74.95, ISBN 0521643384. (See http://www.haskell.org/soe/.) > - This book uses multimedia examples to motivate learning Haskell, and is > extremely interesting to read. The one drawback I discovered was that some > of the exercises assume trigonometry, which I had learned long ago but > forgotten by the time I started reading this book. In my opinion, this book > is to Haskell as SICP is to Scheme (i.e., it is the authoritative textbook > on this subject). > > * Kees Doets and Jan van Eijck: The Haskell Road to Logic, Maths and > Programming, King's College Publications, London, 2004, 14.00 pounds or > $25.00, ISBN 0-9543006-9-6. (See http://homepages.cwi.nl/~jve/HR/.) > - While this book approaches Haskell from a proof-oriented, mathematical > perspective guided toward proving program correctness, it assumes only > elementary mathematics and is very easy to approach. Personally, I found it > much easier to follow than any of the existing online tutorials. > > Another tip is to write your own version of Towers of Hanoi (see > http://en.wikipedia.org/wiki/Tower_of_Hanoi) in Haskell. Writing your own > original programs is usually a much quicker road to mastering a programming > language than just reading books, because it forces you to think in the > target programming language. > > Benjamin L. Russell > > --- On Thu, 5/8/08, Ambrish Bhargava wrote: > > > From: Ambrish Bhargava > > Subject: [Haskell-cafe] I am new to haskell > > To: haskell-cafe@haskell.org > > Date: Thursday, May 8, 2008, 1:37 PM > > Hi All, > > > > I am new to Haskell. Can anyone guide me how can I start on > > it (Like getting > > binaries, some tutorials)? > > > > Thanks in advance. > > > > -- > > Regards, > > Ambrish > > Bhargava_______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From wss at Cs.Nott.AC.UK Thu May 8 05:02:12 2008 From: wss at Cs.Nott.AC.UK (Wouter Swierstra) Date: Thu May 8 04:58:18 2008 Subject: [Haskell-cafe] Using Template Haskell to make type-safe database access In-Reply-To: <1210195445.4192.54.camel@localhost.localdomain> References: <1209760319.4242.4.camel@localhost.localdomain> <1210017744.4300.30.camel@localhost.localdomain> <6A286E8D-2C96-4E77-9FA3-077702204CBE@Cs.Nott.AC.UK> <1210195445.4192.54.camel@localhost.localdomain> Message-ID: <0C39F272-5FC0-48A7-8831-1F2BF03F4989@Cs.Nott.AC.UK> Hi Mads, > Not only pictures, but also code can say more than a thousands words. > Therefore, I have been implementing a proof of concept. The code is > attached in two files. Nice! I have to admit, it's much nicer than I expected it to be. Just out of curiousity, what happens when you write: selectTupleList :: Connection -> IO [Integer] instead of selectTupleList :: Connection -> IO [(Integer, String, String)] What kind of error message do you get? More specifically, is this error caught statically or dynamically. The only other limitation I can think of, would be in the situation where you don't have compile-time access to the database, e.g. developing software for a client with a database that can only be accessed from their intranet. I have no idea how much of a limitation that is. > ok, there is some noise. But at the end of line three it says "Unknown > column 'duser_id'". Also with a little more work I could properly > improve the output. The message is a bit verbose, but if you ignore the noise, it gives pretty good feedback about what's wrong. Good. >> Perhaps I should explain my own thoughts on the subject a bit better. >> I got interested in this problem because I think it makes a nice >> example of dependent types "in the real world" - you really want to > > But won't you end up implementing all the functionality of an SQL > parser? While possible, it does seem like a huge job. With a TH > solution > you will safe a lot of work. Yes - but parsing the result of an SQL describe statement is pretty easy. > A library that > will be a lot more complex to learn than what I am proposing (assuming > the developer already knows SQL). Hmm. This is a rather sticky point. One might also argue that Haskell developers have to learn SQL to use the solution you propose. I'm not particularly convinced. Both approaches have their merits I think. Anyhow - nice work! Have you asked Bjorn Bringert what he thinks? He's a really clever and approachable guy - and he knows a lot more about interfacing with databases than I do. Kind regards, Wouter This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. From bhargava.ambrish at gmail.com Thu May 8 05:22:17 2008 From: bhargava.ambrish at gmail.com (Ambrish Bhargava) Date: Thu May 8 05:16:20 2008 Subject: [Haskell-cafe] I am new to haskell In-Reply-To: <211207.79205.qm@web30202.mail.mud.yahoo.com> References: <211207.79205.qm@web30202.mail.mud.yahoo.com> Message-ID: Thanks for this list. On Thu, May 8, 2008 at 12:29 PM, Benjamin L. Russell wrote: > One hint that is not (at least to my knowledge) listed on haskell.org is > that, according to at least one user (see "The Programmers' Stone ? Blog > Archive ? A First Haskell Experience" at > http://the-programmers-stone.com/2008/03/04/a-first-haskell-experience/), > the online tutorials can "confuse more than they illuminate." > > Personally, I would recommend starting with one of the available books > (see "Books - HaskellWiki" at http://haskell.org/haskellwiki/Books), > instead. In particular, I would recommend one of the following titles: > > * Paul Hudak: The Haskell School of Expression: Learning Functional > Programming through Multimedia, Cambridge University Press, New York, 2000, > 416 pp, 15 line diagrams, 75 exercises, Paperback $29.95, ISBN 0521644089, > Hardback $74.95, ISBN 0521643384. (See http://www.haskell.org/soe/.) > - This book uses multimedia examples to motivate learning Haskell, and is > extremely interesting to read. The one drawback I discovered was that some > of the exercises assume trigonometry, which I had learned long ago but > forgotten by the time I started reading this book. In my opinion, this book > is to Haskell as SICP is to Scheme (i.e., it is the authoritative textbook > on this subject). > > * Kees Doets and Jan van Eijck: The Haskell Road to Logic, Maths and > Programming, King's College Publications, London, 2004, 14.00 pounds or > $25.00, ISBN 0-9543006-9-6. (See http://homepages.cwi.nl/~jve/HR/ > .) > - While this book approaches Haskell from a proof-oriented, mathematical > perspective guided toward proving program correctness, it assumes only > elementary mathematics and is very easy to approach. Personally, I found it > much easier to follow than any of the existing online tutorials. > > Another tip is to write your own version of Towers of Hanoi (see > http://en.wikipedia.org/wiki/Tower_of_Hanoi) in Haskell. Writing your own > original programs is usually a much quicker road to mastering a programming > language than just reading books, because it forces you to think in the > target programming language. > > Benjamin L. Russell > > --- On Thu, 5/8/08, Ambrish Bhargava wrote: > > > From: Ambrish Bhargava > > Subject: [Haskell-cafe] I am new to haskell > > To: haskell-cafe@haskell.org > > Date: Thursday, May 8, 2008, 1:37 PM > > Hi All, > > > > I am new to Haskell. Can anyone guide me how can I start on > > it (Like getting > > binaries, some tutorials)? > > > > Thanks in advance. > > > > -- > > Regards, > > Ambrish > > Bhargava_______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- Regards, Ambrish Bhargava -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080508/6559b954/attachment.htm From madocdoyu at gmail.com Thu May 8 06:34:23 2008 From: madocdoyu at gmail.com (Madoc) Date: Thu May 8 06:28:24 2008 Subject: [Haskell-cafe] Random numbers / monads - beginner question Message-ID: <17124380.post@talk.nabble.com> Hello, I am just learning Haskell. Now, I encountered something that I cannot solve by myself. Your advice will be greatly appreciated. Given a list of numbers, I want to modify each of those numbers by adding a random offset. However, each such modified number shall stay within certain bounds, given by the integers minValue and maxValue. After that, I want to continue computation with the resulting list of type [Int]. But for demonstration, I made a program that just prints out the list: import IO; import Random minValue = 0::Int maxValue = 1000::Int normalize a | a < minValue = minValue | a > maxValue = maxValue | otherwise = a modify a = do offset <- randomRIO(-100::Int, 100) return(normalize(a + offset)) main = putStrLn $ show $ map (modify) [0, 200, 400, 600, 800, 1000] This program will not compile. GHC complains: test.hs:14:18: No instance for (Show (IO Int)) arising from a use of `show' at test.hs:14:18-21 Possible fix: add an instance declaration for (Show (IO Int)) In the first argument of `($)', namely `show' In the second argument of `($)', namely `show $ map (modify) [0, 200, 400, 600, ....]' In the expression: putStrLn $ show $ map (modify) [0, 200, 400, 600, ....] I understand that the result of the modify function is not an Int, as I would like to have it, but instead IO Int, and that cannot be applied to show. (I also did not quite understand why I need those brackets around the return value of the modify value. It won't compile if I leave them out, but I can accept that for now.) I also figured out how to generate a modified list of type [IO Int] and of type IO [Int]. However, I could not find out how to completely get rid of the IO monad and just get a mofied list of type [Int], which is what I really want. Please, do You have any advice for me? I tried for some hours, and now I am really angry at that IO monad that sticks to my pretty integers like glue! Also, any comment on the programming style and how I could achive my goals easier would be appreciated. (I left out comments and function types for the sake of brevity.) Thanks a lot in advance. Madoc. -- View this message in context: http://www.nabble.com/Random-numbers---monads---beginner-question-tp17124380p17124380.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080508/2d906796/attachment-0001.htm From claudiusmaximus at goto10.org Thu May 8 06:47:59 2008 From: claudiusmaximus at goto10.org (Claude Heiland-Allen) Date: Thu May 8 06:42:03 2008 Subject: [Haskell-cafe] Random numbers / monads - beginner question In-Reply-To: <17124380.post@talk.nabble.com> References: <17124380.post@talk.nabble.com> Message-ID: <4822DA5F.5050603@goto10.org> Madoc wrote: > Given a list of numbers, I want to modify each of those numbers by adding a > random offset. However, each such modified number shall stay within certain > bounds, given by the integers minValue and maxValue. After that, I want to > continue computation with the resulting list of type [Int]. Personally, I'd do something like this, isolate the IO code outside the algorithm to keep the algorithm pure: modify' :: Int -> Int -> Int modify' offset a = normalize (a + offset) generateInfiniteListOfRandomNumbers :: IO [Int] -- implementation left as an exercise main = do randomNumbers <- generateInfiniteListOfRandomNumbers print $ zipWith modify' randomNumbers [0, 200, 400, 600, 800, 1000] hope this helps, Claude -- http://claudiusmaximus.goto10.org From byorgey at gmail.com Thu May 8 07:18:39 2008 From: byorgey at gmail.com (Brent Yorgey) Date: Thu May 8 07:12:42 2008 Subject: [Haskell-cafe] help in tree folding In-Reply-To: <48218432.9020201@gmail.com> References: <48204CF4.2040808@gmail.com> <22fcbd520805060742ked232cate31e436e21c9ee68@mail.gmail.com> <4820C25B.3080906@gmail.com> <200805062116.00279.daniel.is.fischer@web.de> <48218432.9020201@gmail.com> Message-ID: <22fcbd520805080418y6afeccc2gff156a00870a13f4@mail.gmail.com> On Wed, May 7, 2008 at 6:28 AM, patrik osgnach wrote: > Daniel Fischer ha scritto: > > Am Dienstag, 6. Mai 2008 22:40 schrieb patrik osgnach: >> >>> Brent Yorgey ha scritto: >>> >>>> On Tue, May 6, 2008 at 8:20 AM, patrik osgnach < >>>> patrik.osgnach@gmail.com> >>>> >>>> wrote: >>>> >>>>> Hi. I'm learning haskell but i'm stuck on a generic tree folding >>>>> exercise. i must write a function of this type >>>>> treefoldr::(Eq a,Show a)=>(a->b->c)->c->(c->b->b)->b->Tree a->c >>>>> Tree has type >>>>> data (Eq a,Show a)=>Tree a=Void | Node a [Tree a] deriving (Eq,Show) >>>>> as an example treefoldr (:) [] (++) [] (Node '+' [Node '*' [Node 'x' >>>>> [], >>>>> Node 'y' []], Node 'z' []]) >>>>> must return "+?xyz" >>>>> any help? >>>>> (sorry for my bad english) >>>>> >>>> Having a (Tree a) parameter, where Tree is defined as an algebraic data >>>> type, also immediately suggests that you should do some pattern-matching >>>> to break treefoldr down into cases: >>>> >>>> treefoldr f y g z Void = ? >>>> treefoldr f y g z (Node x t) = ? >>>> >>>> -Brent >>>> >>> so far i have tried >>> treefoldr f x g y Void = x >>> >> >> Yes, nothing else could be done. >> >> treefoldr f x g y (Node a []) = f a y >>> >> >> Not bad. But actually there's no need to treat nodes with and without >> children differently. >> Let's see: >> >> treefoldr f x g y (Node v ts) >> >> should have type c, and it should use v. We have >> f :: a -> b -> c >> x :: c >> g :: c -> b -> b >> y :: b >> v :: a. >> >> The only thing which produces a value of type c using a value of type a is >> f, so we must have >> >> treefoldr f x g y (Node v ts) = f v someExpressionUsing'ts' >> >> where >> >> someExpressionUsing'ts' :: b. >> >> The only thing we have which produces a value of type b is g, so >> someExpressionUsing'ts' must ultimately be g something somethingElse. >> Now take a look at the code and type of foldr, that might give you the >> idea. >> >> Cheers, >> Daniel >> >> >> treefoldr f x g y (Node a (t:ts)) = treefoldr f x g (g (treefoldr f x g >>> y t) y) (Node a ts) >>> but it is incorrect. i can't figure out how to build the recursive call >>> thanks for the answer >>> Patrik >>> >> >> >> thanks for the tip. > so, if i have understood correctly i have to wirite something like: > treefoldr f x g y (Node a ts) = f a (g (treefoldr f x g y (head ts)) (g > (treefoldr f x g y (head (tail ts)) (g ... > it looks like a list foldr so... > treefoldr f x g y Void = x > treefoldr f x g y (Node a ts) = f a (foldr (g) y (map (treefoldr f x g y) > ts)) > it seems to work. i'm not yet sure it is correct but is better than nothing > thanks to you all. now i will try to write a treefoldl > If it typechecks and you have used all the parameters, then it is probably correct! =) That may sound trite, but it is often true. -Brent -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080508/fb49861f/attachment.htm From byorgey at gmail.com Thu May 8 07:29:27 2008 From: byorgey at gmail.com (Brent Yorgey) Date: Thu May 8 07:23:32 2008 Subject: [Haskell-cafe] Induction (help!) In-Reply-To: <7.0.1.0.0.20080508010106.01d9cd40@ntlworld.com> References: <7.0.1.0.0.20080506095651.01d0edb8@ntlworld.com> <7ca3f0160805060756j42408484s85f82513a983febb@mail.gmail.com> <7.0.1.0.0.20080506223340.01dc88a0@ntlworld.com> <200805070051.25953.daniel.is.fischer@web.de> <2f9b2d30805061721g2185f976r9b783457cb2eb9bf@mail.gmail.com> <48210620.3080300@imageworks.com> <7.0.1.0.0.20080507222730.01d86ec0@ntlworld.com> <7ca3f0160805071443k254fa5d1n340b4d81e0c171b0@mail.gmail.com> <7.0.1.0.0.20080508010106.01d9cd40@ntlworld.com> Message-ID: <22fcbd520805080429r6ad6d962x508aca235283c52a@mail.gmail.com> On Wed, May 7, 2008 at 8:01 PM, PR Stanley wrote: > So, when you apply the function to the first element in the set - e.g. Zero > or Nil in the case of lists - you're actually testing to see the function > works. Then in the inductive step you base everything on the assumption that > p holds for some n and of course if that's true then p must hold for Succ n > but you have to prove this by taking Succ from n and thus going bakc to its > predecessor which is also the hypothesis p(n). > So, to reiterate > assumption: if hypothesis then conclusion > if p(n) then p(Succ n) > proof of assumption if p(Succ n) = Succ(p(n)) then we've won. If pn+1) = > p(n) + p(1) then we have liftoff! > I'm not going to go any further in case I'm once again on the wrong track. > Cheers > Paul > You've got the right idea. I should point out that it doesn't make sense to say p(Succ n) = Succ(p(n)), p(x) represents some statement that is either true or false, so it doesn't make sense to say Succ(p(n)). But I think you are on the right track. -Brent -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080508/154ad486/attachment.htm From thomas-haskell at d-y.me.uk Thu May 8 07:36:29 2008 From: thomas-haskell at d-y.me.uk (Thomas Dinsdale-Young) Date: Thu May 8 07:30:33 2008 Subject: [Haskell-cafe] Random numbers / monads - beginner question In-Reply-To: References: Message-ID: <8b61bd180805080436h232ba6a5r5fe5ea8c153ea586@mail.gmail.com> Madoc wrote: Given a list of numbers, I want to modify each of those numbers by adding a random offset. However, each such modified number shall stay within certain bounds, given by the integers minValue and maxValue. After that, I want to continue computation with the resulting list of type [Int]. Personally, I'd do something like this, isolate the IO code outside the algorithm to keep the algorithm pure: modify' :: Int -> Int -> Int modify' offset a = normalize (a + offset) generateInfiniteListOfRandomNumbers :: IO [Int] -- implementation left as an exercise main = do randomNumbers <- generateInfiniteListOfRandomNumbers print $ zipWith modify' randomNumbers [0, 200, 400, 600, 800, 1000] I may be wrong, but generateInfiniteListOfRandomNumbers won't terminate and I think it has to before the next IO action occurs. (Laziness is great, but I don't think you can really do lazy IO like that.) Instead of map :: (a -> b) -> [a] -> [b], I think you are looking for mapM :: Monad m => (a -> m b) -> [a] -> m [b]. * * * *Hope this helps, Thomas > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080508/8ac9a21b/attachment.htm From byorgey at gmail.com Thu May 8 07:45:23 2008 From: byorgey at gmail.com (Brent Yorgey) Date: Thu May 8 07:39:25 2008 Subject: [Haskell-cafe] Random numbers / monads - beginner question In-Reply-To: <8b61bd180805080436h232ba6a5r5fe5ea8c153ea586@mail.gmail.com> References: <8b61bd180805080436h232ba6a5r5fe5ea8c153ea586@mail.gmail.com> Message-ID: <22fcbd520805080445r11a70372q6716863d8ec1135f@mail.gmail.com> 2008/5/8 Thomas Dinsdale-Young : > Madoc wrote: > > Given a list of numbers, I want to modify each of those numbers by adding a > > random offset. However, each such modified number shall stay within certain > > bounds, given by the integers minValue and maxValue. After that, I want to > continue computation with the resulting list of type [Int]. > > > Personally, I'd do something like this, isolate the IO code outside the > algorithm to keep the algorithm pure: > > > modify' :: Int -> Int -> Int > modify' offset a = normalize (a + offset) > > generateInfiniteListOfRandomNumbers :: IO [Int] > -- implementation left as an exercise > > main = do > randomNumbers <- generateInfiniteListOfRandomNumbers > print $ zipWith modify' randomNumbers [0, 200, 400, 600, 800, 1000] > > I may be wrong, but generateInfiniteListOfRandomNumbers won't terminate > and I think it has to before the next IO action occurs. (Laziness is great, > but I don't think you can really do lazy IO like that.) > Sure it will. You're right that you cannot do lazy IO like this, but no lazy IO needs to happen here. The key is that an IO action does not have to be performed in order to generate each element of the list -- one IO action is performed at the beginning to produce a random generator, and then this generator is used (functionally and purely) to produce a lazy infinite list of pseudorandom numbers. For example see the 'newStdGen' and 'randoms' functions from System.Random. -Brent -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080508/968cccb3/attachment.htm From marlowsd at gmail.com Thu May 8 08:30:03 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Thu May 8 08:24:11 2008 Subject: [Haskell-cafe] Re: [Haskell] Re: ANN: Haddock version 2.1.0 In-Reply-To: References: <20080501190625.GB474@localhost> <481A46C0.3050209@gmail.com> <012e01c8ac61$cc2f0d60$bf078351@cr3lt> Message-ID: <4822F24B.4040801@microsoft.com> David Waern wrote: > 2008/5/2 Claus Reinke : >>> 2008/5/2 Simon Marlow : >>> >>>> David Waern wrote: >>>> >>>>> No it doesn't, but it's on the TODO list. It needs a fix in GHC. >>>>> >>>>> By the way, I'm going to experiment with doing the parsing of comments >>>>> on the Haddock side instead of in GHC. >>>>> If that works out, we won't have to fix these things in GHC anymore. >>>>> >>>> Sounds great - along the lines that we discussed on cvs-ghc a while >> back? >>> Yes, something along the lines of separately parsing the comments and >>> recording their source locations, and then >>> trying to match them with the source locations of the AST nodes. >>> >> yay!-) i hope that the haddock-independent part (parsing, preserving, >> and accessing comments) becomes part of the GHC API in a form that would >> fix trac ticket #1886, then we could finally start writing (ghc) haskell >> source-to-source transformations without losing pragmas or comments! >> losing layout would still be a pain, but that could be dealt with >> later - at least the code would remain functional under some >> form of (pretty . id . parse). > > Hmm. When it comes Haddock, things are simpler than in a refactoring > situation, since we don't need to know exactly where the comments > appear in the concrete syntax. The original Haddock parser is very > liberal in where you can place comments. For example, it doesn't > matter if you place a comment before or after a comma in a record > field list, it is still attached to the previous (or next, depending > on the type of comment) field. I need to take another look at the > grammar to confirm that this is true in general, though. But anyway, > my plan was to do this entirely in Haddock, not do the "preserving" > part that you mention, and not do anything to GHC. So basically you want to run a lexer over the source again to collect all the comments? You really want to use GHC's lexer, because otherwise you have to write another lexer. So a flag to GHC's lexer that says whether it should return comments or not seems like a reasonable way to go. But if you're doing that, you might as well have the parser collect all the comments off to the side during parsing, to avoid having to lex the file twice, right? Cheers, Simon From lemming at henning-thielemann.de Thu May 8 08:36:21 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu May 8 08:29:19 2008 Subject: [Haskell-cafe] Random numbers / monads - beginner question In-Reply-To: <17124380.post@talk.nabble.com> References: <17124380.post@talk.nabble.com> Message-ID: On Thu, 8 May 2008, Madoc wrote: > Given a list of numbers, I want to modify each of those numbers by adding a > random offset. However, each such modified number shall stay within certain > bounds, given by the integers minValue and maxValue. After that, I want to > continue computation with the resulting list of type [Int]. But for > demonstration, I made a program that just prints out the list: > > > import IO; import Random > > minValue = 0::Int > maxValue = 1000::Int > > normalize a | a < minValue = minValue > | a > maxValue = maxValue > | otherwise = a normalize = min maxValue . max minValue > modify a = do > offset <- randomRIO(-100::Int, 100) > return(normalize(a + offset)) Stay away from IO whereever possible, use randomR instead. Say map normalize (zipWith (+) (randomRs (-100::Int, 100)) x) http://haskell.org/haskellwiki/Humor/Erlk??nig http://haskell.org/haskellwiki/Things_to_avoid#Separate_IO_and_data_processing From mark at simplycompute.co.uk Thu May 8 08:45:42 2008 From: mark at simplycompute.co.uk (Mark Wallsgrove) Date: Thu May 8 08:40:20 2008 Subject: [Haskell-cafe] IO Help Message-ID: <4822F5F6.30000@simplycompute.co.uk> Hey, I am studying Haskell as a unit at University. I find the concept and design idea's of Haskell interesting but I am finding my self struggling to understand the relationship between the normal state and IO state of Haskell. This is my situation: I have created 12 functions for a program which take in two types: type Catalogue = [Track] type Playlist = [Track] The definition for track is as follows: -- Track = ArtistDetails Title Length PCount data Track = Track ArtistType String Float Int deriving (Show,Eq,Read) -- Popular = Artist | Composor Performer data ArtistType = Popular String | Classical String String deriving (Show,Eq,Read) I have managed to save the data to a file using this code: --Saving Data saveData :: String -> Catalogue -> IO() saveData fileName catalogue = writeFile fileName (show catalogue) Problem now is reading the data back into the program. When I read the data back into the program it comes as IO [Track]. This is the code I have been using to load the data: loadData :: String -> Catalogue loadData fileName = do x <- readFile fileName return (read x :: Catalogue) I think I have missed a trick some where or I am using IO wrong, I really don't know. I believe it is the latter. I have been told that my definition for the function is wrong and that I should use the lazy approach to fix the problem. But this still leaves me with IO [Track]. Could someone inform me on what I am doing wrong? Thank you in advance Smoky From lemming at henning-thielemann.de Thu May 8 08:55:19 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu May 8 08:48:11 2008 Subject: [Haskell-cafe] IO Help In-Reply-To: <4822F5F6.30000@simplycompute.co.uk> References: <4822F5F6.30000@simplycompute.co.uk> Message-ID: On Thu, 8 May 2008, Mark Wallsgrove wrote: > Problem now is reading the data back into the program. When I read the data > back into the program it comes as IO [Track]. This is the code I have been > using to load the data: > > > loadData :: String -> Catalogue > loadData fileName = do x <- readFile fileName > return (read x :: Catalogue) type should be loadData :: String -> IO Catalogue But using plainly 'read' may not satisfy you, because the program will abort unrecoverably if the file has corrupt content. You may want to use 'reads' and check manually if parsing was successful: case reads x of [(cat, "")] -> return cat _ -> fail "corrupt file content" From mark at simplycompute.co.uk Thu May 8 08:59:06 2008 From: mark at simplycompute.co.uk (Mark Wallsgrove) Date: Thu May 8 08:53:12 2008 Subject: [Haskell-cafe] IO Help In-Reply-To: References: <4822F5F6.30000@simplycompute.co.uk> Message-ID: <4822F91A.4000601@simplycompute.co.uk> Thank you very much for your fast response! Ok, that is now changed, but everything else in my program is expecting Catalogue without IO. Is there a way to change IO Catalogue into Catalogue? Henning Thielemann wrote: > > On Thu, 8 May 2008, Mark Wallsgrove wrote: > >> Problem now is reading the data back into the program. When I read the >> data >> back into the program it comes as IO [Track]. This is the code I have >> been >> using to load the data: >> >> >> loadData :: String -> Catalogue >> loadData fileName = do x <- readFile fileName >> return (read x :: Catalogue) > > type should be > > loadData :: String -> IO Catalogue > > > But using plainly 'read' may not satisfy you, because the program will > abort unrecoverably if the file has corrupt content. You may want to use > 'reads' and check manually if parsing was successful: > > case reads x of > [(cat, "")] -> return cat > _ -> fail "corrupt file content" > From daniel.is.fischer at web.de Thu May 8 09:19:53 2008 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Thu May 8 09:12:09 2008 Subject: [Haskell-cafe] IO Help In-Reply-To: <4822F91A.4000601@simplycompute.co.uk> References: <4822F5F6.30000@simplycompute.co.uk> <4822F91A.4000601@simplycompute.co.uk> Message-ID: <200805081519.54019.daniel.is.fischer@web.de> Am Donnerstag, 8. Mai 2008 14:59 schrieb Mark Wallsgrove: > Thank you very much for your fast response! > > Ok, that is now changed, but everything else in my program is expecting > Catalogue without IO. Is there a way to change IO Catalogue into Catalogue? > Not a recommendable way. But there's no need to, your programme will probably look like main = do args <- getArgs let realArgs = parseArgs args catalogue <- loadData doSomething realArgs catalogue and doSomething might e.g. construct an updated catalogue and write it to a file. From u4538637 at anu.edu.au Thu May 8 09:36:02 2008 From: u4538637 at anu.edu.au (u4538637@anu.edu.au) Date: Thu May 8 09:30:05 2008 Subject: [Haskell-cafe] (no subject) Message-ID: Hi I have a bit of a?dilemma.I have a list of lists, eg, [[1,2,3],[4,5,6],[7,8,9]]. Imagine they represent a grid with 0-2 on the x axis and 0-2 on the y axis, eg, (0,0) is 1, (1,0) is 2, (2,1) is 6, etc and (2,3) is 9. I want to be able to put in the list of lists, and the (x,y) coordinate, and return the value.? Also, I need to be able to replace a value in the list. Eg, if I wanted to replace (2,3) with 100, then the output of the expression would be [[1,2,3],[4,5,6],[7,8,100]]. Any help would be great! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080508/0a56c717/attachment.htm From scook0 at gmail.com Thu May 8 09:46:03 2008 From: scook0 at gmail.com (Stuart Cook) Date: Thu May 8 09:40:05 2008 Subject: [Haskell-cafe] IO Help In-Reply-To: <4822F91A.4000601@simplycompute.co.uk> References: <4822F5F6.30000@simplycompute.co.uk> <4822F91A.4000601@simplycompute.co.uk> Message-ID: <49b351060805080646g3b400f17mfbeb0e7b89e09a2e@mail.gmail.com> On Thu, May 8, 2008 at 10:59 PM, Mark Wallsgrove wrote: > Thank you very much for your fast response! > > Ok, that is now changed, but everything else in my program is expecting > Catalogue without IO. Is there a way to change IO Catalogue into Catalogue? Suppose I have a function "readFile" of type String -> IO String, and a function "read" of type String -> Catalogue. How can I feed the output of the first function into the second function, when that pesky "IO" is in my way? Perhaps I would write something that looks like this: loadData :: String -> IO Catalogue loadData fileName = do x <- readFile fileName return (read x :: Catalogue) Even though the expression "readFile fileName" has type IO String, the variable "x" bound on the third line has type String. This means that I can pass it into "read" without any problems. Eventually you'll learn about things like (>>=) and "liftM", which can be used to write this in a simpler form, but hopefully this will get you going for now. Stuart From sebastian.sylvan at gmail.com Thu May 8 09:55:25 2008 From: sebastian.sylvan at gmail.com (Sebastian Sylvan) Date: Thu May 8 09:49:29 2008 Subject: [Haskell-cafe] Random numbers / monads - beginner question In-Reply-To: <17124380.post@talk.nabble.com> References: <17124380.post@talk.nabble.com> Message-ID: <3d96ac180805080655q5e8f5a77n62cf12656a2d97bd@mail.gmail.com> 2008/5/8 Madoc : > Hello, > > I am just learning Haskell. Now, I encountered something that I cannot > solve by myself. Your advice will be greatly appreciated. > > Given a list of numbers, I want to modify each of those numbers by adding a > random offset. However, each such modified number shall stay within certain > bounds, given by the integers minValue and maxValue. After that, I want to > continue computation with the resulting list of type [Int]. But for > demonstration, I made a program that just prints out the list: > > import IO; import Random > > minValue = 0::Int > maxValue = 1000::Int > > normalize a | a < minValue = minValue > | a > maxValue = maxValue > | otherwise = a > > modify a = do > offset <- randomRIO(-100::Int, 100) > return(normalize(a + offset)) > > main = putStrLn $ show $ map (modify) [0, 200, 400, 600, 800, 1000] > > This program will not compile. GHC complains: > > test.hs:14:18: > No instance for (Show (IO Int)) > arising from a use of `show' at test.hs:14:18-21 > Possible fix: add an instance declaration for (Show (IO Int)) > In the first argument of `($)', namely `show' > In the second argument of `($)', namely > `show $ map (modify) [0, 200, 400, 600, ....]' > In the expression: > putStrLn $ show $ map (modify) [0, 200, 400, 600, ....] > > I understand that the result of the modify function is not an Int, as I > would like to have it, but instead IO Int, and that cannot be applied to > show. (I also did not quite understand why I need those brackets around > the return value of the modify value. It won't compile if I leave them > out, but I can accept that for now.) > > I also figured out how to generate a modified list of type [IO Int] and of > type IO [Int]. However, I could not find out how to completely get rid of > the IO monad and just get a mofied list of type [Int], which is what I > really want. > > Please, do You have any advice for me? I tried for some hours, and now I am > really angry at that IO monad that sticks to my pretty integers like glue! > > Also, any comment on the programming style and how I could achive my goals > easier would be appreciated. (I left out comments and function types for the > sake of brevity.) > You should use newStdGen to produce a random generator, then randomRs to produce a list of random numbers (without using IO!). But if you really want this version with IO interspersed through the algorithm to work, then something like this should do it (uncompiled): main = do xs <- mapM (modify) [0, 200, 400, 600, 800, 1000] putStrLn $ show $ xs The only way to "get rid of the IO monad", is to use "<-" to bind it to a value from within the IO monad. -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080508/e918498b/attachment.htm From madocdoyu at gmail.com Thu May 8 10:03:27 2008 From: madocdoyu at gmail.com (Madoc) Date: Thu May 8 09:57:29 2008 Subject: [Haskell-cafe] Thanks for the help! (Random numbers / monads - beginner question) In-Reply-To: <17124380.post@talk.nabble.com> References: <17124380.post@talk.nabble.com> Message-ID: <17125957.post@talk.nabble.com> Thanks for helping me! Your fast and accurate responses helped me to solve this issue. I am not so angry at IO any more. You showed me more than one way in which I can solve the problem. In addition, the answers to the other thread "IO Help" helped me too. It seems that Mr. Wallsgrove had a very similar question at the same time. Thanks very much, this was really great for me! -- View this message in context: http://www.nabble.com/Random-numbers---monads---beginner-question-tp17124380p17125957.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. From lemming at henning-thielemann.de Thu May 8 10:20:32 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu May 8 10:13:08 2008 Subject: [Haskell-cafe] IO Help In-Reply-To: <4822F91A.4000601@simplycompute.co.uk> References: <4822F5F6.30000@simplycompute.co.uk> <4822F91A.4000601@simplycompute.co.uk> Message-ID: On Thu, 8 May 2008, Mark Wallsgrove wrote: > Thank you very much for your fast response! > > Ok, that is now changed, but everything else in my program is expecting > Catalogue without IO. Is there a way to change IO Catalogue into Catalogue? Yes, but you do not want that. You will go on writing functions which consume Catalogue and finally you will apply a Catalogue function in the IO monad which does all the work at once. From daniel.is.fischer at web.de Thu May 8 10:21:18 2008 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Thu May 8 10:14:14 2008 Subject: [Haskell-cafe] (no subject) In-Reply-To: References: Message-ID: <200805081621.18700.daniel.is.fischer@web.de> Am Donnerstag, 8. Mai 2008 15:36 schrieb u4538637@anu.edu.au: > Hi I have a bit of a dilemma.I have a list of lists, eg, > [[1,2,3],[4,5,6],[7,8,9]]. Imagine they represent a grid with 0-2 on the x > axis and 0-2 on the y axis, eg, (0,0) is 1, (1,0) is 2, (2,1) is 6, etc and > (2,3) is 9. I want to be able to put in the list of lists, and the (x,y) > coordinate, and return the value. > > Also, I need to be able to replace a value in the list. Eg, if I wanted to > replace (2,3) with 100, then the output of the expression would be > [[1,2,3],[4,5,6],[7,8,100]]. > > Any help would be great! To get the value at a position, look up (!!) To replace a value, you could use zipWith From barsoap at web.de Thu May 8 10:20:14 2008 From: barsoap at web.de (Achim Schneider) Date: Thu May 8 10:14:31 2008 Subject: [Haskell-cafe] List questions References: Message-ID: <20080508162014.39ffa06f@solaris> wrote: > Hi I have a bit of a?dilemma.I have a list of lists, eg, > [[1,2,3],[4,5,6],[7,8,9]]. Imagine they represent a grid with 0-2 on > the x axis and 0-2 on the y axis, eg, (0,0) is 1, (1,0) is 2, (2,1) > is 6, etc and (2,3) is 9. I want to be able to put in the list of > lists, and the (x,y) coordinate, and return the value.? > select x y ys = (ys !! y) !! x > Also, I need to be able to replace a value in the list. Eg, if I > wanted to replace (2,3) with 100, then the output of the expression > would be [[1,2,3],[4,5,6],[7,8,100]]. > you can't replace it, you can only construct a new list: Your function will likely be of the type replace :: Int -> Int -> a -> [[a]] -> [[a]] I won't give the answer here, as that would spoil all of the fun and delight you'll have while browsing through the Prelude and Data.List and see how much duct tape there's around, waiting to be used, plus I'd have to open a new file as ghci doesn't support multi-line functions. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. From lemming at henning-thielemann.de Thu May 8 10:27:06 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu May 8 10:19:41 2008 Subject: [Haskell-cafe] IO Help In-Reply-To: <4822F91A.4000601@simplycompute.co.uk> References: <4822F5F6.30000@simplycompute.co.uk> <4822F91A.4000601@simplycompute.co.uk> Message-ID: On Thu, 8 May 2008, Mark Wallsgrove wrote: > Thank you very much for your fast response! > > Ok, that is now changed, but everything else in my program is expecting > Catalogue without IO. Is there a way to change IO Catalogue into Catalogue? Btw. there was a nice article precisely about the issue "How to get rid of the IO?" in the old Hawiki. What is the progress in bringing back Hawiki? From mark at simplycompute.co.uk Thu May 8 10:31:38 2008 From: mark at simplycompute.co.uk (Mark Wallsgrove) Date: Thu May 8 10:25:45 2008 Subject: [Haskell-cafe] IO Help In-Reply-To: References: <4822F5F6.30000@simplycompute.co.uk> <4822F91A.4000601@simplycompute.co.uk> Message-ID: <48230ECA.5090308@simplycompute.co.uk> Was there? I have been google'ing that problem for ages.. Just one more thing. I have to make a menu system where the user chooses what functionality they want. Because you cannot change a value once it is set I have used recursion so that when something changes it then calls the menu back up. I feel this is way to memory consuming. Is there another way? CODE: main catalogue playlist: x = choose option passtofunction x passtofunction value: function1 1 = main (functionName value) playlist function2 2 = main catalogue (functionName value) Henning Thielemann wrote: > > On Thu, 8 May 2008, Mark Wallsgrove wrote: > >> Thank you very much for your fast response! >> >> Ok, that is now changed, but everything else in my program is >> expecting Catalogue without IO. Is there a way to change IO Catalogue >> into Catalogue? > > Btw. there was a nice article precisely about the issue "How to get rid > of the IO?" in the old Hawiki. What is the progress in bringing back > Hawiki? > > From tom.davie at gmail.com Thu May 8 10:36:38 2008 From: tom.davie at gmail.com (Thomas Davie) Date: Thu May 8 10:30:44 2008 Subject: [Haskell-cafe] IO Help In-Reply-To: <48230ECA.5090308@simplycompute.co.uk> References: <4822F5F6.30000@simplycompute.co.uk> <4822F91A.4000601@simplycompute.co.uk> <48230ECA.5090308@simplycompute.co.uk> Message-ID: <239D78D1-D6EF-4298-9242-26D3E063A63C@gmail.com> On 8 May 2008, at 16:31, Mark Wallsgrove wrote: > Was there? I have been google'ing that problem for ages.. > > Just one more thing. I have to make a menu system where the user > chooses what functionality they want. Because you cannot change a > value once it is set I have used recursion so that when something > changes it then calls the menu back up. I feel this is way to memory > consuming. Is there another way? While this method feels like it should consume lots of memory, it in fact doesn't. Remember that you're dealing with a graph machine, and that no stack is maintained of all the calls you've made. The garbage collector will simply follow you through the menu system clearing up the memory behind you. Bob From mark at simplycompute.co.uk Thu May 8 10:43:27 2008 From: mark at simplycompute.co.uk (Mark Wallsgrove) Date: Thu May 8 10:37:40 2008 Subject: [Haskell-cafe] IO Help In-Reply-To: <239D78D1-D6EF-4298-9242-26D3E063A63C@gmail.com> References: <4822F5F6.30000@simplycompute.co.uk> <4822F91A.4000601@simplycompute.co.uk> <48230ECA.5090308@simplycompute.co.uk> <239D78D1-D6EF-4298-9242-26D3E063A63C@gmail.com> Message-ID: <4823118F.1070209@simplycompute.co.uk> Thank you all for your help, you have been invaluable Thomas Davie wrote: > > On 8 May 2008, at 16:31, Mark Wallsgrove wrote: > >> Was there? I have been google'ing that problem for ages.. >> >> Just one more thing. I have to make a menu system where the user >> chooses what functionality they want. Because you cannot change a >> value once it is set I have used recursion so that when something >> changes it then calls the menu back up. I feel this is way to memory >> consuming. Is there another way? > > While this method feels like it should consume lots of memory, it in > fact doesn't. Remember that you're dealing with a graph machine, and > that no stack is maintained of all the calls you've made. The garbage > collector will simply follow you through the menu system clearing up the > memory behind you. > > Bob > From darrinth at gmail.com Thu May 8 11:24:36 2008 From: darrinth at gmail.com (Darrin Thompson) Date: Thu May 8 11:18:41 2008 Subject: [Haskell-cafe] I am new to haskell In-Reply-To: <211207.79205.qm@web30202.mail.mud.yahoo.com> References: <211207.79205.qm@web30202.mail.mud.yahoo.com> Message-ID: On Thu, May 8, 2008 at 2:59 AM, Benjamin L. Russell wrote: > * Kees Doets and Jan van Eijck: The Haskell Road to Logic, Maths and Programming, As someone approaching haskell with very rusty math skills, this book has been invaluable. My haskell skills are (mostly) beyond what the text is covering, but I'm dutifully working through the math problems as doing it (partway through chapter 4 now, yay!) has sharpened my thinking already. The end result is that I can already sort of read some of the Haskell research papers like the Fusion one. Also, Jan van Eijck is pretty responsive and untangled my mind from time to time. -- Darrin From mads_lindstroem at yahoo.dk Thu May 8 11:32:25 2008 From: mads_lindstroem at yahoo.dk (Mads =?ISO-8859-1?Q?Lindstr=F8m?=) Date: Thu May 8 11:29:40 2008 Subject: [Haskell-cafe] Using Template Haskell to make type-safe database access In-Reply-To: <0C39F272-5FC0-48A7-8831-1F2BF03F4989@Cs.Nott.AC.UK> References: <1209760319.4242.4.camel@localhost.localdomain> <1210017744.4300.30.camel@localhost.localdomain> <6A286E8D-2C96-4E77-9FA3-077702204CBE@Cs.Nott.AC.UK> <1210195445.4192.54.camel@localhost.localdomain> <0C39F272-5FC0-48A7-8831-1F2BF03F4989@Cs.Nott.AC.UK> Message-ID: <1210260745.4265.29.camel@localhost.localdomain> Hi Wouter, Wouter Swierstra wrote: > Nice! I have to admit, it's much nicer than I expected it to be. Just > out of curiousity, what happens when you write: > > selectTupleList :: Connection -> IO [Integer] > > instead of > > selectTupleList :: Connection -> IO [(Integer, String, String)] > > What kind of error message do you get? More specifically, is this > error caught statically or dynamically. The type annotation in UseSqlExpr.hs was just for the reader. The compiler can infer the types completely. Thus when I make the suggested change I get a compile time error. It looks like this: UseSqlExpr.hs:27:6: Couldn't match expected type `Integer' against inferred type `(Integer, String, String)' Expected type: IO [Integer] Inferred type: IO [(Integer, String, String)] In the expression: (return $ (map (\ [x0[a2ZY], x1[a2ZZ], x2[a300]] -> (readInteger x0[a2ZY], readString x1[a2ZZ], readString x2[a300])) rows[a2ZX])) In the expression: do rows[a2ZX] <- fetchRows dsn[a2ZW] ['S', 'E', 'L', 'E', 'C', 'T', ' ', 'u', 's', 'e', 'r', '_', 'i', 'd', ',', ' ', 'u', 's', 'e', 'r', '_', 'n', 'a', 'm', 'e', ',', ' ', 'u', 's', 'e', 'r', '_', 'r', 'e', 'a', 'l', '_', 'n', 'a', 'm', 'e', ' ', 'F', 'R', 'O', 'M', ' ', 'u', 's', 'e', 'r', ';'] (return $ (map (\ [x0[a2ZY], x1[a2ZZ], x2[a300]] -> (readInteger x0[a2ZY], readString x1[a2ZZ], readString x2[a300])) rows[a2ZX])) make: *** [all] Fejl 1 > > The only other limitation I can think of, would be in the situation > where you don't have compile-time access to the database, e.g. > developing software for a client with a database that can only be > accessed from their intranet. I have no idea how much of a limitation > that is. True, but this limitation is only relevant when you do not have access to the production database or a database with identical metadata. How often do people develop like that? How are they testing? I have a hard time picturing a setup without a test database with identical metadata to the production database. > >> Perhaps I should explain my own thoughts on the subject a bit better. > >> I got interested in this problem because I think it makes a nice > >> example of dependent types "in the real world" - you really want to > > > > But won't you end up implementing all the functionality of an SQL > > parser? While possible, it does seem like a huge job. With a TH > > solution > > you will safe a lot of work. > > Yes - but parsing the result of an SQL describe statement is pretty > easy. ok. > > > A library that > > will be a lot more complex to learn than what I am proposing (assuming > > the developer already knows SQL). > > Hmm. This is a rather sticky point. One might also argue that Haskell > developers have to learn SQL to use the solution you propose. I'm not > particularly convinced. Both approaches have their merits I think. Yes. I was _not_ making what you could call a strong argument. I was assuming that most (Haskell) developers knew SQL anyway. I have no data to back it up. Just my gut feeling. To be fair I should mention a couple of drawbacks with the TH-based approach. While SQL got static typing, it is not really as powerful as it could be. For example if you do "select sum(...) from ..." the type system will tell you that a set of values are returned. In reality this set will never have more than one member. Your proposal would be able to return a Float in stead of a [Float]. Another advantage your proposal (and disadvantage of the TH based one) would be that it can abstract over variances in different database implementation. That is, you could translate to SQL depending on SQL backend. This would be really nice. But I guess it would also be a big task. > > Anyhow - nice work! Have you asked Bjorn Bringert what he thinks? He's > a really clever and approachable guy - and he knows a lot more about > interfacing with databases than I do. > > Kind regards, > > Wouter /Mads Lindstr?m From chad.scherrer at gmail.com Thu May 8 13:34:01 2008 From: chad.scherrer at gmail.com (Chad Scherrer) Date: Thu May 8 13:28:22 2008 Subject: [Haskell-cafe] Re: Interesting critique of OCaml References: <20080508033013.GA29498@scytale.galois.com> Message-ID: Don Stewart galois.com> writes: [interesting quote...] > Which I think really captures the joy of being able to write algebraic > and data structure transformations, via rewrite rules, without having to > extend the compiler -- all thanks to purity, laziness, and static > typing. This makes me wonder... Rewrite rules are certainly effective, and seem to be a good place to point (one of many, of course) when asked why you'd want a language with Haskell's characteristics. It seems like there should be an argument to this effect: 1. You'd like be able to declare compile-time transformations like map f . map g = map (f . g) without messing with the compiler 2. For x in [purity, laziness, static typing, higher-order functions] If you don't have x, here's what goes wrong (or can go wrong) 3. Of the very few languages with these characteristics, Haskell is the most widely-used, and the most actively developed and researched. Now, I don't know much about lisp, but aren't code transformations like this the whole point of macros? What makes is difficult to do the same thing in this context? What about object-oriented languages? The problem with step 1 in the argument is that it's already cast in a functional-programming framework. Is there a way to recast it so OOP could play? Thanks, Chad PS - the link now gives a "500 server error" - did our traffic overwhelm it? Is the cafe the next slashdot? ;) From david.waern at gmail.com Thu May 8 13:46:28 2008 From: david.waern at gmail.com (David Waern) Date: Thu May 8 13:40:29 2008 Subject: [Haskell-cafe] Re: [Haskell] Re: ANN: Haddock version 2.1.0 In-Reply-To: <4822F24B.4040801@microsoft.com> References: <20080501190625.GB474@localhost> <481A46C0.3050209@gmail.com> <012e01c8ac61$cc2f0d60$bf078351@cr3lt> <4822F24B.4040801@microsoft.com> Message-ID: 2008/5/8 Simon Marlow : > So basically you want to run a lexer over the source again to collect all > the comments? Yes. > You really want to use GHC's lexer, because otherwise you > have to write another lexer. I don't mind writing a lexer that just collects the comments. It should be simpler than a full Haskell lexer, right? It wouldn't need to handle layout, for instance. Using GHC is also a good option. > So a flag to GHC's lexer that says whether it > should return comments or not seems like a reasonable way to go. But if > you're doing that, you might as well have the parser collect all the > comments off to the side during parsing, to avoid having to lex the file > twice, right? Yes. David From barsoap at web.de Thu May 8 13:48:18 2008 From: barsoap at web.de (Achim Schneider) Date: Thu May 8 13:42:27 2008 Subject: [Haskell-cafe] Re: Interesting critique of OCaml References: <20080508033013.GA29498@scytale.galois.com> Message-ID: <20080508194818.32afc64c@solaris> Chad Scherrer wrote: > Don Stewart galois.com> writes: > [Stuff where I totally agree] > > Now, I don't know much about lisp, but aren't code transformations > like this the whole point of macros? What makes is difficult to do > the same thing in this context? > Proof of correctness, or even a graspable notion of correctness for the whole semantics of the language. If you consider that hygienic macros (that is, macros that don't make a mess of every concept you have of "namespace") were introduced quite late, you might get a grasp on how bravely and hackish they were designed. > What about object-oriented languages? The problem with step 1 in the > argument is that it's already cast in a functional-programming > framework. Is there a way to recast it so OOP could play? > Yes, I suppose so, but you'll be left with Haskell with an OOP Syntax, and a style of OOP that uses Objects mainly as closures, which isn't a thing OOP coders regularly, or at all, do, to get the granularity of replacements that is necessary to consider them useful in the first run. Some years or decades ahead, perhaps Haskell will not be able to avoid being successful anymore, and that is the time where you'll see things that look like Java, feel like Java, work like Java, but still use a Haskell RTS. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. From andrewcoppin at btinternet.com Thu May 8 14:27:02 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Thu May 8 14:20:57 2008 Subject: [Haskell-cafe] Re: Interesting critique of OCaml In-Reply-To: <20080508194818.32afc64c@solaris> References: <20080508033013.GA29498@scytale.galois.com> <20080508194818.32afc64c@solaris> Message-ID: <482345F6.1060402@btinternet.com> Achim Schneider wrote: > Some years or decades ahead, perhaps Haskell will not be able to avoid > being successful anymore, and that is the time where you'll see things > that look like Java, feel like Java, work like Java, but still use a > Haskell RTS. > I'm told they're calling it F#... [No, I can't verify the truth of that claim. But every time I mention Haskell, everybody goes "Haskell is obsolete. Everybody who even *wants* functional programming in the first place will just use F# instead. The end."] From andrewcoppin at btinternet.com Thu May 8 14:27:42 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Thu May 8 14:21:36 2008 Subject: [Haskell-cafe] Re: Interesting critique of OCaml In-Reply-To: References: <20080508033013.GA29498@scytale.galois.com> Message-ID: <4823461E.1080103@btinternet.com> Chad Scherrer wrote: > PS - the link now gives a "500 server error" - did our traffic overwhelm it? Is > the cafe the next slashdot? ;) > Hell, I can't even get a TCP SYN-ACK packet out of it... :-/ From westondan at imageworks.com Thu May 8 14:52:50 2008 From: westondan at imageworks.com (Dan Weston) Date: Thu May 8 14:47:29 2008 Subject: [Haskell-cafe] Random numbers / monads - beginner question In-Reply-To: References: <17124380.post@talk.nabble.com> Message-ID: <48234C02.3060600@imageworks.com> Henning Thielemann wrote: > > On Thu, 8 May 2008, Madoc wrote: > >> minValue = 0::Int >> maxValue = 1000::Int >> >> normalize a | a < minValue = minValue >> | a > maxValue = maxValue >> | otherwise = a > > > normalize' = min maxValue . max minValue There is a curiosity here. The functions normalize and normalize' are extensionally equal only because minValue <= maxValue, but intensionally different. The intensional equivalent is to reverse order of composition: normalize'' = max minValue . min maxValue which remains equal to to normalize whatever the values of minValue and maxValue. That the order of composition (or of guarded expressions) matters conditionally base on its parameters is reason enough for the original poster to decide what the "right answer" should be if maxValue < minValue. These corner cases are often where future bugs lie dormant. My choice would be: normalize''' = max trueMin . min trueMax where trueMin = min minValue maxValue trueMax = max minValue maxValue Now the function makes no assumptions about external values. This is no less efficient than before, since trueMin and trueMax are CAFs evaluated only once. From donnie at darthik.com Thu May 8 14:59:17 2008 From: donnie at darthik.com (Donnie Jones) Date: Thu May 8 14:53:19 2008 Subject: [Haskell-cafe] Re: Interesting critique of OCaml In-Reply-To: <4823461E.1080103@btinternet.com> References: <20080508033013.GA29498@scytale.galois.com> <4823461E.1080103@btinternet.com> Message-ID: Hello, I pasted a copy of the article below for those that cannot access the site. I would be interested to see an article on Haskell in the same light as this Ocaml article, aka a constructive criticism of Haskell. Enjoy! __ Donnie ### Begin Article ### Why Ocaml Sucks Published by Brian at 6:49 pm under Functional Languages: Ocaml, Haskell One of the ways to not fall into the blub fallacy is to regularly consider those ways in which your favorite language is inferior, and could be improved- preferrably radically improved. Now, it should come as a surprise to no one that my favorite language is (currently) Ocaml. So as an intellectual exercise I want to list at least some of the ways that Ocaml falls short as a language. I will note that if you use this post as a reason to *not* use Ocaml, you are a fool and are missing the point of this post. With the *possible*exception of Haskell, no other language I know of comes close to getting all the things right that Ocaml gets right. So, with that in mind, let's begin. 1. Lack of Parallelism In case you haven't guessed it from reading this blog, I think parallelism is going to be the big problem for the next decade. And while Ocaml does have threads, it also has a big ol' global interpreter lock, so that only one thread can be executing Ocaml code at a time. Which severely limits the utility of threads, and severely limits the ability of Ocaml programmers to take advantage of multiple cores. Now, to give the INRIA team credit, the reason they have for this is a good one- we (programmers) still don't know for sure how to write multithreaded code safely (I have my suspicions, but I have no proof), and we had even less of an idea a decade and a half ago when the fundamentals of Ocaml were being decided. And supporting multithreaded code slows down the garbage collector. And, a decade and a half ago, multithreaded code was a lot less important, and multicore systems were rare and expensive. So this is mainly just Ocaml showing it's age. But still, if I were to pick the biggest shortcomming of Ocaml, this would be it. 2. Printf You know what? Printf was a bad idea for C- having this special domain-specific language in what looks like strings to control formatting. It's even worse in Ocaml, where you have to add special kludges to the compiler to support it (at least the way Ocaml did it- there are smarter ways that don't require compiler kludges). You might think that "%3d" is a string in Ocaml, and sometimes you'd be right. But sometimes it's a (int -> '_a, '_b, '_c, '_a) format4. This horrid type (which is *not* a string) is necessary to encode the types of the arguments printf needs to be passed it. The one thing I know of that C++ did better than Ocaml was ditching printf. And the idea of iostreams even isn't that bad- except for the fact that they encouraged generations of C++ programmers to abuse operator overloading (hint to Bjarne Stroustrup: << and >> are not the I/O operators, they're the bit shift operators!), and they made the iostream classes exceptionally difficult to inherit from or extend. But a combination of C++ style iostream operators and Java style iostream classes would have worked so much better, and not required hacking the compiler. An even better idea might be some variant of functional unparsing . 3. Lack of multi-file modules Ocaml has an exceptionally powerfull and flexible module and functor system, which stops rather annoyingly at the file level. Files are modules, and files (and modules) can contain other modules within them, but you can't collect several files into one big multi-file module. You especially can't say that certain files, while they may be visible to other modules within the multi-file module, aren't visible outside the multi-file module. This is especially useful if you want to factor out common base functionality from a library of modules into a shared module, but not productize it for export to the outside world. This limits the ability of the programmers to correctly structure large projects. The -for-pack arguments help fix a lot of this, sorta- but they require smarts in the build system and generally special .mli files to control visibility. It can be done, but it's not clean- it makes the build process a lot more complex, and important information about which files are externally visible or not is contained somewhere that is not in the source code. This could certainly be done a hell of a lot better than it is. 4. Mutable data Mutable data is both a blessing and a curse. It is a blessing when learning the language, especially when you're coming from conventional imperative programming languages. Rather than having to learn what a lazy real time catenable dequeue is, and why you want one, you can just bang out a quick mutable doubly linked list and get the same behavior. I would argue that if you're coming from the imperative/OO world, it's easier to learn Ocaml than Haskell for precisely this reason. But this implies that mutable data is training wheels of a sort. And, like the fact that training wheels prevent you from going fast, mutable data prevents Ocaml from doing a lot of interesting and useful things. Many of Haskell's most interesting features- such as STM, easy multithreading, and deforrestation, and scrap your boilerplate, arise out of Haskell being purely applicative. Mutable data is holding Ocaml back. 5. Strings This is more of a minor nit, but the representation of strings as a (compact) array of chars is stupid. It made sense of pointer-arithmetic C, not so much for Ocaml. The definition of chars as 8 bits prevents the internationalization of Ocaml beyond the European languages, and the representation is inefficient. The most important operations on strings are either iterating over all the characters in a string, or concatenating two strings. Random access and mutation is rare, *unless* you're using the string as a bit or byte array, which is encouraged by the nature of strings. Bit arrays should be first class types of themselves, with specialized internal representations, allowing strings to be optimized as strings. An unbalanced tree based structure would allow O(1) (and exceptionally fast) string concatenation while preserving the O(N) cost to iterate over all characters in a string. Also, strings are currently mutable data, and as described above, mutable data is teh sucketh. This is doubly so for strings, which can be profitably interned (and thus should be). 6. Shift-reduce conflicts Shift-reduce conflicts happen in parser generators, especially LALR(1) parser generators like yacc and ocamlyacc, where there are situations where the parser doesn't know if the current expression is complete, or can still go on. The golden example of this is the "dangling else" problem of C and other languages, where you might see code like this: if (test1) then if (test2) then expr1 else expr2 The problem is that the parser, after it has finished parsing expr1expression and looking at the else, doesn't know wether to shift it (making the else and expr2 part of the inner if) or reduce it (making the else part of the outer if). I strongly recommend everyone who is developing a language to write the initial syntax in a LALR(1) parser, and eliminate all shift-reduce (and especially reduce-reduce) conflicts while you still can, because every shift-reduce conflict is a bug waiting to happen. In the above example, based on indenting, it is very likely to be meant to be part of the outer if, but the parser is going to bind it to the wrong if, causing a bug. This is slightly less bad in Ocaml, where generally the bug will be a type error, but that doesn't mean it's good. And Ocaml has literally dozens of these suckers lying in wait to bite and unwary programmer. Even I get bitten by shift-reduce conflict generated bugs on a regular basis. A quick side digression for those who started yelling that the indentation should be significant to the compiler. Consider the output that would be caused by printing the following 3 C/Ocaml strings: "\n \tx\n", "\n \t x\n", and "\n\t x\n". Each one starts with a newline, ends with an x and a newline, and contains exactly two spaces and a tab in between. Now, what columns do the three x's end up in? The answer is "it depends upon which editor you're using to view the output with, and what configuration that editor has". I just spent a large chunk of this afternoon cleaning up a bunch of code written by a programmer who merrily mixed spaces and tabs, and used a different editor than I do. As a consequence, what looked neatly formatted to him looked like gibberish to me. And if two humans can't agree on whether a particular piece of code is well formatted or not, what hope does the computer have to figure out the situation? The solution is to eliminate the root cause of the problem (the shift-reduce conflicts), not add a new way to introduce subtle and hard to debug errors. 7. Not_found One of the worst design decisions Ocaml has to have made is Not_found- this is the exception that's thrown whenever something isn't found. Tha'ts helpfull, isn't it? It's thrown by the Set and Map modules (and all their functor applications) the List module, various other data structure libraries, various regular expression libraries, and, as a rule, just about any random peice of code. And it contains absolutely no information as to what is not found, or what was being looked for. Or even what was doing the looking. At least Failure and Invalid_argument at least take a string argument, which is generally is the name the function that failed. So if you see the exception Invalid_argument("hd"), you know at least to be looking at calls to List.hd (or to other functions named "hd"). But Not_found? This is the sound of your hd hitting the desk, repeatedly. 8. Exceptions And while I'm ragging on Not_found, let me rag on exceptions a bit. Exceptions are used way too commonly in Ocaml- OK, I'll give Failure, Invalid_argument, and Assertion_failure a pass, but basically Not_found and End_of_file should never, *ever*, be thrown. Return 'a option instead. This has non-trivial implications. For example, take the classic newbie ocaml "mistake"- write a function that reads in a file and returns the file as a list of strings, one string per line. Should be easy. We use input_line as to read a line, and write our code like: let read_file desc = let rec loop accum = try let line = input desc in loop (line :: accum) with | End_of_file -> List.rev accum in loop [] ;; And they can't understand why this code blows up when they try to read a file with more than 30,000 lines in it. There are standard solutions to this- but they make the code uglier, and by far the best is to wrap the exception throwing code in an expression that turns the exception into an option, like: let read_file desc = let rec loop accum = let line = try Some(input desc) with | End_of_file -> None in match line with | Some s -> loop (s :: accum) | None -> List.rev accum in loop [] ;; At which point you really have to raise the question of why input_string didn't just return string_option from the get-go. The other popular alternative is to use mutable data. Which is just trading off one problem set for another. There is, by the way, an interesting idea for expetion handling that's been raised recently (see hereand here ). The basic idea is that the current Ocaml syntax for declaring an exception handler is: try expr1 with | Exception -> expr2 where if expr1 doesn't throw an exception, the value of the hole expression is the value returned by expr1- otherwise, if it throws Exception, then the whole expression has the value expr2. This syntax is replaced by: try var = expr1 in expr2 with | Exception -> expr3 Here, if expr1 does not throw an exception, then the value of the whole expression is that of expr2 with variable var having the value of expr1, while if it throws Exception, then the value of the whole expression is then expr3. Note that exceptions are only caught in expr1- it's just that if an exception is caught, then expr2 is skipped as well. But this means that calls from within expr2 can be tail calls. Let's take a look at our read_file program, the newbie way, a third time, this time with our new exception syntax: let read_file desc = let rec loop accum = try line = input_line desc in loop (line :: accum) with | End_of_file -> List.rev accum in loop [] ;; Since the tail call to loop is outside where we catch exceptions, it's a true tail call, and the function works "as expected". And the fact that we're using exceptions instead of options isn't that big of a deal anymore (Not_found still sucks, due to it's simple ubiquity and taciturnity). If someone with more time and/or camlp4 knowledge than I have wants to write this up as an extension, I'd be eternally gratefull. While I'm at it, would it be possible to have exceptions in the type system? I know Java tried this and everyone hated it, but Ocaml has two things that Java didn't- type inference and type variables. The type variables are nice because they allow you to deal with "unknown" exceptions- for example you could have a function of type (int -> int throws 'a) -> int throws 'a, meaning that you don't know (or care) what exceptions the passed-in funciton might throw, but that you throw the same exceptions (presumably by calling the passed-in function). Type inference also means you don't have to declare most of these cases, the compiler can infer what exceptions are thrown. This level of changes to the type system are highly unlikely, but a boy can dream, can't he? 9. Deforrestation This really should be under the "mutable data is the sucketh" section, but oh well. Haskell has introduced a very interesting and (to my knowledge) unique layer of optimization, called deforrestation. Basically, what happens if that the ghc compiler recognizes and can optimize certain common sub-optimal data structure transformations. For example, it can convert map f (map g lst) into map (f . g) lst, where the peroid (.) is the function composition operator. There are a couple of obvious advantages to being able to do this- for example, by doing so we've eliminated an intermediate data structure, and created new opportunities for optimizing the combined f and g functions. But there are two things of serious interest to me about this. First of all, this is the first time I've seen optimizations at this level being this easily performed. Companies like Intel and IBM have thrown literally man-millenia at this problem, and the solutions they've come up with were limited and fragile (slight changes to the code would enable or disable the optimization). And yet the Haskell people implemented in one Simon Peyton Jones long weekend (also known as a couple of man months for mere mortals like you and I). The reason for this is that the real difficult is not actually implementing the transformation, or even detecting that the transformation might be applicable, it's proving that the transformation is correct, that the code after the transformation is applied behaves identically to the code before the transformation is applied. In langauges with mutable data, like Fortran and C++ (and Ocaml), this is decidedly non-trivial. In Haskell, you can dash off the proof that it's always correct on the back of a cocktail napkin- proving that it's correct in the general case for all lists and all functions. And that thus the compiler doesn't even need to check- once it detects that the pattern can be applied, it can just go ahead and apply it. Haskell is doing data structure level optimizations with the ease that most other compiler do peephole instruction optimization. This is a non-trivial result. The second important aspect of this is that it changes the concept of what optimization is, or should be. I forget which paper it was I was reading that said that optimization should really be called depessimization. That the programmer wants to introduce pessimizations- the programmer could do the above deforrestation himself, except that to do so would make maintainance more difficult, as it'd break module boundaries, or requires knowledge of how a particular module is implemented, or simply requires knowledge of widely seperated peices of code. The goal of the compiler, rather than striving to produce some "optimal" (and thus impossible to obtain) implementation, but simple to undo the pessimizations that the programmer has introduced in the name of maintainablity, modularity, readability, and/or simplicity. The programmer shouldn't have to worry about creating intermediate data structures, and should worry about corrupting his code in the name of performance- that's the compilers job (don't break your code, let the computer do that for you! :-). Needless to say, between the mutable data, the side effects, and the handling of exceptions, Ocaml isn't going get deforrestation any time soon. 10. Limited standard library If writing monad tutorials is the cottage industry of Haskell programmers, than rewriting the standard library is Ocaml's cottage industry. You almost can't call yourself an Ocaml programmer if you haven't rewritten a goodly chunk of the standard library at least once. This is because every Ocaml programmer has a long list of functions that should (they think) be in the standard library but just aren't. The big ones for me are the lack of Int and Float modules ready for use by the Set and Map functors, the lack of an already-instantiated Map and Set modules for Strings, Ints, and Floats, and the lack of a list to set/map function. None of these are exactly hard to do, just annoying to have to constantly redo. Of course, the problem with this is the range and design patterns of Ocaml programmers- especially with comparison to languages like Java and C++, or even Ruby. The design patterns of a top-5% Java programmer is not all that different from the design philosophy of a bottom-30%'er. There may be differences in precisely what features are supported, and what names things are given may change, but the broad stroke designs will be similiar. The design patterns of Brian Hurt circa 2008 are radically different than the design patterns of Brian Hurt circa 2003. For example, were I to redo extlib now, it's be purely applicative, heavily functorized, lots of monads, and a fair bit of lazy evaluation, as opposed to the code I wrote in 2003. 11. Slow lazy Speaking of lazy evaluation- Ocaml's built-in lazy evaluation is wicked slow. I've actually timed it, and it's like 130+ clock cycles of overhead to force a lazy value the first time, and over 70 clock cycles of overhead to force it the second and subsequent times (when all it has to do is return the cached value). Given that most of the good uses of lazy evaluation has it wrapping computations that are like 10 clock cycles long or so, the overhead of the lazy thunk dominates. In this era of Ruby programmers, this may not seem like much- but this overhead discourages Ocaml programmers from using lazy evaluation. Which is a shame, as anyone who has read Okasaki knows how frimping usefull it is. Well, that's my list so far- subject to revision without notice. The vast majority of them qualify as picking nits- and they are. If you can damn with faint praise, then you should also be able to praise with faint damning- and this certainly qualifies as that. Most of the problems here only became apparent (or their solutions became apparent) long after Ocaml was mature and set. For example, it's only be recently that multi-threading has been a big deal. And the usefullness of monads and lazy evaluation for functional programming weren't understood until the late nineties/early 21st, a decade after Ocaml's formative years. So this whole post mostly amounts to whining that the Ocaml developers weren't *even more insightfull and foresightfull*than they were. And, compared to the major revisions Ocaml's "age-mates" Java and Perl have gone through, it's stood up well with the passing of time. No lanuage is perfect, including Ocaml. And to continue to improve we must understand what has gone before- both what worked, and what didn't. Popularity: 6% [? ] ### End Article ### On Thu, May 8, 2008 at 2:27 PM, Andrew Coppin wrote: > Chad Scherrer wrote: > >> PS - the link now gives a "500 server error" - did our traffic overwhelm >> it? Is >> the cafe the next slashdot? ;) >> >> > > Hell, I can't even get a TCP SYN-ACK packet out of it... :-/ > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080508/b50b6f50/attachment.htm From icfp.publicity at googlemail.com Thu May 8 15:01:54 2008 From: icfp.publicity at googlemail.com (Matthew Fluet (ICFP Publicity Chair)) Date: Thu May 8 14:55:58 2008 Subject: [Haskell-cafe] Workshop on Generic Programming: Call for Papers (co-located w/ ICFP08) Message-ID: <53ff55480805081201t7e8e557fo11d29e9abc14c432@mail.gmail.com> CALL FOR PAPERS Workshop on Generic Programming 2008 Victoria, Canada, 20th September 2008 http://www.comlab.ox.ac.uk/ralf.hinze/wgp2008/cfp.{html,pdf,ps,txt} The Workshop on Generic Programming is sponsored by ACM SIGPLAN and forms part of ICFP 2008. Previous Workshops on Generic Programming have been held in Marstrand (affiliated with MPC), Ponte de Lima (affiliated with MPC), Nottingham (informal workshop), Dagstuhl (IFIP WG2.1 Working Conference), Oxford (informal workshop), Utrecht (informal workshop), and Portland (affiliated with ICFP). Scope ----- Generic programming is about making programs more adaptable by making them more general. Generic programs often embody non-traditional kinds of polymorphism; ordinary programs are obtained from them by suitably instantiating their parameters. In contrast with normal programs, the parameters of a generic program are often quite rich in structure; for example they may be other programs, types or type constructors, class hierarchies, or even programming paradigms. Generic programming techniques have always been of interest, both to practitioners and to theoreticians, but only recently have generic programming techniques become a specific focus of research in the functional and object-oriented programming language communities. This workshop will bring together leading researchers in generic programming from around the world, and feature papers capturing the state of the art in this important emerging area. We welcome contributions on all aspects, theoretical as well as practical, of o adaptive object-oriented programming, o aspect-oriented programming, o component-based programming, o generic programming, o meta-programming, o polytypic programming, o programming with modules, and so on. Submission details ------------------ Deadline for submission: 30th June 2008 Notification of acceptance: 14th July 2008 Final submission due: 28th July 2008 Workshop: 20th September 2008 Authors should submit papers, in PostScript or PDF format, formatted for A4 paper, to Ralf Hinze (ralf.hinze@comlab.ox.ac.uk) or Don Syme (Don.Syme@microsoft.com) by 30th June 2008. The length should be restricted to 12 pages in standard (two-column, 9pt) ACM. Accepted papers are published by the ACM and will additionally appear in the ACM digital library. Programme committee ------------------- Ralf Hinze (co-chair) University of Oxford Patrik Jansson Chalmers University Andrew Lumsdaine Indiana University Conor McBride University of Nottingham Adriaan Moors Universiteit Leuven Fritz Ruehr Willamette University Tim Sheard Portland State University Don Syme (co-chair) Microsoft Research Todd Veldhuizen University of Waterloo From andrewcoppin at btinternet.com Thu May 8 15:20:31 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Thu May 8 15:14:28 2008 Subject: [Haskell-cafe] The Monad.Reader (11) - Call for Copy In-Reply-To: References: <4821FB57.3010808@btinternet.com> Message-ID: <4823527F.40608@btinternet.com> Wouter Swierstra wrote: > > On 7 May 2008, at 19:56, Andrew Coppin wrote: > >> Wouter Swierstra wrote: >>> Please consider writing something for the next issue of The >>> Monad.Reader. >> >> You know, I'm actually tempted to do just that... > > Please do! We've had lots of excellent articles written by people who > were just learning Haskell. Sometimes a beginner's perspective can be > quite refreshing. Feel free to contact me personally if you have any > questions. Without reading through every issue ever published, do you have any specific examples of this that I [or anybody else in cafe] could take a look at? From bulat.ziganshin at gmail.com Thu May 8 15:23:53 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu May 8 15:19:30 2008 Subject: [Haskell] [Haskell-cafe] Help with polymorphic functions In-Reply-To: References: Message-ID: <543108430.20080508232353@gmail.com> Hello Wei, Thursday, May 8, 2008, 11:10:08 PM, you wrote: > test :: a -> Int -> a > shift is defined as "a -> Int -> a" not exactly ;) this type signature is given inside class Bits, where 'a' isn't a free variable (as in standalone signature declaration), but means 'a' from type class header: class Num a => Bits a where shift :: a -> Int -> a so, this declaration is equivalent to the following standalone one: shift :: (Bits a) => a -> Int -> a from the common sense POV, you can't shift *ANY* type 'a', but only types that belong to the Bits class. so, shift cannot have signature w/o class, and the same remains true for `test` -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From tux_rocker at reinier.de Thu May 8 15:32:24 2008 From: tux_rocker at reinier.de (Reinier Lamers) Date: Thu May 8 15:26:40 2008 Subject: [Haskell] [Haskell-cafe] Help with polymorphic functions In-Reply-To: References: Message-ID: <200805082132.24666.tux_rocker@reinier.de> Op Thursday 08 May 2008 21:10:08 schreef Wei Yuan Cai: > shift is defined as "a -> Int -> a" It's not. It's defined as "(Bits a) => a -> Int -> a" or something along those lines. So there is a restriction that the type a must be a member of the Bits typeclass. Because "test" is essentially just "shift", its type must also be "(Bits a) => a -> Int -> a". Reinier From bjorn.buckwalter at gmail.com Thu May 8 15:48:06 2008 From: bjorn.buckwalter at gmail.com (Bjorn Buckwalter) Date: Thu May 8 15:42:20 2008 Subject: [Haskell-cafe] Re: I am new to haskell References: Message-ID: Ambrish Bhargava gmail.com> writes: > Hi All,I am new to Haskell. Can anyone guide me how can I start on it (Like getting binaries, some tutorials)?Thanks in advance.-- Regards,Ambrish Bhargava Ambrish, When I started learning Haskell I had no previous exposure to functional programming. The sources I found most useful were Hal Daume III's "Yet Another Haskell Tutorial" and Eric Etheridge's "Haskell Tutorial for C Programmers", both linked to from the tutorials wiki page: http://www.haskell.org/haskellwiki/Tutorials I found the "Gentle Introduction..." mentioned elsewhere in this thread to be not-so-gentle as described on the tutorials wiki page. I'd avoid it unless you're already comfortable with functional programming. Good luck! -Bjorn From bjorn.buckwalter at gmail.com Thu May 8 15:51:20 2008 From: bjorn.buckwalter at gmail.com (Bjorn Buckwalter) Date: Thu May 8 15:49:10 2008 Subject: [Haskell-cafe] Re: I am new to haskell References: Message-ID: Bjorn Buckwalter gmail.com> writes: > I found the "Gentle Introduction..." mentioned elsewhere in this thread to be > not-so-gentle as described on the tutorials wiki page. I'd avoid it unless > you're already comfortable with functional programming. Let me modify that statement. I'd avoid it until you've made your way through one or two of the other tutorials, and then give it a good reading. It's an excellent "introduction", only not for beginners. ;) -Bjorn From mblazevic at stilo.com Thu May 8 16:34:32 2008 From: mblazevic at stilo.com (Mario Blazevic) Date: Thu May 8 16:28:39 2008 Subject: [Haskell-cafe] A Cabal problem In-Reply-To: <1210104342.30059.366.camel@localhost> References: <481F123B.4060303@stilo.com> <20080505101032.22e04edc@trogdor> <481F45C8.1070702@stilo.com> <20080505104020.3e5d40bb@trogdor> <4820607B.4090002@stilo.com> <1210104342.30059.366.camel@localhost> Message-ID: <482363D8.2090809@stilo.com> Duncan Coutts wrote: > On Tue, 2008-05-06 at 09:43 -0400, Mario Blazevic wrote: >> Trevor Elliott wrote: > >>> Cabal doesn't pass the --main-is option, I believe because it is >>> specific to GHC. What you could do is add this flag in the ghc-options >>> field of your executable in the cabal file, like this: >>> >>> ghc-options: --main-is Shell >> That worked like charm, except the two dashes should be one (my >> mistake). Thank you. > > Note that hackage will reject packages that use "ghc-options: -main-is" > with the message that it is not portable. The rationale is that unlike > other non-portable extensions, it is easy to change to make it portable: > http://hackage.haskell.org/trac/hackage/ticket/179 > If you want to argue for supporting this ghc extension and/or implement > support (possibly with workaround support for the other haskell > implementations) then please do comment on the above ticket. > > Duncan > After some experimentation, I've changed my opinion and now agree with the current behaviour. I had the impression that every Haskell module had to reside in a same-named file. While this appears to be true for *imported* modules and GHC (hence my mistaken impression), the Haskell 98 standard does not specify anything of the sort. In case of the top-level module, GHC (as well as the standard) allows it to reside in a file of any name. So the only reasonable use for -main-is option, as I see it, is to allow multiple small main modules residing in the same file, and I guess that's not likely to be encountered in a package. From wss at cs.nott.ac.uk Thu May 8 16:43:44 2008 From: wss at cs.nott.ac.uk (Wouter Swierstra) Date: Thu May 8 16:37:52 2008 Subject: [Haskell-cafe] The Monad.Reader (11) - Call for Copy In-Reply-To: <4823527F.40608@btinternet.com> References: <4821FB57.3010808@btinternet.com> <4823527F.40608@btinternet.com> Message-ID: > Without reading through every issue ever published, do you have any > specific examples of this that I [or anybody else in cafe] could > take a look at? The following two articles spring to mind: * Kenneth Hoste wrote a gtk2hs tutorial, after having just started using it: http://www.haskell.org/sitewiki/images/9/9d/TMR-Issue1.pdf * Graham Klyne wrote some notes on learning Haskell: http://www.haskell.org/tmrwiki/LearningHaskellNotes Best, Wouter From darrinth at gmail.com Thu May 8 16:54:56 2008 From: darrinth at gmail.com (Darrin Thompson) Date: Thu May 8 16:49:00 2008 Subject: [Haskell-cafe] Re: Interesting critique of OCaml In-Reply-To: References: <20080508033013.GA29498@scytale.galois.com> <4823461E.1080103@btinternet.com> Message-ID: 2008/5/8 Donnie Jones : > I would be interested to see an article on Haskell in the same light as this > Ocaml article, aka a constructive criticism of Haskell. > http://www.drmaciver.com/2008/02/tell-us-why-your-language-sucks/ -- Darrin From dons at galois.com Thu May 8 16:59:55 2008 From: dons at galois.com (Don Stewart) Date: Thu May 8 16:54:12 2008 Subject: [Haskell-cafe] The Monad.Reader (11) - Call for Copy In-Reply-To: <4823527F.40608@btinternet.com> References: <4821FB57.3010808@btinternet.com> <4823527F.40608@btinternet.com> Message-ID: <20080508205955.GB3528@scytale.galois.com> andrewcoppin: > Wouter Swierstra wrote: > > > >On 7 May 2008, at 19:56, Andrew Coppin wrote: > > > >>Wouter Swierstra wrote: > >>>Please consider writing something for the next issue of The > >>>Monad.Reader. > >> > >>You know, I'm actually tempted to do just that... > > > >Please do! We've had lots of excellent articles written by people who > >were just learning Haskell. Sometimes a beginner's perspective can be > >quite refreshing. Feel free to contact me personally if you have any > >questions. > > Without reading through every issue ever published, do you have any > specific examples of this that I [or anybody else in cafe] could take a > look at? You should read through every issue ever published though -- there's a lot of interesting lessons in TMR for the practical Haskeller. -- Don From andrewcoppin at btinternet.com Thu May 8 17:07:08 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Thu May 8 17:01:03 2008 Subject: [Haskell-cafe] The Monad.Reader (11) - Call for Copy In-Reply-To: <20080508205955.GB3528@scytale.galois.com> References: <4821FB57.3010808@btinternet.com> <4823527F.40608@btinternet.com> <20080508205955.GB3528@scytale.galois.com> Message-ID: <48236B7C.4000908@btinternet.com> Don Stewart wrote: > You should read through every issue ever published though -- there's a > lot of interesting lessons in TMR for the practical Haskeller. > That would be entertaining sometime, but how many issues have ac... oh, wait... this is issue 11? Hmm, I hadn't realised that this publication was this new. I was thinking there were several hundred prior issues to wade through or something! :-. From donnie at darthik.com Thu May 8 17:31:31 2008 From: donnie at darthik.com (Donnie Jones) Date: Thu May 8 17:25:32 2008 Subject: [Haskell-cafe] The Monad.Reader (11) - Call for Copy In-Reply-To: <48236B7C.4000908@btinternet.com> References: <4821FB57.3010808@btinternet.com> <4823527F.40608@btinternet.com> <20080508205955.GB3528@scytale.galois.com> <48236B7C.4000908@btinternet.com> Message-ID: Speaking of old Monad.Reader issues... the wiki says, "Issues 2 through 5 can be found on the special tmrwiki ? they haven't been included here for licensing reasons. I hope to move over most of the content soon." Any chance of those issues being moved over still? I'd prefer to read the older issues in pdf format, like the new issues. Thank you! __ Donnie Jones On Thu, May 8, 2008 at 5:07 PM, Andrew Coppin wrote: > Don Stewart wrote: > >> You should read through every issue ever published though -- there's a >> lot of interesting lessons in TMR for the practical Haskeller. >> >> > > That would be entertaining sometime, but how many issues have ac... oh, > wait... this is issue 11? Hmm, I hadn't realised that this publication was > this new. I was thinking there were several hundred prior issues to wade > through or something! :-. > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080508/8680b75b/attachment.htm From prstanley at ntlworld.com Thu May 8 18:04:40 2008 From: prstanley at ntlworld.com (PR Stanley) Date: Thu May 8 17:58:26 2008 Subject: [Haskell-cafe] Induction (help!) In-Reply-To: <22fcbd520805080429r6ad6d962x508aca235283c52a@mail.gmail.co m> References: <7.0.1.0.0.20080506095651.01d0edb8@ntlworld.com> <7ca3f0160805060756j42408484s85f82513a983febb@mail.gmail.com> <7.0.1.0.0.20080506223340.01dc88a0@ntlworld.com> <200805070051.25953.daniel.is.fischer@web.de> <2f9b2d30805061721g2185f976r9b783457cb2eb9bf@mail.gmail.com> <48210620.3080300@imageworks.com> <7.0.1.0.0.20080507222730.01d86ec0@ntlworld.com> <7ca3f0160805071443k254fa5d1n340b4d81e0c171b0@mail.gmail.com> <7.0.1.0.0.20080508010106.01d9cd40@ntlworld.com> <22fcbd520805080429r6ad6d962x508aca235283c52a@mail.gmail.com> Message-ID: <7.0.1.0.0.20080508230352.01d21c10@ntlworld.com> You've got the right idea. Paul: At long last! :-) I should point out that it doesn't make sense to say p(Succ n) = Succ(p(n)), p(x) represents some statement that is either true or false, so it doesn't make sense to say Succ(p(n)). . Paul: okay, da capo: We prove/test through case analysis that the predicate p holds true for the first/starting case/element in the sequence. When dealing with natural numbers this could be 0 or 1. We try the formula with 0 and if it returns the desired result we move onto the next stage. If the formula doesn't work with 0 and so the predicate does not hold true for the base case then we've proved that it's a nonstarter. In the inductive step we'll make a couple of assumptions: we'll imagine that p(j). We'll also assume that p holds true for the successor of j - p(j+1). Then with the help of rules and the protocol available to us we'll try to establish whether the formula (f) gives us f(j) = f(j+1) - f(1) So, we know that the predicate holds for 0 or at least one element. By the way, could we have 3 or 4 or any element other than 0? Anyway, p(0). Then we set out to find out if p holds for the successor of 0 followed by the successor of the successor of 0 and so forth. However, rather than laboriously applying p to every natural number we innstead try to find out if f(j+1) - f(1) will take us back to fj). I think this was the bit I wasn't getting. The assumptions in the inductive step and the algebraic procedures are not to prove the formula or premise per se. That's sort of been done with the base case. Rather, they help us to illustrate that f remains consistent while allowing for any random element to be succeeded or broken down a successive step at a time until we reach the base/starting element/value. Okay so far? Cheers Paul From mail at philip.in-aachen.net Thu May 8 18:17:41 2008 From: mail at philip.in-aachen.net (=?ISO-8859-15?Q?Philip_M=FCller?=) Date: Thu May 8 18:12:06 2008 Subject: [Haskell-cafe] Newbie Question: Using Haskell Functions in a C Program Message-ID: <48237C05.6000708@philip.in-aachen.net> Hi, I'm in the process of writing a C program, but I can't stop thinking about how some functions would be much nicer implemented in Haskell. Is there a way to write some of the functions in Haskell and then use them in my C code via some kind of interface? BTW yes, I have been thinking about writing the whole program in Haskell, but I just don't have the level of experience in Haskell programming for that, since it's really heavy on IO. Thanks in advance for the answers! Regards Philip From daniel.is.fischer at web.de Thu May 8 18:27:07 2008 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Thu May 8 18:19:24 2008 Subject: [Haskell-cafe] Induction (help!) In-Reply-To: <7.0.1.0.0.20080508230352.01d21c10@ntlworld.com> References: <7.0.1.0.0.20080506095651.01d0edb8@ntlworld.com> <22fcbd520805080429r6ad6d962x508aca235283c52a@mail.gmail.com> <7.0.1.0.0.20080508230352.01d21c10@ntlworld.com> Message-ID: <200805090027.07579.daniel.is.fischer@web.de> Am Freitag, 9. Mai 2008 00:04 schrieb PR Stanley: > You've got the right idea. > Paul: At long last! :-) > I should point out that it doesn't make sense to say p(Succ n) = > Succ(p(n)), p(x) represents some statement that is either true or > false, so it doesn't make sense to say Succ(p(n)). . > Paul: okay, da capo: We prove/test through case analysis > that the predicate p holds true for the first/starting case/element > in the sequence. When dealing with natural numbers this could be 0 or > 1. We try the formula with 0 and if it returns the desired result we > move onto the next stage. If the formula doesn't work with 0 and so > the predicate does not hold true for the base case then we've proved > that it's a nonstarter. Well, it might hold for all n >= 3. But you're right, if p doesn't hold for the base case, then it doesn't hold for _all_ cases. > > In the inductive step we'll make a couple of assumptions: we'll > imagine that p(j). We'll also assume that p holds true for the > successor of j - p(j+1). No. In the induction step, we prove that IF p(j) holds, THEN p(j+1) holds, too. p(j) is the assumption, and we prove that *given that assumption*, p(j+1) follows. Then we have proved (*) p(j) implies p(j+1), for all j. If we already have established the base case, p(0), we have p(0) and (p(0) implies p(1)) - the latter is a special case of (*) - from that follows p(1). Then we have p(1) and (p(1) implies p(2), again a special case of (*), therefore p(2). Now we have p(2) and (p(2) implies p(3)), hence p(3) and so on. > Then with the help of rules and the protocol available to us we'll > try to establish whether the formula (f) gives us f(j) = f(j+1) - f(1) > So, we know that the predicate holds for 0 or at least one element. > By the way, could we have 3 or 4 or any element other than 0? Sure, anything. Start with proving p(1073) and the induction proves p(n) for all n >= 1073, it does not say anything about n <= 1072. > Anyway, > p(0). Then we set out to find out if p holds for the successor of 0 > followed by the successor of the successor of 0 and so forth. > However, rather than laboriously applying p to every natural number > we innstead try to find out if f(j+1) - f(1) will take us back to > fj). I think this was the bit I wasn't getting. The assumptions in > the inductive step and the algebraic procedures are not to prove the > formula or premise per se. That's sort of been done with the base > case. Rather, they help us to illustrate that f remains consistent > while allowing for any random element to be succeeded or broken down > a successive step at a time until we reach the base/starting element/value. > Okay so far? Not quite, but close. > > Cheers > Paul > From barsoap at web.de Thu May 8 18:28:00 2008 From: barsoap at web.de (Achim Schneider) Date: Thu May 8 18:22:11 2008 Subject: [Haskell-cafe] Re: Newbie Question: Using Haskell Functions in a C Program References: <48237C05.6000708@philip.in-aachen.net> Message-ID: <20080509002800.72fea4f4@solaris> Philip M?ller wrote: > Is there a way to write some of the functions in Haskell and then use > them in my C code via some kind of interface? > The beast you are looking for is called the FFI: Foreign Function Interface. C doesn't make IO any easier, though. More verbose and low-level, I would say. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. From devriese at cs.tcd.ie Thu May 8 18:29:17 2008 From: devriese at cs.tcd.ie (Edsko de Vries) Date: Thu May 8 18:23:20 2008 Subject: [Haskell-cafe] Stack vs Heap allocation Message-ID: <20080508222917.GA22916@netsoc.tcd.ie> Hi, How can I know whether something will be stack or heap allocated? For example, in the standard example of why foldl (+) 0 will fail to evaluate a long list of integers due to a stack overflow, but foldl' won't, it is pointed out that foldl starts building up unevaluated thunks. So, apparently, these thunks are allocated on the stack rather than on the heap with a pointer to the thunk on the stack. (I understand that foldl' is asymptotically better than foldl space-wise; that is irrelevant to my question.) On the other hand, in this version that sums all the values in a tree data Tree = Leaf Int | Node Tree Tree sum :: Tree -> Int sum t = sum' [t] 0 where sum' [] acc = acc sum' (Leaf i : ts) acc = sum' ts $! (i + acc) sum' (Node l r : ts) acc = sum' (l : r : ts) acc we are building up a (potentially) large lists of trees yet to be processed, but never run out of stack space. Apparently, the list is built up on the heap rather than on the stack. What is the fundamental difference between these two examples? Why is the list of trees yet to be processed allocated on the heap (with a pointer on the stack, presumably) but the unevaluated thunks in the foldl example allocated on the stack? Thanks, Edsko From bulat.ziganshin at gmail.com Thu May 8 18:29:40 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu May 8 18:24:47 2008 Subject: [Haskell-cafe] Newbie Question: Using Haskell Functions in a C Program In-Reply-To: <48237C05.6000708@philip.in-aachen.net> References: <48237C05.6000708@philip.in-aachen.net> Message-ID: <707316768.20080509022940@gmail.com> Hello Philip, Friday, May 9, 2008, 2:17:41 AM, you wrote: > Is there a way to write some of the functions in Haskell and then use > them in my C code via some kind of interface? http://haskell.org/haskellwiki/IO_inside#Interfacing_with_foreign_evil_.28under_development.29 and then entries 1,6,7 in http://haskell.org/haskellwiki/IO_inside#Further_reading -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From dons at galois.com Thu May 8 18:33:16 2008 From: dons at galois.com (Don Stewart) Date: Thu May 8 18:27:17 2008 Subject: [Haskell-cafe] Newbie Question: Using Haskell Functions in a C Program In-Reply-To: <48237C05.6000708@philip.in-aachen.net> References: <48237C05.6000708@philip.in-aachen.net> Message-ID: <20080508223316.GE3528@scytale.galois.com> mail: > Is there a way to write some of the functions in Haskell and then use > them in my C code via some kind of interface? Using C just for IO is a bit weird -- perhaps you could illustrate the kind of IO you're doing? Learning how to do IO in Haskell is a much safer solution that linking the Haskell runtime into your C program. That said, this is done by using 'foreign export' declarations in your Haskell code, then linking the compiled Haskell objects into your C code, as follows: We define the fibonacci function in Haskell: {-# LANGUAGE ForeignFunctionInterface #-} module Safe where import Foreign.C.Types fibonacci :: Int -> Int fibonacci n = fibs !! n where fibs = 0 : 1 : zipWith (+) fibs (tail fibs) fibonacci_hs :: CInt -> CInt fibonacci_hs = fromIntegral . fibonacci . fromIntegral foreign export ccall fibonacci_hs :: CInt -> CInt And call it from C: #include "A_stub.h" #include int main(int argc, char *argv[]) { int i; hs_init(&argc, &argv); i = fibonacci_hs(42); printf("Fibonacci: %d\n", i); hs_exit(); return 0; } Now, first compile the Haskell file: $ ghc -c -O A.hs Which creates some *.c and *.h headers, which you import into your C program. Now compile your C code with ghc (!), passing the Haskell objects on the command line: $ ghc -optc-O test.c A.o A_stub.o -o test How run your C code: $ ./test Fibonacci: 267914296 And that's it. -- Don P.S. Its easier to learn how to do IO in Haskell :) From derek.a.elkins at gmail.com Thu May 8 18:54:33 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Thu May 8 18:48:37 2008 Subject: [Haskell-cafe] Stack vs Heap allocation In-Reply-To: <20080508222917.GA22916@netsoc.tcd.ie> References: <20080508222917.GA22916@netsoc.tcd.ie> Message-ID: <1210287273.5514.46.camel@derek-laptop> On Thu, 2008-05-08 at 23:29 +0100, Edsko de Vries wrote: > Hi, > > How can I know whether something will be stack or heap allocated? For > example, in the standard example of why > > foldl (+) 0 > > will fail to evaluate a long list of integers due to a stack overflow, > but foldl' won't, it is pointed out that foldl starts building up > unevaluated thunks. So, apparently, these thunks are allocated on the > stack rather than on the heap with a pointer to the thunk on the stack. > (I understand that foldl' is asymptotically better than foldl > space-wise; that is irrelevant to my question.) > > On the other hand, in this version that sums all the values in a tree > > data Tree = Leaf Int | Node Tree Tree > > sum :: Tree -> Int > sum t = sum' [t] 0 > where > sum' [] acc = acc > sum' (Leaf i : ts) acc = sum' ts $! (i + acc) > sum' (Node l r : ts) acc = sum' (l : r : ts) acc > > we are building up a (potentially) large lists of trees yet to be > processed, but never run out of stack space. Apparently, the list is > built up on the heap rather than on the stack. > > What is the fundamental difference between these two examples? Why is > the list of trees yet to be processed allocated on the heap (with a > pointer on the stack, presumably) but the unevaluated thunks in the > foldl example allocated on the stack? No, the thunks are (usually) stored on the heap. You don't get the stack overflow until you actually force the computation at which point you have an expression like: (...(((1+2)+3)+4) ... + 10000000) which requires stack in proportion to the number of nested parentheses (effectively) From mail at philip.in-aachen.net Thu May 8 19:09:33 2008 From: mail at philip.in-aachen.net (=?ISO-8859-15?Q?Philip_M=FCller?=) Date: Thu May 8 19:03:29 2008 Subject: [Haskell-cafe] Newbie Question: Using Haskell Functions in a C Program In-Reply-To: <48237C05.6000708@philip.in-aachen.net> References: <48237C05.6000708@philip.in-aachen.net> Message-ID: <4823882D.2070804@philip.in-aachen.net> Thanks for all the answers. I'm testing this right now and simples cases work as expected. However from what I've read it seems it'll get ugly once I try to pass a C array to a Haskell function. Well, maybe arrays in C have been ugly before trying to pass them to Haskell functions ;) To elaborate a bit about the C program, it's a small game using OpenGL for output and mouse and keyboard for input. I just don't know how to do that in Haskell - my knowledge is quite basic in nature ;) Regards Philip From ryani.spam at gmail.com Thu May 8 19:11:08 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Thu May 8 19:05:09 2008 Subject: [Haskell-cafe] Induction (help!) In-Reply-To: <200805090027.07579.daniel.is.fischer@web.de> References: <7.0.1.0.0.20080506095651.01d0edb8@ntlworld.com> <22fcbd520805080429r6ad6d962x508aca235283c52a@mail.gmail.com> <7.0.1.0.0.20080508230352.01d21c10@ntlworld.com> <200805090027.07579.daniel.is.fischer@web.de> Message-ID: <2f9b2d30805081611y573e4d3cv8af6629b32db1f45@mail.gmail.com> On 5/8/08, Daniel Fischer wrote: > No. In the induction step, we prove that > IF p(j) holds, THEN p(j+1) holds, too. > p(j) is the assumption, and we prove that *given that assumption*, p(j+1) > follows. > Then we have proved > (*) p(j) implies p(j+1), for all j. To formalize this, you can work in a system of logic with the following rules: Variable introduction: x is not free in L, L |- t is a type proves L, x :: t |- x :: t --- this is a proof of "x has type t" Forall introduction (removing the above assumption) L, x :: t |- p proves L |- forall x :: t. p Assumption of a proposition: L, p |- p --- no pre-requisites Impication introduction ("Deduction"; if P then Q) L, p |- q proves L |- p => q The part to the left of the |- is an "environment"; it represents assumptions you have made up to this point. The part to the right is a statement which is "true" in that environment; the L just represents "any environment". For example, in the first rule, we say that if we know that t is a type, and we haven't assumed anything about x yet, we can assume that x is a member of that type. Then in the second rule, if we've proved some proposition "p" once we've assumed that x is something of type t, we can say that p holds for -all- x of type t; we didn't assume anything about that x besides its type. Induction corresponds to adding the following rule to the logic: L |- p(0) L |- forall x :: Nat, p(x) => p(x+1) proves L |- forall x :: Nat, p(x) A "true" statement is one that holds with no environment: |- p Now, if you are proving something by induction, you had to prove that second line; and the only way to do so is by making some assumptions. A skeleton of a proof: axiom |- Nat is a type variable introduction x :: Nat |- x :: Nat proposition introduction x :: Nat, p(x) |- p(x) ... some proof using p(x) here ... x :: Nat, p(x) |- p(x+1) deduction x :: Nat |- p(x) => p(x+1) forall introduction |- forall x :: Nat, p(x) => p(x+1) ... some proof of p(0) here ... |- p(0) induction |- forall x :: Nat, p(x) Every proof by induction looks basically like this; you just need to fill in the "... some proof here..." parts. -- ryan From dons at galois.com Thu May 8 19:12:15 2008 From: dons at galois.com (Don Stewart) Date: Thu May 8 19:06:17 2008 Subject: [Haskell-cafe] Newbie Question: Using Haskell Functions in a C Program In-Reply-To: <4823882D.2070804@philip.in-aachen.net> References: <48237C05.6000708@philip.in-aachen.net> <4823882D.2070804@philip.in-aachen.net> Message-ID: <20080508231215.GF3528@scytale.galois.com> mail: > Thanks for all the answers. I'm testing this right now and simples > cases work as expected. However from what I've read it seems it'll > get ugly once I try to pass a C array to a Haskell function. Right, passing arrays back and forth is going to get tiring. > Well, maybe arrays in C have been ugly before trying to pass them to > Haskell functions ;) > > To elaborate a bit about the C program, it's a small game using > OpenGL for output and mouse and keyboard for input. > I just don't know how to do that in Haskell - my knowledge is quite > basic in nature ;) Oh, then you'll want to use the Haskell OpenGL bindings. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/OpenGL There's a few OpenGL-based games in Haskell, here: http://haskell.org/haskellwiki/Applications_and_libraries/Games and a section of blog articles on using the OpenGL bindings: http://haskell.org/haskellwiki/Blog_articles/Graphics#OpenGL -- Don From trebla at vex.net Thu May 8 19:13:08 2008 From: trebla at vex.net (Albert Y. C. Lai) Date: Thu May 8 19:07:09 2008 Subject: [Haskell-cafe] Stack vs Heap allocation In-Reply-To: <20080508222917.GA22916@netsoc.tcd.ie> References: <20080508222917.GA22916@netsoc.tcd.ie> Message-ID: <48238904.1020801@vex.net> Edsko de Vries wrote: > sum :: Tree -> Int > sum t = sum' [t] 0 > where > sum' [] acc = acc > sum' (Leaf i : ts) acc = sum' ts $! (i + acc) > sum' (Node l r : ts) acc = sum' (l : r : ts) acc Because of $!, you should compare the Leaf case to foldl', not foldl. The Node case can be said to mimic a stack using heap resource. From bulat.ziganshin at gmail.com Thu May 8 19:21:08 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu May 8 19:16:08 2008 Subject: [Haskell-cafe] Newbie Question: Using Haskell Functions in a C Program In-Reply-To: <4823882D.2070804@philip.in-aachen.net> References: <48237C05.6000708@philip.in-aachen.net> <4823882D.2070804@philip.in-aachen.net> Message-ID: <1904139457.20080509032108@gmail.com> Hello Philip, Friday, May 9, 2008, 3:09:33 AM, you wrote: > Thanks for all the answers. I'm testing this right now and simples cases > work as expected. However from what I've read it seems it'll get ugly > once I try to pass a C array to a Haskell function. http://haskell.org/haskellwiki/Modern_array_libraries read about foreign arrays -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From timd at macquarie.com.au Thu May 8 22:04:53 2008 From: timd at macquarie.com.au (Tim Docker) Date: Thu May 8 21:58:55 2008 Subject: [Haskell-cafe] Interesting critique of OCaml In-Reply-To: <20080508033013.GA29498@scytale.galois.com> References: <20080508033013.GA29498@scytale.galois.com> Message-ID: <9A015D433594EA478964C5B34AF3179B76BA7B@ntsydexm06.pc.internal.macquarie.com> | An interesting critique of OCaml. | | http://enfranchisedmind.com/blog/2008/05/07/why-ocaml-sucks/ Interesting to me is that my pet ocaml peeve is not there: namely the lack of convenient operator overloading. Admittedly I only used ocaml for 6 months, but I never adapted to needing to write (+) for ints, and (.+) for floats. >From the F# documentation it would appear that F# does have overloaded numerical operators, at least. I'm not sure how these fit into its type system however. (Their type is documented as "overloaded"). Tim From mvanier at cs.caltech.edu Thu May 8 22:06:32 2008 From: mvanier at cs.caltech.edu (Michael Vanier) Date: Thu May 8 22:00:36 2008 Subject: [Haskell-cafe] Interesting critique of OCaml In-Reply-To: <9A015D433594EA478964C5B34AF3179B76BA7B@ntsydexm06.pc.internal.macquarie.com> References: <20080508033013.GA29498@scytale.galois.com> <9A015D433594EA478964C5B34AF3179B76BA7B@ntsydexm06.pc.internal.macquarie.com> Message-ID: <4823B1A8.6030708@cs.caltech.edu> Actually, it's (+) for ints and (+.) for floats. Which kind of proves your point. Mike Tim Docker wrote: > | An interesting critique of OCaml. > | > | http://enfranchisedmind.com/blog/2008/05/07/why-ocaml-sucks/ > > Interesting to me is that my pet ocaml peeve is not there: namely the > lack of convenient operator overloading. Admittedly I only used ocaml > for 6 months, but I never adapted to needing to write (+) for ints, and > (.+) for floats. > >>From the F# documentation it would appear that F# does have overloaded > numerical operators, at least. I'm not sure how these fit into its type > system however. (Their type is documented as "overloaded"). > > Tim > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From vigalchin at gmail.com Fri May 9 02:04:18 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Fri May 9 01:58:29 2008 Subject: [Haskell-cafe] "resource exhausted" Message-ID: <5ae4f2ba0805082304y2ce4f464j8de6457c75333c7d@mail.gmail.com> Hello, I am running some monadic code that I have written. I double checked my code and it seems to be ok (no guarantee though). I am getting a "resource exhausted (Message too long)". I just did a google on "resource exhausted" and saw a few posts on the number of open files which is obviously not my case. Any ideas? Kind regards, Vasili -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080509/712c1c49/attachment.htm From giorgio_v at mac.com Fri May 9 02:40:47 2008 From: giorgio_v at mac.com (Giorgio Valoti) Date: Fri May 9 02:35:28 2008 Subject: [Haskell-cafe] I am new to haskell In-Reply-To: <211207.79205.qm@web30202.mail.mud.yahoo.com> References: <211207.79205.qm@web30202.mail.mud.yahoo.com> Message-ID: <651B5C2C-A92D-4401-BEEB-83D0B4C5156D@mac.com> On 08/mag/08, at 08:59, Benjamin L. Russell wrote: > One hint that is not (at least to my knowledge) listed on > haskell.org is that, according to at least one user (see "The > Programmers? Stone ? Blog Archive ? A First Haskell Experience" at > http://the-programmers-stone.com/2008/03/04/a-first-haskell- > experience/), the online tutorials can "confuse more than they > illuminate." > > Personally, I would recommend starting with one of the available > books (see "Books - HaskellWiki" at http://haskell.org/haskellwiki/ > Books), instead. In particular, I would recommend one of the > following titles: > [?] What?s your opinion on Programming in Haskell by Graham Hutton. It is the first book about Haskell that I?ve read and wondering what could be the next one. Should I wait for Real world Haskell or do you think that the books you listed offer something new/different/more advanced than Programming in Haskell? Thank you in advance -- Giorgio Valoti From wss at Cs.Nott.AC.UK Fri May 9 02:51:47 2008 From: wss at Cs.Nott.AC.UK (Wouter Swierstra) Date: Fri May 9 02:45:47 2008 Subject: [Haskell-cafe] The Monad.Reader (11) - Call for Copy In-Reply-To: References: <4821FB57.3010808@btinternet.com> <4823527F.40608@btinternet.com> <20080508205955.GB3528@scytale.galois.com> <48236B7C.4000908@btinternet.com> Message-ID: Hi Donnie, > Any chance of those issues being moved over still? I'd prefer to > read the older issues in pdf format, like the new issues. I have gotten permission from (almost) all the authors to move the content to the new wiki. I've started reformatting everything to the MediaWiki format - for example: http://www.haskell.org/haskellwiki/The_Monad.Reader/Issue2 Unfortunately, progress is pretty slow. The automated tools to convert between MoinMoin and MediaWiki are pretty crummy; reformatting by hand is a fair amount of boring work; I'm writing up my thesis at the moment, so it's not very high on my list of things to do, I'm afraid. If you, or anyone else, would like to help out it would be much appreciated! It's just too much work for me to do by myself. All the best, Wouter From vigalchin at gmail.com Fri May 9 03:03:25 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Fri May 9 02:57:28 2008 Subject: [Haskell-cafe] Re: "resource exhausted" In-Reply-To: <5ae4f2ba0805082304y2ce4f464j8de6457c75333c7d@mail.gmail.com> References: <5ae4f2ba0805082304y2ce4f464j8de6457c75333c7d@mail.gmail.com> Message-ID: <5ae4f2ba0805090003v530c9a37yc1849bf9e8433ce8@mail.gmail.com> More importantly I grepped(Linux) through the ghc6.8.2 source for "resource exhausted" .. maybe incorrectly ?? Vasili On Fri, May 9, 2008 at 1:04 AM, Galchin, Vasili wrote: > Hello, > > I am running some monadic code that I have written. I double checked my > code and it seems to be ok (no guarantee though). I am getting a "resource > exhausted (Message too long)". I just did a google on "resource exhausted" > and saw a few posts on the number of open files which is obviously not my > case. Any ideas? > > Kind regards, Vasili > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080509/3700a1ab/attachment.htm From voigt at tcs.inf.tu-dresden.de Fri May 9 03:26:40 2008 From: voigt at tcs.inf.tu-dresden.de (Janis Voigtlaender) Date: Fri May 9 03:18:43 2008 Subject: [Haskell-cafe] REMINDER: Haskell Communities and Activities Report Message-ID: <4823FCB0.2000508@tcs.inf.tu-dresden.de> Dear Haskellers, It is not yet too late to contribute to the 14th edition of the HC&A Report. The deadline is this weekend, Saturday, 10 May 2008. If you haven't already, please write an entry for your new project or update your old entry. Please mail your entries to in plain text or LaTeX format. More information can be found in the original Call for Contributions at http://www.haskell.org/pipermail/haskell/2008-April/020378.html We look forward to receiving your contributions. Thanks a lot, Andres and Janis. -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:voigt@tcs.inf.tu-dresden.de From bulat.ziganshin at gmail.com Fri May 9 03:25:18 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Fri May 9 03:20:34 2008 Subject: [Haskell-cafe] I am new to haskell In-Reply-To: <651B5C2C-A92D-4401-BEEB-83D0B4C5156D@mac.com> References: <211207.79205.qm@web30202.mail.mud.yahoo.com> <651B5C2C-A92D-4401-BEEB-83D0B4C5156D@mac.com> Message-ID: <1379550089.20080509112518@gmail.com> Hello Giorgio, Friday, May 9, 2008, 10:40:47 AM, you wrote: > be the next one. Should I wait for Real world Haskell or do you think > that the books you listed offer something new/different/more advanced > than Programming in Haskell? i recommend you to read papers from the http://haskell.org/haskellwiki/Learning_Haskell page, in particular those in Advanced tutorials, Monads, Type classes, Popular libraries sections -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From simonmarhaskell at gmail.com Fri May 9 05:16:11 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Fri May 9 05:10:16 2008 Subject: [Haskell-cafe] Re: [Haskell] Re: ANN: Haddock version 2.1.0 In-Reply-To: References: <20080501190625.GB474@localhost> <481A46C0.3050209@gmail.com> <012e01c8ac61$cc2f0d60$bf078351@cr3lt> <4822F24B.4040801@microsoft.com> Message-ID: <4824165B.60800@gmail.com> David Waern wrote: > 2008/5/8 Simon Marlow : >> So basically you want to run a lexer over the source again to collect all >> the comments? > > Yes. > >> You really want to use GHC's lexer, because otherwise you >> have to write another lexer. > > I don't mind writing a lexer that just collects the comments. It > should be simpler than a full Haskell lexer, right? It wouldn't need > to handle layout, for instance. Using GHC is also a good option. I'm not sure it's that much easier to write a lexer that just collects comments. For example, is there a comment here? 3#--foo with -XMagicHash it is (3# followed by a comment), but without -XMagicHash it is not (3 followed by the operator #--). You have to implement a significant chunk of the options that GHC supports to get it right. I'd say its probably easier to work with GHC's lexer. Cheers, Simon From devriese at cs.tcd.ie Fri May 9 05:58:12 2008 From: devriese at cs.tcd.ie (Edsko de Vries) Date: Fri May 9 05:52:12 2008 Subject: [Haskell-cafe] Stack vs Heap allocation In-Reply-To: <1210287273.5514.46.camel@derek-laptop> References: <20080508222917.GA22916@netsoc.tcd.ie> <1210287273.5514.46.camel@derek-laptop> Message-ID: <20080509095812.GA2907@netsoc.tcd.ie> Hi, > No, the thunks are (usually) stored on the heap. You don't get the > stack overflow until you actually force the computation at which point > you have an expression like: > (...(((1+2)+3)+4) ... + 10000000) > which requires stack in proportion to the number of nested parentheses > (effectively) Ah, that makes! So does it make sense to talk about "tail recursive thunks"? Or does the evaluation of thunks always take stack space proportional to the "nesting level"? Edsko From Malcolm.Wallace at cs.york.ac.uk Fri May 9 06:04:12 2008 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Fri May 9 06:00:07 2008 Subject: [Haskell-cafe] Stack vs Heap allocation In-Reply-To: <20080509095812.GA2907@netsoc.tcd.ie> References: <20080508222917.GA22916@netsoc.tcd.ie> <1210287273.5514.46.camel@derek-laptop> <20080509095812.GA2907@netsoc.tcd.ie> Message-ID: <20080509110412.262fee0f.Malcolm.Wallace@cs.york.ac.uk> Edsko de Vries wrote: > > (...(((1+2)+3)+4) ... + 10000000) > > which requires stack in proportion to the number of nested parentheses > > Ah, that makes! So does it make sense to talk about "tail recursive > thunks"? Or does the evaluation of thunks always take stack space > proportional to the "nesting level"? The key reason why nested additions take stack space, is because (+) on Integers is *strict* in both arguments. If it were somehow non-strict instead, then the unevaluated parts of the number would be heap-allocated rather than stack-allocated. Regards, Malcolm From david.waern at gmail.com Fri May 9 07:26:48 2008 From: david.waern at gmail.com (David Waern) Date: Fri May 9 07:20:46 2008 Subject: [Haskell-cafe] Re: [Haskell] Re: ANN: Haddock version 2.1.0 In-Reply-To: <4824165B.60800@gmail.com> References: <20080501190625.GB474@localhost> <481A46C0.3050209@gmail.com> <012e01c8ac61$cc2f0d60$bf078351@cr3lt> <4822F24B.4040801@microsoft.com> <4824165B.60800@gmail.com> Message-ID: 2008/5/9 Simon Marlow : > David Waern wrote: >> >> 2008/5/8 Simon Marlow : >>> >>> So basically you want to run a lexer over the source again to collect all >>> the comments? >> >> Yes. >> >>> You really want to use GHC's lexer, because otherwise you >>> have to write another lexer. >> >> I don't mind writing a lexer that just collects the comments. It >> should be simpler than a full Haskell lexer, right? It wouldn't need >> to handle layout, for instance. Using GHC is also a good option. > > I'm not sure it's that much easier to write a lexer that just collects > comments. For example, is there a comment here? > > 3#--foo > > with -XMagicHash it is (3# followed by a comment), but without -XMagicHash > it is not (3 followed by the operator #--). You have to implement a > significant chunk of the options that GHC supports to get it right. I'd say > its probably easier to work with GHC's lexer. Ah, I didn't think about the GHC options that change the lexical syntax. You're right, using the GHC lexer should be easier. David From prstanley at ntlworld.com Fri May 9 07:50:56 2008 From: prstanley at ntlworld.com (PR Stanley) Date: Fri May 9 07:44:56 2008 Subject: [Haskell-cafe] Induction (help!) In-Reply-To: <200805090027.07579.daniel.is.fischer@web.de> References: <7.0.1.0.0.20080506095651.01d0edb8@ntlworld.com> <22fcbd520805080429r6ad6d962x508aca235283c52a@mail.gmail.com> <7.0.1.0.0.20080508230352.01d21c10@ntlworld.com> <200805090027.07579.daniel.is.fischer@web.de> Message-ID: <7.0.1.0.0.20080509125022.01d1bea8@ntlworld.com> Paul: okay, da capo: We prove/test through case analysis > that the predicate p holds true for the first/starting case/element > in the sequence. When dealing with natural numbers this could be 0 or > 1. We try the formula with 0 and if it returns the desired result we > move onto the next stage. If the formula doesn't work with 0 and so > the predicate does not hold true for the base case then we've proved > that it's a nonstarter. Well, it might hold for all n >= 3. But you're right, if p doesn't hold for the base case, then it doesn't hold for _all_ cases. Paul: I don't understand the point you're contending. We've chosen 0 as our base case and if p(0) doesn't hold then nothing else will for our proof. Granted, you may want to start from 3 or 4 as your base case but we're not doing that here and for all we know forall n >= 3 p(n) but this isn't relevant to our proof, surely. > Paul: In the inductive step we'll make a couple of assumptions: we'll > imagine that p(j). We'll also assume that p holds true for the > successor of j - p(j+1). Daniel: No. In the induction step, we prove that IF p(j) holds, THEN p(j+1) holds, too. p(j) is the assumption, and we prove that *given that assumption*, p(j+1) follows. Then we have proved (*) p(j) implies p(j+1), for all j. Paul: No, you haven't proved anything! I'm sorry but your assertion fails to make much sense. Daniel: If we already have established the base case, p(0), we have p(0) and (p(0) implies p(1)) - the latter is a special case of (*) - from that follows p(1). Then we have p(1) and (p(1) implies p(2), again a special case of (*), therefore p(2). Now we have p(2) and (p(2) implies p(3)), hence p(3) and so on. Paul: Then with the help of rules and the protocol available to us we'll > try to establish whether the formula (f) gives us f(j) = f(j+1) - f(1) > So, we know that the predicate holds for 0 or at least one element. > By the way, could we have 3 or 4 or any element other than 0? Daniel: Sure, anything. Start with proving p(1073) and the induction proves p(n) for all n >= 1073, it does not say anything about n <= 1072. Paul: p(0). Then we set out to find out if p holds for the successor of 0 > followed by the successor of the successor of 0 and so forth. > However, rather than laboriously applying p to every natural number > we innstead try to find out if f(j+1) - f(1) will take us back to > fj). I think this was the bit I wasn't getting. The assumptions in > the inductive step and the algebraic procedures are not to prove the > formula or premise per se. That's sort of been done with the base > case. Rather, they help us to illustrate that f remains consistent > while allowing for any random element to be succeeded or broken down > a successive step at a time until we reach the base/starting element/value. > Okay so far? Cheers, Paul From dekudekuplex at yahoo.com Fri May 9 07:59:31 2008 From: dekudekuplex at yahoo.com (Benjamin L. Russell) Date: Fri May 9 07:53:30 2008 Subject: [Haskell-cafe] I am new to haskell In-Reply-To: <1379550089.20080509112518@gmail.com> Message-ID: <775358.40764.qm@web30205.mail.mud.yahoo.com> --- On Fri, 5/9/08, Bulat Ziganshin wrote: > Hello Giorgio, > > Friday, May 9, 2008, 10:40:47 AM, you wrote: > > > be the next one. Should I wait for Real world Haskell > or do you think > > that the books you listed offer something > new/different/more advanced > > than Programming in Haskell? > > i recommend you to read papers from the > http://haskell.org/haskellwiki/Learning_Haskell > page, in particular those in Advanced tutorials, Monads, > Type classes, > Popular libraries sections That is one idea. Also, since The Haskell School of Expression (http://www.haskell.org/soe/), by Paul Hudak, is sometimes regarded as easier to read as a second book on Haskell, you could read that, too. A more interesting suggestion, depending on your interests, is to find a specific interesting paper and do follow-up reading to understand that paper's topic better. For example, a few months ago, I was reading a paper, "A History of Haskell: Being Lazy With Class" (http://research.microsoft.com/~simonpj/papers/history-of-haskell/history.pdf), by Paul Hudak, John Hughes, Simon Peyton Jones, and Philip Wadler. While reading this paper, I encountered multiple references to a "Hindley-Milner type system," which apparently formed the basis for Haskell's type system, and wanted to learn more about this. A reference in the bibliography of the above paper pointed to "A theory of type polymorphism in programming," by Robert Milner, which unfortunately I was unable to find online. Further investigation led to a doctoral dissertation, "A General Framework for Hindley-Milner Type Systems with Constraints" (http://citeseer.ist.psu.edu/sulzmann00general.html), by Martin Sulzmann. Being new to type theory, I had some difficulty in understanding this paper, so I sent a question by e-mail to the author. He wrote back a rather terse reply suggesting that I go read the book "Types and Programming Languages" (http://www.cis.upenn.edu/~bcpierce/tapl/) by Benjamin Pierce, adding that then I might better be able to understand his paper. Fortunately, the Wikipedia entry for "Type inference" pointed to Chapter 22 of that huge book. This dramatically reduced the amount of relevant reading. However, the book is very heavy, and was unavailable at the library when I wanted to borrow it. I plan to purchase that book in the near future. Some other suggestions for relevant papers not mentioned in "Learning Haskell - HaskellWiki" that I have found interesting are the following: * A critique of Abelson and Sussman or why calculating is better than scheming, by Philip Wadler http://www.cs.kent.ac.uk/people/staff/dat/miranda/wadler87.pdf This paper describes advantages of KRC, a predecessor to Miranda, itself a predecessor to Haskell, over LISP. * Wearing the hair shirt: a retrospective on Haskell (Microsoft PowerPoint presentation), by Simon Peyton Jones This paper describes the evolution of Haskell, and describes some advantages of Haskell over other programming languages. http://research.microsoft.com/~simonpj/papers/haskell-retrospective/HaskellRetrospective-2.pdf * Archived e-mail message by Roger Hindley explaining the history of type inference (c/o http://en.wikipedia.org/wiki/Type_inference#Hindley.E2.80.93Milner_type_inference_algorithm) http://www.cis.upenn.edu/~bcpierce/types/archives/1988/msg00042.html This short (one-page) e-mail message describes the history of the Hindley-Milner typing algorithm. Also, you may wish to attend an academic conference related to Haskell. For example, recently, I attended "Continuation Fest 2008" (http://logic.cs.tsukuba.ac.jp/~kam/Continuation2008/) on continuations. There, I met an Assistant Professor from Rutgers, The State University of New Jersey. During the conference dinner afterwards, I was able to ask him to help me figure out how to write Towers of Hanoi in Haskell. In addition, I met some local researchers who gave me information on attending a monthly Haskell study meeting. Benjamin L. Russell From allbery at ece.cmu.edu Fri May 9 08:11:54 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Fri May 9 08:05:53 2008 Subject: [Haskell-cafe] The Monad.Reader (11) - Call for Copy In-Reply-To: References: <4821FB57.3010808@btinternet.com> <4823527F.40608@btinternet.com> <20080508205955.GB3528@scytale.galois.com> <48236B7C.4000908@btinternet.com> Message-ID: On 2008 May 9, at 2:51, Wouter Swierstra wrote: >> Any chance of those issues being moved over still? I'd prefer to >> read the older issues in pdf format, like the new issues. > > I have gotten permission from (almost) all the authors to move the > content to the new wiki. I've started reformatting everything to the > MediaWiki format - for example: Put them up as is, let people with haskellwiki accounts reformat them? -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From allbery at ece.cmu.edu Fri May 9 08:15:02 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Fri May 9 08:09:01 2008 Subject: [Haskell-cafe] "resource exhausted" In-Reply-To: <5ae4f2ba0805082304y2ce4f464j8de6457c75333c7d@mail.gmail.com> References: <5ae4f2ba0805082304y2ce4f464j8de6457c75333c7d@mail.gmail.com> Message-ID: <7FC104C0-D54A-4B14-B50C-A10198C2CE5C@ece.cmu.edu> On 2008 May 9, at 2:04, Galchin, Vasili wrote: > I am running some monadic code that I have written. I double > checked my code and it seems to be ok (no guarantee though). I am > getting a "resource exhausted (Message too long)". I just did a > google on "resource exhausted" and saw a few posts on the number of > open files which is obviously not my case. Any ideas? "Message too long" (EMSGSIZE) is a Unix IPC error. You might want to examine what your code is doing in terms of actual I/O, as opposed to Haskell issues. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080509/7cfb97d1/attachment.htm From daniel.is.fischer at web.de Fri May 9 08:29:14 2008 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Fri May 9 08:21:26 2008 Subject: [Haskell-cafe] Induction (help!) In-Reply-To: <7.0.1.0.0.20080509125022.01d1bea8@ntlworld.com> References: <7.0.1.0.0.20080506095651.01d0edb8@ntlworld.com> <200805090027.07579.daniel.is.fischer@web.de> <7.0.1.0.0.20080509125022.01d1bea8@ntlworld.com> Message-ID: <200805091429.14753.daniel.is.fischer@web.de> Am Freitag, 9. Mai 2008 13:50 schrieb PR Stanley: > Paul: okay, da capo: We prove/test through case analysis > > > that the predicate p holds true for the first/starting case/element > > in the sequence. When dealing with natural numbers this could be 0 or > > 1. We try the formula with 0 and if it returns the desired result we > > move onto the next stage. If the formula doesn't work with 0 and so > > the predicate does not hold true for the base case then we've proved > > that it's a nonstarter. > > Well, it might hold for all n >= 3. But you're right, if p doesn't hold > for the base case, then it doesn't hold for _all_ cases. > Paul: I don't understand the point you're contending. We've chosen 0 > as our base case and if p(0) doesn't hold then nothing else will for > our proof. Granted, you may want to start from 3 or 4 as your base > case but we're not doing that here and for all we know forall n >= 3 > p(n) but this isn't relevant to our proof, surely. Right. I only wanted to say that we might have chosen the wrong base case for the proposition. If p(0) doesn't hold, then obviously [for all n. p(n)] doesn't hold. But [for all n. p(n) implies p(n+1)] could still be true, and in that case, if e.g. p(3) holds, then [for all n >= 3. p(n)] holds. So if the base case fails, still a large portion of the proposition might be saved, but if the induction step fails, that is not so. > > Paul: In the inductive step we'll make a couple of assumptions: we'll > > > imagine that p(j). We'll also assume that p holds true for the > > successor of j - p(j+1). > > Daniel: No. In the induction step, we prove that > IF p(j) holds, THEN p(j+1) holds, too. > p(j) is the assumption, and we prove that *given that assumption*, p(j+1) > follows. > Then we have proved > (*) p(j) implies p(j+1), for all j. > Paul: No, you haven't proved anything! I'm sorry but your assertion > fails to make much sense. Sorry? The induction step consists of proving that WHATEVER j is, IF p(j) holds, THEN p(j+1) holds, too. If or when we have done that, it is tautological to say that we proved (*) for all j. [p(j) implies p(j+1)]. In the notation used by Ryan Ingram yesterday, the induction step consists of proving L, j :: Nat |- p(j) => p(j+1) typically, that is done via proving L, j :: Nat, p(j) |- p(j+1) , i.e. proving p(j+1) under the assumption p(j), which by the logical rule of deduction/implication introduction is equivalent to L, j :: Nat |- p(j) => p(j+1). > > Daniel: If we already have established the base case, p(0), we have > p(0) and (p(0) implies p(1)) - the latter is a special case of (*) - from > that follows p(1). > Then we have > p(1) and (p(1) implies p(2), again a special case of (*), therefore p(2). > Now we have p(2) and (p(2) implies p(3)), hence p(3) and so on. > > Paul: Then with the help of rules and the protocol available to us we'll > > > try to establish whether the formula (f) gives us f(j) = f(j+1) - f(1) > > So, we know that the predicate holds for 0 or at least one element. > > By the way, could we have 3 or 4 or any element other than 0? > > Daniel: Sure, anything. Start with proving p(1073) and the induction > proves p(n) for > all n >= 1073, it does not say anything about n <= 1072. > > Paul: p(0). Then we set out to find out if p holds for the successor of 0 > > > followed by the successor of the successor of 0 and so forth. > > However, rather than laboriously applying p to every natural number > > we innstead try to find out if f(j+1) - f(1) will take us back to > > fj). I think this was the bit I wasn't getting. The assumptions in > > the inductive step and the algebraic procedures are not to prove the > > formula or premise per se. That's sort of been done with the base > > case. Rather, they help us to illustrate that f remains consistent > > while allowing for any random element to be succeeded or broken down > > a successive step at a time until we reach the base/starting > > element/value. Okay so far? > > Cheers, > Paul From olivier.boudry at gmail.com Fri May 9 09:42:08 2008 From: olivier.boudry at gmail.com (Olivier Boudry) Date: Fri May 9 09:36:07 2008 Subject: [Haskell-cafe] FFI: Creating a Storable for a C-struct composed of char arrays Message-ID: Hi all, I'm trying to make RFC calls to SAP using the nwsaprfc library. Some structs defined in the library contains arrays (byte or word arrays). For example: typedef struct _RFC_ATTRIBUTES { SAP_UC dest[64+1]; /* RFC destination */ SAP_UC host[100+1]; /* Own host name */ SAP_UC partnerHost[100+1]; /* Partner host name */ SAP_UC sysNumber[2+1]; /* R/3 system number */ SAP_UC sysId[8+1]; /* R/3 system name */ SAP_UC client[3+1]; /* Client */ SAP_UC user[12+1]; /* User */ SAP_UC language[2+1]; /* Language */ ... continued }}RFC_ATTRIBUTES, *P_RFC_ATTRIBUTES; I would like to create a Haskell Storable counterpart of this structure. Using http://therning.org/magnus/archives/tag/hsc2hs as an starting point, I could create Storable for structures containing fields with basic types. Before working on the real data structures I wrote a more simple example to play with: -- File: ArrayStruct.h -- typedef struct _ArrayStruct { char a[10+1]; char b[20+1]; char c[30+1]; } ArrayStruct, *P_ArrayStruct; -- File: ArrayStruct.c -- #include "ArrayStruct.h" void print_array_struct(ArrayStruct *f) { printf("%s\n", __FUNCTION__); printf("f->a: %s\n", f->a); printf("f->b: %s\n", f->b); printf("f->c: %s\n", f->c); } -- File: HArrayStruct.hsc {-# OPTIONS -ffi #-} module Main where import Foreign import Foreign.C.Types #include "ArrayStruct.h" data HArrayStruct = HArrayStruct { a :: String, b :: String, c :: String } type HarrayStructPtr = Ptr HArrayStruct foreign import ccall "static ArrayStruct.h print_array_struct" f_print_array_struct :: ArrayStructPtr -> IO () instance Storable HArrayStruct where sizeOf _ = (#size ArrayStruct) alignment _ = alignment (undefined :: CInt) peek _ = error "peek is not implemented" poke ptr (HArrayStruct a' b' c') = do (#poke ArrayStruct, a) ptr a' (#poke ArrayStruct, b) ptr b' (#poke ArrayStruct, c) ptr c' printArrayStruct as = with as f_print_array_struct main = printArrayStruct $ HArrayStruct { a="some", b="test", c="data" } -- End of files Of course it won't work as HArrayStruct in file HArrayStruct.hs uses Strings and String is not an instance of Storable. Ideally I would need some sort of Storable array of char. Is Data.Storable.Array the type I'm looking for? Could someone point me to some code using the same kind of structures? Thanks, Olivier. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080509/d682c410/attachment.htm From allbery at ece.cmu.edu Fri May 9 09:52:01 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Fri May 9 09:46:00 2008 Subject: [Haskell-cafe] FFI: Creating a Storable for a C-struct composed of char arrays In-Reply-To: References: Message-ID: <678A01DF-DD48-4318-AA11-08AA81DA1249@ece.cmu.edu> On 2008 May 9, at 9:42, Olivier Boudry wrote: > Of course it won't work as HArrayStruct in file HArrayStruct.hs uses > Strings and String is not an instance of Storable. > > Ideally I would need some sort of Storable array of char. Is > Data.Storable.Array the type I'm looking for? Could someone point me > to some code using the same kind of structures? You want CString (Foreign.C.String). -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080509/2ccf8e14/attachment.htm From andrewcoppin at btinternet.com Fri May 9 10:02:05 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Fri May 9 09:55:56 2008 Subject: [Haskell-cafe] Re: Interesting critique of Haskell In-Reply-To: References: <20080508033013.GA29498@scytale.galois.com> <4823461E.1080103@btinternet.com> Message-ID: <4824595D.80806@btinternet.com> Darrin Thompson wrote: > 2008/5/8 Donnie Jones : > >> I would be interested to see an article on Haskell in the same light as this >> Ocaml article, aka a constructive criticism of Haskell. >> >> > > http://www.drmaciver.com/2008/02/tell-us-why-your-language-sucks/ > Impressive. He thought of a whole bunch of stuff I hadn't thought of. While I'm here - I'm aware of how you control importing [or not] from the Prelude. Is there a way that I can, for example, import all the stuff like the basic types, classes, etc., but *not* all the list-related stuff? Or is the Prelude not that modular? From gcengels at cs.uu.nl Fri May 9 10:02:14 2008 From: gcengels at cs.uu.nl (Gerbo Engels) Date: Fri May 9 09:56:12 2008 Subject: [Haskell-cafe] GHC API: how to get the typechecked AST? Message-ID: <59631.131.211.84.84.1210341734.squirrel@mail.students.cs.uu.nl> Hello all, In the GHC Commentary [1] I can read that the type checker adds type information to the syntax tree. So I would expect that there is a way to get a syntax tree of type HsModule Id. The GHC API provides functions checkModule and checkAndLoadModule which both return a CheckedModule that contains the parsedSource :: Located (HsModule RdrName) and typecheckedSource :: LHsBinds Id. But it doesn't include anything of type HsModule Id. I don't see how to unify the parsedSource and typecheckedSource to get the syntax tree parametrised by Id instead of RdrName (and containing the type information), and the API doesn't seem to provide such functionality (or did I miss something?). Can anyone help? Or indicate where in the parsedSource the LHsBinds should be placed? Regards, Gerbo Engels [1] http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/HsSynType#DecoratingHsSynwithtypeinformation From andrewcoppin at btinternet.com Fri May 9 10:16:28 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Fri May 9 10:10:18 2008 Subject: [Haskell-cafe] List concat Message-ID: <48245CBC.309@btinternet.com> The function (++) :: [x] -> [x] -> [x] has O(n) complexity. If somebody were to invent some type that looks like [x] but actually uses some sort of tree rather than a linked list, you should be able to get O(1) concatenation. Has anybody ever implemented such a thing? From ndmitchell at gmail.com Fri May 9 10:20:38 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Fri May 9 10:14:37 2008 Subject: [Haskell-cafe] List concat In-Reply-To: <48245CBC.309@btinternet.com> References: <48245CBC.309@btinternet.com> Message-ID: <404396ef0805090720j5b34b549va09a15a06f119a8a@mail.gmail.com> Hi data List a = Zero | One a | Two (List a) (List a) On Fri, May 9, 2008 at 3:16 PM, Andrew Coppin wrote: > The function (++) :: [x] -> [x] -> [x] has O(n) complexity. (++) = Two -- O(1) complexity > If somebody were to invent some type that looks like [x] but actually uses > some sort of tree rather than a linked list, you should be able to get O(1) > concatenation. Has anybody ever implemented such a thing? Yes. Me, last month. http://www.cs.york.ac.uk/fp/darcs/uniplate/Data/Generics/Str.hs I wasn't the first though - it's been in Lava for years as well, which is where I got my inspiration. Thanks Neil From chris at eidhof.nl Fri May 9 10:23:03 2008 From: chris at eidhof.nl (Chris Eidhof) Date: Fri May 9 10:17:02 2008 Subject: [Haskell-cafe] [ANN] Twitter Client Message-ID: <9155ECD6-A50E-456A-9E2C-F3777007318D@eidhof.nl> Hey everyone, I was tired of all those graphical Twitter clients that aren't usable from my Terminal, so I wrote my own. It's still very much alpha, but comments or improvements are more than welcome. You can install it by downloading the twitter-package from hackage. In order to get it to work, create a file "~/.twitter" with the contents username:password, and you should be set. The source code isn't polished yet, but it makes heavy use of the new curl, json and xml libraries from Galois, so it might be interesting to browse the source. -chris From jeff.polakow at db.com Fri May 9 10:27:25 2008 From: jeff.polakow at db.com (Jeff Polakow) Date: Fri May 9 10:21:27 2008 Subject: [Haskell-cafe] List concat In-Reply-To: <48245CBC.309@btinternet.com> Message-ID: Hello, > The function (++) :: [x] -> [x] -> [x] has O(n) complexity. > > If somebody were to invent some type that looks like [x] but actually > uses some sort of tree rather than a linked list, you should be able to > get O(1) concatenation. Has anybody ever implemented such a thing? > You can also do this with a functional representation of lists (i.e. lists are functions); this idea is usually called difference lists. There is a nice dlist library on hackage. -Jeff --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080509/89049035/attachment.htm From olivier.boudry at gmail.com Fri May 9 10:28:38 2008 From: olivier.boudry at gmail.com (Olivier Boudry) Date: Fri May 9 10:22:37 2008 Subject: [Haskell-cafe] FFI: Creating a Storable for a C-struct composed of char arrays In-Reply-To: <678A01DF-DD48-4318-AA11-08AA81DA1249@ece.cmu.edu> References: <678A01DF-DD48-4318-AA11-08AA81DA1249@ece.cmu.edu> Message-ID: Hi Brandon, Thanks for your help, CString will work great for Char arrays, but what about the 16bit-Word arrays? I was not clear in my previous post but the structures used in the nwrfcsdk library can use 8bit or 16 bit "chars" depending on a #define (#define SAPwithUNICODE). Reading another post on FFI in this mailing list I found a link to the following page http://haskell.org/haskellwiki/Modern_array_libraries with a section on StorableArrayS. I'm now trying to use this example code to get StorableArray to work. I will try to use Data.Encoding to convert Haskell StringS to ASCII or UTF16 ByteStringS. Then unpack those ByteStringS to Word8 list and populate StorableArrayS with the bytes. I hope it'll do the job for both Word8 and Word16 arrays. Olivier. On Fri, May 9, 2008 at 9:52 AM, Brandon S. Allbery KF8NH < allbery@ece.cmu.edu> wrote: > > On 2008 May 9, at 9:42, Olivier Boudry wrote: > > Of course it won't work as HArrayStruct in file HArrayStruct.hs uses > Strings and String is not an instance of Storable. > > Ideally I would need some sort of Storable array of char. Is > Data.Storable.Array the type I'm looking for? Could someone point me to some > code using the same kind of structures? > > > You want CString (Foreign.C.String). > > -- > brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com > system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu > electrical and computer engineering, carnegie mellon university KF8NH > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080509/57ed57aa/attachment.htm From jules at jellybean.co.uk Fri May 9 10:31:31 2008 From: jules at jellybean.co.uk (Jules Bean) Date: Fri May 9 10:25:31 2008 Subject: [Haskell-cafe] List concat In-Reply-To: <48245CBC.309@btinternet.com> References: <48245CBC.309@btinternet.com> Message-ID: <48246043.60101@jellybean.co.uk> Andrew Coppin wrote: > The function (++) :: [x] -> [x] -> [x] has O(n) complexity. > > If somebody were to invent some type that looks like [x] but actually > uses some sort of tree rather than a linked list, you should be able to > get O(1) concatenation. Has anybody ever implemented such a thing? See also Data.Sequence, which is not O(1) append, but it is O(log something), and also O(1) cons and snoc and has lots of other nice complexities including fast update of a single cell. Jules From bulat.ziganshin at gmail.com Fri May 9 10:32:42 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Fri May 9 10:27:21 2008 Subject: [Haskell-cafe] FFI: Creating a Storable for a C-struct composed of char arrays In-Reply-To: References: <678A01DF-DD48-4318-AA11-08AA81DA1249@ece.cmu.edu> Message-ID: <797288778.20080509183242@gmail.com> Hello Olivier, Friday, May 9, 2008, 6:28:38 PM, you wrote: > Thanks for your help, CString will work great for Char arrays, but > what about the 16bit-Word arrays? TString. they are used a lot for interfacing with Win32 API -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From wss at Cs.Nott.AC.UK Fri May 9 10:42:39 2008 From: wss at Cs.Nott.AC.UK (Wouter Swierstra) Date: Fri May 9 10:37:51 2008 Subject: [Haskell-cafe] The Monad.Reader (11) - Call for Copy In-Reply-To: References: <4821FB57.3010808@btinternet.com> <4823527F.40608@btinternet.com> <20080508205955.GB3528@scytale.galois.com> <48236B7C.4000908@btinternet.com> Message-ID: <6C384441-9180-4313-A5A9-3E8F98D27A28@Cs.Nott.AC.UK> > Put them up as is, let people with haskellwiki accounts reformat them? Good idea. All the old content is now available, although some articles do look fairly horrendous: http://www.haskell.org/haskellwiki/The_Monad.Reader/Issue2 http://www.haskell.org/haskellwiki/The_Monad.Reader/Issue3 http://www.haskell.org/haskellwiki/The_Monad.Reader/Issue4 http://www.haskell.org/haskellwiki/The_Monad.Reader/Issue5 If anyone feels inclined to help reformat them, I'd really appreciate it! Wouter This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. From mblazevic at stilo.com Fri May 9 10:59:17 2008 From: mblazevic at stilo.com (Mario Blazevic) Date: Fri May 9 10:53:16 2008 Subject: [Haskell-cafe] Announce: SCC, Streaming Component Combinator library Message-ID: <482466C5.6080306@stilo.com> I'm pleased to announce the 0.1 release of Streaming Component Combinators in Haskell, based on my earlier work done in OmniMark and published in paper Mario Bla?evi?, Streaming component combinators, Extreme Markup Languages, 2006. http://www.idealliance.org/papers/extreme/proceedings/html/2006/Blazevic01/EML2006Blazevic01.html The release consists of the following: - Yet another monad transformer with coroutine functionality. Its central feature is the function pipe :: forall context x m r1 r2. Monad m => Producer m x r1 -> Consumer m x r2 -> Pipe context m (r1, r2) - Based on the above, streaming component types Transducer and Splitter are defined, as well as a number of primitive component instances. - Next are component combinators that can be used to synthesize larger components. - Finally, there is a rudimentary executable, shsh (Streaming Haskell SHell), that exposes most of the above within a command-line shell. It's useful for experiments and testing of new components. Here are a few simple command examples: wc -c count | show | concatenate wc -l foreach line then substitute x else suppress end | count | show | concatenate grep "foo" foreach line having substring "foo" then append "\n" else suppress end sed "s:foo:bar:" foreach substring "foo" then substitute "bar" end sed "s:foo:[\\&]:" foreach substring "foo" then prepend "[" | append "]" end The SCC library and shell are available on Hackage, at http://hackage.haskell.org/cgi-bin/hackage-scripts/package/scc-0.1 From byorgey at gmail.com Fri May 9 11:35:32 2008 From: byorgey at gmail.com (Brent Yorgey) Date: Fri May 9 11:29:31 2008 Subject: [Haskell-cafe] Re: Interesting critique of Haskell In-Reply-To: <4824595D.80806@btinternet.com> References: <20080508033013.GA29498@scytale.galois.com> <4823461E.1080103@btinternet.com> <4824595D.80806@btinternet.com> Message-ID: <22fcbd520805090835qdc3e879p8734adfaf1847fab@mail.gmail.com> On Fri, May 9, 2008 at 10:02 AM, Andrew Coppin wrote: > Darrin Thompson wrote: > >> 2008/5/8 Donnie Jones : >> >> >>> I would be interested to see an article on Haskell in the same light as >>> this >>> Ocaml article, aka a constructive criticism of Haskell. >>> >>> >>> >> >> http://www.drmaciver.com/2008/02/tell-us-why-your-language-sucks/ >> >> > > Impressive. He thought of a whole bunch of stuff I hadn't thought of. > > While I'm here - I'm aware of how you control importing [or not] from the > Prelude. Is there a way that I can, for example, import all the stuff like > the basic types, classes, etc., but *not* all the list-related stuff? Or is > the Prelude not that modular? > Not only is the Prelude not that modular, there's not really any mechanism to make it so. There's no way to partition an export list in such a way that whole chunks of it can be imported/not imported at a go. Would that be a nice feature? I don't know, possibly. -Brent -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080509/c7bf7ab6/attachment.htm From droundy at darcs.net Fri May 9 11:51:26 2008 From: droundy at darcs.net (David Roundy) Date: Fri May 9 11:45:25 2008 Subject: [Haskell-cafe] Re: Interesting critique of Haskell In-Reply-To: <22fcbd520805090835qdc3e879p8734adfaf1847fab@mail.gmail.com> References: <20080508033013.GA29498@scytale.galois.com> <4823461E.1080103@btinternet.com> <4824595D.80806@btinternet.com> <22fcbd520805090835qdc3e879p8734adfaf1847fab@mail.gmail.com> Message-ID: <20080509155125.GJ8845@darcs.net> On Fri, May 09, 2008 at 11:35:32AM -0400, Brent Yorgey wrote: > On Fri, May 9, 2008 at 10:02 AM, Andrew Coppin > wrote: > > While I'm here - I'm aware of how you control importing [or not] from the > > Prelude. Is there a way that I can, for example, import all the stuff like > > the basic types, classes, etc., but *not* all the list-related stuff? Or is > > the Prelude not that modular? > > Not only is the Prelude not that modular, there's not really any mechanism > to make it so. There's no way to partition an export list in such a way > that whole chunks of it can be imported/not imported at a go. Would that be > a nice feature? I don't know, possibly. Ordinary functions are easily split off from the Prelude. The only tricky bit is classes and class instances, and that's a Hard Problem, as far as I can tell. And, of course, "only" is quite an understatement here. -- David Roundy Department of Physics Oregon State University From andrewcoppin at btinternet.com Fri May 9 12:19:05 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Fri May 9 12:12:58 2008 Subject: [Haskell-cafe] Re: Interesting critique of Haskell In-Reply-To: <22fcbd520805090835qdc3e879p8734adfaf1847fab@mail.gmail.com> References: <20080508033013.GA29498@scytale.galois.com> <4823461E.1080103@btinternet.com> <4824595D.80806@btinternet.com> <22fcbd520805090835qdc3e879p8734adfaf1847fab@mail.gmail.com> Message-ID: <48247979.6030700@btinternet.com> Brent Yorgey wrote: > > On Fri, May 9, 2008 at 10:02 AM, Andrew Coppin > > wrote: > > While I'm here - I'm aware of how you control importing [or not] > from the Prelude. Is there a way that I can, for example, import > all the stuff like the basic types, classes, etc., but *not* all > the list-related stuff? Or is the Prelude not that modular? > > > Not only is the Prelude not that modular, there's not really any > mechanism to make it so. There's no way to partition an export list > in such a way that whole chunks of it can be imported/not imported at > a go. Would that be a nice feature? I don't know, possibly. Well, if the Prelude was split into several seperate modules, you could import just the modules you wanted. That sounds pretty easy to me. [I mean, apart from the minor detail that no current implementation works this way...] By default, if you don't ask for anything, your module automatically imports "Prelude". What if we made Prelude a module that just imports and re-exports several other modules - Prelude.Types, Prelude.Classes, Prelude.List (or rather, a subset of Data.List). Then if a module imports Prelude, or anything under Prelude, it turns off the automatic import, similar to the current system. Of course, I guess all this isn't likely to happen any time soon... I'm just throwing ideas out there. From droundy at darcs.net Fri May 9 12:23:52 2008 From: droundy at darcs.net (David Roundy) Date: Fri May 9 12:17:49 2008 Subject: [Haskell-cafe] Re: Interesting critique of Haskell In-Reply-To: <48247979.6030700@btinternet.com> References: <20080508033013.GA29498@scytale.galois.com> <4823461E.1080103@btinternet.com> <4824595D.80806@btinternet.com> <22fcbd520805090835qdc3e879p8734adfaf1847fab@mail.gmail.com> <48247979.6030700@btinternet.com> Message-ID: <20080509162351.GL8845@darcs.net> On Fri, May 09, 2008 at 05:19:05PM +0100, Andrew Coppin wrote: > Brent Yorgey wrote: > > > >On Fri, May 9, 2008 at 10:02 AM, Andrew Coppin > >> wrote: > > > > While I'm here - I'm aware of how you control importing [or not] > > from the Prelude. Is there a way that I can, for example, import > > all the stuff like the basic types, classes, etc., but *not* all > > the list-related stuff? Or is the Prelude not that modular? > > > > > >Not only is the Prelude not that modular, there's not really any > >mechanism to make it so. There's no way to partition an export list > >in such a way that whole chunks of it can be imported/not imported at > >a go. Would that be a nice feature? I don't know, possibly. > > Well, if the Prelude was split into several seperate modules, you could > import just the modules you wanted. That sounds pretty easy to me. [I > mean, apart from the minor detail that no current implementation works > this way...] > > By default, if you don't ask for anything, your module automatically > imports "Prelude". What if we made Prelude a module that just imports > and re-exports several other modules - Prelude.Types, Prelude.Classes, > Prelude.List (or rather, a subset of Data.List). Then if a module > imports Prelude, or anything under Prelude, it turns off the automatic > import, similar to the current system. > > Of course, I guess all this isn't likely to happen any time soon... I'm > just throwing ideas out there. It's pretty easy (albeit tedious) to do this for yourself (except that you wouldn't automatically turn off the import of Prelude, and you'd still suffer from the instances disease). module Prelude.Types ( Int, Double, Char, String ) where import Prelude From andrewcoppin at btinternet.com Fri May 9 12:32:44 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Fri May 9 12:26:35 2008 Subject: [Haskell-cafe] Re: Interesting critique of Haskell In-Reply-To: <20080509162351.GL8845@darcs.net> References: <20080508033013.GA29498@scytale.galois.com> <4823461E.1080103@btinternet.com> <4824595D.80806@btinternet.com> <22fcbd520805090835qdc3e879p8734adfaf1847fab@mail.gmail.com> <48247979.6030700@btinternet.com> <20080509162351.GL8845@darcs.net> Message-ID: <48247CAC.4070201@btinternet.com> David Roundy wrote: > It's pretty easy (albeit tedious) to do this for yourself (except that you > wouldn't automatically turn off the import of Prelude, and you'd still > suffer from the instances disease). > > module Prelude.Types ( Int, Double, Char, String ) where > > import Prelude > Sounds like a Hackage project for any suitable-bored persons. :-) From prstanley at ntlworld.com Fri May 9 13:52:55 2008 From: prstanley at ntlworld.com (PR Stanley) Date: Fri May 9 13:46:53 2008 Subject: [Haskell-cafe] Order of Evaluation Message-ID: <7.0.1.0.0.20080509184428.01d21b28@ntlworld.com> Hi (take 4 . map (>0)) (f s t) where s = 2 : t t = 3 : s f = zipWith (-) What would be the order of evaluation for the above code? How would I illustrate the evaluation step-by-step? I'm guessing that the code necessitates lazy evaluation and as such it starts with take then it applies f which in turn applies s and t and zipWith until the first element satisfies the predicate in map and This is repeated 4 times What does the list think? Many thanks, Paul P.S. I'm not done with induction. I'm just letting it rst for a bit. From miguelimo38 at yandex.ru Fri May 9 14:01:07 2008 From: miguelimo38 at yandex.ru (Miguel Mitrofanov) Date: Fri May 9 13:55:12 2008 Subject: [Haskell-cafe] Order of Evaluation In-Reply-To: <7.0.1.0.0.20080509184428.01d21b28@ntlworld.com> References: <7.0.1.0.0.20080509184428.01d21b28@ntlworld.com> Message-ID: On 9 May 2008, at 21:52, PR Stanley wrote: > Hi > (take 4 . map (>0)) (f s t) > where > s = 2 : t > t = 3 : s > f = zipWith (-) > What would be the order of evaluation for the above code? How would > I illustrate the evaluation step-by-step? What do you need it for, really? Pure functional programs are not about evaluation order, but about values. From donnie at darthik.com Fri May 9 14:34:47 2008 From: donnie at darthik.com (Donnie Jones) Date: Fri May 9 14:28:57 2008 Subject: [Haskell-cafe] Order of Evaluation In-Reply-To: <7.0.1.0.0.20080509184428.01d21b28@ntlworld.com> References: <7.0.1.0.0.20080509184428.01d21b28@ntlworld.com> Message-ID: Hello, I'm quite new to Haskell, but this is my understanding... Please correct me if I am wrong, as there is a good chance I am. ;) ### Begin Code ### module Main where main = putStrLn (show( (take 4 . map (> 0)) (f s t) )) where s = 2 : t t = 3 : s f = zipWith (-) {- - Output: - *Main> main - [False,True,False,True] -} {- - (take 4 . map (> 0)) (f s t) - Evaluates the list for take until 4 elements have been reached. - Below I replaced (f s t) with the values to make the evaluation - explicit. - - Evaluation: - - map (> 0) (zipWith (-) [2 ..] [3 ..]) - False -- 1st element for take. - - map (> 0) (zipWith (-) [3 ..] [2 ..]) - True -- 2nd element for take. - - map (> 0) (zipWith (-) [2 ..] [3 ..]) - False -- 3rd element for take. - - map (> 0) (zipWith (-) [3 ..] [2 ..]) - True -- 4th element for take. -} -- EOF. ### End Code ### Hope that helps. __ Donnie Jones On Fri, May 9, 2008 at 1:52 PM, PR Stanley wrote: > Hi > (take 4 . map (>0)) (f s t) > where > s = 2 : t > t = 3 : s > f = zipWith (-) > What would be the order of evaluation for the above code? How would I > illustrate the evaluation step-by-step? > I'm guessing that the code necessitates lazy evaluation and as such it > starts with take then it applies f which in turn applies s and t and zipWith > until the first element satisfies the predicate in map and This is repeated > 4 times > What does the list think? > Many thanks, > Paul > P.S. I'm not done with induction. I'm just letting it rst for a bit. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080509/fd2f5bdb/attachment-0001.htm From r.kelsall at millstream.com Fri May 9 14:43:48 2008 From: r.kelsall at millstream.com (Richard Kelsall) Date: Fri May 9 14:37:47 2008 Subject: [Haskell-cafe] Order of Evaluation In-Reply-To: <7.0.1.0.0.20080509184428.01d21b28@ntlworld.com> References: <7.0.1.0.0.20080509184428.01d21b28@ntlworld.com> Message-ID: <48249B64.2070003@millstream.com> PR Stanley wrote: > (take 4 . map (>0)) (f s t) > where > s = 2 : t > t = 3 : s > f = zipWith (-) > What would be the order of evaluation for the above code? As I understand it Haskell does not specify an order of evaluation and it would therefore be a mistake to write a program which relies on a particular evaluation order. This is the 'unsafe' aspect of unsafePerformIO. It is entirely at the whim of the compiler writer how it is evaluated as long as the eventual answer produced is correct. It would be possible to evaluate it in all sorts of exotic ways, or maybe choose a different one for each day of the week. However, you may be asking how does GHC 6.8.2 evaluate it when compiled at a certain optimisation level so you can make your program run fast or use less memory. In which case there will be a precise answer to your question. Richard. From miguelimo38 at yandex.ru Fri May 9 14:49:11 2008 From: miguelimo38 at yandex.ru (Miguel Mitrofanov) Date: Fri May 9 14:43:12 2008 Subject: [Haskell-cafe] Order of Evaluation In-Reply-To: <48249B64.2070003@millstream.com> References: <7.0.1.0.0.20080509184428.01d21b28@ntlworld.com> <48249B64.2070003@millstream.com> Message-ID: <23BC7113-91B2-4615-8915-E8F61D2AB8C3@yandex.ru> > As I understand it Haskell does not specify an order of evaluation > and it would therefore be a mistake to write a program which relies > on a particular evaluation order. This is the 'unsafe' aspect of > unsafePerformIO. Hmm... IMHO unsafePerformIO is 'unsafe' because it can lead to type errors in runtime. At least, that seems to be much more dangerous. From ryani.spam at gmail.com Fri May 9 15:01:44 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Fri May 9 14:55:41 2008 Subject: [Haskell-cafe] Induction (help!) In-Reply-To: <200805091429.14753.daniel.is.fischer@web.de> References: <7.0.1.0.0.20080506095651.01d0edb8@ntlworld.com> <200805090027.07579.daniel.is.fischer@web.de> <7.0.1.0.0.20080509125022.01d1bea8@ntlworld.com> <200805091429.14753.daniel.is.fischer@web.de> Message-ID: <2f9b2d30805091201s4e91ae6fgab80a6c76edc67af@mail.gmail.com> On 5/9/08, Daniel Fischer wrote: > Right. I only wanted to say that we might have chosen the wrong base case for > the proposition. If p(0) doesn't hold, then obviously [for all n. p(n)] > doesn't hold. But [for all n. p(n) implies p(n+1)] could still be true, and > in that case, if e.g. p(3) holds, then [for all n >= 3. p(n)] holds. > So if the base case fails, still a large portion of the proposition might be > saved, but if the induction step fails, that is not so. Note that this is reasonably trivial to translate into a regular inductive proof: let q(x) = p(x) OR (x < 3). given forall y :: Nat, (y >= 3) => p(y) => p(y+1) given p(3) given x :: Nat, and q(x) x < 2 or x == 2 or x > 2 case (x < 2): x+1 <= 2 q(x+1) holds trivially; x+1 < 3. case (x == 2) x+1 == 3 p(3) holds (given) therefore q(3) holds therefore q(x+1) holds case (x > 2) q(x) holds, so either p(x) holds or (x < 3). case (x < 3): x > 2 and x < 3 is a contradiction. case q(x) holds: forall y :: Nat, (y >= 3) => p(y) => p(y+1) (given) (x >= 3) => p(x) => p(x+1) (instantiate with y <- x) (x >= 3) (since x > 2) p(x+1) (derive from p(x) and x >= 3 and the instantiation) (x < 3) or p(x+1) therefore q(x+1) so, forall x::Nat, q(x) => q(x+1). p(0) is trivial (x < 3). so, forall x::Nat, q(x) which means forall x :: Nat, x >= 3 => p(x). -- ryan From gwern0 at gmail.com Fri May 9 15:31:25 2008 From: gwern0 at gmail.com (Gwern Branwen) Date: Fri May 9 15:26:53 2008 Subject: [Haskell-cafe] [ANN] Twitter Client In-Reply-To: <9155ECD6-A50E-456A-9E2C-F3777007318D@eidhof.nl> References: <9155ECD6-A50E-456A-9E2C-F3777007318D@eidhof.nl> Message-ID: <20080509193125.GA14946@localhost> On 2008.05.09 16:23:03 +0200, Chris Eidhof scribbled 0.6K characters: > Hey everyone, > > I was tired of all those graphical Twitter clients that aren't usable from > my Terminal, so I wrote my own. It's still very much alpha, but comments or > improvements are more than welcome. You can install it by downloading the > twitter-package from hackage. > > In order to get it to work, create a file "~/.twitter" with the contents > username:password, and you should be set. > > The source code isn't polished yet, but it makes heavy use of the new curl, > json and xml libraries from Galois, so it might be interesting to browse > the source. > > -chris For those interested, the links is . Hackage reports a build-failure, but I think that particular problem is because of Curl's Haddock failure. That said, I did run into a build problem: --- gwern@localhost:4089~/twitter-0.1>cabal-install twitter [ 3:30PM] 'twitter-0.1' is cached. Configuring twitter-0.1... Preprocessing executables for twitter-0.1... Building twitter-0.1... ./Twitter.hs:3:7: Could not find module `GUI.Terminal': Use -v to see a list of the files searched for. cabal: Error: some packages failed to install: twitter-0.1 failed during the building phase. The exception was: exit: ExitFailure 1 --- Is GUI.Terminal some special Mac haskell package I wouldn't have on Linux? -- gwern Retinal NACSI Global Branch RUOP Team Embassy presidential Kerry SETA -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080509/9991ac9e/attachment.bin From andrewcoppin at btinternet.com Fri May 9 15:39:38 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Fri May 9 15:33:28 2008 Subject: [Haskell-cafe] MonadPlus Message-ID: <4824A87A.8050306@btinternet.com> OK, so I feel I understand monads fine. I regularly use Maybe, [] and IO, and I've even constructed a few monads of my own. But here's a question: what is the purpose of the MonadPlus class? Clearly it defines a binary operation over monadic values and an identity element for that operation. But... what is this supposed to *do*? (For example, (>>) has an almost identical signature to mplus. But presumably they don't both do the same thing...) What functionallity is this supposed to give you? [In a somewhat unrelated question... I saw some code the other day that used Either as if it were a monad. And yet, I don't see an instance given in the standard libraries - even though there should be one. I can see Functor (Either a), but not Monad (Either a) or even Monad (Either String)...] From droundy at darcs.net Fri May 9 15:47:32 2008 From: droundy at darcs.net (David Roundy) Date: Fri May 9 15:41:29 2008 Subject: [Haskell-cafe] MonadPlus In-Reply-To: <4824A87A.8050306@btinternet.com> References: <4824A87A.8050306@btinternet.com> Message-ID: <20080509194731.GN8845@darcs.net> On Fri, May 09, 2008 at 08:39:38PM +0100, Andrew Coppin wrote: > OK, so I feel I understand monads fine. I regularly use Maybe, [] and > IO, and I've even constructed a few monads of my own. But here's a > question: what is the purpose of the MonadPlus class? > > Clearly it defines a binary operation over monadic values and an > identity element for that operation. But... what is this supposed to > *do*? (For example, (>>) has an almost identical signature to mplus. But > presumably they don't both do the same thing...) What functionallity is > this supposed to give you? MonadPlus is a crude way of achieving the catching of exceptional cases, and you should think of mplus as being equivalent to (catch . const). The trouble is that MonadPlus doesn't provide any mechanism for finding out what went wrong, so I've only ever found it useful when using the Maybe monad (which itself has no way of identifying what went wrong). > [In a somewhat unrelated question... I saw some code the other day that > used Either as if it were a monad. And yet, I don't see an instance > given in the standard libraries - even though there should be one. I can > see Functor (Either a), but not Monad (Either a) or even Monad (Either > String)...] I am pretty certain that there is a monad instance for Either, but also don't know where it's defined. -- David Roundy Department of Physics Oregon State University From rich.neswold at gmail.com Fri May 9 15:47:38 2008 From: rich.neswold at gmail.com (Rich Neswold) Date: Fri May 9 15:41:39 2008 Subject: [Haskell-cafe] MonadPlus In-Reply-To: <4824A87A.8050306@btinternet.com> References: <4824A87A.8050306@btinternet.com> Message-ID: <14cf844b0805091247q3990d102pf005570f8b03c3ba@mail.gmail.com> On Fri, May 9, 2008 at 2:39 PM, Andrew Coppin wrote: > [In a somewhat unrelated question... I saw some code the other day that > used Either as if it were a monad. And yet, I don't see an instance given in > the standard libraries - even though there should be one. I can see Functor > (Either a), but not Monad (Either a) or even Monad (Either String)...] It's used in the Error Monad. -- Rich JID: rich@neswold.homeunix.net LOI: https://www.google.com/reader/shared/00900594587109808626 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080509/6ab40d58/attachment.htm From bos at serpentine.com Fri May 9 15:48:29 2008 From: bos at serpentine.com (Bryan O'Sullivan) Date: Fri May 9 15:42:29 2008 Subject: [Haskell-cafe] MonadPlus In-Reply-To: <4824A87A.8050306@btinternet.com> References: <4824A87A.8050306@btinternet.com> Message-ID: <4824AA8D.1010207@serpentine.com> Andrew Coppin wrote: > But here's a > question: what is the purpose of the MonadPlus class? It gives you a way of working with monads as monoids. Consider a Parsec example: metasyntactic = text "foo" `mplus` text "bar" `mplus` text "baz" You'll get back whichever one matched, in left-to-right-order, or mzero (a parse failure) if all of them fail. References: <4824A87A.8050306@btinternet.com> <4824AA8D.1010207@serpentine.com> Message-ID: <4824AC53.9000805@btinternet.com> Bryan O'Sullivan wrote: > Andrew Coppin wrote: > >> But here's a >> question: what is the purpose of the MonadPlus class? >> > > It gives you a way of working with monads as monoids. Consider a Parsec > example: > > metasyntactic = text "foo" `mplus` text "bar" `mplus` text "baz" > > You'll get back whichever one matched, in left-to-right-order, or mzero > (a parse failure) if all of them fail. > ...so it's a kind of choice operator? Run all actions until you get to one that succeeds and return the result from that? From allbery at ece.cmu.edu Fri May 9 16:09:37 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Fri May 9 16:03:34 2008 Subject: [Haskell-cafe] MonadPlus In-Reply-To: <4824AC53.9000805@btinternet.com> References: <4824A87A.8050306@btinternet.com> <4824AA8D.1010207@serpentine.com> <4824AC53.9000805@btinternet.com> Message-ID: On May 9, 2008, at 15:56 , Andrew Coppin wrote: > Bryan O'Sullivan wrote: >> Andrew Coppin wrote: >> >>> But here's a >>> question: what is the purpose of the MonadPlus class? >>> >> >> It gives you a way of working with monads as monoids. Consider a >> Parsec >> example: >> >> metasyntactic = text "foo" `mplus` text "bar" `mplus` text "baz" >> >> You'll get back whichever one matched, in left-to-right-order, or >> mzero >> (a parse failure) if all of them fail. >> > > ...so it's a kind of choice operator? Run all actions until you get > to one that succeeds and return the result from that? In monadic guise that's how it's usually used, yes (since monoids like (+) are not generally all that useful as monads; (++) (list monad) and (.) (Monad ((-) r)) might be, though). -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From derek.a.elkins at gmail.com Fri May 9 16:09:36 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Fri May 9 16:03:40 2008 Subject: [Haskell-cafe] MonadPlus In-Reply-To: <20080509194731.GN8845@darcs.net> References: <4824A87A.8050306@btinternet.com> <20080509194731.GN8845@darcs.net> Message-ID: <1210363776.5514.52.camel@derek-laptop> On Fri, 2008-05-09 at 12:47 -0700, David Roundy wrote: > On Fri, May 09, 2008 at 08:39:38PM +0100, Andrew Coppin wrote: > > OK, so I feel I understand monads fine. I regularly use Maybe, [] and > > IO, and I've even constructed a few monads of my own. But here's a > > question: what is the purpose of the MonadPlus class? > > > > Clearly it defines a binary operation over monadic values and an > > identity element for that operation. But... what is this supposed to > > *do*? (For example, (>>) has an almost identical signature to mplus. But > > presumably they don't both do the same thing...) What functionallity is > > this supposed to give you? > > MonadPlus is a crude way of achieving the catching of exceptional cases, > and you should think of mplus as being equivalent to (catch . const). The > trouble is that MonadPlus doesn't provide any mechanism for finding out > what went wrong, so I've only ever found it useful when using the Maybe > monad (which itself has no way of identifying what went wrong). MonadPlus is a crude way of doing that, but that isn't the motivating example of MonadPlus, indeed, that arguably shouldn't be a MonadPlus instance. Cale Gibbard suggests (perhaps not originally) splitting MonadPlus into MonadPlus (and MonadZero) and MonadOrElse. They'd have essentially the same operations, but would be intended to satisfy different laws. Maybe, Either e, IO are better instances of MonadOrElse while [], Parser, LogicT, other non-determinism, parser, or concurrency monads would more appropriately be MonadPlus. From bos at serpentine.com Fri May 9 16:12:08 2008 From: bos at serpentine.com (Bryan O'Sullivan) Date: Fri May 9 16:06:06 2008 Subject: [Haskell-cafe] MonadPlus In-Reply-To: <4824AC53.9000805@btinternet.com> References: <4824A87A.8050306@btinternet.com> <4824AA8D.1010207@serpentine.com> <4824AC53.9000805@btinternet.com> Message-ID: <4824B018.8030202@serpentine.com> Andrew Coppin wrote: > ...so it's a kind of choice operator? Run all actions until you get to > one that succeeds and return the result from that? In the context of Parsec, yes. In the grander scheme of things, the behaviour depends on whatever is appropriate for the particular monad you're working in. So, for example, mplus for lists is (++) and mzero is [], which is quite a different set of behaviours from the Parsec case. Usually, you can rely on MonadPlus behaving like a monoid. There are occasional exceptions, which is a mite upsetting. http://www.haskell.org/haskellwiki/MonadPlus References: <4824A87A.8050306@btinternet.com> <4824AA8D.1010207@serpentine.com> Message-ID: <1210364405.5514.63.camel@derek-laptop> On Fri, 2008-05-09 at 12:48 -0700, Bryan O'Sullivan wrote: > Andrew Coppin wrote: > > But here's a > > question: what is the purpose of the MonadPlus class? > > It gives you a way of working with monads as monoids. I find this description mostly useless. Monads form monoids without being MonadPlus. instance Monad m => Monoid (m ()) where mempty = return () mappend = (<<) You can form monoids out of Kleisli arrows, instance Monad m => Monoid (a -> m a) where mempty = return mappend = (<=<) You could form monads into a monoid in another way, instance (Monad m, Monoid a) => Monoid (m a) mempty = return mempty mappend = liftM2 mappend So "It gives you a way of working with monads as monoids." is significantly underspecified and doesn't actually say what MonadPlus means, let alone what it is intended for. A more interesting statement in that vein is: It gives you a way of working with monads as (distributive) near-rigs. This statement does actually encode some (all?) of the intended meaning of MonadPlus, e.g. mzero is intended to be a zero of (>>) beyond simply being a unit for mplus. From nicolas.frisby at gmail.com Fri May 9 16:24:40 2008 From: nicolas.frisby at gmail.com (Nicolas Frisby) Date: Fri May 9 16:18:39 2008 Subject: [Haskell-cafe] MonadPlus In-Reply-To: <4824B018.8030202@serpentine.com> References: <4824A87A.8050306@btinternet.com> <4824AA8D.1010207@serpentine.com> <4824AC53.9000805@btinternet.com> <4824B018.8030202@serpentine.com> Message-ID: <5ce89fb50805091324i19890851v25ec9f96c1517780@mail.gmail.com> It sounds like the semantics of the MonadPlus methods are under-specified. I recall once writing a newtype wrapper to treat the same non-determinism monad with different mplus semantics, akin to cut versus backtracking. I think of MonadPlus as a less expressive version of msplit, from Backtracking, Interleaving, and Terminating Monad Transformers The Functional Pearl paper by Oleg Kiselyov, Chung-chieh Shan, Daniel P. Friedman and Amr Sabry. ICFP 2005. Is that an over-simplification? On Fri, May 9, 2008 at 3:12 PM, Bryan O'Sullivan wrote: > Andrew Coppin wrote: > >> ...so it's a kind of choice operator? Run all actions until you get to >> one that succeeds and return the result from that? > > In the context of Parsec, yes. In the grander scheme of things, the > behaviour depends on whatever is appropriate for the particular monad > you're working in. > > So, for example, mplus for lists is (++) and mzero is [], which is quite > a different set of behaviours from the Parsec case. Usually, you can > rely on MonadPlus behaving like a monoid. There are occasional > exceptions, which is a mite upsetting. > > http://www.haskell.org/haskellwiki/MonadPlus > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From prstanley at ntlworld.com Fri May 9 16:37:02 2008 From: prstanley at ntlworld.com (PR Stanley) Date: Fri May 9 16:31:04 2008 Subject: [Haskell-cafe] Order of Evaluation In-Reply-To: References: <7.0.1.0.0.20080509184428.01d21b28@ntlworld.com> Message-ID: <7.0.1.0.0.20080509213225.01d749d0@ntlworld.com> >>Hi >>(take 4 . map (>0)) (f s t) >>where >> s = 2 : t >> t = 3 : s >>f = zipWith (-) >>What would be the order of evaluation for the above code? How would >>I illustrate the evaluation step-by-step? > >What do you need it for, really? Pure functional programs are not >about evaluation order, but about values. Paul: It actually comes from an old test. The question provides the code, asks for the evaluation of the code and then asks " You should show your working at each stage of the calculation." This isn't a straightforward top-to-bottom calculation that you can carry out in the style demonstrated frequently in the Hutton book. - {apply bla bla } So I'm wondering how else it can be done. Many thanks Paul From bf3 at telenet.be Fri May 9 16:37:30 2008 From: bf3 at telenet.be (Peter Verswyvelen) Date: Fri May 9 16:31:34 2008 Subject: [Haskell-cafe] unsafeInterleaveIO and OpenGL Message-ID: <4824B60A.5040709@telenet.be> I'm experiencing strange behavior when executing some Haskell OpenGL code inside unsafeInterleaveIO. For example, vp <- get GL.viewport returns garbage, as if the opengl context is not correctly set. Is this to be expected? Or is it likely a bug on my side? Thanks, Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080509/c239a34e/attachment.htm From dpiponi at gmail.com Fri May 9 16:43:05 2008 From: dpiponi at gmail.com (Dan Piponi) Date: Fri May 9 16:37:14 2008 Subject: [Haskell-cafe] MonadPlus In-Reply-To: <4824AC53.9000805@btinternet.com> References: <4824A87A.8050306@btinternet.com> <4824AA8D.1010207@serpentine.com> <4824AC53.9000805@btinternet.com> Message-ID: <625b74080805091343g821b93fi8f14f772cee9e0e1@mail.gmail.com> Andrew asked, > ...so it's a kind of choice operator? Run all actions until you get to one > that succeeds and return the result from that? The eternal bit of trickiness for Haskell is that type classes group often together things that people don't immediately see as similar - monads probably being the best example. So it's probably best not to immediately try to find an all-encompassing summary of MonadPlus like "a kind of choice operator" but instead concentrate on the definition. The key thing is the line > mplus :: m a -> m a -> m a You can combine two m a's together with a binary operation to get another m a. Absolutely any binary operation (with an identity) that fits the rather lax laws that come with MonadPlus will do. Depending on context mplus might mean "either/or", or "and", or "this first, or else that" or something entirely different that nobody here has anticipated yet. For each monad m, just try to think about how you might combine a pair of m a's and what might serve as an identity. -- Dan From trevion at gmail.com Fri May 9 16:46:05 2008 From: trevion at gmail.com (J. Garrett Morris) Date: Fri May 9 16:40:03 2008 Subject: [Haskell-cafe] Haskell PNG Writer In-Reply-To: References: Message-ID: <6cf91caa0805091346u6a8db6dx4b3ce0a7da84f6b3@mail.gmail.com> As long as you don't mind producing two-color images, http://haskell.org/haskellwiki/Library/PNG is an option. I found it very easy to extend it to eight-bit grayscale - I didn't need fullcolor images. /g On Sat, May 3, 2008 at 11:12 PM, Nahuel Rullo wrote: > Hi list, i am new in Haskell. I need to make images (PNG, JPEG) with > haskell, if you can give me a tutorial, thanks! > > -- > Nahuel Rullo > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- It is myself I have never met, whose face is pasted on the underside of my mind. From miguelimo38 at yandex.ru Fri May 9 16:58:28 2008 From: miguelimo38 at yandex.ru (Miguel Mitrofanov) Date: Fri May 9 16:52:34 2008 Subject: [Haskell-cafe] MonadPlus In-Reply-To: <625b74080805091343g821b93fi8f14f772cee9e0e1@mail.gmail.com> References: <4824A87A.8050306@btinternet.com> <4824AA8D.1010207@serpentine.com> <4824AC53.9000805@btinternet.com> <625b74080805091343g821b93fi8f14f772cee9e0e1@mail.gmail.com> Message-ID: <9B3E548A-4D26-40B2-9FE4-C41097DEACE2@yandex.ru> On 10 May 2008, at 00:43, Dan Piponi wrote: > Andrew asked, > >> ...so it's a kind of choice operator? Run all actions until you get >> to one >> that succeeds and return the result from that? > > The eternal bit of trickiness for Haskell is that type classes group > often together things that people don't immediately see as similar - > monads probably being the best example. Well, that's the whole point of mathematics, isn't it? Mathematics is just a way to name different things with one word (opposed to philosophy, which is a way to name the same thing with different words). From lemming at henning-thielemann.de Fri May 9 17:05:04 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri May 9 16:57:37 2008 Subject: [Haskell-cafe] unsafeInterleaveIO and OpenGL In-Reply-To: <4824B60A.5040709@telenet.be> References: <4824B60A.5040709@telenet.be> Message-ID: On Fri, 9 May 2008, Peter Verswyvelen wrote: > I'm experiencing strange behavior when executing some Haskell OpenGL code > inside unsafeInterleaveIO. > > For example, > > vp <- get GL.viewport > > returns garbage, as if the opengl context is not correctly set. Sounds reasonable. 'unsafeInterleaveIO' defers computation of 'vp' until it is actually needed. At this time the viewport might have changed. From jeff.polakow at db.com Fri May 9 17:07:12 2008 From: jeff.polakow at db.com (Jeff Polakow) Date: Fri May 9 17:01:13 2008 Subject: [Haskell-cafe] GHC predictability Message-ID: Hello, One frequent criticism of Haskell (and by extension GHC) is that it has unpredictable performance and memory consumption. I personally do not find this to be the case. I suspect that most programmer confusion is rooted in shaky knowledge of lazy evaluation; and I have been able to fix, with relative ease, the various performance problems I've run into. However I am not doing any sort of performance critical computing (I care about minutes or seconds, but not about milliseconds). I would like to know what others think about this. Is GHC predictable? Is a thorough knowledge of lazy evaluation good enough to write efficient (whatever that means to you) code? Or is intimate knowledge of GHC's innards necessary? thanks, Jeff PS I am conflating Haskell and GHC because I use GHC (with its extensions) and it produces (to my knowledge) the fastest code. --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080509/af1e8846/attachment.htm From prstanley at ntlworld.com Fri May 9 17:07:48 2008 From: prstanley at ntlworld.com (PR Stanley) Date: Fri May 9 17:01:47 2008 Subject: [Haskell-cafe] (Num t) => [t] or [Int] Message-ID: <7.0.1.0.0.20080509220113.01d7dd60@ntlworld.com> Hi I thought [1, 2, 3] :: [Int] GHC says it's (Num t) > [t] Okay, when it comes to 3.3:[1,2,3] (Num t) => [t] makes more sense. Is that the only reason? Cheers, Paul From gwern0 at gmail.com Fri May 9 17:07:51 2008 From: gwern0 at gmail.com (Gwern Branwen) Date: Fri May 9 17:01:57 2008 Subject: [Haskell-cafe] Old editions of The Monad.Reader lost In-Reply-To: <4E8D36EF-FAAA-4204-85CD-398FAF2822E6@cs.nott.ac.uk> References: <4E8D36EF-FAAA-4204-85CD-398FAF2822E6@cs.nott.ac.uk> Message-ID: On Mon, Nov 26, 2007 at 9:27 AM, Wouter Swierstra wrote: > > On 18 Aug 2007, at 20:10, Henk-Jan van Tuyl wrote: > >> Now that all hawiki pages have been removed, we have lost some valuable >> information. For example The Monad.Reader; on >> http://www.haskell.org/haskellwiki/The_Monad.Reader > > A few people have been asking what has happened to old editions of the > Monad.Reader. I'm happy to announce that almost all authors have agreed to > the new Haskellwiki license. > > I have added the .pdf of the very first issue to the Monad.Reader homepage; > Shae Erisson was kind enough to set up a wiki hosting the later issues. > > http://www.haskell.org/sitewiki/images/9/9d/TMR-Issue1.pdf > > http://www.haskell.org/tmrwiki/ > > Both are links can be found on the Monad.Reader homepage. > > If anyone is inclined to port the MoinMoin content to the Haskellwiki > format, I'd be happy to provide them with a list of all the authors that > have agreed with the new license. > > Wouter Almost all? Is that why some are missing? eg. omits "Impure Thoughts 1 - Thtatic Compilathionth (without a lisp) " . -- gwern From bulat.ziganshin at gmail.com Fri May 9 17:15:30 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Fri May 9 17:09:56 2008 Subject: [Haskell-cafe] (Num t) => [t] or [Int] In-Reply-To: <7.0.1.0.0.20080509220113.01d7dd60@ntlworld.com> References: <7.0.1.0.0.20080509220113.01d7dd60@ntlworld.com> Message-ID: <923053136.20080510011530@gmail.com> Hello PR, Saturday, May 10, 2008, 1:07:48 AM, you wrote: > Okay, when it comes to 3.3:[1,2,3] (Num t) => [t] makes more sense. > Is that the only reason? the reason is that 1 as any other numerical constant, may be directly used as Int, Integer, Double or any other Num value. if 1 is Int, you will need to make more conversions -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From lemming at henning-thielemann.de Fri May 9 17:17:44 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri May 9 17:10:15 2008 Subject: [Haskell-cafe] Re: Interesting critique of Haskell In-Reply-To: <48247979.6030700@btinternet.com> References: <20080508033013.GA29498@scytale.galois.com> <4823461E.1080103@btinternet.com> <4824595D.80806@btinternet.com> <22fcbd520805090835qdc3e879p8734adfaf1847fab@mail.gmail.com> <48247979.6030700@btinternet.com> Message-ID: On Fri, 9 May 2008, Andrew Coppin wrote: > Brent Yorgey wrote: >> >> On Fri, May 9, 2008 at 10:02 AM, Andrew Coppin > > wrote: >> >> While I'm here - I'm aware of how you control importing [or not] >> from the Prelude. Is there a way that I can, for example, import >> all the stuff like the basic types, classes, etc., but *not* all >> the list-related stuff? Or is the Prelude not that modular? >> >> >> Not only is the Prelude not that modular, there's not really any mechanism >> to make it so. There's no way to partition an export list in such a way >> that whole chunks of it can be imported/not imported at a go. Would that >> be a nice feature? I don't know, possibly. > > Well, if the Prelude was split into several seperate modules, you could > import just the modules you wanted. That sounds pretty easy to me. [I mean, > apart from the minor detail that no current implementation works this way...] I think, Prelude is meant as one monolithic module and it should be certainly the only one from which all identifiers are anonymously imported in an unqualified way. (In order to avoid name clashes.) http://www.haskell.org/haskellwiki/Import_modules_properly Actually, Prelude exports some identifiers, that can be also imported from more specific modules like Text.Show, Data.List. From dons at galois.com Fri May 9 17:24:12 2008 From: dons at galois.com (Don Stewart) Date: Fri May 9 17:18:14 2008 Subject: [Haskell-cafe] GHC predictability In-Reply-To: References: Message-ID: <20080509212412.GE24396@scytale.galois.com> jeff.polakow: > Hello, > > One frequent criticism of Haskell (and by extension GHC) is that it has > unpredictable performance and memory consumption. I personally do not find > this to be the case. I suspect that most programmer confusion is rooted in > shaky knowledge of lazy evaluation; and I have been able to fix, with > relative ease, the various performance problems I've run into. However I > am not doing any sort of performance critical computing (I care about > minutes or seconds, but not about milliseconds). > > I would like to know what others think about this. Is GHC predictable? Is > a thorough knowledge of lazy evaluation good enough to write efficient > (whatever that means to you) code? Or is intimate knowledge of GHC's > innards necessary? > > thanks, > Jeff > > PS I am conflating Haskell and GHC because I use GHC (with its extensions) > and it produces (to my knowledge) the fastest code. This has been my experience to. I'm not even sure where "unpredicatiblity" would even come in, other than though not understanding the demand patterns of the code. It's relatively easy to look at the Core to get a precise understanding of the runtime behaviour. I've also not found the GC unpredicatble either. -- Don From dpiponi at gmail.com Fri May 9 17:34:33 2008 From: dpiponi at gmail.com (Dan Piponi) Date: Fri May 9 17:28:34 2008 Subject: [Haskell-cafe] MonadPlus In-Reply-To: <9B3E548A-4D26-40B2-9FE4-C41097DEACE2@yandex.ru> References: <4824A87A.8050306@btinternet.com> <4824AA8D.1010207@serpentine.com> <4824AC53.9000805@btinternet.com> <625b74080805091343g821b93fi8f14f772cee9e0e1@mail.gmail.com> <9B3E548A-4D26-40B2-9FE4-C41097DEACE2@yandex.ru> Message-ID: <625b74080805091434w135f5293sdfabc218fbc08d65@mail.gmail.com> Miguel said: > Well, that's the whole point of mathematics, isn't it? Abstraction is common to mathematics and computing. But in computing the abstraction often follows lines that seem obvious. For example a GUI library might have a Widget class and people can immediately identify various regions of the screen with Widgets and know that when they want a new kind of device in their GUI it's time to define a widget. Although the Widget class may be technically defined by the interface it exposes, in practice people just think "a gadget that can appear on the screen". Even someone who has never programmed can probably quickly guess what kinds of things correspond to instances of the Widget class. But mathematics is full of abstractions that aren't like this. Times modulo 24 hours and the way a closed loop can travel around a knot both form a group. The thing they have in common is that there's a binary operation with identity and inverses. Sometimes it can be more confusing to try to find a snappy English phrase that sums them up without restating the definition. Many common Haskell type classes lean towards the latter kind of abstraction. -- Dan From barsoap at web.de Fri May 9 17:34:40 2008 From: barsoap at web.de (Achim Schneider) Date: Fri May 9 17:28:51 2008 Subject: [Haskell-cafe] Re: Order of Evaluation References: <7.0.1.0.0.20080509184428.01d21b28@ntlworld.com> <48249B64.2070003@millstream.com> <23BC7113-91B2-4615-8915-E8F61D2AB8C3@yandex.ru> Message-ID: <20080509233440.4b671b6a@solaris> Miguel Mitrofanov wrote: > > As I understand it Haskell does not specify an order of evaluation > > and it would therefore be a mistake to write a program which relies > > on a particular evaluation order. This is the 'unsafe' aspect of > > unsafePerformIO. > > Hmm... IMHO unsafePerformIO is 'unsafe' because it can lead to type > errors in runtime. At least, that seems to be much more dangerous. > Nope. That'd be unsafeCoerce#, which you never heard of, and I did not mention it in this post. Go away. This is not the function you are looking for. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. From droundy at darcs.net Fri May 9 17:38:11 2008 From: droundy at darcs.net (David Roundy) Date: Fri May 9 17:32:09 2008 Subject: [Haskell-cafe] GHC predictability In-Reply-To: <20080509212412.GE24396@scytale.galois.com> References: <20080509212412.GE24396@scytale.galois.com> Message-ID: <20080509213810.GP8845@darcs.net> On Fri, May 09, 2008 at 02:24:12PM -0700, Don Stewart wrote: > jeff.polakow: > > Hello, > > > > One frequent criticism of Haskell (and by extension GHC) is that it has > > unpredictable performance and memory consumption. I personally do not find > > this to be the case. I suspect that most programmer confusion is rooted in > > shaky knowledge of lazy evaluation; and I have been able to fix, with > > relative ease, the various performance problems I've run into. However I > > am not doing any sort of performance critical computing (I care about > > minutes or seconds, but not about milliseconds). > > > > I would like to know what others think about this. Is GHC predictable? Is > > a thorough knowledge of lazy evaluation good enough to write efficient > > (whatever that means to you) code? Or is intimate knowledge of GHC's > > innards necessary? > > > > thanks, > > Jeff > > > > PS I am conflating Haskell and GHC because I use GHC (with its extensions) > > and it produces (to my knowledge) the fastest code. > > This has been my experience to. I'm not even sure where > "unpredicatiblity" would even come in, other than though not > understanding the demand patterns of the code. I think the unpredictability comes in due to the difficulty of predicting resource useage in the presence of lazy data (and particularly lazy IO). It's not really that hard to predict the behavior of code that you write, but it can certainly be hard to predict the effect of changes that you make to someone else's code. It's an effect of the possibility of constructing and consuming large data objects without ever holding them in memory. It's beautiful, and it's wonderful, but it's also really easy for someone to add a second consumer of the same object, and send performance through the floor. Of course, one can avoid this particular pattern, but then you lose some of the very nice abstractions that laziness gives us. -- David Roundy Department of Physics Oregon State University From miguelimo38 at yandex.ru Fri May 9 17:42:30 2008 From: miguelimo38 at yandex.ru (Miguel Mitrofanov) Date: Fri May 9 17:36:33 2008 Subject: [Haskell-cafe] Re: Order of Evaluation In-Reply-To: <20080509233440.4b671b6a@solaris> References: <7.0.1.0.0.20080509184428.01d21b28@ntlworld.com> <48249B64.2070003@millstream.com> <23BC7113-91B2-4615-8915-E8F61D2AB8C3@yandex.ru> <20080509233440.4b671b6a@solaris> Message-ID: Oh, you sure? It is less well known that unsafePerformIO is not type safe. For example: test :: IORef [a] test = unsafePerformIO $ newIORef [] main = do writeIORef test [42] bang <- readIORef test print (bang :: [Char]) This program will core dump. This problem with polymorphic references is well known in the ML community, and does not arise with normal monadic use of references. There is no easy way to make it impossible once you use unsafePerformIO. Indeed, it is possible to write coerce :: a -> b with the help of unsafePerformIO. So be careful! That's the reason why "f" has sometimes LESS general type than "\x -> f x" in OCaml. On 10 May 2008, at 01:34, Achim Schneider wrote: > Miguel Mitrofanov wrote: > >>> As I understand it Haskell does not specify an order of evaluation >>> and it would therefore be a mistake to write a program which relies >>> on a particular evaluation order. This is the 'unsafe' aspect of >>> unsafePerformIO. >> >> Hmm... IMHO unsafePerformIO is 'unsafe' because it can lead to type >> errors in runtime. At least, that seems to be much more dangerous. >> > Nope. That'd be unsafeCoerce#, which you never heard of, and I did not > mention it in this post. Go away. This is not the function you are > looking for. > > -- > (c) this sig last receiving data processing entity. Inspect headers > for > past copyright information. All rights reserved. Unauthorised copying, > hiring, renting, public performance and/or broadcasting of this > signature prohibited. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From pjdtech2000 at gmail.com Fri May 9 17:45:29 2008 From: pjdtech2000 at gmail.com (PJ Durai) Date: Fri May 9 17:39:27 2008 Subject: [Haskell-cafe] Seeking advice on best practices with FFI Message-ID: <4f712c6f0805091445k56562fc4n47309c92657c360b@mail.gmail.com> Hello, I am trying to write FFI wrappers for a dynamic library in windows. I would like to get some help in how to go about doing things. For example for this C function, the import and wrapper I came up with are listed below. -- STATUS LNPUBLIC NSFDbOpen (char far *PathName, DBHANDLE far *rethDB); foreign import stdcall "nsfdb.h NSFDbOpen" nsfDbOpen' ::CString -> Ptr CInt -> IO CInt type DbHandle = CInt nsfDbOpen :: String -> IO DbHandle nsfDbOpen dbname = alloca $ \ptr -> do db <- newCString dbname rc <- nsfDbOpen' db ptr handle <- peek ptr if rc /= 0 then error "dbopen failed" else return handle Q: Does that look ok? Is the db <- newCString leaking ? Q: How would I import and call a function with signature like this calling C code: char str1[MAX_PATH]; char str2[MAX_PATH]; GetStringValues( str1, str2); called C function signature is: void GetStringValues( char* s1, char* s2); i.e. how would the haskell import (and the wrapper function) look like in situation like this (where I have to pass preallocated char array to C code and get it filled up)? Appreciate your time. thanks pj From barsoap at web.de Fri May 9 17:46:07 2008 From: barsoap at web.de (Achim Schneider) Date: Fri May 9 17:40:19 2008 Subject: [Haskell-cafe] Re: Order of Evaluation References: <7.0.1.0.0.20080509184428.01d21b28@ntlworld.com> <48249B64.2070003@millstream.com> <23BC7113-91B2-4615-8915-E8F61D2AB8C3@yandex.ru> <20080509233440.4b671b6a@solaris> Message-ID: <20080509234607.3c6ae98c@solaris> Miguel Mitrofanov wrote: > Oh, you sure? > I was, until you wrote that. But then, I am, as I wouldn't use unsafePerformIO together with IORef's, it's giving me the creeps. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. From bulat.ziganshin at gmail.com Fri May 9 17:52:51 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Fri May 9 17:47:36 2008 Subject: [Haskell-cafe] Seeking advice on best practices with FFI In-Reply-To: <4f712c6f0805091445k56562fc4n47309c92657c360b@mail.gmail.com> References: <4f712c6f0805091445k56562fc4n47309c92657c360b@mail.gmail.com> Message-ID: <1645649662.20080510015251@gmail.com> Hello PJ, Saturday, May 10, 2008, 1:45:29 AM, you wrote: > Q: Does that look ok? Is the db <- newCString leaking ? yes. use withCString instead > void GetStringValues( char* s1, char* s2); if this functions fills s1 and s2, use alloca and peekCString one example of (rather generic) wrapper for C functions that accepts string (c_method) and returns string (c_out_method): generalDoWithMethod mType c_action method = do withCString method $ \c_method -> do allocaBytes aMAX_METHOD_STRLEN $ \c_out_method -> do ret <- c_action c_method c_out_method case ret of 0 -> peekCString c_out_method _ -> fail$ "Unsupported "++mType++" method or error in parameters: "++method -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From lennart at augustsson.net Fri May 9 17:55:25 2008 From: lennart at augustsson.net (Lennart Augustsson) Date: Fri May 9 17:49:23 2008 Subject: [Haskell-cafe] Order of Evaluation In-Reply-To: <7.0.1.0.0.20080509184428.01d21b28@ntlworld.com> References: <7.0.1.0.0.20080509184428.01d21b28@ntlworld.com> Message-ID: As others have pointed out, there are many allowed evaluation orders of this expressions. But not only that, how it gets evaluated depends on how you are going to use it. Say that you print it, then you need all 4 elements, but say that it's oly going to be used as an argument to null, then you will evaluate less (probably). Even so, it's instructive to study how the normal order reduction of this expression would proceed under the assumption that all 4 elements will be used. -- Lennart On Fri, May 9, 2008 at 6:52 PM, PR Stanley wrote: > Hi > (take 4 . map (>0)) (f s t) > where > s = 2 : t > t = 3 : s > f = zipWith (-) > What would be the order of evaluation for the above code? How would I > illustrate the evaluation step-by-step? > I'm guessing that the code necessitates lazy evaluation and as such it > starts with take then it applies f which in turn applies s and t and zipWith > until the first element satisfies the predicate in map and This is repeated > 4 times > What does the list think? > Many thanks, > Paul > P.S. I'm not done with induction. I'm just letting it rst for a bit. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080509/c59dfdfd/attachment.htm From lennart at augustsson.net Fri May 9 18:04:26 2008 From: lennart at augustsson.net (Lennart Augustsson) Date: Fri May 9 17:58:26 2008 Subject: [Haskell-cafe] List concat In-Reply-To: <48245CBC.309@btinternet.com> References: <48245CBC.309@btinternet.com> Message-ID: There are many implementations of such things. Data.Sequence is one. You can also make an implementation that has O(1) cons, snoc, and append, but that's rather tricky and has a large constant factor. -- Lennart On Fri, May 9, 2008 at 3:16 PM, Andrew Coppin wrote: > The function (++) :: [x] -> [x] -> [x] has O(n) complexity. > > If somebody were to invent some type that looks like [x] but actually uses > some sort of tree rather than a linked list, you should be able to get O(1) > concatenation. Has anybody ever implemented such a thing? > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080509/17f81e1f/attachment.htm From allbery at ece.cmu.edu Fri May 9 18:08:58 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Fri May 9 18:02:54 2008 Subject: [Haskell-cafe] (Num t) => [t] or [Int] In-Reply-To: <7.0.1.0.0.20080509220113.01d7dd60@ntlworld.com> References: <7.0.1.0.0.20080509220113.01d7dd60@ntlworld.com> Message-ID: On 2008 May 9, at 17:07, PR Stanley wrote: > I thought [1, 2, 3] :: [Int] > GHC says it's (Num t) > [t] > Okay, when it comes to 3.3:[1,2,3] (Num t) => [t] makes more sense. > Is that the only reason? The Haskell 98 standard says that numeric literals are of type Num t => t (so you don't need to fromIntegral everything that looks like an Int but is used with e.g. Doubles). Therefore a list of them is Num t => [t]. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From lennart at augustsson.net Fri May 9 18:13:39 2008 From: lennart at augustsson.net (Lennart Augustsson) Date: Fri May 9 18:07:37 2008 Subject: [Haskell-cafe] Re: Control.Exception.evaluate - 'correct definition' not so correct In-Reply-To: <7ca3f0160805060727n52bbe96fracd3d9a303f61ba3@mail.gmail.com> References: <20080503091917.GA5333@shion.is.fushizen.net> <5ab17e790805041730o33b378e4u74f4f1f9e813e72b@mail.gmail.com> <7ca3f0160805060727n52bbe96fracd3d9a303f61ba3@mail.gmail.com> Message-ID: GHC already ignores the existence of seq, for instance when doing list fusion. The unconstrained seq function just ruins too many things. I say, move seq top a type class (where is used to be), and add an unsafeSeq for people who want to play dangerously. -- Lennart On Tue, May 6, 2008 at 3:27 PM, Luke Palmer wrote: > On Tue, May 6, 2008 at 2:50 AM, apfelmus > wrote: > > Concerning the folklore that seq destroys the monad laws, I would like > > to remark that as long as we don't apply seq to arguments that are > > functions, everything is fine. When seq is applied to functions, > > already simple laws like > > > > f . id = f > > > > are trashed, so it's hardly surprising that the monad laws are broken > > willy-nilly. That's because seq can be used to distinguish between > > > > _|_ :: A -> B and \x -> _|_ :: A -> B > > > > although there shouldn't be a semantic difference between them. > > It seems that there is a culture developing where people intentionally > ignore the existence of seq when reasoning about Haskell. Indeed I've > heard many people argue that it shouldn't be in the language as it is > now, that instead it should be a typeclass. > > I wonder if it's possible for the compiler to do more aggressive > optimizations if it, too, ignored the existence of seq. Would it make > it easier to do various sorts of lambda lifting, and would it make > strictness analysis easier? > > Luke > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080509/55835278/attachment.htm From claus.reinke at talk21.com Fri May 9 14:30:18 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Fri May 9 18:25:27 2008 Subject: [Haskell-cafe] Re: [Haskell] Re: ANN: Haddock version 2.1.0 References: <20080501190625.GB474@localhost><481A46C0.3050209@gmail.com><012e01c8ac61$cc2f0d60$bf078351@cr3lt><4822F24B.4040801@microsoft.com><4824165B.60800@gmail.com> Message-ID: <016401c8b224$6b0b5250$5a307ad5@cr3lt> > Ah, I didn't think about the GHC options that change the lexical > syntax. You're right, using the GHC lexer should be easier. and, if you do that, you could also make the GHC lexer squirrel away the comments (including pragmas, if they aren't already in the AST) someplace safe, indexed by, or at least annotated with, their source locations, and make this comment/ pragma storage available via the GHC API. (1a) then, we'd need a way to merge those comments and pragmas back into the output during pretty printing, and we'd have made the first small step towards source-to-source transformations: making code survive semantically intact over (pretty . parse). (1b) that would still not quite fullfill the GHC API comment ticket (*), but that was only a quick sketch, not a definite design. it might be sufficient to let each GHC API client do its own search to associate bits of comment/pragma storage with bits of AST. if i understand you correctly, you are going to do (1a), so if you could add that to the GHC API, we'd only need (1b) to go from useable-for-analysis-and-extraction to useable-for-transformation. is that going to be a problem? claus (*) knowing the source location of some piece of AST is not sufficient for figuring out whether it has any immediately preceding or following comments (there might be other AST fragments in between, closer to the next comment). but, if one knows the nearest comment segment for each piece of AST, one could then build a map where the closest AST pieces are mapped to (Just commentID), and the other AST pieces are mapped to Nothing. From prstanley at ntlworld.com Fri May 9 18:35:25 2008 From: prstanley at ntlworld.com (PR Stanley) Date: Fri May 9 18:29:23 2008 Subject: [Haskell-cafe] inserting values in a binary tree Message-ID: <7.0.1.0.0.20080509232420.01d95988@ntlworld.com> Hi data Ord a => Tree a = Nil | Node (Tree a) a (Tree a) How would one go about inserting a value in a binary search tree of the above description? Cheers Paul From tom.davie at gmail.com Fri May 9 18:40:29 2008 From: tom.davie at gmail.com (Thomas Davie) Date: Fri May 9 18:34:30 2008 Subject: [Haskell-cafe] inserting values in a binary tree In-Reply-To: <7.0.1.0.0.20080509232420.01d95988@ntlworld.com> References: <7.0.1.0.0.20080509232420.01d95988@ntlworld.com> Message-ID: On 10 May 2008, at 00:35, PR Stanley wrote: > Hi > data Ord a => Tree a = Nil | Node (Tree a) a (Tree a) > How would one go about inserting a value in a binary search tree of > the above description? All you need to do is consider what the trees should look like in the two cases: If I try and insert an item into a completely empty tree, what do I end up with? I'll give you a hint, it has one Node, and 2 Nils. If I have a Node, do I need to insert into the left tree, or the right tree? Take it from there Bob From lennart at augustsson.net Fri May 9 18:43:42 2008 From: lennart at augustsson.net (Lennart Augustsson) Date: Fri May 9 18:37:41 2008 Subject: [Haskell-cafe] inserting values in a binary tree In-Reply-To: <7.0.1.0.0.20080509232420.01d95988@ntlworld.com> References: <7.0.1.0.0.20080509232420.01d95988@ntlworld.com> Message-ID: Are there any invariants you wish to maintain when inserting? If not, it's rather trivial. -- Lennart On Fri, May 9, 2008 at 11:35 PM, PR Stanley wrote: > Hi > data Ord a => Tree a = Nil | Node (Tree a) a (Tree a) > How would one go about inserting a value in a binary search tree of the > above description? > > Cheers > Paul > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080509/35607d10/attachment.htm From barsoap at web.de Fri May 9 18:46:28 2008 From: barsoap at web.de (Achim Schneider) Date: Fri May 9 18:40:37 2008 Subject: [Haskell-cafe] Re: inserting values in a binary tree References: <7.0.1.0.0.20080509232420.01d95988@ntlworld.com> Message-ID: <20080510004628.00a25d11@solaris> PR Stanley wrote: > Hi > data Ord a => Tree a = Nil | Node (Tree a) a (Tree a) > How would one go about inserting a value in a binary search tree of > the above description? > Using a library ;) Inserting isn't the problem, balancing is where things get interesting: have a look at http://en.wikipedia.org/wiki/AVL_tree -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. From prstanley at ntlworld.com Fri May 9 18:55:44 2008 From: prstanley at ntlworld.com (PR Stanley) Date: Fri May 9 18:49:44 2008 Subject: [Haskell-cafe] Re: inserting values in a binary tree In-Reply-To: <20080510004628.00a25d11@solaris> References: <7.0.1.0.0.20080509232420.01d95988@ntlworld.com> <20080510004628.00a25d11@solaris> Message-ID: <7.0.1.0.0.20080509234905.01d8e9d8@ntlworld.com> Actually, you've touched an important point there. It's balancing that I'm having difficulty with. Paul At 23:46 09/05/2008, you wrote: >PR Stanley wrote: > > > Hi > > data Ord a => Tree a = Nil | Node (Tree a) a (Tree a) > > How would one go about inserting a value in a binary search tree of > > the above description? > > >Using a library ;) > >Inserting isn't the problem, balancing is where things get interesting: >have a look at > >http://en.wikipedia.org/wiki/AVL_tree > >-- >(c) this sig last receiving data processing entity. Inspect headers for >past copyright information. All rights reserved. Unauthorised copying, >hiring, renting, public performance and/or broadcasting of this >signature prohibited. > >_______________________________________________ >Haskell-Cafe mailing list >Haskell-Cafe@haskell.org >http://www.haskell.org/mailman/listinfo/haskell-cafe From dons at galois.com Fri May 9 19:10:11 2008 From: dons at galois.com (Don Stewart) Date: Fri May 9 19:04:12 2008 Subject: [Haskell-cafe] [ANN] Twitter Client In-Reply-To: <9155ECD6-A50E-456A-9E2C-F3777007318D@eidhof.nl> References: <9155ECD6-A50E-456A-9E2C-F3777007318D@eidhof.nl> Message-ID: <20080509231011.GB22253@scytale.galois.com> chris: > Hey everyone, > > I was tired of all those graphical Twitter clients that aren't usable > from my Terminal, so I wrote my own. It's still very much alpha, but > comments or improvements are more than welcome. You can install it by > downloading the twitter-package from hackage. > > In order to get it to work, create a file "~/.twitter" with the > contents username:password, and you should be set. > > The source code isn't polished yet, but it makes heavy use of the new > curl, json and xml libraries from Galois, so it might be interesting > to browse the source. Great! Perhaps we could use it as an annotated tutorial for the libs? Put the source on the wiki with comments? -- Don From prstanley at ntlworld.com Fri May 9 19:10:59 2008 From: prstanley at ntlworld.com (PR Stanley) Date: Fri May 9 19:05:02 2008 Subject: [Haskell-cafe] inserting values in a binary tree In-Reply-To: References: <7.0.1.0.0.20080509232420.01d95988@ntlworld.com> Message-ID: <7.0.1.0.0.20080510000542.01d897f0@ntlworld.com> >Are there any invariants you wish to maintain when inserting? If >not, it's rather trivial. Paul: The idea is to find a value in the tree greater than the new value and then placing the new value before it on the tree. duplicates are ignored and if no value greater than he new value is found then it is appended as a new node to the end of the last node checked. in C you'd fiddle with pointers and Bob's your uncle. Here I'm not sure how to piece that tree back together again with the new element after having expanded it recursively. Cheers Paul From bulat.ziganshin at gmail.com Fri May 9 19:27:17 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Fri May 9 19:22:11 2008 Subject: [Haskell-cafe] inserting values in a binary tree In-Reply-To: <7.0.1.0.0.20080510000542.01d897f0@ntlworld.com> References: <7.0.1.0.0.20080509232420.01d95988@ntlworld.com> <7.0.1.0.0.20080510000542.01d897f0@ntlworld.com> Message-ID: <1924256926.20080510032717@gmail.com> Hello PR, Saturday, May 10, 2008, 3:10:59 AM, you wrote: > in C you'd fiddle with pointers and Bob's your uncle. Here I'm not > sure how to piece that tree back together again with the new element > after having expanded it recursively. in Haskell, you just return new tree with element inserted. it's constructed from the two subtrees, where you've inserted element in one of these. and so on recursively: data Tree a = Tree a (Tree a) (Tree a) | EmptyTree insert (Tree x t1 t2) y | x References: <7.0.1.0.0.20080509184428.01d21b28@ntlworld.com> Message-ID: <4824F4C6.8040508@vex.net> Lennart Augustsson wrote: > Even so, it's instructive to study how the normal order reduction of > this expression would proceed under the assumption that all 4 elements > will be used. I think it's useful to try normal order until weak head normal form. Not all steps are shown. Definitions of take, map, zipWith are taken from the Haskell 98 Report. Whenever you see me expanding a parameter, it is because some function's pattern matching forces it. (take 4 . map (>0)) (f s t) take 4 (map (>0) (f s t)) take 4 (map (>0) (zipWith (-) s t)) take 4 (map (>0) (zipWith (-) (2:t) (3:s))) take 4 (map (>0) ( 2-3 : zipWith (-) t s )) take 4 ( 2-3>0 : map (>0) (zipWith (-) t s) ) 2-3>0 : take (4-1) (map (>0) (zipWith (-) t s)) From lane at downstairspeople.org Fri May 9 21:13:54 2008 From: lane at downstairspeople.org (Christopher Lane Hinson) Date: Fri May 9 21:07:51 2008 Subject: [Haskell-cafe] ANN: Roguestar 0.2 Message-ID: website: http://roguestar.downstairspeople.org darcs 2: darcs get --lazy http://www.downstairspeople.org/darcs/roguestar tarball: http://www.downstairspeople.org/roguestar/roguestar-0.2.tar.gz After much delay, I'm happy to announce Roguestar 0.2. Roguestar is a science fiction themed roguelike (turn-based, chessboard-tiled, role playing) game written in Haskell. Roguestar uses OpenGL for graphics. This is still a very early release and several important things don't work. This initial release allows you to play one of six alien races. You begin the game stranded on an alien planet, fighting off an endless hoard of hostile robots. RSAGL, the RogueStar Animation and Graphics Library, includes a domain-specific monad for 3D modelling of arbitrary parametric surfaces, as well as an animation monad and arrow, which is more or less like YAMPA as a stack of arrow transformers. RSAGL was specifically designed for roguestar, but every effort has been made (including the license) to make it accessable to other projects that might benefit from it. Performance is an issue, but there is a lot of low-hanging fruit in this area. Roguestar is released under the Affero General Public License version 3. However, RSAGL uses a permissive license. I would be absolutely thrilled to receive any feedback anyone may have on the design and aesthetics of the game, especially in the form of source code. From vigalchin at gmail.com Sat May 10 00:56:51 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Sat May 10 00:50:48 2008 Subject: [Haskell-cafe] build version problem? Message-ID: <5ae4f2ba0805092156u34bb75f1ne77e0e9c12009253@mail.gmail.com> Hello, I changed the version # in a cabal file and now I get ... runhaskell Setup.hs configure Configuring unix-2.4.0.0... vigalchin@ubuntu:~/FTP/Haskell/unix-2.2.0.0$ runhaskell Setup.hs build Setup.hs: unix.cabal has been changed, please re-configure. Now no matter what I change the version #, e.g. 2.3.0.0, things are not happy. ? Thanks, Vasili -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080509/27bcc195/attachment.htm From donn at avvanta.com Sat May 10 01:21:19 2008 From: donn at avvanta.com (Donn Cave) Date: Sat May 10 01:15:46 2008 Subject: [Haskell-cafe] haskell compiler on NetBSD amd64 Message-ID: <20080509222119.cfe30daa.donn@avvanta.com> So here I am with 64 bit Athlon hardware, running amd64 NetBSD (a.k.a. x86_64), reasonably motivated to compile Haskell. From what I make of the porting instructions, my only hope is to install FreeBSD-amd64 on another partition and download the 6.6.1 ghc for that platform, use it to generate .hc files to build 6.6.1 on NetBSD, and then use 6.6.1 to build 6.8 or whatever the current version may be by the time I get there? -- Donn Cave From vigalchin at gmail.com Sat May 10 01:37:38 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Sat May 10 01:31:34 2008 Subject: [Haskell-cafe] ANN: unix-2.4.0.0 additional POSIX real time support Message-ID: <5ae4f2ba0805092237j4d40cb74i2fb86e25d3f4f149@mail.gmail.com> Hello, Additional POSIX realtime (POSIX 1003.1b) support has been added: 1) MQueue.hsc - POSIX message queues Supported FFI bindings for: - mq_open - mq_close - mq_unlink - mq_getattributes - mq_setattributes - mq_send Not yet supported bindings: - mq_rcv .. still debugging a mysterious problem - mq_notify - will support when asynchronous I/O is implemented 2) RTsched.hsc - real time scheduling Supported bindings for: - sched_yield - sched_get_param - sched_set_param - sched _get_scheduler - sched_set_scheduler - sched_get_priority_min - sched_get_priority_max Unsupported currently: - sched_rr_get_interval - still looking for the TimeSpec data type in order to get "peek" working 3) Files.hsc Added bindings for: - fsync - fdatasync I am new to Haskell but would like to make a lot of contributions to insure Haskell success in the marketplace (of ideas ;^)). I apologize for any glitches and look for feedback. Kind regards, Vasili -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080510/9344cc18/attachment.htm From dons at galois.com Sat May 10 01:58:47 2008 From: dons at galois.com (Don Stewart) Date: Sat May 10 01:52:44 2008 Subject: [Haskell-cafe] ANN: unix-2.4.0.0 additional POSIX real time support In-Reply-To: <5ae4f2ba0805092237j4d40cb74i2fb86e25d3f4f149@mail.gmail.com> References: <5ae4f2ba0805092237j4d40cb74i2fb86e25d3f4f149@mail.gmail.com> Message-ID: <20080510055847.GC24496@scytale.galois.com> vigalchin: > Hello, > > Additional POSIX realtime (POSIX 1003.1b) support has been added: > > 1) MQueue.hsc - POSIX message queues > > Supported FFI bindings for: > > - mq_open > > - mq_close > > - mq_unlink > > - mq_getattributes > > - mq_setattributes > > - mq_send > > Not yet supported bindings: > > - mq_rcv .. still debugging a mysterious problem > > - mq_notify - will support when asynchronous I/O is implemented > > 2) RTsched.hsc - real time scheduling > > Supported bindings for: > > - sched_yield > > - sched_get_param > > - sched_set_param > > - sched _get_scheduler > > - sched_set_scheduler > > - sched_get_priority_min > > - sched_get_priority_max > > Unsupported currently: > > - sched_rr_get_interval - still looking for the TimeSpec data > type in order to get "peek" working > > 3) Files.hsc > > Added bindings for: > > - fsync > > - fdatasync > > I am new to Haskell but would like to make a lot of contributions to > insure Haskell success in the marketplace (of ideas ;^)). I apologize for > any glitches and look for feedback. Very interesting! However... this library is a core package, and maintained by libraries@haskell.org, so you should not release it yourself. Instead, submit your patches to libraries@ for inclusion, following the patch submission guide here: http://haskell.org/haskellwiki/How_to_write_a_Haskell_program Where the patches will be tested on other unix platforms, and then encorporated into the main 'unix' repository. Also, as unix .hsc files tend to be a bit fragile, portability wise, it might be a good idea to instead place your patches in a separate library on hackage, rather than patching the 'unix' package directly. We have many other unix-alike packages, so one for message queues, and real time scheduling make sense -- separate from the core 'unix' package (like the mmap package, for example). -- Don From chris at eidhof.nl Sat May 10 03:01:14 2008 From: chris at eidhof.nl (Chris Eidhof) Date: Sat May 10 02:55:11 2008 Subject: [Haskell-cafe] [ANN] Twitter Client In-Reply-To: <20080509193125.GA14946@localhost> References: <9155ECD6-A50E-456A-9E2C-F3777007318D@eidhof.nl> <20080509193125.GA14946@localhost> Message-ID: On 9 mei 2008, at 21:31, Gwern Branwen wrote: > On 2008.05.09 16:23:03 +0200, Chris Eidhof > scribbled 0.6K characters: >> Hey everyone, >> >> I was tired of all those graphical Twitter clients that aren't >> usable from >> my Terminal, so I wrote my own. It's still very much alpha, but >> comments or >> improvements are more than welcome. You can install it by >> downloading the >> twitter-package from hackage. > > For those interested, the links is >. Hackage reports a build-failure, but I think that particular > problem is because of Curl's Haddock failure. > > That said, I did run into a build problem: > > Is GUI.Terminal some special Mac haskell package I wouldn't have on > Linux? No, I was a bit sloppy with casing of the directory-names. On my Mac it was called Gui, but it should have been called GUI. I uploaded a changed package, it should build fine now. Thanks! -chris From devriese at cs.tcd.ie Sat May 10 04:18:12 2008 From: devriese at cs.tcd.ie (Edsko de Vries) Date: Sat May 10 04:12:10 2008 Subject: [Haskell-cafe] Stack vs Heap allocation In-Reply-To: <20080509110412.262fee0f.Malcolm.Wallace@cs.york.ac.uk> References: <20080508222917.GA22916@netsoc.tcd.ie> <1210287273.5514.46.camel@derek-laptop> <20080509095812.GA2907@netsoc.tcd.ie> <20080509110412.262fee0f.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <20080510081811.GA17212@netsoc.tcd.ie> Hi, > > > (...(((1+2)+3)+4) ... + 10000000) > > > which requires stack in proportion to the number of nested parentheses > > > > Ah, that makes! So does it make sense to talk about "tail recursive > > thunks"? Or does the evaluation of thunks always take stack space > > proportional to the "nesting level"? > > The key reason why nested additions take stack space, is because (+) on > Integers is *strict* in both arguments. If it were somehow non-strict > instead, then the unevaluated parts of the number would be heap-allocated > rather than stack-allocated. I don't understand. Could you elaborate? Thanks, Edsko From toman144 at student.liu.se Sat May 10 05:09:22 2008 From: toman144 at student.liu.se (Tomas Andersson) Date: Sat May 10 05:03:28 2008 Subject: [Haskell-cafe] Re: inserting values in a binary tree In-Reply-To: <7.0.1.0.0.20080509234905.01d8e9d8@ntlworld.com> References: <7.0.1.0.0.20080509232420.01d95988@ntlworld.com> <20080510004628.00a25d11@solaris> <7.0.1.0.0.20080509234905.01d8e9d8@ntlworld.com> Message-ID: <200805101109.22658.toman144@student.liu.se> Den Saturday 10 May 2008 00.55.44 skrev PR Stanley: > Actually, you've touched an important point there. It's balancing > that I'm having difficulty with. > Paul > So what kind of balancing rules does it have to obey? AVL? Red-black? Something else? > At 23:46 09/05/2008, you wrote: > >PR Stanley wrote: > > > Hi > > > data Ord a => Tree a = Nil | Node (Tree a) a (Tree a) > > > How would one go about inserting a value in a binary search tree of > > > the above description? > > > >Using a library ;) > > > >Inserting isn't the problem, balancing is where things get interesting: > >have a look at > > > >http://en.wikipedia.org/wiki/AVL_tree > > > >-- > >(c) this sig last receiving data processing entity. Inspect headers for > >past copyright information. All rights reserved. Unauthorised copying, > >hiring, renting, public performance and/or broadcasting of this > >signature prohibited. > > > >_______________________________________________ > >Haskell-Cafe mailing list > >Haskell-Cafe@haskell.org > >http://www.haskell.org/mailman/listinfo/haskell-cafe > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From emil.skoldberg at nuigalway.ie Sat May 10 05:35:12 2008 From: emil.skoldberg at nuigalway.ie (Emil Skoeldberg) Date: Sat May 10 05:29:19 2008 Subject: [Haskell-cafe] haskell compiler on NetBSD amd64 In-Reply-To: <20080509222119.cfe30daa.donn@avvanta.com> References: <20080509222119.cfe30daa.donn@avvanta.com> Message-ID: <20080510093512.GA27361@matstaff04.nuigalway.ie> On Fri, May 09, 2008 at 10:21:19PM -0700, Donn Cave wrote: > So here I am with 64 bit Athlon hardware, running amd64 > NetBSD (a.k.a. x86_64), reasonably motivated to compile > Haskell. From what I make of the porting instructions, So, we are in the same boat then! > my only hope is to install FreeBSD-amd64 on another > partition and download the 6.6.1 ghc for that platform, > use it to generate .hc files to build 6.6.1 on NetBSD, > and then use 6.6.1 to build 6.8 or whatever the current > version may be by the time I get there? > But what I thought was rather to go with OpenBSD, since I figured that it would be closer to NetBSD (You can e.g. build ghc on OpenBSD using NetBSD-generated .hc files on i386), and generate the .hc files on OpenBSD. I have unfortunately not got any further than getting an openbsd partition though, have not had the time to get into the actual porting. Emil > -- > Donn Cave -- Emil Sk?ldberg From philip.weaver at gmail.com Sat May 10 05:41:17 2008 From: philip.weaver at gmail.com (Philip Weaver) Date: Sat May 10 05:35:12 2008 Subject: [Haskell-cafe] build version problem? In-Reply-To: <5ae4f2ba0805092156u34bb75f1ne77e0e9c12009253@mail.gmail.com> References: <5ae4f2ba0805092156u34bb75f1ne77e0e9c12009253@mail.gmail.com> Message-ID: Ok, I'll ask the obvious question... did you try to re-configure? runhaskell Setup.hs configure 2008/5/9 Galchin, Vasili : > Hello, > > I changed the version # in a cabal file and now I get ... > > runhaskell Setup.hs configure > Configuring unix-2.4.0.0... > vigalchin@ubuntu:~/FTP/Haskell/unix-2.2.0.0$ runhaskell Setup.hs build > Setup.hs: unix.cabal has been changed, please re-configure. > > Now no matter what I change the version #, e.g. 2.3.0.0, things are not > happy. ? > > Thanks, Vasili > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From barsoap at web.de Sat May 10 06:07:43 2008 From: barsoap at web.de (Achim Schneider) Date: Sat May 10 06:01:52 2008 Subject: [Haskell-cafe] Re: inserting values in a binary tree References: <7.0.1.0.0.20080509232420.01d95988@ntlworld.com> <20080510004628.00a25d11@solaris> <7.0.1.0.0.20080509234905.01d8e9d8@ntlworld.com> Message-ID: <20080510120743.4e5ac8d7@solaris> PR Stanley wrote: > Actually, you've touched an important point there. It's balancing > that I'm having difficulty with. > Paul http://en.wikipedia.org/wiki/Tree_rotation is the key to all this: It changes the tree structure without changing the tree ordering. rotr (Node (Node a p b) q c) = Node a p $ Node b q c untested, mind you. > At 23:46 09/05/2008, you wrote: > >PR Stanley wrote: > > > > > Hi > > > data Ord a => Tree a = Nil | Node (Tree a) a (Tree a) > > > How would one go about inserting a value in a binary search tree > > > of the above description? > > > > >Using a library ;) > > > >Inserting isn't the problem, balancing is where things get > >interesting: have a look at > > > >http://en.wikipedia.org/wiki/AVL_tree > > > >-- > >(c) this sig last receiving data processing entity. Inspect headers > >for past copyright information. All rights reserved. Unauthorised > >copying, hiring, renting, public performance and/or broadcasting of > >this signature prohibited. > > > >_______________________________________________ > >Haskell-Cafe mailing list > >Haskell-Cafe@haskell.org > >http://www.haskell.org/mailman/listinfo/haskell-cafe -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. From wss at Cs.Nott.AC.UK Sat May 10 07:17:45 2008 From: wss at Cs.Nott.AC.UK (Wouter Swierstra) Date: Sat May 10 07:11:42 2008 Subject: [Haskell-cafe] Old editions of The Monad.Reader lost In-Reply-To: References: <4E8D36EF-FAAA-4204-85CD-398FAF2822E6@cs.nott.ac.uk> Message-ID: <72FD811C-B6AF-4390-B7E5-E466FE005F7F@Cs.Nott.AC.UK> > Almost all? Is that why some are missing? eg. > omits > "Impure Thoughts 1 - Thtatic Compilathionth (without a lisp) " > . Philippa did not want her articles published under the new license - that's why they haven't been added. Hope this clears things up, Wouter From bf3 at telenet.be Sat May 10 07:30:58 2008 From: bf3 at telenet.be (Peter Verswyvelen) Date: Sat May 10 07:25:00 2008 Subject: [Haskell-cafe] unsafeInterleaveIO and OpenGL In-Reply-To: References: <4824B60A.5040709@telenet.be> Message-ID: <48258771.4000809@telenet.be> > Sounds reasonable. 'unsafeInterleaveIO' defers computation of 'vp' > until it is actually needed. At this time the viewport might have > changed. That sound reasonable indeed, but the viewport does not change and the values I get are really random. I'll try to make minimal example to demonstrate the problem. Thanks, Peter From giorgio_v at mac.com Sat May 10 08:03:26 2008 From: giorgio_v at mac.com (Giorgio Valoti) Date: Sat May 10 07:57:22 2008 Subject: [Haskell-cafe] I am new to haskell In-Reply-To: <775358.40764.qm@web30205.mail.mud.yahoo.com> References: <775358.40764.qm@web30205.mail.mud.yahoo.com> Message-ID: <153D306D-5DC9-43BC-81B0-1F2007AA42E7@mac.com> On 09/mag/08, at 13:59, Benjamin L. Russell wrote: >>> [?] >> >> i recommend you to read papers from the >> http://haskell.org/haskellwiki/Learning_Haskell >> page, in particular those in Advanced tutorials, Monads, >> Type classes, >> Popular libraries sections > > That is one idea. Also, since The Haskell School of Expression (http://www.haskell.org/soe/ > ), by Paul Hudak, is sometimes regarded as easier to read as a > second book on Haskell, you could read that, too. I think I?ll get the book. Thank you for the suggestions! > [?] Ciao -- Giorgio Valoti From andrewcoppin at btinternet.com Sat May 10 08:15:40 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Sat May 10 08:09:27 2008 Subject: [Haskell-cafe] List concat In-Reply-To: References: <48245CBC.309@btinternet.com> Message-ID: <482591EC.8060806@btinternet.com> Lennart Augustsson wrote: > There are many implementations of such things. Data.Sequence is one. > You can also make an implementation that has O(1) cons, snoc, and > append, but that's rather tricky and has a large constant factor. Ah. So not only is it possible, but it's already in a standard library. I had a feeling this might be the case... From ross at soi.city.ac.uk Sat May 10 08:24:53 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Sat May 10 08:18:53 2008 Subject: [Haskell-cafe] List concat In-Reply-To: References: <48245CBC.309@btinternet.com> Message-ID: <20080510122452.GA3684@soi.city.ac.uk> On Fri, May 09, 2008 at 11:04:26PM +0100, Lennart Augustsson wrote: > There are many implementations of such things. Data.Sequence is one. You can > also make an implementation that has O(1) cons, snoc, and append, but that's > rather tricky and has a large constant factor. It's also rather difficult to construct a use case that distinguishes between O(1) and O(log(min(n1,n2))) append. For example, building a sequence with either sort of append takes linear time. The constant factors are everything. From eric.stansifer at gmail.com Sat May 10 08:28:58 2008 From: eric.stansifer at gmail.com (Eric Stansifer) Date: Sat May 10 08:22:53 2008 Subject: [Haskell-cafe] Type unions Message-ID: <2e58fd390805100528q90a85e5h46cc3c24ba142d15@mail.gmail.com> I have been trying to write a DSL for Povray (see www.povray.org) in Haskell, using the technique of: http://okmij.org/ftp/papers/tagless-final-APLAS.pdf with some inspiration taken from http://okmij.org/ftp/Haskell/DSLSharing.hs The Povray Scene Description Language is a very declarative language, with few high level constructs (even loops take a bit of work) -- which is why I'm putting it in Haskell. At one point, I needed a "varargs" function for the DSL, a function f :: b -> a -> b dressed up to take a variable number of 'a's, known at compile time. This was easy enough: > data Nil a = Nil > data Cons b a = a ::: b a > infixr 1 ::: > > class VarArgs v where > apply_args :: (s -> a -> s) -> s -> v a -> s > > instance VarArgs Nil where > apply_args _ start _ = start > > instance VarArgs b => VarArgs (Cons b) where > apply_args f start (a ::: b) = apply_args f (f start a) b The solution is quite workable: I can simply write the following, and I believe the summation is expanded out at compile-time: > apply_args (+) 0 (2 ::: 3 ::: 8 ::: 1 ::: (-3) ::: Nil) But I found I also needed a function to take a union type -- that is, the function would either take an argument of type T1, or of type T2, known at compile time. I tried a similar technique as I tried with varargs, and unfortunately ended up with this: > data LeftOf a b = L a > data RightOf a b = R b > > class Union u where > apply_union :: (a -> c) -> (b -> c) -> (u a b) -> c > > instance Union LeftOf where > apply_union f _ (L a) = f a > > instance Union RightOf where > apply_union _ g (R b) = g b > > type A = Integer > type B = String > type C = () > > type Union_ABC u1 u2 = u1 A (u2 B C) > > f_A = show . (+ 3) > f_B = reverse > f_C = const "unit" > > f :: (Union u1, Union u2) => Union_ABC u1 u2 -> String > f = apply_union f_A (apply_union f_B f_C) > > main = do > putStrLn $ f $ (L 6 :: Union_ABC LeftOne LeftOne) > putStrLn $ f $ R (L "hello, world") > putStrLn $ f $ R (R ()) Notice a lot of ugliness in my example: e.g., the definition of f, the type signature of f (I can't move the context into the type-synonym Union_ABC), creating objects of the union type, and the unpleasant surprise that I needed to provide the type of 'L 6'. This solution is very not-scalable: the Povray SDL is a "messy" language, and for my DSL I would need approximately 20 or 30 such unions, each a union of about 20 types (admittedly with a lot of overlap from union to union). I think the solution is to abandon the lofty ideal of statically determining argument types; instead have a universal type with tags to distinguish types dynamically: > data Universal = UA A | UB B | UC C > f :: Universal -> String > f (UA a) = f_A a > f (UB b) = f_B b > f (UC c) = f_C c > > main2 = do > putStrLn $ f $ UA 6 > putStrLn $ f $ UB "hello, world" > putStrLn $ f $ UC () ...but I'm not ready to give up hope yet. Suggestions please? Eric From andrewcoppin at btinternet.com Sat May 10 08:42:50 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Sat May 10 08:36:38 2008 Subject: [Haskell-cafe] Copy on read Message-ID: <4825984A.4010905@btinternet.com> I just had a random idea, which I thought I'd share with you all. I've heard about systems that do "copy on write". That is, all users share a single copy of some structure, until somebody tries to write on it. At that moment they get a personal copy to modify so they don't upset everybody else. This way, you don't have to go to all the expense of copying a potentially large structure unless it's actually necessary to do so. Then I started thinking about Clean's "uniqueness typing". If I'm understanding this correctly, it lets you do things like mutate data in-place without requiring a monad. The restriction is that the compiler has to be satisfied, at compile-time, that you will never try to access the old data you just overwrote. Although I once held more optimistic beliefs, as far as I can tell no current, real-world Haskell implementation ever mutates the fields of algebraic data types in-place. (Ignoring for a moment the issue of overwriting a thunk with it's result.) This strikes me as rather pessimistic. I was thinking... If Haskell had uniqueness typing, maybe the compiler could be made to infer when values are used in a unique way. And maybe if the compiler can detect data being used in a unique way, it could code for in-place updates instead of copying, and thereby gain a performance advantage. I don't know how viable this would be - the thing that immediately jumps out at me is that in practice there might be comparatively few places where you can *guarantee* the transformation is safe, and so it might not get applied very much. And considering all this would likely take a fair bit of work on the compiler, that wouldn't be a great payoff. Still, the idea of the compiler transparently rewriting your pure functional code to efficient mutable updates (when safe) is very appealing for performance reasons. Thoughts, people? [I'd be surprised if I'm the first person ever to have this idea...] From daniil.elovkov at googlemail.com Sat May 10 08:50:36 2008 From: daniil.elovkov at googlemail.com (Daniil Elovkov) Date: Sat May 10 08:44:34 2008 Subject: [Haskell-cafe] Order of Evaluation In-Reply-To: <7.0.1.0.0.20080509184428.01d21b28@ntlworld.com> References: <7.0.1.0.0.20080509184428.01d21b28@ntlworld.com> Message-ID: <48259A1C.2090202@gmail.com> Hello You may find this paper useful http://research.microsoft.com/~simonpj/Papers/spineless-tagless-gmachine.ps.gz It should give you the general feeling of how things are actually executed. It's quite old, some things in GHC have changed, but the overall scheme, I believe, is the same. The competent people will correct me, if I'm wrong. PR Stanley wrote: > Hi > (take 4 . map (>0)) (f s t) > where > s = 2 : t > t = 3 : s > f = zipWith (-) > What would be the order of evaluation for the above code? How would I > illustrate the evaluation step-by-step? > I'm guessing that the code necessitates lazy evaluation and as such it > starts with take then it applies f which in turn applies s and t and > zipWith until the first element satisfies the predicate in map and This > is repeated 4 times > What does the list think? > Many thanks, > Paul > P.S. I'm not done with induction. I'm just letting it rst for a bit. From lennart at augustsson.net Sat May 10 10:15:10 2008 From: lennart at augustsson.net (Lennart Augustsson) Date: Sat May 10 10:09:07 2008 Subject: [Haskell-cafe] Type unions In-Reply-To: <2e58fd390805100528q90a85e5h46cc3c24ba142d15@mail.gmail.com> References: <2e58fd390805100528q90a85e5h46cc3c24ba142d15@mail.gmail.com> Message-ID: Try making a type class for the functions. That will allow you both varargs and unions. Have a look at Text.Printf. -- Lennart On Sat, May 10, 2008 at 1:28 PM, Eric Stansifer wrote: > I have been trying to write a DSL for Povray (see www.povray.org) in > Haskell, using the technique of: > http://okmij.org/ftp/papers/tagless-final-APLAS.pdf > with some inspiration taken from > http://okmij.org/ftp/Haskell/DSLSharing.hs > > The Povray Scene Description Language is a very declarative language, > with few high level constructs (even loops take a bit of work) -- > which is why I'm putting it in Haskell. > > At one point, I needed a "varargs" function for the DSL, a function f > :: b -> a -> b dressed up to take a variable number of 'a's, known at > compile time. This was easy enough: > > > data Nil a = Nil > > data Cons b a = a ::: b a > > infixr 1 ::: > > > > class VarArgs v where > > apply_args :: (s -> a -> s) -> s -> v a -> s > > > > instance VarArgs Nil where > > apply_args _ start _ = start > > > > instance VarArgs b => VarArgs (Cons b) where > > apply_args f start (a ::: b) = apply_args f (f start a) b > > The solution is quite workable: I can simply write the following, and > I believe the summation is expanded out at compile-time: > > > apply_args (+) 0 (2 ::: 3 ::: 8 ::: 1 ::: (-3) ::: Nil) > > But I found I also needed a function to take a union type -- that is, > the function would either take an argument of type T1, or of type T2, > known at compile time. I tried a similar technique as I tried with > varargs, and unfortunately ended up with this: > > > data LeftOf a b = L a > > data RightOf a b = R b > > > > class Union u where > > apply_union :: (a -> c) -> (b -> c) -> (u a b) -> c > > > > instance Union LeftOf where > > apply_union f _ (L a) = f a > > > > instance Union RightOf where > > apply_union _ g (R b) = g b > > > > type A = Integer > > type B = String > > type C = () > > > > type Union_ABC u1 u2 = u1 A (u2 B C) > > > > f_A = show . (+ 3) > > f_B = reverse > > f_C = const "unit" > > > > f :: (Union u1, Union u2) => Union_ABC u1 u2 -> String > > f = apply_union f_A (apply_union f_B f_C) > > > > main = do > > putStrLn $ f $ (L 6 :: Union_ABC LeftOne LeftOne) > > putStrLn $ f $ R (L "hello, world") > > putStrLn $ f $ R (R ()) > > Notice a lot of ugliness in my example: e.g., the definition of f, > the type signature of f (I can't move the context into the > type-synonym Union_ABC), creating objects of the union type, and the > unpleasant surprise that I needed to provide the type of 'L 6'. This > solution is very not-scalable: the Povray SDL is a "messy" language, > and for my DSL I would need approximately 20 or 30 such unions, each a > union of about 20 types (admittedly with a lot of overlap from union > to union). > > I think the solution is to abandon the lofty ideal of statically > determining argument types; instead have a universal type with tags > to distinguish types dynamically: > > > data Universal = UA A | UB B | UC C > > f :: Universal -> String > > f (UA a) = f_A a > > f (UB b) = f_B b > > f (UC c) = f_C c > > > > main2 = do > > putStrLn $ f $ UA 6 > > putStrLn $ f $ UB "hello, world" > > putStrLn $ f $ UC () > > ...but I'm not ready to give up hope yet. Suggestions please? > > Eric > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080510/222e7918/attachment.htm From ndmitchell at gmail.com Sat May 10 10:20:46 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Sat May 10 10:14:40 2008 Subject: [Haskell-cafe] Copy on read In-Reply-To: <4825984A.4010905@btinternet.com> References: <4825984A.4010905@btinternet.com> Message-ID: <404396ef0805100720vff904c1lac6a5fad44d5cf06@mail.gmail.com> Hi You're not the first: Jurriaan Hage and Stefan Holdermans. Heap recycling for lazy languages. In John Hatcliff, Robert Gl?ck, and Oege de Moor, editors, _Proceedings of the 2008 ACM SIGPLAN Symposium on Partial Evaluation and Semantics-Based Program Manipulation_, PEPM'08, San Francisco, California, USA, January 7--8, 2008, pages 189--197. ACM Press, 2008. http://doi.acm.org/10.1145/1328408.1328436. Like I said to them in private mail - nice idea, but without benchmarks its only an idea. You have to consider effects of cache, generational garbage collection, complexity etc. I think they are going to do the benchmarks at some point, when we'll know if the idea was a good one. Thanks Neil On Sat, May 10, 2008 at 1:42 PM, Andrew Coppin wrote: > I just had a random idea, which I thought I'd share with you all. > > I've heard about systems that do "copy on write". That is, all users share a > single copy of some structure, until somebody tries to write on it. At that > moment they get a personal copy to modify so they don't upset everybody > else. This way, you don't have to go to all the expense of copying a > potentially large structure unless it's actually necessary to do so. > > Then I started thinking about Clean's "uniqueness typing". If I'm > understanding this correctly, it lets you do things like mutate data > in-place without requiring a monad. The restriction is that the compiler has > to be satisfied, at compile-time, that you will never try to access the old > data you just overwrote. > > Although I once held more optimistic beliefs, as far as I can tell no > current, real-world Haskell implementation ever mutates the fields of > algebraic data types in-place. (Ignoring for a moment the issue of > overwriting a thunk with it's result.) This strikes me as rather > pessimistic. I was thinking... If Haskell had uniqueness typing, maybe the > compiler could be made to infer when values are used in a unique way. And > maybe if the compiler can detect data being used in a unique way, it could > code for in-place updates instead of copying, and thereby gain a performance > advantage. > > I don't know how viable this would be - the thing that immediately jumps out > at me is that in practice there might be comparatively few places where you > can *guarantee* the transformation is safe, and so it might not get applied > very much. And considering all this would likely take a fair bit of work on > the compiler, that wouldn't be a great payoff. Still, the idea of the > compiler transparently rewriting your pure functional code to efficient > mutable updates (when safe) is very appealing for performance reasons. > > Thoughts, people? [I'd be surprised if I'm the first person ever to have > this idea...] > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From eric.stansifer at gmail.com Sat May 10 12:26:27 2008 From: eric.stansifer at gmail.com (Eric Stansifer) Date: Sat May 10 12:20:22 2008 Subject: [Haskell-cafe] Type unions In-Reply-To: References: <2e58fd390805100528q90a85e5h46cc3c24ba142d15@mail.gmail.com> Message-ID: <2e58fd390805100926pb68c1a5h2dd201148dde078f@mail.gmail.com> > Try making a type class for the functions. That will allow you both varargs > and unions. > Have a look at Text.Printf. Thank you -- looking at Printf was very helpful. My syntax is much happier as a result. I also see now that I am approaching the problem from the wrong direction -- that by writing a whole slew of functions whose behavior depends arbitrarily upon their argument type, I would need to code the desired behavior for each function and each argument type; getting hung up on making the syntax manageable hid this realization from me. The solution is for me to try much harder to extract common behavior across argument types and only code special cases when truly necessary. Eric From bulat.ziganshin at gmail.com Sat May 10 13:01:12 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sat May 10 12:56:16 2008 Subject: [Haskell-cafe] Type unions In-Reply-To: <2e58fd390805100926pb68c1a5h2dd201148dde078f@mail.gmail.com> References: <2e58fd390805100528q90a85e5h46cc3c24ba142d15@mail.gmail.com> <2e58fd390805100926pb68c1a5h2dd201148dde078f@mail.gmail.com> Message-ID: <1917703804.20080510210112@gmail.com> Hello Eric, Saturday, May 10, 2008, 8:26:27 PM, you wrote: > Thank you -- looking at Printf was very helpful. My syntax is much > happier as a result. btw, i also recommend to look into HsLua[1] which uses type classes in very smart and elegant way to automatically convert between Haskell and Lua data types [1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hslua -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From malcolm.wallace at cs.york.ac.uk Sat May 10 13:31:48 2008 From: malcolm.wallace at cs.york.ac.uk (Malcolm Wallace) Date: Sat May 10 13:25:44 2008 Subject: [Haskell-cafe] Copy on read In-Reply-To: <4825984A.4010905@btinternet.com> References: <4825984A.4010905@btinternet.com> Message-ID: > If Haskell had uniqueness typing, maybe the compiler could be made > to infer when values are used in a unique way. And maybe if the > compiler can detect data being used in a unique way, it could code > for in-place updates instead of copying, and thereby gain a > performance advantage. Uniqueness typing does not lead to in-place update. If a value is only used once, then there is no need to update it at all! In fact, I believe ghc does this analysis, and has a minor optimisation that omits the thunk-update. That is, if an unevaluated thunk is forced, but it has a unique usage, the original thunk is not overwritten with an indirection to the reduced value (as it normally would be), but the reduced value is just used directly. I believe that rather than _uniqueness_, you are really trying to describe _linear_ usage, that is, multiple uses, but in a single non- branching sequence. Single-threaded usage of a data structure might permit in-place modification of its parts. The analysis for linear usage is much more difficult than for uniqueness, and David Wakeling's PhD Thesis "Linearity and Laziness" (circa 1990) did some experiments, but was ultimately pessimistic about the value. Regards, Malcolm From gwern0 at gmail.com Sat May 10 14:09:33 2008 From: gwern0 at gmail.com (Gwern Branwen) Date: Sat May 10 14:04:04 2008 Subject: [Haskell-cafe] Old editions of The Monad.Reader lost In-Reply-To: <72FD811C-B6AF-4390-B7E5-E466FE005F7F@Cs.Nott.AC.UK> References: <4E8D36EF-FAAA-4204-85CD-398FAF2822E6@cs.nott.ac.uk> <72FD811C-B6AF-4390-B7E5-E466FE005F7F@Cs.Nott.AC.UK> Message-ID: <20080510180933.GA13359@localhost> On 2008.05.10 12:17:45 +0100, Wouter Swierstra scribbled 0.4K characters: >> Almost all? Is that why some are missing? eg. >> omits >> "Impure Thoughts 1 - Thtatic Compilathionth (without a lisp) " >> . > > Philippa did not want her articles published under the new license - that's > why they haven't been added. Hope this clears things up, > > Wouter I see; that was what I thought, but there was no note explicitly saying so. I'll go add them. -- gwern SRI d DIA Tangimoana ssor IDP Pesec VIP Schengen timers -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080510/2b35f2ba/attachment.bin From dons at galois.com Sat May 10 15:13:16 2008 From: dons at galois.com (Don Stewart) Date: Sat May 10 15:07:13 2008 Subject: [Haskell-cafe] haskell compiler on NetBSD amd64 In-Reply-To: <20080510093512.GA27361@matstaff04.nuigalway.ie> References: <20080509222119.cfe30daa.donn@avvanta.com> <20080510093512.GA27361@matstaff04.nuigalway.ie> Message-ID: <20080510191316.GD32478@scytale.galois.com> emil.skoldberg: > On Fri, May 09, 2008 at 10:21:19PM -0700, Donn Cave wrote: > > So here I am with 64 bit Athlon hardware, running amd64 > > NetBSD (a.k.a. x86_64), reasonably motivated to compile > > Haskell. From what I make of the porting instructions, > > So, we are in the same boat then! > > > my only hope is to install FreeBSD-amd64 on another > > partition and download the 6.6.1 ghc for that platform, > > use it to generate .hc files to build 6.6.1 on NetBSD, > > and then use 6.6.1 to build 6.8 or whatever the current > > version may be by the time I get there? > > > > But what I thought was rather to go with OpenBSD, since I > figured that it would be closer to NetBSD (You can e.g. build > ghc on OpenBSD using NetBSD-generated .hc files on i386), > and generate the .hc files on OpenBSD. I have unfortunately > not got any further than getting an openbsd partition though, > have not had the time to get into the actual porting. I wonder if it is still possible to use the .hc files already generated for the OpenBSD/amd64 port, and use those to do the port to NetBSD/amd64. http://www.openbsd.org/cgi-bin/cvsweb/ports/lang/ghc/ Actually, with headers starting to diverge, it might make more sense to just generate the amd64/netbsd .hc files from i386/netbsd -- where there's already a working ghc. -- Don From kili at outback.escape.de Sat May 10 15:39:14 2008 From: kili at outback.escape.de (Matthias Kilian) Date: Sat May 10 15:34:05 2008 Subject: [Haskell-cafe] haskell compiler on NetBSD amd64 In-Reply-To: <20080510191316.GD32478@scytale.galois.com> References: <20080509222119.cfe30daa.donn@avvanta.com> <20080510093512.GA27361@matstaff04.nuigalway.ie> <20080510191316.GD32478@scytale.galois.com> Message-ID: <20080510193913.GA8931@petunia.outback.escape.de> On Sat, May 10, 2008 at 12:13:16PM -0700, Don Stewart wrote: > I wonder if it is still possible to use the .hc files already generated > for the OpenBSD/amd64 port, and use those to do the port to > NetBSD/amd64. > > http://www.openbsd.org/cgi-bin/cvsweb/ports/lang/ghc/ If nobody tries, we'll never know. Ciao, Kili -- > Do with this info and this argument what u will - as u always do. Delete it. -- Jeffrey Lim and Theo de Raadt in "The famous t-shirt thread" From vigalchin at gmail.com Sat May 10 16:47:52 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Sat May 10 16:41:47 2008 Subject: [Haskell-cafe] seeking advice on my POSIX wrapper Message-ID: <5ae4f2ba0805101347s3a41630cg7265892c37a143d2@mail.gmail.com> Hello, Last night I sent out an announcement about some POSIX work that I have been doing. In any case, one of the FFI wrappers is driving me crazy, i.e. the one for mq_receive: http://opengroup.org/onlinepubs/007908799/xsh/mq_receive.html . When I call this function (mqReceive), I get "message too long". In my test cases I am sending and receiving messages that are only 11 bytes! The wrapper seems really straightforward. Perhaps I am looking right at the problem and don't see. I need other eyes on the wrapper to help me ;^). Please see below. Regards, V. ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- -- mqReceive is still being debugged!!!!!!!!!! -- | Retrieve a message from mqueue designated by "mqd" -- mqReceive :: Fd -> ByteCount -> Maybe Int -> IO (String, Int) mqReceive (Fd mqd) len (Just prio) = do allocaBytes (fromIntegral len) $ \ p_buffer -> do with (fromIntegral prio) $ \ p_prio -> do rc <- throwErrnoIfMinus1 "mqReceive" (c_mq_receive mqd p_buffer (fromIntegral len) p_prio) case fromIntegral rc of 0 -> ioError (IOError Nothing EOF "mqReceive" "EOF" Nothing) n -> do s <- peekCStringLen (p_buffer, fromIntegral n) return (s, n) mqReceive (Fd mqd) len Nothing = do allocaBytes (fromIntegral len) $ \ p_buffer -> do rc <- throwErrnoIfMinus1 "mqReceive" (c_mq_receive mqd p_buffer (fromIntegral len) nullPtr) case fromIntegral rc of 0 -> ioError (IOError Nothing EOF "mqReceive" "EOF" Nothing) n -> do s <- peekCStringLen (p_buffer, fromIntegral n) return (s, n) foreign import ccall unsafe "mqueue.h mq_receive" c_mq_receive :: CInt -> Ptr CChar -> CSize -> Ptr CInt -> IO CInt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080510/a74a19a2/attachment.htm From bulat.ziganshin at gmail.com Sat May 10 17:03:51 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sat May 10 16:59:16 2008 Subject: [Haskell-cafe] seeking advice on my POSIX wrapper In-Reply-To: <5ae4f2ba0805101347s3a41630cg7265892c37a143d2@mail.gmail.com> References: <5ae4f2ba0805101347s3a41630cg7265892c37a143d2@mail.gmail.com> Message-ID: <444685627.20080511010351@gmail.com> Hello Vasili, Sunday, May 11, 2008, 12:47:52 AM, you wrote: > . When I call this function (mqReceive), I get "message too long". you can divide-and-conquer the problem by trying 1) write the C code that calls mq_receive with the same params 2) call your own function instead of mq_receive and printf parameters it receives -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From allbery at ece.cmu.edu Sat May 10 17:09:01 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sat May 10 17:02:56 2008 Subject: [Haskell-cafe] seeking advice on my POSIX wrapper In-Reply-To: <5ae4f2ba0805101347s3a41630cg7265892c37a143d2@mail.gmail.com> References: <5ae4f2ba0805101347s3a41630cg7265892c37a143d2@mail.gmail.com> Message-ID: <8A1FD2D5-A2DF-4A37-BD62-04551C8B0934@ece.cmu.edu> On 2008 May 10, at 16:47, Galchin, Vasili wrote: > Last night I sent out an announcement about some POSIX work > that I have been doing. In any case, one of the FFI wrappers is > driving me crazy, i.e. the one for mq_receive:http://opengroup.org/onlinepubs/007908799/xsh/mq_receive.html > . When I call this function (mqReceive), I get "message too long". > In my test cases I am sending and receiving messages that are only > 11 bytes! The wrapper seems really straightforward. Perhaps I am > looking right at the problem and don't see. I need other eyes on the > wrapper to help me ;^). Please see below. What's the other end sending? I suspect most implementations of mq_receive() layer it on top of msgrcv(), which can return E2BIG (== EMSGSIZE) if the message to be received is larger than the receiving buffer --- a condition which I note mq_receive() does not document (unless mq_msgsize means a given queue only supports fixed size messages, which seems odd). -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080510/37a7ae15/attachment.htm From donn at avvanta.com Sat May 10 17:36:43 2008 From: donn at avvanta.com (Donn Cave) Date: Sat May 10 17:31:06 2008 Subject: [Haskell-cafe] haskell compiler on NetBSD amd64 In-Reply-To: <20080510191316.GD32478@scytale.galois.com> References: <20080509222119.cfe30daa.donn@avvanta.com> <20080510093512.GA27361@matstaff04.nuigalway.ie> <20080510191316.GD32478@scytale.galois.com> Message-ID: <20080510143643.51eacc56.donn@avvanta.com> On Sat, 10 May 2008 12:13:16 -0700 Don Stewart wrote: > I wonder if it is still possible to use the .hc files already generated > for the OpenBSD/amd64 port, and use those to do the port to > NetBSD/amd64. > > http://www.openbsd.org/cgi-bin/cvsweb/ports/lang/ghc/ That sounds fine to me, if I understand you right - I managed to install an OpenBSD partition this afternoon, but if I can skip that step, that's fine with me. I don't see any .hc files at that link, though. > Actually, with headers starting to diverge, it might make more sense to > just generate the amd64/netbsd .hc files from i386/netbsd -- where > there's already a working ghc. I have ghc 6.4.1 on NetBSD 3.0 i386. That's the idea, right? as apparently 6.8 is known to not build from .hc files. I don't understand `with headers starting to diverge'. Donn Cave, donn@avvanta.com -- Donn Cave From kili at outback.escape.de Sat May 10 17:59:18 2008 From: kili at outback.escape.de (Matthias Kilian) Date: Sat May 10 17:54:06 2008 Subject: [Haskell-cafe] haskell compiler on NetBSD amd64 In-Reply-To: <20080510143643.51eacc56.donn@avvanta.com> References: <20080509222119.cfe30daa.donn@avvanta.com> <20080510093512.GA27361@matstaff04.nuigalway.ie> <20080510191316.GD32478@scytale.galois.com> <20080510143643.51eacc56.donn@avvanta.com> Message-ID: <20080510215917.GA28142@petunia.outback.escape.de> On Sat, May 10, 2008 at 02:36:43PM -0700, Donn Cave wrote: > > I wonder if it is still possible to use the .hc files already generated > > for the OpenBSD/amd64 port, and use those to do the port to > > NetBSD/amd64. > > > > http://www.openbsd.org/cgi-bin/cvsweb/ports/lang/ghc/ > > That sounds fine to me, if I understand you right - I managed > to install an OpenBSD partition this afternoon, but if I can > skip that step, that's fine with me. I don't see any .hc files > at that link, though. Here you go: http://openbsd.dead-parrot.de/distfiles/ghc-6.6.1-amd64-unknown-openbsd-hc.tar.bz2 I've to admit that the ghc port for OpenBSD is a little bit weird ;-) (but not as weird as my current work on ghc-6.8 for OpenBSD) > > Actually, with headers starting to diverge, it might make more sense to > > just generate the amd64/netbsd .hc files from i386/netbsd -- where > > there's already a working ghc. > > I have ghc 6.4.1 on NetBSD 3.0 i386. That's the idea, right? If possible, start with ghc 6.6.1, even if that means to install a newer version of NetBSD. > as apparently 6.8 is known to not build from .hc files. I don't > understand `with headers starting to diverge'. Nor do I, but I guess Don meant significant differences in system libraries (between NetBSD and OpenBSD). Ciao, Kili -- Weg mit dieser verfluchten Demokratie wo alles das Wort f?hren will. -- Georg Christoph Lichtenberg From dons at galois.com Sat May 10 18:03:39 2008 From: dons at galois.com (Don Stewart) Date: Sat May 10 17:57:34 2008 Subject: [Haskell-cafe] haskell compiler on NetBSD amd64 In-Reply-To: <20080510215917.GA28142@petunia.outback.escape.de> References: <20080509222119.cfe30daa.donn@avvanta.com> <20080510093512.GA27361@matstaff04.nuigalway.ie> <20080510191316.GD32478@scytale.galois.com> <20080510143643.51eacc56.donn@avvanta.com> <20080510215917.GA28142@petunia.outback.escape.de> Message-ID: <20080510220339.GB3427@scytale.galois.com> kili: > http://openbsd.dead-parrot.de/distfiles/ghc-6.6.1-amd64-unknown-openbsd-hc.tar.bz2 > > I've to admit that the ghc port for OpenBSD is a little bit weird ;-) > > (but not as weird as my current work on ghc-6.8 for OpenBSD) What's your plan for the OpenBSD port, Kili? > > as apparently 6.8 is known to not build from .hc files. I don't > > understand `with headers starting to diverge'. > > Nor do I, but I guess Don meant significant differences in system > libraries (between NetBSD and OpenBSD). That's what I meant. When you take the .hc files from OpenBSD to NetBSD, there's going to be some breakages in the C layer. So better to do the x86 -> amd64 port, staying on NetBSD, I think. -- Don From prstanley at ntlworld.com Sat May 10 18:36:36 2008 From: prstanley at ntlworld.com (PR Stanley) Date: Sat May 10 18:30:47 2008 Subject: [Haskell-cafe] Maybe a, The Rationale Message-ID: <7.0.1.0.0.20080510233243.01d44f90@ntlworld.com> Hi folks data Maybe a = Nothing | Just a What is the underlying rationale for the Maybe data type? is it the safe style of programming it encourages/ Something tells me this is going to start a lengthy discussion. :-) Cheers, Paul From tom.davie at gmail.com Sat May 10 18:49:04 2008 From: tom.davie at gmail.com (Thomas Davie) Date: Sat May 10 18:43:01 2008 Subject: [Haskell-cafe] Maybe a, The Rationale In-Reply-To: <7.0.1.0.0.20080510233243.01d44f90@ntlworld.com> References: <7.0.1.0.0.20080510233243.01d44f90@ntlworld.com> Message-ID: <8D962D9A-55B0-4812-AD9C-04022F20BAD7@gmail.com> On 11 May 2008, at 00:36, PR Stanley wrote: > Hi folks > > data Maybe a = Nothing | Just a > > What is the underlying rationale for the Maybe data type? is it the > safe style of programming it encourages/ > Something tells me this is going to start a lengthy discussion. :-) Pure and simple -- it allows you to represent partial functions. Looking up a map will only sometimes find a value, so we either return Nothing, or Just that value. Bob From prstanley at ntlworld.com Sat May 10 18:56:48 2008 From: prstanley at ntlworld.com (PR Stanley) Date: Sat May 10 18:50:46 2008 Subject: [Haskell-cafe] Maybe a, The Rationale In-Reply-To: <8D962D9A-55B0-4812-AD9C-04022F20BAD7@gmail.com> References: <7.0.1.0.0.20080510233243.01d44f90@ntlworld.com> <8D962D9A-55B0-4812-AD9C-04022F20BAD7@gmail.com> Message-ID: <7.0.1.0.0.20080510235343.01d87e78@ntlworld.com> >> Paul: Hi folks >> >> data Maybe a = Nothing | Just a >> >> What is the underlying rationale for the Maybe data type? >> is it the >>safe style of programming it encourages/ >>Something tells me this is going to start a lengthy discussion. :-) > > Bob: Pure and simple -- it allows you to represent partial > functions. >Looking up a map will only sometimes find a value, so we either return >Nothing, or Just that value. Paul: Would yu like to demonstrate this in an example? Cheers, Paul From philip.weaver at gmail.com Sat May 10 19:02:53 2008 From: philip.weaver at gmail.com (Philip Weaver) Date: Sat May 10 18:56:47 2008 Subject: [Haskell-cafe] Maybe a, The Rationale In-Reply-To: <7.0.1.0.0.20080510235343.01d87e78@ntlworld.com> References: <7.0.1.0.0.20080510233243.01d44f90@ntlworld.com> <8D962D9A-55B0-4812-AD9C-04022F20BAD7@gmail.com> <7.0.1.0.0.20080510235343.01d87e78@ntlworld.com> Message-ID: On Sat, May 10, 2008 at 3:56 PM, PR Stanley wrote: > >>> Paul: Hi folks >>> >>> data Maybe a = Nothing | Just a >>> >>> What is the underlying rationale for the Maybe data type? is it >>> the >>> safe style of programming it encourages/ >>> Something tells me this is going to start a lengthy discussion. :-) >> >> Bob: Pure and simple -- it allows you to represent partial >> functions. Here's one simple example that popped into my head... maybeHead :: [a] -> Maybe a maybeHead [] = Nothing maybeHead (x:xs) = Just x >> Looking up a map will only sometimes find a value, so we either return >> Nothing, or Just that value. > > Paul: Would yu like to demonstrate this in an example? > See the 'lookup' function ( http://haskell.org/ghc/docs/latest/html/libraries/base/Data-List.html#v%3Alookup ) or just abut any other function on Hoogle that uses a Maybe type. > Cheers, Paul > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From allbery at ece.cmu.edu Sat May 10 19:04:11 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sat May 10 18:58:05 2008 Subject: [Haskell-cafe] Maybe a, The Rationale In-Reply-To: <7.0.1.0.0.20080510235343.01d87e78@ntlworld.com> References: <7.0.1.0.0.20080510233243.01d44f90@ntlworld.com> <8D962D9A-55B0-4812-AD9C-04022F20BAD7@gmail.com> <7.0.1.0.0.20080510235343.01d87e78@ntlworld.com> Message-ID: <10A0ADA6-6D6A-41D7-8686-C7E73385805D@ece.cmu.edu> On 2008 May 10, at 18:56, PR Stanley wrote: > >>> Paul: Hi folks >>> >>> data Maybe a = Nothing | Just a >>> >>> What is the underlying rationale for the Maybe data type? >>> is it the >>> safe style of programming it encourages/ >>> Something tells me this is going to start a lengthy discussion. :-) >> >> Bob: Pure and simple -- it allows you to represent partial >> functions. >> Looking up a map will only sometimes find a value, so we either >> return >> Nothing, or Just that value. > > Paul: Would yu like to demonstrate this in an example? Um, I was encountering and recognizing times when I really needed an out-of-band "null", and the pain of representing such in C, shortly after I started serious programming in C (call it 1984-5). Is this really difficult? -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From prstanley at ntlworld.com Sat May 10 19:10:45 2008 From: prstanley at ntlworld.com (PR Stanley) Date: Sat May 10 19:04:45 2008 Subject: [Haskell-cafe] Maybe a, The Rationale In-Reply-To: <10A0ADA6-6D6A-41D7-8686-C7E73385805D@ece.cmu.edu> References: <7.0.1.0.0.20080510233243.01d44f90@ntlworld.com> <8D962D9A-55B0-4812-AD9C-04022F20BAD7@gmail.com> <7.0.1.0.0.20080510235343.01d87e78@ntlworld.com> <10A0ADA6-6D6A-41D7-8686-C7E73385805D@ece.cmu.edu> Message-ID: <7.0.1.0.0.20080511000738.01d9cc40@ntlworld.com> >>>> Paul: Hi folks >>>> >>>> data Maybe a = Nothing | Just a >>>> >>>> What is the underlying rationale for the Maybe data type? >>>>is it the >>>>safe style of programming it encourages/ >>>>Something tells me this is going to start a lengthy discussion. :-) >>> >>> Bob: Pure and simple -- it allows you to represent partial >>>functions. >>>Looking up a map will only sometimes find a value, so we either >>>return >>>Nothing, or Just that value. >> >> Paul: Would yu like to demonstrate this in an example? > > >Um, I was encountering and recognizing times when I really needed an >out-of-band "null", and the pain of representing such in C, shortly >after I started serious programming in C (call it 1984-5). Is this >really difficult? Paul: Hmm, I'm not quite sure what you're driving at. Cheers, Paul From vigalchin at gmail.com Sat May 10 19:50:20 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Sat May 10 19:44:15 2008 Subject: [Haskell-cafe] seeking advice on my POSIX wrapper In-Reply-To: <8A1FD2D5-A2DF-4A37-BD62-04551C8B0934@ece.cmu.edu> References: <5ae4f2ba0805101347s3a41630cg7265892c37a143d2@mail.gmail.com> <8A1FD2D5-A2DF-4A37-BD62-04551C8B0934@ece.cmu.edu> Message-ID: <5ae4f2ba0805101650k7f62acc9q73868bdbe40d1120@mail.gmail.com> sender ...... main = do fd <- mqOpen "/myipc" ReadWrite (Just nullFileMode) (Just (MQAttributes 0 128 128 0)) mqSend fd "Hello world" 11 1 (MQAttributes flags maxMsgNum maxMsgSize curNumMsgs) <- mqGetAttributes fd putStrLn ("attrs flags->" ++ (show flags) ++ " maxMsgNum -> " ++ (show maxMsgNum) ++ " maxMsgSize -> " ++ (show maxMsgSize) ++ " curNumMsgs -> " ++ (show curNumMsgs)) mqClose fd return fd ~ ----------------------------------------- receiver main = do fd <- mqOpen "/myipc" ReadWrite (Just nullFileMode) (Just (MQAttributes 0 128 128 0)) (MQAttributes flags maxMsgNum maxMsgSize curNumMsgs) <- mqGetAttributes fd putStrLn ("attrs flags->" ++ (show flags) ++ " maxMsgNum -> " ++ (show maxMsgNum) ++ " maxMsgSize -> " ++ (show maxMsgSize) ++ " curNumMsgs -> " ++ (show curNumMsgs)) (MQAttributes flags maxMsgNum maxMsgSize curNumMsgs) <- mqSetAttributes fd (MQAttributes{flags=0, maxMsgNum=127, maxMsgSize=127, curNumMsgs=7}) putStrLn ("attrs flags->" ++ (show flags) ++ " maxMsgNum -> " ++ (show maxMsgNum) ++ " maxMsgSize -> " ++ (show maxMsgSize) ++ " curNumMsgs -> " ++ (show curNumMsgs)) (s, n) <- mqReceive fd 60 Nothing putStrLn ("dump " ++ s) (s, n) <- mqReceive fd 11 (Just 1) putStrLn s mqClose fd -- mqUnlink "/myipc" return fd ~ --------------------------------------------------------------------------------------------------------------------------------------------- Thanks, Vasili On Sat, May 10, 2008 at 4:09 PM, Brandon S. Allbery KF8NH < allbery@ece.cmu.edu> wrote: > > On 2008 May 10, at 16:47, Galchin, Vasili wrote: > > Last night I sent out an announcement about some POSIX work that I > have been doing. In any case, one of the FFI wrappers is driving me crazy, > i.e. the one for mq_receive: > http://opengroup.org/onlinepubs/007908799/xsh/mq_receive.html . When I > call this function (mqReceive), I get "message too long". In my test cases I > am sending and receiving messages that are only 11 bytes! The wrapper seems > really straightforward. Perhaps I am looking right at the problem and don't > see. I need other eyes on the wrapper to help me ;^). Please see below. > > > What's the other end sending? > > I suspect most implementations of mq_receive() layer it on top of msgrcv(), > which can return E2BIG (== EMSGSIZE) if the message to be received is larger > than the receiving buffer --- a condition which I note mq_receive() does not > document (unless mq_msgsize means a given queue only supports fixed size > messages, which seems odd). > > -- > brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com > system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu > electrical and computer engineering, carnegie mellon university KF8NH > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080510/0abc05d1/attachment.htm From vigalchin at gmail.com Sat May 10 19:57:06 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Sat May 10 19:51:00 2008 Subject: [Haskell-cafe] seeking advice on my POSIX wrapper In-Reply-To: <8A1FD2D5-A2DF-4A37-BD62-04551C8B0934@ece.cmu.edu> References: <5ae4f2ba0805101347s3a41630cg7265892c37a143d2@mail.gmail.com> <8A1FD2D5-A2DF-4A37-BD62-04551C8B0934@ece.cmu.edu> Message-ID: <5ae4f2ba0805101657h7cfb1889qf328cc45dd1357d9@mail.gmail.com> The Linux version of mqueue that I am using is implemented as a Linux filesystem. I am reading now, Brandon. V. On Sat, May 10, 2008 at 4:09 PM, Brandon S. Allbery KF8NH < allbery@ece.cmu.edu> wrote: > > On 2008 May 10, at 16:47, Galchin, Vasili wrote: > > Last night I sent out an announcement about some POSIX work that I > have been doing. In any case, one of the FFI wrappers is driving me crazy, > i.e. the one for mq_receive: > http://opengroup.org/onlinepubs/007908799/xsh/mq_receive.html . When I > call this function (mqReceive), I get "message too long". In my test cases I > am sending and receiving messages that are only 11 bytes! The wrapper seems > really straightforward. Perhaps I am looking right at the problem and don't > see. I need other eyes on the wrapper to help me ;^). Please see below. > > > What's the other end sending? > > I suspect most implementations of mq_receive() layer it on top of msgrcv(), > which can return E2BIG (== EMSGSIZE) if the message to be received is larger > than the receiving buffer --- a condition which I note mq_receive() does not > document (unless mq_msgsize means a given queue only supports fixed size > messages, which seems odd). > > -- > brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com > system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu > electrical and computer engineering, carnegie mellon university KF8NH > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080510/7c061e57/attachment.htm From philip.weaver at gmail.com Sat May 10 20:41:58 2008 From: philip.weaver at gmail.com (Philip Weaver) Date: Sat May 10 20:35:52 2008 Subject: [Haskell-cafe] Maybe a, The Rationale In-Reply-To: <7.0.1.0.0.20080511000738.01d9cc40@ntlworld.com> References: <7.0.1.0.0.20080510233243.01d44f90@ntlworld.com> <8D962D9A-55B0-4812-AD9C-04022F20BAD7@gmail.com> <7.0.1.0.0.20080510235343.01d87e78@ntlworld.com> <10A0ADA6-6D6A-41D7-8686-C7E73385805D@ece.cmu.edu> <7.0.1.0.0.20080511000738.01d9cc40@ntlworld.com> Message-ID: On Sat, May 10, 2008 at 3:10 PM, PR Stanley wrote: > >>>>> Paul: Hi folks >>>>> >>>>> data Maybe a = Nothing | Just a >>>>> >>>>> What is the underlying rationale for the Maybe data type? >>>>> is it the >>>>> safe style of programming it encourages/ >>>>> Something tells me this is going to start a lengthy discussion. :-) >>>> >>>> Bob: Pure and simple -- it allows you to represent partial >>>> functions. >>>> Looking up a map will only sometimes find a value, so we either >>>> return >>>> Nothing, or Just that value. >>> >>> Paul: Would yu like to demonstrate this in an example? >> >> >> Um, I was encountering and recognizing times when I really needed an >> out-of-band "null", and the pain of representing such in C, shortly >> after I started serious programming in C (call it 1984-5). Is this >> really difficult? > > > Paul: Hmm, I'm not quite sure what you're driving at. > Me neither. > Cheers, Paul > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From sebastian.sylvan at gmail.com Sat May 10 21:03:56 2008 From: sebastian.sylvan at gmail.com (Sebastian Sylvan) Date: Sat May 10 20:57:52 2008 Subject: [Haskell-cafe] Maybe a, The Rationale In-Reply-To: <7.0.1.0.0.20080510233243.01d44f90@ntlworld.com> References: <7.0.1.0.0.20080510233243.01d44f90@ntlworld.com> Message-ID: <3d96ac180805101803x6bc72123k4d63cd2c49005ae6@mail.gmail.com> On Sat, May 10, 2008 at 11:36 PM, PR Stanley wrote: > Hi folks > > data Maybe a = Nothing | Just a > > What is the underlying rationale for the Maybe data type? is it the > safe style of programming it encourages/ > Something tells me this is going to start a lengthy discussion. :-) > Cheers, Paul > > Sometimes you want to express things that can either be a value, or nothing. In some languages all or most "values" (using that term loosely) can be "nullable". E.g. in C# any reference can be nullable, so you can just return null to signify "no value" (e.g. when looking someting up in a dictionary). The problem with this is that every single dereference can no potentially cause a runtime error, which pushes a whole lot of problems to the runtime, when they really could be statically eliminated at compile time. Most functions, after all, really do need all their parameters to "exist" and aren't defined for null, and they really do return a result and never null, so it's useful to know for sure that a "Map Int String" really is a map, and not "null", while you still have the ability to deal with "optional" values in the tiny minority of cases that need it. Also, since it's impossible to actualy use a value without inspecting the constructors of Maybe, you avoid even more runtime errors (unless you use things like "fromJust"). IME "nullable by default" is one of the biggest sources of runtime crashes in high level OOP languages like C#, which is a shame because it really isn't that difficult to statically eliminate the vast majority of them, especially when you're sort of hand-waving the semantics of your language anyway and don't require it to be super rigorous... -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080511/6afd56c5/attachment.htm From allbery at ece.cmu.edu Sat May 10 21:27:53 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sat May 10 21:21:47 2008 Subject: [Haskell-cafe] Maybe a, The Rationale In-Reply-To: References: <7.0.1.0.0.20080510233243.01d44f90@ntlworld.com> <8D962D9A-55B0-4812-AD9C-04022F20BAD7@gmail.com> <7.0.1.0.0.20080510235343.01d87e78@ntlworld.com> <10A0ADA6-6D6A-41D7-8686-C7E73385805D@ece.cmu.edu> <7.0.1.0.0.20080511000738.01d9cc40@ntlworld.com> Message-ID: <3AEBDC06-AC4C-4B6D-8B5C-2A02CB394A98@ece.cmu.edu> On 2008 May 10, at 20:41, Philip Weaver wrote: > On Sat, May 10, 2008 at 3:10 PM, PR Stanley > wrote: >>> >>> Um, I was encountering and recognizing times when I really needed an >>> out-of-band "null", and the pain of representing such in C, shortly >>> after I started serious programming in C (call it 1984-5). Is this >>> really difficult? >> >> >> Paul: Hmm, I'm not quite sure what you're driving at. >> > Me neither. Null pointers, EOF markers, didn't find specified key in some tree, etc. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From stansife at caltech.edu Sat May 10 21:59:32 2008 From: stansife at caltech.edu (Eric Stansifer) Date: Sat May 10 21:53:26 2008 Subject: [Haskell-cafe] Maybe a, The Rationale In-Reply-To: <3d96ac180805101803x6bc72123k4d63cd2c49005ae6@mail.gmail.com> References: <7.0.1.0.0.20080510233243.01d44f90@ntlworld.com> <3d96ac180805101803x6bc72123k4d63cd2c49005ae6@mail.gmail.com> Message-ID: <2e58fd390805101859u693ab1f6s693f00d08b6bdf4a@mail.gmail.com> > IME "nullable by default" is one of the biggest > sources of runtime crashes in high level OOP languages like C#, which is a > shame because it really isn't that difficult to statically eliminate the > vast majority of them, especially when you're sort of hand-waving the > semantics of your language anyway and don't require it to be super > rigorous... I definitely agree. After I'd been learning Haskell for 6 months and then wrote a program in Java & C++, almost the first thing I did was code up a generic Maybe class in each language. It is so much clearer and more obvious to _explicitly_ have no value (Maybe.Nothing()) as opposed to _implicitly_ having no value (null). Now I find my Java & C++ Maybe class indispensable when I am programming in those languages. Eric From zao at acc.umu.se Sat May 10 22:24:38 2008 From: zao at acc.umu.se (Lars Viklund) Date: Sat May 10 22:18:46 2008 Subject: [Haskell-cafe] Maybe a, The Rationale In-Reply-To: <2e58fd390805101859u693ab1f6s693f00d08b6bdf4a@mail.gmail.com> References: <7.0.1.0.0.20080510233243.01d44f90@ntlworld.com> <3d96ac180805101803x6bc72123k4d63cd2c49005ae6@mail.gmail.com> <2e58fd390805101859u693ab1f6s693f00d08b6bdf4a@mail.gmail.com> Message-ID: <20080511022438.GD4930@shaka.acc.umu.se> On Sun, May 11, 2008 at 02:59:32AM +0100, Eric Stansifer wrote: > I definitely agree. After I'd been learning Haskell for 6 months and > then wrote a program in Java & C++, almost the first thing I did was > code up a generic Maybe class in each language. It is so much > clearer and more obvious to _explicitly_ have no value > (Maybe.Nothing()) as opposed to _implicitly_ having no value (null). > Now I find my Java & C++ Maybe class indispensable when I am > programming in those languages. You may want to take a peek at the Boost.Optional [1] library in C++, which provides a lovely Maybe-like class template called "optional". [1] http://www.boost.org/doc/libs/1_35_0/libs/optional/doc/html/index.html -- Lars Viklund | zao@acc.umu.se | 070-310 47 07 From ketil at malde.org Sun May 11 05:01:33 2008 From: ketil at malde.org (Ketil Malde) Date: Sun May 11 04:55:11 2008 Subject: [Haskell-cafe] Maybe a, The Rationale In-Reply-To: <7.0.1.0.0.20080510233243.01d44f90@ntlworld.com> (PR Stanley's message of "Sat\, 10 May 2008 23\:36\:36 +0100") References: <7.0.1.0.0.20080510233243.01d44f90@ntlworld.com> Message-ID: <878wyh5i4y.fsf@nmd9999.imr.no> PR Stanley writes: > What is the underlying rationale for the Maybe data type? It is the equivalent of a database field that can be NULL. > is it the safe style of programming it encourages/ Yes. Consider C, where this is typically done with a NULL pointer, or Lisp, where you use the empty list, nil. These are perfectly good values in themselves, while Nothing is just Nothing, if you pardon the pun. -k -- If I haven't seen further, it is by standing in the footprints of giants From prstanley at ntlworld.com Sun May 11 05:09:19 2008 From: prstanley at ntlworld.com (PR Stanley) Date: Sun May 11 05:03:12 2008 Subject: [Haskell-cafe] Maybe a, The Rationale In-Reply-To: <3AEBDC06-AC4C-4B6D-8B5C-2A02CB394A98@ece.cmu.edu> References: <7.0.1.0.0.20080510233243.01d44f90@ntlworld.com> <8D962D9A-55B0-4812-AD9C-04022F20BAD7@gmail.com> <7.0.1.0.0.20080510235343.01d87e78@ntlworld.com> <10A0ADA6-6D6A-41D7-8686-C7E73385805D@ece.cmu.edu> <7.0.1.0.0.20080511000738.01d9cc40@ntlworld.com> <3AEBDC06-AC4C-4B6D-8B5C-2A02CB394A98@ece.cmu.edu> Message-ID: <7.0.1.0.0.20080511100047.01d2afe0@ntlworld.com> >>>> Um, I was encountering and recognizing times when I >>>> really needed an >>>>out-of-band "null", and the pain of representing such in C, shortly >>>>after I started serious programming in C (call it 1984-5). Is this >>>>really difficult? >>> >>> >>> Paul: Hmm, I'm not quite sure what you're driving at. >>Me neither. > >Null pointers, EOF markers, didn't find specified key in some tree, etc. Paul: So much time is wasted on making the thing work even if you have perfectly sound semantics. Still, that's a hundred times more preferable to c++ and its anomalies and contradictions. What was Stroustroup thinking of! :- Cheers, Paul From chaddai.fouche at gmail.com Sun May 11 05:21:52 2008 From: chaddai.fouche at gmail.com (=?ISO-8859-1?Q?Chadda=EF_Fouch=E9?=) Date: Sun May 11 05:15:44 2008 Subject: [Haskell-cafe] Stack vs Heap allocation In-Reply-To: <20080510081811.GA17212@netsoc.tcd.ie> References: <20080508222917.GA22916@netsoc.tcd.ie> <1210287273.5514.46.camel@derek-laptop> <20080509095812.GA2907@netsoc.tcd.ie> <20080509110412.262fee0f.Malcolm.Wallace@cs.york.ac.uk> <20080510081811.GA17212@netsoc.tcd.ie> Message-ID: 2008/5/10 Edsko de Vries : >> The key reason why nested additions take stack space, is because (+) on >> Integers is *strict* in both arguments. If it were somehow non-strict >> instead, then the unevaluated parts of the number would be heap-allocated >> rather than stack-allocated. > > I don't understand. Could you elaborate? > The key problem here is not that a huge thunk is built : it is allocated on the heap. But when it is forced, the fact that (+) is strict means that all the calls of (+) that had been created must go on the stack... So in the example of "fold (+) 0 [long list]", the problem is not in the evaluation of foldl which only build a big thunk (with a tail recursion), the problem intervene when you must evaluate the big thunk since then you need to stack all the (+)... If (+) was lazy it wouldn't be a problem since you would only need to call one (+) to get a value (which will go in the heap). -- Jeda? From lrpalmer at gmail.com Sun May 11 05:24:04 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Sun May 11 05:17:57 2008 Subject: [Haskell-cafe] Re: Order of Evaluation In-Reply-To: <20080509234607.3c6ae98c@solaris> References: <7.0.1.0.0.20080509184428.01d21b28@ntlworld.com> <48249B64.2070003@millstream.com> <23BC7113-91B2-4615-8915-E8F61D2AB8C3@yandex.ru> <20080509233440.4b671b6a@solaris> <20080509234607.3c6ae98c@solaris> Message-ID: <7ca3f0160805110224i7619f7dfw7dd416aa66cb6a90@mail.gmail.com> On Fri, May 9, 2008 at 3:46 PM, Achim Schneider wrote: > Miguel Mitrofanov wrote: > > > Oh, you sure? > > > I was, until you wrote that. But then, I am, as I wouldn't use > unsafePerformIO together with IORef's, it's giving me the creeps. So.. what do you use unsafePerformIO together with? In uses where I'm not just debugging stuff, I _usually_ use it with IORefs, for more complex caching behavior than I can get out of the language. Luke From r.kelsall at millstream.com Sun May 11 05:28:50 2008 From: r.kelsall at millstream.com (Richard Kelsall) Date: Sun May 11 05:22:43 2008 Subject: [Haskell-cafe] Order of Evaluation In-Reply-To: <23BC7113-91B2-4615-8915-E8F61D2AB8C3@yandex.ru> References: <7.0.1.0.0.20080509184428.01d21b28@ntlworld.com> <48249B64.2070003@millstream.com> <23BC7113-91B2-4615-8915-E8F61D2AB8C3@yandex.ru> Message-ID: <4826BC52.5060302@millstream.com> Miguel Mitrofanov wrote: >> As I understand it Haskell does not specify an order of evaluation >> and it would therefore be a mistake to write a program which relies >> on a particular evaluation order. This is the 'unsafe' aspect of >> unsafePerformIO. > > Hmm... IMHO unsafePerformIO is 'unsafe' because it can lead to type > errors in runtime. At least, that seems to be much more dangerous. > Oh yes, quite right. This and especially the wicked unsafeCoerce seem like great ways to shoot myself in the foot and are strong candidates for inclusion in entries to the International Obfuscated Haskell competition :) http://www.haskell.org/pipermail/haskell/2004-August/014387.html http://www.haskell.org/haskellwiki/Obfuscation Richard. From kili at outback.escape.de Sun May 11 06:08:17 2008 From: kili at outback.escape.de (Matthias Kilian) Date: Sun May 11 06:03:56 2008 Subject: [Haskell-cafe] haskell compiler on NetBSD amd64 In-Reply-To: <20080510220339.GB3427@scytale.galois.com> References: <20080509222119.cfe30daa.donn@avvanta.com> <20080510093512.GA27361@matstaff04.nuigalway.ie> <20080510191316.GD32478@scytale.galois.com> <20080510143643.51eacc56.donn@avvanta.com> <20080510215917.GA28142@petunia.outback.escape.de> <20080510220339.GB3427@scytale.galois.com> Message-ID: <20080511100817.GA15749@petunia.outback.escape.de> On Sat, May 10, 2008 at 03:03:39PM -0700, Don Stewart wrote: > > I've to admit that the ghc port for OpenBSD is a little bit weird ;-) > > > > (but not as weird as my current work on ghc-6.8 for OpenBSD) > > What's your plan for the OpenBSD port, Kili? * Proper bootstrapping from .hc files. * Think about a better way to build the libraries; I understand why the GHC developers do it using the makefiles generated by Cabal, but I'd really prefer something less intrusive (i.e. let Cabal generate only some makefile snippets with dependencies, special flags etc. and include those snippets from a "classical" Makefile that fits better into the good old fptools framework). * Port it to more archs (arm, powerpc, maybe alpha and vax, and, if I'll ever be at that point, to everything else, at least unregisterised). * Omit as many core libraries as possible from the build, and make separate ports for them. * Improve ghc.port.mk to make ports of "standard" stuff on hackage more simple. Currently all GHC-depending ports are a real mess, for example xmonad: http://www.openbsd.org/cgi-bin/cvsweb/ports/x11/xmonad/ With the new ghc.port.mk, all the do-something targets will vanish, and the xmonad Makefile will just contain a line like MODGHC_BUILD= cabal hackage haddock register which means: use Cabal (Setup.hs or Setup.lhs), fetch sources from hackage, use haddock to build the documentation, create register/unregister scripts that update package.conf on installation/deinstallation. Ciao, Kili From bulat.ziganshin at gmail.com Sun May 11 06:12:44 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sun May 11 06:15:58 2008 Subject: [Haskell-cafe] Re: Order of Evaluation In-Reply-To: <7ca3f0160805110224i7619f7dfw7dd416aa66cb6a90@mail.gmail.com> References: <7.0.1.0.0.20080509184428.01d21b28@ntlworld.com> <48249B64.2070003@millstream.com> <23BC7113-91B2-4615-8915-E8F61D2AB8C3@yandex.ru> <20080509233440.4b671b6a@solaris> <20080509234607.3c6ae98c@solaris> <7ca3f0160805110224i7619f7dfw7dd416aa66cb6a90@mail.gmail.com> Message-ID: <1562982984.20080511141244@gmail.com> Hello Luke, Sunday, May 11, 2008, 1:24:04 PM, you wrote: > So.. what do you use unsafePerformIO together with? when i call function that in general case depends on the execution order (so it's type is ...->IO x), but in my specific case it doesn't matter. typical example is hGetContents on config file, GetSystemInfo just to get number of processors, string processing via C functions -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From lrpalmer at gmail.com Sun May 11 06:25:07 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Sun May 11 06:18:59 2008 Subject: [Haskell-cafe] Newbie Question: Using Haskell Functions in a C Program In-Reply-To: <4823882D.2070804@philip.in-aachen.net> References: <48237C05.6000708@philip.in-aachen.net> <4823882D.2070804@philip.in-aachen.net> Message-ID: <7ca3f0160805110325o1439be20w5849c4526e5b21f8@mail.gmail.com> On Thu, May 8, 2008 at 5:09 PM, Philip M?ller wrote: > Thanks for all the answers. I'm testing this right now and simples cases > work as expected. However from what I've read it seems it'll get ugly once I > try to pass a C array to a Haskell function. > > Well, maybe arrays in C have been ugly before trying to pass them to > Haskell functions ;) > > To elaborate a bit about the C program, it's a small game using OpenGL for > output and mouse and keyboard for input. The SDL package (http://hackage.haskell.org/cgi-bin/hackage-scripts/package/SDL) is quite nice for input handling and window making and whatnot. I have heard it is a bitch to get working on Windows, though. The OpenGL package (http://hackage.haskell.org/cgi-bin/hackage-scripts/package/OpenGL) is good, but can be a real pain to get going because the documentation layout is terrible. To toot my own horn, if your graphics are simple enough (specifically, 2D), you can use graphics-drawingcombinators (http://hackage.haskell.org/cgi-bin/hackage-scripts/package/graphics-drawingcombinators), which has a simple interface, for output. It depends on SDL, so above caveat applies. But once you learn the pattern, I/O is basically a transliteration from C. The reason I struggle with such C-like libraries in Haskell is that I spend all my time trying to clean them up and make them more Haskell-like. I definitely consider FFI more of a pain (when you want to do anything sophisticated) than the OpenGL package, though. Luke From amarquaye.ivan at hotmail.com Sun May 11 07:36:04 2008 From: amarquaye.ivan at hotmail.com (Ivan Amarquaye) Date: Sun May 11 07:29:57 2008 Subject: [Haskell-cafe] Error: Improperly terminated character constant Message-ID: I'm writing a function dRop to accept words ending in 'es' and drop the last two characters i.e. 'es'.eg. mangoes -> mongo but i keep on getting this error: "Improperly terminated character constant" after running this code which i have left below. Can i get any form of help from anyone in here...? ----------------------------------------- dRop :: String -> String dRop word = if drop (length word - 2) word == 'es' then take (length word - 2) word else word -------------------------------------------------- regards Amarquaye.Ivan _________________________________________________________________ Connect to the next generation of MSN Messenger? http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source=wlmailtagline -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080511/72a0b308/attachment.htm From johannes.laire at gmail.com Sun May 11 07:46:37 2008 From: johannes.laire at gmail.com (Johannes Laire) Date: Sun May 11 07:40:28 2008 Subject: [Haskell-cafe] Error: Improperly terminated character constant In-Reply-To: References: Message-ID: <5f271a760805110446q31c7076as74f601a77d7e2098@mail.gmail.com> Single quotes are for characters, double quotes are for strings. So change 'es' to "es". -- Johannes Laire 2008/5/11 Ivan Amarquaye : > > > I'm writing a function dRop to accept words ending in 'es' and drop the last > two characters i.e. 'es'.eg. mangoes -> mongo but i keep on getting this > error: "Improperly terminated character constant" after running this code > which i have left below. Can i get any form of help from anyone in here...? > > > ----------------------------------------- > > dRop :: String -> String > dRop word = if drop (length word - 2) word == 'es' > then take (length word - 2) word > else word > > -------------------------------------------------- > > regards > > > > Amarquaye.Ivan > ________________________________ > Connect to the next generation of MSN Messenger Get it now! > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From GK at ninebynine.org Sun May 11 06:04:40 2008 From: GK at ninebynine.org (Graham Klyne) Date: Sun May 11 08:00:04 2008 Subject: Cryptographic hash uniquness (was [Haskell-cafe] Simple network client) In-Reply-To: References: Message-ID: <4826C4B8.2000303@ninebynine.org> This is a very late response ... but I did some calculations as part of some work I did a while ago: http://www.ietf.org/rfc/rfc2938.txt (See appendix A "The birthday paradox") #g -- Peter Verswyvelen wrote: >> winds up having a write cache, which is mutable in practice. The >> interesting thing is that the block's location is the cryptographic >> hash of its contents, which leads to all sorts of neat properties (as >> well as requiring immutability). > > That's interesting. When I developed a version control system for a customer, I also used a cryptographic hash as the database key of file+content in question, but I was afraid I might have clashes (two files with different content generating the same hash)... My intuition told me that the odds of two cryptographic hashes (on meaningful content) colliding was much less than the earth being destroyed by an asteroid... But this is just intuition... What does computer science tell us about this? > > Thank you, > Peter -- Graham Klyne Contact info: http://www.ninebynine.org/#Contact From r.kelsall at millstream.com Sun May 11 09:15:30 2008 From: r.kelsall at millstream.com (Richard Kelsall) Date: Sun May 11 09:09:23 2008 Subject: Cryptographic hash uniquness (was [Haskell-cafe] Simple network client) In-Reply-To: <4826C4B8.2000303@ninebynine.org> References: <4826C4B8.2000303@ninebynine.org> Message-ID: <4826F172.6030207@millstream.com> Graham Klyne wrote: > This is a very late response ... but I did some calculations as part of > some work I did a while ago: > http://www.ietf.org/rfc/rfc2938.txt > (See appendix A "The birthday paradox") > > #g A memorable summary of the birthday paradox being : There is a 50% chance of a collision when number of digits in your population size reaches half the number of digits in the largest possible population. e.g. With a 128 bit hash you get a 50% chance of a collision when you've hashed 2^64 files etc. Richard. From allbery at ece.cmu.edu Sun May 11 09:52:40 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sun May 11 09:46:32 2008 Subject: [Haskell-cafe] Maybe a, The Rationale In-Reply-To: <7.0.1.0.0.20080511100047.01d2afe0@ntlworld.com> References: <7.0.1.0.0.20080510233243.01d44f90@ntlworld.com> <8D962D9A-55B0-4812-AD9C-04022F20BAD7@gmail.com> <7.0.1.0.0.20080510235343.01d87e78@ntlworld.com> <10A0ADA6-6D6A-41D7-8686-C7E73385805D@ece.cmu.edu> <7.0.1.0.0.20080511000738.01d9cc40@ntlworld.com> <3AEBDC06-AC4C-4B6D-8B5C-2A02CB394A98@ece.cmu.edu> <7.0.1.0.0.20080511100047.01d2afe0@ntlworld.com> Message-ID: <6466A9A7-44E9-4A88-84C5-D54E65B0D8FA@ece.cmu.edu> On 2008 May 11, at 5:09, PR Stanley wrote: >>>>> Um, I was encountering and recognizing times when I >>>>> really needed an >>>>> out-of-band "null", and the pain of representing such in C, >>>>> shortly >>>>> after I started serious programming in C (call it 1984-5). Is >>>>> this >>>>> really difficult? >>>> >>>> >>>> Paul: Hmm, I'm not quite sure what you're driving at. >>> Me neither. >> >> Null pointers, EOF markers, didn't find specified key in some tree, >> etc. > > Paul: So much time is wasted on making the thing work even if > you have perfectly sound semantics. Still, that's a hundred times > more preferable to c++ and its anomalies and contradictions. What > was Stroustroup thinking of! :- My real point was that in the C programming culture it was/is far too common to use an in-band value; that is, one that could be confused with or treated as a valid response: null pointers, stdio's EOF (= -1). This just causes problems because code is almost encouraged to ignore the special cases. For example, the ctype macros have to support being passed EOF. Maybe types force you to deal with it, while simultaneously providing convenience functions to help you deal with it. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From mfn-haskell-cafe at cs.york.ac.uk Sun May 11 11:02:12 2008 From: mfn-haskell-cafe at cs.york.ac.uk (Matthew Naylor) Date: Sun May 11 10:59:56 2008 Subject: [Haskell-cafe] Copy on read In-Reply-To: References: <4825984A.4010905@btinternet.com> Message-ID: <20080511150212.GA4049@pc149.staff.cs.york.ac.uk> > Uniqueness typing does not lead to in-place update. If a value is > only used once, then there is no need to update it at all! my understanding is that if a value is uniquely-typed then it is statically known never to have more than one reference, thus it can be modified in-place. Some potential advantages seem to be: * Less heap is used, reducing the strain on the garbage collector. * Memory writes can sometimes be avoided. Imagine changing the value of a leaf in a large unique tree. Only one memory write is required rather than N, where N is the length of the path to that leaf from the root. Such paths can obviously be quite long when working with lists. Also, the cost of rebuilding constructors with many fields -- only to change a single field -- could be expensive. I wonder to what extent deforestation supersedes such optimisations. This would be a good topic to raise with a Cleaner. The paper Neil mentions looks like a nice alternative to uniqueness typing -- and it appears that there will be a FitA talk about it, this Thursday. Matt. From wchogg at gmail.com Sun May 11 11:35:46 2008 From: wchogg at gmail.com (Creighton Hogg) Date: Sun May 11 11:29:38 2008 Subject: [Haskell-cafe] Re: Couple of formal questions In-Reply-To: References: <814617240804292014td3d79f9ve9f0e2345b851e2@mail.gmail.com> <9729FF97-57A8-4B58-8447-4B78FFCEEE6B@cs.nott.ac.uk> Message-ID: <814617240805110835i317e89e6h94ba3a7b01310481@mail.gmail.com> On Mon, May 5, 2008 at 9:53 AM, Wouter Swierstra wrote: > > On 1 May 2008, at 16:58, Michael Karcher wrote: > > Wouter Swierstra wrote: > > > > > Hi Creighton, > > > > > > > Where could I find a proof that the initial algebras & final > > > > coalgebras of CPO coincide? I saw this referenced in the > > > > "Bananas.." paper as a fact, but am not sure where this comes from. > > > > > > > I couldn't find the statement you are referring to in "Functional > > > Programming with Bananas, Lenses, Envelopes, and Barbed Wire" - but > > > I'm not sure if this holds for every CPO. > > > > > > > Probably he was referring to the last paragraph of the introduction: > > > > Working in CPO has the advantage that the carriers of intial algebras > > and final co-algebras coincide, thus there is a single data type that > > comprises both finite and infinite elements. > > > > Ah - thanks for pointing that out. According to my more categorically > inclined office mates, Marcelo Fiore's thesis is a good reference: > > https://www.lfcs.inf.ed.ac.uk/reports/94/ECS-LFCS-94-307/ > > Hope that answers your question, > > Wouter > I've had a lot of good reading material from this thread, and I greatly appreciate it: As a more background reading on this, I think Meijer & Fokkinga's "Program Calculation Properties of Continuous Algebras" is good, though the notation is a little idiosyncratic. http://citeseer.ist.psu.edu/717129.html I've also liked Baez et al's Rosetta Stone paper as food for thought http://math.ucr.edu/home/baez/rosetta.pdf Creighton Hogg -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080511/cc0175d9/attachment.htm From amarquaye.ivan at hotmail.com Sun May 11 11:47:00 2008 From: amarquaye.ivan at hotmail.com (Ivan Amarquaye) Date: Sun May 11 11:40:53 2008 Subject: [Haskell-cafe] dropping hyphens and \n in words Message-ID: Generally a hyphen is written at the end of the sentance when moving on to the next line and i managed to achieve this in haskell by using the "\n"- newline which places an index word in the next line i.e. if the words appear indexed like this...([1]),[mangoes] and a hyphen is applied, it becomes ([1],[mang-oes]) and it is valid in my function as i made it accept hyphens as part of a single word. Now my problem is this...I'm assuming that the hyphen normally comes at the end of a sentence like this: "there are so many guys ravis-hing our women" and this can be demonstrated in haskell by "\n" which places the words or characters following it in a new line like this: input: makeIndex"there are so many guys ravis\nhing our women" and output is: (([1],[there]),([1],[ravis]),([2],[hing])) where 1 means the first line and 2 the next. Now i want to write a function that would take away the hyphen and \n from all the words supposed to end on the first line and continue on the next and make all appear on the first line like this: all words in this form: "chip-\nheater" should become "chipheater". hope i can get some guidance on doing this. _________________________________________________________________ Connect to the next generation of MSN Messenger? http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source=wlmailtagline -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080511/1dbfaf2b/attachment.htm From allbery at ece.cmu.edu Sun May 11 12:20:35 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sun May 11 12:14:28 2008 Subject: [Haskell-cafe] dropping hyphens and \n in words In-Reply-To: References: Message-ID: <584E6D55-90E8-45E0-97C6-7CB36E1182CF@ece.cmu.edu> On 2008 May 11, at 11:47, Ivan Amarquaye wrote: > Now my problem is this...I'm assuming that the hyphen normally comes > at the end of a sentence like this: "there are so many guys ravis- > hing our women" and this can be demonstrated in haskell by "\n" > which places the words or characters following it in a new line like > this: > input: makeIndex"there are so many guys ravis\nhing our women" and > output is: (([1],[there]),([1],[ravis]),([2],[hing])) where 1 means > the first line and 2 the next. Somewhat unrelated point: breaking between "s" and "h" would be peculiar for English because they're components of a digraph. > Now i want to write a function that would take away the hyphen and > \n from all the words supposed to end on the first line and > continue on the next and make all appear on the first line like > this: all words in this form: "chip-\nheater" should become > "chipheater". hope i can get some guidance on doing this. Is this homework? http://haskell.org/haskellwiki/Homework_help Hint: \n may look funny, but it is a character like any other and can be used in pattern matching. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080511/f52c9fc8/attachment-0001.htm From gwern0 at gmail.com Sun May 11 13:01:17 2008 From: gwern0 at gmail.com (Gwern Branwen) Date: Sun May 11 12:57:38 2008 Subject: [Haskell-cafe] ANN: xmonad-utils 0.1 Message-ID: <20080511170117.GA11090@localhost> Just dropping in a quick note: I've uploaded to Hackage the 0.1 release of xmonad-utils here: . There is of course a Darcs repo available as well: . What is xmonad-utils? It's a couple of small Xlib programs which might be useful for Xmonaders. In particular: * hxsel can replace xclip, and was the foundation for the XMonad.Util.XSelection module in XMonadContrib/; it gets a copy of the copy-paste buffer to manipulate * hhp is a replacement for unclutter, the famous utility which hides your mouse when not in use and so cleans up your screen (but which is also famously unmaintained and buggy). I've personally found hhp to be very helpful, so I packaged it all up. Miscellaneous notes: * There is also a 'heval' program, which tries to provide an X prompt to a GHC eval through the GHC API, but that may or may not work for you (it doesn't compile for me, but I'm fairly sure that's because my 'directory' package is b0rked in an unrelated manner). * There is a requirement on cabal >= 1.4; this was needed because older Cabals didn't properly include in the sdist tarball one of the .hsc files. I don't believe it's actually needed to build. -- gwern nuclear Monarch NSADS Scud foundation World or Kilo SADMS M-x -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080511/8c03dd51/attachment.bin From barsoap at web.de Sun May 11 13:58:57 2008 From: barsoap at web.de (Achim Schneider) Date: Sun May 11 13:52:58 2008 Subject: [Haskell-cafe] Re: dropping hyphens and \n in words References: Message-ID: <20080511195857.7a009941@solaris> Ivan Amarquaye wrote: > > Generally a hyphen is written at the end of the sentance when moving > on to the next line and i managed to achieve this in haskell by using > the "\n"- newline which places an index word in the next line i.e. if > the words appear indexed like this...([1]),[mangoes] and a hyphen is > applied, it becomes ([1],[mang-oes]) and it is valid in my function > as i made it accept hyphens as part of a single word. Now my problem > is this...I'm assuming that the hyphen normally comes at the end of a > sentence like this: "there are so many guys ravis-hing our women" and > this can be demonstrated in haskell by "\n" which places the words or > characters following it in a new line like this: input: > makeIndex"there are so many guys ravis\nhing our women" and output > is: (([1],[there]),([1],[ravis]),([2],[hing])) where 1 means the > first line and 2 the next. Now i want to write a function that would > take away the hyphen and \n from all the words supposed to end on > the first line and continue on the next and make all appear on the > first line like this: all words in this form: "chip-\nheater" should > become "chipheater". hope i can get some guidance on doing this. > Excuse my bluntness, but I utterly fail to make sense of this. Reformulating your understanding of it would surely be beneficial. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. From dons at galois.com Sun May 11 14:31:16 2008 From: dons at galois.com (Don Stewart) Date: Sun May 11 14:25:09 2008 Subject: [Haskell-cafe] haskell compiler on NetBSD amd64 In-Reply-To: <20080511100817.GA15749@petunia.outback.escape.de> References: <20080509222119.cfe30daa.donn@avvanta.com> <20080510093512.GA27361@matstaff04.nuigalway.ie> <20080510191316.GD32478@scytale.galois.com> <20080510143643.51eacc56.donn@avvanta.com> <20080510215917.GA28142@petunia.outback.escape.de> <20080510220339.GB3427@scytale.galois.com> <20080511100817.GA15749@petunia.outback.escape.de> Message-ID: <20080511183116.GA12360@scytale.galois.com> kili: > On Sat, May 10, 2008 at 03:03:39PM -0700, Don Stewart wrote: > > > I've to admit that the ghc port for OpenBSD is a little bit weird ;-) > > > > > > (but not as weird as my current work on ghc-6.8 for OpenBSD) > > > > What's your plan for the OpenBSD port, Kili? > > * Proper bootstrapping from .hc files. > > * Think about a better way to build the libraries; I understand why the > GHC developers do it using the makefiles generated by Cabal, but I'd > really prefer something less intrusive (i.e. let Cabal generate only > some makefile snippets with dependencies, special flags etc. and > include those snippets from a "classical" Makefile that fits better > into the good old fptools framework). > > * Port it to more archs (arm, powerpc, maybe alpha and vax, and, if I'll > ever be at that point, to everything else, at least unregisterised). The debian port is inspiring in this regard. E.g. xmonad is available for: alpha, amd64, arm, hppa, i386, ia64, mips, mipsel, s390, sparc http://packages.debian.org/sid/xmonad > * Omit as many core libraries as possible from the build, and make > separate ports for them. So in 6.8.2 only those actually required to build ghc should be in the core. > * Improve ghc.port.mk to make ports of "standard" stuff on hackage > more simple. Currently all GHC-depending ports are a real mess, for > example xmonad: > http://www.openbsd.org/cgi-bin/cvsweb/ports/x11/xmonad/ > With the new ghc.port.mk, all the do-something targets will vanish, > and the xmonad Makefile will just contain a line like > > MODGHC_BUILD= cabal hackage haddock register > > which means: use Cabal (Setup.hs or Setup.lhs), fetch sources > from hackage, use haddock to build the documentation, create > register/unregister scripts that update package.conf on > installation/deinstallation. yeah, a tool to spit out Makefile defs from .cabal files to automate the process of getting the 500 things on hackage into the ports tree would be ideal. -- Don From donn at avvanta.com Sun May 11 14:58:52 2008 From: donn at avvanta.com (Donn Cave) Date: Sun May 11 14:53:12 2008 Subject: [Haskell-cafe] haskell compiler on NetBSD amd64 In-Reply-To: <20080510215917.GA28142@petunia.outback.escape.de> References: <20080509222119.cfe30daa.donn@avvanta.com> <20080510093512.GA27361@matstaff04.nuigalway.ie> <20080510191316.GD32478@scytale.galois.com> <20080510143643.51eacc56.donn@avvanta.com> <20080510215917.GA28142@petunia.outback.escape.de> Message-ID: <20080511115852.9ad8edab.donn@avvanta.com> On Sat, 10 May 2008 23:59:18 +0200 Matthias Kilian wrote: > > Here you go: > > http://openbsd.dead-parrot.de/distfiles/ghc-6.6.1-amd64-unknown-openbsd-hc.tar.bz2 Thanks, I have managed to build a stage1/ghc-6.6.1 with those, which is a start even if it does immediately core dump. I will follow up off list if I get anywhere interesting with it, either to parties to this exchange or maybe glasgow-haskell-users would be an appropriate place. -- Donn Cave From chaddai.fouche at gmail.com Sun May 11 15:10:52 2008 From: chaddai.fouche at gmail.com (=?ISO-8859-1?Q?Chadda=EF_Fouch=E9?=) Date: Sun May 11 15:04:44 2008 Subject: [Haskell-cafe] Re: dropping hyphens and \n in words In-Reply-To: <20080511195857.7a009941@solaris> References: <20080511195857.7a009941@solaris> Message-ID: 2008/5/11 Achim Schneider : > Excuse my bluntness, but I utterly fail to make sense of this. > Reformulating your understanding of it would surely be beneficial. He has a routine that gives him a list of words classified by line, and he want the hyphens to be accounted for. So that : "Hello mis- ter world !" gives [(1,["Hello","mister"]),(2,["world","!"])] -- Jeda? From barsoap at web.de Sun May 11 15:30:57 2008 From: barsoap at web.de (Achim Schneider) Date: Sun May 11 15:25:07 2008 Subject: [Haskell-cafe] Re: dropping hyphens and \n in words References: <20080511195857.7a009941@solaris> Message-ID: <20080511213057.0d726549@solaris> "Chadda? Fouch?" wrote: > 2008/5/11 Achim Schneider : > > Excuse my bluntness, but I utterly fail to make sense of this. > > Reformulating your understanding of it would surely be beneficial. > > He has a routine that gives him a list of words classified by line, > and he want the hyphens to be accounted for. > So that : > "Hello mis- > ter world !" > gives [(1,["Hello","mister"]),(2,["world","!"])] > Well, that's either a relatively complex hand-written recursion, or you map a predicate that tests for hyphens over the list and zip it with the original, offset by one, and then map it all into the result. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. From jhc0033 at gmail.com Sun May 11 16:33:09 2008 From: jhc0033 at gmail.com (J C) Date: Sun May 11 16:27:06 2008 Subject: [Haskell-cafe] saner shootout programs Message-ID: I don't know Haskell very well, but even I can tell, looking at, for example, the N-body benchmark, that the Haskell code is probably not type-safe, and the tricks used in it would not be usable in a larger program (see below). The task is essentially a pure computation: take a list of bodies having mass, position and velocity; apply Newton laws at discrete intervals for a large number of times; return new positions and velocities. I could write a C++ procedure that performs this task and have some piece of mind regarding its type correctness, exception safety and functional purity: side effects would be local to the procedure, arguments passed as const or by value, the result returned by value, no type casts or new/delete operators used. On the other hand, the Haskell code makes assumptions about the size of double-precision floats (obviously not type-safe). Further, the simulation is not a pure function. It is often argued that one only needs these dirty tricks in the most time-consuming functions. However, if using imperative programming in these "inner loop" procedures places them in IO monad, the "outer loops" (the rest of the program - procedures that call it) will have to go there as well. This makes me doubt the Haskell approach to functional programming. If anyone has a version of the N-body benchmark, where the simulation is a type-safe pure function, I would very much like to see and time it. From dons at galois.com Sun May 11 16:40:14 2008 From: dons at galois.com (Don Stewart) Date: Sun May 11 16:34:06 2008 Subject: [Haskell-cafe] saner shootout programs In-Reply-To: References: Message-ID: <20080511204014.GB12404@scytale.galois.com> jhc0033: > I don't know Haskell very well, but even I can tell, looking at, for > example, the N-body benchmark, that the Haskell code is probably not > type-safe, and the tricks used in it would not be usable in a larger > program (see below). > > The task is essentially a pure computation: take a list of bodies > having mass, position and velocity; apply Newton laws at discrete > intervals for a large number of times; return new positions and > velocities. > > I could write a C++ procedure that performs this task and have some > piece of mind regarding its type correctness, exception safety and > functional purity: side effects would be local to the procedure, > arguments passed as const or by value, the result returned by value, > no type casts or new/delete operators used. > > On the other hand, the Haskell code makes assumptions about the size > of double-precision floats (obviously not type-safe). Further, the > simulation is not a pure function. > > It is often argued that one only needs these dirty tricks in the most > time-consuming functions. However, if using imperative programming in > these "inner loop" procedures places them in IO monad, the "outer > loops" (the rest of the program - procedures that call it) will have > to go there as well. This makes me doubt the Haskell approach to > functional programming. > > If anyone has a version of the N-body benchmark, where the simulation > is a type-safe pure function, I would very much like to see and time > it. n-body requires updating a global array of double values to be competitive performance-wise, though we haven't really nailed this benchmark yet. The current entry should be considered an older approach to raw performance -- typically we can get good (or better) results in using the ST monad. To improve safety, it should run in the ST monad. A version using ST is here, http://haskell.org/haskellwiki/Shootout/Nbody However, the current fastest program should really be cross-ported to run in ST, for best results. (Similar to the nsieve-bits program): http://shootout.alioth.debian.org/gp4/benchmark.php?test=nsievebits&lang=ghc&id=0 I suspect the optimisations that weren't happening, that forced nbody to use Foreign.Ptr in the first place are likely obsolete now -- GHC 6.8.2 should do a good job with STUArray Double, in careful hands. Also worth looking at is the other purely functional entry, in Clean, http://shootout.alioth.debian.org/gp4/benchmark.php?test=nbody&lang=clean&id=0 translation to Haskell should be fairly straightforward. -- Don From dons at galois.com Sun May 11 16:42:10 2008 From: dons at galois.com (Don Stewart) Date: Sun May 11 16:36:03 2008 Subject: [Haskell-cafe] saner shootout programs In-Reply-To: <20080511204014.GB12404@scytale.galois.com> References: <20080511204014.GB12404@scytale.galois.com> Message-ID: <20080511204210.GC12404@scytale.galois.com> dons: > jhc0033: > > I don't know Haskell very well, but even I can tell, looking at, for > > example, the N-body benchmark, that the Haskell code is probably not > > type-safe, and the tricks used in it would not be usable in a larger > > program (see below). > > > > The task is essentially a pure computation: take a list of bodies > > having mass, position and velocity; apply Newton laws at discrete > > intervals for a large number of times; return new positions and > > velocities. > > > > I could write a C++ procedure that performs this task and have some > > piece of mind regarding its type correctness, exception safety and > > functional purity: side effects would be local to the procedure, > > arguments passed as const or by value, the result returned by value, > > no type casts or new/delete operators used. > > > > On the other hand, the Haskell code makes assumptions about the size > > of double-precision floats (obviously not type-safe). Further, the > > simulation is not a pure function. > > > > It is often argued that one only needs these dirty tricks in the most > > time-consuming functions. However, if using imperative programming in > > these "inner loop" procedures places them in IO monad, the "outer > > loops" (the rest of the program - procedures that call it) will have > > to go there as well. This makes me doubt the Haskell approach to > > functional programming. > > > > If anyone has a version of the N-body benchmark, where the simulation > > is a type-safe pure function, I would very much like to see and time > > it. > > n-body requires updating a global array of double values to be > competitive performance-wise, though we haven't really nailed this > benchmark yet. The current entry should be considered an older approach > to raw performance -- typically we can get good (or better) results in > using the ST monad. Oh, for those following, the program we're talking about is this one: http://shootout.alioth.debian.org/gp4/benchmark.php?test=nbody&lang=ghc&id=0 Which I have to argue doesn't /look/ to bad, though the use of Ptr Double to represent mutable arrays of vectors -- following C -- is a bit lower level than we'd like. -- Don From prstanley at ntlworld.com Sun May 11 16:57:29 2008 From: prstanley at ntlworld.com (PR Stanley) Date: Sun May 11 16:51:16 2008 Subject: [Haskell-cafe] saner shootout programs In-Reply-To: References: Message-ID: <7.0.1.0.0.20080511215137.01d7eed0@ntlworld.com> >I don't know Haskell very well, but Paul: "I'm not racist but . . ." :-) >even I can tell, looking at, for >example, the N-body benchmark, that the Haskell code is probably not >type-safe, and the tricks used in it would not be usable in a larger >program (see below). > >The task is essentially a pure computation: take a list of bodies >having mass, position and velocity; apply Newton laws at discrete >intervals for a large number of times; return new positions and >velocities. > >I could write a C++ procedure that performs this task and have some >piece of mind regarding its type correctness, exception safety and >functional purity: side effects would be local to the procedure, >arguments passed as const or by value, the result returned by value, >no type casts or new/delete operators used. > >On the other hand, the Haskell code makes assumptions about the size >of double-precision floats (obviously not type-safe). Further, the >simulation is not a pure function. > >It is often argued that one only needs these dirty tricks in the most >time-consuming functions. However, if using imperative programming in >these "inner loop" procedures places them in IO monad, the "outer >loops" (the rest of the program - procedures that call it) will have >to go there as well. This makes me doubt the Haskell approach to >functional programming. > >If anyone has a version of the N-body benchmark, where the simulation >is a type-safe pure function, I would very much like to see and time >it. >_______________________________________________ >Haskell-Cafe mailing list >Haskell-Cafe@haskell.org >http://www.haskell.org/mailman/listinfo/haskell-cafe From jhc0033 at gmail.com Sun May 11 17:23:38 2008 From: jhc0033 at gmail.com (J C) Date: Sun May 11 17:17:30 2008 Subject: [Haskell-cafe] saner shootout programs In-Reply-To: <20080511204014.GB12404@scytale.galois.com> References: <20080511204014.GB12404@scytale.galois.com> Message-ID: On Sun, May 11, 2008 at 1:40 PM, Don Stewart wrote: > n-body requires updating a global array of double values to be I think the array and any side-effects on it can and should be local to the simulation procedure. > competitive performance-wise, though we haven't really nailed this > benchmark yet. The current entry should be considered an older approach > to raw performance -- typically we can get good (or better) results in > using the ST monad. As I understand, a function can use ST, but still be pure. If so, that's the version I'd like to time (assuming it's also type-safe). The only pure functional solution on that page that I found claims to have a huge leak. From dons at galois.com Sun May 11 17:26:28 2008 From: dons at galois.com (Don Stewart) Date: Sun May 11 17:20:21 2008 Subject: [Haskell-cafe] saner shootout programs In-Reply-To: References: <20080511204014.GB12404@scytale.galois.com> Message-ID: <20080511212628.GD12404@scytale.galois.com> jhc0033: > On Sun, May 11, 2008 at 1:40 PM, Don Stewart wrote: > > > n-body requires updating a global array of double values to be > > I think the array and any side-effects on it can and should be local > to the simulation procedure. > > > competitive performance-wise, though we haven't really nailed this > > benchmark yet. The current entry should be considered an older approach > > to raw performance -- typically we can get good (or better) results in > > using the ST monad. > > As I understand, a function can use ST, but still be pure. If so, Right, its identical to the current solution, but the mutability is guaranteed not to escape the simulation scope. -- Don From dons at galois.com Sun May 11 20:35:00 2008 From: dons at galois.com (Don Stewart) Date: Sun May 11 20:29:12 2008 Subject: [Haskell-cafe] haskell compiler on NetBSD amd64 In-Reply-To: <20080511115852.9ad8edab.donn@avvanta.com> References: <20080509222119.cfe30daa.donn@avvanta.com> <20080510093512.GA27361@matstaff04.nuigalway.ie> <20080510191316.GD32478@scytale.galois.com> <20080510143643.51eacc56.donn@avvanta.com> <20080510215917.GA28142@petunia.outback.escape.de> <20080511115852.9ad8edab.donn@avvanta.com> Message-ID: <20080512003500.GB12845@scytale.galois.com> donn: > On Sat, 10 May 2008 23:59:18 +0200 > Matthias Kilian wrote: > > > > Here you go: > > > > http://openbsd.dead-parrot.de/distfiles/ghc-6.6.1-amd64-unknown-openbsd-hc.tar.bz2 > > Thanks, I have managed to build a stage1/ghc-6.6.1 with those, > which is a start even if it does immediately core dump. I will > follow up off list if I get anywhere interesting with it, either > to parties to this exchange or maybe glasgow-haskell-users would > be an appropriate place. glasgow-haskell-users is good. Also, gdb can be your friend when debugging failures porting .hc files. -- Don From ok at cs.otago.ac.nz Sun May 11 20:58:36 2008 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Sun May 11 20:52:37 2008 Subject: [Haskell-cafe] Re: Interesting critique of OCaml In-Reply-To: References: <20080508033013.GA29498@scytale.galois.com> <4823461E.1080103@btinternet.com> Message-ID: On 9 May 2008, at 6:59 am, Donnie Jones wrote: > > I pasted a copy of the article below for those that cannot access > the site.Why Ocaml Sucks > Published by Brian at 6:49 pm under Functional Languages: Ocaml, > Haskell > > . An even better idea [for 'printf'] might be some variant of > functional unparsing. > There's a link to http://www.brics.dk/RS/98/12/. I spent a bit of time last week playing with the code in that paper. Some of the basic ideas are nice; the idea that 'formats' are functions and concatenation of formats is composition of functions was particularly nice. But seeing it with Haskell eyes, the idea of building strings up using cascades of (basically) \s x -> s ++ f x, where s is a byte string, not a list, and ++ is concatenation of byte strings, seemed obviously wrong. I replaced it by \sl x -> f x : sl, with the final step (in an already existing interface function) being to reverse all the stringlet and concatenate them in one big step. I was gratified, but the very reverse of surprised, to get a substantial speedup. (A factor of over 100 for a small but non- trivial test, using SML/NJ.) In effect, thinking in terms of "shows" paid off handsomely. Haskell-think wins again! From ok at cs.otago.ac.nz Sun May 11 22:20:32 2008 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Sun May 11 22:14:30 2008 Subject: [Haskell-cafe] Maybe a, The Rationale In-Reply-To: <6466A9A7-44E9-4A88-84C5-D54E65B0D8FA@ece.cmu.edu> References: <7.0.1.0.0.20080510233243.01d44f90@ntlworld.com> <8D962D9A-55B0-4812-AD9C-04022F20BAD7@gmail.com> <7.0.1.0.0.20080510235343.01d87e78@ntlworld.com> <10A0ADA6-6D6A-41D7-8686-C7E73385805D@ece.cmu.edu> <7.0.1.0.0.20080511000738.01d9cc40@ntlworld.com> <3AEBDC06-AC4C-4B6D-8B5C-2A02CB394A98@ece.cmu.edu> <7.0.1.0.0.20080511100047.01d2afe0@ntlworld.com> <6466A9A7-44E9-4A88-84C5-D54E65B0D8FA@ece.cmu.edu> Message-ID: <75762365-1AF4-41B3-B02C-4212096FC64C@cs.otago.ac.nz> On 12 May 2008, at 1:52 am, Brandon S. Allbery KF8NH wrote: > My real point was that in the C programming culture it was/is far > too common to use an in-band value; that is, one that could be > confused with or treated as a valid response: null pointers, > stdio's EOF (= -1). Here I must disagree. I've hacked character-level I/O in lots of programming languages (the last time I counted I'd used more than 100), and C was the first language I ever met that made it easy, precisely BECAUSE the perfectly normal "there are no more characters" situation was handled the same way as every other outcome. > This just causes problems because code is almost encouraged to > ignore the special cases. > For example, the ctype macros have to support being passed EOF. So they do, but it is elementary to do so. The only reason there is anything even remotely unusual there is that the *same* functions are used in C for *character* input and *byte* input. I'll grant you that you probably don't want to process binary input using quite the same quasi-FSA code that you want for characters. Since C uses NUL for terminating strings, and since ASCII made it clear that NUL was never ever *supposed* to appear in text, NUL would have been the perfect choice for character EOF, and in that case there would never have been anything odd about having the ctype macros handle it. I've been writing some Smalltalk recently, which uses a Pascal-like convention aStream atEnd "test for EOF" ifTrue: [self handleEOF] ifFalse: [self handleCharacter: aStream next] and the EOF tests clutter up the code inordinately and make it so painful that C starts looking good again. The C approach here has several benefits: - you can *postpone* checking for EOF until after you have checked for other things; since EOF is seldom or never what the code is mainly *about* this is good for clarity - if you want to know "is the next character one of these" you have only two cases to deal with at that point (yes and no), not three (yes, no, and you-idiot-you-forgot-to-test-for-EOF-first-and-testing-for-EOF- is- the-most-important-thing-anybody-could-be-interested-in-when- reading). > Maybe types force you to deal with it, while simultaneously > providing convenience functions to help you deal with it. I readily grant that Maybe is a wonderful wonderful thing and I use it freely and voluntarily. BUT it should not dominate the code. Consider Haskell's getChar and hGetChar. They DON'T return Maybe Char; they raise an exception at end of file. You have to keep testing isEOF/ hIsEOF before each character read, as if we had learned nothing since Pascal. Arguably, maybeGetChar :: IO (Maybe Char) and hMaybeGetChar :: Handle - > IO (Maybe Char) would be a good idea, at least then one could easily set up some combinators to deal with this nuisance. > > > -- > brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com > system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu > electrical and computer engineering, carnegie mellon university > KF8NH > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- "I don't want to discuss evidence." -- Richard Dawkins, in an interview with Rupert Sheldrake. (Fortean times 232, p55.) From dons at galois.com Sun May 11 22:42:47 2008 From: dons at galois.com (Don Stewart) Date: Sun May 11 22:36:54 2008 Subject: [Haskell-cafe] Maybe a, The Rationale In-Reply-To: <75762365-1AF4-41B3-B02C-4212096FC64C@cs.otago.ac.nz> References: <7.0.1.0.0.20080510233243.01d44f90@ntlworld.com> <8D962D9A-55B0-4812-AD9C-04022F20BAD7@gmail.com> <7.0.1.0.0.20080510235343.01d87e78@ntlworld.com> <10A0ADA6-6D6A-41D7-8686-C7E73385805D@ece.cmu.edu> <7.0.1.0.0.20080511000738.01d9cc40@ntlworld.com> <3AEBDC06-AC4C-4B6D-8B5C-2A02CB394A98@ece.cmu.edu> <7.0.1.0.0.20080511100047.01d2afe0@ntlworld.com> <6466A9A7-44E9-4A88-84C5-D54E65B0D8FA@ece.cmu.edu> <75762365-1AF4-41B3-B02C-4212096FC64C@cs.otago.ac.nz> Message-ID: <20080512024247.GA13040@scytale.galois.com> ok: > > Maybe types force you to deal with it, while simultaneously > >providing convenience functions to help you deal with it. > > I readily grant that Maybe is a wonderful wonderful thing and I use it > freely and > voluntarily. BUT it should not dominate the code. > > Consider Haskell's getChar and hGetChar. They DON'T return Maybe > Char; they > raise an exception at end of file. You have to keep testing isEOF/ > hIsEOF before > each character read, as if we had learned nothing since Pascal. > Arguably, maybeGetChar :: IO (Maybe Char) and hMaybeGetChar :: Handle - > > IO (Maybe Char) > would be a good idea, at least then one could easily set up some > combinators to > deal with this nuisance. Thankfully its easy to lift IO-throwing things into a safer world. import Control.Exception import Prelude hiding (getChar) import qualified Prelude as P getChar :: IO (Maybe Char) getChar = handle (const (return Nothing)) (Just `fmap` P.getChar) -- Don From allbery at ece.cmu.edu Sun May 11 23:10:05 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sun May 11 23:03:57 2008 Subject: [Haskell-cafe] Maybe a, The Rationale In-Reply-To: <20080512024247.GA13040@scytale.galois.com> References: <7.0.1.0.0.20080510233243.01d44f90@ntlworld.com> <8D962D9A-55B0-4812-AD9C-04022F20BAD7@gmail.com> <7.0.1.0.0.20080510235343.01d87e78@ntlworld.com> <10A0ADA6-6D6A-41D7-8686-C7E73385805D@ece.cmu.edu> <7.0.1.0.0.20080511000738.01d9cc40@ntlworld.com> <3AEBDC06-AC4C-4B6D-8B5C-2A02CB394A98@ece.cmu.edu> <7.0.1.0.0.20080511100047.01d2afe0@ntlworld.com> <6466A9A7-44E9-4A88-84C5-D54E65B0D8FA@ece.cmu.edu> <75762365-1AF4-41B3-B02C-4212096FC64C@cs.otago.ac.nz> <20080512024247.GA13040@scytale.galois.com> Message-ID: <969BBA4C-8997-4FBF-971F-39FE61F9ABF1@ece.cmu.edu> On 2008 May 11, at 22:42, Don Stewart wrote: > ok: >>> Maybe types force you to deal with it, while simultaneously >>> providing convenience functions to help you deal with it. >> >> I readily grant that Maybe is a wonderful wonderful thing and I use >> it >> freely and >> voluntarily. BUT it should not dominate the code. >> >> Consider Haskell's getChar and hGetChar. They DON'T return Maybe >> Char; they >> raise an exception at end of file. You have to keep testing isEOF/ >> hIsEOF before >> each character read, as if we had learned nothing since Pascal. >> Arguably, maybeGetChar :: IO (Maybe Char) and hMaybeGetChar :: >> Handle - >>> IO (Maybe Char) >> would be a good idea, at least then one could easily set up some >> combinators to >> deal with this nuisance. > > Thankfully its easy to lift IO-throwing things into a safer world. > > import Control.Exception > import Prelude hiding (getChar) > import qualified Prelude as P > > getChar :: IO (Maybe Char) > getChar = handle (const (return Nothing)) (Just `fmap` P.getChar) And it's a monad, so it doesn't have to dominate the code; you can write your code monadically and let the scaffolding deal. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From abhay.parvate at gmail.com Mon May 12 02:35:41 2008 From: abhay.parvate at gmail.com (Abhay Parvate) Date: Mon May 12 02:29:30 2008 Subject: [Haskell-cafe] GHC predictability In-Reply-To: References: Message-ID: <3c4d5adf0805112335j22b35549qbdd9289a0c2b051d@mail.gmail.com> As a beginner, I had found the behaviour quite unpredictable. But with time I found that I could reason out the behaviour with my slowly growing knowledge of laziness. I don't spot all the places in my program that will suck while writing a program, but post facto many things become clear. (And then there is the profiler!) GHC's internal details had been never necessary to me! I aspire to write computationally heavy programs in haskell in future, and I have been successful in reaching factors of 3 to 5 with C programs (though I have not been upto factors of 1 for which I find claims here and there) without any knowledge of GHC internals. But the GHC user guide is immensely valuable. I would like to note that beginners' codes are many times time/memory consuming even in slighly complicated cases, and it may be a big source of frustration and turn-away if they don't stick up and pursue. This is not a problem of GHC, or even Haskell; it generally applies to functional programming. These are my opinions; I am only an advanced beginner :) 2008/5/10 Jeff Polakow : > > Hello, > > One frequent criticism of Haskell (and by extension GHC) is that it has > unpredictable performance and memory consumption. I personally do not find > this to be the case. I suspect that most programmer confusion is rooted in > shaky knowledge of lazy evaluation; and I have been able to fix, with > relative ease, the various performance problems I've run into. However I am > not doing any sort of performance critical computing (I care about minutes > or seconds, but not about milliseconds). > > I would like to know what others think about this. Is GHC predictable? Is a > thorough knowledge of lazy evaluation good enough to write efficient > (whatever that means to you) code? Or is intimate knowledge of GHC's innards > necessary? > > thanks, > Jeff > > PS I am conflating Haskell and GHC because I use GHC (with its extensions) > and it produces (to my knowledge) the fastest code. > > --- > > This e-mail may contain confidential and/or privileged information. If you > are not the intended recipient (or have received this e-mail in error) > please notify the sender immediately and destroy this e-mail. Any > unauthorized copying, disclosure or distribution of the material in this > e-mail is strictly forbidden. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080512/50541ab0/attachment.htm From ajb at spamcop.net Mon May 12 02:36:14 2008 From: ajb at spamcop.net (ajb@spamcop.net) Date: Mon May 12 02:30:04 2008 Subject: [Haskell-cafe] List concat In-Reply-To: <48245CBC.309@btinternet.com> References: <48245CBC.309@btinternet.com> Message-ID: <20080512023614.wcqdpgl63kgsgcwc-nwo@fcnzpbc.arg@webmail.spamcop.net> G'day all. Quoting Andrew Coppin : > The function (++) :: [x] -> [x] -> [x] has O(n) complexity. That's not entirely true. When you call (++), it does O(1) work. If you evaluate k cons cells. it takes O(min(k,n)) work. Cheers, Andrew Bromage From dominic.steinitz at blueyonder.co.uk Mon May 12 03:34:44 2008 From: dominic.steinitz at blueyonder.co.uk (Dominic Steinitz) Date: Mon May 12 03:28:51 2008 Subject: [Haskell-cafe] Re: Couple of formal questions References: <814617240804292014td3d79f9ve9f0e2345b851e2@mail.gmail.com> Message-ID: Creighton Hogg gmail.com> writes: between well-founded recursion & well-founded(?) corecursion?Where could I find a proof that the initial algebras & final coalgebras of CPO coincide?? I Creighton, I started putting something together here. I'm not sure if it's what you are after and in any event it will now have to wait until the weekend. Dominic. http://idontgetoutmuch.wordpress.com/2008/05/12/isomorphic-types/ From vigalchin at gmail.com Mon May 12 05:00:12 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Mon May 12 04:54:03 2008 Subject: [Haskell-cafe] help(!!) Message-ID: <5ae4f2ba0805120200m57fa4ec9gae442bae2ddbeee0@mail.gmail.com> Hello, As I said in a Friday posting, I changed the version # of the cabal file that I am using, unix.cabal. Now my build environment is broken and I am dead in the water: vigalchin@ubuntu:~/FTP/Haskell/unix-2.2.0.0$ runhaskell Setup.hs configure Configuring unix-2.3.0.0... vigalchin@ubuntu:~/FTP/Haskell/unix-2.2.0.0$ runhaskell Setup.hs build Setup.hs: unix.cabal has been changed, please re-configure. vigalchin@ubuntu:~/FTP/Haskell/unix-2.2.0.0$ It seems like "runhaskell Setup.hs configure" isn't doing much after the unix.cabal change. How can I force the configure to really run? Do something with some of the config files?? Thanks, Vasili -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080512/383b3a27/attachment.htm From dekudekuplex at yahoo.com Mon May 12 05:19:26 2008 From: dekudekuplex at yahoo.com (Benjamin L. Russell) Date: Mon May 12 05:13:16 2008 Subject: [Haskell-cafe] saner shootout programs In-Reply-To: <7.0.1.0.0.20080511215137.01d7eed0@ntlworld.com> Message-ID: <504674.87728.qm@web30201.mail.mud.yahoo.com> --- On Mon, 5/12/08, PR Stanley wrote: > >I don't know Haskell very well, but > > > Paul: "I'm not racist but . . ." :-) Relevant Haskell humor: Humor/Homework - HaskellWiki: see line 3: http://www.haskell.org/haskellwiki/Humor/Homework Benjamin L. Russell From duncan.coutts at worc.ox.ac.uk Mon May 12 06:25:39 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon May 12 06:17:55 2008 Subject: [Haskell-cafe] help(!!) In-Reply-To: <5ae4f2ba0805120200m57fa4ec9gae442bae2ddbeee0@mail.gmail.com> References: <5ae4f2ba0805120200m57fa4ec9gae442bae2ddbeee0@mail.gmail.com> Message-ID: <1210587939.5824.95.camel@localhost> On Mon, 2008-05-12 at 04:00 -0500, Galchin, Vasili wrote: > Hello, > > As I said in a Friday posting, I changed the version # of the > cabal file that I am using, unix.cabal. Now my build environment is > broken and I am dead in the water: > > vigalchin@ubuntu:~/FTP/Haskell/unix-2.2.0.0$ runhaskell Setup.hs > configure > Configuring unix-2.3.0.0... > vigalchin@ubuntu:~/FTP/Haskell/unix-2.2.0.0$ runhaskell Setup.hs build > Setup.hs: unix.cabal has been changed, please re-configure. Yeah, configure seems to be failing without any error message. > It seems like "runhaskell Setup.hs configure" isn't doing much after > the unix.cabal change. How can I force the configure to really run? Do > something with some of the config files?? Try doing a $ runhaskell Setup.hs clean first and then $ runhaskell Setup.hs configure -v3 $ runhaskell Setup.hs build and if it still fails you should be able to see what it was doing last. If it is indeed still failing then send me the full output of $ runhaskell Setup.hs configure -v3 and the version of Cabal you're using and the full package you're working on (preferably as a link to a darcs repo or as a tarball). Don't send it all to the whole mailing list though or we'll annoy people :-). Duncan From r.kelsall at millstream.com Mon May 12 07:38:57 2008 From: r.kelsall at millstream.com (Richard Kelsall) Date: Mon May 12 07:32:50 2008 Subject: [Haskell-cafe] saner shootout programs In-Reply-To: References: Message-ID: <48282C51.1040706@millstream.com> J C wrote: ... > If anyone has a version of the N-body benchmark, where the simulation > is a type-safe pure function, I would very much like to see and time > it. Hello JC, I think you've set yourself a challenge there :) Welcome to Haskell programming. Taking a Shootout entry and playing with it is a great way to learn Haskell. The Shootout provides an example in your favourite previous language for comparison and a small well defined program with exact test results you can pit your wits against. Fame awaits you for a fast and beautiful entry. I'm still learning useful things from the Fasta benchmark. It's surprising how many interesting things you can discover in a small piece of code. Richard. From skynare at gmail.com Mon May 12 09:51:17 2008 From: skynare at gmail.com (sam lee) Date: Mon May 12 09:45:08 2008 Subject: [Haskell-cafe] M1 + M2 = M3 where both computations in M1 and M2 can be used? Message-ID: <4e7aa0f80805120651u45fdac69hc8835103376dbce7@mail.gmail.com> Hi. I want to compose two monads to build another monad where computations of the two monads can be used inside. I have: - MonadTypeInfer : interface (class) for TypeInfer monad - TypeInfer : a monad that has Map String Type (association of names and types) - TypeInferT : transformer of above monad - MonadEval : interface (class) for Eval monad - Eval : a monad that has Map String Expr (association of names and code/function body) - EvalT : transformer of Eval - tInfer :: Expr -> TypeInfer Type -- given expr, returns type of it in TypeInfer monad - eval :: Expr -> Eval Expr -- given expr, returns normalized expr in Eval monad Problem: in repl, when user defines a function, it should type check and register type of the function to TypeInfer monad's Map String Type. Also, it should store the expression of the function in Eval monad. I build REPL monad using TypeInferT and EvalT. > newtype REPL a = REPL { runREPL :: TypeInferT (EvalT IO) a } > deriving(Monad, Functor, MonadIO, MonadTypeInfer, MonadEval) > repl :: REPL () > repl = do > input <- prompt ">>> " > case parse input of > Left err -> -- handle error > Right expr -> do > t <- tInfer expr -- BAD!! tInfer :: TypeInfer Type > println (show t) > result <- eval expr -- BAD!! eval :: Eval Expr > println (show result) > repl Should I make tInfer :: REPL Type, eval :: REPL Expr? Is there a way to build a monad where you could use sub-monads' (monads used to build current monad) computations? I prefer keeping tInfer :: TypeInfer Type, eval :: Eval Expr because tInfer never uses actions in Eval monad and vice versa. It seems like what I am asking is to break the type system. Maybe I should just make them run in REPL monad. Thank you. Sam. From twanvl at gmail.com Mon May 12 10:38:47 2008 From: twanvl at gmail.com (Twan van Laarhoven) Date: Mon May 12 10:32:36 2008 Subject: [Haskell-cafe] M1 + M2 = M3 where both computations in M1 and M2 can be used? In-Reply-To: <4e7aa0f80805120651u45fdac69hc8835103376dbce7@mail.gmail.com> References: <4e7aa0f80805120651u45fdac69hc8835103376dbce7@mail.gmail.com> Message-ID: <48285677.3010806@gmail.com> sam lee wrote: > Hi. > > I want to compose two monads to build another monad where > computations of the two monads can be used inside. > > I have: > > - MonadTypeInfer : interface (class) for TypeInfer monad > - TypeInfer : a monad that has Map String Type (association of names and types) > - TypeInferT : transformer of above monad > - MonadEval : interface (class) for Eval monad > - Eval : a monad that has Map String Expr (association of names and > code/function body) > - EvalT : transformer of Eval > - tInfer :: Expr -> TypeInfer Type -- given expr, returns type of it > in TypeInfer monad > - eval :: Expr -> Eval Expr -- given expr, returns normalized expr in Eval monad > > Is there a way to build a monad where you could use sub-monads' > (monads used to build current monad) computations? A solution to this problem is to use type classes, and in particular MonadTrans. You can then give an instance of MonadTypeInfer for EvalT m where m is an instance of MonadTypeInfer, and similarly an instance MonadEval for TypeInferT m. How this is implemented depends on the Monads in question, but if you use the monad transformer library with newtype deriving you can just add "deriving MonadTrans". class Monad m => MonadTypeInfer m where -- functions -- tiStuff :: X -> m Whatever class Monad m => MonadEval m where -- functions -- instance Monad m => MonadTypeInfer (TypeInferT m) where -- implementation -- tiStuff = ... instance Monad m => MonadEval (EvalT m) where -- implementation -- instance MonadEval m => MonadTypeInfer (EvalT m) where -- lift the functions from TypeInfer through the EvalT type, -- MonadTrans from the mtl might help here tiStuff x = lift (tiStuff x) tInfer :: MonadTypeInfer m => Expr -> m Type eval :: MonadEval m => Expr -> m Expr Twan From derek.a.elkins at gmail.com Mon May 12 12:25:10 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Mon May 12 12:19:04 2008 Subject: [Haskell-cafe] List concat In-Reply-To: <20080512023614.wcqdpgl63kgsgcwc-nwo@fcnzpbc.arg@webmail.spamcop.net> References: <48245CBC.309@btinternet.com> <20080512023614.wcqdpgl63kgsgcwc-nwo@fcnzpbc.arg@webmail.spamcop.net> Message-ID: <1210609510.5514.66.camel@derek-laptop> On Mon, 2008-05-12 at 02:36 -0400, ajb@spamcop.net wrote: > G'day all. > > Quoting Andrew Coppin : > > > The function (++) :: [x] -> [x] -> [x] has O(n) complexity. > > That's not entirely true. > > When you call (++), it does O(1) work. If you evaluate k cons cells. > it takes O(min(k,n)) work. I think we can safely simplify that to O(k) (at least for sequential programs). From lassoken at gmail.com Mon May 12 12:41:55 2008 From: lassoken at gmail.com (Lauri Oksanen) Date: Mon May 12 12:35:46 2008 Subject: [Haskell-cafe] On syntactic sugar Message-ID: <22dc08990805120941l3a9c63cfmaf962806a669449e@mail.gmail.com> Hi, I'm writing my first real Haskell program and I came up with the following code snippet. --- let x' = x \+ dist \* dir nx' = normal geometry wi = (-1) \* dir in do (p, wo) <- brdfCosSampling reflector nx' wi let color' = p \** color q = min 1 (scalarContribution p) in do sampler <- biasedCoinSampler q (radianceSampler surfaces x' wo (q \* color')) (terminalRadianceSampler surfaces x' nx' ((1-q) \* color')) sampler --- This works just fine but I don't like the way I had to indent the code because of alternating lets and dos. I would like to indent the code more like an imperative code i.e. like this --- let { x' = x \+ dist \* dir ; nx' = normal geometry ; wi = (-1) \* dir ; } in do { (p, wo) <- brdfCosSampling reflector nx' wi ; let { color' = p \** color ; q = min 1 (scalarContribution p) ; } in do { sampler <- biasedCoinSampler q (radianceSampler surfaces x' wo (q \* color')) (terminalRadianceSampler surfaces x' nx' ((1-q) \* color')) ; sampler ; }} --- but without braces and semicolons. Following works also, but is ugly (and probably less efficient?). --- do x' <- return $ x \+ dist \* dir nx' <- return $ normal geometry wi <- return $ (-1) \* dir (p, wo) <- brdfCosSampling reflector nx' wi color' <- return $ p \** color q <- return $ min 1 (scalarContribution p) sampler <- biasedCoinSampler q (radianceSampler surfaces x' wo (q \* color')) (terminalRadianceSampler surfaces x' nx' ((1-q) \* color')) sampler --- Is there some nice trick to do this? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080512/dd072011/attachment-0001.htm From dbueno at gmail.com Mon May 12 12:45:11 2008 From: dbueno at gmail.com (Denis Bueno) Date: Mon May 12 12:38:59 2008 Subject: [Haskell-cafe] On syntactic sugar In-Reply-To: <22dc08990805120941l3a9c63cfmaf962806a669449e@mail.gmail.com> References: <22dc08990805120941l3a9c63cfmaf962806a669449e@mail.gmail.com> Message-ID: <6dbd4d000805120945l579257a1v3ba78a5f01efa344@mail.gmail.com> 2008/5/12 Lauri Oksanen : > Hi, > > I'm writing my first real Haskell program and I came up with the following > code snippet. > > --- > let x' = x \+ dist \* dir > nx' = normal geometry > wi = (-1) \* dir > in do > (p, wo) <- brdfCosSampling reflector nx' wi > let color' = p \** color > q = min 1 (scalarContribution p) > in do > sampler <- biasedCoinSampler q > (radianceSampler surfaces x' wo (q \* color')) > (terminalRadianceSampler surfaces x' nx' ((1-q) \* > color')) > sampler > --- > > This works just fine but I don't like the way I had to indent the code > because of alternating lets and dos. > I would like to indent the code more like an imperative code i.e. like this You can use let in a do-block, just don't use "in": do x <- something let y = ... x ... return (x + y) -- Denis From alfonso.acosta at gmail.com Mon May 12 12:46:20 2008 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Mon May 12 12:40:31 2008 Subject: [Haskell-cafe] On syntactic sugar In-Reply-To: <22dc08990805120941l3a9c63cfmaf962806a669449e@mail.gmail.com> References: <22dc08990805120941l3a9c63cfmaf962806a669449e@mail.gmail.com> Message-ID: <6a7c66fc0805120946n164350d8x57e8c8f2f3600fe0@mail.gmail.com> 2008/5/12 Lauri Oksanen : > Hi, > > I'm writing my first real Haskell program and I came up with the following > code snippet. > > --- > let x' = x \+ dist \* dir > nx' = normal geometry > wi = (-1) \* dir > in do > (p, wo) <- brdfCosSampling reflector nx' wi > let color' = p \** color > q = min 1 (scalarContribution p) > in do > sampler <- biasedCoinSampler q > (radianceSampler surfaces x' wo (q \* color')) > (terminalRadianceSampler surfaces x' nx' ((1-q) \* > color')) > sampler Do-notation already offers what you want. Try this out: do let x' = x \+ dist \* dir nx' = normal geometry wi = (-1) \* dir (p, wo) <- brdfCosSampling reflector nx' wi let color' = p \** color q = min 1 (scalarContribution p) sampler <- biasedCoinSampler q (radianceSampler surfaces x' wo (q \* color')) (terminalRadianceSampler surfaces x' nx' ((1-q) \* color')) sampler From jake.mcarthur at gmail.com Mon May 12 13:05:29 2008 From: jake.mcarthur at gmail.com (Jake Mcarthur) Date: Mon May 12 12:59:22 2008 Subject: [Haskell-cafe] On syntactic sugar In-Reply-To: <22dc08990805120941l3a9c63cfmaf962806a669449e@mail.gmail.com> References: <22dc08990805120941l3a9c63cfmaf962806a669449e@mail.gmail.com> Message-ID: <99E787B5-E178-4230-A34A-2A45D304FB71@gmail.com> On May 12, 2008, at 11:41 AM, Lauri Oksanen wrote: > let x' = x \+ dist \* dir > nx' = normal geometry > wi = (-1) \* dir > in do > (p, wo) <- brdfCosSampling reflector nx' wi > let color' = p \** color > q = min 1 (scalarContribution p) > in do > sampler <- biasedCoinSampler q > (radianceSampler surfaces x' wo (q \* color')) > (terminalRadianceSampler surfaces x' nx' ((1- > q) \* color')) > sampler Something like the following should work: do let x' = x \+ dist \* dir let nx' = normal geometry let wi = (-1) \* dir (p, wo) <- brdfCosSampling reflector nx' wi let color' = p \** color let q = min 1 (scalarContribution p) sampler <- biasedCoinSampler q (radianceSampler surfaces x' wo (q \* color')) (terminalRadianceSampler surfaces x' nx' ((1-q) \* color')) sampler - Jake McArthur From kenn at kenn.frap.net Mon May 12 14:33:20 2008 From: kenn at kenn.frap.net (Kenn Knowles) Date: Mon May 12 14:27:11 2008 Subject: [Haskell-cafe] M1 + M2 = M3 where both computations in M1 and M2 can be used? In-Reply-To: <4e7aa0f80805120651u45fdac69hc8835103376dbce7@mail.gmail.com> References: <4e7aa0f80805120651u45fdac69hc8835103376dbce7@mail.gmail.com> Message-ID: <476d7e8c0805121133l6e204837q236138dd7f21182d@mail.gmail.com> On Mon, May 12, 2008 at 6:51 AM, sam lee wrote: > Hi. > > I want to compose two monads to build another monad where > computations of the two monads can be used inside. Twan's suggestion seems like a natural way to continue with the existing code you have described (based on monad transformers). If you would like to understand this issue in some depth, I recommend the following paper which presents a general way to combine two monads that is not biased towards having one "contained" in the other. - Composing monads using coproducts. C L=FCth, N Ghani. ICFP 2002. - http://www.mcs.le.ac.uk/~ng13/papers/icfp02.ps.gz I just tried it out the other day, so if you'll excuse the self-promotion here is a demonstration http://www.kennknowles.com/blog/2008/05/10/debugging-with-open-recursion-mixins/ - Kenn From david.waern at gmail.com Mon May 12 14:45:15 2008 From: david.waern at gmail.com (David Waern) Date: Mon May 12 14:39:07 2008 Subject: [Haskell-cafe] Re: [Haskell] Re: ANN: Haddock version 2.1.0 In-Reply-To: <016401c8b224$6b0b5250$5a307ad5@cr3lt> References: <481A46C0.3050209@gmail.com> <012e01c8ac61$cc2f0d60$bf078351@cr3lt> <4822F24B.4040801@microsoft.com> <4824165B.60800@gmail.com> <016401c8b224$6b0b5250$5a307ad5@cr3lt> Message-ID: 2008/5/9 Claus Reinke : > > > > Ah, I didn't think about the GHC options that change the lexical > > syntax. You're right, using the GHC lexer should be easier. > > > > and, if you do that, you could also make the GHC lexer > squirrel away the comments (including pragmas, if they aren't > already in the AST) someplace safe, indexed by, or at least annotated with, > their source locations, and make this comment/ > pragma storage available via the GHC API. (1a) > > then, we'd need a way to merge those comments and pragmas > back into the output during pretty printing, and we'd have made > the first small step towards source-to-source transformations: making code > survive semantically intact over (pretty . parse). (1b) > > that would still not quite fullfill the GHC API comment ticket (*), > but that was only a quick sketch, not a definite design. it might be > sufficient to let each GHC API client do its own search to associate bits of > comment/pragma storage with bits of AST. > if i understand you correctly, you are going to do (1a), so > if you could add that to the GHC API, we'd only need (1b) > to go from useable-for-analysis-and-extraction to > useable-for-transformation. > > is that going to be a problem? I'll have a look to see if doing 1a) is possible without too much work. And then if I actually implement something, adding it to the GHC API shouldn't be a problem. David From andrewcoppin at btinternet.com Mon May 12 15:01:53 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Mon May 12 14:55:52 2008 Subject: [Haskell-cafe] GHC predictability In-Reply-To: <20080509212412.GE24396@scytale.galois.com> References: <20080509212412.GE24396@scytale.galois.com> Message-ID: <48289421.2070408@btinternet.com> Don Stewart wrote: > jeff.polakow: > >> Hello, >> >> One frequent criticism of Haskell (and by extension GHC) is that it has >> unpredictable performance and memory consumption. I personally do not find >> this to be the case. I suspect that most programmer confusion is rooted in >> shaky knowledge of lazy evaluation; and I have been able to fix, with >> relative ease, the various performance problems I've run into. However I >> am not doing any sort of performance critical computing (I care about >> minutes or seconds, but not about milliseconds). >> >> I would like to know what others think about this. Is GHC predictable? Is >> a thorough knowledge of lazy evaluation good enough to write efficient >> (whatever that means to you) code? Or is intimate knowledge of GHC's >> innards necessary? >> >> thanks, >> Jeff >> >> PS I am conflating Haskell and GHC because I use GHC (with its extensions) >> and it produces (to my knowledge) the fastest code. >> > > This has been my experience to. I'm not even sure where > "unpredicatiblity" would even come in, other than though not > understanding the demand patterns of the code. > > It's relatively easy to look at the Core to get a precise understanding > of the runtime behaviour. > > I've also not found the GC unpredicatble either. > I offer up the following example: mean xs = sum xs / length xs Now try, say, "mean [1.. 1e9]", and watch GHC eat several GB of RAM. (!!) If we now rearrange this to mean = (\(s,n) -> s / n) . foldr (\x (s,n) -> let s' = s+x; n' = n+1 in s' `seq` n' `seq` (s', n')) (0,0) and run the same example, and watch it run in constant space. Of course, the first version is clearly readable, while the second one is almost utterly incomprehensible, especially to a beginner. (It's even more fun that you need all those seq calls in there to make it work properly.) The sad fact is that if you just write something in Haskell in a nice, declarative style, then roughly 20% of the time you get good performance, and 80% of the time you get laughably poor performance. For example, I sat down and spent the best part of a day writing an MD5 implementation. Eventually I got it so that all the test vectors work right. (Stupid little-endian nonsense... mutter mutter...) When I tried it on a file containing more than 1 MB of data... ooooohhhh dear... I gave up after waiting several minutes for an operation that the C implementation can do in milliseconds. I'm sure there's some way of fixing this, but... the source code is pretty damn large, and very messy as it is. I shudder to think what you'd need to do to it to speed it up. Of course, the first step in any serious attempt at performance improvement is to actually profile the code to figure out where the time is being spent. Laziness is *not* your friend here. I've more or less given up trying to comprehend the numbers I get back from the GHC profiles, because they apparently defy logic. I'm sure there's a reason to the madness somewhere, but... for nontrivial programs, it's just too hard to figure out what's going on. Probably the best part is that almost any nontrivial program you write spends 60% or more of its time doing GC rather than actual work. Good luck with the heap profiler. It's even more mysterious than the time profiles. ;-) In short, as a fairly new Haskell programmer, I find it completely impossibly to write code that doesn't crawl along at a snail's pace. Even when I manage to make it faster, I usually have no clue why. (E.g., adding a seq to a mergesort made it 10x faster. Why? Changing from strict ByteString to lazy ByteString made one program 100x faster. Why?) Note that I'm not *blaming* GHC for this - I think it's just inherantly very hard to predict performance in a lazy language. (Remember, deterministic isn't the same as predictable - see Chaos Theory for why.) I wish it wasn't - becuase I really *really* want to write all my complex compute-bounded programs in Haskell, because it makes algorithms so beautifully easy to express. But when you're trying to implement something that takes hours to run even in C... From andrewcoppin at btinternet.com Mon May 12 16:05:44 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Mon May 12 15:59:24 2008 Subject: [Haskell-cafe] Copy on read In-Reply-To: <20080511150212.GA4049@pc149.staff.cs.york.ac.uk> References: <4825984A.4010905@btinternet.com> <20080511150212.GA4049@pc149.staff.cs.york.ac.uk> Message-ID: <4828A318.3070207@btinternet.com> Matthew Naylor wrote: > I wonder to what extent deforestation supersedes such optimisations. > This would be a good topic to raise with a Cleaner. The paper Neil > mentions looks like a nice alternative to uniqueness typing -- and it > appears that there will be a FitA talk about it, this Thursday. > What if you have, say, a giant array, and you run a loop that updates the entire array. Rather expensive to keep copying and collecting all that space. That's why most array-based code is explicitly in-place. But wouldn't it be nice if it didn't have to be? Similarly, there are recursion patterns for which fusion isn't very easy. (How would you fuse, say, a Gaussian elimination algorithm?) From lennart at augustsson.net Mon May 12 17:07:21 2008 From: lennart at augustsson.net (Lennart Augustsson) Date: Mon May 12 17:01:10 2008 Subject: [Haskell-cafe] List concat In-Reply-To: <-5854735012137960878@unknownmsgid> References: <48245CBC.309@btinternet.com> <-5854735012137960878@unknownmsgid> Message-ID: Well, if you want to be picky evaluating (calling) (xs ++ ys) takes whatever time it takes to evaluate xs to WHNF and if xs is null then it in addition takes the time it takes to evaluate ys to WHNF. Saying anything about time complexity with lazy evaluation requires a lot of context to be exact. -- Lennart On Mon, May 12, 2008 at 7:36 AM, wrote: > G'day all. > > Quoting Andrew Coppin : > > The function (++) :: [x] -> [x] -> [x] has O(n) complexity. >> > > That's not entirely true. > > When you call (++), it does O(1) work. If you evaluate k cons cells. > it takes O(min(k,n)) work. > > Cheers, > Andrew Bromage > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080512/3af77b50/attachment.htm From jlhamilton at gmail.com Mon May 12 18:09:44 2008 From: jlhamilton at gmail.com (John Hamilton) Date: Mon May 12 18:03:34 2008 Subject: [Haskell-cafe] Short circuiting and the Maybe monad Message-ID: <65113aef0805121509s6b4e76bbxd23e86070a2a0be3@mail.gmail.com> I'm trying to understand how short circuiting works with the Maybe monad. Take the expression n >>= f >>= g >>= h, which can be written as (((n >>= f) >>= g) >>= h) because >>= is left associative. If n is Nothing, this implies that (n >>= f) is Nothing, and so on, each nested sub-expression easily evaluating to Nothing, but without there being a quick way to short circuit at the beginning. Now take the example do x <- xs y <- ys z <- zs return (x, y, z) which I believe desugars like xs >>= (\x -> ys >>= (\y -> zs >>= (\z -> return (x, y, z)))) Here the associativity of >>= no longer matters, and if xs is Nothing the whole expression can quickly be determined to be Nothing, because Nothing >>= _ = Nothing. Am I looking at this correctly? - John From skynare at gmail.com Mon May 12 18:22:49 2008 From: skynare at gmail.com (sam lee) Date: Mon May 12 18:16:42 2008 Subject: [Haskell-cafe] M1 + M2 = M3 where both computations in M1 and M2 can be used? In-Reply-To: <48285677.3010806@gmail.com> References: <4e7aa0f80805120651u45fdac69hc8835103376dbce7@mail.gmail.com> <48285677.3010806@gmail.com> Message-ID: <4e7aa0f80805121522w669138a3mc28d537585945535@mail.gmail.com> > tInfer :: MonadTypeInfer m => Expr -> m Type > eval :: MonadEval m => Expr -> m Expr That solves! I should've left out type annotation. On Mon, May 12, 2008 at 10:38 AM, Twan van Laarhoven wrote: > sam lee wrote: > > > > > > Hi. > > > > I want to compose two monads to build another monad where > > computations of the two monads can be used inside. > > > > I have: > > > > - MonadTypeInfer : interface (class) for TypeInfer monad > > - TypeInfer : a monad that has Map String Type (association of names and > types) > > - TypeInferT : transformer of above monad > > - MonadEval : interface (class) for Eval monad > > - Eval : a monad that has Map String Expr (association of names and > > code/function body) > > - EvalT : transformer of Eval > > - tInfer :: Expr -> TypeInfer Type -- given expr, returns type of it > > in TypeInfer monad > > - eval :: Expr -> Eval Expr -- given expr, returns normalized expr in Eval > monad > > > > > > Is there a way to build a monad where you could use sub-monads' > > (monads used to build current monad) computations? > > > > A solution to this problem is to use type classes, and in particular > MonadTrans. You can then give an instance of MonadTypeInfer for EvalT m > where m is an instance of MonadTypeInfer, and similarly an instance > MonadEval for TypeInferT m. How this is implemented depends on the Monads in > question, but if you use the monad transformer library with newtype deriving > you can just add "deriving MonadTrans". > > class Monad m => MonadTypeInfer m where > -- functions -- > tiStuff :: X -> m Whatever > > class Monad m => MonadEval m where > -- functions -- > > instance Monad m => MonadTypeInfer (TypeInferT m) where > -- implementation -- > tiStuff = ... > > instance Monad m => MonadEval (EvalT m) where > -- implementation -- > > instance MonadEval m => MonadTypeInfer (EvalT m) where > -- lift the functions from TypeInfer through the EvalT type, > -- MonadTrans from the mtl might help here > tiStuff x = lift (tiStuff x) > > tInfer :: MonadTypeInfer m => Expr -> m Type > eval :: MonadEval m => Expr -> m Expr > > > Twan > From duncan.coutts at worc.ox.ac.uk Mon May 12 19:16:08 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon May 12 19:08:20 2008 Subject: [Haskell-cafe] GHC predictability In-Reply-To: <48289421.2070408@btinternet.com> References: <20080509212412.GE24396@scytale.galois.com> <48289421.2070408@btinternet.com> Message-ID: <1210634168.5824.107.camel@localhost> On Mon, 2008-05-12 at 20:01 +0100, Andrew Coppin wrote: > In short, as a fairly new Haskell programmer, I find it completely > impossibly to write code that doesn't crawl along at a snail's pace. > Even when I manage to make it faster, I usually have no clue why. (E.g., > adding a seq to a mergesort made it 10x faster. Why? Changing from > strict ByteString to lazy ByteString made one program 100x faster. Why?) This isn't just a little language issue. You know nothing about the data representations you're working with and then you're surprised that switching data representations makes a big difference. Have you looked up the time complexity of the operations you're using? Duncan From gale at sefer.org Mon May 12 19:27:05 2008 From: gale at sefer.org (Yitzchak Gale) Date: Mon May 12 19:20:58 2008 Subject: [Haskell-cafe] GHC predictability In-Reply-To: <48289421.2070408@btinternet.com> References: <20080509212412.GE24396@scytale.galois.com> <48289421.2070408@btinternet.com> Message-ID: <2608b8a80805121627s480ef1fgc0baa3fb4c5d79e1@mail.gmail.com> Andrew Coppin wrote: > I offer up the following example: > > mean xs = sum xs / length xs > > Now try, say, "mean [1.. 1e9]", and watch GHC eat several GB of RAM. (!!) > > If we now rearrange this to > > mean = (\(s,n) -> s / n) . foldr (\x (s,n) -> let s' = s+x; n' = n+1 in s' > `seq` n' `seq` (s', n')) (0,0) > > and run the same example, and watch it run in constant space. > > Of course, the first version is clearly readable, while the second one is > almost utterly incomprehensible, especially to a beginner. (It's even more > fun that you need all those seq calls in there to make it work properly.) You can write it like this: mean = uncurry (/) . foldl' (\(s,n) x -> ((,) $! s+x) $! n+1) (0,0) I don't think that's so bad. And for real-life examples, you almost never need the ($!)'s or seq's - your function will do some kind of pattern matching that will force the arguments. So really, all you need to remember is: if you're repeating a fast calculation across a big list, use foldl'. And insertWith', if you're storing the result in a Data.Map. That's about it. > The sad fact is that if you just write something in Haskell in a nice, > declarative style, then roughly 20% of the time you get good performance, > and 80% of the time you get laughably poor performance. I don't know why you think that. I've written a wide variety of functions over the past few years. I find that when performance isn't good enough, it's because of the algorithm, not because of laziness. Laziness works for me, not against me. Of course, it depends what you mean by "good performance". I have never needed shootout-like performance. But to get that, you need some messy optimization in any language. Regards, Yitz From dpiponi at gmail.com Mon May 12 21:10:07 2008 From: dpiponi at gmail.com (Dan Piponi) Date: Mon May 12 21:03:55 2008 Subject: [Haskell-cafe] Copy on read In-Reply-To: <404396ef0805100720vff904c1lac6a5fad44d5cf06@mail.gmail.com> References: <4825984A.4010905@btinternet.com> <404396ef0805100720vff904c1lac6a5fad44d5cf06@mail.gmail.com> Message-ID: <625b74080805121810j128b9ad1vfad1dbe4a439639b@mail.gmail.com> On Sat, May 10, 2008 at 7:20 AM, Neil Mitchell wrote: > Jurriaan Hage and Stefan Holdermans. Heap recycling for lazy > languages. In John Hatcliff, Robert Gl?ck, and Oege de Moor, editors, > _Proceedings of the 2008 ACM SIGPLAN Symposium on Partial Evaluation > and Semantics-Based Program Manipulation_, PEPM'08, San Francisco, > California, USA, January 7--8, 2008, pages 189--197. ACM Press, 2008. > http://doi.acm.org/10.1145/1328408.1328436. If I'm reading it aright, it works by tagging the types of values as unique or not but keeps that annotation secret from the programmer. The typing rules are incredibly complicated so to make things less scary, they are also hidden from the user. As a result, this idea makes it impossible for a developer to reason about whether their code will compile. That doesn't seem like a viable solution. Have I read this correctly? Cute idea though. -- Dan From jeff.polakow at db.com Mon May 12 22:18:49 2008 From: jeff.polakow at db.com (Jeff Polakow) Date: Mon May 12 22:12:42 2008 Subject: [Haskell-cafe] GHC predictability In-Reply-To: <48289421.2070408@btinternet.com> Message-ID: Hello, > I offer up the following example: > This is an instructive example. > mean xs = sum xs / length xs > In order to type-check, I actually need to write something like: mean xs = sum xs / fromIntegral (length xs) There are other ways of get the numeric types to match correctly, but this is fairly general. Then, I immediately blow my stack if I try something like: mean [1..1000000000]. The culprit is actually sum which is defined in the base libraries as either a foldl or a direct recursion depending on a compiler flag. In either case, the code is not strict enough; just trying to compute: sum [1..10000000] blows the stack. This can be easily fixed by defining a suitable strict sum: sum' = foldl' (+) 0 and now sum' has constant space. We could try to redefine mean using sum': mean1 xs = sum' xs / fromIntegral (length xs) but this still gobbles up memory. The reason is that xs is used twice and cannot be discarded as it is generated. So we must move to a direct fold, as you did, to get a space efficient mean. > If we now rearrange this to > > mean = (\(s,n) -> s / n) . foldr (\x (s,n) -> let s' = s+x; n' = n+1 > in s' `seq` n' `seq` (s', n')) (0,0) > > and run the same example, and watch it run in constant space. > This code actually blows the stack on my machine just like the first naive mean. Foldl is perhaps more intuitive to use here, since we are summing the numbers as we encounter them while walking down the list, and there is a strict version, foldl', provided in the base libraries. mean2 = uncurry (/) . foldl' (\(s,n) x -> (s+x, n+1)) (0,0) However, this still gobbles up memory... the reason is that pairs are lazy. So we need a way to force the (s+x) and (n+1). An easy, and unobtrusive way to do this is to use strict pattern matching: mean2 = uncurry (/) . foldl' (\(!s, !n) x -> (s+x, n+1)) (0,0) Now we can run: mean2 [1..1000000000] in constant space. While using an explicit foldl is less readable than the direct version (especially to a beginner), it is a standard functional idiom. Furthermore, a good understanding of lazy evaluation should be enough to guide you to using the strict foldl' and then then strict patterns. Is this a reasonable analysis? Also, we've made no attempt to address speed. However, I would argue that the code's performance time is predictable-- it grows linearly with the size of the list. Improving the performance time is another matter that requires knowing about the internal representation of the various types being used. -Jeff --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080512/bebb8e94/attachment.htm From dons at galois.com Mon May 12 22:30:43 2008 From: dons at galois.com (Don Stewart) Date: Mon May 12 22:24:35 2008 Subject: [Haskell-cafe] Re: GHC predictability Message-ID: <20080513023043.GA3520@scytale.galois.com> > I offer up the following example: > > mean xs = sum xs / length xs > > Now try, say, "mean [1.. 1e9]", and watch GHC eat several GB of RAM. (!!) But you know why, don't you? > sat down and spent the best part of a day writing an MD5 > implementation. Eventually I got it so that all the test vectors work > right. (Stupid little-endian nonsense... mutter mutter...) When I tried > it on a file containing more than 1 MB of data... ooooohhhh dear... Did you use Data.Binary or the other libraries for efficient access to gigabytes of data? > Of course, the first step in any serious attempt at performance improvement > is to actually profile the code to figure out where the time > is being spent. Well, actually, for our 'mean()' case, it means just using the right structures. Arrays for example: import Data.Array.Vector import Text.Printf mean :: UArr Double -> Double mean arr = b / fromIntegral a where k (n :*: s) a = n+1 :*: s+a a :*: b = foldlU k (0 :*: 0) arr :: (Int :*: Double) main = printf "%f\n" . mean $ enumFromToFracU 1 1e9 For example, $ time ./A 5.00000000067109e8 ./A 3.53s user 0.00s system 99% cpu 3.532 total Try allocating an array of doubles in C, and getting similar results. (The compiler is optimising this to: Main_zdszdwfold_info: leaq 32(%r12), %rax cmpq %r15, %rax movq %rax, %r12 ja .L10 movsd .LC0(%rip), %xmm0 ucomisd %xmm5, %xmm0 jae .L12 movq %rsi, (%rax) movq $base_GHCziFloat_Dzh_con_info, -24(%rax) movsd %xmm6, -16(%rax) movq $base_GHCziBase_Izh_con_info, -8(%rax) leaq -7(%rax), %rbx leaq -23(%rax), %rsi jmp *(%rbp) .L12: movapd %xmm6, %xmm0 addq $1, %rsi subq $32, %r12 addsd %xmm5, %xmm0 addsd .LC2(%rip), %xmm5 movapd %xmm0, %xmm6 jmp Main_zdszdwfold_info Note even any garbage collection. This should be pretty much the same performance-wise as unoptimised C. > almost any nontrivial program you write > spends 60% or more of its time doing GC rather than actual work. Ok, you're doing something very wrong. GC time is typically less than 15% of the running time of typical work programs I hack on. I bet you're using lists inappropriately? > I find it completely impossibly to write code that doesn't crawl along at a > snail's pace. Even when I manage to make it faster, I usually have no clue > why. I think there is a problem that few people are taking the time to understand the compilation model of Haskell, while they've had the C runtime behaviour drilled into their brains since college. Until you sit down and understand what your Haskell code means, it will be very hard to reason about optimisations, unfortunately. GHC does what it does well, and its predictable. As long as you understand the operations your trying to make predictions about. I suggest installing ghc-core, and looking at how your code is compiled. Try many examples, and have a good knowledge of the STG paper. -- Don From trebla at vex.net Mon May 12 22:51:24 2008 From: trebla at vex.net (Albert Y. C. Lai) Date: Mon May 12 22:45:11 2008 Subject: [Haskell-cafe] GHC predictability In-Reply-To: References: Message-ID: <4829022C.4040207@vex.net> Advanced technology ought to look like unpredictable magic. My experience with lazy evaluation is such that every time a program is slower or bulkier than I presumed, it is not arbitrariness, it is something new to learn. My experience with GHC is such that every surprise it gives me is a pleasant surprise: it produces a program faster or leaner than lazy evaluation would have it. "Where has the box gone?" From sjanssen at cse.unl.edu Mon May 12 23:40:21 2008 From: sjanssen at cse.unl.edu (Spencer Janssen) Date: Mon May 12 23:34:13 2008 Subject: [Haskell-cafe] GHC predictability In-Reply-To: <48289421.2070408@btinternet.com> References: <20080509212412.GE24396@scytale.galois.com> <48289421.2070408@btinternet.com> Message-ID: <20080513034021.GA24162@celeborn> On Mon, May 12, 2008 at 08:01:53PM +0100, Andrew Coppin wrote: > I offer up the following example: > > mean xs = sum xs / length xs > > Now try, say, "mean [1.. 1e9]", and watch GHC eat several GB of RAM. (!!) I don't see why the performance implications of this program are surprising. Just ask any programmer used to a strict language how much memory "[1 .. 1e9]" will require. > If we now rearrange this to > > mean = (\(s,n) -> s / n) . foldr (\x (s,n) -> let s' = s+x; n' = n+1 in > s' `seq` n' `seq` (s', n')) (0,0) > > and run the same example, and watch it run in constant space. This will use linear stack space. You probably meant to use foldl'? Better: mean = uncurry (/) . foldl' f (0, 0) where f (!s, !n) x = (s + x, n + 1) -- or, if you require Haskell '98: f (s, n) x = s `seq` n `seq` (s + x, n + 1) This version is very legible in my opinion. In fact, the algorithm is identical to what I'd write in C. Also, "mean [1 .. 1e9]" will actually work in Haskell, while in C you'll just run out of memory. Cheers, Spencer Janssen From jhc0033 at gmail.com Tue May 13 00:26:46 2008 From: jhc0033 at gmail.com (J C) Date: Tue May 13 00:20:36 2008 Subject: [Haskell-cafe] saner shootout programs In-Reply-To: <48282C51.1040706@millstream.com> References: <48282C51.1040706@millstream.com> Message-ID: On Mon, May 12, 2008 at 4:38 AM, Richard Kelsall wrote: > Hello JC, I think you've set yourself a challenge there :) Welcome to > Haskell programming. Taking a Shootout entry and playing with it is > a great way to learn Haskell. The Shootout provides an example in your > favourite previous language for comparison and a small well defined > program with exact test results you can pit your wits against. Fame > awaits you for a fast and beautiful entry. I'm still learning useful > things from the Fasta benchmark. It's surprising how many interesting > things you can discover in a small piece of code. It may be fun, but I don't think it would be meaningful. My code will be, most likely, slow, leaving some doubt as to whether it's slow because of the limitations of the compiler or my inexperience. On the other hand, if the experts can't help using malloc, unsafe*, global mutables and IO, I'll be able to conclude that this is probably what it takes to make Haskell run fast :-( From abhay.parvate at gmail.com Tue May 13 01:13:33 2008 From: abhay.parvate at gmail.com (Abhay Parvate) Date: Tue May 13 01:08:16 2008 Subject: [Haskell-cafe] Short circuiting and the Maybe monad In-Reply-To: <65113aef0805121509s6b4e76bbxd23e86070a2a0be3@mail.gmail.com> References: <65113aef0805121509s6b4e76bbxd23e86070a2a0be3@mail.gmail.com> Message-ID: <3c4d5adf0805122213w9e52794ybf1a1d1b0ed752e6@mail.gmail.com> Yes, I had always desired that the operator >>= should have been right associative for this short cut even when written without the 'do' notation. On Tue, May 13, 2008 at 3:39 AM, John Hamilton wrote: > I'm trying to understand how short circuiting works with the Maybe monad. > Take the expression n >>= f >>= g >>= h, which can be written as > (((n >>= f) >>= g) >>= h) because >>= is left associative. If n is > Nothing, this implies that (n >>= f) is Nothing, and so on, each nested > sub-expression easily evaluating to Nothing, but without there being a > quick way to short circuit at the beginning. > > Now take the example > > do x <- xs > y <- ys > z <- zs > return (x, y, z) > > which I believe desugars like > > xs >>= (\x -> ys >>= (\y -> zs >>= (\z -> return (x, y, z)))) > > Here the associativity of >>= no longer matters, and if xs is Nothing the > whole expression can quickly be determined to be Nothing, because Nothing > >>= _ = Nothing. Am I looking at this correctly? > > - John > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080513/3e2d4f68/attachment.htm From wqeqweuqy at hotmail.com Tue May 13 00:53:56 2008 From: wqeqweuqy at hotmail.com (Neal Alexander) Date: Tue May 13 02:14:00 2008 Subject: [Haskell-cafe] Parsec3 performance issues (in relation to v2) Message-ID: Just a heads up - i only have a month or so experience with Haskell, so alot of these issues may be my own fault. Anyway, the log file that i'm parsing uses English grammar, and the performance really dropped just by upgrading to Parsec3. I was hoping to use the ByteString support to boost the speed of already slow code, but had no such luck. It basicly went from "Ugh, this is kinda slow" to "Uhhhh i'm gonna go grab a burger and let this melt my CPU" haha. If anything, its probably all the look-ahead the rules have to do to get the context specific stuff right. Some of the code is here: http://hpaste.org/7578 ------------------------------------------------------------- #1 . Parsec 2: total time = 46.44 secs (2322 ticks @ 20 ms) total alloc = 16,376,179,008 bytes (excl. profiling overheads) Parse taking 51.3% time and 65.3% alloc. ------------------------------------------------------------- ------------------------------------------------------------- #2 . Parsec3 (4 times slower, no code changes): total time = 181.08 secs (9054 ticks @ 20 ms) total alloc = 46,002,859,656 bytes (excl. profiling overheads) Text.Parsec.Prim Taking 84.7% time and 86.0% alloc. ------------------------------------------------------------- ------------------------------------------------------------- #3 . Parsec3 but with the whole project converted to ByteString: (8 times slower): total time = 378.22 secs (18911 ticks @ 20 ms) total alloc = 100,051,417,672 bytes (excl. overheads) ------------------------------------------------------------- The third parse probably isn't a great indicator, since i reverted some rule-set optimizations that were causing errors. Plus i ended up packing the parsec String results to ByteStrings to fit in with everything else. I can post the full profiling info if anyone really cares. From dons at galois.com Tue May 13 02:20:22 2008 From: dons at galois.com (Don Stewart) Date: Tue May 13 02:14:23 2008 Subject: [Haskell-cafe] GHC predictability In-Reply-To: <2608b8a80805121627s480ef1fgc0baa3fb4c5d79e1@mail.gmail.com> References: <20080509212412.GE24396@scytale.galois.com> <48289421.2070408@btinternet.com> <2608b8a80805121627s480ef1fgc0baa3fb4c5d79e1@mail.gmail.com> Message-ID: <20080513062022.GA19372@scytale.galois.com> gale: > Andrew Coppin wrote: > > I offer up the following example: > > > > mean xs = sum xs / length xs > > > > Now try, say, "mean [1.. 1e9]", and watch GHC eat several GB of RAM. (!!) > > > > If we now rearrange this to > > > > mean = (\(s,n) -> s / n) . foldr (\x (s,n) -> let s' = s+x; n' = n+1 in s' > > `seq` n' `seq` (s', n')) (0,0) > > > > and run the same example, and watch it run in constant space. > > > > Of course, the first version is clearly readable, while the second one is > > almost utterly incomprehensible, especially to a beginner. (It's even more > > fun that you need all those seq calls in there to make it work properly.) > > You can write it like this: > > mean = uncurry (/) . foldl' (\(s,n) x -> ((,) $! s+x) $! n+1) (0,0) > > I don't think that's so bad. And for real-life examples, you almost > never need the ($!)'s or seq's - your function will do some kind > of pattern matching that will force the arguments. So really, all > you need to remember is: if you're repeating a fast calculation across > a big list, use foldl'. And insertWith', if you're storing the result in > a Data.Map. That's about it. > > > The sad fact is that if you just write something in Haskell in a nice, > > declarative style, then roughly 20% of the time you get good performance, > > and 80% of the time you get laughably poor performance. > > I don't know why you think that. I've written a wide variety of functions > over the past few years. I find that when performance isn't good enough, > it's because of the algorithm, not because of laziness. Laziness > works for me, not against me. > > Of course, it depends what you mean by "good performance". I have > never needed shootout-like performance. But to get that, you need > some messy optimization in any language. We can actually get great performance here, {-# LANGUAGE TypeOperators #-} import Data.Array.Vector import Text.Printf mean :: UArr Double -> Double mean arr = b / fromIntegral a where k (n :*: s) a = n+1 :*: s+a a :*: b = foldlU k (0 :*: 0) arr :: (Int :*: Double) main = printf "%f\n" . mean $ enumFromToFracU 1 1e9 ghc -O2 $ time ./A 500000000.067109 ./A 3.69s user 0.00s system 99% cpu 3.692 total Versus on lists: import Data.List import Text.Printf import Data.Array.Vector mean :: [Double] -> Double mean arr = b / fromIntegral a where k (n :*: s) a = (n+1 :*: s+a) (a :*: b) = foldl' k (0 :*: 0) arr :: (Int :*: Double) main = printf "%f\n" . mean $ [1 .. 1e9] $ time ./A 500000000.067109 ./A 66.08s user 1.53s system 99% cpu 1:07.61 total Note the use of strict pairs. Key to ensuring the accumulators end up in registers. The performance difference here is due to fold (and all left folds) not fusing in normal build/foldr fusion. The vector version runs about the same speed as unoptimsed C. -- Don From mfn-haskell-cafe at cs.york.ac.uk Tue May 13 04:16:23 2008 From: mfn-haskell-cafe at cs.york.ac.uk (Matthew Naylor) Date: Tue May 13 04:15:14 2008 Subject: [Haskell-cafe] Copy on read In-Reply-To: <4828A318.3070207@btinternet.com> References: <4825984A.4010905@btinternet.com> <20080511150212.GA4049@pc149.staff.cs.york.ac.uk> <4828A318.3070207@btinternet.com> Message-ID: <20080513081623.GA4065@pc149.staff.cs.york.ac.uk> Hi Andrew, my probably dodgy reason for mentioning deforestation is that sharing of intermediate values is a major stumbling block; code that uses data linearly is possibly well suited for deforesting. See Frankau's SASL for a language that deforests all lists simply by not letting you copy them! (IIRC there is another constraint that forbids accumulating parameters too.) > Similarly, there are recursion patterns for which fusion isn't very > easy. Yep, I suspect you're right. > That's why most array-based code is explicitly in-place. wouldn't > it be nice if it didn't have to be? I agree. As an aside, DiffArray looks quite nice: http://www.haskell.org/haskellwiki/Modern_array_libraries ``if a diff array is used in a single-threaded style, ..., a!i takes O(1) time and a//d takes O(length d).'' Notice the use of "seq" in 2nd example to enforce a kind of single-threaded behaviour. Seems nasty! I wonder if this could be avoided by providing a (*!*) such that arr *!* i = seq x (arr, x) where x = arr ! i It returns a new array which the programmer should use if they want single-threaded behaviour. Matt. From abhay.parvate at gmail.com Tue May 13 06:56:59 2008 From: abhay.parvate at gmail.com (Abhay Parvate) Date: Tue May 13 06:50:57 2008 Subject: [Haskell-cafe] GHC predictability In-Reply-To: References: <48289421.2070408@btinternet.com> Message-ID: <3c4d5adf0805130356rf0ff8f2g5ad10e5baaeeaaa3@mail.gmail.com> I don't know why, but perhaps beginners may expect too much from the laziness, almost to the level of magic (me too, in the beginning!). In an eager language, a function like mean :: (Fractional a) => [a] -> a expects the *whole* list before it can calculate the mean, and the question of the 'mean' function consuming memory does not arise. We look for other methods of finding the mean of very long lists. We do not expect such a function in C or Scheme to succeed when the number of numbers is more than that can fit the memory. (It will not even be called; the list creation itself will not succeed.) Lazy languages allow us to use the same abstraction while allowing doing more. But it is not magic, it is plain normal order evaluation. Just as every Scheme programmer or C programmer must understand the consequences of the fact that the arguments to a function will be evaluated first, a Haskell programmer must understand the consequences of the fact that the arguments to a function will be evaluated only when needed/forced. Perhaps an early emphasis on an understanding of normal order evaluation is needed while learning Haskell in order to stop expecting magic, especially when one comes prejudiced from eager languages. Regards Abhay -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080513/ee169301/attachment.htm From allbery at ece.cmu.edu Tue May 13 09:38:05 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Tue May 13 09:31:56 2008 Subject: [Haskell-cafe] saner shootout programs In-Reply-To: References: <48282C51.1040706@millstream.com> Message-ID: <8B912FC6-AE18-4AF1-954A-F382AC9624F3@ece.cmu.edu> On 2008 May 13, at 0:26, J C wrote: > On the other hand, if the experts can't help using malloc, unsafe*, > global mutables and IO, I'll be able to conclude that this is probably > what it takes to make Haskell run fast :-( Very few of the shootout entries have been revisited since most of the improvements to list and stream fusion, etc. in GHC, if I can trust the amount of discussion of shootout entries I've seen on IRC. Some of them are still vintage 6.4.2, which had very little in the way of compiler smarts so hand optimization was crucial. 6.8.2, on the other hand, does much better all by itself as long as you don't e.g. use lists in stupid ways. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From allbery at ece.cmu.edu Tue May 13 09:55:28 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Tue May 13 09:49:19 2008 Subject: [Haskell-cafe] GHC predictability In-Reply-To: References: Message-ID: On 2008 May 12, at 22:18, Jeff Polakow wrote: > Then, I immediately blow my stack if I try something like: > > mean [1..1000000000]. > > The culprit is actually sum which is defined in the base libraries > as either a foldl or a direct recursion depending on a compiler > flag. In either case, the code is not strict enough; just trying to > compute: > > sum [1..10000000] There's also an insufficient-laziness issue with enumerations in at least some versions of the standard library, IIRC. meaning that just saying [1..10000000] can introduce a space leak that can lead to a stack blowout. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080513/5948ffcf/attachment.htm From r.kelsall at millstream.com Tue May 13 10:10:54 2008 From: r.kelsall at millstream.com (Richard Kelsall) Date: Tue May 13 10:04:47 2008 Subject: [Haskell-cafe] saner shootout programs In-Reply-To: References: <48282C51.1040706@millstream.com> Message-ID: <4829A16E.9000506@millstream.com> J C wrote: > wrote: > >> Hello JC, I think you've set yourself a challenge there :) Welcome to >> Haskell programming. Taking a Shootout entry and playing with it is >> a great way to learn Haskell. The Shootout provides an example in your >> favourite previous language for comparison and a small well defined >> program with exact test results you can pit your wits against. Fame >> awaits you for a fast and beautiful entry. I'm still learning useful >> things from the Fasta benchmark. It's surprising how many interesting >> things you can discover in a small piece of code. > > It may be fun, but I don't think it would be meaningful. My code will > be, most likely, slow, leaving some doubt as to whether it's slow > because of the limitations of the compiler or my inexperience. > > On the other hand, if the experts can't help using malloc, unsafe*, > global mutables and IO, I'll be able to conclude that this is probably > what it takes to make Haskell run fast :-( Don't tell the experts who wrote the current shootout entries, but the playing field is tilted radically in favour of us beginners being able to improve on their entries because of new versions of GHC and new tools that have been developed since they wrote their entries. GHC will now automatically perform many of the optimisations that used to have to be done by hand. For example I was surprised to discover the other day when working on Fasta that putting this plain and simple version of splitAt splitAt n (x : xs) = (x : xs', xs'') where (xs', xs'') = splitAt (n-1) xs in my program made it run more quickly than using the built-in version of splitAt which I now know looks like (ug!) this splitAt (I# n#) ls | n# <# 0# = ([], ls) | otherwise = splitAt# n# ls where splitAt# :: Int# -> [a] -> ([a], [a]) splitAt# 0# xs = ([], xs) splitAt# _ xs@[] = (xs, xs) splitAt# m# (x:xs) = (x:xs', xs'') where (xs', xs'') = splitAt# (m# -# 1#) xs because I was compiling my splitAt with -O2 optimisation as opposed to the built-in version being compiled with -O. The extra optimisations in -O2 are a new feature of GHC (and -O2 is slower to compile which is why the built-in version doesn't use it, but that doesn't matter for the shootout). You may similarly find various elaborations in the shootout entries that were historically necessary for speed or memory reasons, but which can now be removed because GHC or new libraries do the work for us. Have a go and see what happens to the speed when you change things to make N-body more readable. I would bet money on there being simple tweaks which will make it simultaneously faster and more readable. Richard. From s.clover at gmail.com Tue May 13 10:37:24 2008 From: s.clover at gmail.com (Sterling Clover) Date: Tue May 13 10:31:12 2008 Subject: [Haskell-cafe] saner shootout programs In-Reply-To: References: <48282C51.1040706@millstream.com> Message-ID: Well, it would be meaningful for your own experience in learning Haskell. Some time ago somebody took a shot at nbodies using pure immutable structures, and as I recall, got within about 4x the performance of mutable structures. In 6.6, an STArray based approach was maybe 2x slower, but by now it may well be comparable, as Dons pointed out. In fact, lots of the shootout entries could use an overhaul now that 6.8 is running on their machines, as plenty of older, uglier, optimizations are probably preformed as efficiently if not more so by the newer GHC, whose strictness analysis, for example, is consistently and pleasantly surprising. If you take a stab at some of these benchmarks, with some helpful guidance from #haskell, you'll no doubt get a much better sense of how memory and performance works in haskell, and which tweaks are just there for the last 2%. So even if you can't beat the current winners (and given the compiler changes, you may well be able to) you'll still come out ahead in the process. As for the clean entry though, it no doubt relies heavily on uniqueness typing and so is secretly mutating like crazy under the hood. Cheers, S. On Tue, May 13, 2008 at 12:26 AM, J C wrote: > On Mon, May 12, 2008 at 4:38 AM, Richard Kelsall > wrote: > > > Hello JC, I think you've set yourself a challenge there :) Welcome to > > Haskell programming. Taking a Shootout entry and playing with it is > > a great way to learn Haskell. The Shootout provides an example in your > > favourite previous language for comparison and a small well defined > > program with exact test results you can pit your wits against. Fame > > awaits you for a fast and beautiful entry. I'm still learning useful > > things from the Fasta benchmark. It's surprising how many interesting > > things you can discover in a small piece of code. > > It may be fun, but I don't think it would be meaningful. My code will > be, most likely, slow, leaving some doubt as to whether it's slow > because of the limitations of the compiler or my inexperience. > > On the other hand, if the experts can't help using malloc, unsafe*, > global mutables and IO, I'll be able to conclude that this is probably > what it takes to make Haskell run fast :-( > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080513/575755c3/attachment.htm From darrinth at gmail.com Tue May 13 10:55:59 2008 From: darrinth at gmail.com (Darrin Thompson) Date: Tue May 13 10:49:46 2008 Subject: [Haskell-cafe] GHC predictability In-Reply-To: <20080513062022.GA19372@scytale.galois.com> References: <20080509212412.GE24396@scytale.galois.com> <48289421.2070408@btinternet.com> <2608b8a80805121627s480ef1fgc0baa3fb4c5d79e1@mail.gmail.com> <20080513062022.GA19372@scytale.galois.com> Message-ID: On Tue, May 13, 2008 at 2:20 AM, Don Stewart wrote: > Note the use of strict pairs. Key to ensuring the accumulators end up in > registers. The performance difference here is due to fold (and all left > folds) not fusing in normal build/foldr fusion. > > The vector version runs about the same speed as unoptimsed C. > These "tricks" going into Real World Haskell? When you say someone needs to get familiar with the "STG paper" it scares me (a beginner) off a little, an I've been making an effort to approach the papers. I could barely understand the Fusion one and getting familiar with compiler internals sounds like something I'd not be ready for. Probably if I really looked at ghc-core I'd be pleasantly surprised but I'm totally biased against even looking. Gcc is hard to read, thus ghc is also. So while you are right about all this when you say it, I think your goal is to persuade. RWH has some of the best practical prose I've read yet. Well done there. Hopefully chapter 26 will be crammed full of this stuff? -- Darrin From graham.fawcett at gmail.com Tue May 13 11:23:35 2008 From: graham.fawcett at gmail.com (Graham Fawcett) Date: Tue May 13 11:17:28 2008 Subject: [Haskell-cafe] Short circuiting and the Maybe monad In-Reply-To: <65113aef0805121509s6b4e76bbxd23e86070a2a0be3@mail.gmail.com> References: <65113aef0805121509s6b4e76bbxd23e86070a2a0be3@mail.gmail.com> Message-ID: On Mon, May 12, 2008 at 6:09 PM, John Hamilton wrote: > I'm trying to understand how short circuiting works with the Maybe monad. > Take the expression n >>= f >>= g >>= h, which can be written as > (((n >>= f) >>= g) >>= h) because >>= is left associative. If n is > Nothing, this implies that (n >>= f) is Nothing, and so on, each nested > sub-expression easily evaluating to Nothing, but without there being a > quick way to short circuit at the beginning. Yes, but that's still a 'quick' short-circuiting. In your example, if 'n' is Nothing, then the 'f >>= g >>= h' thunks will not be forced (thanks to lazy evaluation), regardless of associativity. Tracing verifies this: > import Debug.Trace > talk s = Just . (trace s) > f = talk "--f" > g = talk "--g" > h = talk "--h" > foo n = n >>= f >>= g >>= h *Main> foo (Just 3) Just --h --g --f 3 *Main> foo Nothing Nothing I suspect the cost of creating and discarding those unused thunks is negligible, so in effect the associativity of the bind operator is irrelevant here. Graham From nominolo at googlemail.com Tue May 13 11:37:56 2008 From: nominolo at googlemail.com (Thomas Schilling) Date: Tue May 13 11:31:52 2008 Subject: [Haskell-cafe] Re: [Haskell] Re: ANN: Haddock version 2.1.0 In-Reply-To: <016401c8b224$6b0b5250$5a307ad5@cr3lt> References: <481A46C0.3050209@gmail.com> <012e01c8ac61$cc2f0d60$bf078351@cr3lt> <4822F24B.4040801@microsoft.com> <4824165B.60800@gmail.com> <016401c8b224$6b0b5250$5a307ad5@cr3lt> Message-ID: <916b84820805130837s677e2b42jeccb325fdb67e9c@mail.gmail.com> Feel free to CC me or the ticket with things like that. I'll be working on this for this year's GSoC and it'd be helpful to find out what I should tackle first. On Fri, May 9, 2008 at 8:30 PM, Claus Reinke wrote: > > > > Ah, I didn't think about the GHC options that change the lexical > > syntax. You're right, using the GHC lexer should be easier. > > > > and, if you do that, you could also make the GHC lexer > squirrel away the comments (including pragmas, if they aren't > already in the AST) someplace safe, indexed by, or at least annotated with, > their source locations, and make this comment/ > pragma storage available via the GHC API. (1a) > > then, we'd need a way to merge those comments and pragmas > back into the output during pretty printing, and we'd have made > the first small step towards source-to-source transformations: making code > survive semantically intact over (pretty . parse). (1b) > > that would still not quite fullfill the GHC API comment ticket (*), > but that was only a quick sketch, not a definite design. it might be > sufficient to let each GHC API client do its own search to associate bits of > comment/pragma storage with bits of AST. > if i understand you correctly, you are going to do (1a), so > if you could add that to the GHC API, we'd only need (1b) > to go from useable-for-analysis-and-extraction to > useable-for-transformation. > > is that going to be a problem? > > claus > > (*) knowing the source location of some piece of AST is not > sufficient for figuring out whether it has any immediately > preceding or following comments (there might be other AST > fragments in between, closer to the next comment). > but, if one knows the nearest comment segment for each piece of AST, one > could then build a map where the closest > AST pieces are mapped to (Just commentID), and the other > AST pieces are mapped to Nothing. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From bulat.ziganshin at gmail.com Tue May 13 11:38:36 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue May 13 11:33:57 2008 Subject: [Haskell-cafe] saner shootout programs In-Reply-To: <4829A16E.9000506@millstream.com> References: <48282C51.1040706@millstream.com> <4829A16E.9000506@millstream.com> Message-ID: <1881893895.20080513193836@gmail.com> Hello Richard, Tuesday, May 13, 2008, 6:10:54 PM, you wrote: > because I was compiling my splitAt with -O2 optimisation as opposed > to the built-in version being compiled with -O. The extra optimisations > in -O2 are a new feature of GHC (and -O2 is slower to compile which is > why the built-in version doesn't use it, but that doesn't matter for the > shootout). -O2 is very old ghc feature and i think that ghc base library is compiled with -O2 - it's too obvious idea -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From r.kelsall at millstream.com Tue May 13 11:56:36 2008 From: r.kelsall at millstream.com (Richard Kelsall) Date: Tue May 13 11:50:26 2008 Subject: [Haskell-cafe] saner shootout programs In-Reply-To: <1881893895.20080513193836@gmail.com> References: <48282C51.1040706@millstream.com> <4829A16E.9000506@millstream.com> <1881893895.20080513193836@gmail.com> Message-ID: <4829BA34.6070205@millstream.com> Bulat Ziganshin wrote: > Hello Richard, > > Tuesday, May 13, 2008, 6:10:54 PM, you wrote: > >> because I was compiling my splitAt with -O2 optimisation as opposed >> to the built-in version being compiled with -O. The extra optimisations >> in -O2 are a new feature of GHC (and -O2 is slower to compile which is >> why the built-in version doesn't use it, but that doesn't matter for the >> shootout). > > -O2 is very old ghc feature and i think that ghc base library is > compiled with -O2 - it's too obvious idea > In July 2007 -O2 was documented in GHC as making no difference to the speed of programs : http://www.haskell.org/pipermail/haskell-cafe/2007-July/029118.html and from this thread http://www.haskell.org/pipermail/haskell-cafe/2008-April/042155.html it appears to be currently unused for splitAt. I guess -O2 has however been around for a long time. Richard. From bulat.ziganshin at gmail.com Tue May 13 12:04:42 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue May 13 11:59:27 2008 Subject: [Haskell-cafe] saner shootout programs In-Reply-To: <4829BA34.6070205@millstream.com> References: <48282C51.1040706@millstream.com> <4829A16E.9000506@millstream.com> <1881893895.20080513193836@gmail.com> <4829BA34.6070205@millstream.com> Message-ID: <1522825917.20080513200442@gmail.com> Hello Richard, Tuesday, May 13, 2008, 7:56:36 PM, you wrote: > In July 2007 -O2 was documented in GHC as making no difference to > the speed of programs : > http://www.haskell.org/pipermail/haskell-cafe/2007-July/029118.html it's because ghc is 15 years old and its documentation may be not updated as things changes :) > and from this thread > http://www.haskell.org/pipermail/haskell-cafe/2008-April/042155.html > it appears to be currently unused for splitAt. i've read this thread. it was just assumption - don't believe it before you have checked it -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From barsoap at web.de Tue May 13 12:13:29 2008 From: barsoap at web.de (Achim Schneider) Date: Tue May 13 12:07:25 2008 Subject: [Haskell-cafe] Re: GHC predictability References: <20080509212412.GE24396@scytale.galois.com> <48289421.2070408@btinternet.com> <2608b8a80805121627s480ef1fgc0baa3fb4c5d79e1@mail.gmail.com> <20080513062022.GA19372@scytale.galois.com> Message-ID: <20080513181329.2d8dc416@solaris> "Darrin Thompson" wrote: > On Tue, May 13, 2008 at 2:20 AM, Don Stewart wrote: > > Note the use of strict pairs. Key to ensuring the accumulators > > end up in registers. The performance difference here is due to > > fold (and all left folds) not fusing in normal build/foldr fusion. > > > > The vector version runs about the same speed as unoptimsed C. > > > > These "tricks" going into Real World Haskell? When you say someone > needs to get familiar with the "STG paper" it scares me (a beginner) > off a little, an I've been making an effort to approach the papers. I > could barely understand the Fusion one and getting familiar with > compiler internals sounds like something I'd not be ready for. > Probably if I really looked at ghc-core I'd be pleasantly surprised > but I'm totally biased against even looking. Gcc is hard to read, thus > ghc is also. So while you are right about all this when you say it, I > think your goal is to persuade. RWH has some of the best practical > prose I've read yet. Well done there. Hopefully chapter 26 will be > crammed full of this stuff? > You know, sometimes I wish this would be the Eve forums, so that I could just answer "FAIL". Anyway, the goal of the Haskell community is to prevent success at any cost, so anything that is done to ease things for noobs that is not purely meant to prevent anyone from asking questions will be warded off by automatic defence systems of the big ivory tower, which are reinforced faster than you can ever hope to understand any topic. To get a bit more on-topic: I currently completely fail to implement a layout rule in Parsec because I don't understand its inner workings, and thus constantly mess up my state. Parsec's ease of usage is deceiving as soon as you use more than combinators: Suddenly the plumbing becomes important, and hackage is full of such things. Haskell has potentially infinite learning curves, and each one of them usually represents a wall. To make them crumble, you have to get used to not understand anything until you understand everything. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. From r.kelsall at millstream.com Tue May 13 12:23:59 2008 From: r.kelsall at millstream.com (Richard Kelsall) Date: Tue May 13 12:17:51 2008 Subject: [Haskell-cafe] saner shootout programs In-Reply-To: <1522825917.20080513200442@gmail.com> References: <48282C51.1040706@millstream.com> <4829A16E.9000506@millstream.com> <1881893895.20080513193836@gmail.com> <4829BA34.6070205@millstream.com> <1522825917.20080513200442@gmail.com> Message-ID: <4829C09F.4010205@millstream.com> Bulat Ziganshin wrote: > Hello Richard, > >> In July 2007 -O2 was documented in GHC as making no difference to >> the speed of programs : > >> http://www.haskell.org/pipermail/haskell-cafe/2007-July/029118.html > > it's because ghc is 15 years old and its documentation may be not > updated as things changes :) > >> and from this thread > >> http://www.haskell.org/pipermail/haskell-cafe/2008-April/042155.html > >> it appears to be currently unused for splitAt. > > i've read this thread. it was just assumption - don't believe it > before you have checked it > Hello Bulat, Yes it was just a plausible guess, but not contradicted by the experts. And that was using the Windows version of GHC so other versions may have better optimisation. I don't know how to check, maybe the experts can illuminate the subject? Richard. From tanielsen at gmail.com Tue May 13 12:27:34 2008 From: tanielsen at gmail.com (Tom Nielsen) Date: Tue May 13 12:21:21 2008 Subject: [Haskell-cafe] Analog data acquisition Message-ID: <78dc001e0805130927g72aac077yaae100ae90008297@mail.gmail.com> Hello, I would like to use a lazy, purely functional language to create an experiement description (and execution!) language for cellular neuroscience, i.e. electrical recordings and stimulation. Unfortunately, this means I have to talk to a Analog-to-Digital/Digital-to-Analog converter board, with a precision of about 16 bit at a rate of 50 kHz. I currently have a National Instruments M-series board, but would be happy to try another board. I'm not looking for real-time control right now, but that might be of interest in the future. Has anyone looked at creating bindings to the NI-DAQmx drivers or the open-source COMEDI project, or similar hardware? Would anyone be interested in helping out with this driver binding? Regards Tom From leosieb at arcor.de Tue May 13 12:29:10 2008 From: leosieb at arcor.de (Leonard Siebeneicher) Date: Tue May 13 12:22:58 2008 Subject: [Haskell-cafe] Instance of Eq on cyclic data structure? Message-ID: <4829C1D6.7030105@arcor.de> Hi. I am testing a winged edge data structure. > module Main where > > type Point3 = (Float, Float, Float) > > data Body= Body [Vertex] [Edge] [Face] deriving(Eq) > data Face= Face Edge deriving(Eq) > data Edge= Edge (Vertex, Vertex) > (Face, Face) > (Edge, Edge) > (Edge, Edge) deriving(Eq) > data Vertex= Vertex Point3 Edge deriving(Eq) ... > --- Face, Edge, Vertex: Conversion > > getVertsFromFace :: Face -> [Vertex] > getVertsFromFace (Face startEdge) = process_wing_clockwise startEdge > where > process_wing_clockwise (Edge > (vp, _) > _ > (_, eWing1) > _) > | startEdge == eWing1 = > [vp] > | otherwise = > vp : (process_wing_clockwise eWing1) > > > --- Misc procedures > printPointList :: [Vertex] -> IO () > printPointList [] = return () > printPointList ((Vertex p _ ):vs) = putStr (show p) >> > printPointList vs > > --- main > main = > do > let q = createQuad (0,0,0) (0,1,0) (1,1,0) (1,0,0) > let f = (\(Body _ _ (face:faces)) -> face) q > let verts = getVertsFromFace f > printPointList verts > > Here I get a error message. > (0.0,0.0,0.0)(0.0,1.0,0.0)(1.0,1.0,0.0)runhugs: Error occurred > > ERROR - Control stack overflow > I think this come because the derived Eq-Instance "==" get into an infinite loop Alternatively I tried following > --- We want to identify each Body, Face, Edge or Vertex by a number ID > type ID = Int --- A special number for identifying, used for Eq > > data Body = Body ID [Vertex] [Edge] [Face] > data Face = Face ID (Edge) > data Edge = Edge ID > (Vertex , Vertex) > (Face , Face) > (Edge , Edge) > (Edge , Edge) > data Vertex = Vertex ID Edge > > --- Eq Instances > instance Eq Vertex) where > (Vertex i1 _) == (Vertex i2 _) = i1 == i2 > > instance Eq Face where > (Face i1 _ ) == (Face i2 _) = i1 == i2 > > instance Eq Edge where > (Edge i1 _ _ _ _) == (Edge i2 _ _ _ _) = i1 == i2 > > > instance Eq (Body) where > (Body i1 _ _ _) == (Body i2 _ _ _) = i1 == i2 ... This way my code does not hang up. But I have to manage those ugly ID's. Is there a better way to create instances of class Eq, without something like ID? Thanks for reading. Best regards, Leonard > > > -------------------- > -------------------- > ---- Begin ---- > -------------------- > module Main where > > type Point3 = (Float, Float, Float) > > data Body= Body [Vertex] [Edge] [Face] deriving(Eq) > data Face= Face Edge deriving(Eq) > data Edge= Edge (Vertex, Vertex) > (Face, Face) > (Edge, Edge) > (Edge, Edge) deriving(Eq) > data Vertex= Vertex Point3 Edge deriving(Eq) > > {- > implementing simple generative modelling > -} > > --- elementar object generation > createQuad :: Point3 -> > Point3 -> > Point3 -> > Point3 -> > Body > > createQuad p0 p1 p2 p3 = > let > {faceFront = Face edge0 > ;faceBack = Face edge2 > ;vert0 = Vertex p0 edge0 > ;edge0 = Edge > (vert0, vert1) > (faceFront, faceBack) > (edge3, edge1) > (edge1, edge3) > ;vert1 = Vertex p1 edge1 > ;edge1 = Edge > (vert1, vert2) > (faceFront, faceBack) > (edge0, edge2) > (edge2, edge0) > ;vert2 = Vertex p2 edge2 > ;edge2 = Edge > (vert2, vert3) > (faceFront, faceBack) > (edge1, edge3) > (edge3, edge1) > ;vert3 = Vertex p3 edge3 > ;edge3 = Edge > (vert3, vert0) > (faceFront, faceBack) > (edge2, edge0) > (edge0, edge2) > } > in > Body [vert0, vert1, vert2, vert3] [edge0, edge1, edge2, edge3] > [faceFront, faceBack] > > --- Face, Edge, Vertex: Conversion > > getVertsFromFace :: Face -> [Vertex] > getVertsFromFace (Face startEdge) = process_wing_clockwise startEdge > where > process_wing_clockwise (Edge > (vp, _) > _ > (_, eWing1) > _) > | startEdge == eWing1 = > [vp] > | otherwise = > vp : (process_wing_clockwise eWing1) > > > --- Misc procedures > printPointList :: [Vertex] -> IO () > printPointList [] = return () > printPointList ((Vertex p _ ):vs) = putStr (show p) >> > printPointList vs > > --- main > main = > do > let q = createQuad (0,0,0) (0,1,0) (1,1,0) (1,0,0) > let f = (\(Body _ _ (face:faces)) -> face) q > let verts = getVertsFromFace f > printPointList verts > ----------------- > ---- End ---- From jules at jellybean.co.uk Tue May 13 13:39:12 2008 From: jules at jellybean.co.uk (Jules Bean) Date: Tue May 13 13:33:48 2008 Subject: [Haskell-cafe] Data.Dynamic over the wire Message-ID: <4829D240.60504@jellybean.co.uk> > {-# LANGUAGE ScopedTypeVariables #-} Data.Dynamic gives a passable impression of adding support for dynamically typed code and runtime typing to GHC, without changing the basic statically typed, all types known at runtime nature of the language. Note that Data.Dynamic relies upon two things: it relies upon a concrete representation of types, given by TypeRep, and a primitive which has to be provided by the compiler to actually implement fromDynamic. (In GHC it uses unsafeCoerce# which is already available, but you could imagine providing other primitives). In principle TypeReps could be derived by hand, although if you do so you can break everything by providing invalid instances. In practice we'd rather the compiler did it for us and guaranteed safety. You can do all sorts of things with Dynamic, but the general pattern is that data which has some fixed, known type, can be passed through a chunk of code which doesn't know its type (wrapped in Dynamic) and then eventually consumed by another piece of code which *does* know the type, and can unwrap it. The consuming code has to know the type to unwrap it, although it can 'guess' various alternatives if it wants, and thus type safety is preserved. One thing which you can't obviously do is write Read or Show instances for Dynamic. So can we pass Dynamic data over the wire? If not, Dynamic is limited to the context of "within a single program", and can't be used over the network between cooperating programs, or in file formats, etc. You can try this: > import Data.Typeable > data SerialisedDynamic = SD TypeRep String deriving (Show) > freeze :: (Show a, Typeable a) => a -> SerialisedDynamic > freeze x = SD (typeOf x) (show x) > thaw :: forall a . (Read a, Typeable a) => SerialisedDynamic -> Maybe a > thaw (SD t s) = if typeOf (undefined :: a) == t then > Just (read s) > else Nothing This is close, and works as far as it goes. It is a limited reimplementation of Dynamic which uses show/read instead of unsafeCoerce#. As such it is pure haskell (but relies on Typeable instances). You can't finish it off because you can't derive a 'Read' instance for SD, because there is no read instance for TypeRep. Off-hand I can't think of any reason why there can't be a Read instance for TypeRep, but it would be a bit tricky with the current TypeRep because of the way its implemented, I think. You need to take care about globally qualified types and might want to use package names like ghc does in its linking phase, but those are definitely surmountable problems. Having said all that, I'm not sure how useful this really is. Most of the time you could use this, you could equally just pass around the String and 'read' it once you get to the place where you want to use the value. Practical over-the-wire protocols necessarily have some kind of tagging mechanism, and all this adds is a global "tag table" for Typeable types via TypeRep. Jules From olivier.boudry at gmail.com Tue May 13 13:42:48 2008 From: olivier.boudry at gmail.com (Olivier Boudry) Date: Tue May 13 13:36:36 2008 Subject: [Haskell-cafe] hsc2hs: expanding macros in the .hsc file Message-ID: Hi all, Is it possible to expand macros defined in includes into the .hsc file? I'm trying to call functions from a library written in C. The library can be used with or without Unicode chars, depending on #define instructions. The library has macros for all the standard functions used to work on strings (malloc, strlen, strcpy, strtok, ...). So that in code using the library one can always call the macro and don't care about the char type (strlenU instead of wcslen or strlen). Macro expansion will define which function will be used depending on the SAPwithUNICODE #define. I put a very simplified example below. The original file contains much more conditions (OS, Unicode or not, little or big endian, ...). #define strlenU SAP_UNAME(strlen) #ifdef SAPwithUNICODE #define SAP_UNAME(name) name##U16 #else #define SAP_UNAME(name) name #endif #if defined(WCHAR_is_2B) #define strlenU16 wcslen #endif I would like to be able to expand strlenU in my .hsc file and get the correct function. foreign import ccall "static sapuc.h strlenU" f_strlenU :: Ptr (#type SAP_UC) -> IO (#type size_t) I would like to be able to expand the strlenU macro to the real function name (wcslen or strlen). Is there a way to do this? Thanks, Olivier. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080513/654b6137/attachment.htm From bulat.ziganshin at gmail.com Tue May 13 13:58:39 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue May 13 13:54:25 2008 Subject: [Haskell-cafe] Data.Dynamic over the wire In-Reply-To: <4829D240.60504@jellybean.co.uk> References: <4829D240.60504@jellybean.co.uk> Message-ID: <781059647.20080513215839@gmail.com> Hello Jules, Tuesday, May 13, 2008, 9:39:12 PM, you wrote: > This is close, and works as far as it goes. It is a limited > reimplementation of Dynamic which uses show/read instead of there are gread/gshow funcs. don't know how these works, though :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From lennart at augustsson.net Tue May 13 14:01:57 2008 From: lennart at augustsson.net (Lennart Augustsson) Date: Tue May 13 13:55:58 2008 Subject: [Haskell-cafe] Instance of Eq on cyclic data structure? In-Reply-To: <4829C1D6.7030105@arcor.de> References: <4829C1D6.7030105@arcor.de> Message-ID: Using IDs is the only way. Haskell has no concept of circular data structures. An implementation might use them internally, but there is no such language concept. So what you have are infinitely unfolding trees and they cannot be compared for equality. -- Lennart On Tue, May 13, 2008 at 5:29 PM, Leonard Siebeneicher wrote: > Hi. > > I am testing a winged edge data structure. > > module Main where >> >> type Point3 = (Float, Float, Float) >> >> data Body= Body [Vertex] [Edge] [Face] deriving(Eq) >> data Face= Face Edge deriving(Eq) >> data Edge= Edge (Vertex, Vertex) >> (Face, Face) >> (Edge, Edge) >> (Edge, Edge) deriving(Eq) >> data Vertex= Vertex Point3 Edge deriving(Eq) >> > ... > >> --- Face, Edge, Vertex: Conversion >> >> getVertsFromFace :: Face -> [Vertex] >> getVertsFromFace (Face startEdge) = process_wing_clockwise startEdge >> where >> process_wing_clockwise (Edge >> (vp, _) >> _ >> (_, eWing1) >> _) >> | startEdge == eWing1 = >> [vp] >> | otherwise = >> vp : (process_wing_clockwise eWing1) >> >> >> --- Misc procedures >> printPointList :: [Vertex] -> IO () >> printPointList [] = return () >> printPointList ((Vertex p _ ):vs) = putStr (show p) >> >> printPointList vs >> >> --- main >> main = >> do >> let q = createQuad (0,0,0) (0,1,0) (1,1,0) (1,0,0) >> let f = (\(Body _ _ (face:faces)) -> face) q >> let verts = getVertsFromFace f >> printPointList verts >> >> >> Here I get a error message. > > (0.0,0.0,0.0)(0.0,1.0,0.0)(1.0,1.0,0.0)runhugs: Error occurred >> >> ERROR - Control stack overflow >> >> I think this come because the derived Eq-Instance "==" get into an > infinite loop > > Alternatively I tried following > >> --- We want to identify each Body, Face, Edge or Vertex by a number ID >> type ID = Int --- A special number for identifying, used for Eq >> >> data Body = Body ID [Vertex] [Edge] [Face] >> data Face = Face ID (Edge) >> data Edge = Edge ID >> (Vertex , Vertex) >> (Face , Face) >> (Edge , Edge) >> (Edge , Edge) >> data Vertex = Vertex ID Edge >> >> --- Eq Instances >> instance Eq Vertex) where >> (Vertex i1 _) == (Vertex i2 _) = i1 == i2 >> >> instance Eq Face where >> (Face i1 _ ) == (Face i2 _) = i1 == i2 >> >> instance Eq Edge where >> (Edge i1 _ _ _ _) == (Edge i2 _ _ _ _) = i1 == i2 >> >> >> instance Eq (Body) where >> (Body i1 _ _ _) == (Body i2 _ _ _) = i1 == i2 >> > ... > > This way my code does not hang up. But I have to manage those ugly ID's. > Is there a better way to create instances of class Eq, without something > like ID? > > Thanks for reading. > > Best regards, Leonard > > > >> >> -------------------- >> -------------------- >> ---- Begin ---- >> -------------------- >> module Main where >> >> type Point3 = (Float, Float, Float) >> >> data Body= Body [Vertex] [Edge] [Face] deriving(Eq) >> data Face= Face Edge deriving(Eq) >> data Edge= Edge (Vertex, Vertex) >> (Face, Face) >> (Edge, Edge) >> (Edge, Edge) deriving(Eq) >> data Vertex= Vertex Point3 Edge deriving(Eq) >> >> {- >> implementing simple generative modelling >> -} >> >> --- elementar object generation >> createQuad :: Point3 -> >> Point3 -> >> Point3 -> >> Point3 -> >> Body >> >> createQuad p0 p1 p2 p3 = >> let >> {faceFront = Face edge0 >> ;faceBack = Face edge2 >> ;vert0 = Vertex p0 edge0 >> ;edge0 = Edge >> (vert0, vert1) >> (faceFront, faceBack) >> (edge3, edge1) >> (edge1, edge3) >> ;vert1 = Vertex p1 edge1 >> ;edge1 = Edge >> (vert1, vert2) >> (faceFront, faceBack) >> (edge0, edge2) >> (edge2, edge0) >> ;vert2 = Vertex p2 edge2 >> ;edge2 = Edge >> (vert2, vert3) >> (faceFront, faceBack) >> (edge1, edge3) >> (edge3, edge1) >> ;vert3 = Vertex p3 edge3 >> ;edge3 = Edge >> (vert3, vert0) >> (faceFront, faceBack) >> (edge2, edge0) >> (edge0, edge2) >> } >> in >> Body [vert0, vert1, vert2, vert3] [edge0, edge1, edge2, edge3] >> [faceFront, faceBack] >> >> --- Face, Edge, Vertex: Conversion >> >> getVertsFromFace :: Face -> [Vertex] >> getVertsFromFace (Face startEdge) = process_wing_clockwise startEdge >> where >> process_wing_clockwise (Edge >> (vp, _) >> _ >> (_, eWing1) >> _) >> | startEdge == eWing1 = >> [vp] >> | otherwise = >> vp : (process_wing_clockwise eWing1) >> >> >> --- Misc procedures >> printPointList :: [Vertex] -> IO () >> printPointList [] = return () >> printPointList ((Vertex p _ ):vs) = putStr (show p) >> >> printPointList vs >> >> --- main >> main = >> do >> let q = createQuad (0,0,0) (0,1,0) (1,1,0) (1,0,0) >> let f = (\(Body _ _ (face:faces)) -> face) q >> let verts = getVertsFromFace f >> printPointList verts >> ----------------- >> ---- End ---- >> > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080513/13946657/attachment.htm From stansife at caltech.edu Tue May 13 14:16:48 2008 From: stansife at caltech.edu (Eric Stansifer) Date: Tue May 13 14:18:42 2008 Subject: [Haskell-cafe] Trying to avoid duplicate instances Message-ID: <2e58fd390805131116v7261e572r8d3455f8c52f4634@mail.gmail.com> I am using a bunch of empty type classes to categorize some objects: > class FiniteSolidObject o > class FinitePatchObject o > class InfiniteSolidObject o ... > instance FiniteSolidObject Box > instance FiniteSolidObject Sphere > instance FinitePatchObject Mesh > instance InfiniteSolidObject Plane ... and would like to write a function elsewhere with a type signature like: > intersection :: (SolidObject o1, SolidObject o2) => o1 -> o2 -> Intersection o1 o2 These classes are not exposed to the user (which will be me, but that's besides the point) so the the user (me) does not accidentally try to intersect two meshes, etc. So long as I define my instances correctly the compiler will verify this at compile time. Since "solid objects" are exactly "finite solid objects" plus "infinite solid objects", there is an obvious way to code up this logical relationship. So I try to write: > class SolidObject o > instance FiniteSolidObject o => SolidObject o > instance InfiniteSolidObject o => SolidObject o but inevitably GHC complains that I have duplicate instance declarations. I had mistakenly thought that GHC would only give such an error if it could exhibit a specific type 'o' which satisfied both the context 'FiniteSoildObject o' and the context 'InfiniteSolidObject o' (and I know that there does not exist any such 'o' because I define my instances such that 'FiniteSolidObject' and 'InfiniteSolidObject' will never coincide, and I do not export any of these type classes), but I see now that this is not the case. Adding flags like -fallow-overlapping-instances doesn't convince GHC. Is there a way around this other than manually writing out all the instances I want? That is, > instance FiniteSolidObject Box > instance FiniteObject Box > instance SolidObject Box > instance UnionableObject Box > instance Object Box > > instance FiniteSolidObject Sphere ... Thanks, Eric From bulat.ziganshin at gmail.com Tue May 13 14:22:07 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue May 13 14:18:55 2008 Subject: [Haskell-cafe] saner shootout programs In-Reply-To: <4829C09F.4010205@millstream.com> References: <48282C51.1040706@millstream.com> <4829A16E.9000506@millstream.com> <1881893895.20080513193836@gmail.com> <4829BA34.6070205@millstream.com> <1522825917.20080513200442@gmail.com> <4829C09F.4010205@millstream.com> Message-ID: <1411830730.20080513222207@gmail.com> Hello Richard, Tuesday, May 13, 2008, 8:23:59 PM, you wrote: > Yes it was just a plausible guess, but not contradicted by the experts. > And that was using the Windows version of GHC so other versions may > have better optimisation. I don't know how to check, maybe the experts > can illuminate the subject? note that my letter was not contradicted too LOL 1. many experts just don't read this list due to its high traffic, write into ghc-users instead 2. ghc is too large system and no one know all its details. this particular option may be set up 10 years ago and never touched/studied by anyone since then. for example, i'm ghc performance expert [to some degree], but i don't know anything about its build system. all that i can tell is that ghc base library build times don't prohibit use of -O2 -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From bulat.ziganshin at gmail.com Tue May 13 14:25:29 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue May 13 14:20:43 2008 Subject: [Haskell-cafe] Trying to avoid duplicate instances In-Reply-To: <2e58fd390805131116v7261e572r8d3455f8c52f4634@mail.gmail.com> References: <2e58fd390805131116v7261e572r8d3455f8c52f4634@mail.gmail.com> Message-ID: <1082454176.20080513222529@gmail.com> Hello Eric, Tuesday, May 13, 2008, 10:16:48 PM, you wrote: > -fallow-overlapping-instances doesn't convince GHC. Is there a way > around this other than manually writing out all the instances I want? afaik, no. typeclasses are not the same as OOP classes. i suggest you to look into http://haskell.org/haskellwiki/OOP_vs_type_classes and in particular papers mentioned at the end - one describes implementation of type classes and other emphasize differences between t.c. and classes. these should shed the light :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From dons at galois.com Tue May 13 14:35:30 2008 From: dons at galois.com (Don Stewart) Date: Tue May 13 14:31:45 2008 Subject: [Haskell-cafe] Analog data acquisition In-Reply-To: <78dc001e0805130927g72aac077yaae100ae90008297@mail.gmail.com> References: <78dc001e0805130927g72aac077yaae100ae90008297@mail.gmail.com> Message-ID: <20080513183530.GB22506@scytale.galois.com> tanielsen: > Hello, > > I would like to use a lazy, purely functional language to create an > experiement description (and execution!) language for cellular > neuroscience, i.e. electrical recordings and stimulation. > Unfortunately, this means I have to talk to a > Analog-to-Digital/Digital-to-Analog converter board, with a precision > of about 16 bit at a rate of 50 kHz. I currently have a National > Instruments M-series board, but would be happy to try another board. > I'm not looking for real-time control right now, but that might be of > interest in the future. > > Has anyone looked at creating bindings to the NI-DAQmx drivers or the > open-source COMEDI project, or similar hardware? Would anyone be > interested in helping out with this driver binding? I'm assuming there are existing C libraries for this? So a Haskell binding would just talk to these? From wnoise at ofb.net Tue May 13 14:35:57 2008 From: wnoise at ofb.net (Aaron Denney) Date: Tue May 13 14:31:57 2008 Subject: [Haskell-cafe] Endianess (was Re: GHC predictability) References: <20080509212412.GE24396@scytale.galois.com> <48289421.2070408@btinternet.com> Message-ID: On 2008-05-12, Andrew Coppin wrote: > (Stupid little-endian nonsense... mutter mutter...) I used to be a big-endian advocate, on the principle that it doesn't really matter, and it was standard network byte order. Now I'm convinced that little endian is the way to go, as bit number n should have value 2^n, byte number n should have value 256^n, and so forth. Yes, in human to human communication there is value in having the most significant bit first. Not really true for computer-to-computer communication. -- Aaron Denney -><- From ketil at malde.org Tue May 13 14:46:58 2008 From: ketil at malde.org (Ketil Malde) Date: Tue May 13 14:40:31 2008 Subject: [Haskell-cafe] Endianess In-Reply-To: (Aaron Denney's message of "Tue\, 13 May 2008 18\:35\:57 +0000 \(UTC\)") References: <20080509212412.GE24396@scytale.galois.com> <48289421.2070408@btinternet.com> Message-ID: <87ve1ixcrh.fsf@nmd9999.imr.no> Aaron Denney writes: > I used to be a big-endian advocate, on the principle that it doesn't > really matter, and it was standard network byte order. Now I'm > convinced that little endian is the way to go I guess it depends a lot on what you grew up with. The names (little/big endian) are incredibly apt. The only argument I can come up with, is that big endian seems to make more sense for 'od': % echo foobar > foo % od -x foo 0000000 6f66 626f 7261 000a 0000007 Since this is little endian, the output corresponds to "of bo ra \0\n". So I guess the argument is that for big-endian, the concatenation of hex numbers is invariant with respect to word sizes? -k -- If I haven't seen further, it is by standing in the footprints of giants From paul at cogito.org.uk Tue May 13 14:48:18 2008 From: paul at cogito.org.uk (Paul Johnson) Date: Tue May 13 14:42:06 2008 Subject: [Haskell-cafe] GHC predictability In-Reply-To: References: Message-ID: <4829E272.2000401@cogito.org.uk> Jeff Polakow wrote: > [...] This can be easily fixed by defining a suitable strict sum: > > sum' = foldl' (+) 0 > > and now sum' has constant space. We could try to redefine mean using > sum': > > mean1 xs = sum' xs / fromIntegral (length xs) > > but this still gobbles up memory. The reason is that xs is used twice > and cannot be discarded as it is generated. As an experiment I tried using "pointfree" to see if it would do something similar. > $ pointfree "\xs -> foldl' (+) 0 xs / fromIntegral (length xs)" > ap ((/) . foldl' (+) 0) (fromIntegral . length) But when I try this in GHCi 6.8.2 I get: > Prelude Data.List Control.Monad> let mean2 = ap ((/) . foldl' (+) 0) (fromIntegral . length) > > :1:12: > No instance for (Monad ((->) [b])) > arising from a use of `ap' at :1:12-58 > Possible fix: add an instance declaration for (Monad ((->) [b])) > In the expression: ap ((/) . foldl' (+) 0) (fromIntegral . length) > In the definition of `mean2': > mean2 = ap ((/) . foldl' (+) 0) (fromIntegral . length) Any ideas? Would the auto-generated pointfree version be any better if it could be made to work? Paul. From tanielsen at gmail.com Tue May 13 14:48:45 2008 From: tanielsen at gmail.com (Tom Nielsen) Date: Tue May 13 14:42:31 2008 Subject: [Haskell-cafe] Analog data acquisition In-Reply-To: <20080513183530.GB22506@scytale.galois.com> References: <78dc001e0805130927g72aac077yaae100ae90008297@mail.gmail.com> <20080513183530.GB22506@scytale.galois.com> Message-ID: <78dc001e0805131148o548c11f0l82c863022a3be4b@mail.gmail.com> Yes. I guess I have to wait for chapter 19, then? Tom On Tue, May 13, 2008 at 7:35 PM, Don Stewart wrote: > tanielsen: > > > > Hello, > > > > I would like to use a lazy, purely functional language to create an > > experiement description (and execution!) language for cellular > > neuroscience, i.e. electrical recordings and stimulation. > > Unfortunately, this means I have to talk to a > > Analog-to-Digital/Digital-to-Analog converter board, with a precision > > of about 16 bit at a rate of 50 kHz. I currently have a National > > Instruments M-series board, but would be happy to try another board. > > I'm not looking for real-time control right now, but that might be of > > interest in the future. > > > > Has anyone looked at creating bindings to the NI-DAQmx drivers or the > > open-source COMEDI project, or similar hardware? Would anyone be > > interested in helping out with this driver binding? > > I'm assuming there are existing C libraries for this? So a Haskell > binding would just talk to these? > From ndmitchell at gmail.com Tue May 13 14:56:59 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Tue May 13 14:52:24 2008 Subject: [Haskell-cafe] Parsec3 performance issues (in relation to v2) In-Reply-To: References: Message-ID: <404396ef0805131156r2814d922o8335e407bb97cfac@mail.gmail.com> Hi > Anyway, the log file that i'm parsing uses English grammar, and the > performance really dropped just by upgrading to Parsec3. I was hoping to use > the ByteString support to boost the speed of already slow code, but had no > such luck. It basicly went from "Ugh, this is kinda slow" to "Uhhhh i'm > gonna go grab a burger and let this melt my CPU" haha. I think it is known that Parsec 3 is slower than Parsec 2, as a result of the increased generality. I know that in the past someone was working on it, but I am not sure if they ever got anywhere. Thanks Neil From bjorn at bringert.net Tue May 13 15:00:01 2008 From: bjorn at bringert.net (Bjorn Bringert) Date: Tue May 13 14:53:46 2008 Subject: [Haskell-cafe] Using Template Haskell to make type-safe database access In-Reply-To: <1210260745.4265.29.camel@localhost.localdomain> References: <1209760319.4242.4.camel@localhost.localdomain> <1210017744.4300.30.camel@localhost.localdomain> <6A286E8D-2C96-4E77-9FA3-077702204CBE@Cs.Nott.AC.UK> <1210195445.4192.54.camel@localhost.localdomain> <0C39F272-5FC0-48A7-8831-1F2BF03F4989@Cs.Nott.AC.UK> <1210260745.4265.29.camel@localhost.localdomain> Message-ID: On Thu, May 8, 2008 at 5:32 PM, Mads Lindstr?m wrote: > Hi Wouter, > > Wouter Swierstra wrote: > > > > Nice! I have to admit, it's much nicer than I expected it to be. Just > > out of curiousity, what happens when you write: > > > > selectTupleList :: Connection -> IO [Integer] > > > > instead of > > > > selectTupleList :: Connection -> IO [(Integer, String, String)] > > > > What kind of error message do you get? More specifically, is this > > error caught statically or dynamically. > > The type annotation in UseSqlExpr.hs was just for the reader. The > compiler can infer the types completely. Thus when I make the suggested > change I get a compile time error. It looks like this: > > UseSqlExpr.hs:27:6: > Couldn't match expected type `Integer' > against inferred type `(Integer, String, String)' > Expected type: IO [Integer] > Inferred type: IO [(Integer, String, String)] > In the expression: > (return > $ (map > (\ [x0[a2ZY], x1[a2ZZ], x2[a300]] > -> (readInteger x0[a2ZY], > readString x1[a2ZZ], > readString x2[a300])) > rows[a2ZX])) > In the expression: > do rows[a2ZX] <- fetchRows > dsn[a2ZW] > ['S', 'E', 'L', 'E', 'C', 'T', ' ', 'u', 's', 'e', 'r', '_', 'i', > 'd', ',', ' ', 'u', 's', 'e', 'r', '_', 'n', 'a', 'm', 'e', ',', > ' ', 'u', 's', 'e', 'r', '_', 'r', 'e', 'a', 'l', '_', 'n', 'a', > 'm', 'e', ' ', 'F', 'R', 'O', 'M', ' ', 'u', 's', 'e', 'r', ';'] > (return > $ (map > (\ [x0[a2ZY], x1[a2ZZ], x2[a300]] > -> (readInteger x0[a2ZY], > readString x1[a2ZZ], > readString x2[a300])) > rows[a2ZX])) > make: *** [all] Fejl 1 > > > > > > The only other limitation I can think of, would be in the situation > > where you don't have compile-time access to the database, e.g. > > developing software for a client with a database that can only be > > accessed from their intranet. I have no idea how much of a limitation > > that is. > > True, but this limitation is only relevant when you do not have access > to the production database or a database with identical metadata. How > often do people develop like that? How are they testing? I have a hard > time picturing a setup without a test database with identical metadata > to the production database. > > > > >> Perhaps I should explain my own thoughts on the subject a bit better. > > >> I got interested in this problem because I think it makes a nice > > >> example of dependent types "in the real world" - you really want to > > > > > > But won't you end up implementing all the functionality of an SQL > > > parser? While possible, it does seem like a huge job. With a TH > > > solution > > > you will safe a lot of work. > > > > Yes - but parsing the result of an SQL describe statement is pretty > > easy. > ok. > > > > > > > A library that > > > will be a lot more complex to learn than what I am proposing (assuming > > > the developer already knows SQL). > > > > Hmm. This is a rather sticky point. One might also argue that Haskell > > developers have to learn SQL to use the solution you propose. I'm not > > particularly convinced. Both approaches have their merits I think. > > Yes. I was _not_ making what you could call a strong argument. I was > assuming that most (Haskell) developers knew SQL anyway. I have no data > to back it up. Just my gut feeling. > > To be fair I should mention a couple of drawbacks with the TH-based > approach. While SQL got static typing, it is not really as powerful as > it could be. For example if you do "select sum(...) from ..." the type > system will tell you that a set of values are returned. In reality this > set will never have more than one member. Your proposal would be able to > return a Float in stead of a [Float]. > > Another advantage your proposal (and disadvantage of the TH based one) > would be that it can abstract over variances in different database > implementation. That is, you could translate to SQL depending on SQL > backend. This would be really nice. But I guess it would also be a big > task. > > > > > > Anyhow - nice work! Have you asked Bjorn Bringert what he thinks? He's > > a really clever and approachable guy - and he knows a lot more about > > interfacing with databases than I do. I guess I'll just have to reply then :-) Mads: Preparing the statement and asking the DB about the type at compile is a great idea! I've never thought of that. Please consider completing this and packaging it as a library. I can't really see any major problems with this approach, other than the obivious "changing schema" problem that it shares with HaskellDB. Of course there are some things that it won't catch, like the singleton results from aggregates, but it does go a long way towards a statically safe DB interface. I think that the main disadvantages compared to HaskellDB are that: - It won't let you write your own query combinators. - The program becomes dependent on the exact SQL dialect you chose to use. On the other hand it addresses some of the problems with HaskellDB: - Poorly optimized queries. - Missing SQL features (e.g. outer joins). - Poor support for DB-specific features. - Difficult to understand type errors. /Bj?rn From alfonso.acosta at gmail.com Tue May 13 15:01:56 2008 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Tue May 13 14:55:51 2008 Subject: [Haskell-cafe] Data.Dynamic over the wire In-Reply-To: <4829D240.60504@jellybean.co.uk> References: <4829D240.60504@jellybean.co.uk> Message-ID: <6a7c66fc0805131201i6a2a58areb728fe7b360cf19@mail.gmail.com> On Tue, May 13, 2008 at 7:39 PM, Jules Bean wrote: > One thing which you can't obviously do is write Read or Show instances > for Dynamic. So can we pass Dynamic data over the wire? If not, > Dynamic is limited to the context of "within a single program", and > can't be used over the network between cooperating programs, or in > file formats, etc. I've never used hs-plugins, but if I recall properly, it includes its own implementation of TypeRep (and consequently Dynamic) in order to overcome the serialization problem you have mentioned. From ketil at malde.org Tue May 13 15:09:50 2008 From: ketil at malde.org (Ketil Malde) Date: Tue May 13 15:04:07 2008 Subject: [Haskell-cafe] Parsec3 performance issues (in relation to v2) In-Reply-To: <404396ef0805131156r2814d922o8335e407bb97cfac@mail.gmail.com> (Neil Mitchell's message of "Tue\, 13 May 2008 19\:56\:59 +0100") References: <404396ef0805131156r2814d922o8335e407bb97cfac@mail.gmail.com> Message-ID: <87mymuxbpd.fsf@nmd9999.imr.no> "Neil Mitchell" writes: > I think it is known that Parsec 3 is slower than Parsec 2, as a result > of the increased generality. I know that in the past someone was > working on it, but I am not sure if they ever got anywhere. I got pretty good performance (IMHO - about 10MB/s, still CPU-bound) using a lazy bytestring tokenizer and Parsec on top of that. Of course, it probably depends on the complexity of the parsing... -k -- If I haven't seen further, it is by standing in the footprints of giants From jed at 59A2.org Tue May 13 15:11:02 2008 From: jed at 59A2.org (Jed Brown) Date: Tue May 13 15:06:09 2008 Subject: [Haskell-cafe] Endianess In-Reply-To: <87ve1ixcrh.fsf@nmd9999.imr.no> References: <20080509212412.GE24396@scytale.galois.com> <48289421.2070408@btinternet.com> <87ve1ixcrh.fsf@nmd9999.imr.no> Message-ID: <20080513191102.GA11402@brakk.ethz.ch> On Tue 2008-05-13 20:46, Ketil Malde wrote: > Aaron Denney writes: > > I guess it depends a lot on what you grew up with. The names > (little/big endian) are incredibly apt. > > The only argument I can come up with, is that big endian seems to make > more sense for 'od': > > % echo foobar > foo > % od -x foo > 0000000 6f66 626f 7261 000a > 0000007 This, of course, is because `od -x' regards the input as 16-bit integers. We can get saner output if we regard it is 8-bit integers. $ od -t x1 foo 0000000 66 6f 6f 62 61 72 0a 0000007 > > Now I'm convinced that little endian is the way to go, as bit number n > > should have value 2^n, byte number n should have value 256^n, and so forth. It's not that simple with bits. They lack consistency just like the usual US date format and the way Germans read numbers. Jed -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080513/dec91f7b/attachment.bin From ketil at malde.org Tue May 13 15:24:53 2008 From: ketil at malde.org (Ketil Malde) Date: Tue May 13 15:18:26 2008 Subject: [Haskell-cafe] Endianess In-Reply-To: <20080513191102.GA11402@brakk.ethz.ch> (Jed Brown's message of "Tue\, 13 May 2008 21\:11\:02 +0200") References: <20080509212412.GE24396@scytale.galois.com> <48289421.2070408@btinternet.com> <87ve1ixcrh.fsf@nmd9999.imr.no> <20080513191102.GA11402@brakk.ethz.ch> Message-ID: <87fxsmxb0a.fsf@nmd9999.imr.no> Jed Brown writes: > This, of course, is because `od -x' regards the input as 16-bit integers. We > can get saner output if we regard it is 8-bit integers. Yes, of course. The point was that for big-endian, the word size won't matter. Little-endian words will be reversed with respect to the normal (left-to-right, most significant first) way we print numbers. -k -- If I haven't seen further, it is by standing in the footprints of giants From wnoise at ofb.net Tue May 13 15:28:01 2008 From: wnoise at ofb.net (Aaron Denney) Date: Tue May 13 15:22:15 2008 Subject: [Haskell-cafe] Re: Endianess References: <20080509212412.GE24396@scytale.galois.com> <48289421.2070408@btinternet.com> <87ve1ixcrh.fsf@nmd9999.imr.no> <20080513191102.GA11402@brakk.ethz.ch> <87fxsmxb0a.fsf@nmd9999.imr.no> Message-ID: On 2008-05-13, Ketil Malde wrote: > Jed Brown writes: > >> This, of course, is because `od -x' regards the input as 16-bit integers. We >> can get saner output if we regard it is 8-bit integers. > > Yes, of course. The point was that for big-endian, the word size > won't matter. Little-endian words will be reversed with respect to > the normal (left-to-right, most significant first) way we print > numbers. Right. Because we print numbers backwards. -- Aaron Denney -><- From anton at appsolutions.com Tue May 13 15:38:51 2008 From: anton at appsolutions.com (Anton van Straaten) Date: Tue May 13 15:23:07 2008 Subject: [Haskell-cafe] Re: GHC predictability In-Reply-To: <20080513181329.2d8dc416@solaris> References: <20080509212412.GE24396@scytale.galois.com> <48289421.2070408@btinternet.com> <2608b8a80805121627s480ef1fgc0baa3fb4c5d79e1@mail.gmail.com> <20080513062022.GA19372@scytale.galois.com> <20080513181329.2d8dc416@solaris> Message-ID: <4829EE4B.9090908@appsolutions.com> Achim Schneider wrote: > To get a bit more on-topic: I currently completely fail to implement a > layout rule in Parsec because I don't understand its inner workings, > and thus constantly mess up my state. Parsec's ease of usage is > deceiving as soon as you use more than combinators: Suddenly the > plumbing becomes important, and hackage is full of such things. Haskell > has potentially infinite learning curves, and each one of them > usually represents a wall. To make them crumble, you have to get used to > not understand anything until you understand everything. A big component of this is just that a high level of abstraction is involved. Something similar occurs in other languages, for programs that are written in a very abstract way. Some frameworks in e.g. Smalltalk, Java, or C++ are an example of this: full of classes whose domain is mainly internal to the framework, and you have to understand the framework's design principles in their full generality in order to be able to really understand the code. As a more concrete example related to Parsec, consider a generator of table-driven parsers written in C, and compare this to writing a recursive-descent parser directly. The code for the parser generator is completely impenetrable for someone who isn't familiar with the theory behind it, so if they want to change the generator's behavior, they're likely to be stuck. Whereas for a recursive descent parser for a single language, it's much easier to map between the ultimate application goals, and how those are accomplished in the code, without much special knowledge. Of course there are pros and cons on either side. One reason that DSLs work well is that when done right, so that abstraction leakage is minimal, they can insulate users from having to understand the underlying system. Embedded DSLs, like Parsec, seem more likely to suffer from problems in this area, although in that case the tradeoff is that you're getting to use them directly in a general-purpose language. Anton From wnoise at ofb.net Tue May 13 15:33:08 2008 From: wnoise at ofb.net (Aaron Denney) Date: Tue May 13 15:27:24 2008 Subject: [Haskell-cafe] Re: Endianess References: <20080509212412.GE24396@scytale.galois.com> <48289421.2070408@btinternet.com> <87ve1ixcrh.fsf@nmd9999.imr.no> <20080513191102.GA11402@brakk.ethz.ch> Message-ID: On 2008-05-13, Jed Brown wrote: >> > Now I'm convinced that little endian is the way to go, as bit number n >> > should have value 2^n, byte number n should have value 256^n, and so forth. > > It's not that simple with bits. They lack consistency just like the > usual US date format and the way Germans read numbers. Yes. I'm saying what should be, not what is. I'm saying one of those ways is wrong, wrong, wrong. It usually doesn't matter in practice, because writes to e.g. RAM effectively happen at byte-level or higher, making the internal labels fairly arbitrary. It matters and can cause confusion in actual serial protocols, of course, which have been making a resurgence in recent years, though again, the bit order in these are well understood. Just possibly wrong. -- Aaron Denney -><- From lrpalmer at gmail.com Tue May 13 15:38:05 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Tue May 13 15:31:53 2008 Subject: [Haskell-cafe] GHC predictability In-Reply-To: <4829E272.2000401@cogito.org.uk> References: <4829E272.2000401@cogito.org.uk> Message-ID: <7ca3f0160805131238g63aba45ahff23f71768806fa1@mail.gmail.com> On Tue, May 13, 2008 at 12:48 PM, Paul Johnson wrote: > > $ pointfree "\xs -> foldl' (+) 0 xs / fromIntegral (length xs)" > > ap ((/) . foldl' (+) 0) (fromIntegral . length) > > But when I try this in GHCi 6.8.2 I get: > > > Prelude Data.List Control.Monad> let mean2 = ap ((/) . foldl' (+) 0) > (fromIntegral . length) > > > > :1:12: > > No instance for (Monad ((->) [b])) > > arising from a use of `ap' at :1:12-58 > > Possible fix: add an instance declaration for (Monad ((->) [b])) > > In the expression: ap ((/) . foldl' (+) 0) (fromIntegral . length) > > In the definition of `mean2': > > mean2 = ap ((/) . foldl' (+) 0) (fromIntegral . length) It's using the Monad ((->) r) instance, which doesn't exist by default. import Control.Monad.Instances to get it. Luke From bos at serpentine.com Tue May 13 15:40:05 2008 From: bos at serpentine.com (Bryan O'Sullivan) Date: Tue May 13 15:33:56 2008 Subject: [Haskell-cafe] GHC predictability In-Reply-To: References: <20080509212412.GE24396@scytale.galois.com> <48289421.2070408@btinternet.com> <2608b8a80805121627s480ef1fgc0baa3fb4c5d79e1@mail.gmail.com> <20080513062022.GA19372@scytale.galois.com> Message-ID: <4829EE95.3040704@serpentine.com> Darrin Thompson wrote: > These "tricks" going into Real World Haskell? Some will, yes. For example, the natural and naive way to write Andrew's "mean" function doesn't involve tuples at all: simply tail recurse with two accumulator parameters, and compute the mean at the end. GHC's strictness analyser does the right thing with this, so there's no need for seq, $!, or the like. It's about 3 lines of code. References: <87fxsmxb0a.fsf@nmd9999.imr.no> Message-ID: <200805132143.57643.daniel.is.fischer@web.de> Am Dienstag, 13. Mai 2008 21:28 schrieb Aaron Denney: > On 2008-05-13, Ketil Malde wrote: > > Jed Brown writes: > >> This, of course, is because `od -x' regards the input as 16-bit > >> integers. We can get saner output if we regard it is 8-bit integers. > > > > Yes, of course. The point was that for big-endian, the word size > > won't matter. Little-endian words will be reversed with respect to > > the normal (left-to-right, most significant first) way we print > > numbers. > > Right. Because we print numbers backwards. Try hebrew or arab then, they have the least significant digit first in reading order :) From jeff.polakow at db.com Tue May 13 15:53:52 2008 From: jeff.polakow at db.com (Jeff Polakow) Date: Tue May 13 15:50:34 2008 Subject: [Haskell-cafe] GHC predictability In-Reply-To: <4829EE95.3040704@serpentine.com> Message-ID: Hello, > For example, the natural and naive way to write Andrew's "mean" function > doesn't involve tuples at all: simply tail recurse with two accumulator > parameters, and compute the mean at the end. GHC's strictness analyser > does the right thing with this, so there's no need for seq, $!, or the > like. It's about 3 lines of code. > Is this the code you mean? meanNat = go 0 0 where go s n [] = s / n go s n (x:xs) = go (s+x) (n+1) xs If so, bang patterns are still required bang patterns in ghc-6.8.2 to run in constant memory: meanNat = go 0 0 where go s n [] = s / n go !s !n (x:xs) = go (s+x) (n+1) xs Is there some other way to write it so that ghc will essentially insert the bangs for me? -Jeff --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080513/10bd9e68/attachment.htm From jeff.polakow at db.com Tue May 13 16:07:01 2008 From: jeff.polakow at db.com (Jeff Polakow) Date: Tue May 13 16:00:54 2008 Subject: [Haskell-cafe] GHC predictability In-Reply-To: <4829E272.2000401@cogito.org.uk> Message-ID: Hello, > > $ pointfree "\xs -> foldl' (+) 0 xs / fromIntegral (length xs)" > > ap ((/) . foldl' (+) 0) (fromIntegral . length) > This will have the same space usage as the pointed version. You can see this by looking at the monad instance for ((->) r): instance Monad ((->) r) where return = const f >>= k = \ r -> k (f r) r -Jeff --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080513/d7de38a9/attachment.htm From barsoap at web.de Tue May 13 16:14:20 2008 From: barsoap at web.de (Achim Schneider) Date: Tue May 13 16:09:22 2008 Subject: [Haskell-cafe] Re: Endianess References: <20080509212412.GE24396@scytale.galois.com> <48289421.2070408@btinternet.com> <87ve1ixcrh.fsf@nmd9999.imr.no> <20080513191102.GA11402@brakk.ethz.ch> Message-ID: <20080513221420.5611a662@solaris> Jed Brown wrote: > It's not that simple with bits. They lack consistency just like the > usual US date format and the way Germans read numbers. > So you claim that you pronounce 14 tenty-four? In German pronunciation is completely uniform from 13 to 99. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. From dan.doel at gmail.com Tue May 13 16:22:48 2008 From: dan.doel at gmail.com (Dan Doel) Date: Tue May 13 16:15:44 2008 Subject: [Haskell-cafe] GHC predictability In-Reply-To: References: Message-ID: <200805131622.49660.dan.doel@gmail.com> On Tuesday 13 May 2008, Jeff Polakow wrote: > Is this the code you mean? > > meanNat = go 0 0 where > go s n [] = s / n > go s n (x:xs) = go (s+x) (n+1) xs > > If so, bang patterns are still required bang patterns in ghc-6.8.2 to run > in constant memory: > > meanNat = go 0 0 where > go s n [] = s / n > go !s !n (x:xs) = go (s+x) (n+1) xs > > Is there some other way to write it so that ghc will essentially insert > the bangs for me? It works fine here when compiled with -O or better. Perhaps that should be a tip in the book? Make sure you're compiling with optimizations. :) -- Dan From dons at galois.com Tue May 13 16:21:38 2008 From: dons at galois.com (Don Stewart) Date: Tue May 13 16:15:56 2008 Subject: [Haskell-cafe] GHC predictability In-Reply-To: References: <4829EE95.3040704@serpentine.com> Message-ID: <20080513202138.GC22506@scytale.galois.com> jeff.polakow: > Hello, > > > For example, the natural and naive way to write Andrew's "mean" function > > doesn't involve tuples at all: simply tail recurse with two accumulator > > parameters, and compute the mean at the end. GHC's strictness analyser > > does the right thing with this, so there's no need for seq, $!, or the > > like. It's about 3 lines of code. > > > Is this the code you mean? > > meanNat = go 0 0 where > go s n [] = s / n > go s n (x:xs) = go (s+x) (n+1) xs > If so, bang patterns are still required bang patterns in ghc-6.8.2 to run > in constant memory: > > meanNat = go 0 0 where > go s n [] = s / n > go !s !n (x:xs) = go (s+x) (n+1) xs > > Is there some other way to write it so that ghc will essentially insert > the bangs for me? Yes, give a type annotation, constraining 'n' to Int. meanNat :: [Double] -> Double meanNat = go 0 0 where go :: Double -> Int -> [Double] -> Double go s n [] = s / fromIntegral n go s n (x:xs) = go (s+x) (n+1) xs And you get this loop: M.$wgo :: Double# -> Int# -> [Double] -> Double# M.$wgo = \ (ww_smN :: Double#) (ww1_smR :: Int#) (w_smT :: [Double]) -> case w_smT of wild_B1 { [] -> /## ww_smN (int2Double# ww1_smR); : x_a9k xs_a9l -> case x_a9k of wild1_am7 { D# y_am9 -> M.$wgo (+## ww_smN y_am9) (+# ww1_smR 1) xs_a9l } } Without the annotation you get: M.$wgo :: Double# -> Integer -> [Double] -> Double GHC sees through the strictness of I#. -- Don From andrewcoppin at btinternet.com Tue May 13 16:24:05 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Tue May 13 16:17:42 2008 Subject: [Haskell-cafe] GHC predictability In-Reply-To: References: Message-ID: <4829F8E5.5070708@btinternet.com> Jeff Polakow wrote: > Then, I immediately blow my stack if I try something like: > > mean [1..1000000000]. > > The culprit is actually sum which is defined in the base libraries as > either a foldl or a direct recursion depending on a compiler flag. In > either case, the code is not strict enough; just trying to compute: > > sum [1..10000000] > > blows the stack. This can be easily fixed by defining a suitable > strict sum: > > sum' = foldl' (+) 0 > > and now sum' has constant space. OK *now* I'm worried... I thought sum was _already_ defined this way? o_O From dons at galois.com Tue May 13 16:26:07 2008 From: dons at galois.com (Don Stewart) Date: Tue May 13 16:20:07 2008 Subject: [Haskell-cafe] GHC predictability In-Reply-To: <20080513202138.GC22506@scytale.galois.com> References: <4829EE95.3040704@serpentine.com> <20080513202138.GC22506@scytale.galois.com> Message-ID: <20080513202607.GD22506@scytale.galois.com> dons: > jeff.polakow: > > Hello, > > > > > For example, the natural and naive way to write Andrew's "mean" function > > > doesn't involve tuples at all: simply tail recurse with two accumulator > > > parameters, and compute the mean at the end. GHC's strictness analyser > > > does the right thing with this, so there's no need for seq, $!, or the > > > like. It's about 3 lines of code. > > > > > Is this the code you mean? > > > > meanNat = go 0 0 where > > go s n [] = s / n > > go s n (x:xs) = go (s+x) (n+1) xs > > If so, bang patterns are still required bang patterns in ghc-6.8.2 to run > > in constant memory: > > > > meanNat = go 0 0 where > > go s n [] = s / n > > go !s !n (x:xs) = go (s+x) (n+1) xs > > > > Is there some other way to write it so that ghc will essentially insert > > the bangs for me? > > Yes, give a type annotation, constraining 'n' to Int. > > meanNat :: [Double] -> Double > meanNat = go 0 0 > where > go :: Double -> Int -> [Double] -> Double > go s n [] = s / fromIntegral n > go s n (x:xs) = go (s+x) (n+1) xs > > And you get this loop: > > M.$wgo :: Double# > -> Int# > -> [Double] > -> Double# > > M.$wgo = > \ (ww_smN :: Double#) > (ww1_smR :: Int#) > (w_smT :: [Double]) -> > case w_smT of wild_B1 { > [] -> /## ww_smN (int2Double# ww1_smR); > : x_a9k xs_a9l -> > case x_a9k of wild1_am7 { D# y_am9 -> > M.$wgo (+## ww_smN y_am9) (+# ww1_smR 1) xs_a9l > } > } > Note this is pretty much identical to the code you get with a foldl' (though without the unboxed pair return): import Data.List import Text.Printf import Data.Array.Vector mean :: [Double] -> Double mean arr = b / fromIntegral a where k (n :*: s) a = (n+1 :*: s+a) (a :*: b) = foldl' k (0 :*: 0) arr :: (Int :*: Double) main = printf "%f\n" . mean $ [1 .. 1e9] Note I'm using strict pairs for the accumulator, instead of banging lazy pairs. $s$wlgo :: [Double] -> Double# -> Int# -> (# Int, Double #) $s$wlgo = \ (xs1_aMQ :: [Double]) (sc_sYK :: Double#) (sc1_sYL :: Int#) -> case xs1_aMQ of wild_aML { [] -> (# I# sc1_sYL, D# sc_sYK #); : x_aMP xs11_XMX -> case x_aMP of wild1_aOg { D# y_aOi -> $s$wlgo xs11_XMX (+## sc_sYK y_aOi) (+# sc1_sYL 1) } } -- Don From dave at zednenem.com Tue May 13 16:28:01 2008 From: dave at zednenem.com (David Menendez) Date: Tue May 13 16:21:48 2008 Subject: [Haskell-cafe] Short circuiting and the Maybe monad In-Reply-To: <3c4d5adf0805122213w9e52794ybf1a1d1b0ed752e6@mail.gmail.com> References: <65113aef0805121509s6b4e76bbxd23e86070a2a0be3@mail.gmail.com> <3c4d5adf0805122213w9e52794ybf1a1d1b0ed752e6@mail.gmail.com> Message-ID: <49a77b7a0805131328y72235e8ejda36cc8a4d88a065@mail.gmail.com> 2008/5/13 Abhay Parvate : > Yes, I had always desired that the operator >>= should have been right > associative for this short cut even when written without the 'do' notation. You pretty much always want "a >>= b >>= c" to parse as "(a >>= b) >>= c" and not "a >>= (b >>= c)". In the latter case, the two uses of (>>=) aren't in the same monad. You can get desired effect with the Kleisli composition operator (>=>), which is in recent versions of Control.Monad. Unfortunately, it has the same precedence as (>>=), so you can't use them together without parentheses. Using it, "a >>= b >>= c" can be rewritten "a >>= (b >=> c)" which is short for "a >>= \x -> b x >>= c". -- Dave Menendez From andrewcoppin at btinternet.com Tue May 13 16:30:14 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Tue May 13 16:23:49 2008 Subject: [Haskell-cafe] GHC predictability In-Reply-To: References: <20080509212412.GE24396@scytale.galois.com> <48289421.2070408@btinternet.com> <2608b8a80805121627s480ef1fgc0baa3fb4c5d79e1@mail.gmail.com> <20080513062022.GA19372@scytale.galois.com> Message-ID: <4829FA56.1090903@btinternet.com> Darrin Thompson wrote: > These "tricks" going into Real World Haskell? Seconded. > When you say someone > needs to get familiar with the "STG paper" it scares me (a beginner) > off a little, an I've been making an effort to approach the papers. Well, I'm the sort of contrary person who reads random papers like that just for the fun of it. But when somebody says something like this, I don't think "ooo, that's scary", I think "ooo, somebody really ought to sit down and write a more gentle introduction". You really shouldn't *need* to know the exact implementation details to get some idea of what will perform well and what won't. But obviously you do need some kind of high-level understanding of what's going on. The STG paper isn't a good way to get that high-level overview. From dons at galois.com Tue May 13 16:34:07 2008 From: dons at galois.com (Don Stewart) Date: Tue May 13 16:28:03 2008 Subject: [Haskell-cafe] GHC predictability In-Reply-To: <4829FA56.1090903@btinternet.com> References: <20080509212412.GE24396@scytale.galois.com> <48289421.2070408@btinternet.com> <2608b8a80805121627s480ef1fgc0baa3fb4c5d79e1@mail.gmail.com> <20080513062022.GA19372@scytale.galois.com> <4829FA56.1090903@btinternet.com> Message-ID: <20080513203407.GE22506@scytale.galois.com> andrewcoppin: > Darrin Thompson wrote: > >These "tricks" going into Real World Haskell? > > Seconded. > > >When you say someone > >needs to get familiar with the "STG paper" it scares me (a beginner) > >off a little, an I've been making an effort to approach the papers. > > Well, I'm the sort of contrary person who reads random papers like that > just for the fun of it. But when somebody says something like this, I > don't think "ooo, that's scary", I think "ooo, somebody really ought to > sit down and write a more gentle introduction". You really shouldn't > *need* to know the exact implementation details to get some idea of what > will perform well and what won't. But obviously you do need some kind of > high-level understanding of what's going on. The STG paper isn't a good > way to get that high-level overview. Andrew, would you say you understand the original problem of why mean xs = sum xs / fromIntegral (length xs) was a bad idea now? Or why the left folds were a better solution? -- Don From darrinth at gmail.com Tue May 13 16:37:32 2008 From: darrinth at gmail.com (Darrin Thompson) Date: Tue May 13 16:31:22 2008 Subject: [Haskell-cafe] GHC predictability In-Reply-To: <4829FA56.1090903@btinternet.com> References: <20080509212412.GE24396@scytale.galois.com> <48289421.2070408@btinternet.com> <2608b8a80805121627s480ef1fgc0baa3fb4c5d79e1@mail.gmail.com> <20080513062022.GA19372@scytale.galois.com> <4829FA56.1090903@btinternet.com> Message-ID: On Tue, May 13, 2008 at 4:30 PM, Andrew Coppin wrote: > Well, I'm the sort of contrary person who reads random papers like that > just for the fun of it. But when somebody says something like this, I don't > think "ooo, that's scary", I think "ooo, somebody really ought to sit down > and write a more gentle introduction". You really shouldn't *need* to know > the exact implementation details to get some idea of what will perform well > and what won't. But obviously you do need some kind of high-level > understanding of what's going on. The STG paper isn't a good way to get that > high-level overview. > I don't think anyone would disagree with that. Reflecting on what I already know, I can optimize python pretty well and the principles are pretty similar for C. The reason I can't just port that knowledge is that with GHC I'm in the land of optimizing for cache hits and at the same time I'm at a really high level of abstraction so I have to have some mental picture of how the plumbing connects. I'm hoping that the optimization chapter of RWH covers a lot of individual techniques. I think the sum of the techniques will shed light on the compiler internals in a practical way. But then I'm not the one doing the work. -- Darrin From jed at 59A2.org Tue May 13 16:54:59 2008 From: jed at 59A2.org (Jed Brown) Date: Tue May 13 16:50:04 2008 Subject: [Haskell-cafe] Re: Endianess In-Reply-To: <20080513221420.5611a662@solaris> References: <20080509212412.GE24396@scytale.galois.com> <48289421.2070408@btinternet.com> <87ve1ixcrh.fsf@nmd9999.imr.no> <20080513191102.GA11402@brakk.ethz.ch> <20080513221420.5611a662@solaris> Message-ID: <20080513205459.GB11402@brakk.ethz.ch> On Tue 2008-05-13 22:14, Achim Schneider wrote: > Jed Brown wrote: > > > It's not that simple with bits. They lack consistency just like the > > usual US date format and the way Germans read numbers. > > > So you claim that you pronounce 14 tenty-four? In German pronunciation > is completely uniform from 13 to 99. I would argue that 100n+11 to 100n+19 are special cases in both German and English, but only 100n+11 to 100n+15 in Spanish. In any case, the order of the digits is dependent on where the decimal falls. If the ordering is pure little endian (not x86 halfway) or big endian, the bit order is not dependent on the width of the field. Converting breaks this nice property. Convention is to write numbers in big endian and it would be nice if there were fewer exceptions. Yet another argument for ISO 8601 dates. A somewhat dramatic change would be to put the exponent first in scientific notation. Alas, this seems unlikely to happen. Jed -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080513/861ed7af/attachment.bin From flippa at flippac.org Tue May 13 16:56:45 2008 From: flippa at flippac.org (Philippa Cowderoy) Date: Tue May 13 16:50:39 2008 Subject: [Haskell-cafe] Parsec3 performance issues (in relation to v2) In-Reply-To: References: Message-ID: <62634.86.145.154.157.1210712205.squirrel@www.gradwell.com> On Tue, May 13, 2008 5:53 am, Neal Alexander wrote: > I can post the full profiling info if anyone really cares. > Any info is helpful. It's taking a while to get round to things, but the more relevant info we have to hand when we do the easier it is to improve things and the less begging for data we have to do! -- flippa@flippac.org I knew I forgot to pack something - thankfully it was my .sig From andrewcoppin at btinternet.com Tue May 13 16:58:05 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Tue May 13 16:51:37 2008 Subject: [Haskell-cafe] Re: GHC predictability In-Reply-To: <20080513023043.GA3520@scytale.galois.com> References: <20080513023043.GA3520@scytale.galois.com> Message-ID: <482A00DD.7050701@btinternet.com> Don Stewart wrote: >> Now try, say, "mean [1.. 1e9]", and watch GHC eat several GB of RAM. (!!) >> > > But you know why, don't you? > What I'm trying to say [and saying very badly] is that Haskell is an almost terrifyingly subtle language. Seemingly insignificant chages can have drastic consequences. (Ever tried to run a program and find it goes into an infinite loop or a deadlock because you accidentally made some function slightly stricter than it needs to be?) I can't find it right now, but some paper I was reading showed two example programs, one of which is dramatically less performant than the other, and yet they look like they should be exactly equivilent, "and one might even expect a good compiler to 'optimise' one to the other [in the wrong direction]". After studying that chapter for about half an hour, I *still* can't wrap my brain around what the difference is. But I assume SPJ knows what he's talking about. >> sat down and spent the best part of a day writing an MD5 >> implementation. Eventually I got it so that all the test vectors work >> right. (Stupid little-endian nonsense... mutter mutter...) When I tried >> it on a file containing more than 1 MB of data... ooooohhhh dear... >> > > Did you use Data.Binary or the other libraries for efficient access to gigabytes of data? > Data.ByteString for all I/O. The rest is just moving data around one byte at a time. Difficult to see how you'd do it any different. [I'll check to see if I still have the code, maybe somebody can do something to it.] And we're not talking about "gigabytes" of data - we're talking about the program completely choking on a 5 MB file. Even plain String I/O couldn't possibly take *minutes* to read 5 MB! >> Of course, the first step in any serious attempt at performance improvement >> is to actually profile the code to figure out where the time >> is being spent. >> > > Well, actually, for our 'mean()' case, it means just using the right structures. > Arrays for example: > Doesn't that mean all the data has to be present in memory at once? I would expect [optimistically?] that if you have a definition for "mean" that performs only 1 traversal of the list, you'd end up with something approximating x = 0 for n = 1 to 1e9 x = x + n return x If you allocate an array, you're limited to what will fit into RAM at once. > (The compiler is optimising this to: > > Main_zdszdwfold_info: > leaq 32(%r12), %rax > cmpq %r15, %rax > movq %rax, %r12 > ja .L10 > movsd .LC0(%rip), %xmm0 > ucomisd %xmm5, %xmm0 > jae .L12 > movq %rsi, (%rax) > movq $base_GHCziFloat_Dzh_con_info, -24(%rax) > movsd %xmm6, -16(%rax) > movq $base_GHCziBase_Izh_con_info, -8(%rax) > leaq -7(%rax), %rbx > leaq -23(%rax), %rsi > jmp *(%rbp) > .L12: > movapd %xmm6, %xmm0 > addq $1, %rsi > subq $32, %r12 > addsd %xmm5, %xmm0 > addsd .LC2(%rip), %xmm5 > movapd %xmm0, %xmm6 > jmp Main_zdszdwfold_info > > Note even any garbage collection. This should be pretty much the same > performance-wise as unoptimised C. > Uh... I can't actually read x86 assembly, but I'll take your word. ;-) I guess it was kind of a bad example. >> almost any nontrivial program you write >> spends 60% or more of its time doing GC rather than actual work. >> > > Ok, you're doing something very wrong. GC time is typically less than 15% of the running > time of typical work programs I hack on. > > I bet you're using lists inappropriately? > No offense, but from what I can tell, you're a super-ultra-hyper expert in Haskell hacking. It's not surprising that *you* can write fast code. What I'm debating is how easy it is for relative beginners to write performant code. Certainly I'm not attempting to suggest that Haskell programs cannot be fast - this is manifestly false. What I'm contesting is how easy it is to make them fast. I guess because Haskell is such an implicit language, it's very easy to end up implicitly doing a hell of a lot of work without realising you're doing it. Certainly when I first started with Haskell, a lot of non-trivial programs I wrote were *horrifyingly* slow, or ate astonishing amounts of RAM. (My favourite one was that time I tried to use the "length" function to decide when to switch from quick-sort to insert sort. I'll leave you to guess what this did to the performance levels...) Today, my programs generally work better - but there's still a long, long way from being "fast". > I think there is a problem that few people are taking the time to understand > the compilation model of Haskell, while they've had the C runtime behaviour > drilled into their brains since college. > > Until you sit down and understand what your Haskell code means, it will be very > hard to reason about optimisations, unfortunately. > You're probably right about all that. I would humbly suggest that what is somewhat lacking is a good, introductory, high-level text on what makes Haskell go fast and what makes it go slow. As with many things in the Haskell world, there are bits and pieces of information out there, but it's difficult to track them all down and present a coherant picture. We've got a section on the wiki containing scraps and snippets of information. There are various GHC-related papers [if you can find them online]. GHC has various profiling possibilities, but thus far I've found it difficult to digest the results. We need a good, thorough body of text on this subject, I feel. [Of course, that still means somebody has to write one...] Maybe Real World Haskell will contain such a thing. Certainly making your code not crawl is a very significant real-world issue! ;-) > GHC does what it does well Not contesting that. ;-) > and it's predictable. As long as you understand > the operations you're trying to make predictions about. > That's the part I'm contesting. I feel I have a pretty solid basic understanding of what's going on, and yet benchmark results continue to astonish me... > I suggest installing ghc-core, and looking at how your code is compiled. > Try many examples, and have a good knowledge of the STG paper. > 1. What is "ghc-core"? 2. Does anybody know how to actually read GHC's Core output anyway? To me, it looks almost exactly like very, very complicated Haskell source with a suspicious concentration of case expressions - but I understand that in the Core language, many constructs actually mean something quite different. 3. Any idea where the STG paper is? Is it still an accurate reflection of GHC's current technology? From bulat.ziganshin at gmail.com Tue May 13 16:57:13 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue May 13 16:53:23 2008 Subject: [Haskell-cafe] GHC predictability In-Reply-To: <20080513203407.GE22506@scytale.galois.com> References: <20080509212412.GE24396@scytale.galois.com> <48289421.2070408@btinternet.com> <2608b8a80805121627s480ef1fgc0baa3fb4c5d79e1@mail.gmail.com> <20080513062022.GA19372@scytale.galois.com> <4829FA56.1090903@btinternet.com> <20080513203407.GE22506@scytale.galois.com> Message-ID: <24656920.20080514005713@gmail.com> Hello Don, Wednesday, May 14, 2008, 12:34:07 AM, you wrote: >> high-level understanding of what's going on. The STG paper isn't a good >> way to get that high-level overview. > Andrew, would you say you understand the original problem of why > mean xs = sum xs / fromIntegral (length xs) > was a bad idea now? Or why the left folds were a better solution? i think that the problem is just what xs can't be consumed while it generated because it's used two times and this may be understood just by learning reduction graph as strategy of Haskell evaluation. isn't? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From andrewcoppin at btinternet.com Tue May 13 17:01:28 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Tue May 13 16:55:00 2008 Subject: [Haskell-cafe] GHC predictability In-Reply-To: <20080513203407.GE22506@scytale.galois.com> References: <20080509212412.GE24396@scytale.galois.com> <48289421.2070408@btinternet.com> <2608b8a80805121627s480ef1fgc0baa3fb4c5d79e1@mail.gmail.com> <20080513062022.GA19372@scytale.galois.com> <4829FA56.1090903@btinternet.com> <20080513203407.GE22506@scytale.galois.com> Message-ID: <482A01A8.3060801@btinternet.com> Don Stewart wrote: > Andrew, would you say you understand the original problem of why > > mean xs = sum xs / fromIntegral (length xs) > > was a bad idea now? Or why the left folds were a better solution? > That definition of mean is wrong because it traverses the list twice. (Curiosity: would traversing it twice in parallel work any better?) As for the folds - I always *always* mix up left and right folds. Every single damn time I want a fold I have to look it up to see which one I want. I had a similar problem with learning to drive, by the way... the consequences there are of course much more serious than just crashing your _computer_... It was probably a poor example. The point I was attempting to make is that in Haskell, very subtle little things can have an unexpectedly profound effect. If you don't know what you're supposed to be looking for, it can be really hard to see why your program is performing badly. For what it's worth, I think I *do* currently have a reasonably gasp of how lazzy evaluation works, normal order reduction, graph machines, and so on. And yet, I still have trouble making my code go fast sometimes. As I said in another post, if I can track down some *specific* programs I've written and had problems with, maybe we can have a more meaningful debate about it. From andrewcoppin at btinternet.com Tue May 13 17:12:12 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Tue May 13 17:05:49 2008 Subject: [Haskell-cafe] Endianess In-Reply-To: References: <20080509212412.GE24396@scytale.galois.com> <48289421.2070408@btinternet.com> Message-ID: <482A042C.6050305@btinternet.com> Aaron Denney wrote: > On 2008-05-12, Andrew Coppin wrote: > >> (Stupid little-endian nonsense... mutter mutter...) >> > > I used to be a big-endian advocate, on the principle that it doesn't > really matter, and it was standard network byte order. Now I'm > convinced that little endian is the way to go, as bit number n should > have value 2^n, byte number n should have value 256^n, and so forth. > > Yes, in human to human communication there is value in having the most > significant bit first. Not really true for computer-to-computer > communication. > It just annoys me that the number 0x12345678 has to be transmuted into 0x78563412 just because Intel says so. Why make everything so complicated? [Oh GOD I hope I didn't just start a Holy War...] From lennart at augustsson.net Tue May 13 17:13:35 2008 From: lennart at augustsson.net (Lennart Augustsson) Date: Tue May 13 17:07:21 2008 Subject: [Haskell-cafe] Endianess (was Re: GHC predictability) In-Reply-To: References: <20080509212412.GE24396@scytale.galois.com> <48289421.2070408@btinternet.com> Message-ID: Also, the way we write numbers is little endian when writing in Arabic; we just forgot to reverse the digits when we borrowed the notation. Little endian is more logical unless you also number your bits with MSB as bit 0. On Tue, May 13, 2008 at 7:35 PM, Aaron Denney wrote: > On 2008-05-12, Andrew Coppin wrote: >> (Stupid little-endian nonsense... mutter mutter...) > > I used to be a big-endian advocate, on the principle that it doesn't > really matter, and it was standard network byte order. Now I'm > convinced that little endian is the way to go, as bit number n should > have value 2^n, byte number n should have value 256^n, and so forth. > > Yes, in human to human communication there is value in having the most > significant bit first. Not really true for computer-to-computer > communication. > > -- > Aaron Denney > -><- > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From harkiisk at utu.fi Tue May 13 17:31:17 2008 From: harkiisk at utu.fi (Harri Kiiskinen) Date: Tue May 13 17:25:14 2008 Subject: [Haskell-cafe] HSFFIG compilation problem Message-ID: <1210714277.2671.32.camel@localhost.localdomain> Hello, I've tried to compile hsffig-1.0pl2, unsuccesfully, also from the unstable darcs repo. I'm using ghc-6.8 (ghc6-6.8.2 from Debian unstable). HSFFIG comes with its own version of Cabal, but I cannot get past the configuration phase (./cabal-setup configure), when I get the following output: Configuring HSFFIG-1.0... configure: searching for ghc in path. configure: found ghc at /usr/bin/ghc configure: looking for package tool: ghc-pkg near compiler in /usr/bin/ghc configure: found package tool in /usr/bin/ghc-pkg configure: Using install prefix: /usr/local configure: Using compiler: /usr/bin/ghc configure: Compiler flavor: GHC configure: Compiler version: 6.8.2 configure: Using package tool: /usr/bin/ghc-pkg configure: Using haddock: /usr/bin/haddock configure: Using happy: /usr/bin/happy configure: Using alex: /usr/bin/alex configure: Using hsc2hs: /usr/bin/hsc2hs configure: Using cpphs: /usr/bin/cpphs configure: Reading installed packages... configure: Dependency base-any: using base-3.0.1.0 cannot satisfy dependency text-any Does anyone have an idea, how the dependency 'text-any' could be satisfied? Harri K. From prstanley at ntlworld.com Tue May 13 17:35:16 2008 From: prstanley at ntlworld.com (PR Stanley) Date: Tue May 13 17:29:05 2008 Subject: [Haskell-cafe] Maybe a, The Rationale In-Reply-To: <878wyh5i4y.fsf@nmd9999.imr.no> References: <7.0.1.0.0.20080510233243.01d44f90@ntlworld.com> <878wyh5i4y.fsf@nmd9999.imr.no> Message-ID: <7.0.1.0.0.20080513222904.01d848a0@ntlworld.com> > Paul: What is the underlying rationale for the Maybe data type? > >It is the equivalent of a database field that can be NULL. Paul: shock, horror! the null value or the absence of any value denoted by null is not really in harmony with the relational model. > > is it the safe style of programming it encourages/ > >Yes. Consider C, where this is typically done with a NULL pointer, or >Lisp, where you use the empty list, nil. These are perfectly good >values in themselves, while Nothing is just Nothing, if you pardon the >pun. > >-k >-- >If I haven't seen further, it is by standing in the footprints of giants From barsoap at web.de Tue May 13 17:37:28 2008 From: barsoap at web.de (Achim Schneider) Date: Tue May 13 17:31:30 2008 Subject: [Haskell-cafe] Re: GHC predictability References: <20080513023043.GA3520@scytale.galois.com> <482A00DD.7050701@btinternet.com> Message-ID: <20080513233728.0ec26833@solaris> Andrew Coppin wrote: > You're probably right about all that. I would humbly suggest that > what is somewhat lacking is a good, introductory, high-level text on > what makes Haskell go fast and what makes it go slow. As with many > things in the Haskell world, there are bits and pieces of information > out there, but it's difficult to track them all down and present a > coherant picture. We've got a section on the wiki containing scraps > and snippets of information. There are various GHC-related papers [if > you can find them online]. GHC has various profiling possibilities, > but thus far I've found it difficult to digest the results. We need a > good, thorough body of text on this subject, I feel. [Of course, that > still means somebody has to write one...] > Something like the history paper but concentrating on algorithms, techniques & tricks would be great, yes. And, most importantly, less buzzwords where you're lucky if you find a definition of it by googling. > 1. What is "ghc-core"? > An intermediate language, I'm quoting from memory: First comes a Syntax tree, then the type checker, then the translation to core, then optimisations on core (, then the printout) and finally c/assembly. > 2. Does anybody know how to actually read GHC's Core output anyway? > To me, it looks almost exactly like very, very complicated Haskell > source with a suspicious concentration of case expressions - but I > understand that in the Core language, many constructs actually mean > something quite different. > I found it rather easy to parse... as long as you succeed in finding what you're looking for behind all that inlining. Types ending in # mean they're unboxed. It's particularly useful to find out how much ghc specialises your code. > 3. Any idea where the STG paper is? Is it still an accurate > reflection of GHC's current technology? > http://research.microsoft.com/~simonpj/Papers/papers.html Implementing lazy functional languages on stock hardware: the Spineless Tagless G-machine, SL Peyton Jones, Journal of Functional Programming 2(2), Apr 1992, pp127-202. while googling for it, I stumbled across http://citeseer.ist.psu.edu/reid98putting.html which might be more actual, but I neither read it yet or have any idea whatsoever. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. From ndmitchell at gmail.com Tue May 13 17:45:07 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Tue May 13 17:38:53 2008 Subject: [Haskell-cafe] Re: GHC predictability In-Reply-To: <482A00DD.7050701@btinternet.com> References: <20080513023043.GA3520@scytale.galois.com> <482A00DD.7050701@btinternet.com> Message-ID: <404396ef0805131445l2c2a6a2cu68442ffcc2420f9a@mail.gmail.com> Hi > 1. What is "ghc-core"? You actually answer this question as part of question 2. Think of it as simple Haskell with some additional bits. > 2. Does anybody know how to actually read GHC's Core output anyway? > To me, > it looks almost exactly like very, very complicated Haskell source with a > suspicious concentration of case expressions - but I understand that in the > Core language, many constructs actually mean something quite different. There is one different from standard Haskell I am aware of. In Core, case x of _ -> 1 will evaluate x, in Haskell it won't. Other than that, its just Haskell, but without pattern matching and only cases - hence the rather high number of cases. Thanks Neil From dons at galois.com Tue May 13 17:47:49 2008 From: dons at galois.com (Don Stewart) Date: Tue May 13 17:41:47 2008 Subject: [Haskell-cafe] Re: GHC predictability In-Reply-To: <404396ef0805131445l2c2a6a2cu68442ffcc2420f9a@mail.gmail.com> References: <20080513023043.GA3520@scytale.galois.com> <482A00DD.7050701@btinternet.com> <404396ef0805131445l2c2a6a2cu68442ffcc2420f9a@mail.gmail.com> Message-ID: <20080513214749.GG22506@scytale.galois.com> ndmitchell: > Hi > > > 1. What is "ghc-core"? > > You actually answer this question as part of question 2. Think of it > as simple Haskell with some additional bits. > > > 2. Does anybody know how to actually read GHC's Core output anyway? > > To me, > > it looks almost exactly like very, very complicated Haskell source with a > > suspicious concentration of case expressions - but I understand that in the > > Core language, many constructs actually mean something quite different. > > There is one different from standard Haskell I am aware of. In Core, > case x of _ -> 1 will evaluate x, in Haskell it won't. Other than > that, its just Haskell, but without pattern matching and only cases - > hence the rather high number of cases. Well, 'let's too, which bind either unlifted or lifted values. If they're binding lifted things, that's a thunk being allocated. -- Don From wnoise at ofb.net Tue May 13 18:40:57 2008 From: wnoise at ofb.net (Aaron Denney) Date: Tue May 13 18:35:53 2008 Subject: [Haskell-cafe] Re: Endianess References: <20080509212412.GE24396@scytale.galois.com> <48289421.2070408@btinternet.com> <482A042C.6050305@btinternet.com> Message-ID: On 2008-05-13, Andrew Coppin wrote: > Aaron Denney wrote: >> On 2008-05-12, Andrew Coppin wrote: >> >>> (Stupid little-endian nonsense... mutter mutter...) >>> >> >> I used to be a big-endian advocate, on the principle that it doesn't >> really matter, and it was standard network byte order. Now I'm >> convinced that little endian is the way to go, as bit number n should >> have value 2^n, byte number n should have value 256^n, and so forth. >> >> Yes, in human to human communication there is value in having the most >> significant bit first. Not really true for computer-to-computer >> communication. >> > > It just annoys me that the number 0x12345678 has to be transmuted into > 0x78563412 just because Intel says so. Why make everything so complicated? > > [Oh GOD I hope I didn't just start a Holy War...] On the other hand I appreciate that the consecutive memory locations containing [1][0][0][0] are the number 1, no matter whether you're reading a byte, a short, or an int. -- Aaron Denney -><- From derek.a.elkins at gmail.com Tue May 13 19:05:17 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Tue May 13 18:59:06 2008 Subject: [Haskell-cafe] Analog data acquisition In-Reply-To: <78dc001e0805131148o548c11f0l82c863022a3be4b@mail.gmail.com> References: <78dc001e0805130927g72aac077yaae100ae90008297@mail.gmail.com> <20080513183530.GB22506@scytale.galois.com> <78dc001e0805131148o548c11f0l82c863022a3be4b@mail.gmail.com> Message-ID: <1210719917.5514.68.camel@derek-laptop> On Tue, 2008-05-13 at 19:48 +0100, Tom Nielsen wrote: > Yes. I guess I have to wait for chapter 19, then? Just read the FFI Addendum: http://www.cse.unsw.edu.au/~chak/haskell/ffi/ It's not complicated at all. From allbery at ece.cmu.edu Tue May 13 19:15:00 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Tue May 13 19:08:48 2008 Subject: [Haskell-cafe] GHC predictability In-Reply-To: <482A01A8.3060801@btinternet.com> References: <20080509212412.GE24396@scytale.galois.com> <48289421.2070408@btinternet.com> <2608b8a80805121627s480ef1fgc0baa3fb4c5d79e1@mail.gmail.com> <20080513062022.GA19372@scytale.galois.com> <4829FA56.1090903@btinternet.com> <20080513203407.GE22506@scytale.galois.com> <482A01A8.3060801@btinternet.com> Message-ID: <70B7AD12-3352-462E-A1EF-CF205E7E5586@ece.cmu.edu> On 2008 May 13, at 17:01, Andrew Coppin wrote: > That definition of mean is wrong because it traverses the list > twice. (Curiosity: would traversing it twice in parallel work any > better?) As for the folds - I always *always* mix up It might work "better" but you're still wasting a core that could be put to better use doing something more sensible. It's pretty much always best to do all the calculations that require traversing a given list in a single traversal. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From allbery at ece.cmu.edu Tue May 13 19:15:42 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Tue May 13 19:09:28 2008 Subject: [Haskell-cafe] Endianess In-Reply-To: <482A042C.6050305@btinternet.com> References: <20080509212412.GE24396@scytale.galois.com> <48289421.2070408@btinternet.com> <482A042C.6050305@btinternet.com> Message-ID: <3A477F1B-7D7B-4123-B8DC-1C1917FBC961@ece.cmu.edu> On 2008 May 13, at 17:12, Andrew Coppin wrote: > [Oh GOD I hope I didn't just start a Holy War...] Er, I'd say it's already well in progress. :/ -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From john at repetae.net Tue May 13 20:15:37 2008 From: john at repetae.net (John Meacham) Date: Tue May 13 20:09:21 2008 Subject: [Haskell-cafe] Data.Dynamic over the wire In-Reply-To: <4829D240.60504@jellybean.co.uk> References: <4829D240.60504@jellybean.co.uk> Message-ID: <20080514001537.GA29215@sliver.repetae.net> I use a trick like this to allow saving of dynamics into ho files for jhc, the same thing will work for network connections. see Info.Info for the data type, and Info.Binary for the binary serialization routines. http://repetae.net/dw/darcsweb.cgi?r=jhc;a=tree;f=/Info John -- John Meacham - ?repetae.net?john? From gwern0 at gmail.com Tue May 13 20:20:32 2008 From: gwern0 at gmail.com (Gwern Branwen) Date: Tue May 13 20:15:12 2008 Subject: [Haskell-cafe] HSFFIG compilation problem In-Reply-To: <1210714277.2671.32.camel@localhost.localdomain> References: <1210714277.2671.32.camel@localhost.localdomain> Message-ID: <20080514002032.GB20584@localhost> On 2008.05.13 23:31:17 +0200, Harri Kiiskinen scribbled 1.1K characters: > Hello, > > I've tried to compile hsffig-1.0pl2, unsuccesfully, also from the > unstable darcs repo. I'm using ghc-6.8 (ghc6-6.8.2 from Debian > unstable). HSFFIG comes with its own version of Cabal, but I cannot get > past the configuration phase (./cabal-setup configure), when I get the > following output: > > Configuring HSFFIG-1.0... > configure: searching for ghc in path. > configure: found ghc at /usr/bin/ghc > configure: looking for package tool: ghc-pkg near compiler > in /usr/bin/ghc > configure: found package tool in /usr/bin/ghc-pkg > configure: Using install prefix: /usr/local > configure: Using compiler: /usr/bin/ghc > configure: Compiler flavor: GHC > configure: Compiler version: 6.8.2 > configure: Using package tool: /usr/bin/ghc-pkg > configure: Using haddock: /usr/bin/haddock > configure: Using happy: /usr/bin/happy > configure: Using alex: /usr/bin/alex > configure: Using hsc2hs: /usr/bin/hsc2hs > configure: Using cpphs: /usr/bin/cpphs > configure: Reading installed packages... > configure: Dependency base-any: using base-3.0.1.0 > cannot satisfy dependency text-any > > Does anyone have an idea, how the dependency 'text-any' could be > satisfied? > > Harri K. hsffig is old enough you should probably be using the latest, from Darcs (although the last patch is still from February 2006): . I got a little further by running make and then modifying the build-depends: +Build-depends: base>3, parsec, hxt, Cabal>=1.1.3, filepath, unix, process, containers, array, directory Which leads to a bunch of build errors: [ 5 of 14] Compiling TokenOps ( programs/TokenOps.hs, dist/build/ffipkg/ffipkg-tmp/TokenOps.o ) programs/TokenOps.hs:48:11: No instance for (Text.Parsec.Prim.Stream s mtl-1.1.0.0:Control.Monad.Identity.Identity Token) arising from a use of `tokenTest' at programs/TokenOps.hs:48:11-45 Possible fix: add an instance declaration for (Text.Parsec.Prim.Stream s mtl-1.1.0.0:Control.Monad.Identity.Identity Token) In the expression: tokenTest (TCOMM_OPEN undefined) tf In the definition of `commOpen': commOpen = tokenTest (TCOMM_OPEN undefined) tf where tf (TCOMM_OPEN _) (TCOMM_OPEN _) = True tf _ _ = False programs/TokenOps.hs:52:12: No instance for (Text.Parsec.Prim.Stream s1 mtl-1.1.0.0:Control.Monad.Identity.Identity Token) arising from a use of `tokenTest' at programs/TokenOps.hs:52:12-47 Possible fix: add an instance declaration for (Text.Parsec.Prim.Stream s1 mtl-1.1.0.0:Control.Monad.Identity.Identity Token) In the expression: tokenTest (TCOMM_CLOSE undefined) tf In the definition of `commClose': commClose = tokenTest (TCOMM_CLOSE undefined) tf where tf (TCOMM_CLOSE _) (TCOMM_CLOSE _) = True tf _ _ = False programs/TokenOps.hs:58:10: No instance for (Text.Parsec.Prim.Stream s2 mtl-1.1.0.0:Control.Monad.Identity.Identity Token) arising from a use of `tokenTest' at programs/TokenOps.hs:58:10-50 Possible fix: add an instance declaration for (Text.Parsec.Prim.Stream s2 mtl-1.1.0.0:Control.Monad.Identity.Identity Token) In the expression: tokenTest (TKFILE undefined undefined) tf In the definition of `anyFile': anyFile = tokenTest (TKFILE undefined undefined) tf where tf (TKFILE _ _) (TKFILE _ _) = True tf _ _ = False programs/TokenOps.hs:64:12: No instance for (Text.Parsec.Prim.Stream s3 mtl-1.1.0.0:Control.Monad.Identity.Identity Token) arising from a use of `tokenTest' at programs/TokenOps.hs:64:12-54 Possible fix: add an instance declaration for (Text.Parsec.Prim.Stream s3 mtl-1.1.0.0:Control.Monad.Identity.Identity Token) In the expression: tokenTest (TKSTRING undefined undefined) tf In the definition of `anyString': anyString = tokenTest (TKSTRING undefined undefined) tf where tf (TKSTRING _ _) (TKSTRING _ _) = True tf _ _ = False programs/TokenOps.hs:70:9: No instance for (Text.Parsec.Prim.Stream s4 mtl-1.1.0.0:Control.Monad.Identity.Identity Token) arising from a use of `tokenTest' at programs/TokenOps.hs:70:9-48 Possible fix: add an instance declaration for (Text.Parsec.Prim.Stream s4 mtl-1.1.0.0:Control.Monad.Identity.Identity Token) In the expression: tokenTest (TKDEF undefined undefined) tf In the definition of `anyDef': anyDef = tokenTest (TKDEF undefined undefined) tf where tf (TKDEF _ _) (TKDEF _ _) = True tf _ _ = False programs/TokenOps.hs:115:8: No instance for (Text.Parsec.Prim.Stream s5 mtl-1.1.0.0:Control.Monad.Identity.Identity Token) arising from a use of `tokenTest' at programs/TokenOps.hs:115:8-45 Possible fix: add an instance declaration for (Text.Parsec.Prim.Stream s5 mtl-1.1.0.0:Control.Monad.Identity.Identity Token) In the expression: tokenTest (TKW undefined undefined) tf In the definition of `anyKw': anyKw = tokenTest (TKW undefined undefined) tf where tf (TKW _ _) (TKW _ _) = True tf _ _ = False programs/TokenOps.hs:121:8: No instance for (Text.Parsec.Prim.Stream s6 mtl-1.1.0.0:Contr ---- Oh dear. I suppose one might want to ask the hsffig devs whether they will update hsffig / trouble-shoot this, or if hsffig is even still worth using (perhaps it was meant to occupy a niche since filled). -- gwern JD Uzbekistan SARL Goldman Mole Hello 52 SGDN Red SIG -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080513/7ed849cb/attachment.bin From trebla at vex.net Tue May 13 21:04:00 2008 From: trebla at vex.net (Albert Y. C. Lai) Date: Tue May 13 20:58:03 2008 Subject: [Haskell-cafe] Re: GHC predictability In-Reply-To: <482A00DD.7050701@btinternet.com> References: <20080513023043.GA3520@scytale.galois.com> <482A00DD.7050701@btinternet.com> Message-ID: <482A3A80.3080703@vex.net> Andrew Coppin wrote: > 2. Does anybody know how to actually read GHC's Core output anyway? To > me, it looks almost exactly like very, very complicated Haskell source > with a suspicious concentration of case expressions - but I understand > that in the Core language, many constructs actually mean something quite > different. I can read most of GHC Core. I was never taught, and I never asked. I did not read GHC's source code. I just guessed. I agree with your assessment about the domination by case expressions. They spell out the evaluation order. You need truckloads of them. I slightly agree with your assessment about "complicated", but I call it detailed and tedious. This is an assembly language for functional programming. If it weren't detailed and tedious, it would have no right to exist. From oddron at gmail.com Tue May 13 21:06:11 2008 From: oddron at gmail.com (Ronald Guida) Date: Tue May 13 20:59:57 2008 Subject: [Haskell-cafe] Commutative monads vs Applicative functors Message-ID: <62728db30805131806q232cc251g24bf64acadd033af@mail.gmail.com> I have a few questions about commutative monads and applicative functors. >From what I have read about applicative functors, they are weaker than monads because with a monad, I can use the results of a computation to select between alternative future computations and their side effects, whereas with an applicative functor, I can only select between the results of computations, while the structure of those computations and their side effects are fixed in advance. But then there are commutative monads. I'm not exactly sure what a commutative monad is, but my understanding is that in a commutative monad the order of side effects does not matter. This leads me to wonder, are commutative monads still stronger than applicative functors, or are they equivalent? And by the way, what exactly is a commutative monad? From wqeqweuqy at hotmail.com Tue May 13 22:23:21 2008 From: wqeqweuqy at hotmail.com (Neal Alexander) Date: Tue May 13 22:17:27 2008 Subject: [Haskell-cafe] Re: Parsec3 performance issues (in relation to v2) In-Reply-To: <62634.86.145.154.157.1210712205.squirrel@www.gradwell.com> References: <62634.86.145.154.157.1210712205.squirrel@www.gradwell.com> Message-ID: Philippa Cowderoy wrote: > On Tue, May 13, 2008 5:53 am, Neal Alexander wrote: >> I can post the full profiling info if anyone really cares. >> > > Any info is helpful. It's taking a while to get round to things, but the > more relevant info we have to hand when we do the easier it is to improve > things and the less begging for data we have to do! > I stripped the code down to just the parsec related stuff and retested it. http://72.167.145.184:8000/parsec_test/Parsec2.prof http://72.167.145.184:8000/parsec_test/Parsec3.prof And the parser with a 9mb (800 kb gziped) sample log file: http://72.167.145.184:8000/parsec_test.tar.gz From aslatter at gmail.com Wed May 14 00:43:47 2008 From: aslatter at gmail.com (Antoine Latter) Date: Wed May 14 00:37:33 2008 Subject: [Haskell-cafe] Re: Parsec3 performance issues (in relation to v2) In-Reply-To: References: <62634.86.145.154.157.1210712205.squirrel@www.gradwell.com> Message-ID: <694519c50805132143s7237aee1s31eef8e3af308508@mail.gmail.com> On Tue, May 13, 2008 at 9:23 PM, Neal Alexander wrote: > I stripped the code down to just the parsec related stuff and retested it. > > http://72.167.145.184:8000/parsec_test/Parsec2.prof > http://72.167.145.184:8000/parsec_test/Parsec3.prof > > And the parser with a 9mb (800 kb gziped) sample log file: > http://72.167.145.184:8000/parsec_test.tar.gz > So I've been picking at some ways to speed up Parsec 3. I haven't had much success at this benchmark, but one thing confused me: In my hacked-up version, when I change the monadic type from a "data" declaration to a "newtype" declaration, I get a significant slowdown. In the program posted by Neal, I go from ~43 s with "data" to about 1 minute with a "newtype". Is this expected? I don't really understand why adding an extra layer of indirection should speed things up. -Antoine From bulat.ziganshin at gmail.com Wed May 14 01:17:52 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed May 14 01:11:52 2008 Subject: [Haskell-cafe] Re: Parsec3 performance issues (in relation to v2) In-Reply-To: <694519c50805132143s7237aee1s31eef8e3af308508@mail.gmail.com> References: <62634.86.145.154.157.1210712205.squirrel@www.gradwell.com> <694519c50805132143s7237aee1s31eef8e3af308508@mail.gmail.com> Message-ID: <1767157027.20080514091752@gmail.com> Hello Antoine, Wednesday, May 14, 2008, 8:43:47 AM, you wrote: > Is this expected? I don't really understand why adding an extra layer > of indirection should speed things up. adding laziness may improve performance by avoiding calculation of unnecessary stuff or moving into into later stage when it will be immediately consumed -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From ok at cs.otago.ac.nz Wed May 14 01:35:16 2008 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Wed May 14 01:29:08 2008 Subject: [Haskell-cafe] Re: GHC predictability In-Reply-To: <482A00DD.7050701@btinternet.com> References: <20080513023043.GA3520@scytale.galois.com> <482A00DD.7050701@btinternet.com> Message-ID: <5A349526-0595-4542-BAA8-C484580CA734@cs.otago.ac.nz> On 14 May 2008, at 8:58 am, Andrew Coppin wrote: > What I'm trying to say [and saying very badly] is that Haskell is an > almost terrifyingly subtle language. Name me a useful programming language that isn't. Simply interchanging two for-loops, from for (i = 0; i < N; i++) for (j = 0; j < N; j++) to for (j = 0; j < N; j++) for (i = 0; i < N; i++) when marching over an array, can easily slow you down by nearly two orders of magnitude in C. [Hint: read "What every computer scientist needs to know about memory".] For a real shock, take a look at what your C++ templates are doing... There's one big difference between Haskell and language T (my other preferred language). Seemingly insignificant changes in Haskell can kill performance, but seemingly insignificant changes in language T can take you into territory the library designers never thought of where there are lions, tigers, and bears in abundance. "Unexpectedly slow" is better than "inexplicably buggy". From voigt at tcs.inf.tu-dresden.de Wed May 14 01:38:56 2008 From: voigt at tcs.inf.tu-dresden.de (Janis Voigtlaender) Date: Wed May 14 01:30:18 2008 Subject: [Haskell-cafe] Short circuiting and the Maybe monad In-Reply-To: References: <65113aef0805121509s6b4e76bbxd23e86070a2a0be3@mail.gmail.com> Message-ID: <482A7AF0.6020008@tcs.inf.tu-dresden.de> Graham Fawcett wrote: > Yes, but that's still a 'quick' short-circuiting. In your example, if > 'n' is Nothing, then the 'f >>= g >>= h' thunks will not be forced > (thanks to lazy evaluation), regardless of associativity. Tracing > verifies this: No, it doesn't. What your tracing verifies is that the f, g, and h will not be evaluated. It doesn't verify that the 'f >>= g >>= h' part of the expression causes no evaluation overhead. Because that is not true. Consider the following: > import Debug.Trace > data Maybe' a = Nothing' | Just' a deriving Show > instance Monad Maybe' where > return = Just' > Nothing' >>= _ = trace "match" Nothing' > Just' a >>= k = k a > talk s = Just' . (trace s) > f = talk "--f" > g = talk "--g" > h = talk "--h" > foo n = n >>= f >>= g >>= h Now: *Main> foo Nothing' match match match Nothing' So you get three pattern-matches on Nothing', where with the associative variant > foo' n = n >>= \a -> f a >>= \b -> g b >>= h you get only one: *Main> foo' Nothing' match Nothing' For a way to obtain such improvements automatically, and without touching the code, you may want to look into http://wwwtcs.inf.tu-dresden.de/~voigt/mpc08.pdf Ciao, Janis. -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:voigt@tcs.inf.tu-dresden.de From oleg at okmij.org Wed May 14 02:04:29 2008 From: oleg at okmij.org (oleg@okmij.org) Date: Wed May 14 01:59:42 2008 Subject: [Haskell-cafe] Re: Trying to avoid duplicate instances Message-ID: <20080514060429.D1FD7AA92@Adric.metnet.fnmoc.navy.mil> Eric Stansifer wrote: > I am using a bunch of empty type classes to categorize some objects: > > > class FiniteSolidObject o > > class FinitePatchObject o > > class InfiniteSolidObject o > > Since "solid objects" are exactly "finite solid objects" plus > "infinite solid objects", there is an obvious way to code up this > logical relationship. So I try to write: > > > class SolidObject o > > instance FiniteSolidObject o => SolidObject o > > instance InfiniteSolidObject o => SolidObject o There is an easy way to accomplish your goal in GHC, with a couple of simple tricks. First of all, it pays in this and many related cases do define the full predicate for the classification of objects. That is, rather than defining the constraint (FiniteSolidObject o) that succeeds when 'o' is really a FiniteSolidObject and fails otherwise, define a constraint (FiniteSolidObjectP o f) which always succeeds; it unifies the second argument with HTrue if o is indeed FiniteSolidObject, and unifies f with HFalse otherwise. We can easily define the semi-predicate (FiniteSolidObject o) if so needed. That is the first trick. One can then introduce typeclasses HAnd, HOr, etc. and use them to define more complex predicates like SolidObject (which is the logical OR of FiniteSolidObjectP and InfiniteSolidObjectP). Defining the primitive predicates such as FiniteSolidObject does including the trick, the TypeCast. It may appear bizarre; well, if the point is to use it rather than contemplate it, one can just take the pattern for granted. It works. http://okmij.org/ftp/Haskell/typecast.html But there is even a more uniform way, explained in http://okmij.org/ftp/Haskell/poly2.hs http://okmij.org/ftp/Haskell/poly2.txt Using that file, we can write your code as follows: {-# OPTIONS -fglasgow-exts #-} {-# OPTIONS -fallow-undecidable-instances #-} {-# OPTIONS -fallow-overlapping-instances #-} module Mem where -- primitive types data Box = Box data Sphere = Sphere data Mesh = Mesh data Plane = Plane -- classes of types type FiniteSolidObjects = Box :*: Sphere :*: HNil type FinitePatchObjects = Mesh :*: HNil type InfiniteSolidObjects = Plane :*: HNil -- All of finite and infinite solid objects are solid objects type SolidObjects = AllOf FiniteSolidObjects :*: AllOf InfiniteSolidObjects :*: HNil -- membership predicate -- Statically tests if an object of the type x is a member of the class c is_of_class :: forall c x r. Apply (Member c) x r => x -> c -> r is_of_class x t = apply (undefined::Member c) x test1 = is_of_class Box (undefined::FiniteSolidObjects) -- type HTrue test2 = is_of_class Box (undefined::SolidObjects) -- type HTrue test3 = is_of_class Box (undefined::InfiniteSolidObjects) -- type HFalse test4 = is_of_class Plane (undefined::SolidObjects) -- type HTrue -- make a semi-predicate SolidObject class SolidObject c instance Apply (Member SolidObjects) x HTrue => SolidObject x test_solid :: SolidObject x => x -> () test_solid = undefined ts1 = test_solid Plane -- ts3 = test_solid Mesh -- causes the type error -- The following is borrowed verbatim from poly2.hs type Fractionals = Float :*: Double :*: HNil type Nums = Int :*: Integer :*: AllOf Fractionals :*: HNil type Ords = Bool :*: Char :*: AllOf Nums :*: HNil type Eqs = AllOf (TypeCl OpenEqs) :*: AllOfBut Ords Fractionals :*: HNil -- The Fractionals, Nums and Ords above are closed. But Eqs is open -- (i.e., extensible), due to the following: data OpenEqs instance TypeCls OpenEqs () HTrue -- others can be added in the future -- Type class membership testing data AllOf x data AllOfBut x y data TypeCl x -- Classifies if the type x belongs to the open class labeled l -- The result r is either HTrue or HFalse class TypeCls l x r | l x -> r -- the default instance: x does not belong instance TypeCast r HFalse => TypeCls l x r -- Deciding the membership in a closed class, specified -- by enumeration, union and difference data Member tl instance Apply (Member HNil) x HFalse instance TypeCls l x r => Apply (Member (TypeCl l)) x r instance (TypeEq h x bf, MemApp bf t x r) => Apply (Member (h :*: t)) x r instance (Apply (Member h) x bf, MemApp bf t x r) => Apply (Member ((AllOf h) :*: t)) x r instance (Apply (Member exc) x bf, Apply (MemCase2 h t x) bf r) => Apply (Member ((AllOfBut h exc) :*: t)) x r class MemApp bf t x r | bf t x -> r instance MemApp HTrue t x HTrue instance Apply (Member t) x r => MemApp HFalse t x r -- we avoid defining a new class like MemApp above. -- I guess, after Apply, we don't need a single class ever? data MemCase2 h t x instance Apply (Member t) x r => Apply (MemCase2 h t x) HTrue r instance Apply (Member ((AllOf h) :*: t)) x r => Apply (MemCase2 h t x) HFalse r testm1 = apply (undefined::Member Fractionals) (1::Float) testm2 = apply (undefined::Member Fractionals) (1::Int) testm3 = apply (undefined::Member Fractionals) () -- The standard HList stuff, extracted from HList library data HNil = HNil data a :*: b = a :*: b infixr 5 :*: data HTrue data HFalse data Z = Z newtype S n = S n class TypeCast a b | a -> b, b->a where typeCast :: a -> b class TypeCast' t a b | t a -> b, t b -> a where typeCast' :: t->a->b class TypeCast'' t a b | t a -> b, t b -> a where typeCast'' :: t->a->b instance TypeCast' () a b => TypeCast a b where typeCast x = typeCast' () x instance TypeCast'' t a b => TypeCast' t a b where typeCast' = typeCast'' instance TypeCast'' () a a where typeCast'' _ x = x class TypeEq x y b | x y -> b instance TypeEq x x HTrue instance TypeCast HFalse b => TypeEq x y b -- A heterogeneous apply operator class Apply f a r | f a -> r where apply :: f -> a -> r apply = undefined -- Normal function application instance Apply (x -> y) x y where apply f x = f x From bruno.oliveira at comlab.ox.ac.uk Wed May 14 04:00:51 2008 From: bruno.oliveira at comlab.ox.ac.uk (Bruno Oliveira) Date: Wed May 14 03:54:50 2008 Subject: [Haskell-cafe] Commutative monads vs Applicative functors In-Reply-To: <62728db30805131806q232cc251g24bf64acadd033af@mail.gmail.com> References: <62728db30805131806q232cc251g24bf64acadd033af@mail.gmail.com> Message-ID: <26EAC8E0-8931-4C4C-8852-76893405DA1D@comlab.ox.ac.uk> Hello, On 14 May 2008, at 02:06, Ronald Guida wrote: > I have a few questions about commutative monads and applicative > functors. > >> From what I have read about applicative functors, they are weaker >> than > monads because with a monad, I can use the results of a computation to > select between alternative future computations and their side effects, > whereas with an applicative functor, I can only select between the > results of computations, while the structure of those computations and > their side effects are fixed in advance. > > But then there are commutative monads. I'm not exactly sure what a > commutative monad is, but my understanding is that in a commutative > monad the order of side effects does not matter. > > This leads me to wonder, are commutative monads still stronger than > applicative functors, or are they equivalent? > I would say that they are stronger because they still support: concat :: Monad m => m (m a) -> m a or (>>=) :: Monad m => m a -> (a -> m b) -> m b which are not supported, in general, by applicative functors. In fact, I would probably risk to say that they are even stronger than monads (as there are less commutative monads than regular monads). > And by the way, what exactly is a commutative monad? > Here is a possible characterization: The monad m is commutative if, for all mx and my: do {x <- mx; y <- my; return (x,y)} = do {y <- my; x <- mx; return (x,y)} As you mentioned above, the basic idea is that the order of the side effects does not matter. This law is not true in general for monads. I am not sure if you know about the paper entitled "The essence of the Iterator Pattern" (by Jeremy Gibbons and myself): http://www.comlab.ox.ac.uk/people/Bruno.Oliveira/iterator-jfp.pdf But, you may be interested to read it as it discusses related ideas. In particular you may want to take a look at Section 5.4. Cheers, Bruno -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080514/bbc23f03/attachment-0001.htm From devriese at cs.tcd.ie Wed May 14 05:11:17 2008 From: devriese at cs.tcd.ie (Edsko de Vries) Date: Wed May 14 05:05:02 2008 Subject: [Haskell-cafe] Monad for HOAS? Message-ID: <20080514091117.GA20684@netsoc.tcd.ie> Hi, Suppose we have some data structure that uses HOAS; typically, a DSL with explicit sharing. For example: > data Expr = One | Add Expr Expr | Let Expr (Expr -> Expr) When I use such a data structure, I find myself writing expressions such as > Let foo $ \a -> > Let bar $ \b -> > Add a b It seems to me that there should be a monad here somewhere, so that I can write this approximately like do a <- foo b <- bar return (Add a b) or something along those lines. It is however not at all clear to me what this monad should look like. I have experimented with adding a type parameter to Expr, something like > data Expr a = One > | Add (Expr a) (Expr a) > | Let (Expr a) (Expr a -> Expr a) > | Place a which has the additional benefit of supporting catamorphisms; I have also experimented with defining various variations on > Let a b = Let a (a -> b) and making Let an instance of Monad rather than Expr; but none of my experiments wered satisfactory. Am I missing something obvious, or is there a good reason this cannot be done? Thanks, Edsko From stansife at caltech.edu Wed May 14 07:51:34 2008 From: stansife at caltech.edu (Eric Stansifer) Date: Wed May 14 07:45:16 2008 Subject: [Haskell-cafe] Re: Trying to avoid duplicate instances In-Reply-To: <20080514060429.D1FD7AA92@Adric.metnet.fnmoc.navy.mil> References: <20080514060429.D1FD7AA92@Adric.metnet.fnmoc.navy.mil> Message-ID: <2e58fd390805140451s4824c071kc48f41036872da01@mail.gmail.com> Thanks for your detailed input -- I appreciate seeing these rather abstract techniques being applied to specific problems. Tom Nielsen pointed me in the direction of the solution you've supplied, so I should have replied to the list that my question had been addressed. Anyhow, I now have code that looks a little like: > class DummySolidObject flag o > class SolidObject o > > instance FiniteSolidObject o => DummySolidObject Dummy1 o > instance InfiniteSolidObject o => DummySolidObject Dummy2 o > instance DummySolidObject d o => SolidObject o > > data Dummy1 > data Dummy2 Thanks, Eric From voigt at tcs.inf.tu-dresden.de Wed May 14 08:44:54 2008 From: voigt at tcs.inf.tu-dresden.de (Janis Voigtlaender) Date: Wed May 14 08:36:15 2008 Subject: [Haskell-cafe] Commutative monads vs Applicative functors In-Reply-To: <62728db30805131806q232cc251g24bf64acadd033af@mail.gmail.com> References: <62728db30805131806q232cc251g24bf64acadd033af@mail.gmail.com> Message-ID: <482ADEC6.3090606@tcs.inf.tu-dresden.de> Ronald Guida wrote: > From what I have read about applicative functors, they are weaker than > monads because with a monad, I can use the results of a computation to > select between alternative future computations and their side effects, > whereas with an applicative functor, I can only select between the > results of computations, while the structure of those computations and > their side effects are fixed in advance. If you are not already aware of them, you might be interested in the following two papers: http://homepages.inf.ed.ac.uk/wadler/papers/arrows-and-idioms/arrows-and-idioms.pdf http://homepages.inf.ed.ac.uk/wadler/papers/arrows/arrows.pdf ("idioms" is a synonym for "applicative functors", and both papers also discuss the relation to monads.) Ciao, Janis. -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:voigt@tcs.inf.tu-dresden.de From la at iki.fi Wed May 14 08:59:58 2008 From: la at iki.fi (Lauri Alanko) Date: Wed May 14 08:53:42 2008 Subject: [Haskell-cafe] Monad for HOAS? In-Reply-To: <20080514091117.GA20684@netsoc.tcd.ie> References: <20080514091117.GA20684@netsoc.tcd.ie> Message-ID: <20080514125958.GA10853@cs.helsinki.fi> On Wed, May 14, 2008 at 10:11:17AM +0100, Edsko de Vries wrote: > Suppose we have some data structure that uses HOAS; typically, a DSL > with explicit sharing. For example: > > > data Expr = One | Add Expr Expr | Let Expr (Expr -> Expr) > > When I use such a data structure, I find myself writing expressions such > as > > > Let foo $ \a -> > > Let bar $ \b -> > > Add a b > > It seems to me that there should be a monad here somewhere, so that I > can write this approximately like > > do a <- foo > b <- bar > return (Add a b) Neat idea, but the monad can't work exactly as you propose, because it'd break the monad laws: do { a <- foo; return a } should be equal to foo, but in your example it'd result in Let foo id. However, with an explicit binding marker the continuation monad does what you want: import Control.Monad.Cont data Expr = One | Add Expr Expr | Let Expr (Expr -> Expr) type ExprM = Cont Expr bind :: Expr -> ExprM Expr bind e = Cont (Let e) runExprM :: ExprM Expr -> Expr runExprM e = runCont e id Now you'd write your example as do a <- bind foo b <- bind bar return (Add a b) HTH. Lauri From Patrick.Surry at portraitsoftware.com Wed May 14 09:43:44 2008 From: Patrick.Surry at portraitsoftware.com (Patrick Surry) Date: Wed May 14 09:37:40 2008 Subject: [Haskell-cafe] Richer (than ascii) notation for haskell source? Message-ID: <93BECC602E286B499D5443ECB850D2FF01331E95@newman.usa.aitgroupad.com> Probably a silly question, but for me one of the nice things about Haskell is that it's a lot like just writing math(s). But in contrast to math you lose a lot of notational flexibility being limited to the ascii character set in your source code. It would be nice to be able to use a richer set of symbols in your source code for operators and functions (e.g. integral, sum, dot and cross-product, ...), as well as variables (the standard upper and lower-case greek for example, along with things like super- and sub-scripting, bold/italic and what-not). You could imagine ending up with source code that reads just like a mathematical paper. Don't know how I'd actually then write/maintain the source-code - some WYSIWYG editor or effectively writing it in '(la)tex'? Maybe that's what Knuth is on about with his 'literate programming' weave/tangle stuff which I don't know much about - does that translate to Haskell? Patrick Patrick.Surry@portraitsoftware.com , VP Technology Tel: (617) 457 5230 Mob: (857) 919 1700 Fax: (617) 457 5299 Map Portrait Software introduces Portrait Campaign Manager : Easy, integrated campaign management for automated and highly targeted outbound marketing http://supportcentre.portraitsoftware.com/Vmail/emailfooter/balloon.gif http://supportcentre.portraitsoftware.com/Vmail/emailfooter/portrait_sof tware_logo.gif www.portraitsoftware.com ________________________________________________________________________ DISCLAIMER: This e-mail is intended only for the addressee named above. As this e-mail may contain confidential or privileged information, if you are not the named addressee, you are not authorised to retain, read, copy or disseminate this message or any part of it. If you received this email in error, please notify the sender and delete the message from your computer. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080514/aafb77ed/attachment.htm From bulat.ziganshin at gmail.com Wed May 14 09:48:21 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed May 14 09:42:31 2008 Subject: [Haskell-cafe] Richer (than ascii) notation for haskell source? In-Reply-To: <93BECC602E286B499D5443ECB850D2FF01331E95@newman.usa.aitgroupad.com> References: <93BECC602E286B499D5443ECB850D2FF01331E95@newman.usa.aitgroupad.com> Message-ID: <83441017.20080514174821@gmail.com> Hello Patrick, Wednesday, May 14, 2008, 5:43:44 PM, you wrote: > It would be nice to be able to use a richer set of symbols in your ghc supports UTF-8 encoded haskell sources and there are lots of utf-8 enabled editors available -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From jules at jellybean.co.uk Wed May 14 09:49:30 2008 From: jules at jellybean.co.uk (Jules Bean) Date: Wed May 14 09:43:17 2008 Subject: [Haskell-cafe] Maybe a, The Rationale In-Reply-To: <7.0.1.0.0.20080513222904.01d848a0@ntlworld.com> References: <7.0.1.0.0.20080510233243.01d44f90@ntlworld.com> <878wyh5i4y.fsf@nmd9999.imr.no> <7.0.1.0.0.20080513222904.01d848a0@ntlworld.com> Message-ID: <482AEDEA.6060207@jellybean.co.uk> PR Stanley wrote: > >> Paul: What is the underlying rationale for the Maybe data type? >> >> It is the equivalent of a database field that can be NULL. > > Paul: shock, horror! the null value or the absence of any value > denoted by null is not really in harmony with the relational model. Ketil should have said: It is the equivalent of the extremely common way of misusing NULL. It doesn't bring in all the unpleasant baggage of three valued logic, but simple indicates an exceptional value. This use of NULL, very common in practical databases, frowned on by DB designers who understand about relational theory and normalisation, is prevalent precisely because common SQL dialects really make it a pain to invent your own datatypes, so it's hard to "add an exceptional value". Practical programming needs a particular exceptional value very often indeed, to model things like optional parameters. If common SQL dialects supported types like 'Maybe Int' natively, then NULL could be used much less. Jules PS Students of NULL and 3-valued logic will note that some of the problem therein can be studied in Haskell by comparing (==) and liftM2 (==) as functions on Maybe Bool, or (>) vs liftM2 (>) on Maybe Int. From barsoap at web.de Wed May 14 10:07:04 2008 From: barsoap at web.de (Achim Schneider) Date: Wed May 14 10:00:54 2008 Subject: [Haskell-cafe] Re: Richer (than ascii) notation for haskell source? References: <93BECC602E286B499D5443ECB850D2FF01331E95@newman.usa.aitgroupad.com> Message-ID: <20080514160704.69042f91@solaris> "Patrick Surry" wrote: > Probably a silly question, but for me one of the nice things about > Haskell is that it's a lot like just writing math(s). But in contrast > to math you lose a lot of notational flexibility being limited to the > ascii character set in your source code. > > Don't know how I'd actually then write/maintain the source-code - some > WYSIWYG editor or effectively writing it in '(la)tex'? > Feel free to extend literal Haskell and e.g. LyX to support this. Shouldn't be too much of work, translating math formulae into plain Haskell code to keep it executable. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. From alec at thened.net Wed May 14 10:16:30 2008 From: alec at thened.net (Alec Berryman) Date: Wed May 14 10:10:14 2008 Subject: [Haskell-cafe] Richer (than ascii) notation for haskell source? In-Reply-To: <93BECC602E286B499D5443ECB850D2FF01331E95@newman.usa.aitgroupad.com> References: <93BECC602E286B499D5443ECB850D2FF01331E95@newman.usa.aitgroupad.com> Message-ID: <20080514141630.GA17460@thened.net> Patrick Surry on 2008-05-14 09:43:44 -0400: > Probably a silly question, but for me one of the nice things about > Haskell is that it's a lot like just writing math(s). But in contrast > to math you lose a lot of notational flexibility being limited to the > ascii character set in your source code. If you use emacs, there's some code that will display arbitrary words/symbols as Greek letters or math symbols: http://www.emacswiki.org/cgi-bin/wiki/PrettyLambda It's cute. It won't replace the actual text, just what's displayed, so if you need to share your code with someone else, they'll still be able to use it. From lemming at henning-thielemann.de Wed May 14 10:47:02 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed May 14 10:39:16 2008 Subject: [Haskell-cafe] Re: Endianess In-Reply-To: <20080513221420.5611a662@solaris> References: <20080509212412.GE24396@scytale.galois.com> <48289421.2070408@btinternet.com> <87ve1ixcrh.fsf@nmd9999.imr.no> <20080513191102.GA11402@brakk.ethz.ch> <20080513221420.5611a662@solaris> Message-ID: On Tue, 13 May 2008, Achim Schneider wrote: > Jed Brown wrote: > >> It's not that simple with bits. They lack consistency just like the >> usual US date format and the way Germans read numbers. >> > So you claim that you pronounce 14 tenty-four? In German pronunciation > is completely uniform from 13 to 99. http://www.verein-zwanzigeins.de/ From ndmitchell at gmail.com Wed May 14 10:45:57 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Wed May 14 10:39:40 2008 Subject: [Haskell-cafe] Richer (than ascii) notation for haskell source? In-Reply-To: <93BECC602E286B499D5443ECB850D2FF01331E95@newman.usa.aitgroupad.com> References: <93BECC602E286B499D5443ECB850D2FF01331E95@newman.usa.aitgroupad.com> Message-ID: <404396ef0805140745m705300a2v99d0ddeacff49b64@mail.gmail.com> Hi > It would be nice to be able to use a richer set of symbols in your source > code for operators and functions (e.g. integral, sum, dot and cross-product, > ?), as well as variables (the standard upper and lower-case greek for > example, along with things like super- and sub-scripting, bold/italic and > what-not). You could imagine ending up with source code that reads just > like a mathematical paper. You probably still want to write in ASCII, as keyboards have buttons for each of the letters in the alphabet, so its much easier. However, you can format your code nicely using lhs2tex - I use it for all my papers. I have things like: %subst alpha = "{\alpha}" Which means I can write: id :: alpha -> alpha The code is valid Haskell, and looks super-pretty in papers. Lhs2tex: http://people.cs.uu.nl/andres/lhs2tex/ Thanks Neil From devriese at cs.tcd.ie Wed May 14 10:59:23 2008 From: devriese at cs.tcd.ie (Edsko de Vries) Date: Wed May 14 10:53:06 2008 Subject: [Haskell-cafe] Monad for HOAS? In-Reply-To: <20080514125958.GA10853@cs.helsinki.fi> References: <20080514091117.GA20684@netsoc.tcd.ie> <20080514125958.GA10853@cs.helsinki.fi> Message-ID: <20080514145922.GA2936@netsoc.tcd.ie> Hi, On Wed, May 14, 2008 at 03:59:58PM +0300, Lauri Alanko wrote: > On Wed, May 14, 2008 at 10:11:17AM +0100, Edsko de Vries wrote: > > Suppose we have some data structure that uses HOAS; typically, a DSL > > with explicit sharing. For example: > > > > > data Expr = One | Add Expr Expr | Let Expr (Expr -> Expr) > > > > When I use such a data structure, I find myself writing expressions such > > as > > > > > Let foo $ \a -> > > > Let bar $ \b -> > > > Add a b > > > > It seems to me that there should be a monad here somewhere, so that I > > can write this approximately like > > > > do a <- foo > > b <- bar > > return (Add a b) > > Neat idea, but the monad can't work exactly as you propose, because > it'd break the monad laws: do { a <- foo; return a } should be equal > to foo, but in your example it'd result in Let foo id. > > However, with an explicit binding marker the continuation monad does > what you want: > > import Control.Monad.Cont > > data Expr = One | Add Expr Expr | Let Expr (Expr -> Expr) > > type ExprM = Cont Expr > > bind :: Expr -> ExprM Expr > bind e = Cont (Let e) > > runExprM :: ExprM Expr -> Expr > runExprM e = runCont e id > > Now you'd write your example as > > do a <- bind foo > b <- bind bar > return (Add a b) Nice. That's certainly a step towards what I was looking for, although it requires slightly more "tags" than I was hoping for :) But I've incorporated it into my code and it's much better already :) You mention that a "direct" implementation of what I suggested would break the monad laws, as (foo) and (Let foo id) are not equal. But one might argue that they are in fact, in a sense, equivalent. Do you reckon that if it is acceptable that foo and do { a <- foo; return a } don't return equal terms (but equivalent terms), we can do still better? Thanks again, Edsko From lemming at henning-thielemann.de Wed May 14 11:06:42 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed May 14 10:58:57 2008 Subject: [Haskell-cafe] Richer (than ascii) notation for haskell source? In-Reply-To: <93BECC602E286B499D5443ECB850D2FF01331E95@newman.usa.aitgroupad.com> References: <93BECC602E286B499D5443ECB850D2FF01331E95@newman.usa.aitgroupad.com> Message-ID: On Wed, 14 May 2008, Patrick Surry wrote: > Probably a silly question, but for me one of the nice things about > Haskell is that it's a lot like just writing math(s). But in contrast > to math you lose a lot of notational flexibility being limited to the > ascii character set in your source code. Leksah supports visualizing keywords as fancy symbols: http://www.leksah.org/ From la at iki.fi Wed May 14 11:25:55 2008 From: la at iki.fi (Lauri Alanko) Date: Wed May 14 11:19:39 2008 Subject: [Haskell-cafe] Monad for HOAS? In-Reply-To: <20080514145922.GA2936@netsoc.tcd.ie> References: <20080514091117.GA20684@netsoc.tcd.ie> <20080514125958.GA10853@cs.helsinki.fi> <20080514145922.GA2936@netsoc.tcd.ie> Message-ID: <20080514152554.GA11519@ruuvi.it.helsinki.fi> On Wed, May 14, 2008 at 03:59:23PM +0100, Edsko de Vries wrote: > You mention that a "direct" implementation of what I suggested would > break the monad laws, as (foo) and (Let foo id) are not equal. But one > might argue that they are in fact, in a sense, equivalent. Do you reckon > that if it is acceptable that foo and do { a <- foo; return a } don't > return equal terms (but equivalent terms), we can do still better? If you just want the syntactic sugar and don't care about monads, in GHC you can use plain do-notation: {-# OPTIONS -fno-implicit-prelude #-} import Prelude hiding ((>>=), fail) data Expr = One | Add Expr Expr | Let Expr (Expr -> Expr) (>>=) = Let fail = error t :: Expr t = do a <- One b <- Add a a Add b b That's generally pretty icky, though. Lauri From barsoap at web.de Wed May 14 11:44:27 2008 From: barsoap at web.de (Achim Schneider) Date: Wed May 14 11:38:20 2008 Subject: [Haskell-cafe] Re: Endianess References: <20080509212412.GE24396@scytale.galois.com> <48289421.2070408@btinternet.com> <87ve1ixcrh.fsf@nmd9999.imr.no> <20080513191102.GA11402@brakk.ethz.ch> <20080513221420.5611a662@solaris> Message-ID: <20080514174427.2ed489e8@solaris> Henning Thielemann wrote: > > On Tue, 13 May 2008, Achim Schneider wrote: > > > Jed Brown wrote: > > > >> It's not that simple with bits. They lack consistency just like > >> the usual US date format and the way Germans read numbers. > >> > > So you claim that you pronounce 14 tenty-four? In German > > pronunciation is completely uniform from 13 to 99. > > http://www.verein-zwanzigeins.de/ > Dammit! Don't affirm the stereotype that any group of like-minded Germans forms an association to affirm importance and ultimately get drowned by the "well I don't care at all" mentality of the rest. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. From mjarmy at gmail.com Wed May 14 11:47:25 2008 From: mjarmy at gmail.com (Mike Jarmy) Date: Wed May 14 11:41:07 2008 Subject: [Haskell-cafe] printing a list of directories which don't exist Message-ID: <6b4a562b0805140847r6c52aa55ic39cd8e11880e656@mail.gmail.com> Newbie question: Given a list of type '[FilePath]', how do I create a list of all those directories which do not actually exist, and then print the list? I've figured out how to extract the ones which *do* exist, like so: module Main where import Control.Monad (filterM) import System.Directory (doesDirectoryExist) import System.Environment (getArgs) main :: IO () main = do dirs <- getArgs let existing = filterM doesDirectoryExist dirs ...... which gives me a list of type 'IO [FilePath]'. However, because of the 'IO' tag, I cannot figure out how to do any of the following 3 things (noted in comments): -- filter via composition let bogusDirs = filterM (not . doesDirectoryExist) dirs -- test for emptiness if bogusDirs /= [] -- print the list then putStrLn $ "bogus: " ++ show bogusDirs else putStrLn "OK" Can anyone set me straight? How do I make the IO tag go away, or am I going about this all wrong? E.g. the 'filterM (not . doesDirectoryExist) dirs' expression gives the following compilation error: ~/code/haskell$ ghc -o newbie newbie.hs newbie.hs:16:35: Couldn't match expected type `Bool' against inferred type `IO Bool' Expected type: FilePath -> Bool Inferred type: FilePath -> IO Bool In the second argument of `(.)', namely `doesDirectoryExist' In the first argument of `filterM', namely `(not . doesDirectoryExist)' -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080514/ae4b7904/attachment.htm From lemming at henning-thielemann.de Wed May 14 11:54:20 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed May 14 11:46:34 2008 Subject: [Haskell-cafe] printing a list of directories which don't exist In-Reply-To: <6b4a562b0805140847r6c52aa55ic39cd8e11880e656@mail.gmail.com> References: <6b4a562b0805140847r6c52aa55ic39cd8e11880e656@mail.gmail.com> Message-ID: On Wed, 14 May 2008, Mike Jarmy wrote: > Newbie question: Given a list of type '[FilePath]', how do I create a list > of all those directories which do not actually exist, and then print the > list? I've figured out how to extract the ones which *do* exist, like so: > > module Main where > > import Control.Monad (filterM) > import System.Directory (doesDirectoryExist) > import System.Environment (getArgs) > > main :: IO () > main = do > dirs <- getArgs > let existing = filterM doesDirectoryExist dirs should be > existing <- filterM doesDirectoryExist dirs I think. From daniel.is.fischer at web.de Wed May 14 12:04:56 2008 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Wed May 14 11:56:51 2008 Subject: [Haskell-cafe] printing a list of directories which don't exist In-Reply-To: <6b4a562b0805140847r6c52aa55ic39cd8e11880e656@mail.gmail.com> References: <6b4a562b0805140847r6c52aa55ic39cd8e11880e656@mail.gmail.com> Message-ID: <200805141804.56831.daniel.is.fischer@web.de> Am Mittwoch, 14. Mai 2008 17:47 schrieb Mike Jarmy: > Newbie question: Given a list of type '[FilePath]', how do I create a list > of all those directories which do not actually exist, and then print the > list? I've figured out how to extract the ones which *do* exist, like so: > > module Main where > > import Control.Monad (filterM) > import System.Directory (doesDirectoryExist) > import System.Environment (getArgs) > > main :: IO () > main = do > dirs <- getArgs > let existing = filterM doesDirectoryExist dirs > ...... > > which gives me a list of type 'IO [FilePath]'. However, because of the > 'IO' tag, I cannot figure out how to do any of the following 3 things > (noted in comments): What you want is 'fmap' (from the Functor class) or 'liftM' (from the Monad class). bogusDirs <- filterM (fmap not . doesDirectoryExist) dirs should work, same with liftM in place of fmap. > > -- filter via composition > let bogusDirs = filterM (not . doesDirectoryExist) dirs > > -- test for emptiness > if bogusDirs /= [] > -- print the list > then putStrLn $ "bogus: " ++ show bogusDirs > else putStrLn "OK" > > Can anyone set me straight? How do I make the IO tag go away, or am I > going about this all wrong? E.g. the 'filterM (not . doesDirectoryExist) > dirs' expression gives the following compilation error: > > ~/code/haskell$ ghc -o newbie newbie.hs > > newbie.hs:16:35: > Couldn't match expected type `Bool' against inferred type `IO Bool' > Expected type: FilePath -> Bool > Inferred type: FilePath -> IO Bool > In the second argument of `(.)', namely `doesDirectoryExist' > In the first argument of `filterM', namely > `(not . doesDirectoryExist)' From conal at conal.net Wed May 14 12:15:59 2008 From: conal at conal.net (Conal Elliott) Date: Wed May 14 12:09:44 2008 Subject: [Haskell-cafe] Monad for HOAS? In-Reply-To: <20080514145922.GA2936@netsoc.tcd.ie> References: <20080514091117.GA20684@netsoc.tcd.ie> <20080514125958.GA10853@cs.helsinki.fi> <20080514145922.GA2936@netsoc.tcd.ie> Message-ID: I share your perspective, Edsko. If foo and (Let foo id) are indistinguishable to clients of your module and are equal with respect to your intended semantics of Exp, then I'd say at least this one monad law holds. - Conal On Wed, May 14, 2008 at 7:59 AM, Edsko de Vries wrote: > Hi, > > On Wed, May 14, 2008 at 03:59:58PM +0300, Lauri Alanko wrote: > > On Wed, May 14, 2008 at 10:11:17AM +0100, Edsko de Vries wrote: > > > Suppose we have some data structure that uses HOAS; typically, a DSL > > > with explicit sharing. For example: > > > > > > > data Expr = One | Add Expr Expr | Let Expr (Expr -> Expr) > > > > > > When I use such a data structure, I find myself writing expressions > such > > > as > > > > > > > Let foo $ \a -> > > > > Let bar $ \b -> > > > > Add a b > > > > > > It seems to me that there should be a monad here somewhere, so that I > > > can write this approximately like > > > > > > do a <- foo > > > b <- bar > > > return (Add a b) > > > > Neat idea, but the monad can't work exactly as you propose, because > > it'd break the monad laws: do { a <- foo; return a } should be equal > > to foo, but in your example it'd result in Let foo id. > > > > However, with an explicit binding marker the continuation monad does > > what you want: > > > > import Control.Monad.Cont > > > > data Expr = One | Add Expr Expr | Let Expr (Expr -> Expr) > > > > type ExprM = Cont Expr > > > > bind :: Expr -> ExprM Expr > > bind e = Cont (Let e) > > > > runExprM :: ExprM Expr -> Expr > > runExprM e = runCont e id > > > > Now you'd write your example as > > > > do a <- bind foo > > b <- bind bar > > return (Add a b) > > Nice. That's certainly a step towards what I was looking for, although > it requires slightly more "tags" than I was hoping for :) But I've > incorporated it into my code and it's much better already :) > > You mention that a "direct" implementation of what I suggested would > break the monad laws, as (foo) and (Let foo id) are not equal. But one > might argue that they are in fact, in a sense, equivalent. Do you reckon > that if it is acceptable that foo and do { a <- foo; return a } don't > return equal terms (but equivalent terms), we can do still better? > > Thanks again, > > Edsko > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080514/1b266709/attachment.htm From dave at zednenem.com Wed May 14 12:59:11 2008 From: dave at zednenem.com (David Menendez) Date: Wed May 14 12:52:55 2008 Subject: [Haskell-cafe] Commutative monads vs Applicative functors In-Reply-To: <62728db30805131806q232cc251g24bf64acadd033af@mail.gmail.com> References: <62728db30805131806q232cc251g24bf64acadd033af@mail.gmail.com> Message-ID: <49a77b7a0805140959v39462883g5950e652f65b5494@mail.gmail.com> On Tue, May 13, 2008 at 9:06 PM, Ronald Guida wrote: > I have a few questions about commutative monads and applicative functors. > > >From what I have read about applicative functors, they are weaker than > monads because with a monad, I can use the results of a computation to > select between alternative future computations and their side effects, > whereas with an applicative functor, I can only select between the > results of computations, while the structure of those computations and > their side effects are fixed in advance. > > But then there are commutative monads. I'm not exactly sure what a > commutative monad is, but my understanding is that in a commutative > monad the order of side effects does not matter. > > This leads me to wonder, are commutative monads still stronger than > applicative functors, or are they equivalent? > > And by the way, what exactly is a commutative monad? A monad is commutative if the expression "a >>= \x -> b >>= \y -> f x y" is equivalent to "b >>= \y -> a >>= \x -> f x y". The identity, state reader, and maybe monads are commutative, for example. To put it another way, a monad is commutative if liftM2 f a b = liftM2 (flip f) b a Since liftA2 generalizes liftM2, we can also say that an applicative functor is commutative if liftA2 f a b = liftA2 (flip f) b a Or, put another way, if a <*> b = flip ($) <$> b <*> a If w is a commutative monoid (that is, if mappend w1 w2 == mappend w2 w1), then Const w is a commutative applicative functor. To summarize: some applicative functors are commutative, some applicative functors are monads, and the ones that are both are commutative monads. -- Dave Menendez From paul at cogito.org.uk Wed May 14 13:08:28 2008 From: paul at cogito.org.uk (Paul Johnson) Date: Wed May 14 13:02:13 2008 Subject: [Haskell-cafe] Two-iteration optimisation (was: GHC Predictability) Message-ID: <482B1C8C.4060509@cogito.org.uk> We've had a big debate over > mean xs = foldl' (+) 0 xs / fromIntegral (length xs) For anyone who didn't follow it, the problem is that "mean" needs to traverse its argument twice, so the entire list has to be held in memory. So if "xs = [1..1000000000]" then "mean xs" uses all your memory, but "foldl' (+) 0 xs" and "length xs" by themselves do not. The solution is for the programmer to rewrite "mean" to accumulate a pair containing the running total and count together, then do the division. This makes me wonder: could there be a compiler optimisation rule for this, collapsing two iterations over a list into one. I've never tried writing GHC rules, but something like: > f (foldl' g x) (foldl' h x) = (uncurry f) (foldl' (\i (gt,ht) -> (g i gt, h i ht))) The first problem that occurs to me is the number of permutations of fold and map functions. Paul. From tux_rocker at reinier.de Wed May 14 13:20:14 2008 From: tux_rocker at reinier.de (Reinier Lamers) Date: Wed May 14 13:14:30 2008 Subject: [Haskell-cafe] Richer (than ascii) notation for haskell source? In-Reply-To: <93BECC602E286B499D5443ECB850D2FF01331E95@newman.usa.aitgroupad.com> References: <93BECC602E286B499D5443ECB850D2FF01331E95@newman.usa.aitgroupad.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Op 14-mei-2008, om 15:43 heeft Patrick Surry het volgende geschreven: > It would be nice to be able to use a richer set of symbols in your > source code for operators and functions (e.g. integral, sum, dot > and cross-product, ?), as well as variables (the standard upper > and lower-case greek for example, along with things like super- and > sub-scripting, bold/italic and what-not). You could imagine ending > up with source code that reads just like a mathematical paper. > People have already thought about this, and it partly works already in GHC. See http://hackage.haskell.org/trac/haskell-prime/wiki/ UnicodeInHaskellSource. I don't like, however, the tendency of many Haskell authors to use math-like variable names. There are far to many Haskell programs where you rarely find a variable name of more than three letters, and all those variables that have more than one letter are English names for Greek letters like 'phi' or 'mu'. It makes a difference for your style whether you are just talking to humans (a math paper) or to humans and compilers at the same time (a computer program). When talking to a compiler, the compiler is not interested in the semantical explanations, so programmers mostly leave them out. But when you do that, you must make sure that the formal language is still comprehensible to humans - I'd say by using descriptive variable names. Regards, Reinier -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkgrH04ACgkQR3bgBiWODBfrBQCeLVEIiYDbXdCFJbTI4HZkJr7e qysAn2M3XDynT/NAINsVaeH23XVre1Kf =Zv7j -----END PGP SIGNATURE----- From dons at galois.com Wed May 14 13:20:45 2008 From: dons at galois.com (Don Stewart) Date: Wed May 14 13:14:57 2008 Subject: [Haskell-cafe] Two-iteration optimisation (was: GHC Predictability) In-Reply-To: <482B1C8C.4060509@cogito.org.uk> References: <482B1C8C.4060509@cogito.org.uk> Message-ID: <20080514172045.GA10746@scytale.galois.com> paul: > We've had a big debate over > > > mean xs = foldl' (+) 0 xs / fromIntegral (length xs) > > For anyone who didn't follow it, the problem is that "mean" needs to > traverse its argument twice, so the entire list has to be held in > memory. So if "xs = [1..1000000000]" then "mean xs" uses all your > memory, but "foldl' (+) 0 xs" and "length xs" by themselves do not. > > The solution is for the programmer to rewrite "mean" to accumulate a > pair containing the running total and count together, then do the > division. This makes me wonder: could there be a compiler optimisation > rule for this, collapsing two iterations over a list into one. I've > never tried writing GHC rules, but something like: > > > f (foldl' g x) (foldl' h x) = (uncurry f) (foldl' (\i (gt,ht) -> (g > i gt, h i ht))) > > The first problem that occurs to me is the number of permutations of > fold and map functions. You'd want a general fusion framework for this, and other accumulators, that's let's you treat 'f' as a zip of some kind that pulls items from its two arguments. And then require only a single rewrite rule for all your loop forms. Stream fusion (see "Lists to Streams to Nothing at All") at least does this for zips, zip (foldl .. ) (foldl .. ) Will end up with a single loop, but for an arbitrary 'f' instead of zip, seems harder. -- Don From lemming at henning-thielemann.de Wed May 14 13:25:13 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed May 14 13:17:27 2008 Subject: [Haskell-cafe] Two-iteration optimisation (was: GHC Predictability) In-Reply-To: <482B1C8C.4060509@cogito.org.uk> References: <482B1C8C.4060509@cogito.org.uk> Message-ID: On Wed, 14 May 2008, Paul Johnson wrote: > We've had a big debate over > >> mean xs = foldl' (+) 0 xs / fromIntegral (length xs) > > For anyone who didn't follow it, the problem is that "mean" needs to traverse > its argument twice, so the entire list has to be held in memory. So if "xs = > [1..1000000000]" then "mean xs" uses all your memory, but "foldl' (+) 0 xs" > and "length xs" by themselves do not. I also wondered how to solve that problem. It also occurs in implementations of "wc", that is counting lines, words and characters of a text in parallel. > The solution is for the programmer to rewrite "mean" to accumulate a pair > containing the running total and count together, then do the division. This > makes me wonder: could there be a compiler optimisation rule for this, > collapsing two iterations over a list into one. I've never tried writing GHC > rules, but something like: > >> f (foldl' g x) (foldl' h x) = (uncurry f) (foldl' (\i (gt,ht) -> (g i gt, h i ht))) The left hand sides of GHC rules must have a definite function as top-level construct, whereas 'f' is a variable. You may define a function which points the optimizer to the places where something shall be replaced. Say fuseFold :: (a -> b -> c) -> a -> b -> c fuseFold f x y = f x y {-# RULES forall f g h x y. fuseFold f (foldl' g x) (foldl' h x) = ... #-} However, instead of writing library functions which use foldl', it might be better to implement and export the accumulating functions separately. They can be used with 'foldl's of arbitrary data structures and they can be fused explicitly without GHC rules. However, I suspect you cannot rewrite say (length (words str)) or (length (lines str)) in that manner in an elegant way. > The first problem that occurs to me is the number of permutations of fold and > map functions. foldl' could be merged with 'map' to a foldl', however the existing fusion frameworks use different primitives, like foldr/build. From oddron at gmail.com Wed May 14 14:06:13 2008 From: oddron at gmail.com (Ronald Guida) Date: Wed May 14 13:59:57 2008 Subject: [Haskell-cafe] Commutative monads vs Applicative functors In-Reply-To: <49a77b7a0805140959v39462883g5950e652f65b5494@mail.gmail.com> References: <62728db30805131806q232cc251g24bf64acadd033af@mail.gmail.com> <49a77b7a0805140959v39462883g5950e652f65b5494@mail.gmail.com> Message-ID: <62728db30805141106l33448dd4t3eaf5455b2aeb03a@mail.gmail.com> David Menendez wrote: > To summarize: some applicative functors are commutative, some > applicative functors are monads, and the ones that are both are > commutative monads. OK, so commutativity is orthogonal to "idiom vs monad". Commutativity depends on whether or not the order of side effects is important. Being a monad or just an idiom depends on whether or not "join" is supported. Examples can be constructed for all 4 possibilities of {idiom, monad} (x) {non-commutative, commutative}. Thank you all for clearing this up for me. From andrewcoppin at btinternet.com Wed May 14 14:23:07 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Wed May 14 14:16:33 2008 Subject: [Haskell-cafe] Re: GHC predictability In-Reply-To: <20080513214749.GG22506@scytale.galois.com> References: <20080513023043.GA3520@scytale.galois.com> <482A00DD.7050701@btinternet.com> <404396ef0805131445l2c2a6a2cu68442ffcc2420f9a@mail.gmail.com> <20080513214749.GG22506@scytale.galois.com> Message-ID: <482B2E0B.2040809@btinternet.com> Don Stewart wrote: > ndmitchell: > >>> 2. Does anybody know how to actually read GHC's Core output anyway? >>> >> There is one different from standard Haskell I am aware of. In Core, >> case x of _ -> 1 will evaluate x, in Haskell it won't. Other than >> that, its just Haskell, but without pattern matching and only cases - >> hence the rather high number of cases. >> > > Well, 'let's too, which bind either unlifted or lifted values. > > If they're binding lifted things, that's a thunk being allocated. > See, somebody needs to write all this down - in language comprehensible to people who don't already know what an "unlifed value" is. ;-) From andrewcoppin at btinternet.com Wed May 14 14:23:11 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Wed May 14 14:16:42 2008 Subject: [Haskell-cafe] Re: GHC predictability In-Reply-To: <404396ef0805131445l2c2a6a2cu68442ffcc2420f9a@mail.gmail.com> References: <20080513023043.GA3520@scytale.galois.com> <482A00DD.7050701@btinternet.com> <404396ef0805131445l2c2a6a2cu68442ffcc2420f9a@mail.gmail.com> Message-ID: <482B2E0F.6060400@btinternet.com> Neil Mitchell wrote: > Hi > > >> 1. What is "ghc-core"? >> > > You actually answer this question as part of question 2. Think of it > as simple Haskell with some additional bits. > I rephrase: I know what GHC's Core language is. But Dons said "I suggest you install ghc-core", which suggests the existence of an item of software named "ghc-core". This I know nothing about... From andrewcoppin at btinternet.com Wed May 14 14:25:47 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Wed May 14 14:19:14 2008 Subject: [Haskell-cafe] GHC predictability In-Reply-To: <70B7AD12-3352-462E-A1EF-CF205E7E5586@ece.cmu.edu> References: <20080509212412.GE24396@scytale.galois.com> <48289421.2070408@btinternet.com> <2608b8a80805121627s480ef1fgc0baa3fb4c5d79e1@mail.gmail.com> <20080513062022.GA19372@scytale.galois.com> <4829FA56.1090903@btinternet.com> <20080513203407.GE22506@scytale.galois.com> <482A01A8.3060801@btinternet.com> <70B7AD12-3352-462E-A1EF-CF205E7E5586@ece.cmu.edu> Message-ID: <482B2EAB.6080701@btinternet.com> Brandon S. Allbery KF8NH wrote: > > On 2008 May 13, at 17:01, Andrew Coppin wrote: > >> That definition of mean is wrong because it traverses the list twice. >> (Curiosity: would traversing it twice in parallel work any better?) >> As for the folds - I always *always* mix up > > It might work "better" but you're still wasting a core that could be > put to better use doing something more sensible. It's pretty much > always best to do all the calculations that require traversing a given > list in a single traversal. Yeah, you're probably right there. I mean, with sufficient inlining, maybe you would end up with a loop that doesn't even construct any heap-allocated list nodes, just adds up the integers as fast as it can generate them. On the other hand, N(N+1)/2N is probably even faster! ;-) So I guess it's kinda of a daft example... From andrewcoppin at btinternet.com Wed May 14 14:26:34 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Wed May 14 14:20:01 2008 Subject: [Haskell-cafe] Endianess In-Reply-To: <3A477F1B-7D7B-4123-B8DC-1C1917FBC961@ece.cmu.edu> References: <20080509212412.GE24396@scytale.galois.com> <48289421.2070408@btinternet.com> <482A042C.6050305@btinternet.com> <3A477F1B-7D7B-4123-B8DC-1C1917FBC961@ece.cmu.edu> Message-ID: <482B2EDA.9030600@btinternet.com> Brandon S. Allbery KF8NH wrote: > > On 2008 May 13, at 17:12, Andrew Coppin wrote: > >> [Oh GOD I hope I didn't just start a Holy War...] > > > Er, I'd say it's already well in progress. :/ > Oh dear. Appologies to everybody who doesn't actually _care_ about which endian mode their computer uses... From dons at galois.com Wed May 14 14:28:00 2008 From: dons at galois.com (Don Stewart) Date: Wed May 14 14:21:48 2008 Subject: [Haskell-cafe] GHC predictability In-Reply-To: <482B2EAB.6080701@btinternet.com> References: <20080509212412.GE24396@scytale.galois.com> <48289421.2070408@btinternet.com> <2608b8a80805121627s480ef1fgc0baa3fb4c5d79e1@mail.gmail.com> <20080513062022.GA19372@scytale.galois.com> <4829FA56.1090903@btinternet.com> <20080513203407.GE22506@scytale.galois.com> <482A01A8.3060801@btinternet.com> <70B7AD12-3352-462E-A1EF-CF205E7E5586@ece.cmu.edu> <482B2EAB.6080701@btinternet.com> Message-ID: <20080514182800.GB10746@scytale.galois.com> andrewcoppin: > Brandon S. Allbery KF8NH wrote: > > > >On 2008 May 13, at 17:01, Andrew Coppin wrote: > > > >>That definition of mean is wrong because it traverses the list twice. > >>(Curiosity: would traversing it twice in parallel work any better?) > >>As for the folds - I always *always* mix up Yes, using parallelism does work. It turns the naive definition into one which traverses the list on two cores at the same time, so the garbage collector does get clean up the list as each core races along it. mean ls = count `par` (total/count) where count = fromIntegral (length ls) total = foldl' (+) 0 ls It is kind of amazing how parallelism and laziness enable the naive definition to fall out as much the same as the explicitly recursive version. -- Don From andrewcoppin at btinternet.com Wed May 14 14:29:02 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Wed May 14 14:22:30 2008 Subject: [Haskell-cafe] Re: GHC predictability In-Reply-To: <5A349526-0595-4542-BAA8-C484580CA734@cs.otago.ac.nz> References: <20080513023043.GA3520@scytale.galois.com> <482A00DD.7050701@btinternet.com> <5A349526-0595-4542-BAA8-C484580CA734@cs.otago.ac.nz> Message-ID: <482B2F6E.10607@btinternet.com> Richard A. O'Keefe wrote: > > On 14 May 2008, at 8:58 am, Andrew Coppin wrote: >> What I'm trying to say [and saying very badly] is that Haskell is an >> almost terrifyingly subtle language. > > Name me a useful programming language that isn't. > Simply interchanging two for-loops, from > for (i = 0; i < N; i++) for (j = 0; j < N; j++) > to for (j = 0; j < N; j++) for (i = 0; i < N; i++) > when marching over an array, can easily slow you down > by nearly two orders of magnitude in C. > [Hint: read "What every computer scientist needs to know > about memory".] OK, well *that* is news... :-o I would suggest that for heap-allocated data that isn't an array, both cases will be equally unperformant. I can't prove that though... > "Unexpectedly slow" is better than "inexplicably buggy". +184 o_O From allbery at ece.cmu.edu Wed May 14 14:30:59 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Wed May 14 14:24:42 2008 Subject: [Haskell-cafe] Re: GHC predictability In-Reply-To: <482B2E0F.6060400@btinternet.com> References: <20080513023043.GA3520@scytale.galois.com> <482A00DD.7050701@btinternet.com> <404396ef0805131445l2c2a6a2cu68442ffcc2420f9a@mail.gmail.com> <482B2E0F.6060400@btinternet.com> Message-ID: On 2008 May 14, at 14:23, Andrew Coppin wrote: > Neil Mitchell wrote: >>> >>> 1. What is "ghc-core"? >> >> You actually answer this question as part of question 2. Think of it >> as simple Haskell with some additional bits. > > I rephrase: I know what GHC's Core language is. But Dons said "I > suggest you install ghc-core", which suggests the existence of an > item of software named "ghc-core". This I know nothing about... Any time someone mentions something that sounds like a Haskell package, http://hackage.haskell.org is your friend. And there I find, in the Development category: > ghc-core program: Display GHC's core and assembly output in a pager IIRC it's just a prettyprinter/colorizer to make it easier to follow and understand GHC Core. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From andrewcoppin at btinternet.com Wed May 14 14:32:02 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Wed May 14 14:25:30 2008 Subject: [Haskell-cafe] Richer (than ascii) notation for haskell source? In-Reply-To: <93BECC602E286B499D5443ECB850D2FF01331E95@newman.usa.aitgroupad.com> References: <93BECC602E286B499D5443ECB850D2FF01331E95@newman.usa.aitgroupad.com> Message-ID: <482B3022.2050303@btinternet.com> Patrick Surry wrote: > > Probably a silly question, but for me one of the nice things about > Haskell is that it's a lot like just writing math(s). But in contrast > to math you lose a lot of notational flexibility being limited to the > ascii character set in your source code. > > It would be nice to be able to use a richer set of symbols in your > source code for operators and functions (e.g. integral, sum, dot and > cross-product, ?), as well as variables (the standard upper and > lower-case greek for example, along with things like super- and > sub-scripting, bold/italic and what-not). You could imagine ending up > with source code that reads just like a mathematical paper. > > Don't know how I'd actually then write/maintain the source-code - some > WYSIWYG editor or effectively writing it in '(la)tex'? Maybe that's > what Knuth is on about with his 'literate programming' weave/tangle > stuff which I don't know much about - does that translate to Haskell? > Personally, I'd just like to be able to get rid of "->", "\" and other such hacks. Would it be possible to amend GHC so that it accepts "->" and [whatever the Unicode codepoint for "left arrow" is] and treats both the same? IIRC, GHC already accepts Unicode input. I seem to recall some people debating what to do about languages that don't have a concept of "uppercase" and "lowercase" - the Haskell language critically hinges on that distinction. But then, if you wanted to write your Haskell programs in arabic or something, I would think the fact that all the language keywords and every library ever written are in English, so... From westondan at imageworks.com Wed May 14 14:34:51 2008 From: westondan at imageworks.com (Dan Weston) Date: Wed May 14 14:29:49 2008 Subject: [Haskell-cafe] Re: Endianess In-Reply-To: References: <20080509212412.GE24396@scytale.galois.com> <48289421.2070408@btinternet.com> <87ve1ixcrh.fsf@nmd9999.imr.no> <20080513191102.GA11402@brakk.ethz Message-ID: <482B30CB.7080607@imageworks.com> Henning Thielemann wrote: > > On Tue, 13 May 2008, Achim Schneider wrote: > >> Jed Brown wrote: >> >>> It's not that simple with bits. They lack consistency just like the >>> usual US date format and the way Germans read numbers. >>> >> So you claim that you pronounce 14 tenty-four? In German pronunciation >> is completely uniform from 13 to 99. > > http://www.verein-zwanzigeins.de/ So I've always wondered, if you are writing down a number being dictated (slowly) by someone else, like 234, do you write the 2, then leave space and write the 4, then go back and fill in with 3? Or do you push the 4 onto the stack until the 3 arrives, and write 34 at once. If the latter, does this imply that Germans have a harder time with tail recursion? From andrewcoppin at btinternet.com Wed May 14 14:38:09 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Wed May 14 14:31:41 2008 Subject: [Haskell-cafe] Two-iteration optimisation In-Reply-To: <20080514172045.GA10746@scytale.galois.com> References: <482B1C8C.4060509@cogito.org.uk> <20080514172045.GA10746@scytale.galois.com> Message-ID: <482B3191.7080204@btinternet.com> Don Stewart wrote: > You'd want a general fusion framework for this, and other accumulators, > that's let's you treat 'f' as a zip of some kind that pulls items from > its two arguments. And then require only a single rewrite rule for all > your loop forms. > > Stream fusion (see "Lists to Streams to Nothing at All") at least does this for zips, > > zip (foldl .. ) > (foldl .. ) > > Will end up with a single loop, but for an arbitrary 'f' instead of zip, > seems harder. > It seems the thing to do would be to expose a top-level function for explicitly specifying that this is what you want to do: foo :: (x' -> y' -> z') -> ([x] -> x') -> ([y] -> y') -> [x] -> [y] -> z' You could then say mean xs = foo (/) sum length which is pretty declarative, and gives the compiler an easy time with optimising. Of course, if nobody chooses to *use* this function... it won't help you any. From allbery at ece.cmu.edu Wed May 14 14:40:09 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Wed May 14 14:33:52 2008 Subject: [Haskell-cafe] Richer (than ascii) notation for haskell source? In-Reply-To: <482B3022.2050303@btinternet.com> References: <93BECC602E286B499D5443ECB850D2FF01331E95@newman.usa.aitgroupad.com> <482B3022.2050303@btinternet.com> Message-ID: <4FD84C61-C940-4B29-A207-D23F8B72D00F@ece.cmu.edu> On 2008 May 14, at 14:32, Andrew Coppin wrote: > Personally, I'd just like to be able to get rid of "->", "\" and > other such hacks. Would it be possible to amend GHC so that it > accepts "->" and [whatever the Unicode codepoint for "left arrow" > is] and treats both the same? Both of those are already there, along with some others. It's been discussed here but I can't find it in the 6.8.2 manual.... (boo, hiss) -XUnicodeSyntax -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From allbery at ece.cmu.edu Wed May 14 14:43:37 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Wed May 14 14:37:19 2008 Subject: [Haskell-cafe] Re: Endianess In-Reply-To: <482B30CB.7080607@imageworks.com> References: <20080509212412.GE24396@scytale.galois.com> <48289421.2070408@btinternet.com> <87ve1ixcrh.fsf@nmd9999.imr.no> <20080513191102.GA11402@brakk.ethz <482B30CB.7080607@imageworks.com> Message-ID: <266370AF-E498-42DF-A356-2572A0DDAE70@ece.cmu.edu> On 2008 May 14, at 14:34, Dan Weston wrote: > So I've always wondered, if you are writing down a number being > dictated (slowly) by someone else, like 234, do you write the 2, > then leave space and write the 4, then go back and fill in with 3? > Or do you push the 4 onto the stack until the 3 arrives, and write > 34 at once. > > If the latter, does this imply that Germans have a harder time with > tail recursion? Stacking, surely: recall the joke about the German professor who saved all his verbs for the end of the lecture. :) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From trebla at vex.net Wed May 14 14:47:16 2008 From: trebla at vex.net (Albert Y. C. Lai) Date: Wed May 14 14:41:01 2008 Subject: [Haskell-cafe] Two-iteration optimisation (was: GHC Predictability) In-Reply-To: <482B1C8C.4060509@cogito.org.uk> References: <482B1C8C.4060509@cogito.org.uk> Message-ID: <482B33B4.1060902@vex.net> Paul Johnson wrote: > The solution is for the programmer to rewrite "mean" to accumulate a > pair containing the running total and count together, then do the > division. This makes me wonder: could there be a compiler optimisation > rule for this, collapsing two iterations over a list into one. Do not forget: http://www.haskell.org/tmrwiki/WhyAttributeGrammarsMatter Though not a compiler optimisation, it's a thinker optimisation. I have another thought. It is now time to investigate the viability of mean x = s `par` l `par` (s/l) where s = sum x l = length x If you worry that the sum thread and the length thread are not synchronized and therefore there is still no bound on the list prefix kept in memory, I'm sure you can improve it by one of the chunking strategies. As our hardware grows more cores but not more gigahertz, it may become detrimal to fuse. Fusion implies entangling, an anti-thesis to parallelism. One day we may call this an optimisation: unfuse code hand-fused by programmers, then parallelize. Optimisation people on the imperative side are already doing this (they have more hand-fused code than we do), though targetting at older hardware like vector machines and SIMD, not yet multiple cores. From andrewcoppin at btinternet.com Wed May 14 14:50:22 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Wed May 14 14:43:53 2008 Subject: [Haskell-cafe] Richer (than ascii) notation for haskell source? In-Reply-To: References: <93BECC602E286B499D5443ECB850D2FF01331E95@newman.usa.aitgroupad.com> <482B3022.2050303@btinternet.com> Message-ID: <482B346E.4060604@btinternet.com> Reinier Lamers wrote: > > Op 14-mei-2008, om 20:32 heeft Andrew Coppin het volgende geschreven: >> Personally, I'd just like to be able to get rid of "->", "\" and >> other such hacks. Would it be possible to amend GHC so that it >> accepts "->" and [whatever the Unicode codepoint for "left arrow" is] >> and treats both the same? > I believe GHC already accepts "?" instead of "forall", and some other > Unicode neatness. However, you can't use "?" for "\" because "?" is a > lowercase letter and thus valid in identifiers. So getting rid of "\" > might be impossible even with Unicode. Ooo... well spotted on that subtly edge case with lambda... Damn, that's just too bad. Using a backslash makes it look like a character escape or something. It's really quite ugly... From andrewcoppin at btinternet.com Wed May 14 14:53:58 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Wed May 14 14:47:26 2008 Subject: [Haskell-cafe] Two-iteration optimisation (was: GHC Predictability) In-Reply-To: <482B33B4.1060902@vex.net> References: <482B1C8C.4060509@cogito.org.uk> <482B33B4.1060902@vex.net> Message-ID: <482B3546.3020802@btinternet.com> Albert Y. C. Lai wrote: > If you worry that the sum thread and the length thread are not > synchronized and therefore there is still no bound on the list prefix > kept in memory, I'm sure you can improve it by one of the chunking > strategies. I'm more worried that data now has to go through tiny CPU <--> RAM busses rather than zipping along at the CPU's core frequency as it would if only 1 CPU were involved. I would think the cache issues make the sequential version a fair bit faster. (Not to mention that no GC is required.) > As our hardware grows more cores but not more gigahertz, it may become > detrimal to fuse. Fusion implies entangling, an anti-thesis to > parallelism. One day we may call this an optimisation: unfuse code > hand-fused by programmers, then parallelize. Optimisation people on > the imperative side are already doing this (they have more hand-fused > code than we do), though targetting at older hardware like vector > machines and SIMD, not yet multiple cores. The key to parallel processing is splitting a task into *independent* tasks so you can do them in parallel. If they're still interdependent [like the above], I suspect you're not gaining much. From lemming at henning-thielemann.de Wed May 14 14:56:37 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed May 14 14:48:52 2008 Subject: [Haskell-cafe] Re: Endianess In-Reply-To: <482B30CB.7080607@imageworks.com> References: <20080509212412.GE24396@scytale.galois.com> <48289421.2070408@btinternet.com> <87ve1ixcrh.fsf@nmd9999.imr.no> Message-ID: On Wed, 14 May 2008, Dan Weston wrote: > Henning Thielemann wrote: >> >> http://www.verein-zwanzigeins.de/ > > So I've always wondered, if you are writing down a number being dictated > (slowly) by someone else, like 234, do you write the 2, then leave space and > write the 4, then go back and fill in with 3? Or do you push the 4 onto the > stack until the 3 arrives, and write 34 at once. Of course, we write down 243, realize the mistake and rewrite the number. :-) Actually, many pupils have problems with the mixed order of digits and give solutions like this one in examinations: 8 * 8 = 46 because they write the digits as they speak them. That's one of the reasons the mentioned assocation was founded for. From lemming at henning-thielemann.de Wed May 14 14:59:00 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed May 14 14:51:14 2008 Subject: [Haskell-cafe] Re: Endianess In-Reply-To: <266370AF-E498-42DF-A356-2572A0DDAE70@ece.cmu.edu> References: <20080509212412.GE24396@scytale.galois.com> <48289421.2070408@btinternet.com> <87ve1ixcrh.fsf@nmd9999.imr.no> <266370AF-E498-42DF-A356-2572A0DDAE70@ece.cmu.edu> Message-ID: On Wed, 14 May 2008, Brandon S. Allbery KF8NH wrote: > > On 2008 May 14, at 14:34, Dan Weston wrote: > >> So I've always wondered, if you are writing down a number being dictated >> (slowly) by someone else, like 234, do you write the 2, then leave space >> and write the 4, then go back and fill in with 3? Or do you push the 4 onto >> the stack until the 3 arrives, and write 34 at once. >> >> If the latter, does this imply that Germans have a harder time with tail >> recursion? > > > Stacking, surely: recall the joke about the German professor who saved all > his verbs for the end of the lecture. :) Interesting to know what jokes are told about Germans. 8-] So, do English professors save their prepositions for the end of a lecture? From andrewcoppin at btinternet.com Wed May 14 15:00:59 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Wed May 14 14:54:25 2008 Subject: [Haskell-cafe] Richer (than ascii) notation for haskell source? In-Reply-To: <4FD84C61-C940-4B29-A207-D23F8B72D00F@ece.cmu.edu> References: <93BECC602E286B499D5443ECB850D2FF01331E95@newman.usa.aitgroupad.com> <482B3022.2050303@btinternet.com> <4FD84C61-C940-4B29-A207-D23F8B72D00F@ece.cmu.edu> Message-ID: <482B36EB.6000708@btinternet.com> Brandon S. Allbery KF8NH wrote: > > On 2008 May 14, at 14:32, Andrew Coppin wrote: > >> Personally, I'd just like to be able to get rid of "->", "\" and >> other such hacks. Would it be possible to amend GHC so that it >> accepts "->" and [whatever the Unicode codepoint for "left arrow" is] >> and treats both the same? > > > Both of those are already there, along with some others. It's been > discussed here but I can't find it in the 6.8.2 manual.... (boo, > hiss) -XUnicodeSyntax Mmm, I can see I'm going to have to test this... [That is, just as soon as I figure out how to even type in obscure Unicode symbols...] From lemming at henning-thielemann.de Wed May 14 15:03:36 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed May 14 14:55:50 2008 Subject: [Haskell-cafe] Richer (than ascii) notation for haskell source? In-Reply-To: <482B3022.2050303@btinternet.com> References: <93BECC602E286B499D5443ECB850D2FF01331E95@newman.usa.aitgroupad.com> <482B3022.2050303@btinternet.com> Message-ID: On Wed, 14 May 2008, Andrew Coppin wrote: > Personally, I'd just like to be able to get rid of "->", "\" and other such > hacks. Would it be possible to amend GHC so that it accepts "->" and > [whatever the Unicode codepoint for "left arrow" is] and treats both the > same? As said, the IDE Leksah can display code exactly like this ... From andrewcoppin at btinternet.com Wed May 14 15:03:42 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Wed May 14 14:57:09 2008 Subject: [Haskell-cafe] Short circuiting and the Maybe monad In-Reply-To: <482A7AF0.6020008@tcs.inf.tu-dresden.de> References: <65113aef0805121509s6b4e76bbxd23e86070a2a0be3@mail.gmail.com> <482A7AF0.6020008@tcs.inf.tu-dresden.de> Message-ID: <482B378E.802@btinternet.com> Janis Voigtlaender wrote: > http://wwwtcs.inf.tu-dresden.de/~voigt/mpc08.pdf "It is well-known that trees with substitution form a monad." ...OK, I just learned something new. Hanging around Haskell Cafe can be so illuminating! :-) Now, if only I could actually comprehend the rest of the paper... o_O From andrewcoppin at btinternet.com Wed May 14 15:09:48 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Wed May 14 15:03:19 2008 Subject: [Haskell-cafe] Richer (than ascii) notation for haskell source? In-Reply-To: References: <93BECC602E286B499D5443ECB850D2FF01331E95@newman.usa.aitgroupad.com> <482B3022.2050303@btinternet.com> Message-ID: <482B38FC.2000705@btinternet.com> Henning Thielemann wrote: > > On Wed, 14 May 2008, Andrew Coppin wrote: > >> Personally, I'd just like to be able to get rid of "->", "\" and >> other such hacks. Would it be possible to amend GHC so that it >> accepts "->" and [whatever the Unicode codepoint for "left arrow" is] >> and treats both the same? > > As said, the IDE Leksah can display code exactly like this ... > I noticed the first time. Clearly this is another toy I'm going to have to try out sometime... From mads_lindstroem at yahoo.dk Wed May 14 15:13:35 2008 From: mads_lindstroem at yahoo.dk (Mads =?ISO-8859-1?Q?Lindstr=F8m?=) Date: Wed May 14 15:10:51 2008 Subject: [Haskell-cafe] Using Template Haskell to make type-safe database access In-Reply-To: References: <1209760319.4242.4.camel@localhost.localdomain> <1210017744.4300.30.camel@localhost.localdomain> <6A286E8D-2C96-4E77-9FA3-077702204CBE@Cs.Nott.AC.UK> <1210195445.4192.54.camel@localhost.localdomain> <0C39F272-5FC0-48A7-8831-1F2BF03F4989@Cs.Nott.AC.UK> <1210260745.4265.29.camel@localhost.localdomain> Message-ID: <1210792415.4227.7.camel@localhost.localdomain> Hi Bjorn Bringert wrote: > Mads: Preparing the statement and asking the DB about the type at > compile is a great idea! I've never thought of that. Please consider > completing this and packaging it as a library. Thanks for the nice remark. And I will begin completing the idea, as soon I have packaged up and wrote a little tutorial about my other project (SybWidget). I already started that about three weeks ago, so it should be finished soon. Greetings, Mads Lindstr?m From allbery at ece.cmu.edu Wed May 14 15:19:23 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Wed May 14 15:14:17 2008 Subject: [Haskell-cafe] Richer (than ascii) notation for haskell source? In-Reply-To: <482B36EB.6000708@btinternet.com> References: <93BECC602E286B499D5443ECB850D2FF01331E95@newman.usa.aitgroupad.com> <482B3022.2050303@btinternet.com> <4FD84C61-C940-4B29-A207-D23F8B72D00F@ece.cmu.edu> <482B36EB.6000708@btinternet.com> Message-ID: On 2008 May 14, at 15:00, Andrew Coppin wrote: > Brandon S. Allbery KF8NH wrote: >> >> On 2008 May 14, at 14:32, Andrew Coppin wrote: >> >>> Personally, I'd just like to be able to get rid of "->", "\" and >>> other such hacks. Would it be possible to amend GHC so that it >>> accepts "->" and [whatever the Unicode codepoint for "left arrow" >>> is] and treats both the same? >> >> Both of those are already there, along with some others. It's been >> discussed here but I can't find it in the 6.8.2 manual.... (boo, >> hiss) -XUnicodeSyntax > > > Mmm, I can see I'm going to have to test this... [That is, just as > soon as I figure out how to even type in obscure Unicode symbols...] Unfortunately, while I thought there was a distinct lambda sign that wasn't the lowercase Greek letter, there isn't. (That said, I don't see why it couldn't be a keyword. You'd need a space after it.) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From andrewcoppin at btinternet.com Wed May 14 15:37:53 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Wed May 14 15:31:29 2008 Subject: [Haskell-cafe] Fun with Darcs In-Reply-To: <482B38FC.2000705@btinternet.com> References: <93BECC602E286B499D5443ECB850D2FF01331E95@newman.usa.aitgroupad.com> <482B3022.2050303@btinternet.com> <482B38FC.2000705@btinternet.com> Message-ID: <482B3F91.7050602@btinternet.com> Andrew Coppin wrote: > Henning Thielemann wrote: >> >> As said, the IDE Leksah can display code exactly like this ... >> > > I noticed the first time. Clearly this is another toy I'm going to > have to try out sometime... ...and then he discovers that Darcs isn't working any more. :-( I've recently reinstalled Windows, so I decided to go download the latest Darcs and set that up. Now it's complaining that I don't have curl or wget. (Never used to do that before.) The WindowsConfiguration file doesn't mention anything about it. [And the link back to the Darcs wiki is 404 by the way. "darcs.net" rather than "wiki.darcs.net". Nice touch...] Presumably this change is new in Darcs 2. I don't recall seeing anything about it when I read the announcement, and I'm now searching the wiki and I still don't see anything about it. Presumably I just need to discover a Windows binary for wget and put it in my search path somewhere? Would be nice if this were documented... Darcs used to just work by itself without any additional tools. From allbery at ece.cmu.edu Wed May 14 15:38:58 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Wed May 14 15:33:38 2008 Subject: [Haskell-cafe] Richer (than ascii) notation for haskell source? In-Reply-To: <482B36EB.6000708@btinternet.com> References: <93BECC602E286B499D5443ECB850D2FF01331E95@newman.usa.aitgroupad.com> <482B3022.2050303@btinternet.com> <4FD84C61-C940-4B29-A207-D23F8B72D00F@ece.cmu.edu> <482B36EB.6000708@btinternet.com> Message-ID: <2E09DF0F-AB8C-40DE-928D-1FA37FF7FE63@ece.cmu.edu> On 2008 May 14, at 15:00, Andrew Coppin wrote: > Brandon S. Allbery KF8NH wrote: >> >> On 2008 May 14, at 14:32, Andrew Coppin wrote: >>> Personally, I'd just like to be able to get rid of "->", "\" and >>> other such hacks. Would it be possible to amend GHC so that it >>> accepts "->" and [whatever the Unicode codepoint for "left arrow" >>> is] and treats both the same? >> >> Both of those are already there, along with some others. It's been >> discussed here but I can't find it in the 6.8.2 manual.... (boo, >> hiss) -XUnicodeSyntax > > Mmm, I can see I'm going to have to test this... [That is, just as > soon as I figure out how to even type in obscure Unicode symbols...] And, for future reference: > #if __GLASGOW_HASKELL__ >= 605 > ,("?\x88?", ITdcolon, unicodeSyntaxEnabled) > ,("?\x87\x92", ITdarrow, unicodeSyntaxEnabled) > ,("?\x88\x80", ITforall, \i -> unicodeSyntaxEnabled i && > explicitForallEnabled i) > ,("?\x86\x92", ITrarrow, unicodeSyntaxEnabled) > ,("?\x86\x90", ITlarrow, unicodeSyntaxEnabled) > ,("?\x8b?", ITdotdot, unicodeSyntaxEnabled) > -- ToDo: ideally, ?\x86\x92 and ?\x88? should be "specials", > so that the > y cannot > -- form part of a large operator. This would let us have a > better > -- syntax for kinds: ?\x91?\x88?*?\x86\x92* would be a legal > kind signat > ure. (maybe). > #endif So ?, ?, ?, ?, ?, ? currently supported. Others clearly could be, but probably not as built-in syntax (Prelude.Unicode: let ? = *, anyone?). -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From dpiponi at gmail.com Wed May 14 15:42:25 2008 From: dpiponi at gmail.com (Dan Piponi) Date: Wed May 14 15:36:20 2008 Subject: [Haskell-cafe] Short circuiting and the Maybe monad In-Reply-To: <482B378E.802@btinternet.com> References: <65113aef0805121509s6b4e76bbxd23e86070a2a0be3@mail.gmail.com> <482A7AF0.6020008@tcs.inf.tu-dresden.de> <482B378E.802@btinternet.com> Message-ID: <625b74080805141242odf4122o2ddaf4c0ec9d60ea@mail.gmail.com> On Wed, May 14, 2008 at 12:03 PM, Andrew Coppin wrote: > "It is well-known that trees with substitution form a monad." Now that's funny. Compare with the first line of this paper: http://citeseer.ist.psu.edu/510658.html Anyway, I worked through an elementary example of this with usable source code here: http://sigfpe.blogspot.com/2006/11/variable-substitution-gives.html -- Dan From droundy at darcs.net Wed May 14 16:13:47 2008 From: droundy at darcs.net (David Roundy) Date: Wed May 14 16:07:29 2008 Subject: [Haskell-cafe] Fun with Darcs In-Reply-To: <482B3F91.7050602@btinternet.com> References: <93BECC602E286B499D5443ECB850D2FF01331E95@newman.usa.aitgroupad.com> <482B3022.2050303@btinternet.com> <482B38FC.2000705@btinternet.com> <482B3F91.7050602@btinternet.com> Message-ID: <20080514201346.GP8845@darcs.net> On Wed, May 14, 2008 at 08:37:53PM +0100, Andrew Coppin wrote: > Andrew Coppin wrote: > >Henning Thielemann wrote: > >> > >>As said, the IDE Leksah can display code exactly like this ... > >> > > > >I noticed the first time. Clearly this is another toy I'm going to > >have to try out sometime... > > ...and then he discovers that Darcs isn't working any more. :-( > > I've recently reinstalled Windows, so I decided to go download the > latest Darcs and set that up. Now it's complaining that I don't have > curl or wget. (Never used to do that before.) The WindowsConfiguration > file doesn't mention anything about it. [And the link back to the Darcs > wiki is 404 by the way. "darcs.net" rather than "wiki.darcs.net". Nice > touch...] Presumably this change is new in Darcs 2. I don't recall > seeing anything about it when I read the announcement, and I'm now > searching the wiki and I still don't see anything about it. > > Presumably I just need to discover a Windows binary for wget and put it > in my search path somewhere? Would be nice if this were documented... > Darcs used to just work by itself without any additional tools. It's just that the guy who built the windows binary didn't have libcurl installed. Since there don't seem to be many windows developers, we have to live with those few people willing to compile darcs on windows... David From andrewcoppin at btinternet.com Wed May 14 16:49:32 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Wed May 14 16:42:59 2008 Subject: [Haskell-cafe] Fun with Darcs In-Reply-To: <20080514201346.GP8845@darcs.net> References: <93BECC602E286B499D5443ECB850D2FF01331E95@newman.usa.aitgroupad.com> <482B3022.2050303@btinternet.com> <482B38FC.2000705@btinternet.com> <482B3F91.7050602@btinternet.com> <20080514201346.GP8845@darcs.net> Message-ID: <482B505C.3020300@btinternet.com> David Roundy wrote: > On Wed, May 14, 2008 at 08:37:53PM +0100, Andrew Coppin wrote: > >> Andrew Coppin wrote: >> >> I've recently reinstalled Windows, so I decided to go download the >> latest Darcs and set that up. Now it's complaining that I don't have >> curl or wget. (Never used to do that before.) The WindowsConfiguration >> file doesn't mention anything about it. [And the link back to the Darcs >> wiki is 404 by the way. "darcs.net" rather than "wiki.darcs.net". Nice >> touch...] Presumably this change is new in Darcs 2. I don't recall >> seeing anything about it when I read the announcement, and I'm now >> searching the wiki and I still don't see anything about it. >> >> Presumably I just need to discover a Windows binary for wget and put it >> in my search path somewhere? Would be nice if this were documented... >> Darcs used to just work by itself without any additional tools. >> > > It's just that the guy who built the windows binary didn't have libcurl > installed. Since there don't seem to be many windows developers, we have > to live with those few people willing to compile darcs on windows... > Well, it seems that simply adding wget.exe to my search path did in fact fix the issue. It hasn't hard to find with Google, but a small note to that effect somewhere in the documentation would be quite nice. Seriously, you have literally *no idea* how much trouble I've just had trying to achieve the simple task of getting Leksah to work. Every imaginable thing has gone wrong. Each impediment is fairly trivial in itself, but the sheer volume of them is... straining my patience! - Darcs now needs wget in order to work. [Easy to fix once you work out how.] - Leksah needs Gtk2hs, but I have GHC 6.8.2. [Thank the Maker for gname - I've have never found the URL for the unofficial Gtk2hs build to fix this!] - Leksah needs something called "binary". [Once you figure out that that's a package and you're supposed to get it from Hackage, it's quite easy to find. Figuring out what to do with a tarball on Windows isn't that amusing. However, for once, Cabal did actually build and install it without issue.] - When I try to install Leksah, it complains that a PNG file doesn't exist. [My guess is the author's Darcs repo contains it, but they forgot to tell Darcs.] So I _manually edit_ the Cabal file. [Eeek!] Obviously Cabal now makes me reconfigure and rebuild, but the program now installs just fine. - Gee, now I wonder *where* exactly Cabal installed it? Oh well, it seems to have put the binary in my search path anyway - that's a nice touch. Now, let's see what this IDE actually looks li-- oh you have GOT to be KIDDING me! It can't find the right GTK DLL?!? By now, I've been trying to "try out Leksah" for about an hour. As you can see, each problem is pretty small [although the "manually edit Cabal file" bit was scary]. However, add together enough small problems and you end up with a very frustrating experience. When it takes you 10 minutes or so to fix each problem, 6 small problems = 1 hour of your life. It adds up rather fast. :-( At this point, my best guess is that the unofficial Gtk2hs binary is broken somehow. [Although I don't recall hearing anybody yelling about it...] Maybe tomorrow I'll try again on my other box that has an older GHC on it and see how that goes. For tonight, I'm just too frustrated to continue. [I hope nobody takes my frustration *too* seriously. I'm just a little bit exasperated right now. I'll get over it. By tomorrow, this will probably seem very amusing... but right now it's quite late, and I'm sleepy.] From bulat.ziganshin at gmail.com Wed May 14 17:01:14 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed May 14 16:55:11 2008 Subject: [Haskell-cafe] Fun with Darcs In-Reply-To: <482B505C.3020300@btinternet.com> References: <93BECC602E286B499D5443ECB850D2FF01331E95@newman.usa.aitgroupad.com> <482B3022.2050303@btinternet.com> <482B38FC.2000705@btinternet.com> <482B3F91.7050602@btinternet.com> <20080514201346.GP8845@darcs.net> <482B505C.3020300@btinternet.com> Message-ID: <259058831.20080515010114@gmail.com> Hello Andrew, Thursday, May 15, 2008, 12:49:32 AM, you wrote: > touch. Now, let's see what this IDE actually looks li-- oh you have GOT > to be KIDDING me! It can't find the right GTK DLL?!? gtk2hs includes *developer* gtk2 environment. while it should work fine (as far as it's in your path), you may try to install *runtime* gtk2 environment from http://sourceforge.net/project/showfiles.php?group_id=71914&package_id=255391 -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From barsoap at web.de Wed May 14 17:06:03 2008 From: barsoap at web.de (Achim Schneider) Date: Wed May 14 16:59:56 2008 Subject: [Haskell-cafe] Re: Endianess References: <20080509212412.GE24396@scytale.galois.com> <48289421.2070408@btinternet.com> <87ve1ixcrh.fsf@nmd9999.imr.no> Message-ID: <20080514230603.2b3b244a@solaris> Henning Thielemann wrote: > Of course, we write down 243, realize the mistake and rewrite the > number. :-) Actually, many pupils have problems with the mixed order > of digits and give solutions like this one in examinations: > 8 * 8 = 46 > because they write the digits as they speak them. That's one of the > reasons the mentioned assocation was founded for. > Funny enough you never hear stories about pupils writing 7 + 7 = 41 -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. From claus.reinke at talk21.com Wed May 14 17:13:57 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Wed May 14 17:07:44 2008 Subject: [Haskell-cafe] Re: Endianess References: <20080509212412.GE24396@scytale.galois.com> <48289421.2070408@btinternet.com> <87ve1ixcrh.fsf@nmd9999.imr.no> <20080513191102.GA11402@brakk.ethz <482B30CB.7080607@imageworks.com> Message-ID: <023a01c8b607$6dba95b0$b0178351@cr3lt> >>>> It's not that simple with bits. They lack consistency just like the >>>> usual US date format and the way Germans read numbers. >>>> >>> So you claim that you pronounce 14 tenty-four? In German pronunciation >>> is completely uniform from 13 to 99. >> >> http://www.verein-zwanzigeins.de/ > > So I've always wondered, if you are writing down a number being dictated > (slowly) by someone else, like 234, do you write the 2, then leave space > and write the 4, then go back and fill in with 3? Or do you push the 4 > onto the stack until the 3 arrives, and write 34 at once. Germans have no problems with sentences which though started at the beginning when observed closely and in the light of day (none of which adds anything to the content of the sentence in which the very parenthetical remark you -dear reader- are reading at this very moment while wondering whether the writer -dear me- is ever going to reach his point -if, in fact, there is a point (of which one cannot always be entirely sure until one has stored and processed the whole construct from beginning to end and thought it over carefully at least once more because who knows, sense appears here and there, now and then, to this one and that one, and how are you, Mr. Wilson? > If the latter, does this imply that Germans have a harder time with tail > recursion? you mean as in returning from a different context than the one we decended into? we'd never do such a thing, honestly!-) then again, Jane Austen was happy enough writing about her characters not being "one and twenty", so perhaps that is just a lost art?-) claus From gsan at stillpsycho.net Wed May 14 17:23:39 2008 From: gsan at stillpsycho.net (=?utf-8?q?G=C3=B6khan_San?=) Date: Wed May 14 17:17:39 2008 Subject: [Haskell-cafe] Data.Dynamic over the wire In-Reply-To: <4829D240.60504@jellybean.co.uk> References: <4829D240.60504@jellybean.co.uk> Message-ID: <200805142323.42187.gsan@stillpsycho.net> Hi, > {-# LANGUAGE ExistentialQuantification, ScopedTypeVariables #-} Following the related discussion on #haskell, I ended up writing the below code (thanks to the suggestions). This is for a genetic programming library, but the usage would be similar. It also (de)serializes TypeRep. I'm a haskell newbie, so feel free to report any awkwardness. :-) > module Main (main) where > import Data.Typeable Dyn holds either the data or the serialized version of it. This is for performance reasons. Local functions will return 'D x' values, deserializing any 'S t s' they encounter in the process. When Dyn is shown and read (transmitted?), it becomes a string again. Function names can be stored in the string version, and a lookup table could be used to map to actual functions. > data Dyn = forall a. (Typeable a, Show a) => D a | S TypeRep String > dynTypeRep :: Dyn -> TypeRep > dynTypeRep (D x) = typeOf x > dynTypeRep (S t _) = t > fromDyn :: forall a. (Typeable a, Read a) => Dyn -> Maybe a > fromDyn (D x) = cast x > fromDyn (S t s) = if typeOf (undefined :: a) == t > then Just (read s) > else Nothing The above version would be more useful, but 'S t s' can't be cast into a type other than the one represented by t. (We don't need this anyway.) > fromDyn' :: (Typeable a, Read a) => Dyn -> a > fromDyn' (D x) = case xa of Nothing -> error "Typecast failed!" > Just a -> a > where xa = cast x > fromDyn' (S t s) = read s Rep is the intermediate type used while (de)serializing Typeable. I couldn't think of a way for reading TypeRep with the current implementation of show. > newtype Rep = R (String, [Rep]) deriving (Read, Show) > toRep :: TypeRep -> Rep > toRep t = R (show con, map toRep args) > where (con, args) = splitTyConApp t > fromRep :: Rep -> TypeRep > fromRep (R (con, args)) = mkTyConApp (mkTyCon con) $ map fromRep args > instance Show Dyn where > show (D x) = show (toRep (typeOf x), show x) > show (S t s) = show (toRep t, s) > instance Read Dyn where > readsPrec d = (map toS) . rP > where toS ((rep, str), s') = (S (fromRep rep) str, s') > rP = (readsPrec d) :: ReadS (Rep, String) Below are some examples. I'm looking for a practical way to define functions that work over several types more easily. The functionality should be like type classes for runtime. > add5 :: Dyn -> Dyn > add5 dx | dynTypeRep dx == typeOf (undefined :: Int) = > D (fromDyn' dx + 5 :: Int) > | dynTypeRep dx == typeOf (undefined :: Double) = > D (fromDyn' dx + 5 :: Double) > main :: IO () > main = do > let dd = D ([(1 :: Int, "test")]) > ds = (read $ show dd) :: Dyn > di = D (2 :: Int) > df = D (2 :: Double) > daf = add5 df > dai = add5 di > print dd > print ds -- Should be identical > print (daf, dynTypeRep daf) -- 7.0 > print (dai, dynTypeRep dai) -- 7 On Tuesday May 13 2008, Jules Bean wrote: > You can't finish it off because you can't derive a 'Read' instance for > SD, because there is no read instance for TypeRep. Off-hand I can't -- Gokhan San gsan@stillpsycho.net http://www.stillpsycho.net ... Real programs don't eat cache. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080514/3a7133b4/attachment.bin From olivier.boudry at gmail.com Wed May 14 17:26:28 2008 From: olivier.boudry at gmail.com (Olivier Boudry) Date: Wed May 14 17:20:09 2008 Subject: [Haskell-cafe] FFI: newbie linking problem Message-ID: Hi all, I'm trying to call the following C function. RFC_RC _stdcall RfcUTF8ToSAPUC(const RFC_BYTE *utf8, unsigned utf8Length, SAP_UC *sapuc, unsigned *sapucSize, unsigned *resultLength, RFC_ERROR_INFO *info) I wrote a foreign import for this function: foreign import ccall unsafe "sapnwrfc.h RfcUTF8ToSAPUC" f_RfcUTF8ToSAPUC :: RfcBytePtr -> CUInt -> SapUCPtr -> Ptr CUInt -> Ptr CUInt -> RfcErrorInfoPtr -> IO RfcRetCodeType But when compiling I keep getting this error: C:\Temp\Haskell\HSAP>ghc --make -LC:/Temp/nwrfcsdk/lib -lsapnwrfc SAP/Types.hs Test.hs [1 of 2] Compiling SAP.Types ( SAP/Types.hs, SAP/Types.o ) Linking Test.exe ... SAP/Types.o(.text+0x91c):fake: undefined reference to `RfcUTF8ToSAPUC@24' collect2: ld returned 1 exit status I ran nm.exe on the sapnwrfc.lib to see the exports and got this list: SAPNWRFC.dll: 00000000 I .idata$4 00000000 I .idata$5 00000000 I .idata$6 00000000 T .text 00000000 T _RfcUTF8ToSAPUC@24 U __IMPORT_DESCRIPTOR_SAPNWRFC 00000000 I __imp__RfcUTF8ToSAPUC@24 It looks like RfcUTF8ToSAPUC@24 exists. I tried prepending a _ but it doesn't change anything. GHC tries to link directly to the .dll file and not to the .lib file. Is this a problem? Should I convert the .lib to a .a and link the .a? Is there a way to list the exports directly from the dll file? Thanks, Olivier. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080514/3e134f47/attachment.htm From stefan at cs.uu.nl Wed May 14 17:43:56 2008 From: stefan at cs.uu.nl (Stefan Holdermans) Date: Wed May 14 17:37:39 2008 Subject: [Haskell-cafe] Copy on read In-Reply-To: <625b74080805121810j128b9ad1vfad1dbe4a439639b@mail.gmail.com> References: <4825984A.4010905@btinternet.com> <404396ef0805100720vff904c1lac6a5fad44d5cf06@mail.gmail.com> <625b74080805121810j128b9ad1vfad1dbe4a439639b@mail.gmail.com> Message-ID: <341B4AFB-56BD-4D50-844D-47B65EB9313D@cs.uu.nl> Dan, Let me first apologize for this late reply. Neil pointed you to >> Jurriaan Hage and Stefan Holdermans. Heap recycling for lazy >> languages. In John Hatcliff, Robert Gl?ck, and Oege de Moor, editors, >> _Proceedings of the 2008 ACM SIGPLAN Symposium on Partial Evaluation >> and Semantics-Based Program Manipulation_, PEPM'08, San Francisco, >> California, USA, January 7--8, 2008, pages 189--197. ACM Press, 2008. >> http://doi.acm.org/10.1145/1328408.1328436. and you commented: > If I'm reading it aright, it works by tagging the types of values as > unique or not but keeps that annotation secret from the programmer. > The typing rules are incredibly complicated so to make things less > scary, they are also hidden from the user. As a result, this idea > makes it impossible for a developer to reason about whether their code > will compile. That doesn't seem like a viable solution. Have I read > this correctly? Well, let me first out point out that the paper by no means describes a complete solution. When we wrote it, we were mainly interested in the static semantics of pure nonstrict functional languages featuring a means to perform in-place updates explicitly. We use uniqueness types to ensure that such updates are safe, i.e., do not violate referential transparency, so that we can keep on enjoying the benefits of purity---equational reasoning being the most obvious example of such benefits. Our choice for denoting in-place updates in the source program explicitly is a very conscious one. Of course, having opportunities for in-place updates inferred by the compiler is highly desirable, but there's always a chance that the compiler does not find all the locations in the source program in which an update can be inserted. A programmer, having specific knowledge of the behaviour of the program and the opportunities for in-place updates that arise, may then expect updates to be inserted only to find out, when profiling the memory behaviour of the program, that certain updates where not inferred. What to do then? Restructuring the program, hoping that the optimization can be found if some pieces of code are altered, seems particularly undesirable; we then rather insert the updates by hand. Thus, explicit updates, at the very least, can be a valuable addition to a system that tries to infer updates automatically. As of now, the material in the paper is merely an exercise in static semantics: we have not implemented the system in a full-scale compiler. But to do so, ranks high on our wish list. Maybe it makes an interesting student project. By all means, we would like to get our hands on a mature set of benchmark results. As mentioned in the paper, the viability of a system of explicit updates may well depend on the particularities of the underlying memory model. This may further complicate the semantics and, worse, make the semantics backend-dependent. Note, that backend consideration also play a role in a system in which all updates are implicit, i.e, inferred. The Clean language, for example, features uniqueness typing as a means to deal with side-effects in general and the Clean compiler uses uniqueness information to insert in-place updates of memory cells. Opportunities for in-place updates, however, do not solely depend on the uniqueness of values but, indeed, also on the details of the backend involved as illustrated by a recent thread on the Clean Discussions mailing list: http://mailman.science.ru.nl/pipermail/clean-list/2008/003794.html (in particular: http://mailman.science.ru.nl/pipermail/clean-list/2008/003795.html) . With regard to your concerns: in a system with explicit updates there's always a chance that a programmer uses updates in an unsafe fashion, i.e., in such a way that referential transparency can no longer be guaranteed. Simply issuing a type-error message that involves richly annotates types may be a bit harsh then as these types tend to grow rather complex. We do not as much suggest to hide these types from the programmer altogether, but we think it's at the very least useful to come up with an error message that does a good job explaining what went wrong. (What comes to mind almost immediately is the PhD work of Bastiaan Heeren: http://people.cs.uu.nl/bastiaan/phdthesis/.) An interesting point here is that there are always at least two program points that are "to blame" here: the location of the actual explicit update and the point (or points) at the which the flow of the value to update may fork. So, in short: as far as we are concerned, there's no definite story on this subject yet. For those attending Fun in the Afternoon tomorrow at the University of Herfordshire: Jur will give a talk about this material, roughly based on the stuff we presented at PEPM in January. Then, Malcolm remarked: > Uniqueness typing does not lead to in-place update. If a value is > only used once, then there is no need to update it at all! In fact, > I believe ghc does this analysis, and has a minor optimisation that > omits the thunk-update. That is, if an unevaluated thunk is forced, > but it has a unique usage, the original thunk is not overwritten > with an indirection to the reduced value (as it normally would be), > but the reduced value is just used directly. The analysis he's referring to is not really uniqueness analysis, but what we would like to call sharing analysis. We've commented on how these analyses relate in a paper (co-written with Arie Middelkoop) that we presented at last year's ICFP: Jurriaan Hage, Stefan Holdermans, and Arie Middelkoop. A generic usage analysis with subeffect qualifiers. In Ralf Hinze and Norman Ramsey, editors, Proceedings of the 12th ACM SIGPLAN International Conference on Functional Programming, ICFP 2007, Freiburg, Germany, October 1--3, 2007, pages 235--246. ACM Press, 2007. http://doi.acm.org/10.1145/1291151.1291189. Indeed, uniqueness analysis and sharing analysis are very alike: in a type-based formulation both can be regarded (more or less) as linear typing extended with a subsumption relation. The difference between uniqueness analysis and sharing analysis then shows in the direction of the subsumption relation: in uniqueness analysis "possibly used more than once" subsumes "used no more than once", while in sharing analysis "used no more than once" subsumes "possibly used more than once". Cheers, Stefan From bulat.ziganshin at gmail.com Wed May 14 17:46:11 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed May 14 17:40:57 2008 Subject: [Haskell-cafe] FFI: newbie linking problem In-Reply-To: References: Message-ID: <1262278243.20080515014611@gmail.com> Hello Olivier, Thursday, May 15, 2008, 1:26:28 AM, you wrote: > ??? RFC_RC _stdcall RfcUTF8ToSAPUC(const RFC_BYTE *utf8, unsigned utf8Length,? SAP_UC *sapuc, > ????? unsigned *sapucSize, unsigned *resultLength, RFC_ERROR_INFO *info) > ??? foreign import ccall unsafe "sapnwrfc.h RfcUTF8ToSAPUC" > ? ? ? f_RfcUTF8ToSAPUC :: RfcBytePtr -> CUInt -> SapUCPtr -> Ptr use stdcall instead of ccall in Haskell too. afair, depending on calling conventions, different prefixes/suffixes are used when translating C function name into assembler (dll) name -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From claus.reinke at talk21.com Wed May 14 18:33:48 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Wed May 14 18:27:35 2008 Subject: [Haskell-cafe] GHC API GSoc project (was: ANN: Haddock version 2.1.0) References: <481A46C0.3050209@gmail.com><012e01c8ac61$cc2f0d60$bf078351@cr3lt><4822F24B.4040801@microsoft.com><4824165B.60800@gmail.com><016401c8b224$6b0b5250$5a307ad5@cr3lt> <916b84820805130837s677e2b42jeccb325fdb67e9c@mail.gmail.com> Message-ID: <025001c8b612$95382390$b0178351@cr3lt> > Feel free to CC me or the ticket with things like that. I'll be > working on this for this year's GSoC and it'd be helpful to find out > what I should tackle first. Hi Thomas, thanks, I was wondering about your project. Is there a project page documenting the issues/tickets you look at, and particularly the plan of attack as it changes in the face of reality?-) I've found http://code.google.com/soc/2008/haskell/appinfo.html?csaid=4189AF2C8AE5E25A which covers a lot of ground, and some interesting issues, but is so general (and design- rather than application-driven) that I've been worried about how much of it you'll manage (and with which priorities), given that the GHC API is indeed exposed rather than designed and may thus interfere with your good intentions in unexpected ways. Also, there are very different user needs out there, some want just analysis or some information extraction, some want source transformation capabilities, some want a stable portable hs-plugins replacement, some want to work with backends, etc. . you can't please everyone, but until your focus is known, people can't easily complain about your priorities. IMHO, trying to support a semantics- and comment-preserving roundtrip in (pretty . parse) would be a good way to start (David says he's going to look at the extracting comments/pragmas part, but they still need to be put back in during pretty printing). It sounds simple, and if it is, it will enable a lot more usage of the GHC API; and if it turns out not to be simple, you'll have a first sign of what you're up against, and can adjust your expectations!-) Making yourself available as you've done here "I'm here; I'm going to work on this now; please cc me if you want to express your priorities" sounds like a good way to pull together the many strands of interests relating to the GHC API. Now we all have to dust off our old "wouldn't it be nice if the API could do this and that"s. Perhaps something similar to what the type family folks are doing would help: use the ticket tracker for individual issues, have test cases that demonstrate the issues and their resolution, have more detailed documents online elsewhere, and a single wiki page to tie everything together (making it easier to find relevant tickets and the state of the art). [cf http://hackage.haskell.org/trac/ghc/wiki/TypeFunctionsStatus ] over the years, quite a few issues have been raised as tickets/ email/source comments, so collecting them would be a good way to get an idea of what is needed, deciding which of those issues would take how much effort would be a first useful contribution, and seeing which of these you intend to tackle would give the community at large a better chance to comment on your priorities in relation to their needs. I also hope you are in touch with Chadda? - the port of HaRe to the GHC API did not make it as a GSoC project, but I understand he is going to do some work in this direction anyway. Looking forward to an improved GHC API!-) Claus ps. here are some first entries for your list, and for other interested parties following along (I'd be very interested to hear about your progress): - http://code.google.com/soc/2008/haskell/appinfo.html?csaid=4189AF2C8AE5E25A (project outline) - http://hackage.haskell.org/trac/ghc/ticket/1467 (GHC API: expose separate compilation stages; your main ticket so far?) - concerning exposed phases, it would also be useful if the interface was more uniform (eg., AST, typed AST,..) - search for NOTE in ghc/compiler/main/GHC.hs for some related notes from an earlier GHC/HaRe meeting - is it possible to use standalone deriving to get a generic programming framework over the ASTs without blowing up GHC's code for its own use (deriving Data, etc.)? - http://www.haskell.org/pipermail/haskell-cafe/2008-May/042616.html (GHC API: how to get the typechecked AST?) - http://hackage.haskell.org/trac/ghc/ticket/1886 (GHC API should preserve and provide access to comments) - dynamic loading of Haskell code, ala hs-plugins, but without the version/platform issues (GHCi has to be able to do this anyway, but it would be nice to have the ugly bits hidden, such as unsafeCast#, or whatever it was). that might require a standard for typeReps, if I recall correctly.. - is there a way to reduce version-skew for clients of the GHC API (currently, there is no stability guaranteed at all, so if you don't want to live with lots of #ifdefs and breakage, you keep delaying your fantastic GHC API-base projects "until the dust settles") - I'm sure there have been many more, but that's the problem: not all these issues have been collected as they were raised; even if you don't tackle all of them, it would be nice if you could collect all of them > On Fri, May 9, 2008 at 8:30 PM, Claus Reinke wrote: >> >> >> > Ah, I didn't think about the GHC options that change the lexical >> > syntax. You're right, using the GHC lexer should be easier. >> > >> >> and, if you do that, you could also make the GHC lexer >> squirrel away the comments (including pragmas, if they aren't >> already in the AST) someplace safe, indexed by, or at least annotated with, >> their source locations, and make this comment/ >> pragma storage available via the GHC API. (1a) >> >> then, we'd need a way to merge those comments and pragmas >> back into the output during pretty printing, and we'd have made >> the first small step towards source-to-source transformations: making code >> survive semantically intact over (pretty . parse). (1b) >> >> that would still not quite fullfill the GHC API comment ticket (*), >> but that was only a quick sketch, not a definite design. it might be >> sufficient to let each GHC API client do its own search to associate bits of >> comment/pragma storage with bits of AST. >> if i understand you correctly, you are going to do (1a), so >> if you could add that to the GHC API, we'd only need (1b) >> to go from useable-for-analysis-and-extraction to >> useable-for-transformation. >> >> is that going to be a problem? >> >> claus >> >> (*) knowing the source location of some piece of AST is not >> sufficient for figuring out whether it has any immediately >> preceding or following comments (there might be other AST >> fragments in between, closer to the next comment). >> but, if one knows the nearest comment segment for each piece of AST, one >> could then build a map where the closest >> AST pieces are mapped to (Just commentID), and the other >> AST pieces are mapped to Nothing. >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From oddron at gmail.com Wed May 14 18:37:38 2008 From: oddron at gmail.com (Ronald Guida) Date: Wed May 14 18:31:19 2008 Subject: [Haskell-cafe] Monad vs ArrowChoice Message-ID: <62728db30805141537m226281cat952af3023acb8d70@mail.gmail.com> I have read that Monad is stronger than Idiom because Monad lets me use the results of a computation to choose between the side effects of alternative future computations, while Idiom does not have this feature. Arrow does not have this feature either. ArrowChoice has the feature that the sum type, Either, can be used to choose between alternative computations, including their side effects. I know that Monad is supposed to be stronger than ArrowChoice, but I have to ask, what exactly can Monad do that ArrowChoice can't do? Let me set up an example to illustrate where I'm coming from. > import Control.Monad.Writer > import Control.Applicative > import Control.Arrow hiding (pure) The missileControl function accepts a flag to determine whether missiles actually get launched, and it returns the number of casualties. > missileControl :: Bool -> IO Integer > missileControl b = do > showFlag b > casualties <- if b > then launchMissiles > else doNotLaunch > return casualties > showFlag :: Bool -> IO Bool > showFlag b = (putStrLn $ "Launch flag = " ++ show b) >> return b > launchMissiles :: IO Integer > launchMissiles = do > putStrLn "Missiles have been launched." > putStrLn "Casualties = 6,700,000,000." > return 6700000000 > doNotLaunch :: IO Integer > doNotLaunch = putStrLn "Missiles not launched." >> return 0 If I try to use an Idiom, or even an Arrow, instead of a Monad, then I don't get to choose between the alternative side effects, and the results will be similar to this: > missileControl' :: Bool -> IO Integer > missileControl' b = do > showFlag b > casualties <- launchMissiles > casualties' <- doNotLaunch > if b > then return casualties > else return casualties' If I use ArrowChoice, then I can do this: > missileControl2 :: Bool -> IO Integer > missileControl2 b = runKleisli a b > where a = (Kleisli $ showFlag) >>> (arr boolToEither) >>> > ((Kleisli $ const launchMissiles) ||| > (Kleisli $ const doNotLaunch)) > boolToEither :: Bool -> Either () () > boolToEither True = Left () > boolToEither False = Right () GHCi> missileControl2 True Launch flag = True Missiles have been launched. Casualties = 6,700,000,000. 6700000000 GHCi> missileControl2 False Launch flag = False Missiles not launched. 0 From ccshan at post.harvard.edu Wed May 14 18:01:37 2008 From: ccshan at post.harvard.edu (Chung-chieh Shan) Date: Wed May 14 18:54:57 2008 Subject: [Haskell-cafe] Re: Monad for HOAS? References: <20080514091117.GA20684@netsoc.tcd.ie> <20080514125958.GA10853@cs.helsinki.fi> <20080514145922.GA2936@netsoc.tcd.ie> Message-ID: <134sf5-8af.ln1@mantle.rutgers.edu> Conal Elliott wrote in article in gmane.comp.lang.haskell.cafe: > I share your perspective, Edsko. If foo and (Let foo id) are > indistinguishable to clients of your module and are equal with respect to > your intended semantics of Exp, then I'd say at least this one monad law > holds. - Conal I am at least sympathetic to this perspective, but the Expr constructors are not as polymorphic as the monad operations: if in do a <- foo return a foo has type "ExprM String" (perhaps foo is equal to "return []"), then we want to generate the DSL expression "Let [] id", but "[]" is not of type "Expr". Because whenever foo's type is not "ExprM Expr" the above code using do notation must be exactly equal to foo, by parametricity even when foo's type is "ExprM Expr" we cannot generate Let. -- Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig The pomotarians have nothing to lose but their value chains. Call the Thermodynamics Police! From olivier.boudry at gmail.com Wed May 14 19:08:35 2008 From: olivier.boudry at gmail.com (Olivier Boudry) Date: Wed May 14 19:02:16 2008 Subject: [Haskell-cafe] FFI: newbie linking problem In-Reply-To: <1262278243.20080515014611@gmail.com> References: <1262278243.20080515014611@gmail.com> Message-ID: On Wed, May 14, 2008 at 5:46 PM, Bulat Ziganshin wrote: > use stdcall instead of ccall in Haskell too. afair, depending on > calling conventions, different prefixes/suffixes are used when > translating C function name into assembler (dll) name > Oops, sorry I copied the wrong line in my e-mail. I'm using stdcall in the foreign import. I first tried with ccall and then realized the header was defining the stdcall convention when built on windows. The link error occurs when I use stdcall. When I use ccall it links but gives segmentation faults when I run the program. Here is the last import I used. foreign import stdcall unsafe "sapnwrfc.h RfcUTF8ToSAPUC" f_RfcUTF8ToSAPUC :: RfcBytePtr -> CUInt -> SapUCPtr -> Ptr CUInt -> Ptr CUInt -> RfcErrorInfoPtr -> IO RfcRetCodeType Thanks, Olivier. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080514/defc0fa1/attachment.htm From derek.a.elkins at gmail.com Wed May 14 19:40:22 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Wed May 14 19:34:08 2008 Subject: [Haskell-cafe] Short circuiting and the Maybe monad In-Reply-To: <625b74080805141242odf4122o2ddaf4c0ec9d60ea@mail.gmail.com> References: <65113aef0805121509s6b4e76bbxd23e86070a2a0be3@mail.gmail.com> <482A7AF0.6020008@tcs.inf.tu-dresden.de> <482B378E.802@btinternet.com> <625b74080805141242odf4122o2ddaf4c0ec9d60ea@mail.gmail.com> Message-ID: <1210808422.5514.72.camel@derek-laptop> On Wed, 2008-05-14 at 12:42 -0700, Dan Piponi wrote: > On Wed, May 14, 2008 at 12:03 PM, Andrew Coppin > wrote: > > > "It is well-known that trees with substitution form a monad." > > Now that's funny. Compare with the first line of this paper: > http://citeseer.ist.psu.edu/510658.html Well, it's well-known. Further, not only do they form a monad, but they are a free monad. From twanvl at gmail.com Wed May 14 19:43:18 2008 From: twanvl at gmail.com (Twan van Laarhoven) Date: Wed May 14 19:36:53 2008 Subject: [Haskell-cafe] Monad vs ArrowChoice In-Reply-To: <62728db30805141537m226281cat952af3023acb8d70@mail.gmail.com> References: <62728db30805141537m226281cat952af3023acb8d70@mail.gmail.com> Message-ID: <482B7916.8090608@gmail.com> Ronald Guida wrote: > I have read that Monad is stronger than Idiom because Monad lets me > use the results of a computation to choose between the side effects of > alternative future computations, while Idiom does not have this > feature. Arrow does not have this feature either. > > ArrowChoice has the feature that the sum type, Either, can be used to > choose between alternative computations, including their side effects. > I know that Monad is supposed to be stronger than ArrowChoice, but I > have to ask, what exactly can Monad do that ArrowChoice can't do? Monads are equivalent to ArrowApply, they allow you to use a computed *action*. For example: getMissileLauncher :: IO (String -> IO ()) notWithArrows = do launchMissiles <- getMissleLauncher launchMissiles "Russia" ArrowChoice is not enough to implement this function. But it is possible with ArrowApply, of which Kleisli IO is an instance. Twan From chaddai.fouche at gmail.com Wed May 14 20:12:10 2008 From: chaddai.fouche at gmail.com (=?ISO-8859-1?Q?Chadda=EF_Fouch=E9?=) Date: Wed May 14 20:05:52 2008 Subject: [Haskell-cafe] GHC API GSoc project (was: ANN: Haddock version 2.1.0) In-Reply-To: <025001c8b612$95382390$b0178351@cr3lt> References: <012e01c8ac61$cc2f0d60$bf078351@cr3lt> <4822F24B.4040801@microsoft.com> <4824165B.60800@gmail.com> <016401c8b224$6b0b5250$5a307ad5@cr3lt> <916b84820805130837s677e2b42jeccb325fdb67e9c@mail.gmail.com> <025001c8b612$95382390$b0178351@cr3lt> Message-ID: 2008/5/15 Claus Reinke : > Feel free to CC me or the ticket with things like that. I'll be > IMHO, trying to support a semantics- and comment-preserving > roundtrip in (pretty . parse) would be a good way to start (David > says he's going to look at the extracting comments/pragmas part, > but they still need to be put back in during pretty printing). It sounds > simple, and if it is, it will enable a lot more usage of the GHC API; > and if it turns out not to be simple, you'll have a first sign of what > you're up against, and can adjust your expectations!-) > > I also hope you are in touch with Chadda? - the port of HaRe > to the GHC API did not make it as a GSoC project, but I > understand he is going to do some work in this direction > anyway. > > - http://hackage.haskell.org/trac/ghc/ticket/1886 > (GHC API should preserve and provide access to comments) Well not in touch until now, I was waiting a little bit to see in which direction this project is going to evolve. There's plenty of interesting improvement that one could bring to GHC API. For my project of course, I'm very interested in the preserving comment part. I intended to make it independantly, like Haddock do now, but if the GHC API was to get native support for it, it would be great (for all kind of others applications too). I'll keep in touch. -- Chadda? From derek.a.elkins at gmail.com Wed May 14 20:32:44 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Wed May 14 20:26:29 2008 Subject: [Haskell-cafe] Re: GHC predictability In-Reply-To: <20080513023043.GA3520@scytale.galois.com> References: <20080513023043.GA3520@scytale.galois.com> Message-ID: <1210811564.5514.77.camel@derek-laptop> On Mon, 2008-05-12 at 19:30 -0700, Don Stewart wrote: > > I offer up the following example: > > > > mean xs = sum xs / length xs > > > > Now try, say, "mean [1.. 1e9]", and watch GHC eat several GB of RAM. (!!) > > But you know why, don't you? > > > sat down and spent the best part of a day writing an MD5 > > implementation. Eventually I got it so that all the test vectors work > > right. (Stupid little-endian nonsense... mutter mutter...) When I tried > > it on a file containing more than 1 MB of data... ooooohhhh dear... > > Did you use Data.Binary or the other libraries for efficient access to gigabytes of data? > > > Of course, the first step in any serious attempt at performance improvement > > is to actually profile the code to figure out where the time > > is being spent. > > Well, actually, for our 'mean()' case, it means just using the right structures. > Arrays for example: > > import Data.Array.Vector > import Text.Printf > > mean :: UArr Double -> Double > mean arr = b / fromIntegral a > where > k (n :*: s) a = n+1 :*: s+a > a :*: b = foldlU k (0 :*: 0) arr :: (Int :*: Double) > > main = printf "%f\n" . mean $ enumFromToFracU 1 1e9 > > For example, > > $ time ./A > 5.00000000067109e8 > ./A 3.53s user 0.00s system 99% cpu 3.532 total > > Try allocating an array of doubles in C, and getting similar results. > (The compiler is optimising this to: > > Main_zdszdwfold_info: > leaq 32(%r12), %rax > cmpq %r15, %rax > movq %rax, %r12 > ja .L10 > movsd .LC0(%rip), %xmm0 > ucomisd %xmm5, %xmm0 > jae .L12 > movq %rsi, (%rax) > movq $base_GHCziFloat_Dzh_con_info, -24(%rax) > movsd %xmm6, -16(%rax) > movq $base_GHCziBase_Izh_con_info, -8(%rax) > leaq -7(%rax), %rbx > leaq -23(%rax), %rsi > jmp *(%rbp) > .L12: > movapd %xmm6, %xmm0 > addq $1, %rsi > subq $32, %r12 > addsd %xmm5, %xmm0 > addsd .LC2(%rip), %xmm5 > movapd %xmm0, %xmm6 > jmp Main_zdszdwfold_info > > Note even any garbage collection. This should be pretty much the same > performance-wise as unoptimised C. > > > almost any nontrivial program you write > > spends 60% or more of its time doing GC rather than actual work. > > Ok, you're doing something very wrong. GC time is typically less than 15% of the running > time of typical work programs I hack on. > > I bet you're using lists inappropriately? > > > I find it completely impossibly to write code that doesn't crawl along at a > > snail's pace. Even when I manage to make it faster, I usually have no clue > > why. > > I think there is a problem that few people are taking the time to understand > the compilation model of Haskell, while they've had the C runtime behaviour > drilled into their brains since college. > > Until you sit down and understand what your Haskell code means, it will be very > hard to reason about optimisations, unfortunately. > > GHC does what it does well, and its predictable. As long as you understand > the operations your trying to make predictions about. > > I suggest installing ghc-core, and looking at how your code is compiled. > Try many examples, and have a good knowledge of the STG paper. My experience has been that simply understanding lazy/normal order evaluation is enough to catch most of the "big performance problems" beginners complain about. If you can't evaluate Haskell by hand at the source level, you have no hope of understanding performance issues. For going more for C-like speed, your advice seems more appropriate. From dons at galois.com Wed May 14 20:34:24 2008 From: dons at galois.com (Don Stewart) Date: Wed May 14 20:28:16 2008 Subject: [Haskell-cafe] Re: GHC predictability In-Reply-To: <1210811564.5514.77.camel@derek-laptop> References: <20080513023043.GA3520@scytale.galois.com> <1210811564.5514.77.camel@derek-laptop> Message-ID: <20080515003424.GF10746@scytale.galois.com> derek.a.elkins: > On Mon, 2008-05-12 at 19:30 -0700, Don Stewart wrote: > > > I offer up the following example: > > > > > > mean xs = sum xs / length xs > > > > > > Now try, say, "mean [1.. 1e9]", and watch GHC eat several GB of RAM. (!!) > > > > But you know why, don't you? > > > > > sat down and spent the best part of a day writing an MD5 > > > implementation. Eventually I got it so that all the test vectors work > > > right. (Stupid little-endian nonsense... mutter mutter...) When I tried > > > it on a file containing more than 1 MB of data... ooooohhhh dear... > > > > Did you use Data.Binary or the other libraries for efficient access to gigabytes of data? > > > > > Of course, the first step in any serious attempt at performance improvement > > > is to actually profile the code to figure out where the time > > > is being spent. > > > > Well, actually, for our 'mean()' case, it means just using the right structures. > > Arrays for example: > > > > import Data.Array.Vector > > import Text.Printf > > > > mean :: UArr Double -> Double > > mean arr = b / fromIntegral a > > where > > k (n :*: s) a = n+1 :*: s+a > > a :*: b = foldlU k (0 :*: 0) arr :: (Int :*: Double) > > > > main = printf "%f\n" . mean $ enumFromToFracU 1 1e9 > > > > For example, > > > > $ time ./A > > 5.00000000067109e8 > > ./A 3.53s user 0.00s system 99% cpu 3.532 total > > > > Try allocating an array of doubles in C, and getting similar results. > > (The compiler is optimising this to: > > > > Main_zdszdwfold_info: > > leaq 32(%r12), %rax > > cmpq %r15, %rax > > movq %rax, %r12 > > ja .L10 > > movsd .LC0(%rip), %xmm0 > > ucomisd %xmm5, %xmm0 > > jae .L12 > > movq %rsi, (%rax) > > movq $base_GHCziFloat_Dzh_con_info, -24(%rax) > > movsd %xmm6, -16(%rax) > > movq $base_GHCziBase_Izh_con_info, -8(%rax) > > leaq -7(%rax), %rbx > > leaq -23(%rax), %rsi > > jmp *(%rbp) > > .L12: > > movapd %xmm6, %xmm0 > > addq $1, %rsi > > subq $32, %r12 > > addsd %xmm5, %xmm0 > > addsd .LC2(%rip), %xmm5 > > movapd %xmm0, %xmm6 > > jmp Main_zdszdwfold_info > > > > Note even any garbage collection. This should be pretty much the same > > performance-wise as unoptimised C. > > > > > almost any nontrivial program you write > > > spends 60% or more of its time doing GC rather than actual work. > > > > Ok, you're doing something very wrong. GC time is typically less than 15% of the running > > time of typical work programs I hack on. > > > > I bet you're using lists inappropriately? > > > > > I find it completely impossibly to write code that doesn't crawl along at a > > > snail's pace. Even when I manage to make it faster, I usually have no clue > > > why. > > > > I think there is a problem that few people are taking the time to understand > > the compilation model of Haskell, while they've had the C runtime behaviour > > drilled into their brains since college. > > > > Until you sit down and understand what your Haskell code means, it will be very > > hard to reason about optimisations, unfortunately. > > > > GHC does what it does well, and its predictable. As long as you understand > > the operations your trying to make predictions about. > > > > I suggest installing ghc-core, and looking at how your code is compiled. > > Try many examples, and have a good knowledge of the STG paper. > > My experience has been that simply understanding lazy/normal order > evaluation is enough to catch most of the "big performance problems" > beginners complain about. If you can't evaluate Haskell by hand at the > source level, you have no hope of understanding performance issues. > > For going more for C-like speed, your advice seems more appropriate. > Yes, I agree. You must first be able to reason about the evaluation strategy on paper. If you want to get C like speed, you should understand Core. Thankfully, the knowledge of how to do this, and tools to help, are improving. -- Don From jonathanccast at fastmail.fm Wed May 14 21:32:56 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Wed May 14 21:26:39 2008 Subject: [Haskell-cafe] Re: Endianess In-Reply-To: <023a01c8b607$6dba95b0$b0178351@cr3lt> References: <20080509212412.GE24396@scytale.galois.com> <48289421.2070408@btinternet.com> <87ve1ixcrh.fsf@nmd9999.imr.no> <20080513191102.GA11402@brakk.ethz <482B30CB.7080607@imageworks.com> <023a01c8b607$6dba95b0$b0178351@cr3lt> Message-ID: On 14 May 2008, at 2:13 PM, Claus Reinke wrote: >>>>> It's not that simple with bits. They lack consistency just >>>>> like the >>>>> usual US date format and the way Germans read numbers. >>>>> >>>> So you claim that you pronounce 14 tenty-four? In German >>>> pronunciation >>>> is completely uniform from 13 to 99. >>> http://www.verein-zwanzigeins.de/ >> So I've always wondered, if you are writing down a number being >> dictated (slowly) by someone else, like 234, do you write the 2, >> then leave space and write the 4, then go back and fill in with 3? >> Or do you push the 4 onto the stack until the 3 arrives, and write >> 34 at once. > > Germans have no problems with sentences which though started at > the beginning when observed closely and in the light of day (none of > which adds anything to the content of the sentence in which the very > parenthetical remark you -dear reader- are reading at this very moment > while wondering whether the writer -dear me- is ever going to reach > his point -if, in fact, there is a point (of which one cannot > always be > entirely sure until one has stored and processed the whole construct > from beginning to end and thought it over carefully at least once more > because who knows, sense appears here and there, now and then, > to this one and that one, and how are you, Mr. Wilson? >> If the latter, does this imply that Germans have a harder time >> with tail recursion? > > you mean as in returning from a different context than the one > we decended into? we'd never do such a thing, honestly!-) > > then again, Jane Austen was happy enough writing about her > characters not being "one and twenty", so perhaps that is just a > lost art?-) Murthered, by the same revolutionaries who destroyed the rest of the world Jane Austen wrote about. jcc From stansife at caltech.edu Wed May 14 21:40:13 2008 From: stansife at caltech.edu (Eric Stansifer) Date: Wed May 14 21:33:53 2008 Subject: [Haskell-cafe] Re: Endianess In-Reply-To: <482B30CB.7080607@imageworks.com> References: <20080509212412.GE24396@scytale.galois.com> <48289421.2070408@btinternet.com> <87ve1ixcrh.fsf@nmd9999.imr.no> <482B30CB.7080607@imageworks.com> Message-ID: <2e58fd390805141840v1d874b6at9257f38ce724bf8a@mail.gmail.com> > So I've always wondered, if you are writing down a number being dictated > (slowly) by someone else, like 234, do you write the 2, then leave space and > write the 4, then go back and fill in with 3? Or do you push the 4 onto the > stack until the 3 arrives, and write 34 at once. My German professor told us a story, set in WWII: Two British pilots shot down behind enemy lines, who had received very thorough training on German culture, current sports, etc., successfully blended in with the native Germans for some time until someone noticed them in a cafe writing down the sum on their bill in left-to-right order. They were summarily shot. Not that I have any idea whether this is based on truth or not, or whether Germans, in fact, write the last two digits in reverse order. Also, Claus's reply gives me a headache. Eric From ok at cs.otago.ac.nz Wed May 14 22:07:17 2008 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Wed May 14 22:01:25 2008 Subject: [Haskell-cafe] Richer (than ascii) notation for haskell source? In-Reply-To: References: <93BECC602E286B499D5443ECB850D2FF01331E95@newman.usa.aitgroupad.com> <482B3022.2050303@btinternet.com> <4FD84C61-C940-4B29-A207-D23F8B72D00F@ece.cmu.edu> <482B36EB.6000708@btinternet.com> Message-ID: <72A31F34-22AD-4C81-A450-7463BDA07E86@cs.otago.ac.nz> On 15 May 2008, at 7:19 am, Brandon S. Allbery KF8NH wrote: > Unfortunately, while I thought there was a distinct lambda sign that > wasn't the lowercase Greek letter, there isn't. (That said, I don't > see why it couldn't be a keyword. You'd need a space after it.) There are three lambda letters: lower and upper case Greek, and Ugaritic (U+1038D). But there are also mathematical symbols: U+166CC mathematical bold small lamda (sic.) U+1D706 mathematical italic small lamda (sic.) U+1D740 mathematical bold italic small lamda (sic.) U+1D77A mathematical sans-serif bold small lamda (sic.) U+1D7B4 mathematical sans-serif bold italic small lamda (sic.) These things are visually letters, but as mathematical symbols they should not combine into words. Except that to my surprise, nay, to my utter astonishment, the Unicode 5.1 character data base classifies them as letters just like the letter "e". At least to give editors a fighting chance of matching their concept of a "word" with Haskell tokens, it might be better to use nabla instead of lambda. Other old APL fans may understand why (:-). Alternatively, didn't Church really want to use a character rather like a down tack, and have to squish it to get a letter his printer was happy with? Nah, nabla for me. -- "I don't want to discuss evidence." -- Richard Dawkins, in an interview with Rupert Sheldrake. (Fortean times 232, p55.) From westondan at imageworks.com Wed May 14 22:16:29 2008 From: westondan at imageworks.com (Dan Weston) Date: Wed May 14 22:10:14 2008 Subject: [Haskell-cafe] Richer (than ascii) notation for haskell source? In-Reply-To: <72A31F34-22AD-4C81-A450-7463BDA07E86@cs.otago.ac.nz> References: <93BECC602E286B499D5443ECB850D2FF01331E95@newman.usa.aitgroupad.com> <482B3022.2050303@btinternet.com> <4FD84C61-C940-4B29-A207-D23F8B72D00F@ece.cmu.edu> <482B36EB.6000708@btinternet.com> <72A31F34-22AD-4C81-A450-7463BDA07E86@cs.otago.ac.nz> Message-ID: <482B9CFD.3030600@imageworks.com> Richard A. O'Keefe wrote: > At least to give editors a fighting chance of matching their concept of a > "word" with Haskell tokens, it might be better to use nabla instead of > lambda. Other old APL fans may understand why (:-). Alternatively, didn't > Church really want to use a character rather like a down tack, and have to > squish it to get a letter his printer was happy with? Nah, nabla for me. nablabot anyone? Nabla calculus? (But wait, in differential calculus nabla is a gradient operator, so let's rename that lambda). And people misspelling nabla as nambla will find a surprise when they google it... Better use a Unihan character instead. From Patrick.Surry at portraitsoftware.com Wed May 14 22:23:59 2008 From: Patrick.Surry at portraitsoftware.com (Patrick Surry) Date: Wed May 14 22:18:03 2008 Subject: [Haskell-cafe] Re: Richer (than ascii) notation for haskell source? In-Reply-To: <20080514210752.9206D324238@www.haskell.org> References: <20080514210752.9206D324238@www.haskell.org> Message-ID: <93BECC602E286B499D5443ECB850D2FF01331F40@newman.usa.aitgroupad.com> Lots of folk have suggested writing code with Unicode symbols, but that doesn't really get me where I'm thinking of. Back in the day, I spent many happy hours writing math(s) in amstex style, peppered with latex backslash references/macros for greek symbols, set operators as well as character attributes like underline, bold, goth, italic and so on. With the magic of (la)tex and dvips you get a rich intuitive representation of your equations - where you can 'see' types by character attributes (bold vectors, gothic sets or whatever) and have easily readable operators, functions, etc. Similarly to display alternative pattern cases as a display equation? So maybe what I really want is to essentially write my source in (la)tex and be able to both compile and render to dvi at the same time? I suppose word's crazy equation editor or mathml is another option but it makes the source itself either less portable or less readable? I think Knuth talks about literate programming as this ability to intermingle 'beautified' human-readable representation along with code, and it seems like Haskell is close to delivering that. (Tho I think "literate Haskell" is not the same thing.) Perhaps a pipe dream tho. Patrick ________________________________________________________________________ DISCLAIMER: This e-mail is intended only for the addressee named above. As this e-mail may contain confidential or privileged information, if you are not the named addressee, you are not authorised to retain, read, copy or disseminate this message or any part of it. If you received this email in error, please notify the sender and delete the message from your computer. From Patrick.Surry at portraitsoftware.com Wed May 14 22:28:51 2008 From: Patrick.Surry at portraitsoftware.com (Patrick Surry) Date: Wed May 14 22:23:05 2008 Subject: [Haskell-cafe] RE: Richer (than ascii) notation for haskell source? References: <20080514210752.9206D324238@www.haskell.org> Message-ID: <93BECC602E286B499D5443ECB850D2FF01331F41@newman.usa.aitgroupad.com> Sorry, missed a mail digest: LyX and lhs2tex sound more like what I mean. Patrick -----Original Message----- From: Patrick Surry Sent: Wednesday, May 14, 2008 10:24 PM To: 'haskell-cafe@haskell.org' Subject: Re: Richer (than ascii) notation for haskell source? Lots of folk have suggested writing code with Unicode symbols, but that doesn't really get me where I'm thinking of. Back in the day, I spent many happy hours writing math(s) in amstex style, peppered with latex backslash references/macros for greek symbols, set operators as well as character attributes like underline, bold, goth, italic and so on. With the magic of (la)tex and dvips you get a rich intuitive representation of your equations - where you can 'see' types by character attributes (bold vectors, gothic sets or whatever) and have easily readable operators, functions, etc. Similarly to display alternative pattern cases as a display equation? So maybe what I really want is to essentially write my source in (la)tex and be able to both compile and render to dvi at the same time? I suppose word's crazy equation editor or mathml is another option but it makes the source itself either less portable or less readable? I think Knuth talks about literate programming as this ability to intermingle 'beautified' human-readable representation along with code, and it seems like Haskell is close to delivering that. (Tho I think "literate Haskell" is not the same thing.) Perhaps a pipe dream tho. Patrick ________________________________________________________________________ DISCLAIMER: This e-mail is intended only for the addressee named above. As this e-mail may contain confidential or privileged information, if you are not the named addressee, you are not authorised to retain, read, copy or disseminate this message or any part of it. If you received this email in error, please notify the sender and delete the message from your computer. From allbery at ece.cmu.edu Wed May 14 22:34:03 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Wed May 14 22:27:45 2008 Subject: [Haskell-cafe] Richer (than ascii) notation for haskell source? In-Reply-To: <72A31F34-22AD-4C81-A450-7463BDA07E86@cs.otago.ac.nz> References: <93BECC602E286B499D5443ECB850D2FF01331E95@newman.usa.aitgroupad.com> <482B3022.2050303@btinternet.com> <4FD84C61-C940-4B29-A207-D23F8B72D00F@ece.cmu.edu> <482B36EB.6000708@btinternet.com> <72A31F34-22AD-4C81-A450-7463BDA07E86@cs.otago.ac.nz> Message-ID: <535E1E5A-83DA-4D4B-8D24-FA08B3EF0190@ece.cmu.edu> On 2008 May 14, at 22:07, Richard A. O'Keefe wrote: > On 15 May 2008, at 7:19 am, Brandon S. Allbery KF8NH wrote: >> Unfortunately, while I thought there was a distinct lambda sign >> that wasn't the lowercase Greek letter, there isn't. (That said, I >> don't see why it couldn't be a keyword. You'd need a space after >> it.) > > There are three lambda letters: lower and upper case Greek, and > Ugaritic (U+1038D). > But there are also mathematical symbols: > > U+166CC mathematical bold small lamda (sic.) > U+1D706 mathematical italic small lamda (sic.) > U+1D740 mathematical bold italic small lamda (sic.) > U+1D77A mathematical sans-serif bold small lamda (sic.) > U+1D7B4 mathematical sans-serif bold italic small lamda (sic.) Hm. Newer Unicode standard than the version supported by OSX and GNOME, I take it? That's not so helpful if nobody actually supports the characters in question. (My Mac claims 166CC is in an unassigned area, and no supplied font has the others. It does at least acknowledge that the others should exist and are "letters".) Hm, U+2144 as an approximation? I still suspect it would not be outside the pale to make ? a keyword. We already have several, after all. > At least to give editors a fighting chance of matching their concept > of a > "word" with Haskell tokens, it might be better to use nabla instead of > lambda. Other old APL fans may understand why (:-). Alternatively, > didn't > Church really want to use a character rather like a down tack, and > have to > squish it to get a letter his printer was happy with? Nah, nabla > for me. :) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From allbery at ece.cmu.edu Wed May 14 22:35:00 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Wed May 14 22:28:41 2008 Subject: [Haskell-cafe] Re: Richer (than ascii) notation for haskell source? In-Reply-To: <93BECC602E286B499D5443ECB850D2FF01331F40@newman.usa.aitgroupad.com> References: <20080514210752.9206D324238@www.haskell.org> <93BECC602E286B499D5443ECB850D2FF01331F40@newman.usa.aitgroupad.com> Message-ID: On 2008 May 14, at 22:23, Patrick Surry wrote: > So maybe what I really want is to essentially write my source in > (la)tex > and be able to both compile and render to dvi at the same time? I > suppose word's crazy equation editor or mathml is another option but > it > makes the source itself either less portable or less readable? Someone already pointed to a way to do that, IIRC. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From ok at cs.otago.ac.nz Wed May 14 22:40:15 2008 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Wed May 14 22:34:03 2008 Subject: [Haskell-cafe] Richer (than ascii) notation for haskell source? In-Reply-To: <535E1E5A-83DA-4D4B-8D24-FA08B3EF0190@ece.cmu.edu> References: <93BECC602E286B499D5443ECB850D2FF01331E95@newman.usa.aitgroupad.com> <482B3022.2050303@btinternet.com> <4FD84C61-C940-4B29-A207-D23F8B72D00F@ece.cmu.edu> <482B36EB.6000708@btinternet.com> <72A31F34-22AD-4C81-A450-7463BDA07E86@cs.otago.ac.nz> <535E1E5A-83DA-4D4B-8D24-FA08B3EF0190@ece.cmu.edu> Message-ID: On 15 May 2008, at 2:34 pm, Brandon S. Allbery KF8NH wrote: > Hm. Newer Unicode standard than the version supported by OSX and > GNOME, I take it? That's not so helpful if nobody actually supports > the characters in question. (My Mac claims 166CC is in an > unassigned area, and no supplied font has the others. It does at > least acknowledge that the others should exist and are "letters".) Whoops. Sorry, typo. 166CC should have been 1D6CC. I was actually looking at the Unicode 5.1 character data base, but the copy I keep on my own machine is the 4.0.0 version, and those mathematical symbols were there back in 4.0.0. > I still suspect it would not be outside the pale to make ? a > keyword. We already have several, after all. I'd rather not have to write \x as ? x with a space required after the ?. I suspect that "? is the lambda-symbol iff it is not preceded by any identifier character and is not followed by a Greek letter" might work. From allbery at ece.cmu.edu Wed May 14 22:46:26 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Wed May 14 22:40:08 2008 Subject: [Haskell-cafe] Richer (than ascii) notation for haskell source? In-Reply-To: References: <93BECC602E286B499D5443ECB850D2FF01331E95@newman.usa.aitgroupad.com> <482B3022.2050303@btinternet.com> <4FD84C61-C940-4B29-A207-D23F8B72D00F@ece.cmu.edu> <482B36EB.6000708@btinternet.com> <72A31F34-22AD-4C81-A450-7463BDA07E86@cs.otago.ac.nz> <535E1E5A-83DA-4D4B-8D24-FA08B3EF0190@ece.cmu.edu> Message-ID: On 2008 May 14, at 22:40, Richard A. O'Keefe wrote: >> I still suspect it would not be outside the pale to make ? a >> keyword. We already have several, after all. > > I'd rather not have to write \x as ? x with a space required after > the ?. > I suspect that "? is the lambda-symbol iff it is not preceded by any > identifier character and is not followed by a Greek letter" might > work. Adjacent different scripts in general is probably a reasonable token discriminator. A "token" combining LTR and RTL, for example, is just confusing. (Japanese might need to be an exception; I don't know if ideographs and romanji are ever mixed at the word level.) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From derek.a.elkins at gmail.com Wed May 14 22:57:11 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Wed May 14 22:50:57 2008 Subject: [Haskell-cafe] Richer (than ascii) notation for haskell source? In-Reply-To: References: <93BECC602E286B499D5443ECB850D2FF01331E95@newman.usa.aitgroupad.com> <482B3022.2050303@btinternet.com> <4FD84C61-C940-4B29-A207-D23F8B72D00F@ece.cmu.edu> <482B36EB.6000708@btinternet.com> <72A31F34-22AD-4C81-A450-7463BDA07E86@cs.otago.ac.nz> <535E1E5A-83DA-4D4B-8D24-FA08B3EF0190@ece.cmu.edu> Message-ID: <1210820232.5514.83.camel@derek-laptop> On Thu, 2008-05-15 at 14:40 +1200, Richard A. O'Keefe wrote: > On 15 May 2008, at 2:34 pm, Brandon S. Allbery KF8NH wrote: > > Hm. Newer Unicode standard than the version supported by OSX and > > GNOME, I take it? That's not so helpful if nobody actually supports > > the characters in question. (My Mac claims 166CC is in an > > unassigned area, and no supplied font has the others. It does at > > least acknowledge that the others should exist and are "letters".) > > Whoops. Sorry, typo. 166CC should have been 1D6CC. > > I was actually looking at the Unicode 5.1 character data base, > but the copy I keep on my own machine is the 4.0.0 version, > and those mathematical symbols were there back in 4.0.0. > > > I still suspect it would not be outside the pale to make ? a > > keyword. We already have several, after all. > > I'd rather not have to write \x as ? x with a space required after the > ?. > I suspect that "? is the lambda-symbol iff it is not preceded by any > identifier character and is not followed by a Greek letter" might work. ??. ... ??. ... ?? ?. ... From trebla at vex.net Wed May 14 23:01:03 2008 From: trebla at vex.net (Albert Y. C. Lai) Date: Wed May 14 22:54:42 2008 Subject: [Haskell-cafe] Re: Endianess In-Reply-To: <023a01c8b607$6dba95b0$b0178351@cr3lt> References: <20080509212412.GE24396@scytale.galois.com> <48289421.2070408@btinternet.com> <87ve1ixcrh.fsf@nmd9999.imr.no> <20080513191102.GA11402@brakk.ethz <482B30CB.7080607@imageworks.com> <023a01c8b607$6dba95b0$b0178351@cr3lt> Message-ID: <482BA76F.5040801@vex.net> Claus Reinke wrote: > Germans have no problems with sentences which though started at > the beginning when observed closely and in the light of day (none of > which adds anything to the content of the sentence in which the very > parenthetical remark you -dear reader- are reading at this very moment > while wondering whether the writer -dear me- is ever going to reach > his point -if, in fact, there is a point (of which one cannot always be > entirely sure until one has stored and processed the whole construct > from beginning to end and thought it over carefully at least once more > because who knows, sense appears here and there, now and then, > to this one and that one, and how are you, Mr. Wilson? Unmatched open parentheses. > you mean as in returning from a different context than the one > we decended into? we'd never do such a thing, honestly!-) > > then again, Jane Austen was happy enough writing about her > characters not being "one and twenty", so perhaps that is just a > lost art?-) Oh, I see the matching closing parentheses now. Perfect... 72MB freed by GC in 2.3ms. From allbery at ece.cmu.edu Wed May 14 23:04:11 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Wed May 14 22:57:53 2008 Subject: [Haskell-cafe] Richer (than ascii) notation for haskell source? In-Reply-To: <1210820232.5514.83.camel@derek-laptop> References: <93BECC602E286B499D5443ECB850D2FF01331E95@newman.usa.aitgroupad.com> <482B3022.2050303@btinternet.com> <4FD84C61-C940-4B29-A207-D23F8B72D00F@ece.cmu.edu> <482B36EB.6000708@btinternet.com> <72A31F34-22AD-4C81-A450-7463BDA07E86@cs.otago.ac.nz> <535E1E5A-83DA-4D4B-8D24-FA08B3EF0190@ece.cmu.edu> <1210820232.5514.83.camel@derek-laptop> Message-ID: <56175B3C-D8B4-4763-BD7A-B45947D2D1DA@ece.cmu.edu> On 2008 May 14, at 22:57, Derek Elkins wrote: > On Thu, 2008-05-15 at 14:40 +1200, Richard A. O'Keefe wrote: >> I suspect that "? is the lambda-symbol iff it is not preceded by any >> identifier character and is not followed by a Greek letter" might >> work. > > ??. ... > ??. ... > ?? ?. ... Come to think of it, if you're after math notation, enough Greek letters are used as symbols that it might be necessary to just exclude them from use as letters. (Symbols would be fair game.) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From william.wood3 at comcast.net Thu May 15 01:06:27 2008 From: william.wood3 at comcast.net (Bill) Date: Thu May 15 01:01:29 2008 Subject: [Haskell-cafe] Re: Endianess In-Reply-To: References: <20080509212412.GE24396@scytale.galois.com> <48289421.2070408@btinternet.com> <87ve1ixcrh.fsf@nmd9999.imr.no> <266370AF-E498-42DF-A356-2572A0DDAE70@ece.cmu.edu> Message-ID: <1210827987.4933.2.camel@localhost> On Wed, 2008-05-14 at 20:59 +0200, Henning Thielemann wrote: . . . > Interesting to know what jokes are told about Germans. 8-] So, do English > professors save their prepositions for the end of a lecture? This seems peculiarly apropos: I lately lost a preposition. It hid, I thought, beneath my chair, And angrily I cried "Perdition! Up from out of in under there!" Correctness is my vade mecum And straggling phrases I abhor. Still, I wonder, what should he come Up from out of in under for? - Morris Bishop -- Bill Wood From devriese at cs.tcd.ie Thu May 15 02:04:22 2008 From: devriese at cs.tcd.ie (Edsko de Vries) Date: Thu May 15 01:58:04 2008 Subject: [Haskell-cafe] Re: Monad for HOAS? In-Reply-To: <134sf5-8af.ln1@mantle.rutgers.edu> References: <20080514091117.GA20684@netsoc.tcd.ie> <20080514125958.GA10853@cs.helsinki.fi> <20080514145922.GA2936@netsoc.tcd.ie> <134sf5-8af.ln1@mantle.rutgers.edu> Message-ID: <20080515060422.GA21857@netsoc.tcd.ie> On Wed, May 14, 2008 at 06:01:37PM -0400, Chung-chieh Shan wrote: > Conal Elliott wrote in article in gmane.comp.lang.haskell.cafe: > > I share your perspective, Edsko. If foo and (Let foo id) are > > indistinguishable to clients of your module and are equal with respect to > > your intended semantics of Exp, then I'd say at least this one monad law > > holds. - Conal > > I am at least sympathetic to this perspective, but the Expr constructors > are not as polymorphic as the monad operations: if in > > do a <- foo > return a > > foo has type "ExprM String" (perhaps foo is equal to "return []"), then > we want to generate the DSL expression "Let [] id", but "[]" is not of > type "Expr". Because whenever foo's type is not "ExprM Expr" the above > code using do notation must be exactly equal to foo, by parametricity > even when foo's type is "ExprM Expr" we cannot generate Let. Yes, absolutely. This is the core difficulty in designing the monad, and the reason why I started experimenting with adding a type constructor to Expr data Expr a = One | Add (Expr a) (Expr a) | Let (Expr a) (Expr a -> Expr a) | Place a This is useful regardless, because we can now define catamorphisms over Expr. Nevertheless, I still can't see how to define my monad properly (other than using Lauri's suggestion, which has already improved the readability of my code). Return is now easy (return = Place), and it should be relatively easy to define a join operation Expr (Expr a) -> Expr a *but* since Expr uses HOAS, it is not an instance of Functor and so we cannot use the join operator to define return. Actually, I think this approach is a dead end too, but I'm not 100% sure. Edsko From gale at sefer.org Thu May 15 03:03:43 2008 From: gale at sefer.org (Yitzchak Gale) Date: Thu May 15 02:57:24 2008 Subject: [Haskell-cafe] Richer (than ascii) notation for haskell source? In-Reply-To: References: <93BECC602E286B499D5443ECB850D2FF01331E95@newman.usa.aitgroupad.com> <482B3022.2050303@btinternet.com> <4FD84C61-C940-4B29-A207-D23F8B72D00F@ece.cmu.edu> <482B36EB.6000708@btinternet.com> <72A31F34-22AD-4C81-A450-7463BDA07E86@cs.otago.ac.nz> <535E1E5A-83DA-4D4B-8D24-FA08B3EF0190@ece.cmu.edu> Message-ID: <2608b8a80805150003s4fac9f62hbd98e5242c0ff53b@mail.gmail.com> Brandon S. Allbery KF8NH wrote: > Adjacent different scripts in general is probably a reasonable token > discriminator. A "token" combining LTR and RTL, for example, is just > confusing. So you would like to ban identifiers that contain both letters and digits for those who happen to speak languages whose letters are RTL? I must protest. Regards, Yitz From gale at sefer.org Thu May 15 03:09:34 2008 From: gale at sefer.org (Yitzchak Gale) Date: Thu May 15 03:03:14 2008 Subject: [Haskell-cafe] Richer (than ascii) notation for haskell source? In-Reply-To: <56175B3C-D8B4-4763-BD7A-B45947D2D1DA@ece.cmu.edu> References: <93BECC602E286B499D5443ECB850D2FF01331E95@newman.usa.aitgroupad.com> <482B3022.2050303@btinternet.com> <4FD84C61-C940-4B29-A207-D23F8B72D00F@ece.cmu.edu> <482B36EB.6000708@btinternet.com> <72A31F34-22AD-4C81-A450-7463BDA07E86@cs.otago.ac.nz> <535E1E5A-83DA-4D4B-8D24-FA08B3EF0190@ece.cmu.edu> <1210820232.5514.83.camel@derek-laptop> <56175B3C-D8B4-4763-BD7A-B45947D2D1DA@ece.cmu.edu> Message-ID: <2608b8a80805150009l348e4b70gbf97e1f5ee351f79@mail.gmail.com> Brandon S. Allbery KF8NH wrote: > Come to think of it, if you're after math notation, enough Greek letters are > used as symbols that it might be necessary to just exclude them from use as > letters. While I have not yet noticed anyone from Greece on this list, I don't think it would be appropriate for us to discriminate against Greek speakers as a built-in feature of Haskell. Regards, Yitz From barsoap at web.de Thu May 15 03:25:47 2008 From: barsoap at web.de (Achim Schneider) Date: Thu May 15 03:19:36 2008 Subject: [Haskell-cafe] Re: Richer (than ascii) notation for haskell source? References: <93BECC602E286B499D5443ECB850D2FF01331E95@newman.usa.aitgroupad.com> <482B3022.2050303@btinternet.com> <4FD84C61-C940-4B29-A207-D23F8B72D00F@ece.cmu.edu> <482B36EB.6000708@btinternet.com> <72A31F34-22AD-4C81-A450-7463BDA07E86@cs.otago.ac.nz> <535E1E5A-83DA-4D4B-8D24-FA08B3EF0190@ece.cmu.edu> <1210820232.5514.83.camel@derek-laptop> <56175B3C-D8B4-4763-BD7A-B45947D2D1DA@ece.cmu.edu> <2608b8a80805150009l348e4b70gbf97e1f5ee351f79@mail.gmail.com> Message-ID: <20080515092547.24383f66@solaris> "Yitzchak Gale" wrote: > Brandon S. Allbery KF8NH wrote: > > Come to think of it, if you're after math notation, enough Greek > > letters are used as symbols that it might be necessary to just > > exclude them from use as letters. > > While I have not yet noticed anyone from Greece on this list, > I don't think it would be appropriate for us to discriminate > against Greek speakers as a built-in feature of Haskell. > /me shudders and tries not to remember those occasions when he read code written in french. It's quite akin to decompiled obfuscated Java-code, where you're left with classes say a-j and mostly functions with the name a, discerned by types. Code should be written completely in English, for practical reasons. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. From marlowsd at gmail.com Thu May 15 04:01:22 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Thu May 15 03:55:10 2008 Subject: [Haskell-cafe] Re: GHC API GSoc project In-Reply-To: <025001c8b612$95382390$b0178351@cr3lt> References: <481A46C0.3050209@gmail.com><012e01c8ac61$cc2f0d60$bf078351@cr3lt><4822F24B.4040801@microsoft.com><4824165B.60800@gmail.com><016401c8b224$6b0b5250$5a307ad5@cr3lt> <916b84820805130837s677e2b42jeccb325fdb67e9c@mail.gmail.com> <025001c8b612$95382390$b0178351@cr3lt> Message-ID: <482BEDD2.4060308@gmail.com> Claus, thanks for taking the time to articulate all this, speaking as the mentor for the project this material is invaluable. I'd particularly like to see a wiki page collecting issues, plans and priorities too. My own priority is to have the compilation phases exposed. One (selfish) reason for this is that it will force a number of refactorings and cleanups inside GHC, that we've had on the radar for some time. As soon as there's a wiki page up I can start downloading some of the contents of my whiteboard onto it :-) Keeping track of comments in the parser sounds like a high priority to me, because we have an active customer (Haddock) to drive the design and test it. Another active customer is Yi, as I understand it they are using the GHC API to provide the features we had in Visual Haskell. This will be useful for driving the aspects of the design that IDEs need. Cheers, Simon Claus Reinke wrote: > > thanks, I was wondering about your project. Is there a project > page documenting the issues/tickets you look at, and particularly > the plan of attack as it changes in the face of reality?-) I've found > > http://code.google.com/soc/2008/haskell/appinfo.html?csaid=4189AF2C8AE5E25A > > which covers a lot of ground, and some interesting issues, but > is so general (and design- rather than application-driven) that I've > been worried about how much of it you'll manage (and with which > priorities), given that the GHC API is indeed exposed rather than > designed and may thus interfere with your good intentions in > unexpected ways. > > Also, there are very different user needs out there, some want > just analysis or some information extraction, some want source > transformation capabilities, some want a stable portable hs-plugins > replacement, some want to work with backends, etc. . you can't > please everyone, but until your focus is known, people can't > easily complain about your priorities. > > IMHO, trying to support a semantics- and comment-preserving > roundtrip in (pretty . parse) would be a good way to start (David > says he's going to look at the extracting comments/pragmas part, > but they still need to be put back in during pretty printing). It sounds > simple, and if it is, it will enable a lot more usage of the GHC API; > and if it turns out not to be simple, you'll have a first sign of what > you're up against, and can adjust your expectations!-) > > Making yourself available as you've done here "I'm here; I'm going > to work on this now; please cc me if you want to express your > priorities" sounds like a good way to pull together the many strands > of interests relating to the GHC API. Now we all have to dust off > our old "wouldn't it be nice if the API could do this and that"s. > > Perhaps something similar to what the type family folks are doing > would help: use the ticket tracker for individual issues, have test > cases that demonstrate the issues and their resolution, have more > detailed documents online elsewhere, and a single wiki page to > tie everything together (making it easier to find relevant tickets > and the state of the art). > > [cf http://hackage.haskell.org/trac/ghc/wiki/TypeFunctionsStatus ] > > over the years, quite a few issues have been raised as tickets/ > email/source comments, so collecting them would be a good > way to get an idea of what is needed, deciding which of those > issues would take how much effort would be a first useful > contribution, and seeing which of these you intend to tackle > would give the community at large a better chance to comment > on your priorities in relation to their needs. > > I also hope you are in touch with Chadda? - the port of HaRe > to the GHC API did not make it as a GSoC project, but I > understand he is going to do some work in this direction > anyway. > > Looking forward to an improved GHC API!-) > Claus > > ps. here are some first entries for your list, and for other > interested parties following along (I'd be very interested > to hear about your progress): > > - > http://code.google.com/soc/2008/haskell/appinfo.html?csaid=4189AF2C8AE5E25A > (project outline) > > - http://hackage.haskell.org/trac/ghc/ticket/1467 > (GHC API: expose separate compilation stages; > your main ticket so far?) > > - concerning exposed phases, it would also be useful if > the interface was more uniform (eg., AST, typed AST,..) > > - search for NOTE in ghc/compiler/main/GHC.hs for some > related notes from an earlier GHC/HaRe meeting > > - is it possible to use standalone deriving to get a generic > programming framework over the ASTs without blowing > up GHC's code for its own use (deriving Data, etc.)? > > - http://www.haskell.org/pipermail/haskell-cafe/2008-May/042616.html > (GHC API: how to get the typechecked AST?) > > - http://hackage.haskell.org/trac/ghc/ticket/1886 > (GHC API should preserve and provide access to comments) > > - dynamic loading of Haskell code, ala hs-plugins, but without > the version/platform issues (GHCi has to be able to do this > anyway, but it would be nice to have the ugly bits hidden, > such as unsafeCast#, or whatever it was). that might require > a standard for typeReps, if I recall correctly.. > > - is there a way to reduce version-skew for clients of the GHC > API (currently, there is no stability guaranteed at all, so if you > don't want to live with lots of #ifdefs and breakage, you keep > delaying your fantastic GHC API-base projects "until the dust > settles") > > - I'm sure there have been many more, but that's the problem: > not all these issues have been collected as they were raised; > even if you don't tackle all of them, it would be nice if you > could collect all of them > >> On Fri, May 9, 2008 at 8:30 PM, Claus Reinke >> wrote: >>> >>> >>> > Ah, I didn't think about the GHC options that change the lexical >>> > syntax. You're right, using the GHC lexer should be easier. >>> > >>> >>> and, if you do that, you could also make the GHC lexer >>> squirrel away the comments (including pragmas, if they aren't >>> already in the AST) someplace safe, indexed by, or at least >>> annotated with, >>> their source locations, and make this comment/ >>> pragma storage available via the GHC API. (1a) >>> >>> then, we'd need a way to merge those comments and pragmas >>> back into the output during pretty printing, and we'd have made >>> the first small step towards source-to-source transformations: >>> making code >>> survive semantically intact over (pretty . parse). (1b) >>> >>> that would still not quite fullfill the GHC API comment ticket (*), >>> but that was only a quick sketch, not a definite design. it might be >>> sufficient to let each GHC API client do its own search to associate >>> bits of >>> comment/pragma storage with bits of AST. >>> if i understand you correctly, you are going to do (1a), so >>> if you could add that to the GHC API, we'd only need (1b) >>> to go from useable-for-analysis-and-extraction to >>> useable-for-transformation. >>> >>> is that going to be a problem? >>> >>> claus >>> >>> (*) knowing the source location of some piece of AST is not >>> sufficient for figuring out whether it has any immediately >>> preceding or following comments (there might be other AST >>> fragments in between, closer to the next comment). >>> but, if one knows the nearest comment segment for each piece of AST, >>> one >>> could then build a map where the closest >>> AST pieces are mapped to (Just commentID), and the other >>> AST pieces are mapped to Nothing. >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe@haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe > From gale at sefer.org Thu May 15 04:33:50 2008 From: gale at sefer.org (Yitzchak Gale) Date: Thu May 15 04:27:31 2008 Subject: [Haskell-cafe] Re: Richer (than ascii) notation for haskell source? In-Reply-To: <20080515092547.24383f66@solaris> References: <93BECC602E286B499D5443ECB850D2FF01331E95@newman.usa.aitgroupad.com> <482B36EB.6000708@btinternet.com> <72A31F34-22AD-4C81-A450-7463BDA07E86@cs.otago.ac.nz> <535E1E5A-83DA-4D4B-8D24-FA08B3EF0190@ece.cmu.edu> <1210820232.5514.83.camel@derek-laptop> <56175B3C-D8B4-4763-BD7A-B45947D2D1DA@ece.cmu.edu> <2608b8a80805150009l348e4b70gbf97e1f5ee351f79@mail.gmail.com> <20080515092547.24383f66@solaris> Message-ID: <2608b8a80805150133k23103f54n42d10beff58b63d4@mail.gmail.com> Brandon S. Allbery KF8NH wrote: >>> Come to think of it, if you're after math notation, enough Greek >>> letters are used as symbols that it might be necessary to just >>> exclude them from use as letters. Yitz Gale wrote: >> While I have not yet noticed anyone from Greece on this list, >> I don't think it would be appropriate for us to discriminate >> against Greek speakers as a built-in feature of Haskell. Achim Schneider wrote: > /me shudders and tries not to remember those occasions when he read code > written in french. He he, yes. I've seen C++ written in transliterated Russian, too. Very amusing - as long as I'm not the one who has to debug it. > Code should be written completely in English, for practical reasons. Yes, of course, that's the standard today for software development. But I'm just saying that it would not be a good idea to hard-wire that policy into our language syntax. Just as an example - let's say you want to create an embedded DSL for speakers of a language other than English. The point is that it is always best to keep language syntax as simple as possible, for many reasons. In the case of Unicode, that means staying as close as possible to the spirit of Unicode and minimizing our own ad hoc rules. Adding one more keyword is way simpler than adding a bunch of complex rules to the lexer. A lot less moving parts to break. Especially if those lexer rules are not so consistent with built-in Unicode concepts such as letter and symbol, glyph direction, etc. So I think the best and simplest idea is to make the letter lambda a keyword. True, you need a space after it then. You already need spaces between the variables after the lambda, so anyway you might say that would be more consistent. I always find my thumb hovering indecisively over the space bar when I type a backslash "lambda" in Haskell. Haskell syntax has always been inspired by mathematical notation and reminiscent of it, never identical to it. Regards, Yitz From batterseapower at hotmail.com Thu May 15 04:50:00 2008 From: batterseapower at hotmail.com (Max Bolingbroke) Date: Thu May 15 04:43:43 2008 Subject: [Haskell-cafe] Re: GHC API GSoc project In-Reply-To: <482BEDD2.4060308@gmail.com> References: <4822F24B.4040801@microsoft.com> <4824165B.60800@gmail.com> <016401c8b224$6b0b5250$5a307ad5@cr3lt> <916b84820805130837s677e2b42jeccb325fdb67e9c@mail.gmail.com> <025001c8b612$95382390$b0178351@cr3lt> <482BEDD2.4060308@gmail.com> Message-ID: <9d4d38820805150150m4d5fb066r82637d60eadd2b55@mail.gmail.com> > My own priority is to have the compilation phases exposed. One (selfish) > reason for this is that it will force a number of refactorings and cleanups > inside GHC, that we've had on the radar for some time. As soon as there's a > wiki page up I can start downloading some of the contents of my whiteboard > onto it :-) This aspect is going to affect my own project, GHC plugins. Plugins need to be able to register their own compilation phases and when they should be run with the compiler. A nice way to do this might be to encode the current GHC stage inter-dependencies in code. Plugins could then add their own stages with similar dependency information and finally GHC would compute a topological sort based on the constraints as the actual order in which to run stages. These codified dependencies would complement any documentation based approach. I sketched a very rough idea of what that could look like at http://hackage.haskell.org/trac/ghc/wiki/Plugins (see note [Declarative Core Pass Placement]). I don't have the bandwidth to seriously think about these issues until after exams, but there are other things GHC-API related things that need to happen for plugins: - Expose the Core representation with documentation - Expose and document internal functions for manipulating Core (e.g. CoreUtil, DsUtil) I'm happy to do this work myself, but I need to be sure it's relatively coordinated with Thomas' work and the intentions for the compiler passes so we don't step on each others toes. Cheers, Max From david.waern at gmail.com Thu May 15 04:55:12 2008 From: david.waern at gmail.com (David Waern) Date: Thu May 15 04:48:53 2008 Subject: [Haskell-cafe] GHC API GSoc project (was: ANN: Haddock version 2.1.0) In-Reply-To: <025001c8b612$95382390$b0178351@cr3lt> References: <012e01c8ac61$cc2f0d60$bf078351@cr3lt> <4822F24B.4040801@microsoft.com> <4824165B.60800@gmail.com> <016401c8b224$6b0b5250$5a307ad5@cr3lt> <916b84820805130837s677e2b42jeccb325fdb67e9c@mail.gmail.com> <025001c8b612$95382390$b0178351@cr3lt> Message-ID: 2008/5/15, Claus Reinke : > - is it possible to use standalone deriving to get a generic > programming framework over the ASTs without blowing > up GHC's code for its own use (deriving Data, etc.)? Speaking of generics, I'm working on deriving Data.Traversable for GHC's abstract syntax using the derive package (I should give most credit to Twan here -- he has been modifying the derive package to make this possible). A package of some form that exports these instances should be useful to GHC API clients. David From gale at sefer.org Thu May 15 05:17:43 2008 From: gale at sefer.org (Yitzchak Gale) Date: Thu May 15 05:11:23 2008 Subject: [Haskell-cafe] Two-iteration optimisation (was: GHC Predictability) In-Reply-To: <20080514172045.GA10746@scytale.galois.com> References: <482B1C8C.4060509@cogito.org.uk> <20080514172045.GA10746@scytale.galois.com> Message-ID: <2608b8a80805150217y3da48092uf461160c2c5df961@mail.gmail.com> Don Stewart wrote: > You'd want a general fusion framework for this... > Stream fusion... at least does this for zips... > but for an arbitrary 'f' instead of zip, > seems harder. And of course, you wouldn't want that: f xs = xs : map expensiveCalculation xs Please don't fuse those two loops into one. In the case of "mean", the outer function in question is /, and that is a good candidate for fusion because it is strict in both arguments. I think Don is right. There is a lot of room for expanding the scope of fusion, but it needs to be done one function at a time until our strictness analysis gets better. In the general case, I like the way things work now. The original complaint about "unpredictability" is, in my opinion, a "bug in the documentation". This is yet another concept whose basics need to be made much more accessible to newbies. -Yitz From conor at strictlypositive.org Thu May 15 06:56:48 2008 From: conor at strictlypositive.org (Conor McBride) Date: Thu May 15 06:50:19 2008 Subject: [Haskell-cafe] bottomless Top? Message-ID: Folks [statutory warning: functors, terminal objects, unsafeCoerce] I had a peculiar notion this morning to wonder whether I could get away with shape :: Functor f => f a -> f () shape fa = unsafeCoerce fa Sure enough, ghci gives me *Top> shape "moo" [(),(),()] *Top> shape [undefined] [*** Exception: Prelude.undefined which shows that pattern matching does just enough work to check that an element of () isn't bottom. I'm just wondering if that's really what's happening, what other implementations do, and how the garbage collector would react: would all those a's hang around for as long as the shape? I'm also wondering whether it makes sense to have a "bottomless Top" type, with constructor _ and lazy pattern _ (with (undefined :: Top) equal to _). Then the constant-time shape operator makes the same sort of sense as the constant-time inflate :: Functor f => f Zero -> f a Any thoughts on either or both? Cheers Conor From conor at strictlypositive.org Thu May 15 07:29:48 2008 From: conor at strictlypositive.org (Conor McBride) Date: Thu May 15 07:23:17 2008 Subject: [Haskell-cafe] bottomless Top? In-Reply-To: References: Message-ID: <2A57F9CE-3096-4F96-A016-DEF31999C9FA@strictlypositive.org> Replying slap-foreheadedly to own post... On 15 May 2008, at 11:56, Conor McBride wrote: > Folks > > I'm also wondering whether it makes sense to have a > "bottomless Top" type, with constructor _ and lazy pattern _ > (with (undefined :: Top) equal to _). Then the constant-time > shape operator makes the same sort of sense as the > constant-time > > inflate :: Functor f => f Zero -> f a We've got it already. data One would do, with smart constructor only :: One only = undefined and no other operations, so no way to be strict in its values. It's the lazy version of Zero. Assuming (safely?) that representation of data in each instance of a type constructor is uniform, that means shape :: Functor f => f a -> f One shape = unsafeCoerce should be ok, right? The question about the GC implications of that move still stands, though. Cheers Conor From allbery at ece.cmu.edu Thu May 15 08:24:38 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Thu May 15 08:18:19 2008 Subject: [Haskell-cafe] Richer (than ascii) notation for haskell source? In-Reply-To: <2608b8a80805150003s4fac9f62hbd98e5242c0ff53b@mail.gmail.com> References: <93BECC602E286B499D5443ECB850D2FF01331E95@newman.usa.aitgroupad.com> <482B3022.2050303@btinternet.com> <4FD84C61-C940-4B29-A207-D23F8B72D00F@ece.cmu.edu> <482B36EB.6000708@btinternet.com> <72A31F34-22AD-4C81-A450-7463BDA07E86@cs.otago.ac.nz> <535E1E5A-83DA-4D4B-8D24-FA08B3EF0190@ece.cmu.edu> <2608b8a80805150003s4fac9f62hbd98e5242c0ff53b@mail.gmail.com> Message-ID: <670DAAEF-DD8C-45E8-A472-5D0766FAB484@ece.cmu.edu> On 2008 May 15, at 3:03, Yitzchak Gale wrote: > Brandon S. Allbery KF8NH wrote: >> Adjacent different scripts in general is probably a reasonable token >> discriminator. A "token" combining LTR and RTL, for example, is just >> confusing. > > So you would like to ban identifiers that contain both > letters and digits for those who happen to speak languages > whose letters are RTL? I must protest. Mmmm, more specification needed. Add "letter" to the constraint. (compressing messages) As to your assertion of discrimination against Greek: my point was that mathematical notation *already* discriminates against speakers of Greek by appropriating their alphabet for its own purposes, so if you want to enable a mathematical-notation language mode it's already difficult to support a Greek localization. (I do wonder how modern Greek mathematicians deal with this....) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From allbery at ece.cmu.edu Thu May 15 08:27:52 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Thu May 15 08:21:32 2008 Subject: [Haskell-cafe] Re: Richer (than ascii) notation for haskell source? In-Reply-To: <20080515092547.24383f66@solaris> References: <93BECC602E286B499D5443ECB850D2FF01331E95@newman.usa.aitgroupad.com> <482B3022.2050303@btinternet.com> <4FD84C61-C940-4B29-A207-D23F8B72D00F@ece.cmu.edu> <482B36EB.6000708@btinternet.com> <72A31F34-22AD-4C81-A450-7463BDA07E86@cs.otago.ac.nz> <535E1E5A-83DA-4D4B-8D24-FA08B3EF0190@ece.cmu.edu> <1210820232.5514.83.camel@derek-laptop> <56175B3C-D8B4-4763-BD7A-B45947D2D1DA@ece.cmu.edu> <2608b8a80805150009l348e4b70gbf97e1f5ee351f79@mail.gmail.com> <20080515092547.24383f66@solaris> Message-ID: <5FB5EF73-7B3F-4487-A5EF-E7C757483212@ece.cmu.edu> On 2008 May 15, at 3:25, Achim Schneider wrote: > "Yitzchak Gale" wrote: >> Brandon S. Allbery KF8NH wrote: >>> Come to think of it, if you're after math notation, enough Greek >>> letters are used as symbols that it might be necessary to just >>> exclude them from use as letters. >> >> While I have not yet noticed anyone from Greece on this list, >> I don't think it would be appropriate for us to discriminate >> against Greek speakers as a built-in feature of Haskell. >> > /me shudders and tries not to remember those occasions when he read > code > written in french. So far I've had to deal with: French, Spanish, German, Swedish, Russian (transliterated), Hebrew (transliterated), Arabic (transliterated). I've also dealt with serious spaghetti code (I'm a Perl programmer in my day job, 'nuff said). I'll take the former, thanks. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From allbery at ece.cmu.edu Thu May 15 08:35:43 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Thu May 15 08:29:23 2008 Subject: [Haskell-cafe] Re: Richer (than ascii) notation for haskell source? In-Reply-To: <2608b8a80805150133k23103f54n42d10beff58b63d4@mail.gmail.com> References: <93BECC602E286B499D5443ECB850D2FF01331E95@newman.usa.aitgroupad.com> <482B36EB.6000708@btinternet.com> <72A31F34-22AD-4C81-A450-7463BDA07E86@cs.otago.ac.nz> <535E1E5A-83DA-4D4B-8D24-FA08B3EF0190@ece.cmu.edu> <1210820232.5514.83.camel@derek-laptop> <56175B3C-D8B4-4763-BD7A-B45947D2D1DA@ece.cmu.edu> <2608b8a80805150009l348e4b70gbf97e1f5ee351f79@mail.gmail.com> <20080515092547.24383f66@solaris> <2608b8a80805150133k23103f54n42d10beff58b63d4@mail.gmail.com> Message-ID: On 2008 May 15, at 4:33, Yitzchak Gale wrote: > Brandon S. Allbery KF8NH wrote: >>>> Come to think of it, if you're after math notation, enough Greek >>>> letters are used as symbols that it might be necessary to just >>>> exclude them from use as letters. > > Yitz Gale wrote: >>> While I have not yet noticed anyone from Greece on this list, >>> I don't think it would be appropriate for us to discriminate >>> against Greek speakers as a built-in feature of Haskell. > > Achim Schneider wrote: >> /me shudders and tries not to remember those occasions when he read >> code >> written in french. > > He he, yes. I've seen C++ written in transliterated Russian, too. > Very amusing - as long as I'm not the one who has to debug it. True --- as one of the people who generally gets to fire-test heimdal (http://h5l.org ) and feed back changes, it's always fun to debug those parts where variable names and comments are in Svensk. >> Code should be written completely in English, for practical reasons. > > Yes, of course, that's the standard today for software development. > But I'm just saying that it would not be a good idea to > hard-wire that policy into our language syntax. Suddenly I'm thinking of Lingua::Romana::Perligata.... > I always find my thumb hovering indecisively over the space bar > when I type a backslash "lambda" in Haskell. Come to think of it, I find myself inserting spaces anyway because of emacs' tendency to use backslash as an escape character (and because I'm so used to it being an escaper instead of an active character in its own right). -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From r.kelsall at millstream.com Thu May 15 09:23:21 2008 From: r.kelsall at millstream.com (Richard Kelsall) Date: Thu May 15 09:17:04 2008 Subject: [Haskell-cafe] saner shootout programs In-Reply-To: <1411830730.20080513222207@gmail.com> References: <48282C51.1040706@millstream.com> <4829A16E.9000506@millstream.com> <1881893895.20080513193836@gmail.com> <4829BA34.6070205@millstream.com> <1522825917.20080513200442@gmail.com> <4829C09F.4010205@millstream.com> <1411830730.20080513222207@gmail.com> Message-ID: <482C3949.6070407@millstream.com> Bulat Ziganshin wrote: > Hello Richard, > >> Yes it was just a plausible guess, but not contradicted by the experts. >> And that was using the Windows version of GHC so other versions may >> have better optimisation. I don't know how to check, maybe the experts >> can illuminate the subject? > > note that my letter was not contradicted too LOL > > 1. many experts just don't read this list due to its high traffic, > write into ghc-users instead Good point. I have started a thread here http://www.haskell.org/pipermail/glasgow-haskell-users/2008-May/014742.html > > 2. ghc is too large system and no one know all its details. this > particular option may be set up 10 years ago and never > touched/studied by anyone since then. for example, i'm ghc performance > expert [to some degree], but i don't know anything about its build > system. all that i can tell is that ghc base library build times don't > prohibit use of -O2 > > From graham.fawcett at gmail.com Thu May 15 09:27:38 2008 From: graham.fawcett at gmail.com (Graham Fawcett) Date: Thu May 15 09:21:17 2008 Subject: [Haskell-cafe] Short circuiting and the Maybe monad In-Reply-To: <482A7AF0.6020008@tcs.inf.tu-dresden.de> References: <65113aef0805121509s6b4e76bbxd23e86070a2a0be3@mail.gmail.com> <482A7AF0.6020008@tcs.inf.tu-dresden.de> Message-ID: On Wed, May 14, 2008 at 1:38 AM, Janis Voigtlaender wrote: > Graham Fawcett wrote: >> >> Yes, but that's still a 'quick' short-circuiting. In your example, if >> 'n' is Nothing, then the 'f >>= g >>= h' thunks will not be forced >> (thanks to lazy evaluation), regardless of associativity. Tracing >> verifies this: > > No, it doesn't. What your tracing verifies is that the f, g, and h will > not be evaluated. It doesn't verify that the 'f >>= g >>= h' part of the > expression causes no evaluation overhead. Because that is not true. I didn't mean to suggest that. I confess to using 'the f >>= g >>= h thunks' as a shorthand for the thunks for f, g and h, and not for the binding expressions. I did write later in my message that there would be evaluation overhead, but that I suspected it would be negligible (an imprecise and hand-waving statement, to be sure). > Consider the following: > >> import Debug.Trace > >> data Maybe' a = Nothing' | Just' a deriving Show > >> instance Monad Maybe' where >> return = Just' >> Nothing' >>= _ = trace "match" Nothing' >> Just' a >>= k = k a Neat, I've never seen a bind operator used in a pattern. Thanks for this example. >> talk s = Just' . (trace s) >> f = talk "--f" >> g = talk "--g" >> h = talk "--h" > >> foo n = n >>= f >>= g >>= h > > Now: > > *Main> foo Nothing' > match > match > match > Nothing' > > So you get three pattern-matches on Nothing', where with the associative > variant > >> foo' n = n >>= \a -> f a >>= \b -> g b >>= h > > you get only one: > > *Main> foo' Nothing' > match > Nothing' > > For a way to obtain such improvements automatically, and without > touching the code, you may want to look into > > http://wwwtcs.inf.tu-dresden.de/~voigt/mpc08.pdf Much appreciated, Janis, I look forward to reading the paper. Graham > > Ciao, Janis. > > -- > Dr. Janis Voigtlaender > http://wwwtcs.inf.tu-dresden.de/~voigt/ > mailto:voigt@tcs.inf.tu-dresden.de > From andy.haskell at zambezi.org.uk Thu May 15 09:52:15 2008 From: andy.haskell at zambezi.org.uk (Andy Smith) Date: Thu May 15 09:45:56 2008 Subject: [Haskell-cafe] Re: Richer (than ascii) notation for haskell source? In-Reply-To: <2608b8a80805150133k23103f54n42d10beff58b63d4@mail.gmail.com> References: <93BECC602E286B499D5443ECB850D2FF01331E95@newman.usa.aitgroupad.com> <72A31F34-22AD-4C81-A450-7463BDA07E86@cs.otago.ac.nz> <535E1E5A-83DA-4D4B-8D24-FA08B3EF0190@ece.cmu.edu> <1210820232.5514.83.camel@derek-laptop> <56175B3C-D8B4-4763-BD7A-B45947D2D1DA@ece.cmu.edu> <2608b8a80805150009l348e4b70gbf97e1f5ee351f79@mail.gmail.com> <20080515092547.24383f66@solaris> <2608b8a80805150133k23103f54n42d10beff58b63d4@mail.gmail.com> Message-ID: <5540a5470805150652m6df0d9c6i7f0a3f88ab488787@mail.gmail.com> 2008/5/15 Yitzchak Gale : > So I think the best and simplest idea is to make > the letter lambda a keyword. True, you need a space after it > then. You already need spaces between the variables after the > lambda, so anyway you might say that would be more consistent. You could use a zero width space (U+200B) to preserve the appearance of mathematical notation. I don't know if this is already treated as whitespace but it probably should be. There are also several thin space characters (U+2008 punctuation space, U+2009 thin space, U+200A hair space) that might be better, particularly between variables in a multi-parameter lambda. Andy From olivier.boudry at gmail.com Thu May 15 11:03:02 2008 From: olivier.boudry at gmail.com (Olivier Boudry) Date: Thu May 15 10:56:42 2008 Subject: [Haskell-cafe] FFI: newbie linking problem In-Reply-To: References: <1262278243.20080515014611@gmail.com> Message-ID: Hi all, I found a solution to my linking problem, but it's a bit scary and I'm wondering if there is a simpler way to do this: The solution comes from the following article: http://www.emmestech.com/moron_guides/moron1.html To get ghc to link my dll properly I had to do the following: 1. Create a .def file from the sapnwrfc.lib using pexports.exe: 'pexports sapnwrfc.lib > sapnwrfc.def' 2. Edit the sapnwrfc.def file to add @24 at the end of the function I must call. ... RfcSubmitTransaction RfcTraceTest RfcUTF8ToSAPUC@24 <-- here ... 3. Create a 'sapnwrfc.a' import library using dlltool: 'dlltool --input-def sapnwrfc.def --dllname sapnwrfc.dll --output-lib libsapnwrfc.a -k' Is there a simpler way to do this? Some way of tricking ghc to search for RfcUTF8ToSAPUC instead of RfcUTF8ToSAPUC@24. It looks like ghc/ld/gcc (whoever is responsible) adds a @24 (number depends of args) at the end of the function name when the function is called using stdcall convention. Thanks, Olivier. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080515/12db904b/attachment.htm From nominolo at googlemail.com Thu May 15 11:10:11 2008 From: nominolo at googlemail.com (Thomas Schilling) Date: Thu May 15 11:05:02 2008 Subject: [Haskell-cafe] Re: GHC API GSoc project (was: ANN: Haddock version 2.1.0) In-Reply-To: <025001c8b612$95382390$b0178351@cr3lt> References: <481A46C0.3050209@gmail.com><012e01c8ac61$cc2f0d60$bf078351@cr3lt><4822F24B.4040801@microsoft.com><4824165B.60800@gmail.com><016401c8b224$6b0b5250$5a307ad5@cr3lt> <916b84820805130837s677e2b42jeccb325fdb67e9c@mail.gmail.com> <025001c8b612$95382390$b0178351@cr3lt> Message-ID: <1908C0E3-F53D-4103-A02E-E9A198512668@googlemail.com> Thanks a lot for your comprehensive response, Claus! Per your suggestion, I started a GHC wiki page at http:// hackage.haskell.org/trac/ghc/wiki/GhcApiStatus. I added your comments and I will continue to add more things as I find them. I am closely following the Yi project and I am aware that the HaRe project needs some help from my side. I am interested that both projects become more usable and useful, so I'll be looking forward to concrete requests from both sides. I am also aware of Max's project. We certainly have to look out not to get into each other's ways but as I understand it Max will work on lower-level transformations, while I will concentrate on the front- end. We should therefore be able to keep our work fairly separate. > > thanks, I was wondering about your project. Is there a project > page documenting the issues/tickets you look at, and particularly > the plan of attack as it changes in the face of reality?-) I've found > > http://code.google.com/soc/2008/haskell/appinfo.html? > csaid=4189AF2C8AE5E25A > > which covers a lot of ground, and some interesting issues, but > is so general (and design- rather than application-driven) that I've > been worried about how much of it you'll manage (and with which > priorities), given that the GHC API is indeed exposed rather than > designed and may thus interfere with your good intentions in > unexpected ways. Yes, I tried to comment on this a little on the wiki page. I will also do an internship at MSR beginning in October. The topic isn't decided upon, yet, but working on the GHC API was among the things I proposed. > > Also, there are very different user needs out there, some want > just analysis or some information extraction, some want source > transformation capabilities, some want a stable portable hs-plugins > replacement, some want to work with backends, etc. . you can't > please everyone, but until your focus is known, people can't > easily complain about your priorities. I will start with extracting semantic information from Haskell code. Things that are useful for Yi or HaRe. But if people give good arguments for other features I'd be willing to change priorities. Of course, Simon will have a word there, too. :) > IMHO, trying to support a semantics- and comment-preserving > roundtrip in (pretty . parse) would be a good way to start (David > says he's going to look at the extracting comments/pragmas part, > but they still need to be put back in during pretty printing). It > sounds > simple, and if it is, it will enable a lot more usage of the GHC API; > and if it turns out not to be simple, you'll have a first sign of what > you're up against, and can adjust your expectations!-) I agree. This looks like a good getting-up-to-speed topic. > > Making yourself available as you've done here "I'm here; I'm going > to work on this now; please cc me if you want to express your > priorities" sounds like a good way to pull together the many strands > of interests relating to the GHC API. Now we all have to dust off > our old "wouldn't it be nice if the API could do this and that"s. I'm looking forward to a lot of those responses, and I will try and dig around in the archives to find some of those myself. > / Thomas -- My God's will / becomes me. / When he speaks out, / he speaks through me. / He has needs / like I do. / We both want / to rape you. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080515/401ab1e1/PGP-0001.bin From stansife at caltech.edu Thu May 15 12:25:18 2008 From: stansife at caltech.edu (Eric Stansifer) Date: Thu May 15 12:18:59 2008 Subject: [Haskell-cafe] Richer (than ascii) notation for haskell source? In-Reply-To: <670DAAEF-DD8C-45E8-A472-5D0766FAB484@ece.cmu.edu> References: <93BECC602E286B499D5443ECB850D2FF01331E95@newman.usa.aitgroupad.com> <4FD84C61-C940-4B29-A207-D23F8B72D00F@ece.cmu.edu> <482B36EB.6000708@btinternet.com> <72A31F34-22AD-4C81-A450-7463BDA07E86@cs.otago.ac.nz> <535E1E5A-83DA-4D4B-8D24-FA08B3EF0190@ece.cmu.edu> <2608b8a80805150003s4fac9f62hbd98e5242c0ff53b@mail.gmail.com> <670DAAEF-DD8C-45E8-A472-5D0766FAB484@ece.cmu.edu> Message-ID: <2e58fd390805150925u56945f21mb24e5fd3ed363e16@mail.gmail.com> > As to your assertion of discrimination against Greek: my point was that > mathematical notation *already* discriminates against speakers of Greek by > appropriating their alphabet for its own purposes, so if you want to enable > a mathematical-notation language mode it's already difficult to support a > Greek localization. (I do wonder how modern Greek mathematicians deal with > this....) This made me curious... so hunting around on the internet I found: http://el.wikipedia.org/wiki/%CE%8C%CF%81%CE%B9%CE%BF which, although almost the same as mathematics in English (notice 'epsilon' being used in the same sense), uses 'nu' as a variable to index over the integers, and 'lambda' as a upper/lower bound. Also I found a list of abstracts (mixture of English and Greek): http://users.uoa.gr/~apgiannop/pcma08/program-print.pdf which again looks almost the same as English mathematics (especially when they write it in English), although it seems like 'lambda' is being used as a variable with rather high frequency. Eric From barsoap at web.de Thu May 15 13:27:57 2008 From: barsoap at web.de (Achim Schneider) Date: Thu May 15 13:21:50 2008 Subject: [Haskell-cafe] Re: Endianess References: <20080509212412.GE24396@scytale.galois.com> <48289421.2070408@btinternet.com> <87ve1ixcrh.fsf@nmd9999.imr.no> <20080513191102.GA11402@brakk.ethz <482B30CB.7080607@imageworks.com> <023a01c8b607$6dba95b0$b0178351@cr3lt> Message-ID: <20080515192757.29f35759@solaris> "Claus Reinke" wrote: > then again, Jane Austen was happy enough writing about her > characters not being "one and twenty", so perhaps that is just a > lost art?-) > I'm quite content as long as I'm not "four twenty nineteen". -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. From olivier.boudry at gmail.com Thu May 15 13:40:34 2008 From: olivier.boudry at gmail.com (Olivier Boudry) Date: Thu May 15 13:34:14 2008 Subject: [Haskell-cafe] runInteractiveCommand: program ends before writing or reading all the output Message-ID: Hi all, It's the first time I use the runInteractiveCommand and I was probably bitten by laziness. When I run the following program and send its output to a file using '>' redirection I get the full output of the called process. But if I run it in the console I get only half of the output. As console is slower than disk I assume the called process terminates before all data has been read from it or the main process terminates before data has been written to stdout. I thought using waitForProcess, closing called process output and flushing stdout would solve the problem but it doesn't. > -- Compile with -threaded option > module Main where > > import Control.Concurrent (forkIO) > import System.Environment (getArgs) > import System.FilePath (dropExtension, takeFileName) > import System.IO (Handle, hClose, hFlush, hGetContents, stdout) > import System.Process (runInteractiveCommand, waitForProcess) > > main :: IO () > main = do > (file:_) <- getArgs > (_, out, _, pid) <- runInteractiveCommand $ "dumpbin /EXPORTS " ++ file > forkIO (createDefFile file out) > waitForProcess pid > hClose out > hFlush stdout > > createDefFile :: String -> Handle -> IO () > createDefFile file inp = do > putStrLn $ "LIBRARY " ++ (dropExtension . takeFileName) file ++ ".dll" > putStrLn "EXPORTS" > text <- hGetContents inp > mapM_ writeExport $ keepExports $ map words $ lines text > where > keepExports :: [[String]] -> [String] > keepExports = map head > . filter (not . null) > . takeWhile (["Summary"]/=) > . drop 1 > . dropWhile (["ordinal","name"]/=) > writeExport ('_':xs) = putStrLn xs > writeExport xs = putStrLn xs Any idea regarding the cause of this problem? Thanks, Olivier. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080515/f8360f17/attachment.htm From philip.weaver at gmail.com Thu May 15 13:54:17 2008 From: philip.weaver at gmail.com (Philip Weaver) Date: Thu May 15 13:47:57 2008 Subject: [Haskell-cafe] runInteractiveCommand: program ends before writing or reading all the output In-Reply-To: References: Message-ID: 2008/5/15 Olivier Boudry : > Hi all, > > It's the first time I use the runInteractiveCommand and I was probably > bitten by laziness. > > When I run the following program and send its output to a file using '>' > redirection I get the full output of the called process. But if I run it in > the console I get only half of the output. As console is slower than disk I > assume the called process terminates before all data has been read from it > or the main process terminates before data has been written to stdout. I > thought using waitForProcess, closing called process output and flushing > stdout would solve the problem but it doesn't. > >> -- Compile with -threaded option >> module Main where >> >> import Control.Concurrent (forkIO) >> import System.Environment (getArgs) >> import System.FilePath (dropExtension, takeFileName) >> import System.IO (Handle, hClose, hFlush, hGetContents, stdout) >> import System.Process (runInteractiveCommand, waitForProcess) >> >> main :: IO () >> main = do >> (file:_) <- getArgs >> (_, out, _, pid) <- runInteractiveCommand $ "dumpbin /EXPORTS " ++ file >> forkIO (createDefFile file out) >> waitForProcess pid >> hClose out >> hFlush stdout >> >> createDefFile :: String -> Handle -> IO () >> createDefFile file inp = do >> putStrLn $ "LIBRARY " ++ (dropExtension . takeFileName) file ++ ".dll" >> putStrLn "EXPORTS" >> text <- hGetContents inp >> mapM_ writeExport $ keepExports $ map words $ lines text >> where >> keepExports :: [[String]] -> [String] >> keepExports = map head >> . filter (not . null) >> . takeWhile (["Summary"]/=) >> . drop 1 >> . dropWhile (["ordinal","name"]/=) >> writeExport ('_':xs) = putStrLn xs >> writeExport xs = putStrLn xs > > Any idea regarding the cause of this problem? > I think I've encountered the same problem several times, and it was because I was reading from the handle lazily, like this: (_, out, _, pid) <- runInteractiveProcess ... str <- hGetContents out waitForProcess pid But I didn't use 'str' until after the process finishes. My solution was to use strict IO, usually by replacing String with a strict ByteString. I hear there is now a library that lets you do strict IO with Strings.... Hope this helps. > Thanks, > > Olivier. > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From dons at galois.com Thu May 15 14:31:32 2008 From: dons at galois.com (Don Stewart) Date: Thu May 15 14:25:14 2008 Subject: [Haskell-cafe] Write Haskell as fast as C. [Was: Re: GHC predictability] Message-ID: <20080515183132.GD31635@scytale.galois.com> > I offer up the following example: > > mean xs = sum xs / length xs > > Now try, say, "mean [1.. 1e9]", and watch GHC eat several GB of RAM. (!!) > > If we now rearrange this to > > mean = (\(s,n) -> s / n) . foldr (\x (s,n) -> let s' = s+x; n' = n+1 > in s' `seq` n' `seq` (s', n')) (0,0) > > and run the same example, and watch it run in constant space. > > Of course, the first version is clearly readable, while the second one > is almost utterly incomprehensible, especially to a beginner. (It's even > more fun that you need all those seq calls in there to make it work > properly.) > > The sad fact is that if you just write something in Haskell in a nice, > declarative style, then roughly 20% of the time you get good > performance, and 80% of the time you get laughably poor performance. I've written an extended post on how to understand and reliably optimise code like this, looking at it all the way down to the assembly. The result are some simple rules to follow for generated code as good as gcc -O2. Enjoy, http://cgi.cse.unsw.edu.au/~dons/blog/2008/05/16#fast -- Don From oddron at gmail.com Thu May 15 14:42:31 2008 From: oddron at gmail.com (Ronald Guida) Date: Thu May 15 14:36:11 2008 Subject: [Haskell-cafe] runInteractiveCommand: program ends before writing or reading all the output In-Reply-To: References: Message-ID: <62728db30805151142y7e67efa9xd7581c5b14a13416@mail.gmail.com> It looks like a simple race condition to me. You are using "waitForProcess pid" to wait for runInteractiveCommand to finish, but you don't seem to have anything that waits for createDefFile to finish. > main :: IO () > main = do > (file:_) <- getArgs > (_, out, _, pid) <- runInteractiveCommand $ "dumpbin /EXPORTS " ++ file > forkIO (createDefFile file out) > waitForProcess pid > hClose out > hFlush stdout From philip.weaver at gmail.com Thu May 15 14:54:10 2008 From: philip.weaver at gmail.com (Philip Weaver) Date: Thu May 15 14:47:49 2008 Subject: [Haskell-cafe] runInteractiveCommand: program ends before writing or reading all the output In-Reply-To: <62728db30805151142y7e67efa9xd7581c5b14a13416@mail.gmail.com> References: <62728db30805151142y7e67efa9xd7581c5b14a13416@mail.gmail.com> Message-ID: On Thu, May 15, 2008 at 11:42 AM, Ronald Guida wrote: > It looks like a simple race condition to me. You are using > "waitForProcess pid" to wait for runInteractiveCommand to finish, but > you don't seem to have anything that waits for createDefFile to > finish. > Whoops, sorry, I didn't read the original post closely enough. >> main :: IO () >> main = do >> (file:_) <- getArgs >> (_, out, _, pid) <- runInteractiveCommand $ "dumpbin /EXPORTS " ++ file >> forkIO (createDefFile file out) >> waitForProcess pid >> hClose out >> hFlush stdout > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From moonlite at dtek.chalmers.se Thu May 15 14:56:51 2008 From: moonlite at dtek.chalmers.se (Mattias Bengtsson) Date: Thu May 15 14:53:42 2008 Subject: [Haskell-cafe] Write Haskell as fast as C. [Was: Re: GHC predictability] In-Reply-To: <20080515183132.GD31635@scytale.galois.com> References: <20080515183132.GD31635@scytale.galois.com> Message-ID: <1210877811.9928.4.camel@localhost.localdomain> On Thu, 2008-05-15 at 11:31 -0700, Don Stewart wrote: > I've written an extended post on how to understand and reliably optimise > code like this, looking at it all the way down to the assembly. > > The result are some simple rules to follow for generated code as good > as gcc -O2. > > Enjoy, > > http://cgi.cse.unsw.edu.au/~dons/blog/2008/05/16#fast A good read. Side point: Is the name "go" part of the idiom you mentioned? I sometimes use the same practise but usually just calls the worker the same as the real function with an added prime ('). -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080515/f064984e/attachment.bin From olivier.boudry at gmail.com Thu May 15 15:06:19 2008 From: olivier.boudry at gmail.com (Olivier Boudry) Date: Thu May 15 14:59:59 2008 Subject: [Haskell-cafe] runInteractiveCommand: program ends before writing or reading all the output In-Reply-To: <62728db30805151142y7e67efa9xd7581c5b14a13416@mail.gmail.com> References: <62728db30805151142y7e67efa9xd7581c5b14a13416@mail.gmail.com> Message-ID: On Thu, May 15, 2008 at 2:42 PM, Ronald Guida wrote: > It looks like a simple race condition to me. You are using > "waitForProcess pid" to wait for runInteractiveCommand to finish, but > you don't seem to have anything that waits for createDefFile to > finish. > Thanks Ronald, As I could not find a function to wait on a ThreadId I used a MVar to synchronize both threads. > sync <- newEmptyMVar > forkIO (createDefFile sync file out) > waitForProcess pid > takeMVar sync and at the end of the forked thread: > putMVar sync () Is this normal or have I missed the `waitOnThreadId` function? Thanks for all the comments received on this thread, Olivier. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080515/55036527/attachment.htm From mail at philip.in-aachen.net Thu May 15 15:18:35 2008 From: mail at philip.in-aachen.net (=?ISO-8859-15?Q?Philip_M=FCller?=) Date: Thu May 15 15:12:15 2008 Subject: [Haskell-cafe] getting output from shell commands Message-ID: <482C8C8B.4010900@philip.in-aachen.net> Hi, I would like to be able to run a shell command like curl and process the output in my Haskell program, but I couldn't find anything helpful about it. Something like main = do args <- getArgs inp <- exec "curl" args putStrLn (processInput inp) would be very helpful. Regards Philip From bulat.ziganshin at gmail.com Thu May 15 15:17:55 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu May 15 15:12:24 2008 Subject: [Haskell-cafe] runInteractiveCommand: program ends before writing or reading all the output In-Reply-To: References: <62728db30805151142y7e67efa9xd7581c5b14a13416@mail.gmail.com> Message-ID: <9510019774.20080515231755@gmail.com> Hello Olivier, Thursday, May 15, 2008, 11:06:19 PM, you wrote: > As I could not find a function to wait on a ThreadId I used a MVar to synchronize both threads. > Is this normal or have I missed the `waitOnThreadId` function? yes, it's common idiom -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From jeff.polakow at db.com Thu May 15 15:23:48 2008 From: jeff.polakow at db.com (Jeff Polakow) Date: Thu May 15 15:17:32 2008 Subject: [Haskell-cafe] getting output from shell commands In-Reply-To: <482C8C8B.4010900@philip.in-aachen.net> Message-ID: Hello, > I would like to be able to run a shell command like curl and process the > output in my Haskell program, but I couldn't find anything helpful about it. > Try looking in System.Process. runInteractiveProcess should work for you. -Jeff --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080515/d0f1602e/attachment.htm From olivier.boudry at gmail.com Thu May 15 15:37:25 2008 From: olivier.boudry at gmail.com (Olivier Boudry) Date: Thu May 15 15:31:04 2008 Subject: [Haskell-cafe] getting output from shell commands In-Reply-To: <482C8C8B.4010900@philip.in-aachen.net> References: <482C8C8B.4010900@philip.in-aachen.net> Message-ID: Hi Philip, I just asked a question to the list about using runInteractiveCommand. You may find the code useful but will need to either remove the forkIO instruction or synchronize the two threads using a MVar to avoid the concurrency problem I had. You'll find the thread here: http://www.haskell.org/pipermail/haskell-cafe/2008-May/042975.html Regards, Olivier. On Thu, May 15, 2008 at 3:18 PM, Philip M?ller wrote: > Hi, > > I would like to be able to run a shell command like curl and process the > output in my Haskell program, but I couldn't find anything helpful about it. > > Something like > > main = do > args <- getArgs > inp <- exec "curl" args > putStrLn (processInput inp) > > would be very helpful. > > Regards > Philip > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080515/294eb003/attachment.htm From qdunkan at gmail.com Thu May 15 15:42:35 2008 From: qdunkan at gmail.com (Evan Laforge) Date: Thu May 15 15:36:14 2008 Subject: [Haskell-cafe] Write Haskell as fast as C. [Was: Re: GHC predictability] In-Reply-To: <1210877811.9928.4.camel@localhost.localdomain> References: <20080515183132.GD31635@scytale.galois.com> <1210877811.9928.4.camel@localhost.localdomain> Message-ID: <2518b95d0805151242o5adcf605y96fe509cc0629d48@mail.gmail.com> > Side point: Is the name "go" part of the idiom you mentioned? I > sometimes use the same practise but usually just calls the worker the > same as the real function with an added prime ('). I like to use "go" or the name of the function with _ prepended. For threading state type things outside of a monad, I generally use numbers "let state2 = f state1". I know the prime is conventional, but it's such a tiny mark on a symbol that's otherwise identical I tend to lose it accidentally, leading to type errors for the first, or either bus errors or silently doing the wrong thing for the second (fortunately ghc's unused variable check has always caught that, but I did spend some time thinking the bus error was c++'s fault...). If the "accumulator" function has the same signature as the "wrapper" you can also get silently wrong behaviour by recursing to the wrong function. It's probably harder to do that with 'go' than with a prime. From barsoap at web.de Thu May 15 16:03:15 2008 From: barsoap at web.de (Achim Schneider) Date: Thu May 15 15:57:10 2008 Subject: [Haskell-cafe] Re: Write Haskell as fast as C. [Was: Re: GHC predictability] References: <20080515183132.GD31635@scytale.galois.com> Message-ID: <20080515220315.168cd756@solaris> Don Stewart wrote: > http://cgi.cse.unsw.edu.au/~dons/blog/2008/05/16#fast > Can you put this on the wiki, with the title "An example of how Haskell executes programs", right next to the "Haskell for C programmers" tutorial? It's really helpful for people who are more or less used to think in assembly while writing C. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. From darrinth at gmail.com Thu May 15 16:45:05 2008 From: darrinth at gmail.com (Darrin Thompson) Date: Thu May 15 16:38:45 2008 Subject: [Haskell-cafe] Write Haskell as fast as C. [Was: Re: GHC predictability] In-Reply-To: <20080515183132.GD31635@scytale.galois.com> References: <20080515183132.GD31635@scytale.galois.com> Message-ID: On Thu, May 15, 2008 at 2:31 PM, Don Stewart wrote: > I've written an extended post on how to understand and reliably optimise > code like this, looking at it all the way down to the assembly. > That is a _fabulous_ article. I'm looking forward to the HOF installment. -- Darrin From andrewcoppin at btinternet.com Thu May 15 16:45:32 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Thu May 15 16:38:57 2008 Subject: [Haskell-cafe] Two-iteration optimisation (was: GHC Predictability) In-Reply-To: <2608b8a80805150217y3da48092uf461160c2c5df961@mail.gmail.com> References: <482B1C8C.4060509@cogito.org.uk> <20080514172045.GA10746@scytale.galois.com> <2608b8a80805150217y3da48092uf461160c2c5df961@mail.gmail.com> Message-ID: <482CA0EC.8010106@btinternet.com> Yitzchak Gale wrote: > > > And of course, you wouldn't want that: > > f xs = xs : map expensiveCalculation xs > > Please don't fuse those two loops into one. > ...doesn't type check. Did you mean (++)? > In the case of "mean", the outer function in question > is /, and that is a good candidate for fusion because > it is strict in both arguments. > > I think Don is right. There is a lot of room for expanding > the scope of fusion, but it needs to be done one function > at a time until our strictness analysis gets better. > Mmm, strictnes analysis. That sounds hard... > In the general case, I like the way things work now. The original > complaint about "unpredictability" is, in my opinion, > a "bug in the documentation". This is yet another concept > whose basics need to be made much more accessible to > newbies. > ...which is really the point I was trying to get across, yes. :-) Certainly there are experts [like Don] who seemingly have no trouble knocking out blindingly fast Haskell code. The problem is that only the halowed experts can do this; it's currently rather inaccessible to beginners and intermediates. For example, back when I really *was* a beginner, I found several fleeting references to "laziness can be bad sometimes", but I couldn't find anywhere that explains *why*. The concept that laziness could be something you *don't* want seemed highly counter-intuitive. [After all, laziness is this wonderful thing that stops you doing extra work you don't need to!] Indeed, it wasn't until I wrote a Haskell interpretter that I discovered the [main] problem - huge unevaluated expressions being needlessly dragged around. The fact that laziness is bad sometimes is a pretty basic piece of information for anybody remotely serious about performance programming to be made aware of. I think the information is out there, it's just not tefficially "findable" right now. I'm not 100% sure what the best way to improve this situation would be, but I think it involves somebody somewhere sitting down to write a single, coherant account from beginning to end explaining what the issues are, in language that people who aren't compiler designers can understand. From dons at galois.com Thu May 15 16:56:01 2008 From: dons at galois.com (Don Stewart) Date: Thu May 15 16:49:45 2008 Subject: [Haskell-cafe] Write Haskell as fast as C. [Was: Re: GHC predictability] In-Reply-To: <1210877811.9928.4.camel@localhost.localdomain> References: <20080515183132.GD31635@scytale.galois.com> <1210877811.9928.4.camel@localhost.localdomain> Message-ID: <20080515205601.GI31635@scytale.galois.com> moonlite: > On Thu, 2008-05-15 at 11:31 -0700, Don Stewart wrote: > > I've written an extended post on how to understand and reliably optimise > > code like this, looking at it all the way down to the assembly. > > > > The result are some simple rules to follow for generated code as good > > as gcc -O2. > > > > Enjoy, > > > > http://cgi.cse.unsw.edu.au/~dons/blog/2008/05/16#fast > > A good read. > > Side point: Is the name "go" part of the idiom you mentioned? I > sometimes use the same practise but usually just calls the worker the > same as the real function with an added prime ('). I moved away from that idiom as it was too easy to call the wrapper by accident, by leaving off a prime. In large libraries, I sometimes add the wrapper name to the 'go', so I can find it in the core later, e.g. f x y = go_f 0 where go_f .. -- Don From andrewcoppin at btinternet.com Thu May 15 16:57:07 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Thu May 15 16:50:30 2008 Subject: [Haskell-cafe] Write Haskell as fast as C. [Was: Re: GHC predictability] In-Reply-To: <1210877811.9928.4.camel@localhost.localdomain> References: <20080515183132.GD31635@scytale.galois.com> <1210877811.9928.4.camel@localhost.localdomain> Message-ID: <482CA3A3.2040004@btinternet.com> Mattias Bengtsson wrote: > A good read. > With Don, it usually is. ;-) > Side point: Is the name "go" part of the idiom you mentioned? I > sometimes use the same practise but usually just calls the worker the > same as the real function with an added prime ('). > I usually use "work". Same difference. :-) From what I can tell, the Prelude implementation in the Haskell Report uses primes on the function names [in the tiny number of cases where a worker function is actually required]. Each to their own... From duncan.coutts at worc.ox.ac.uk Thu May 15 18:05:53 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu May 15 17:57:43 2008 Subject: [Haskell-cafe] Fun with Darcs In-Reply-To: <259058831.20080515010114@gmail.com> References: <93BECC602E286B499D5443ECB850D2FF01331E95@newman.usa.aitgroupad.com> <482B3022.2050303@btinternet.com> <482B38FC.2000705@btinternet.com> <482B3F91.7050602@btinternet.com> <20080514201346.GP8845@darcs.net> <482B505C.3020300@btinternet.com> <259058831.20080515010114@gmail.com> Message-ID: <1210889153.5824.137.camel@localhost> On Thu, 2008-05-15 at 01:01 +0400, Bulat Ziganshin wrote: > Hello Andrew, > > Thursday, May 15, 2008, 12:49:32 AM, you wrote: > > > touch. Now, let's see what this IDE actually looks li-- oh you have GOT > > to be KIDDING me! It can't find the right GTK DLL?!? > > gtk2hs includes *developer* gtk2 environment. Which includes all the runtime dlls. > while it should work fine (as far as it's in your path), you may try > to install *runtime* gtk2 environment from > http://sourceforge.net/project/showfiles.php?group_id=71914&package_id=255391 I would not recommend that. I'd use the dlls that come with gtk2hs. Of course if you're deploying a Windows program that uses gtk2hs then using just the runtime dlls is just the right thing to do. Though for that case we provide the runtime dlls: http://haskell.org/gtk2hs/win32/ As an example, here's an installer for a standalone prog that uses gtk2hs but doesn't need ghc or gtk2hs to be installed already: http://haskell.org/~duncan/gtk2hs/LSystemSetup.exe Duncan From duncan.coutts at worc.ox.ac.uk Thu May 15 18:10:20 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu May 15 18:02:06 2008 Subject: [Haskell-cafe] Fun with Darcs In-Reply-To: <482B505C.3020300@btinternet.com> References: <93BECC602E286B499D5443ECB850D2FF01331E95@newman.usa.aitgroupad.com> <482B3022.2050303@btinternet.com> <482B38FC.2000705@btinternet.com> <482B3F91.7050602@btinternet.com> <20080514201346.GP8845@darcs.net> <482B505C.3020300@btinternet.com> Message-ID: <1210889420.5824.142.camel@localhost> On Wed, 2008-05-14 at 21:49 +0100, Andrew Coppin wrote: > At this point, my best guess is that the unofficial Gtk2hs binary is > broken somehow. [Although I don't recall hearing anybody yelling about > it...] Maybe tomorrow I'll try again on my other box that has an older > GHC on it and see how that goes. For tonight, I'm just too frustrated to > continue. Is this the "unofficial" Gtk2Hs installer you were using? http://haskell.org/~duncan/gtk2hs/gtk2hs-0.9.12.1.exe I've been told it works ok. If you've only just installed it then you do need to start a new command shell because existing open shells do not pick up the change to the environment variables. You can double check that Gtk2Hs installed ok by cd'ing to one of the demo directories and using ghc --make to build a demo. If then demo .exe runs ok then the dlls are on the %PATH%. If that fails, you can double check your user %PATH% and make sure it does have an entry that points to the Gtk2Hs/bin dir. The Gtk2Hs installer only sets the %PATH% for the user that ran the installer, not globally for every user. I hope you can get it working. Duncan From duncan.coutts at worc.ox.ac.uk Thu May 15 18:23:52 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu May 15 18:15:38 2008 Subject: [Haskell-cafe] runInteractiveCommand: program ends before writing or reading all the output In-Reply-To: References: Message-ID: <1210890232.5824.153.camel@localhost> On Thu, 2008-05-15 at 13:40 -0400, Olivier Boudry wrote: > Hi all, > > It's the first time I use the runInteractiveCommand and I was probably > bitten by laziness. Yes. I think Philip diagnosed the problem correctly. As an example let me show you as an example how we use it in Cabal: rawSystemStdout :: Verbosity -> FilePath -> [String] -> IO String rawSystemStdout verbosity path args = do Exception.bracket (runInteractiveProcess path args Nothing Nothing) (\(inh,outh,errh,_) -> hClose inh >> hClose outh >> hClose errh) $ \(_,outh,errh,pid) -> do -- We want to process the output as text. hSetBinaryMode outh False -- fork off a thread to pull on (and discard) the stderr -- so if the process writes to stderr we do not block. -- NB. do the hGetContents synchronously, otherwise the outer -- bracket can exit before this thread has run, and hGetContents -- will fail. err <- hGetContents errh forkIO $ do evaluate (length err); return () -- wait for all the output output <- hGetContents outh evaluate (length output) -- wait for the program to terminate exitcode <- waitForProcess pid -- on failure, throw the exit code as an exception unless (exitCode == ExitSuccess) $ exitWith exitCode return (output, exitcode) So as you can see there are two subtleties. One is the issue that we have to make sure we get all the output before we wait for the program to finish. Using evaluate is the trick there. The other is that we also have to pull on the stderr of the process. Otherwise the process may be trying to output to stderr but if the pipe buffer fills up then writing to stderr will block and so it will not be able to continue writing to stdout we'll have deadlocked the process. So we have to forkIO a thread to pull on stderr. This is one reason that runInteractiveProcess is hard to use and especially hard to use portably due to the use of preemptable threads. It would be possible to do without threads if we used non-blocking IO and interleaved between reading from stdout and stderr. Duncan From ok at cs.otago.ac.nz Thu May 15 18:39:51 2008 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Thu May 15 18:33:34 2008 Subject: [Haskell-cafe] Re: Richer (than ascii) notation for haskell source? In-Reply-To: <2608b8a80805150133k23103f54n42d10beff58b63d4@mail.gmail.com> References: <93BECC602E286B499D5443ECB850D2FF01331E95@newman.usa.aitgroupad.com> <482B36EB.6000708@btinternet.com> <72A31F34-22AD-4C81-A450-7463BDA07E86@cs.otago.ac.nz> <535E1E5A-83DA-4D4B-8D24-FA08B3EF0190@ece.cmu.edu> <1210820232.5514.83.camel@derek-laptop> <56175B3C-D8B4-4763-BD7A-B45947D2D1DA@ece.cmu.edu> <2608b8a80805150009l348e4b70gbf97e1f5ee351f79@mail.gmail.com> <20080515092547.24383f66@solaris> <2608b8a80805150133k23103f54n42d10beff58b63d4@mail.gmail.com> Message-ID: <0DC975CE-E825-4900-9659-BA094961C295@cs.otago.ac.nz> On 15 May 2008, at 8:33 pm, Yitzchak Gale wrote: > The point is that it is always best to keep language syntax > as simple as possible, for many reasons. In the case of Unicode, > that means staying as close as possible to the spirit of Unicode and > minimizing our own ad hoc rules. In particular, Unicode has explicit guidance about what an identifier should be, in UAX#31: http://www.unicode.org/reports/tr31/tr31-9.html I've only recently started slogging my way through the capital-city-telephone-book-size Unicode 5.0 book. (I was tolerably current to 4.0) Imagine my stress levels on discovering that Unicode 5.1 is already out, with another "1,624 newly encoded characters", including a capital letter version of "?". It is deeply ironic that one of the things that keeps changing is the stability policy. Another of the things that has changed is UAX#31. > Adding one more > keyword is way simpler than adding a bunch of complex > rules to the lexer. Um, there's no way a Haskell lexer is going to comply with the Unicode rules without a fair bit of complexity. The basic idea is simply *, but there are rules about when ZWJ and ZWNJ are allowed. The real issue here is Unicode compliance, and the Unicode rules say that a mixture of scripts is OK. Er, it's not actually that simple. They do recommend that the scripts in table 4 _not_ be allowed in identifiers, so if you fancied writing some of your identifiers in Shavian, you may or may not be out of luck. (Just why a Coptic priest who is also a coder should be discouraged from using the Coptic script in his programs escapes me.) > A lot less moving parts to break. > Especially if those lexer rules are not so consistent with > built-in Unicode concepts such as letter and symbol, glyph > direction, etc. UAX#31 definitely allows identifiers with any mixture of left to right and right to left characters. The *intent* is that anything even remotely reasonable should be accepted, and should keep on being accepted, but of course the devil is in the details. > > So I think the best and simplest idea is to make > the letter lambda a keyword. The lambda that people actually *want* in Haskell is in fact the >mathematical< small letter lambda, not the Greek letter. UAX#31 explicitly envisages "mathematically oriented programming languages that make distinctive use of the Mathematical Alphanumeric Symbols". I don't think there can be much argument about this being the right way to encode the symbol used in typeset versions of Haskell. There are three arguments against using it routinely: (a) It is outside the 16-bit range that Java is happy with, making it hard to write Haskell tools in Java. But then, about 40% of the characters in Unicode are now outside the 16-bit range that Java is comfortable with, which is just too bad for Java. Haskell tools should be written in Haskell, and should cope with 20-bit characters. (I used to say 21- bit, but Unicode 5 promises never to go beyond 16 planes.) (b) It is outside the range of characters currently available in fonts. A character you cannot type or see isn't much use. Implementations *will* catch up, but what do we do now? (c) People *can* type a Greek small letter now, and will not be interested in making fine distinctions between characters that look pretty much the same. So people will *expect* the Greek letter to work, even if a pedant like me says it's the wrong character. Of course, we could always take an upside down lambda and put some bars through it and use ? for lambda. (Pop quiz: why would some people not be surprised to see this instead of \ ?) [It's a joke.] All of this seems to leave Greek small letter lambda as a keyword as being the simplest solution, but it's easy to predict that it will cause confusion. > True, you need a space after it > then. You already need spaces between the variables after the > lambda, so anyway you might say that would be more consistent. Who says there is more than one variable? \(x,y,z)-> doesn't have any spaces. \x -> \y -> \z -> needs spaces, but that's because ->\ is a single token, not because of the identifiers. -- "I don't want to discuss evidence." -- Richard Dawkins, in an interview with Rupert Sheldrake. (Fortean times 232, p55.) From jonathanccast at fastmail.fm Thu May 15 20:13:26 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Thu May 15 20:07:09 2008 Subject: [Haskell-cafe] bottomless Top? In-Reply-To: <2A57F9CE-3096-4F96-A016-DEF31999C9FA@strictlypositive.org> References: <2A57F9CE-3096-4F96-A016-DEF31999C9FA@strictlypositive.org> Message-ID: <3F77A68B-BA5B-43A0-A252-5E63506C84F6@fastmail.fm> On 15 May 2008, at 4:29 AM, Conor McBride wrote: > Replying slap-foreheadedly to own post... > > On 15 May 2008, at 11:56, Conor McBride wrote: > >> Folks >> >> I'm also wondering whether it makes sense to have a >> "bottomless Top" type, with constructor _ and lazy pattern _ >> (with (undefined :: Top) equal to _). Then the constant-time >> shape operator makes the same sort of sense as the >> constant-time >> >> inflate :: Functor f => f Zero -> f a > > We've got it already. > > data One > > would do, with smart constructor > > only :: One > only = undefined As I've mentioned before, my favorite data type newtype One = One One does the same, and stays in Haskell 98. (And has the same weakness to seq: (`seq` ()) is perfectly strict (it's const undefined)). jcc From olivier.boudry at gmail.com Thu May 15 21:04:39 2008 From: olivier.boudry at gmail.com (Olivier Boudry) Date: Thu May 15 20:58:19 2008 Subject: [Haskell-cafe] runInteractiveCommand: program ends before writing or reading all the output In-Reply-To: <1210890232.5824.153.camel@localhost> References: <1210890232.5824.153.camel@localhost> Message-ID: On Thu, May 15, 2008 at 6:23 PM, Duncan Coutts wrote: > > On Thu, 2008-05-15 at 13:40 -0400, Olivier Boudry wrote: > As an example let me show you as an example how we use it in Cabal: > > Hi Duncan, I tried to place a "length text `seq`" before the mapM_ writeExport to force the process output to be read but the result was even worst (only one line printed). Apparently withtout the `evaluate` function it causes more troubles than it solves. The example you provided is really helpful. I learned a lot reading it. Thanks, Olivier. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080515/11b8941b/attachment.htm From conor at strictlypositive.org Thu May 15 21:42:17 2008 From: conor at strictlypositive.org (Conor McBride) Date: Thu May 15 21:35:46 2008 Subject: [Haskell-cafe] bottomless Top? In-Reply-To: <3F77A68B-BA5B-43A0-A252-5E63506C84F6@fastmail.fm> References: <2A57F9CE-3096-4F96-A016-DEF31999C9FA@strictlypositive.org> <3F77A68B-BA5B-43A0-A252-5E63506C84F6@fastmail.fm> Message-ID: On 16 May 2008, at 01:13, Jonathan Cast wrote: > On 15 May 2008, at 4:29 AM, Conor McBride wrote: > >> Replying slap-foreheadedly to own post... >> >> On 15 May 2008, at 11:56, Conor McBride wrote: >> >>> Folks >>> >>> I'm also wondering whether it makes sense to have a >>> "bottomless Top" type, with constructor _ and lazy pattern _ >>> (with (undefined :: Top) equal to _). Then the constant-time >>> shape operator makes the same sort of sense as the >>> constant-time >>> >>> inflate :: Functor f => f Zero -> f a >> >> We've got it already. >> >> data One >> >> would do, with smart constructor >> >> only :: One >> only = undefined > > As I've mentioned before, my favorite data type > > newtype One = One One > > does the same, and stays in Haskell 98. That's rather fun. On the face of it, it looks peculiar that *Top> case undefined of One _ -> True True until you put your newtype constructor sunglasses on. Funny that newtype constructors really are like id until you fmap them. Or is that optimized away these days? > (And has the same weakness to seq: (`seq` ()) is perfectly strict > (it's const undefined)). Oh boooo! I'd forgotten that seq lets you look at an undefined thing just enough to go wrong. It'd be lovely to have proper unit and product, with their eta-laws, compiling pattern matching to projection. Was it so bad to distingush the value types at which seq could be applied? Meanwhile, the game's up for the unsafeCoerce dodge: *Top> shape ['m', undefined, 'o'] [(),*** Exception: Prelude.undefined I knew it was too good to be true. Like Randy Pollack says, the best thing about working in strongly normalizing languages is not having to normalize things. Loose morals are neither fast nor correct. I'd better crawl back under my rock. All the best Conor From lrpalmer at gmail.com Fri May 16 00:04:05 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Thu May 15 23:57:44 2008 Subject: [Haskell-cafe] Two-iteration optimisation (was: GHC Predictability) In-Reply-To: <482CA0EC.8010106@btinternet.com> References: <482B1C8C.4060509@cogito.org.uk> <20080514172045.GA10746@scytale.galois.com> <2608b8a80805150217y3da48092uf461160c2c5df961@mail.gmail.com> <482CA0EC.8010106@btinternet.com> Message-ID: <7ca3f0160805152104v224dc7a6n3f1aa255d5e9d4f1@mail.gmail.com> On Thu, May 15, 2008 at 8:45 PM, Andrew Coppin wrote: > Yitzchak Gale wrote: >> >> >> And of course, you wouldn't want that: >> >> f xs = xs : map expensiveCalculation xs >> >> Please don't fuse those two loops into one. >> > > ...doesn't type check. Did you mean (++)? Hmm? While the name might be misleading... expensiveCalculation = (:[]) Luke From aeyakovenko at gmail.com Fri May 16 01:37:31 2008 From: aeyakovenko at gmail.com (Anatoly Yakovenko) Date: Fri May 16 01:55:47 2008 Subject: [Haskell-cafe] fgl Data.Graph examples Message-ID: Can someone post some simple examples of using the Data.Graph library? So I can define a simple graph let g = buildG (1,2) [(1,2), (2,1)] but how do i label my edges and nodes? i want to be able to name my nodes, and add weights to the edges and be able to update those weights as well. Thanks, Anatoly From lassoken at gmail.com Fri May 16 04:19:29 2008 From: lassoken at gmail.com (Lauri Oksanen) Date: Fri May 16 04:13:07 2008 Subject: [Haskell-cafe] How to use arrays efficiently? Message-ID: <22dc08990805160119r5526452cuce87634cd222bb69@mail.gmail.com> Hi, I have a list of index-value pairs and I want to get a list which is sorted by the index and which contains index-wise sums of all the values. Here is a function that does this (and a bit more). --- pixelHistogram samples = let index s t = let x = round $ (fromIntegral imageWidth) * (1-s) y = round $ (fromIntegral imageHeight) * (1-t) in y*imageWidth + x indexedSamples = [(index s t, color) | (s, t, color) <- samples] pixelArray :: Array Int Color pixelArray = accumArray (\+) black (0, imageWidth*imageHeight) indexedSamples in elems pixelArray --- The problem is that this function is very inefficient. It seems that the whole indexedSamples list is stored in memory when creating pixelArray. When I do some profiling I see that the heap consumption of this function grows linearly. If I just write the samples list to a file instead of first summing them, I get a nice and flat heap profile. So how to do this efficiently? Thanks, Lauri -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080516/48f1aa82/attachment.htm From bulat.ziganshin at gmail.com Fri May 16 04:37:01 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Fri May 16 04:31:17 2008 Subject: [Haskell-cafe] How to use arrays efficiently? In-Reply-To: <22dc08990805160119r5526452cuce87634cd222bb69@mail.gmail.com> References: <22dc08990805160119r5526452cuce87634cd222bb69@mail.gmail.com> Message-ID: <664213286.20080516123701@gmail.com> Hello Lauri, Friday, May 16, 2008, 12:19:29 PM, you wrote: > ??? pixelArray :: Array Int Color it's boxed array which means that its elements are stored as thunks computed only when you actually use them. try UArray instead: http://haskell.org/haskellwiki/Modern_array_libraries -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From duncan.coutts at worc.ox.ac.uk Fri May 16 05:48:21 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri May 16 05:40:05 2008 Subject: [Haskell-cafe] runInteractiveCommand: program ends before writing or reading all the output In-Reply-To: References: <1210890232.5824.153.camel@localhost> Message-ID: <1210931301.5824.162.camel@localhost> On Thu, 2008-05-15 at 21:04 -0400, Olivier Boudry wrote: > I tried to place a "length text `seq`" before the mapM_ writeExport to > force the process output to be read but the result was even worst > (only one line printed). Apparently withtout the `evaluate` function > it causes more troubles than it solves. Yes, you should prefer evaluate over seq (or return $!) in the IO monad because you sometimes have to distinguish between the evaluation that happens when you construct your IO actions, and the evaluation that happens when you run your IO actions. The evaluate action does the latter and its ordered with respect to the other IO actions. Duncan From alistair at abayley.org Fri May 16 06:12:45 2008 From: alistair at abayley.org (Alistair Bayley) Date: Fri May 16 06:06:23 2008 Subject: [Haskell-cafe] Std lib equivalent for liftM concat . sequence Message-ID: <79d7c4980805160312h4bd702d6tdd1262749a1aae3a@mail.gmail.com> A couple of days ago I had need for: > concatM :: Monad m => [m [a]] -> m [a] > concatM = liftM concat . sequence but found no such thing in the std libs, except perhaps for msum (I don't want to add instances for MonadPlus. Should I have to?). Have I missed something trivial? Alistair From bulat.ziganshin at gmail.com Fri May 16 06:32:49 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Fri May 16 06:30:56 2008 Subject: [Haskell-cafe] Std lib equivalent for liftM concat . sequence In-Reply-To: <79d7c4980805160312h4bd702d6tdd1262749a1aae3a@mail.gmail.com> References: <79d7c4980805160312h4bd702d6tdd1262749a1aae3a@mail.gmail.com> Message-ID: <1116962427.20080516143249@gmail.com> Hello Alistair, Friday, May 16, 2008, 2:12:45 PM, you wrote: >> concatM = liftM concat . sequence > but found no such thing in the std libs, except perhaps for msum (I > don't want to add instances for MonadPlus. Should I have to?). Have I > missed something trivial? 1. it's easy to define yourself 2. it's not widely used. at least, i have in my program for, foreach, concatMapM, filterM and lot of other monadic operations, but no one concatM -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From leledumbo_cool at yahoo.co.id Fri May 16 07:42:31 2008 From: leledumbo_cool at yahoo.co.id (leledumbo) Date: Fri May 16 07:36:06 2008 Subject: [Haskell-cafe] elem of infinite set of tuple Message-ID: <17272802.post@talk.nabble.com> I don't know how Haskell should behave on this. Consider this function: elemOf (x,y) = (x,y) `elem` [ (a,b) | a <- [0..], b <- [0..] ] If I try to query elemOf (1,1), the program keeps searching and searching but it never makes it. But if I query elemOf (0,1) (or anything as long as the first element is 0), it can find it easily. I wonder how it's handled. >From my point of view, instead of starting from (1,0), the program starts from (0,0), which will never finish since the limit of the second element is infinite. -- View this message in context: http://www.nabble.com/elem-of-infinite-set-of-tuple-tp17272802p17272802.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. From lassoken at gmail.com Fri May 16 07:44:19 2008 From: lassoken at gmail.com (Lauri Oksanen) Date: Fri May 16 07:37:56 2008 Subject: [Haskell-cafe] How to use arrays efficiently? In-Reply-To: <664213286.20080516123701@gmail.com> References: <22dc08990805160119r5526452cuce87634cd222bb69@mail.gmail.com> <664213286.20080516123701@gmail.com> Message-ID: <22dc08990805160444t50da9709i34e399b6ab0d2681@mail.gmail.com> Thanks for help. I did some tests with UArray and it does the trick. The problem remaining is, how to implement UArray Int (Double, Double, Double)? UArray source code is far too cryptic for me. Regards, Lauri On Fri, May 16, 2008 at 11:37 AM, Bulat Ziganshin wrote: > Hello Lauri, > > Friday, May 16, 2008, 12:19:29 PM, you wrote: > > > pixelArray :: Array Int Color > > it's boxed array which means that its elements are stored as thunks > computed only when you actually use them. try UArray instead: > > http://haskell.org/haskellwiki/Modern_array_libraries > > > -- > Best regards, > Bulat mailto:Bulat.Ziganshin@gmail.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080516/9c8806c0/attachment.htm From droundy at darcs.net Fri May 16 07:49:16 2008 From: droundy at darcs.net (David Roundy) Date: Fri May 16 07:42:52 2008 Subject: [Haskell-cafe] elem of infinite set of tuple In-Reply-To: <17272802.post@talk.nabble.com> References: <17272802.post@talk.nabble.com> Message-ID: <20080516114915.GH8845@darcs.net> On Fri, May 16, 2008 at 04:42:31AM -0700, leledumbo wrote: > > I don't know how Haskell should behave on this. Consider this function: > elemOf (x,y) = (x,y) `elem` [ (a,b) | a <- [0..], b <- [0..] ] > > If I try to query elemOf (1,1), the program keeps searching and searching > but it never makes it. But if I query elemOf (0,1) (or anything as long as > the first element is 0), it can find it easily. I wonder how it's handled. > > From my point of view, instead of starting from (1,0), the program starts > from (0,0), which will never finish since the limit of the second element is > infinite. Didn't you just answer your own question? -- David Roundy Department of Physics Oregon State University From abhay.parvate at gmail.com Fri May 16 07:49:53 2008 From: abhay.parvate at gmail.com (Abhay Parvate) Date: Fri May 16 07:43:29 2008 Subject: [Haskell-cafe] elem of infinite set of tuple In-Reply-To: <17272802.post@talk.nabble.com> References: <17272802.post@talk.nabble.com> Message-ID: <3c4d5adf0805160449k57e7aadev132fc7ac261b534d@mail.gmail.com> It's not exactly a question of Haskell's behaviour. The list [ (a,b) | a <- [0..], b <- [0..] ] is such that apart from pairs starting with zero, no other pair is associated with a finite index. In other words, [ (a,b) | a <- [0..], b <- [0..] ] is not a correct 'enumeration' of all pairs of nonnegative integers. You need to reorder them if you need a finite index associated with every pair. On Fri, May 16, 2008 at 5:12 PM, leledumbo wrote: > > I don't know how Haskell should behave on this. Consider this function: > elemOf (x,y) = (x,y) `elem` [ (a,b) | a <- [0..], b <- [0..] ] > > If I try to query elemOf (1,1), the program keeps searching and searching > but it never makes it. But if I query elemOf (0,1) (or anything as long as > the first element is 0), it can find it easily. I wonder how it's handled. > > >From my point of view, instead of starting from (1,0), the program starts > from (0,0), which will never finish since the limit of the second element > is > infinite. > -- > View this message in context: > http://www.nabble.com/elem-of-infinite-set-of-tuple-tp17272802p17272802.html > Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080516/fa5b42dd/attachment.htm From abhay.parvate at gmail.com Fri May 16 07:52:16 2008 From: abhay.parvate at gmail.com (Abhay Parvate) Date: Fri May 16 07:45:53 2008 Subject: [Haskell-cafe] How to use arrays efficiently? In-Reply-To: <22dc08990805160444t50da9709i34e399b6ab0d2681@mail.gmail.com> References: <22dc08990805160119r5526452cuce87634cd222bb69@mail.gmail.com> <664213286.20080516123701@gmail.com> <22dc08990805160444t50da9709i34e399b6ab0d2681@mail.gmail.com> Message-ID: <3c4d5adf0805160452s3a8ea19fw81cd39a8413965b1@mail.gmail.com> As far as I know, you can't. It needs machine representable types, such as Int, Double, Char, etc. But making a tuple of three UArray Int Double may help. 2008/5/16 Lauri Oksanen : > Thanks for help. I did some tests with UArray and it does the trick. > The problem remaining is, how to implement UArray Int (Double, Double, > Double)? > UArray source code is far too cryptic for me. > > Regards, > Lauri > > On Fri, May 16, 2008 at 11:37 AM, Bulat Ziganshin < > bulat.ziganshin@gmail.com> wrote: > >> Hello Lauri, >> >> Friday, May 16, 2008, 12:19:29 PM, you wrote: >> >> > pixelArray :: Array Int Color >> >> it's boxed array which means that its elements are stored as thunks >> computed only when you actually use them. try UArray instead: >> >> http://haskell.org/haskellwiki/Modern_array_libraries >> >> >> -- >> Best regards, >> Bulat mailto:Bulat.Ziganshin@gmail.com >> >> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080516/755c685b/attachment.htm From dan.doel at gmail.com Fri May 16 07:58:40 2008 From: dan.doel at gmail.com (Dan Doel) Date: Fri May 16 07:52:20 2008 Subject: [Haskell-cafe] elem of infinite set of tuple In-Reply-To: <17272802.post@talk.nabble.com> References: <17272802.post@talk.nabble.com> Message-ID: <200805160758.41237.dan.doel@gmail.com> On Friday 16 May 2008, leledumbo wrote: > I don't know how Haskell should behave on this. Consider this function: > elemOf (x,y) = (x,y) `elem` [ (a,b) | a <- [0..], b <- [0..] ] FYI: The control-monad-omega package on hackage.haskell.org can handle this sort of thing (liberties taken with ghci formatting): Prelude> :m + Control.Monad.Omega Prelude Control.Monad.Omega> (1,1) `elem` runOmega (do x <- each [0..] ; y <- each [0..] ; return (x,y)) True Prelude Control.Monad.Omega> It does breadth-first instead of depth-first search. -- Dan From droundy at darcs.net Fri May 16 08:02:58 2008 From: droundy at darcs.net (David Roundy) Date: Fri May 16 07:56:35 2008 Subject: [Haskell-cafe] elem of infinite set of tuple In-Reply-To: <200805160758.41237.dan.doel@gmail.com> References: <17272802.post@talk.nabble.com> <200805160758.41237.dan.doel@gmail.com> Message-ID: <20080516120257.GI8845@darcs.net> On Fri, May 16, 2008 at 07:58:40AM -0400, Dan Doel wrote: > On Friday 16 May 2008, leledumbo wrote: > > I don't know how Haskell should behave on this. Consider this function: > > elemOf (x,y) = (x,y) `elem` [ (a,b) | a <- [0..], b <- [0..] ] > > FYI: The control-monad-omega package on hackage.haskell.org can handle this > sort of thing (liberties taken with ghci formatting): > > Prelude> :m + Control.Monad.Omega > Prelude Control.Monad.Omega> > (1,1) `elem` runOmega (do x <- each [0..] ; y <- each [0..] ; return (x,y)) > True > Prelude Control.Monad.Omega> > > It does breadth-first instead of depth-first search. You could also just use [ (b,a-b) | a <- [0..], b <- [0..a]] David From bulat.ziganshin at gmail.com Fri May 16 08:00:12 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Fri May 16 08:01:21 2008 Subject: [Haskell-cafe] How to use arrays efficiently? In-Reply-To: <22dc08990805160444t50da9709i34e399b6ab0d2681@mail.gmail.com> References: <22dc08990805160119r5526452cuce87634cd222bb69@mail.gmail.com> <664213286.20080516123701@gmail.com> <22dc08990805160444t50da9709i34e399b6ab0d2681@mail.gmail.com> Message-ID: <5610420918.20080516160012@gmail.com> Hello Lauri, Friday, May 16, 2008, 3:44:19 PM, you wrote: impossible. you can try parallel arrays > Thanks for help. I did some tests with UArray and it does the trick. > The problem remaining is, how to implement UArray Int (Double, Double, Double)? > UArray source code is far too cryptic for me. > Regards, > Lauri > On Fri, May 16, 2008 at 11:37 AM, Bulat Ziganshin > wrote: > Hello Lauri, > > Friday, May 16, 2008, 12:19:29 PM, you wrote: > >> ???? pixelArray :: Array Int Color > > it's boxed array which means that its elements are stored as thunks > computed only when you actually use them. try UArray instead: > > http://haskell.org/haskellwiki/Modern_array_libraries > > > -- > Best regards, > ?Bulat ? ? ? ? ? ? ? ? ? ? ? ? ? ?mailto:Bulat.Ziganshin@gmail.com > > > -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From gsan at stillpsycho.net Fri May 16 08:13:24 2008 From: gsan at stillpsycho.net (=?utf-8?q?G=C3=B6khan_San?=) Date: Fri May 16 08:07:07 2008 Subject: [Haskell-cafe] fgl Data.Graph examples In-Reply-To: References: Message-ID: <200805161413.24855.gsan@stillpsycho.net> Hi, I'm new to this, but I'll give it a shot. > import Data.Graph.Inductive There are several ways to build a graph. Let's say, node labels are 'String's and edge labels are 'Double's. Edge labels would be the weights. > grs :: [Gr String Double] The below four lines generate the same graph. From labeled nodes and edges: > grs = [mkGraph [(2, "start"), (1, "end")] [(2, 1, 1.0)], > insEdge (2, 1, 1.0) $ insNodes [(2, "start"), (1, "end")] empty, From contexts: > ([], 2, "start", [(1.0, 1)]) & (([], 1, "end", []) & empty), > buildGr [([], 2, "start", [(1.0, 1)]), ([], 1, "end", [])]] Test graph equality: > gr = head grs > same = all (equal gr) (tail grs) You can populate the graph using (&) and ins... functions while using 'newNodes' to get a bunch of unused node indexes ('Node's) to avoid collisions. Deleting nodes also delete all connected edges, but trying to insert an edge to a non-existent node will create an exception. So nodes get in first. > grd = delNode 1 gr -- no problem > grd' = insEdge (2, 1, 1.0) grd -- exception There are some functions to work on edges. For instance, this divides all weights on your graph by 2: > gr2 = emap (/ 2) gr This makes the graph undirected: > gr2u = undir gr2 There are other map and fold functions. 'gfold' is very powerful. It all depends on your motive though. I don't think there is a straightforward way to tweak individual nodes and edges other than using graph construction tools. Maybe someone could shed a light on this. Thanks, -- Gokhan From lassoken at gmail.com Fri May 16 08:25:57 2008 From: lassoken at gmail.com (Lauri Oksanen) Date: Fri May 16 08:19:35 2008 Subject: [Haskell-cafe] How to use arrays efficiently? In-Reply-To: <3c4d5adf0805160452s3a8ea19fw81cd39a8413965b1@mail.gmail.com> References: <22dc08990805160119r5526452cuce87634cd222bb69@mail.gmail.com> <664213286.20080516123701@gmail.com> <22dc08990805160444t50da9709i34e399b6ab0d2681@mail.gmail.com> <3c4d5adf0805160452s3a8ea19fw81cd39a8413965b1@mail.gmail.com> Message-ID: <22dc08990805160525lab78c6cmb437f7c0f0787585@mail.gmail.com> Thanks again. Here is my solution in case that somebody else runs into similar problem. This isn't very elegant and I would be interested to know if somebody has a better solution. Surely many people have encountered this kind of problem where you want to force evaluation of some expression at given point of program flow. Here evaluation of sum must be forced for every update of array element or otherwise memory consumption is proportional to the number of samples (100 000) instead of being proportional to the size of the array (10). --- import Data.Array.IO import Test.QuickCheck import System.Random uniformSampler :: Gen Double uniformSampler = choose (0,1) withSeed sampler seed = generate 1 (mkStdGen seed) sampler ac = 10 sc = 100000 triplet = do i <- uniformSampler s <- uniformSampler t <- uniformSampler return (round $ i * fromIntegral ac, (s,t)) sampling = sequence $ repeat triplet samples = take sc $ withSeed sampling 1 showElems xs = foldr1 (++) [show x ++ "\n" | x <- xs] main = do a1 <- newArray (0,ac) 0 :: IO (IOUArray Int Double) a2 <- newArray (0,ac) 0 :: IO (IOUArray Int Double) let addtoElem i s t = do s' <- readArray a1 i writeArray a1 i (s'+s) t' <- readArray a2 i writeArray a2 i (t'+t) writes = [addtoElem i s t | (i,(s,t)) <- samples] sequence writes ss <- getElems a1 ts <- getElems a2 putStrLn $ showElems (zip ss ts) --- Regards, Lauri On Fri, May 16, 2008 at 2:52 PM, Abhay Parvate wrote: > As far as I know, you can't. It needs machine representable types, such as > Int, Double, Char, etc. But making a tuple of three UArray Int Double may > help. > > 2008/5/16 Lauri Oksanen : > >> Thanks for help. I did some tests with UArray and it does the trick. >> The problem remaining is, how to implement UArray Int (Double, Double, >> Double)? >> UArray source code is far too cryptic for me. >> >> Regards, >> Lauri >> >> On Fri, May 16, 2008 at 11:37 AM, Bulat Ziganshin < >> bulat.ziganshin@gmail.com> wrote: >> >>> Hello Lauri, >>> >>> Friday, May 16, 2008, 12:19:29 PM, you wrote: >>> >>> > pixelArray :: Array Int Color >>> >>> it's boxed array which means that its elements are stored as thunks >>> computed only when you actually use them. try UArray instead: >>> >>> http://haskell.org/haskellwiki/Modern_array_libraries >>> >>> >>> -- >>> Best regards, >>> Bulat mailto:Bulat.Ziganshin@gmail.com >>> >>> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080516/be94f2bb/attachment.htm From ross at soi.city.ac.uk Fri May 16 08:29:56 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Fri May 16 08:23:34 2008 Subject: [Haskell-cafe] elem of infinite set of tuple In-Reply-To: <200805160758.41237.dan.doel@gmail.com> References: <17272802.post@talk.nabble.com> <200805160758.41237.dan.doel@gmail.com> Message-ID: <20080516122956.GA30256@soi.city.ac.uk> On Fri, May 16, 2008 at 07:58:40AM -0400, Dan Doel wrote: > On Friday 16 May 2008, leledumbo wrote: > > I don't know how Haskell should behave on this. Consider this function: > > elemOf (x,y) = (x,y) `elem` [ (a,b) | a <- [0..], b <- [0..] ] > > FYI: The control-monad-omega package on hackage.haskell.org can handle this > sort of thing (liberties taken with ghci formatting): > > Prelude> :m + Control.Monad.Omega > Prelude Control.Monad.Omega> > (1,1) `elem` runOmega (do x <- each [0..] ; y <- each [0..] ; return (x,y)) > True > Prelude Control.Monad.Omega> > > It does breadth-first instead of depth-first search. Note however that it's not a true monad, as it doesn't satisfy the associativity law, unless you ignore the order of the elements. The point is discussed by Spivey and Seres in their chapter in The Fun of Programming. From lemming at henning-thielemann.de Fri May 16 09:23:30 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri May 16 09:15:40 2008 Subject: [Haskell-cafe] elem of infinite set of tuple In-Reply-To: <20080516120257.GI8845@darcs.net> References: <17272802.post@talk.nabble.com> <200805160758.41237.dan.doel@gmail.com> <20080516120257.GI8845@darcs.net> Message-ID: On Fri, 16 May 2008, David Roundy wrote: > On Fri, May 16, 2008 at 07:58:40AM -0400, Dan Doel wrote: >> On Friday 16 May 2008, leledumbo wrote: >>> I don't know how Haskell should behave on this. Consider this function: >>> elemOf (x,y) = (x,y) `elem` [ (a,b) | a <- [0..], b <- [0..] ] >> >> FYI: The control-monad-omega package on hackage.haskell.org can handle this >> sort of thing (liberties taken with ghci formatting): >> >> Prelude> :m + Control.Monad.Omega >> Prelude Control.Monad.Omega> >> (1,1) `elem` runOmega (do x <- each [0..] ; y <- each [0..] ; return (x,y)) >> True >> Prelude Control.Monad.Omega> >> >> It does breadth-first instead of depth-first search. > > You could also just use [ (b,a-b) | a <- [0..], b <- [0..a]] I wonder whether Georg Cantor could imagine that his diagonalization method would be practically applied some day. http://de.wikipedia.org/wiki/Cantor-Diagonalisierung From lemming at henning-thielemann.de Fri May 16 09:26:45 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri May 16 09:18:53 2008 Subject: [Haskell-cafe] How to use arrays efficiently? In-Reply-To: <22dc08990805160444t50da9709i34e399b6ab0d2681@mail.gmail.com> References: <22dc08990805160119r5526452cuce87634cd222bb69@mail.gmail.com> <664213286.20080516123701@gmail.com> <22dc08990805160444t50da9709i34e399b6ab0d2681@mail.gmail.com> Message-ID: On Fri, 16 May 2008, Lauri Oksanen wrote: > Thanks for help. I did some tests with UArray and it does the trick. > The problem remaining is, how to implement UArray Int (Double, Double, Double)? Maybe an (UArray (Int,Int) Double) could help, where the second index range is fixed to (0,2). From ketil at malde.org Fri May 16 09:27:29 2008 From: ketil at malde.org (Ketil Malde) Date: Fri May 16 09:29:25 2008 Subject: [Haskell-cafe] How to use arrays efficiently? In-Reply-To: <22dc08990805160444t50da9709i34e399b6ab0d2681@mail.gmail.com> (Lauri Oksanen's message of "Fri\, 16 May 2008 14\:44\:19 +0300") References: <22dc08990805160119r5526452cuce87634cd222bb69@mail.gmail.com> <664213286.20080516123701@gmail.com> <22dc08990805160444t50da9709i34e399b6ab0d2681@mail.gmail.com> Message-ID: <87ve1emla6.fsf@nmd9999.imr.no> "Lauri Oksanen" writes: > Thanks for help. I did some tests with UArray and it does the trick. > The problem remaining is, how to implement UArray Int (Double, Double, Double)? As (UArray Int Double, UArray Int Double, UArray Int Double). Or as UArray Int Double, but with a specialized lookup function: mylookup array index = (array!3*index, array!3*index+1, array!3*index+2) I guess it would be possible to have UArray Int (# Double, Double, Double #) - packing all three Doubles unboxed into the array, but I've no clue how to go about automating that. -k -- If I haven't seen further, it is by standing in the footprints of giants From lassoken at gmail.com Fri May 16 09:45:50 2008 From: lassoken at gmail.com (Lauri Oksanen) Date: Fri May 16 09:39:26 2008 Subject: [Haskell-cafe] How to use arrays efficiently? In-Reply-To: References: <22dc08990805160119r5526452cuce87634cd222bb69@mail.gmail.com> <664213286.20080516123701@gmail.com> <22dc08990805160444t50da9709i34e399b6ab0d2681@mail.gmail.com> Message-ID: <22dc08990805160645n29224badg99c6badb1811faac@mail.gmail.com> Yes, of course. How blind of me. Here is one more question. If you change IOUArray to IOArray and add $! in front of the two summations in the previous code, it still works correctly. But can you do similar trick with Array and accumArray? I have tried to put $! in different places in the first code that I posted but nothing seems to work. On Fri, May 16, 2008 at 4:26 PM, Henning Thielemann < lemming@henning-thielemann.de> wrote: > > On Fri, 16 May 2008, Lauri Oksanen wrote: > > Thanks for help. I did some tests with UArray and it does the trick. >> The problem remaining is, how to implement UArray Int (Double, Double, >> Double)? >> > > Maybe an (UArray (Int,Int) Double) could help, where the second index range > is fixed to (0,2). > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080516/95e4f218/attachment.htm From bulat.ziganshin at gmail.com Fri May 16 09:55:07 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Fri May 16 09:51:15 2008 Subject: [Haskell-cafe] How to use arrays efficiently? In-Reply-To: <87ve1emla6.fsf@nmd9999.imr.no> References: <22dc08990805160119r5526452cuce87634cd222bb69@mail.gmail.com> <664213286.20080516123701@gmail.com> <22dc08990805160444t50da9709i34e399b6ab0d2681@mail.gmail.com> <87ve1emla6.fsf@nmd9999.imr.no> Message-ID: <1982591285.20080516175507@gmail.com> Hello Ketil, Friday, May 16, 2008, 5:27:29 PM, you wrote: > I guess it would be possible to have UArray Int (# Double, Double, > Double #) - packing all three Doubles unboxed into the array, but I've > no clue how to go about automating that. unoxed tuple doesn't have a box so it cannot be instance of typeclass. actually, ordinary tuple will solve this problem unless one problem in GHC - it's UArray indexing primitives use *element* indexes inatead of *byte* indexes. although at least we can implement UArray ix (a,a), UArray ix (a,a,a) and so on -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From bulat.ziganshin at gmail.com Fri May 16 09:57:28 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Fri May 16 09:51:20 2008 Subject: [Haskell-cafe] How to use arrays efficiently? In-Reply-To: <22dc08990805160645n29224badg99c6badb1811faac@mail.gmail.com> References: <22dc08990805160119r5526452cuce87634cd222bb69@mail.gmail.com> <664213286.20080516123701@gmail.com> <22dc08990805160444t50da9709i34e399b6ab0d2681@mail.gmail.com> <22dc08990805160645n29224badg99c6badb1811faac@mail.gmail.com> Message-ID: <1427452575.20080516175728@gmail.com> Hello Lauri, Friday, May 16, 2008, 5:45:50 PM, you wrote: > Yes, of course. How blind of me. Here is one more question. > If you change IOUArray to IOArray and add $! in front of the two > summations in the previous code, it still works correctly. > But can you do similar trick with Array and accumArray? I have > tried to put $! in different places in the first code that I posted but nothing seems to work. accumArray internally uses more or less the same code with imperative array as you wrote. so if you replace accumArray with your implementation with all those $! - it will work. otherwise you just don't get any chance :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From wagner.andrew at gmail.com Fri May 16 11:29:42 2008 From: wagner.andrew at gmail.com (Andrew Wagner) Date: Fri May 16 11:23:17 2008 Subject: [Haskell-cafe] ChessLibrary project Message-ID: All, I've made my first code drop for a new project I'm working on (though it's really an extension of work I've been doing for about 5 years). Information and code can be found at http://code.haskell.org/ChessLibrary/ . Comments and suggestions warmly welcomed. Also, I'm looking for an experienced haskeller to serve as a mentor for this project - just to provide regular code reviews and architectural advice, mainly. Thanks for looking! From immanuel.normann at googlemail.com Fri May 16 11:51:33 2008 From: immanuel.normann at googlemail.com (Immanuel Normann) Date: Fri May 16 11:45:11 2008 Subject: [Haskell-cafe] Starting Haskell with a web application In-Reply-To: <20080306130245.GB22702@shaka.acc.umu.se> References: <6cc20cea0803051009y7fedd8a2i304f63ac867c3c23@mail.gmail.com> <47CEEBD7.30005@serpentine.com> <20080306130245.GB22702@shaka.acc.umu.se> Message-ID: <92952f860805160851p6e3e5239haf63b68cc10f21d3@mail.gmail.com> Where can I find the sources of the latest WASH? I couldn't find them in HackageDB (and neither with Google). -- Immanuel Normann 2008/3/6 Lars Viklund : > On Wed, Mar 05, 2008 at 10:52:07AM -0800, Bryan O'Sullivan wrote: > > Jonathan Gardner wrote: > > > > There's also WASH, but that has an even lower profile. I couldn't tell > > you if it sees much use, or even builds with recent compilers. > > The HTML component of WASH builds rather cleanly with GHC 6.8.2 after > enabling the following extensions: > MultiParamTypeClasses FlexibleContexts FlexibleInstances > TypeSynonymInstances > > I use it for my statically generated blog, together with sqlite3. I've > modified WASH/HTML to spit out reasonably correct XHTML as well. > > As for the rest of WASH, I have no idea since I had no need for it. > > -- > Lars Viklund | zao@zao.se > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080516/54440f8a/attachment.htm From miguelimo38 at yandex.ru Fri May 16 12:13:37 2008 From: miguelimo38 at yandex.ru (Miguel Mitrofanov) Date: Fri May 16 12:07:27 2008 Subject: [Haskell-cafe] Std lib equivalent for liftM concat . sequence In-Reply-To: <79d7c4980805160312h4bd702d6tdd1262749a1aae3a@mail.gmail.com> References: <79d7c4980805160312h4bd702d6tdd1262749a1aae3a@mail.gmail.com> Message-ID: <2C43B99C-0DAB-4674-9E5A-296B6BBBC46C@yandex.ru> Seems to be close to sequence :: [ListT m a] -> ListT m a Hmm? On 16 May 2008, at 14:12, Alistair Bayley wrote: > A couple of days ago I had need for: > >> concatM :: Monad m => [m [a]] -> m [a] >> concatM = liftM concat . sequence > > but found no such thing in the std libs, except perhaps for msum (I > don't want to add instances for MonadPlus. Should I have to?). Have I > missed something trivial? > > Alistair > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From lgreg.meredith at biosimilarity.com Fri May 16 12:37:44 2008 From: lgreg.meredith at biosimilarity.com (Greg Meredith) Date: Fri May 16 12:31:22 2008 Subject: [Haskell-cafe] NW Functional Programming Interest Group In-Reply-To: <5de3f5ca0804150821t342512bcv5fd3bb5f02f20bd7@mail.gmail.com> References: <5de3f5ca0802011155l771cc649wa0e671bbe3abe364@mail.gmail.com> <5de3f5ca0804150821t342512bcv5fd3bb5f02f20bd7@mail.gmail.com> Message-ID: <5de3f5ca0805160937m1e463076y453281b0648b9853@mail.gmail.com> All, Apologies for multiple listings. It's that time again. Our growing cadre of functionally-minded north westerners is meeting at the The Seattle Public Library *University Branch* 5009 Roosevelt Way N.E. *Seattle*, WA 98105 206-684-4063 from 18:30 - 20:00 on May 28th. **** Note the change in venue **** Agenda - JP has graciously offered to give a talk on darcs - we also need to continue to fill the talk pipeline Hope to see you there. Monadically yours, --greg -- L.G. Meredith Managing Partner Biosimilarity LLC 806 55th St NE Seattle, WA 98105 +1 206.650.3740 http://biosimilarity.blogspot.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080516/afdadc54/attachment.htm From barsoap at web.de Fri May 16 13:42:50 2008 From: barsoap at web.de (Achim Schneider) Date: Fri May 16 13:36:40 2008 Subject: [Haskell-cafe] Proving my point Message-ID: <20080516194250.4f05e8be@solaris> "test.l" (line 7, column 1): unexpected end of input expecting "(", Lambda abstraction, Let binding, Atom, end of input or Function application I obviously don't know anything about Parsec's inner workings. I'm going to investigate as soon as I stopped despairing. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. From miguelimo38 at yandex.ru Fri May 16 13:51:40 2008 From: miguelimo38 at yandex.ru (Miguel Mitrofanov) Date: Fri May 16 13:45:19 2008 Subject: [Haskell-cafe] Std lib equivalent for liftM concat . sequence In-Reply-To: <2C43B99C-0DAB-4674-9E5A-296B6BBBC46C@yandex.ru> References: <79d7c4980805160312h4bd702d6tdd1262749a1aae3a@mail.gmail.com> <2C43B99C-0DAB-4674-9E5A-296B6BBBC46C@yandex.ru> Message-ID: Oops, I was very wrong. Sorry. On 16 May 2008, at 20:13, Miguel Mitrofanov wrote: > Seems to be close to > > sequence :: [ListT m a] -> ListT m a > > Hmm? > > On 16 May 2008, at 14:12, Alistair Bayley wrote: > >> A couple of days ago I had need for: >> >>> concatM :: Monad m => [m [a]] -> m [a] >>> concatM = liftM concat . sequence >> >> but found no such thing in the std libs, except perhaps for msum (I >> don't want to add instances for MonadPlus. Should I have to?). Have I >> missed something trivial? >> >> Alistair >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From aeyakovenko at gmail.com Fri May 16 14:29:54 2008 From: aeyakovenko at gmail.com (Anatoly Yakovenko) Date: Fri May 16 14:23:31 2008 Subject: [Haskell-cafe] fgl Data.Graph examples In-Reply-To: <200805161413.24855.gsan@stillpsycho.net> References: <200805161413.24855.gsan@stillpsycho.net> Message-ID: Thank you, that's exactly what i was looking for. > I don't think there is a straightforward way to tweak individual nodes and > edges other than using graph construction tools. Maybe someone could shed a > light on this. I think i can define updateEdge in terms of insEdge and delEdge From andrewcoppin at btinternet.com Fri May 16 14:42:33 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Fri May 16 14:35:52 2008 Subject: [Haskell-cafe] Two-iteration optimisation (was: GHC Predictability) In-Reply-To: <7ca3f0160805152104v224dc7a6n3f1aa255d5e9d4f1@mail.gmail.com> References: <482B1C8C.4060509@cogito.org.uk> <20080514172045.GA10746@scytale.galois.com> <2608b8a80805150217y3da48092uf461160c2c5df961@mail.gmail.com> <482CA0EC.8010106@btinternet.com> <7ca3f0160805152104v224dc7a6n3f1aa255d5e9d4f1@mail.gmail.com> Message-ID: <482DD599.7070301@btinternet.com> Luke Palmer wrote: > On Thu, May 15, 2008 at 8:45 PM, Andrew Coppin > wrote: > >> Yitzchak Gale wrote: >> >>> And of course, you wouldn't want that: >>> >>> f xs = xs : map expensiveCalculation xs >>> >>> Please don't fuse those two loops into one. >>> >>> >> ...doesn't type check. Did you mean (++)? >> > > Hmm? While the name might be misleading... > > expensiveCalculation = (:[]) > Ah. So f :: [x] -> [[x]]. Devious... From dons at galois.com Fri May 16 14:42:51 2008 From: dons at galois.com (Don Stewart) Date: Fri May 16 14:36:32 2008 Subject: [Haskell-cafe] How to use arrays efficiently? In-Reply-To: <3c4d5adf0805160452s3a8ea19fw81cd39a8413965b1@mail.gmail.com> References: <22dc08990805160119r5526452cuce87634cd222bb69@mail.gmail.com> <664213286.20080516123701@gmail.com> <22dc08990805160444t50da9709i34e399b6ab0d2681@mail.gmail.com> <3c4d5adf0805160452s3a8ea19fw81cd39a8413965b1@mail.gmail.com> Message-ID: <20080516184251.GL13679@scytale.galois.com> You'd have to write a wrapper that implements an array of triples as a triple of arrays. This isn't too hard. There's a new library in the works that should make this a lot easier -- Don abhay.parvate: > As far as I know, you can't. It needs machine representable types, such as > Int, Double, Char, etc. But making a tuple of three UArray Int Double may > help. > > 2008/5/16 Lauri Oksanen <[1]lassoken@gmail.com>: > > Thanks for help. I did some tests with UArray and it does the trick. > The problem remaining is, how to implement UArray Int (Double, Double, > Double)? > UArray source code is far too cryptic for me. > > Regards, > Lauri > > On Fri, May 16, 2008 at 11:37 AM, Bulat Ziganshin > <[2]bulat.ziganshin@gmail.com> wrote: > > Hello Lauri, > > Friday, May 16, 2008, 12:19:29 PM, you wrote: > > > pixelArray :: Array Int Color > > it's boxed array which means that its elements are stored as thunks > computed only when you actually use them. try UArray instead: > > [3]http://haskell.org/haskellwiki/Modern_array_libraries > > -- > Best regards, > Bulat mailto:[4]Bulat.Ziganshin@gmail.com > > _______________________________________________ > Haskell-Cafe mailing list > [5]Haskell-Cafe@haskell.org > [6]http://www.haskell.org/mailman/listinfo/haskell-cafe > > References > > Visible links > 1. mailto:lassoken@gmail.com > 2. mailto:bulat.ziganshin@gmail.com > 3. http://haskell.org/haskellwiki/Modern_array_libraries > 4. mailto:Bulat.Ziganshin@gmail.com > 5. mailto:Haskell-Cafe@haskell.org > 6. http://www.haskell.org/mailman/listinfo/haskell-cafe > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From andrewcoppin at btinternet.com Fri May 16 14:49:48 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Fri May 16 14:43:05 2008 Subject: [Haskell-cafe] Fun with Darcs In-Reply-To: <1210889153.5824.137.camel@localhost> References: <93BECC602E286B499D5443ECB850D2FF01331E95@newman.usa.aitgroupad.com> <482B3022.2050303@btinternet.com> <482B38FC.2000705@btinternet.com> <482B3F91.7050602@btinternet.com> <20080514201346.GP8845@darcs.net> <482B505C.3020300@btinternet.com> <259058831.20080515010114@gmail.com> <1210889153.5824.137.camel@localhost> Message-ID: <482DD74C.1060009@btinternet.com> Duncan Coutts wrote: > On Thu, 2008-05-15 at 01:01 +0400, Bulat Ziganshin wrote: > >> Hello Andrew, >> >> Thursday, May 15, 2008, 12:49:32 AM, you wrote: >> >> >>> touch. Now, let's see what this IDE actually looks li-- oh you have GOT >>> to be KIDDING me! It can't find the right GTK DLL?!? >>> >> gtk2hs includes *developer* gtk2 environment. >> > > Which includes all the runtime dlls. > > >> while it should work fine (as far as it's in your path), you may try >> to install *runtime* gtk2 environment from >> http://sourceforge.net/project/showfiles.php?group_id=71914&package_id=255391 >> > > I would not recommend that. I'd use the dlls that come with gtk2hs. > Well, gmane shows that Duncan sent a second message about this - but since I didn't receive it in my mailbox, I can't reply quoting that. [Most irritating...] Anyway, running Leksah today, it doesn't complaing about missing GTK DLLs at all, so you must be right about the search path thing. [Now instead it crashes with a completely different error.] I built a copy of Leksah at work, and noticed that I didn't get the issue with a missing icon, so apparently the Darcs repo must have changed in the last few hours. (Indeed, I guess I could ask Darcs and find out!) The copy I built at work [with GHC 6.8.1] worked just fine - not that I could figure out how to use it. ;-) From andrewcoppin at btinternet.com Fri May 16 14:52:12 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Fri May 16 14:45:30 2008 Subject: [Haskell-cafe] Proving my point In-Reply-To: <20080516194250.4f05e8be@solaris> References: <20080516194250.4f05e8be@solaris> Message-ID: <482DD7DC.2060601@btinternet.com> Achim Schneider wrote: > "test.l" (line 7, column 1): > unexpected end of input > expecting "(", Lambda abstraction, Let binding, Atom, end of input or > Function application > > I obviously don't know anything about Parsec's inner workings. I'm > going to investigate as soon as I stopped despairing. > Wait... "unexpected end of input; expecting [...] end of input [...]" That's just *wrong*...! ;-) But don't despaire - show us your parser and what it's supposed to parse, and I'm sure somebody [maybe even me] will be able to tell you what's up. From andrewcoppin at btinternet.com Fri May 16 14:56:36 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Fri May 16 14:49:53 2008 Subject: [Haskell-cafe] Re: Write Haskell as fast as C. [Was: Re: GHC predictability] In-Reply-To: <20080515183132.GD31635@scytale.galois.com> References: <20080515183132.GD31635@scytale.galois.com> Message-ID: <482DD8E4.2060509@btinternet.com> Don Stewart wrote: > I've written an extended post on how to understand and reliably optimise > code like this, looking at it all the way down to the assembly. > > The result are some simple rules to follow for generated code as good > as gcc -O2. > > Enjoy, > > http://cgi.cse.unsw.edu.au/~dons/blog/2008/05/16#fast > A well-written piece, as always. My feelings are ambivilent. On the one hand, it's reassuring that such good performance can be obtained without resorting to calling C, explicit unboxed types, GHC-specific hacks, strictness annotations, manual seq calls, strange case expressions, or really anything remotely odd. It's fairly plain Haskell '98 that most beginners would be able to read through and eventually understand. And yet it's fast. On the other hand, this is the anti-theisis of Haskell. We start with a high-level, declarative program, which performs horribly, and end up with a manually hand-optimised blob that's much harder to read but goes way faster. Obviously most people would prefer to write declarative code and feel secure that the compiler is going to produce something efficient. If the muse takes me, maybe I'll see if I can't find a less ugly way to do this... From andrewcoppin at btinternet.com Fri May 16 15:03:31 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Fri May 16 14:56:49 2008 Subject: [Haskell-cafe] Short circuiting and the Maybe monad In-Reply-To: <482B378E.802@btinternet.com> References: <65113aef0805121509s6b4e76bbxd23e86070a2a0be3@mail.gmail.com> <482A7AF0.6020008@tcs.inf.tu-dresden.de> <482B378E.802@btinternet.com> Message-ID: <482DDA83.4070907@btinternet.com> Andrew Coppin wrote: > Janis Voigtlaender wrote: >> http://wwwtcs.inf.tu-dresden.de/~voigt/mpc08.pdf > > "It is well-known that trees with substitution form a monad." > > ...OK, I just learned something new. Hanging around Haskell Cafe can > be so illuminating! :-) > > Now, if only I could actually comprehend the rest of the paper... o_O I'll probably regret this for the rest of my life, but... As best as I can tell, a monad is essentially a container of some kind, together with a function that puts stuff into a container, and another function that maps over the container and combines the results in some way. That would rather suggest that *any* container type is potentially a monad of some kind. [Although possibly not a *useful* one...] Since a tree is a kind of container, yes, it should be a monad. [I'm still not really sure whether it's "useful".] Presumably a set monad would work something like the list monad. One could imagine an array monad [although counting the size of the result set before allocating the array would seem rather expensive]. Perhaps a dictionary could be a monad? I'm not precisely sure how that would work. Hmm, what other kinds of random containers could you make a monad out of? [And would you bother?] On the other hand, Maybe is a rather odd kind of container, but a very useful monad... From dons at galois.com Fri May 16 15:04:22 2008 From: dons at galois.com (Don Stewart) Date: Fri May 16 14:58:16 2008 Subject: [Haskell-cafe] Re: Write Haskell as fast as C. [Was: Re: GHC predictability] In-Reply-To: <482DD8E4.2060509@btinternet.com> References: <20080515183132.GD31635@scytale.galois.com> <482DD8E4.2060509@btinternet.com> Message-ID: <20080516190422.GA13340@scytale.galois.com> andrewcoppin: > Don Stewart wrote: > >I've written an extended post on how to understand and reliably optimise > >code like this, looking at it all the way down to the assembly. > > > >The result are some simple rules to follow for generated code as good > >as gcc -O2. > > > >Enjoy, > > > > http://cgi.cse.unsw.edu.au/~dons/blog/2008/05/16#fast > > > > A well-written piece, as always. > > My feelings are ambivilent. On the one hand, it's reassuring that such > good performance can be obtained without resorting to calling C, > explicit unboxed types, GHC-specific hacks, strictness annotations, > manual seq calls, strange case expressions, or really anything remotely > odd. It's fairly plain Haskell '98 that most beginners would be able to > read through and eventually understand. And yet it's fast. > > On the other hand, this is the anti-theisis of Haskell. We start with a > high-level, declarative program, which performs horribly, and end up > with a manually hand-optimised blob that's much harder to read but goes > way faster. Obviously most people would prefer to write declarative code > and feel secure that the compiler is going to produce something efficient. > > If the muse takes me, maybe I'll see if I can't find a less ugly way to > do this... > I don't understand what's ugly about: go s l x | x > m = s / fromIntegral l | otherwise = go (s+x) (l+1) (x+1) And the point is that it is *reliable*. If you make your money day in, day out writing Haskell, and you don't want to rely on radical transformations for correctness, this is a sensible idiom to follow. Nothing beats understanding what you're writing at all levels of abstraction. -- Don From bulat.ziganshin at gmail.com Fri May 16 15:06:06 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Fri May 16 14:59:50 2008 Subject: [Haskell-cafe] Re: Write Haskell as fast as C. [Was: Re: GHC predictability] In-Reply-To: <482DD8E4.2060509@btinternet.com> References: <20080515183132.GD31635@scytale.galois.com> <482DD8E4.2060509@btinternet.com> Message-ID: <237086617.20080516230606@gmail.com> Hello Andrew, Friday, May 16, 2008, 10:56:36 PM, you wrote: > On the other hand, this is the anti-theisis of Haskell. We start with a > high-level, declarative program, which performs horribly, and end up > with a manually hand-optimised blob that's much harder to read but goes > way faster. Obviously most people would prefer to write declarative code > and feel secure that the compiler is going to produce something efficient. if i understood correctly, fusion system about which Don plan to told next time, is just about translating high-level code into lower-level one "behind the scenes". but it works only on limited subset of programs. it's what we have now - haskell is very inefficient language -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From bos at serpentine.com Fri May 16 15:06:32 2008 From: bos at serpentine.com (Bryan O'Sullivan) Date: Fri May 16 15:00:07 2008 Subject: [Haskell-cafe] Re: Write Haskell as fast as C. [Was: Re: GHC predictability] In-Reply-To: <482DD8E4.2060509@btinternet.com> References: <20080515183132.GD31635@scytale.galois.com> <482DD8E4.2060509@btinternet.com> Message-ID: <482DDB38.2040108@serpentine.com> Andrew Coppin wrote: > On the other hand, this is the anti-theisis of Haskell. We start with a > high-level, declarative program, which performs horribly, and end up > with a manually hand-optimised blob that's much harder to read but goes > way faster. Buh? This is hard to read? mean n m = go 0 0 n where go s l x | x > m = (s::Double) / fromIntegral (l::Int) | otherwise = go (s+x) (l+1) (x+1) One can in fact imagine a world in which the compiler does this transformation for you, though it takes a bit of squinting. http://reddit.com/r/programming/info/6jjhg/comments/c040ybt References: <20080515183132.GD31635@scytale.galois.com> <482DD8E4.2060509@btinternet.com> <482DDB38.2040108@serpentine.com> Message-ID: <482DDDC4.4020002@btinternet.com> Bryan O'Sullivan wrote: > Andrew Coppin wrote: > > >> On the other hand, this is the anti-theisis of Haskell. We start with a >> high-level, declarative program, which performs horribly, and end up >> with a manually hand-optimised blob that's much harder to read but goes >> way faster. >> > > Buh? This is hard to read? > Look closer: it's hardER to read. mean xs = sum xs / fromIntegral (length xs) mean = go 0 0 n where go s l x | x > m = s / fromIntegra l | otherwise = go (s+x) (l+1) (x+1 One version makes it instantly clear, at a glance, what is happening. The other requires you to mentally walk round a look, imperative style, to figure out what's happening. It's not a *big* deal, but it's unfortunate. I'm more worried about what happens in less trivial examples. [Let's face it, who wants to compute the sum of the numbers from 1 to N?] From barsoap at web.de Fri May 16 15:33:47 2008 From: barsoap at web.de (Achim Schneider) Date: Fri May 16 15:27:34 2008 Subject: [Haskell-cafe] Re: Proving my point References: <20080516194250.4f05e8be@solaris> <482DD7DC.2060601@btinternet.com> Message-ID: <20080516213347.23d0b77a@solaris> Andrew Coppin wrote: > Wait... "unexpected end of input; expecting [...] end of input [...]" > > That's just *wrong*...! ;-) > > But don't despaire - show us your parser and what it's supposed to > parse, and I'm sure somebody [maybe even me] will be able to tell you > what's up. This is what I came up with while simplifying the parser: import Text.Parsec identifier = do whiteSpace s <- many1 letter whiteSpace return s whiteSpace = do eof <|> ((many $ choice [ char ' ', newline ]) >> return ()) main = do let syn = runParser (do char '\\' many1 identifier char ':' whiteSpace identifier whiteSpace ) () "" "\\a b" print syn Admittedly, this is a quite degenerate case crouching in at least 10 corners simultaneously. Anyway, I get % ./test Left (line 1, column 5): unexpected end of input expecting end of input, letter or ":" and if I change it to whiteSpace = do (many eof >> return ()) <|> ((many $ choice [ char ' ', newline ]) >> return ()) Left (line 1, column 3): unexpected " " expecting letter, end of input or ":" Please, please don't ask me for the rationale of using eof like this, you would get the same answer as if you'd ask me why I cast a stone into the sea. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. From flippa at flippac.org Fri May 16 15:39:53 2008 From: flippa at flippac.org (Philippa Cowderoy) Date: Fri May 16 15:32:30 2008 Subject: [Haskell-cafe] Proving my point In-Reply-To: <20080516194250.4f05e8be@solaris> References: <20080516194250.4f05e8be@solaris> Message-ID: On Fri, 16 May 2008, Achim Schneider wrote: > "test.l" (line 7, column 1): > unexpected end of input > expecting "(", Lambda abstraction, Let binding, Atom, end of input or > Function application > > I obviously don't know anything about Parsec's inner workings. I'm > going to investigate as soon as I stopped despairing. > One gotcha here, which really wants fixing: if the show instance for your token type returns "", Parsec assumes that's EOF for error purposes. Guess who ran into that with a separate token for layout-inserted braces? -- flippa@flippac.org Sometimes you gotta fight fire with fire. Most of the time you just get burnt worse though. From apfelmus at quantentunnel.de Fri May 16 16:03:58 2008 From: apfelmus at quantentunnel.de (apfelmus) Date: Fri May 16 15:57:50 2008 Subject: [Haskell-cafe] Re: Write Haskell as fast as C. [Was: Re: GHC predictability] In-Reply-To: <482DDDC4.4020002@btinternet.com> References: <20080515183132.GD31635@scytale.galois.com> <482DD8E4.2060509@btinternet.com> <482DDB38.2040108@serpentine.com> <482DDDC4.4020002@btinternet.com> Message-ID: Andrew Coppin wrote: > Bryan O'Sullivan wrote: >> Andrew Coppin wrote: >> >>> On the other hand, this is the anti-theisis of Haskell. We start with a >>> high-level, declarative program, which performs horribly, and end up >>> with a manually hand-optimised blob that's much harder to read but goes >>> way faster. >>> >> >> Buh? This is hard to read? >> > > Look closer: it's hardER to read. > > mean xs = sum xs / fromIntegral (length xs) > > mean = go 0 0 n > where > go s l x > | x > m = s / fromIntegral l > | otherwise = go (s+x) (l+1) (x+1 > > One version makes it instantly clear, at a glance, what is happening. > The other requires you to mentally walk round a look, imperative style, > to figure out what's happening. It's not a *big* deal, but it's > unfortunate. > > I'm more worried about what happens in less trivial examples. [Let's > face it, who wants to compute the sum of the numbers from 1 to N?] Hm, it seems like you're expecting magic, aren't you? Of course the first equation is easier to read, but it's no surprise that this may actually be slower. Like the imperative bubblesort is easier to read than the imperative quicksort but far slower. Put differently, making Haskell as fast as C is easy: just write a slower C program! Namely one that is as easy to read as the Haskell version. If you implement mean xs = sum xs / fromIntegral (length xs) directly in C, I bet you'll be delighted to discover that they perform similarly (using linked lists in the C version). Regards, apfelmus From andrewcoppin at btinternet.com Fri May 16 16:19:20 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Fri May 16 16:12:37 2008 Subject: [Haskell-cafe] Re: Write Haskell as fast as C. [Was: Re: GHC predictability] In-Reply-To: <20080516190422.GA13340@scytale.galois.com> References: <20080515183132.GD31635@scytale.galois.com> <482DD8E4.2060509@btinternet.com> <20080516190422.GA13340@scytale.galois.com> Message-ID: <482DEC48.7080304@btinternet.com> Don Stewart wrote: > I don't understand what's ugly about: > > go s l x | x > m = s / fromIntegral l > | otherwise = go (s+x) (l+1) (x+1) > > And the point is that it is *reliable*. If you make your money day in, day out > writing Haskell, and you don't want to rely on radical transformations for > correctness, this is a sensible idiom to follow. > > Nothing beats understanding what you're writing at all levels of abstraction. > What sets Haskell apart from every other programming language ever used in mainstream programming? You might say conciseness, or the ability to use lazy evaluation to structure your code in usual ways, or something like that. I would say what sets Haskell apart is "abstraction". There are other things, but this is the big one. Haskell allows you to abstract almost everything. The result is often highly succinct yet very readable programs. It would seem a terribly shame if you always have to throw away Haskell's key advantage to get decent runtime performance. If you're trying to get a real program to work, right now, then yes, you may have no choice. But that doesn't mean we shouldn't strive for ways to keep code high-level yet performant. [I'm curios about your other comment. Does anybody, anywhere in the world, actually make *money* using Haskell? This seems rather unlikely to me...] From andrewcoppin at btinternet.com Fri May 16 16:23:40 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Fri May 16 16:16:57 2008 Subject: [Haskell-cafe] Re: Write Haskell as fast as C. [Was: Re: GHC predictability] In-Reply-To: References: <20080515183132.GD31635@scytale.galois.com> <482DD8E4.2060509@btinternet.com> <482DDB38.2040108@serpentine.com> <482DDDC4.4020002@btinternet.com> Message-ID: <482DED4C.6020609@btinternet.com> apfelmus wrote: > Andrew Coppin wrote: >> Look closer: it's hardER to read. >> >> mean xs = sum xs / fromIntegral (length xs) >> >> mean = go 0 0 n >> where >> go s l x >> | x > m = s / fromIntegral l >> | otherwise = go (s+x) (l+1) (x+1 >> >> One version makes it instantly clear, at a glance, what is happening. >> The other requires you to mentally walk round a look, imperative >> style, to figure out what's happening. It's not a *big* deal, but >> it's unfortunate. >> >> I'm more worried about what happens in less trivial examples. [Let's >> face it, who wants to compute the sum of the numbers from 1 to N?] > > Hm, it seems like you're expecting magic, aren't you? > Well, obviously it would be nice, wouldn't it? ;-) > Of course the first equation is easier to read, but it's no surprise > that this may actually be slower. Like the imperative bubblesort is > easier to read than the imperative quicksort but far slower. I'm just saying, I prefer it when somebody posts some tiny snippet of Haskell that does the same thing as a 40-line C program, and then show how using some novel technique they just invented, the Haskell version actually outperforms C even though it's more reasable and more maintainable. Hey, who *wouldn't* like to have their cake and eat it too? :-) But yeah, I get the point. Everybody wants me to be quiet and go away. So I'll go be quiet now... From daniel.is.fischer at web.de Fri May 16 16:25:40 2008 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Fri May 16 16:17:27 2008 Subject: [Haskell-cafe] Re: Proving my point In-Reply-To: <20080516213347.23d0b77a@solaris> References: <20080516194250.4f05e8be@solaris> <482DD7DC.2060601@btinternet.com> <20080516213347.23d0b77a@solaris> Message-ID: <200805162225.40440.daniel.is.fischer@web.de> Am Freitag, 16. Mai 2008 21:33 schrieb Achim Schneider: > Andrew Coppin wrote: > > Wait... "unexpected end of input; expecting [...] end of input [...]" > > > > That's just *wrong*...! ;-) > > > > But don't despaire - show us your parser and what it's supposed to > > parse, and I'm sure somebody [maybe even me] will be able to tell you > > what's up. > > This is what I came up with while simplifying the parser: > > import Text.Parsec > > identifier = do > whiteSpace > s <- many1 letter > whiteSpace > return s > > whiteSpace = do > eof <|> ((many $ choice [ char ' ', newline ]) >> return ()) > > main = do > let syn = runParser (do > char '\\' > many1 identifier > char ':' > whiteSpace > identifier > whiteSpace > ) () "" "\\a b" > print syn running char '\\' on input "\\a b", okay, no problem. running many1 identifier on remaining input "a b" 1. whiteSpace: no eof, many (choice [char ' ', newline) returns [], all fine, nothing consumed 2. many1 letter, remainin input begins with 'a', okay, many1 letter returns "a", remaining input " b" 3. whiteSpace: n eof, one ' ' ~> ' ' consumed, remains "b" first identifier parsed, try another one. whiteSpace again consumes nothing, many1 letter returns "b", remaining input is null. whiteSpace finds eof, second identifier parsed, all input consumed. Now there are two options for a successful parse, a) another identifier b) ':' a) 1. whiteSpace, finds eof, consumes nothing, success 2. many1 letter fails immediately, nothing consumed, overall, identifier fails without consuming anything. b) char ':' fails without consumption. Drat, I want an identifier or a ':' here, I don't expect end of input yet. "unexpected end of input" "expecting " Lemme look what would I need here to continue. Ah, an identifier, how would that start? Oh, yes it could start with "end of input" what else? many (choice [char ' ', newline]), 'many', hmm doesn't require anything specific, I'll skip that, what then? many1 letter, oh, yes ", letter" Or I could continue with char ':' here, so " or \":\"" Oops, bad definition of whiteSpace, I'd say. Don't accept an eof unless you really don't want to continue. > > Admittedly, this is a quite degenerate case crouching in at least 10 > corners simultaneously. Anyway, I get > > % ./test > Left (line 1, column 5): > unexpected end of input > expecting end of input, letter or ":" > > > and if I change it to > > whiteSpace = do > (many eof >> return ()) > <|> ((many $ choice [ char ' ', newline ]) >> return ()) > > Left (line 1, column 3): > unexpected " " > expecting letter, end of input or ":" Sure thing, (many eof) never fails, so the new whiteSpace is in fact many eof >> return () So after having parsed the first identifier, we're trying to either parse another one or a ':'. First, identifier is tried. many eof succeeds, now try letter, that fails. so we have a successful start into many eof, hence, for identifier to succeed, we need more eofs or a letter next ~> "expecting end of input, letter" Or we have no more identifiers, then we need " or \":\"" > > > Please, please don't ask me for the rationale of using eof like this, > you would get the same answer as if you'd ask me why I cast a stone into > the sea. And why did you do that? From flippa at flippac.org Fri May 16 16:25:01 2008 From: flippa at flippac.org (Philippa Cowderoy) Date: Fri May 16 16:17:38 2008 Subject: [Haskell-cafe] Re: Proving my point In-Reply-To: <20080516213347.23d0b77a@solaris> References: <20080516194250.4f05e8be@solaris> <482DD7DC.2060601@btinternet.com> <20080516213347.23d0b77a@solaris> Message-ID: On Fri, 16 May 2008, Achim Schneider wrote: > Andrew Coppin wrote: > > > Wait... "unexpected end of input; expecting [...] end of input [...]" > > > > That's just *wrong*...! ;-) > > > > But don't despaire - show us your parser and what it's supposed to > > parse, and I'm sure somebody [maybe even me] will be able to tell you > > what's up. > > This is what I came up with while simplifying the parser: > > import Text.Parsec > > identifier = do > whiteSpace > s <- many1 letter > whiteSpace > return s > > whiteSpace = do > eof <|> ((many $ choice [ char ' ', newline ]) >> return ()) > > main = do > let syn = runParser (do > char '\\' > many1 identifier > char ':' > whiteSpace > identifier > whiteSpace > ) () "" "\\a b" > print syn > > Admittedly, this is a quite degenerate case crouching in at least 10 > corners simultaneously. Anyway, I get > > % ./test > Left (line 1, column 5): > unexpected end of input > expecting end of input, letter or ":" > Confusing, isn't it? It's almost the right message, too. I'm pretty sure the misbehaviour's because eof doesn't consume - see what happens if you put an error message on all of whiteSpace? > > and if I change it to > > whiteSpace = do > (many eof >> return ()) > <|> ((many $ choice [ char ' ', newline ]) >> return ()) > > Left (line 1, column 3): > unexpected " " > expecting letter, end of input or ":" > Which is broken for your purposes, but that's because many always succeeds so the changed whiteSpace doesn't actually eat whitespace. > > Please, please don't ask me for the rationale of using eof like this, > you would get the same answer as if you'd ask me why I cast a stone into > the sea. > As a matter of general practice I'd suggest including eof exactly once, as in: topLevel = do {r <- realTopLevel; eof; return r} realTopLevel = ... Which isn't to say that you haven't run into something confusing and possibly broken here, of course. -- flippa@flippac.org "The reason for this is simple yet profound. Equations of the form x = x are completely useless. All interesting equations are of the form x = y." -- John C. Baez From flippa at flippac.org Fri May 16 16:40:18 2008 From: flippa at flippac.org (Philippa Cowderoy) Date: Fri May 16 16:32:51 2008 Subject: [Haskell-cafe] Re: Proving my point In-Reply-To: References: <20080516194250.4f05e8be@solaris> <482DD7DC.2060601@btinternet.com> <20080516213347.23d0b77a@solaris> Message-ID: On Fri, 16 May 2008, Philippa Cowderoy wrote: > Confusing, isn't it? It's almost the right message, too. I'm pretty sure > the misbehaviour's because eof doesn't consume - see what happens if you > put an error message on all of whiteSpace? > It is indeed, and because the error merging code can't tell eof's "don't consume" from the "don't consume" try returns when its parm fails - nor is there any equivalent distinction in the error values. Which is to say: it's broken, but at least I know how to fix it in the library. -- flippa@flippac.org "The reason for this is simple yet profound. Equations of the form x = x are completely useless. All interesting equations are of the form x = y." -- John C. Baez From barsoap at web.de Fri May 16 16:47:40 2008 From: barsoap at web.de (Achim Schneider) Date: Fri May 16 16:41:32 2008 Subject: [Haskell-cafe] Re: Proving my point References: <20080516194250.4f05e8be@solaris> <482DD7DC.2060601@btinternet.com> <20080516213347.23d0b77a@solaris> <200805162225.40440.daniel.is.fischer@web.de> Message-ID: <20080516224740.44b1c333@solaris> Daniel Fischer wrote: > [very helpful stuff] > > > Please, please don't ask me for the rationale of using eof like > > this, you would get the same answer as if you'd ask me why I cast a > > stone into the sea. > > And why did you do that? > To cast away something I don't understand. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. From barsoap at web.de Fri May 16 16:49:00 2008 From: barsoap at web.de (Achim Schneider) Date: Fri May 16 16:43:43 2008 Subject: [Haskell-cafe] Re: Proving my point References: <20080516194250.4f05e8be@solaris> Message-ID: <20080516224900.6429d4e6@solaris> Philippa Cowderoy wrote: > On Fri, 16 May 2008, Achim Schneider wrote: > > Guess who ran into that with a separate token for > layout-inserted braces? > It can't be me, as I attempted to be as lazy as possible, not going for a tokenising pass, and ended up being too lazy. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. From barsoap at web.de Fri May 16 16:53:00 2008 From: barsoap at web.de (Achim Schneider) Date: Fri May 16 16:48:39 2008 Subject: [Haskell-cafe] Re: Write Haskell as fast as C. [Was: Re: GHC predictability] References: <20080515183132.GD31635@scytale.galois.com> <482DD8E4.2060509@btinternet.com> <482DDB38.2040108@serpentine.com> <482DDDC4.4020002@btinternet.com> <482DED4C.6020609@btinternet.com> Message-ID: <20080516225300.447e1a7d@solaris> Andrew Coppin wrote: > But yeah, I get the point. Everybody wants me to be quiet and go > away. So I'll go be quiet now... > Yes and no. Everybody wants you to be quiet and go to your study, writing a compiler that's Smart Enough(tm). We will let you out as soon as you're finished and supply you with pizza and crackers from time to time. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. From flippa at flippac.org Fri May 16 16:57:00 2008 From: flippa at flippac.org (Philippa Cowderoy) Date: Fri May 16 16:49:32 2008 Subject: [Haskell-cafe] Re: Proving my point In-Reply-To: <20080516224900.6429d4e6@solaris> References: <20080516194250.4f05e8be@solaris> <20080516224900.6429d4e6@solaris> Message-ID: On Fri, 16 May 2008, Achim Schneider wrote: > Philippa Cowderoy wrote: > > > On Fri, 16 May 2008, Achim Schneider wrote: > > > > Guess who ran into that with a separate token for > > layout-inserted braces? > > > It can't be me, as I attempted to be as lazy as possible, not going for > a tokenising pass, and ended up being too lazy. > Nah, you just picked the wrong way to attempt discipline. I don't use separate tokenising/lexing passes in a lot of my code (though you can't really avoid it when you want to do layout), it's a matter of knowing how it's done. Unless you've got a lexical structure that prevents it (which is to say, there're situations in which two tokens following each other aren't allowed to have whitespace between them), it's a good idea to have your token productions eat any whitespace following them, and then your toplevel becomes: do {whitespace; r <- realTopLevel; eof; return r} and then you need never worry about it again. -- flippa@flippac.org Ivanova is always right. I will listen to Ivanova. I will not ignore Ivanova's recomendations. Ivanova is God. And, if this ever happens again, Ivanova will personally rip your lungs out! From dons at galois.com Fri May 16 17:02:06 2008 From: dons at galois.com (Don Stewart) Date: Fri May 16 16:55:51 2008 Subject: [Haskell-cafe] Re: Write Haskell as fast as C. [Was: Re: GHC predictability] In-Reply-To: <482DEC48.7080304@btinternet.com> References: <20080515183132.GD31635@scytale.galois.com> <482DD8E4.2060509@btinternet.com> <20080516190422.GA13340@scytale.galois.com> <482DEC48.7080304@btinternet.com> Message-ID: <20080516210206.GD13340@scytale.galois.com> andrewcoppin: > Don Stewart wrote: > >I don't understand what's ugly about: > > > > go s l x | x > m = s / fromIntegral l > > | otherwise = go (s+x) (l+1) (x+1) > > > >And the point is that it is *reliable*. If you make your money day in, > >day out > >writing Haskell, and you don't want to rely on radical transformations for > >correctness, this is a sensible idiom to follow. > > > >Nothing beats understanding what you're writing at all levels of > >abstraction. > > > > What sets Haskell apart from every other programming language ever used > in mainstream programming? You might say conciseness, or the ability to > use lazy evaluation to structure your code in usual ways, or something > like that. I would say what sets Haskell apart is "abstraction". There > are other things, but this is the big one. Haskell allows you to > abstract almost everything. The result is often highly succinct yet very > readable programs. It would seem a terribly shame if you always have to > throw away Haskell's key advantage to get decent runtime performance. > > If you're trying to get a real program to work, right now, then yes, you > may have no choice. But that doesn't mean we shouldn't strive for ways > to keep code high-level yet performant. > > [I'm curios about your other comment. Does anybody, anywhere in the > world, actually make *money* using Haskell? This seems rather unlikely > to me...] Yes, and that's the point. When money is on the line not every line is going to use a research result from the last 5 years. You'll have a lot of code using standard idioms, reliable techniques. Because that's what gets the job done. -- Don From andrewcoppin at btinternet.com Fri May 16 17:03:13 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Fri May 16 16:56:30 2008 Subject: [Haskell-cafe] Re: Write Haskell as fast as C. [Was: Re: GHC predictability] In-Reply-To: <20080516225300.447e1a7d@solaris> References: <20080515183132.GD31635@scytale.galois.com> <482DD8E4.2060509@btinternet.com> <482DDB38.2040108@serpentine.com> <482DDDC4.4020002@btinternet.com> <482DED4C.6020609@btinternet.com> <20080516225300.447e1a7d@solaris> Message-ID: <482DF691.3020109@btinternet.com> Achim Schneider wrote: > Andrew Coppin wrote: > > >> But yeah, I get the point. Everybody wants me to be quiet and go >> away. So I'll go be quiet now... >> >> > Yes and no. Everybody wants you to be quiet and go to your study, > writing a compiler that's Smart Enough(tm). We will let you out as soon > as you're finished and supply you with pizza and crackers from time to > time. > I... I think you just described my ideal place of employment! 0_0 It sure as hell beats the living daylights out of the nonesense I just spent 9-5 today dealing with. :-S From barsoap at web.de Fri May 16 17:14:04 2008 From: barsoap at web.de (Achim Schneider) Date: Fri May 16 17:07:49 2008 Subject: [Haskell-cafe] Re: Proving my point References: <20080516194250.4f05e8be@solaris> <20080516224900.6429d4e6@solaris> Message-ID: <20080516231404.0697542d@solaris> Philippa Cowderoy wrote: > On Fri, 16 May 2008, Achim Schneider wrote: > > > Philippa Cowderoy wrote: > > > > > On Fri, 16 May 2008, Achim Schneider wrote: > > > > > > Guess who ran into that with a separate token for > > > layout-inserted braces? > > > > > It can't be me, as I attempted to be as lazy as possible, not going > > for a tokenising pass, and ended up being too lazy. > > > > Nah, you just picked the wrong way to attempt discipline. I don't use > separate tokenising/lexing passes in a lot of my code (though you > can't really avoid it when you want to do layout), it's a matter of > knowing how it's done. Unless you've got a lexical structure that > prevents it (which is to say, there're situations in which two tokens > following each other aren't allowed to have whitespace between them), > it's a good idea to have your token productions eat any whitespace > following them, and then your toplevel becomes: > > do {whitespace; r <- realTopLevel; eof; return r} > > and then you need never worry about it again. > My problem is that realTopLevel = expr, and that I get into an infinite recursion, never "closing" enough parens, never hitting eof. Additionally, two passes are definitely easier to reason about, and it's wise to be lazy there. Btw: Is there any way to make Parsec return a tree of things it tried? The end-user error messages are quite often just not informative enough while debugging the parser itself. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. From flippa at flippac.org Fri May 16 17:42:07 2008 From: flippa at flippac.org (Philippa Cowderoy) Date: Fri May 16 17:34:49 2008 Subject: [Haskell-cafe] Re: Write Haskell as fast as C. [Was: Re: GHC predictability] In-Reply-To: <20080516190422.GA13340@scytale.galois.com> References: <20080515183132.GD31635@scytale.galois.com> <482DD8E4.2060509@btinternet.com> <20080516190422.GA13340@scytale.galois.com> Message-ID: On Fri, 16 May 2008, Don Stewart wrote: > I don't understand what's ugly about: > > go s l x | x > m = s / fromIntegral l > | otherwise = go (s+x) (l+1) (x+1) > I suspect you've been looking at low-level code too long. How about the total lack of domain concepts? Try: mean n m = let (sum, length, _) = go (0,0,n) in sum / fromIntegral length where go :: (Double, Int, Double) -> (Double, Int, Double) go t@(s,l,x) | x > m = t | otherwise = go (s+x) (l+1) (x+1) as a starting point. I might consider generalising to a "while" HOF while I'm at it, because ultimately this is a while loop. Admittedly that would be relying on the implementation doing a little inlining, which you're not reliant on. Given the audience it'd be good to see some of the working to pull it off via fusion in a comment too: -- [1 .. d ] = unfoldr (let f n | n > d = Nothing -- f n = Just (n,n+1) in f) 1 -- sum = foldr ... -- length = foldr ... -- sumAndLength = foldr ... (as calculated from the above) -- mean [1 .. d] = s / l where -- (sum, length) = sumAndLength [1 .. d] -- = sumAndLength . unfoldr ... -- = foldr ... . unfoldr ... -- = ... Some things it might be nice to have and/or know about: * We really ought to be able to build the sumAndLength fold by building the appropriate tuple and tuple function from its components - with there being a standard idiom for naming them, and a library of such things to hand. Same thing for go, too - this means we retain the domain concepts in its implementation by default. The interesting thing about go is that we ourselves running the guts of an unfold at the same time, which means it supplies our termination criteria - I suspect I ought to post a 'most general' form of go on that basis soon? * Does nesting unboxed tuples work appropriately? I was about to suggest a standard way of doing the wiring for the tupling as well, but so long as nesting unboxed tuples works and the optimiser 'gets it' then there's an arrow instance that ought to do nicely! While not quite as low-level, the resulting code should hopefully be easy bait for GHC's optimiser (if not, someone please yell!), while both retaining much of the domain info of the original code and conveying much about how it's made to go fast. > Nothing beats understanding what you're writing at all levels of abstraction. > How about ensuring that a casual reader can do the same quickly? -- flippa@flippac.org Performance anxiety leads to premature optimisation From flippa at flippac.org Fri May 16 17:46:38 2008 From: flippa at flippac.org (Philippa Cowderoy) Date: Fri May 16 17:39:10 2008 Subject: [Haskell-cafe] Re: Proving my point In-Reply-To: <20080516231404.0697542d@solaris> References: <20080516194250.4f05e8be@solaris> <20080516224900.6429d4e6@solaris> <20080516231404.0697542d@solaris> Message-ID: On Fri, 16 May 2008, Achim Schneider wrote: > My problem is that realTopLevel = expr, and that I get into an infinite > recursion, never "closing" enough parens, never hitting eof. Have you run into the left-recursion trap, by any chance? This doesn't work: expr = do expr; ... You can cover common cases with combinators like many* and chain* though. > Btw: Is there any way to make Parsec return a tree of things it tried? > The end-user error messages are quite often just not informative enough > while debugging the parser itself. > If you're willing to accept a little pain, you can write a few helper functions akin to that keep a log in Parsec's state and extract it from there. -- flippa@flippac.org Society does not owe people jobs. Society owes it to itself to find people jobs. From flippa at flippac.org Fri May 16 17:55:46 2008 From: flippa at flippac.org (Philippa Cowderoy) Date: Fri May 16 17:48:19 2008 Subject: [Haskell-cafe] Re: Write Haskell as fast as C. [Was: Re: GHC predictability] In-Reply-To: <482DD8E4.2060509@btinternet.com> References: <20080515183132.GD31635@scytale.galois.com> <482DD8E4.2060509@btinternet.com> Message-ID: On Fri, 16 May 2008, Andrew Coppin wrote: > Obviously most people would prefer to write declarative code and feel secure > that the compiler is going to produce something efficient. > Ultimately the only way to do this is to stick to Einstein's advice - make things as simple as possible but no simpler. This means that if you care about speed then somewhere, the structure that enables a fast implementation needs to be declared so that the compiler can work with it. For example, you might not want to hand-fuse (I know I get bored of it pretty quickly) but the possibility of fusion will have to be clear. If you don't want to have to do it yourself (or don't know how!) and you want to be confident that something's going to run fast, that means a library covering a range of known cases that'll all go quickly. Don has been a major contributor here! But it's hard work, and if you don't understand how fast code is structured then ultimately you won't be able to predict - there'll never be a guarantee that lets you be completely ignorant. -- flippa@flippac.org 'In Ankh-Morpork even the shit have a street to itself... Truly this is a land of opportunity.' - Detritus, Men at Arms From ketil at malde.org Fri May 16 17:57:48 2008 From: ketil at malde.org (Ketil Malde) Date: Fri May 16 17:51:08 2008 Subject: [Haskell-cafe] Re: Write Haskell as fast as C. In-Reply-To: <482DDDC4.4020002@btinternet.com> (Andrew Coppin's message of "Fri\, 16 May 2008 20\:17\:24 +0100") References: <20080515183132.GD31635@scytale.galois.com> <482DD8E4.2060509@btinternet.com> <482DDB38.2040108@serpentine.com> <482DDDC4.4020002@btinternet.com> Message-ID: <87mympnc83.fsf@nmd9999.imr.no> Andrew Coppin writes: > I'm more worried about what happens in less trivial examples. [Let's > face it, who wants to compute the sum of the numbers from 1 to N?] Inspired by Don's blog post, and coincidentally working on a program where profiling points to one particular, short function as responsible for 60% of the work, I thought this would be a good time to look into core and reveal the deep secrets of my code. This is the function: > mkAnn :: ByteString -> Annotation > mkAnn = pick . B.words > where pick (_db:up:rest) = pick' up $ getGo rest > pick' up' (go:_:ev:_) = Ann (B.copy up') (read $ B.unpack go) (read $ B.unpack ev) > getGo = dropWhile (not . B.isPrefixOf (pack "GO:")) A bit clunky, but simple enough: given a line of input, break into words, pick word number two, the word starting with "GO:" and the second-to-next word. Here are the data types involved: > data Annotation = Ann !UniProtAcc !GoTerm !EvidenceCode deriving (Show) > newtype GoTerm = GO Int deriving (Eq,Ord) > type UniProtAcc = ByteString > data EvidenceCode = ... -- many nullary constructors Unfortunately, this results in no less than four pages of core, with tons of less intelligible identfiers and nested cases and whatnot... any idea why this would be so slow? -k -- If I haven't seen further, it is by standing in the footprints of giants From dons at galois.com Fri May 16 17:59:33 2008 From: dons at galois.com (Don Stewart) Date: Fri May 16 17:53:16 2008 Subject: [Haskell-cafe] Re: Write Haskell as fast as C. In-Reply-To: <87mympnc83.fsf@nmd9999.imr.no> References: <20080515183132.GD31635@scytale.galois.com> <482DD8E4.2060509@btinternet.com> <482DDB38.2040108@serpentine.com> <482DDDC4.4020002@btinternet.com> <87mympnc83.fsf@nmd9999.imr.no> Message-ID: <20080516215933.GH13340@scytale.galois.com> ketil: > Andrew Coppin writes: > > > I'm more worried about what happens in less trivial examples. [Let's > > face it, who wants to compute the sum of the numbers from 1 to N?] > > Inspired by Don's blog post, and coincidentally working on a program > where profiling points to one particular, short function as > responsible for 60% of the work, I thought this would be a good time > to look into core and reveal the deep secrets of my code. This is the > function: > > > mkAnn :: ByteString -> Annotation > > mkAnn = pick . B.words > > where pick (_db:up:rest) = pick' up $ getGo rest > > pick' up' (go:_:ev:_) = Ann (B.copy up') (read $ B.unpack go) (read $ B.unpack ev) > > getGo = dropWhile (not . B.isPrefixOf (pack "GO:")) > read $ B.unpack go Looks suspicious. You're unpacking to lists. ByteString performance rule 1: don't unpack to lists. -- Don From dpiponi at gmail.com Fri May 16 18:00:28 2008 From: dpiponi at gmail.com (Dan Piponi) Date: Fri May 16 17:54:02 2008 Subject: [Haskell-cafe] Short circuiting and the Maybe monad In-Reply-To: <482DDA83.4070907@btinternet.com> References: <65113aef0805121509s6b4e76bbxd23e86070a2a0be3@mail.gmail.com> <482A7AF0.6020008@tcs.inf.tu-dresden.de> <482B378E.802@btinternet.com> <482DDA83.4070907@btinternet.com> Message-ID: <625b74080805161500u78843f09w447cacc49d08d8fa@mail.gmail.com> On Fri, May 16, 2008 at 12:03 PM, Andrew Coppin wrote: > Since a tree is a kind of container, yes, it should be a monad. [I'm still > not really sure whether it's "useful".] Not so much containers in general, but 'flattenable' containers. You can flatten a list of lists to a list like this: [[1,2,3],[4,5],[6]] -> [1,2,3,4,5,6] Similarly you can 'flatten' some kinds of trees of trees by grafting the contained trees directly into the containing tree. But consider containers that always contain exactly two elements. It's not immediately obvious how to flatten such a thing because a container of containers will have 4 elements so at the least you'll have to throw two elements away. In fact, you can use the Reader monad as a fixed size container monad. > On the other hand, Maybe is a rather odd kind of container, but a very useful monad... Do you really find it odd? It's like many ordinary household containers: there's room to contain one object, but it might in fact be empty. -- Dan From westondan at imageworks.com Fri May 16 18:08:52 2008 From: westondan at imageworks.com (Dan Weston) Date: Fri May 16 18:02:27 2008 Subject: [Haskell-cafe] Re: Write Haskell as fast as C. In-Reply-To: <87mympnc83.fsf@nmd9999.imr.no> References: <20080515183132.GD31635@scytale.galois.com> <482DD8E4.2060509@btinternet.com> <482DDB38.2040108@serpentine.com> <482DDDC4.4020002@btinternet.com> <87mympnc83.fsf@nmd9999.imr.no> Message-ID: <482E05F4.7050002@imageworks.com> Ketil Malde wrote: >> mkAnn :: ByteString -> Annotation >> mkAnn = pick . B.words >> where pick (_db:up:rest) = pick' up $ getGo rest >> pick' up' (go:_:ev:_) = Ann (B.copy up') (read $ B.unpack go) (read $ B.unpack ev) >> getGo = dropWhile (not . B.isPrefixOf (pack "GO:")) It seems at first face miraculously coincidental that the dropWhile in the getGo definition knows to stop dropping when there are exactly 4 elements, in order to match the pattern in the second parameter of the pick' definition, whose argument is provided by (getGo Rest). What magic makes this true? Just curious... From westondan at imageworks.com Fri May 16 18:10:09 2008 From: westondan at imageworks.com (Dan Weston) Date: Fri May 16 18:03:44 2008 Subject: [Haskell-cafe] Re: Write Haskell as fast as C. In-Reply-To: <482E05F4.7050002@imageworks.com> References: <20080515183132.GD31635@scytale.galois.com> <482DD8E4.2060509@btinternet.com> <482DDB38.2040108@serpentine.com> <482DDDC4.4020002@btinternet.com> <87mympnc83.fsf@nmd9999.imr.no> <482E05F4.7050002@imageworks.com> Message-ID: <482E0641.4010506@imageworks.com> Dan Weston wrote: > Ketil Malde wrote: >>> mkAnn :: ByteString -> Annotation >>> mkAnn = pick . B.words >>> where pick (_db:up:rest) = pick' up $ getGo rest >>> pick' up' (go:_:ev:_) = Ann (B.copy up') (read $ B.unpack >>> go) (read $ B.unpack ev) >>> getGo = dropWhile (not . B.isPrefixOf (pack "GO:")) > > It seems at first face miraculously coincidental that the dropWhile in > the getGo definition knows to stop dropping when there are exactly 4 > elements, in order to match the pattern in the second parameter of the > pick' definition, whose argument is provided by (getGo Rest). > > What magic makes this true? Just curious... I didn't mean "exactly 4", but "at least 3". Otherwise, I'm still curious! :) From barsoap at web.de Fri May 16 18:17:38 2008 From: barsoap at web.de (Achim Schneider) Date: Fri May 16 18:11:21 2008 Subject: [Haskell-cafe] Re: Proving my point References: <20080516194250.4f05e8be@solaris> <20080516224900.6429d4e6@solaris> <20080516231404.0697542d@solaris> Message-ID: <20080517001738.62b0f291@solaris> Philippa Cowderoy wrote: > On Fri, 16 May 2008, Achim Schneider wrote: > > > My problem is that realTopLevel = expr, and that I get into an > > infinite recursion, never "closing" enough parens, never hitting > > eof. > > Have you run into the left-recursion trap, by any chance? > > This doesn't work: > > expr = do expr; ... > expr = do {e <- parens expr; return $ Nest e} <|> lambda <|> _let <|> try app <|> atom There's at least one token before any recursion, so I guess not. After all, it terminates. It's my state that does not succeed in directing the parser not to mess up, so I'm reimplementing the thing as a two-pass but stateless parser now. Definitely the easier and clearer thing to do: I can have an end of line token that carries the number of trailing spaces, so I got perfect indent information without any pain involved, at all, and don't have to make parsers fail based on state. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. From ketil at malde.org Fri May 16 18:31:25 2008 From: ketil at malde.org (Ketil Malde) Date: Fri May 16 18:24:45 2008 Subject: [Haskell-cafe] Re: Write Haskell as fast as C. In-Reply-To: <482E05F4.7050002@imageworks.com> (Dan Weston's message of "Fri\, 16 May 2008 15\:08\:52 -0700") References: <20080515183132.GD31635@scytale.galois.com> <482DD8E4.2060509@btinternet.com> <482DDB38.2040108@serpentine.com> <482DDDC4.4020002@btinternet.com> <87mympnc83.fsf@nmd9999.imr.no> <482E05F4.7050002@imageworks.com> Message-ID: <87fxshnao2.fsf@nmd9999.imr.no> Dan Weston writes: >>> mkAnn :: ByteString -> Annotation >>> mkAnn = pick . B.words >>> where pick (_db:up:rest) = pick' up $ getGo rest >>> pick' up' (go:_:ev:_) = Ann (B.copy up') (read $ B.unpack go) (read $ B.unpack ev) >>> getGo = dropWhile (not . B.isPrefixOf (pack "GO:")) > It seems at first face miraculously coincidental that the dropWhile in > the getGo definition knows to stop dropping when there are exactly 4 > elements, in order to match the pattern in the second parameter of the > pick' definition, whose argument is provided by (getGo Rest). > What magic makes this true? Just curious... You want the long story? :-) This is for parsing the GOA file format, which contains links between proteins from the UniProt database to Gene Onthology (GO) terms. The format is not quite as regular as one would wish, but the second word is always the protein id, and whenever the GO term turns up, it is followed by something I forget (an InterPro reference perhaps) and then the evidence code - which I want. You feel happier now, I can tell. -k -- If I haven't seen further, it is by standing in the footprints of giants From flippa at flippac.org Fri May 16 18:45:51 2008 From: flippa at flippac.org (Philippa Cowderoy) Date: Fri May 16 18:38:23 2008 Subject: [Haskell-cafe] Re: Proving my point In-Reply-To: <20080517001738.62b0f291@solaris> References: <20080516194250.4f05e8be@solaris> <20080516224900.6429d4e6@solaris> <20080516231404.0697542d@solaris> <20080517001738.62b0f291@solaris> Message-ID: On Sat, 17 May 2008, Achim Schneider wrote: > There's at least one token before any recursion, so I guess not. After > all, it terminates. It's my state that does not succeed in directing > the parser not to mess up, so I'm reimplementing the thing as a > two-pass but stateless parser now. In most cases, you're better off stateless unless you've got a really good reason for it. Or at least, not using the state for anything that affects the parse itself. > Definitely the easier and clearer > thing to do: I can have an end of line token that carries the number of > trailing spaces, so I got perfect indent information without any pain > involved, at all, and don't have to make parsers fail based on state. > Definitely! Are you doing some form of layout? It's certainly not worth doing in one pass IMO, I ended up with a three pass design much like that in the Haskell 98 report. Well, that's an understatement - I took the algorithm from it! -- flippa@flippac.org There is no magic bullet. There are, however, plenty of bullets that magically home in on feet when not used in exactly the right circumstances. From barsoap at web.de Fri May 16 19:53:02 2008 From: barsoap at web.de (Achim Schneider) Date: Fri May 16 19:46:49 2008 Subject: [Haskell-cafe] Re: Proving my point References: <20080516194250.4f05e8be@solaris> <20080516224900.6429d4e6@solaris> <20080516231404.0697542d@solaris> <20080517001738.62b0f291@solaris> Message-ID: <20080517015302.33ee996f@solaris> Philippa Cowderoy wrote: > On Sat, 17 May 2008, Achim Schneider wrote: > > > Definitely the easier and clearer > > thing to do: I can have an end of line token that carries the > > number of trailing spaces, so I got perfect indent information > > without any pain involved, at all, and don't have to make parsers > > fail based on state. > > > > Definitely! Are you doing some form of layout? Yes, /pair x y m: m x y /fst z: z \p q: p /snd z: z \p q: q /numbers: pair one two /run: pair (fst numbers) (snd numbers) run is supposed to work (/ indicates a let). I'm trying to purge scheme out of my mind by implementing something that looks quite like it, and then change it. The rule is simple: An indented line continues the previous, and a non-indented closes every opened paren except one from the previous line, eof closing all that are left. I still have to think about recursive lets, but I guess I will go unlambda and just include a Y combinator, keeping the syntax simple. OTOH, I'm thinking about experimenting with a thing remotely resembling varargs and streams, being able to generate and consume possibly infinite argument streams, somewhat equalling tuples, lists and application. Just playing around, you know. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. From seanmcl at gmail.com Fri May 16 21:22:10 2008 From: seanmcl at gmail.com (Sean McLaughlin) Date: Fri May 16 21:15:46 2008 Subject: [Haskell-cafe] alex + happy parser problem Message-ID: <6579f8680805161822y6fa78314i60cb5cf29817e431@mail.gmail.com> Hi, To learn alex and happy, I'm trying to write a parser for a simple expression language. When I wrote my own lexer and just used happy, it was fine. When I used the basic wrapper of alex it was also fine. However, when I use the posn wrapper to get position information, I get a strange exception when the parse error occurs at the end of the input. For example, parsing "1 + " yields "Internal Happy error" rather than something like "Parse error at line 1, column 5" The lexer and parser are attached. Can anyone see what I'm doing wrong? calling parse "1+" yields a "Internal Happy error" instead of a parse error as I would expect. Thanks, Sean ------------------ -- Lexer ------------------ { module ExprLexer ( Token(..), AlexPosn(..), alexScanTokens, tokenPosn ) where } %wrapper "posn" $digit = 0-9 tokens :- $digit+ { (\p s -> Int p (read s)) } [\+] { (\p s -> Sym p (head s)) } { data Token = Sym AlexPosn Char | Int AlexPosn Int deriving (Eq, Show) tokenPosn (Sym p _) = p tokenPosn (Int p _) = p } -------------------------- --- Parser -------------------------- { module ExprParser where import ExprLexer (Token(..), alexScanTokens, tokenPosn, AlexPosn(..)) } %name parseExp %tokentype { Token } %token int { Int _ $$ } '+' { Sym _ '+' } %right '+' %% Exp : Exp '+' Exp { Add $1 $3 } | int { Const $1 } { data Expr = Const Int | Add Expr Expr deriving Show parse :: String -> Expr parse = parseExp . alexScanTokens happyError :: [Token] -> a happyError tks = error ("Parse error at " ++ lcn ++ "\n") where lcn = case tks of [] -> "end of file" tk:_ -> "line " ++ show l ++ ", column " ++ show c where AlexPn _ l c = tokenPosn tk } From vigalchin at gmail.com Sat May 17 00:51:56 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Sat May 17 00:45:31 2008 Subject: [Haskell-cafe] ghc on Ubuntu Linux? Message-ID: <5ae4f2ba0805162151l9ada3fdy7288ca8dda8776e5@mail.gmail.com> Hello, I am running ghc and tools on Ubuntu. I seem to be running into very strange problems between ghc-pkg and the Ubuntu package manager. Suddenly "runhaskell Setup.hs configure" just stops working ... Are any other ghc/Ubuntu users running into problems? If so, please tell me what problems. This is killing my Haskell work! Regards, Vasili -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080516/6422dacd/attachment.htm From vigalchin at gmail.com Sat May 17 01:01:42 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Sat May 17 00:55:16 2008 Subject: [Haskell-cafe] Re: ghc on Ubuntu Linux? In-Reply-To: <5ae4f2ba0805162151l9ada3fdy7288ca8dda8776e5@mail.gmail.com> References: <5ae4f2ba0805162151l9ada3fdy7288ca8dda8776e5@mail.gmail.com> Message-ID: <5ae4f2ba0805162201y1f05dbb4r4b4ee04c7783c249@mail.gmail.com> ghc-pkg list gives me .... vigalchin@ubuntu:~$ ghc-pkg list /usr/local/lib/ghc-6.8.2/package.conf: Cabal-1.2.3.0, GLUT-2.1.1.1, HUnit-1.2.0.0, OpenGL-2.2.1.1, QuickCheck-1.1.0.0, array-0.1.0.0, base-3.0.1.0, bytestring-0.9.0.1, cgi-3001.1.5.1, containers-0.1.0.1, directory-1.0.0.0, fgl-5.4.1.1, filepath-1.1.0.0, (ghc-6.8.2), haskell-src-1.0.1.1, haskell98-1.0.1.0, hpc-0.5.0.0, html-1.0.1.1, mtl-1.1.0.0, network-2.1.0.0, old-locale-1.0.0.0, old-time-1.0.0.0, packedstring-0.1.0.0, parallel-1.0.0.0, parsec-2.1.0.0, pretty-1.0.0.0, process-1.0.0.0, random-1.0.0.0, readline-1.0.1.0, regex-base-0.72.0.1, regex-compat-0.71.0.1, regex-posix-0.72.0.2, rts-1.0, stm-2.1.1.0, template-haskell-2.2.0.0, time-1.1.2.0, unix-2.3.0.0, xhtml-3000.0.2.1 I am using version ghc-6.8.2..... V On Fri, May 16, 2008 at 11:51 PM, Galchin, Vasili wrote: > Hello, > > I am running ghc and tools on Ubuntu. I seem to be running into very > strange problems between ghc-pkg and the Ubuntu package manager. Suddenly > "runhaskell Setup.hs configure" just stops working ... Are any other > ghc/Ubuntu users running into problems? If so, please tell me what problems. > This is killing my Haskell work! > > Regards, Vasili > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080517/db568d20/attachment.htm From a.biurvOir4 at asuhan.com Sat May 17 01:24:15 2008 From: a.biurvOir4 at asuhan.com (Kim-Ee Yeoh) Date: Sat May 17 01:17:49 2008 Subject: [Haskell-cafe] Short circuiting and the Maybe monad In-Reply-To: <625b74080805161500u78843f09w447cacc49d08d8fa@mail.gmail.com> References: <65113aef0805121509s6b4e76bbxd23e86070a2a0be3@mail.gmail.com> <482A7AF0.6020008@tcs.inf.tu-dresden.de> <482B378E.802@btinternet.com> <482DDA83.4070907@btinternet.com> <625b74080805161500u78843f09w447cacc49d08d8fa@mail.gmail.com> Message-ID: <17288351.post@talk.nabble.com> Dan Piponi-2 wrote: > > In fact, you can use the Reader monad as a fixed size container monad. > Interesting that you say that. Reader seems to me more as an anti-container monad. -- View this message in context: http://www.nabble.com/Short-circuiting-and-the-Maybe-monad-tp17200772p17288351.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. From vigalchin at gmail.com Sat May 17 02:07:21 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Sat May 17 02:00:56 2008 Subject: [Haskell-cafe] Re: ghc on Ubuntu Linux? In-Reply-To: <5ae4f2ba0805162201y1f05dbb4r4b4ee04c7783c249@mail.gmail.com> References: <5ae4f2ba0805162151l9ada3fdy7288ca8dda8776e5@mail.gmail.com> <5ae4f2ba0805162201y1f05dbb4r4b4ee04c7783c249@mail.gmail.com> Message-ID: <5ae4f2ba0805162307w666a68eerfaf5aaf170ade4a6@mail.gmail.com> PS I have always installed ghc first via the Ubuntu package installer followed by a build from ghc 6.8.2 source! Vasili On Sat, May 17, 2008 at 12:01 AM, Galchin, Vasili wrote: > ghc-pkg list gives me .... > > > vigalchin@ubuntu:~$ ghc-pkg list > /usr/local/lib/ghc-6.8.2/package.conf: > Cabal-1.2.3.0, GLUT-2.1.1.1, HUnit-1.2.0.0, OpenGL-2.2.1.1, > QuickCheck-1.1.0.0, array-0.1.0.0, base-3.0.1.0, > bytestring-0.9.0.1, cgi-3001.1.5.1, containers-0.1.0.1, > directory-1.0.0.0, fgl-5.4.1.1, filepath-1.1.0.0, (ghc-6.8.2), > haskell-src-1.0.1.1, haskell98-1.0.1.0, hpc-0.5.0.0, html-1.0.1.1, > mtl-1.1.0.0, network-2.1.0.0, old-locale-1.0.0.0, old-time-1.0.0.0, > packedstring-0.1.0.0, parallel-1.0.0.0, parsec-2.1.0.0, > pretty-1.0.0.0, process-1.0.0.0, random-1.0.0.0, readline-1.0.1.0, > regex-base-0.72.0.1, regex-compat-0.71.0.1, regex-posix-0.72.0.2, > rts-1.0, stm-2.1.1.0, template-haskell-2.2.0.0, time-1.1.2.0, > unix-2.3.0.0, xhtml-3000.0.2.1 > > > I am using version ghc-6.8.2..... > > > V > > > On Fri, May 16, 2008 at 11:51 PM, Galchin, Vasili > wrote: > >> Hello, >> >> I am running ghc and tools on Ubuntu. I seem to be running into very >> strange problems between ghc-pkg and the Ubuntu package manager. Suddenly >> "runhaskell Setup.hs configure" just stops working ... Are any other >> ghc/Ubuntu users running into problems? If so, please tell me what problems. >> This is killing my Haskell work! >> >> Regards, Vasili >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080517/cb078c7f/attachment.htm From dave at zednenem.com Sat May 17 02:38:16 2008 From: dave at zednenem.com (David Menendez) Date: Sat May 17 02:31:50 2008 Subject: [Haskell-cafe] Short circuiting and the Maybe monad In-Reply-To: <17288351.post@talk.nabble.com> References: <65113aef0805121509s6b4e76bbxd23e86070a2a0be3@mail.gmail.com> <482A7AF0.6020008@tcs.inf.tu-dresden.de> <482B378E.802@btinternet.com> <482DDA83.4070907@btinternet.com> <625b74080805161500u78843f09w447cacc49d08d8fa@mail.gmail.com> <17288351.post@talk.nabble.com> Message-ID: <49a77b7a0805162338v4bfb2333u2b3ccf2bf0884dcc@mail.gmail.com> On Sat, May 17, 2008 at 1:24 AM, Kim-Ee Yeoh wrote: > > > Dan Piponi-2 wrote: >> >> In fact, you can use the Reader monad as a fixed size container monad. >> > > Interesting that you say that. Reader seems to me more as an anti-container > monad. You just have to think of the environment as an address into an implicit structure. For example, Bool -> a is isomorphic to (a,a). Thus, data Diag a = D { p1 :: a, p2 :: a } to :: Diag a -> (Bool -> a) to (D a b) p = if p then a else b from :: (Bool -> a) -> Diag a from f = D (f True) (f False) Some transformations applied to the monad instance for ((->) Bool) gets you: instance Monad Diag where return x = D x x D a b >>= f = D (p1 (f a), p2 (f b)) This works for any enumeration. Here's a more complex example, data Stream a = a :< Stream a type Nat = Integer -- we'll pretend this can't ever be negative to :: Stream a -> (Nat -> a) to (a :< as) 0 = a to (a :< as) n = to as n from :: (Nat -> a) -> Stream a from f = go 0 where go n = f n :< go (n + 1) shead (a :< as) = a stail (a :< as) = as instance Monad Stream where return x = x :< return x (a :< as) >>= f = shead (f a) :< (as >>= stail . f) Assuming I haven't mistyped anything, to (m >>= f) n = to (f (to m n)) n -- Dave Menendez From ketil at malde.org Sat May 17 05:02:50 2008 From: ketil at malde.org (Ketil Malde) Date: Sat May 17 04:56:10 2008 Subject: [Haskell-cafe] Re: Write Haskell as fast as C. In-Reply-To: <20080516215933.GH13340@scytale.galois.com> (Don Stewart's message of "Fri\, 16 May 2008 14\:59\:33 -0700") References: <20080515183132.GD31635@scytale.galois.com> <482DD8E4.2060509@btinternet.com> <482DDB38.2040108@serpentine.com> <482DDDC4.4020002@btinternet.com> <87mympnc83.fsf@nmd9999.imr.no> <20080516215933.GH13340@scytale.galois.com> Message-ID: <874p8xmhfp.fsf@nmd9999.imr.no> Don Stewart writes: >>> mkAnn :: ByteString -> Annotation >>> mkAnn = pick . B.words >>> where pick (_db:up:rest) = pick' up $ getGo rest >>> pick' up' (go:_:ev:_) = Ann (B.copy up') (read $ B.unpack go) (read $ B.unpack ev) >>> getGo = dropWhile (not . B.isPrefixOf (pack "GO:")) > read $ B.unpack go > > Looks suspicious. You're unpacking to lists. > > ByteString performance rule 1: don't unpack to lists. I tend to use this idiom a bit when I want to loop over the characters. The strings being unpacked is an Int and a short (two or three letter) identifier. Doing a 'go' loop would probably be faster, but a lot more work, and I was hoping the String would be deforested or fused or otherwise optimized to the bone. I wonder if the culprit is the last 'read', it reads one from a set of keywords/identifiers, and since they're upper case, I just made a data type with a matching set of nullary constructors, and derived "Read" for it. I.e: > data EvidenceCode = IAC | IUG | IFR | NAC | NR | ... deriving Show Could it be that this derived read instance is somehow very inefficient? -k -- If I haven't seen further, it is by standing in the footprints of giants From dominic.steinitz at blueyonder.co.uk Sat May 17 05:32:02 2008 From: dominic.steinitz at blueyonder.co.uk (Dominic Steinitz) Date: Sat May 17 05:25:50 2008 Subject: [Haskell-cafe] Re: Couple of formal questions References: <814617240804292014td3d79f9ve9f0e2345b851e2@mail.gmail.com> Message-ID: Creighton Hogg gmail.com> writes: > Where could I find a proof that the initial algebras & final coalgebras of CPO > coincide? I saw this referenced in the "Bananas.." paper as a fact, but am not > sure where this comes from Creighton, As promised and I hope this is what you were after. Dominic. http://idontgetoutmuch.wordpress.com/2008/05/12/isomorphic-types/ From josef.svenningsson at gmail.com Sat May 17 06:01:33 2008 From: josef.svenningsson at gmail.com (Josef Svenningsson) Date: Sat May 17 05:55:07 2008 Subject: [Haskell-cafe] Re: ghc on Ubuntu Linux? In-Reply-To: <5ae4f2ba0805162307w666a68eerfaf5aaf170ade4a6@mail.gmail.com> References: <5ae4f2ba0805162151l9ada3fdy7288ca8dda8776e5@mail.gmail.com> <5ae4f2ba0805162201y1f05dbb4r4b4ee04c7783c249@mail.gmail.com> <5ae4f2ba0805162307w666a68eerfaf5aaf170ade4a6@mail.gmail.com> Message-ID: <8dde104f0805170301t7941aca7y3847a31267f55bd0@mail.gmail.com> Vasili, I have pretty much exactly the same set up as you seem to have. I haven't had a single problem with running configure using cabal. In what sense does it stop working? Cheers, Josef 2008/5/17 Galchin, Vasili : > PS I have always installed ghc first via the Ubuntu package installer > followed by a build from ghc 6.8.2 source! > > Vasili > > > On Sat, May 17, 2008 at 12:01 AM, Galchin, Vasili > wrote: >> >> ghc-pkg list gives me .... >> >> >> vigalchin@ubuntu:~$ ghc-pkg list >> /usr/local/lib/ghc-6.8.2/package.conf: >> Cabal-1.2.3.0, GLUT-2.1.1.1, HUnit-1.2.0.0, OpenGL-2.2.1.1, >> QuickCheck-1.1.0.0, array-0.1.0.0, base-3.0.1.0, >> bytestring-0.9.0.1, cgi-3001.1.5.1, containers-0.1.0.1, >> directory-1.0.0.0, fgl-5.4.1.1, filepath-1.1.0.0, (ghc-6.8.2), >> haskell-src-1.0.1.1, haskell98-1.0.1.0, hpc-0.5.0.0, html-1.0.1.1, >> mtl-1.1.0.0, network-2.1.0.0, old-locale-1.0.0.0, old-time-1.0.0.0, >> packedstring-0.1.0.0, parallel-1.0.0.0, parsec-2.1.0.0, >> pretty-1.0.0.0, process-1.0.0.0, random-1.0.0.0, readline-1.0.1.0, >> regex-base-0.72.0.1, regex-compat-0.71.0.1, regex-posix-0.72.0.2, >> rts-1.0, stm-2.1.1.0, template-haskell-2.2.0.0, time-1.1.2.0, >> unix-2.3.0.0, xhtml-3000.0.2.1 >> >> >> I am using version ghc-6.8.2..... >> >> >> V >> >> On Fri, May 16, 2008 at 11:51 PM, Galchin, Vasili >> wrote: >>> >>> Hello, >>> >>> I am running ghc and tools on Ubuntu. I seem to be running into very >>> strange problems between ghc-pkg and the Ubuntu package manager. Suddenly >>> "runhaskell Setup.hs configure" just stops working ... Are any other >>> ghc/Ubuntu users running into problems? If so, please tell me what problems. >>> This is killing my Haskell work! >>> >>> Regards, Vasili >> > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From vigalchin at gmail.com Sat May 17 07:07:50 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Sat May 17 07:01:25 2008 Subject: [Haskell-cafe] Re: ghc on Ubuntu Linux? In-Reply-To: <8dde104f0805170301t7941aca7y3847a31267f55bd0@mail.gmail.com> References: <5ae4f2ba0805162151l9ada3fdy7288ca8dda8776e5@mail.gmail.com> <5ae4f2ba0805162201y1f05dbb4r4b4ee04c7783c249@mail.gmail.com> <5ae4f2ba0805162307w666a68eerfaf5aaf170ade4a6@mail.gmail.com> <8dde104f0805170301t7941aca7y3847a31267f55bd0@mail.gmail.com> Message-ID: <5ae4f2ba0805170407j30850crd462d64e75c9f811@mail.gmail.com> Josef, Did you consistently only use the Ubuntu package manager to install and upgrade all "ghc" tools including the compiler, cabal?Or did you ever build the ghc compiler from source on your system on top of a Ubuntu package installed ghc like I did? Vasili On Sat, May 17, 2008 at 5:01 AM, Josef Svenningsson < josef.svenningsson@gmail.com> wrote: > Vasili, > > I have pretty much exactly the same set up as you seem to have. I > haven't had a single problem with running configure using cabal. In > what sense does it stop working? > > Cheers, > > Josef > > 2008/5/17 Galchin, Vasili : > > PS I have always installed ghc first via the Ubuntu package installer > > followed by a build from ghc 6.8.2 source! > > > > Vasili > > > > > > On Sat, May 17, 2008 at 12:01 AM, Galchin, Vasili > > wrote: > >> > >> ghc-pkg list gives me .... > >> > >> > >> vigalchin@ubuntu:~$ ghc-pkg list > >> /usr/local/lib/ghc-6.8.2/package.conf: > >> Cabal-1.2.3.0, GLUT-2.1.1.1, HUnit-1.2.0.0, OpenGL-2.2.1.1, > >> QuickCheck-1.1.0.0, array-0.1.0.0, base-3.0.1.0, > >> bytestring-0.9.0.1, cgi-3001.1.5.1, containers-0.1.0.1, > >> directory-1.0.0.0, fgl-5.4.1.1, filepath-1.1.0.0, (ghc-6.8.2), > >> haskell-src-1.0.1.1, haskell98-1.0.1.0, hpc-0.5.0.0, html-1.0.1.1, > >> mtl-1.1.0.0, network-2.1.0.0, old-locale-1.0.0.0, old-time-1.0.0.0, > >> packedstring-0.1.0.0, parallel-1.0.0.0, parsec-2.1.0.0, > >> pretty-1.0.0.0, process-1.0.0.0, random-1.0.0.0, readline-1.0.1.0, > >> regex-base-0.72.0.1, regex-compat-0.71.0.1, regex-posix-0.72.0.2, > >> rts-1.0, stm-2.1.1.0, template-haskell-2.2.0.0, time-1.1.2.0, > >> unix-2.3.0.0, xhtml-3000.0.2.1 > >> > >> > >> I am using version ghc-6.8.2..... > >> > >> > >> V > >> > >> On Fri, May 16, 2008 at 11:51 PM, Galchin, Vasili > >> wrote: > >>> > >>> Hello, > >>> > >>> I am running ghc and tools on Ubuntu. I seem to be running into > very > >>> strange problems between ghc-pkg and the Ubuntu package manager. > Suddenly > >>> "runhaskell Setup.hs configure" just stops working ... Are any other > >>> ghc/Ubuntu users running into problems? If so, please tell me what > problems. > >>> This is killing my Haskell work! > >>> > >>> Regards, Vasili > >> > > > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080517/985b9eed/attachment.htm From barsoap at web.de Sat May 17 08:02:24 2008 From: barsoap at web.de (Achim Schneider) Date: Sat May 17 07:56:05 2008 Subject: [Haskell-cafe] Re: ghc on Ubuntu Linux? References: <5ae4f2ba0805162151l9ada3fdy7288ca8dda8776e5@mail.gmail.com> <5ae4f2ba0805162201y1f05dbb4r4b4ee04c7783c249@mail.gmail.com> <5ae4f2ba0805162307w666a68eerfaf5aaf170ade4a6@mail.gmail.com> <8dde104f0805170301t7941aca7y3847a31267f55bd0@mail.gmail.com> <5ae4f2ba0805170407j30850crd462d64e75c9f811@mail.gmail.com> Message-ID: <20080517140224.1962072a@solaris> "Galchin, Vasili" wrote: > Did you consistently only use the Ubuntu package manager to > install and upgrade all "ghc" tools including the compiler, cabal?Or > did you ever build the ghc compiler from source on your system on top > of a Ubuntu package installed ghc like I did? > > > On Sat, May 17, 2008 at 5:01 AM, Josef Svenningsson < > josef.svenningsson@gmail.com> wrote: > > > I have pretty much exactly the same set up as you seem to have. I > > haven't had a single problem with running configure using cabal. In > > what sense does it stop working? > > SCNR, who is asking questions here? btw: please stop that TOFU A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. From barsoap at web.de Sat May 17 09:12:44 2008 From: barsoap at web.de (Achim Schneider) Date: Sat May 17 09:06:32 2008 Subject: [Haskell-cafe] A point in favour of -XOverlappingInstances (and -XTypeSynonymInstances) Message-ID: <20080517151244.0d113655@solaris> Token.hs:103:15: Overlapping instances for Show (SourcePos, Tok) arising from a use of `anyToken' at Token.hs:103:15-22 Matching instances: instance (Show a, Show b) => Show (a, b) -- Defined in GHC.Show instance [overlap ok] Show Token -- Defined at Token.hs:(39,0)-(40,23) I was just trying _not_ to show the a of (a,b) -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. From andrewcoppin at btinternet.com Sat May 17 10:51:27 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Sat May 17 10:44:42 2008 Subject: [Haskell-cafe] Performance: MD5 Message-ID: <482EF0EF.2090207@btinternet.com> Hi folks. OK, try this: darcs get http://darcs.orphi.me.uk/MyMD5 cd MyMD5 ghc -O2 --make md5sum md5sum On my PC, it takes 3.5 seconds to compute the MD5 hash of a 10 MB file. For comparison, the md5.exe I downloaded from the Internet does it instantaneously. It's literally so fast I can't even time it. As far as I know, my program always produces the *correct* answer, it just takes far too long to do it. If anybody has any interesting insights as to why my version is so damned slow, I'd like to hear them. (Indeed, a description of the process for tracking the problem down would also be useful!) [Much to my bemusement, when I had a look at the code, I discovered that tucked away in a corner somewhere, it reads a ByteString from disk and instantly converts it to [Word8]. Uh... oops? Anyway, eliminating this changed the numbers I get from the profiler, but it's still far too slow.] From conal at conal.net Sat May 17 11:47:52 2008 From: conal at conal.net (Conal Elliott) Date: Sat May 17 11:41:26 2008 Subject: [Haskell-cafe] Re: Write Haskell as fast as C. [Was: Re: GHC predictability] In-Reply-To: <20080516190422.GA13340@scytale.galois.com> References: <20080515183132.GD31635@scytale.galois.com> <482DD8E4.2060509@btinternet.com> <20080516190422.GA13340@scytale.galois.com> Message-ID: My dream would be to write the high-level thing *and* some high-level, composable specification of my performance requirements. If the compiler can't meet the requirements, then it tells me so, together with helpful information about what broke down. Using the error message, I then add some annotations and/or tweak my code and try again. Just like static type-checking. - Conal On Fri, May 16, 2008 at 12:04 PM, Don Stewart wrote: > [...] > And the point is that it is *reliable*. If you make your money day in, day > out > writing Haskell, and you don't want to rely on radical transformations for > correctness, this is a sensible idiom to follow. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080517/fb325673/attachment.htm From bulat.ziganshin at gmail.com Sat May 17 11:52:17 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sat May 17 11:47:36 2008 Subject: [Haskell-cafe] Performance: MD5 In-Reply-To: <482EF0EF.2090207@btinternet.com> References: <482EF0EF.2090207@btinternet.com> Message-ID: <296039281.20080517195217@gmail.com> Hello Andrew, Saturday, May 17, 2008, 6:51:27 PM, you wrote: > If anybody has any interesting insights as to why my version is so > damned slow, I'd like to hear them. i equally will be interesting to hear why you think what your program should be as fast as C version? you wrote it in purely functional style. as Don wrote, if you want to reach unoptimized C-like performance, you need to write in C style - with explicit loop processing primitive types. so 1) -funbox-strict-fields 2) don't use tuples as arguments - they are lazy. you may implement strict tuples instead 3) function as a parameter is very bad unless it will be inlined but these are only half-decisions. if you need maximum efficiency, drop all this high-level code and map md5.c to haskell as it was done in Don's bloag -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From thomas.dubuisson at gmail.com Sat May 17 12:22:34 2008 From: thomas.dubuisson at gmail.com (Thomas M. DuBuisson) Date: Sat May 17 12:13:01 2008 Subject: [Haskell-cafe] Performance: MD5 In-Reply-To: <482EF0EF.2090207@btinternet.com> References: <482EF0EF.2090207@btinternet.com> Message-ID: <1211041354.2519.14.camel@Clunker> Andrew, I spent a reasonable amount of time making pureMD5 (available on hackage) faster, which mainly ment strictness annoitations and unboxing strict fields, but I also spent a good deal of time with the profiler. One of my early versions was fairly slow due to the converting of the LPS to blocks (an Isabelle proven 'blocks' function) caused O(n) space requirement. I've been meaning to revisit this to optimize more and look closly at GHC core. I'm on vacation now, but when I get back I'll try to make time to look at your code (unless its moot by then). Finally, I encourage anyone interested to make reasonably fast bytestring implementations of SHA algorithms as well - Haskell/Hackage has a number of pure and FFI implementations of MD5 but is a bit lacking in any other cryptographic algorithm. TomMD On Sat, 2008-05-17 at 15:51 +0100, Andrew Coppin wrote: > Hi folks. > > OK, try this: > > darcs get http://darcs.orphi.me.uk/MyMD5 > cd MyMD5 > ghc -O2 --make md5sum > md5sum > > On my PC, it takes 3.5 seconds to compute the MD5 hash of a 10 MB file. > For comparison, the md5.exe I downloaded from the Internet does it > instantaneously. It's literally so fast I can't even time it. As far as > I know, my program always produces the *correct* answer, it just takes > far too long to do it. > > If anybody has any interesting insights as to why my version is so > damned slow, I'd like to hear them. (Indeed, a description of the > process for tracking the problem down would also be useful!) > > [Much to my bemusement, when I had a look at the code, I discovered that > tucked away in a corner somewhere, it reads a ByteString from disk and > instantly converts it to [Word8]. Uh... oops? Anyway, eliminating this > changed the numbers I get from the profiler, but it's still far too slow.] > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From yrn001 at gmail.com Sat May 17 12:19:42 2008 From: yrn001 at gmail.com (Jeroen) Date: Sat May 17 12:18:42 2008 Subject: [Haskell-cafe] Another optimization question Message-ID: Hi, I know there's been quite some performance/optimization post lately, so I hope there still room for one more. While solving a ProjectEuler problem (27), I saw a performance issue I cannot explain. I narrowed it down to the following code (never mind that 'primes' is just [1..], the problem is the same or worse with real primes): primes :: [Int] primes = [1..] isPrime :: Int -> Bool isPrime x = isPrime' x primes where isPrime' x (p:ps) | x == p = True | x > p = isPrime' x ps | otherwise = False main = print $ length (filter (== True) (map isPrime [1..5000])) $ time ./experiment1 5000 real 0m4.037s user 0m3.378s sys 0m0.060s All good, but if I change isPrime to the simpeler isPrime x = elem x (takeWhile (<= x) primes) it takes twice as long: time ./experiment2 5000 real 0m7.837s user 0m6.532s sys 0m0.141s With real primes, it even takes 10 times as long. I tried looking at the output of ghc -ddump-simpl, as suggested in a previous post, but it's a bit over my head (newby here...). Any suggestions? Thanks a lot, Jeroen From duncan.coutts at worc.ox.ac.uk Sat May 17 12:38:12 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat May 17 12:31:17 2008 Subject: [Haskell-cafe] A point in favour of -XOverlappingInstances (and -XTypeSynonymInstances) In-Reply-To: <20080517151244.0d113655@solaris> References: <20080517151244.0d113655@solaris> Message-ID: <1211042292.5824.178.camel@localhost> On Sat, 2008-05-17 at 15:12 +0200, Achim Schneider wrote: > Token.hs:103:15: > Overlapping instances for Show (SourcePos, Tok) > arising from a use of `anyToken' at Token.hs:103:15-22 > Matching instances: > instance (Show a, Show b) => Show (a, b) -- Defined in GHC.Show > instance [overlap ok] Show Token > -- Defined at Token.hs:(39,0)-(40,23) > > I was just trying _not_ to show the a of (a,b) A point in favour of newtypes newtype Token = Token (SourcePos, Tok) instance Show Token where ... From mail at philip.in-aachen.net Sat May 17 13:22:36 2008 From: mail at philip.in-aachen.net (=?ISO-8859-15?Q?Philip_M=FCller?=) Date: Sat May 17 13:16:02 2008 Subject: [Haskell-cafe] another Newbie performance question Message-ID: <482F145C.6040908@philip.in-aachen.net> Hi everybody, I was doing an assignment in Java for my university concerning a program that reads, modifies and writes CSV files, when I suddenly had the idea of implementing parts of this in Haskell for fun. When I finished the Haskell programm, I was disappointed by the performance: To parse a 200k lines CSV file, insert a line (yes I know i could insert a line without parsing the file, that's just an example) at pos. 199999 and write the file again, the Java program takes 1.1 seconds while the Haskell program takes 12.5 seconds. I have read Don's blog post but am unsure how to implement his tips into my program, as I am still kind of a Haskell beginner. The source code (40 lines incl. comments and empty lines) and the 200k CSV file I used for testing and a smaller CSV file demonstrating the special easy-to-parse CSV syntax are available on my ftp server, ftp://baah.servegame.org/public/haskell The call syntax is e.g. main lang.csv "test","this","line" I haven't posted the source code here directly because I thought it might be too long. If someone here finds the time to look at my code and give me some hints, that would really be nice. Regards Philip From haskell at colquitt.org Sat May 17 13:45:45 2008 From: haskell at colquitt.org (John Dorsey) Date: Sat May 17 13:39:18 2008 Subject: [Haskell-cafe] Another optimization question In-Reply-To: References: Message-ID: <20080517174545.GA1310@colquitt.org> Jeroen, > isPrime :: Int -> Bool > isPrime x = isPrime' x primes > where isPrime' x (p:ps) | x == p = True > | x > p = isPrime' x ps > | otherwise = False > > main = print $ length (filter (== True) (map isPrime [1..5000])) [...] > isPrime x = elem x (takeWhile (<= x) primes) Here's a couple of things, although I don't know if they account for what you're seeing. All code is untested. 1) A simpler main would be: main = print $ length $ filter isPrime [1..5000] This version manually fuses your map and filter. Of course it's not the same if you're doing anything else besides 'length'. 2) The takeWhile in your second isPrime creates a throwaway list, which doesn't exist in the explicit-recursion isPrime. Unless this gets optimized out, this could be the droid you're looking for. I'd compile with profiling (ghc -O2 --make -prof -auto-all experiment2), and run ./experiment2 +RTS -p -s Find profiling stats in experiment2.prof, and check whether the latter version isn't allocating a lot more. When you feel like Core-diving, it's something specific to look for. 3) Maybe you can get the best of your two versions -- meaning the relative speed of the first and functional style of the second -- by writing your own 'elem' replacement that works on a sorted list. Something like this, with suitably defined elemAsc: -- elemAsc: tests presence of element in an ascending list elemAsc :: (Ord a) => a -> [a] -> Bool elemAsc ... isPrime x = elemAsc x primes Here's a good habit: abstract things like this out. Read the libraries, and look for better and more abstract patterns. Rinse, repeat. 4) This doesn't explain why the version with real primes was 10x slower. Are you comparing apples to apples? Specifically, comparing both versions of isPrime above using real primes, so both of them have to create the primes list? Does your code for real primes still use [Int] and not [Integer] or (Num t) => [t] ? I haven't invested the time yet to stare at GHC Core until it clicks, excepting a few snippets that have been discussed here. I'm not sure how early in the learning curve it's advisable. Probably depends on your background. Good luck Eulering, John From antonmuhin at gmail.com Sat May 17 13:52:05 2008 From: antonmuhin at gmail.com (anton muhin) Date: Sat May 17 13:45:37 2008 Subject: [Haskell-cafe] Another optimization question In-Reply-To: References: Message-ID: <5953a1d00805171052o6445ee4ue929243f2ac9341f@mail.gmail.com> On Sat, May 17, 2008 at 8:19 PM, Jeroen wrote: > Hi, I know there's been quite some performance/optimization post lately, > so I hope there still room for one more. While solving a ProjectEuler > problem (27), I saw a performance issue I cannot explain. I narrowed it > down to the following code (never mind that 'primes' is just [1..], > the problem is the same or worse with real primes): > > primes :: [Int] > primes = [1..] > > isPrime :: Int -> Bool > isPrime x = isPrime' x primes > where isPrime' x (p:ps) | x == p = True > | x > p = isPrime' x ps > | otherwise = False > > main = print $ length (filter (== True) (map isPrime [1..5000])) > > $ time ./experiment1 > 5000 > > real 0m4.037s > user 0m3.378s > sys 0m0.060s > > > All good, but if I change isPrime to the simpeler > > isPrime x = elem x (takeWhile (<= x) primes) > > it takes twice as long: > > time ./experiment2 > 5000 > > real 0m7.837s > user 0m6.532s > sys 0m0.141s > > With real primes, it even takes 10 times as long. > I tried looking at the output of ghc -ddump-simpl, > as suggested in a previous post, but it's a bit over > my head (newby here...). > > Any suggestions? Just a thought: in your first approach you compare any element of the list once. In second---twice: once to check if <= x and second time to check if it is equal to x. That's a hypothesis, but another implementation of isPrime: isPrime x = (== x) $ head $ dropWhile (< x) primes seems to behave closer to your first version than to the second. Note that that does unnecessary comparison as well the find first element >= x. yours, anton. From barsoap at web.de Sat May 17 14:35:22 2008 From: barsoap at web.de (Achim Schneider) Date: Sat May 17 14:29:15 2008 Subject: [Haskell-cafe] Re: another Newbie performance question References: <482F145C.6040908@philip.in-aachen.net> Message-ID: <20080517203522.3b0895fd@solaris> Philip M?ller wrote: > I have read Don's blog post but am unsure how to implement his tips > into my program, as I am still kind of a Haskell beginner. > Dan, you seem to have opened a big can of worms. If Haskell is successful, it's your fault. Without doing any compiling, staring at core nor profiling myself, I advice that you 1) traverse the list less often. 2) use ByteStrings 3) use an intermediate data structure that has better insert behaviour than a standard list, have a look at Data.Sequence 4) really, really use ByteStrings 5) listen to me if I tell you to use ByteStrings 6) if you already must write in pointless style, please don't also order the functions in a backward way. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. From daniel.is.fischer at web.de Sat May 17 14:40:04 2008 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Sat May 17 14:31:48 2008 Subject: [Haskell-cafe] Another optimization question In-Reply-To: <5953a1d00805171052o6445ee4ue929243f2ac9341f@mail.gmail.com> References: <5953a1d00805171052o6445ee4ue929243f2ac9341f@mail.gmail.com> Message-ID: <200805172040.05086.daniel.is.fischer@web.de> Am Samstag, 17. Mai 2008 19:52 schrieb anton muhin: > On Sat, May 17, 2008 at 8:19 PM, Jeroen wrote: > > Hi, I know there's been quite some performance/optimization post lately, > > so I hope there still room for one more. While solving a ProjectEuler > > problem (27), I saw a performance issue I cannot explain. I narrowed it > > down to the following code (never mind that 'primes' is just [1..], > > the problem is the same or worse with real primes): > > > > primes :: [Int] > > primes = [1..] > > > > isPrime :: Int -> Bool > > isPrime x = isPrime' x primes > > where isPrime' x (p:ps) | x == p = True > > > > | x > p = isPrime' x ps > > | otherwise = False > > > > main = print $ length (filter (== True) (map isPrime [1..5000])) > > > > $ time ./experiment1 > > 5000 > > > > real 0m4.037s > > user 0m3.378s > > sys 0m0.060s > > > > > > All good, but if I change isPrime to the simpeler > > > > isPrime x = elem x (takeWhile (<= x) primes) > > > > it takes twice as long: > > > > time ./experiment2 > > 5000 > > > > real 0m7.837s > > user 0m6.532s > > sys 0m0.141s > > > > With real primes, it even takes 10 times as long. > > I tried looking at the output of ghc -ddump-simpl, > > as suggested in a previous post, but it's a bit over > > my head (newby here...). > > > > Any suggestions? > > Just a thought: in your first approach you compare any element of the > list once. In second---twice: once to check if <= x and second time > to check if it is equal to x. That's a hypothesis, I thought so, too, but I couldn't reproduce the behaviour, so I'm not sure what happens. In fact, compiling without optimisations, the first version takes almost twice as long as the second. Compiled with -O2, the second takes about 13% more time. Using a real list of primes, dafis@linux:~/EulerProblems/Testing> ghc --make experiment -o experiment3 [1 of 1] Compiling Main ( experiment.hs, experiment.o ) Linking experiment3 ... dafis@linux:~/EulerProblems/Testing> time ./experiment3 669 real 0m0.222s user 0m0.220s sys 0m0.000s dafis@linux:~/EulerProblems/Testing> ghc --make experiment -o experiment4 [1 of 1] Compiling Main ( experiment.hs, experiment.o ) Linking experiment4 ... dafis@linux:~/EulerProblems/Testing> time ./experiment4 669 real 0m0.299s user 0m0.290s sys 0m0.000s But dafis@linux:~/EulerProblems/Testing> ghc -O2 --make experiment -o experiment3 [1 of 1] Compiling Main ( experiment.hs, experiment.o ) Linking experiment3 ... dafis@linux:~/EulerProblems/Testing> ghc -O2 --make experiment -o experiment4 [1 of 1] Compiling Main ( experiment.hs, experiment.o ) Linking experiment4 ... dafis@linux:~/EulerProblems/Testing> time ./experiment3 669 real 0m0.053s user 0m0.040s sys 0m0.010s dafis@linux:~/EulerProblems/Testing> time ./experiment4 669 real 0m0.257s user 0m0.250s sys 0m0.010s Wow! I've no idea what optimising did to the first version, but apparently it couldn't do much for the second. > but another > implementation of isPrime: > > isPrime x = (== x) $ head $ dropWhile (< x) primes With -O2, this is about 20% slower than the Jeroen's first version, without optimisations 50% faster. Strange. isPrime :: Int -> Bool isPrime x = go primes where go (p:ps) = case compare x p of LT -> False EQ -> True GT -> go ps does best (on my box), with and without optimisations (very very slightly with -O2) for a list of real primes, but not for [1 .. ]. However, more than can be squished out of fiddling with these versions could be gained from a better algorithm. > > seems to behave closer to your first version than to the second. Note > that that does unnecessary comparison as well the find first element > > >= x. > > yours, > anton. perplexed, Daniel From mg at daimi.au.dk Fri May 16 17:18:49 2008 From: mg at daimi.au.dk (Martin Geisler) Date: Sat May 17 14:38:38 2008 Subject: [Haskell-cafe] Re: Write Haskell as fast as C. References: <20080515183132.GD31635@scytale.galois.com> <482DD8E4.2060509@btinternet.com> <482DDB38.2040108@serpentine.com> <482DDDC4.4020002@btinternet.com> Message-ID: <87ej820wxy.fsf@hbox.dyndns.org> Andrew Coppin writes: > Look closer: it's hardER to read. > > mean xs = sum xs / fromIntegral (length xs) > > mean = go 0 0 n > where > go s l x > | x > m = s / fromIntegra l > | otherwise = go (s+x) (l+1) (x+1 > > One version makes it instantly clear, at a glance, what is happening. > The other requires you to mentally walk round a look, imperative > style, to figure out what's happening. It's not a *big* deal, but it's > unfortunate. I am new to Haskell and when I first saw the two versions side by side I too was disappointed with the second version. But after reading the great blog post by Don, I realized that the whole problem comes from the fact that lists in Haskell are not like arrays or vectors in other languages: you don't know how long they are before you have found the end. In other words: they behave like a linked lists -- lists that are generated lazily on demand. Because they are generated on demand you *cannot* really know the length beforehand, and thus you *must* traverse the list to its end to count the length. When the list is too big to fit in memory then it's clear that the code *must* let go of the beginning to allow the garbage collector to do its job. You wouldn't be able to work with a 7.5 GiB linked list otherwise. -- Martin Geisler VIFF (Virtual Ideal Functionality Framework) brings easy and efficient SMPC (Secure Multi-Party Computation) to Python. See: http://viff.dk/. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080516/c001efc9/attachment.bin From kerrangster at gmail.com Sat May 17 14:52:55 2008 From: kerrangster at gmail.com (D. Gregor) Date: Sat May 17 14:47:17 2008 Subject: [Haskell-cafe] Haskell-Cafe Info Page Message-ID: <7AC36395-14C7-4F96-91E9-9F973877B211@gmail.com> Hello, Common Lisp is a multiparadigm, general purpose programming language that supports imperative, functional, and object-oriented programming paradigms. Haskell is purely functional. Is this a reason why there is not macro feature in Haskell? I feel the object-oriented paradigm of CL and Scheme is the reason for the macro feature in these two languages. If it's not, then what does the macro feature provide, and why isn't it in Haskell? Douglas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080517/ebbaa2ed/attachment.htm From allbery at ece.cmu.edu Sat May 17 15:00:38 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sat May 17 14:54:11 2008 Subject: [Haskell-cafe] Haskell-Cafe Info Page In-Reply-To: <7AC36395-14C7-4F96-91E9-9F973877B211@gmail.com> References: <7AC36395-14C7-4F96-91E9-9F973877B211@gmail.com> Message-ID: On 2008 May 17, at 14:52, D. Gregor wrote: > Common Lisp is a multiparadigm, general purpose programming language > that supports imperative, functional, and object-oriented > programming paradigms. Haskell is purely functional. Is this a > reason why there is not macro feature in Haskell? I feel the object- > oriented paradigm of CL and Scheme is the reason for the macro > feature in these two languages. If it's not, then what does the > macro feature provide, and why isn't it in Haskell? Macros in Lisp have less to do with functional vs. non-functional than with programs and data having precisely the same form (s-expressions). There is a macro facility of the kind you're thinking of in Haskell (Template Haskell), but you have to work with abstract syntax tables which look nothing like the original code. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080517/456a34b9/attachment.htm From dons at galois.com Sat May 17 15:16:30 2008 From: dons at galois.com (Don Stewart) Date: Sat May 17 15:10:27 2008 Subject: [Haskell-cafe] Haskell-Cafe Info Page In-Reply-To: References: <7AC36395-14C7-4F96-91E9-9F973877B211@gmail.com> Message-ID: <20080517191630.GA25300@scytale.galois.com> allbery: > On 2008 May 17, at 14:52, D. Gregor wrote: > > Common Lisp is a multiparadigm, general purpose programming language > that supports imperative, functional, and object-oriented programming > paradigms. Haskell is purely functional. Is this a reason why there is > not macro feature in Haskell? I feel the object-oriented paradigm of CL > and Scheme is the reason for the macro feature in these two languages. > If it's not, then what does the macro feature provide, and why isn't it > in Haskell? > > Macros in Lisp have less to do with functional vs. non-functional than > with programs and data having precisely the same form (s-expressions). > There is a macro facility of the kind you're thinking of in Haskell > (Template Haskell), but you have to work with abstract syntax tables which > look nothing like the original code. Also, laziness is used for many of the coding jobs you might use macros for. So there's less need for macros. -- Don From dbueno at gmail.com Sat May 17 15:19:15 2008 From: dbueno at gmail.com (Denis Bueno) Date: Sat May 17 15:12:48 2008 Subject: [Haskell-cafe] Haskell-Cafe Info Page In-Reply-To: <20080517191630.GA25300@scytale.galois.com> References: <7AC36395-14C7-4F96-91E9-9F973877B211@gmail.com> <20080517191630.GA25300@scytale.galois.com> Message-ID: <6dbd4d000805171219r66b4dedbue1fd5fe642dc5fc4@mail.gmail.com> On Sat, May 17, 2008 at 3:16 PM, Don Stewart wrote: > allbery: >> On 2008 May 17, at 14:52, D. Gregor wrote: >> >> Common Lisp is a multiparadigm, general purpose programming language >> that supports imperative, functional, and object-oriented programming >> paradigms. Haskell is purely functional. Is this a reason why there is >> not macro feature in Haskell? I feel the object-oriented paradigm of CL >> and Scheme is the reason for the macro feature in these two languages. >> If it's not, then what does the macro feature provide, and why isn't it >> in Haskell? >> >> Macros in Lisp have less to do with functional vs. non-functional than >> with programs and data having precisely the same form (s-expressions). >> There is a macro facility of the kind you're thinking of in Haskell >> (Template Haskell), but you have to work with abstract syntax tables which >> look nothing like the original code. > > Also, laziness is used for many of the coding jobs you might use macros > for. So there's less need for macros. Precisely so. For example, macros are often used to implement control operators (e.g. specific kinds of complicated iteration), which is easily done in haskell with normal functions, due to laziness. -- Denis From kaveh.shahbazian at gmail.com Sat May 17 15:41:18 2008 From: kaveh.shahbazian at gmail.com (Kaveh Shahbazian) Date: Sat May 17 15:34:50 2008 Subject: [Haskell-cafe] Mapping Haskell Concepts To C# 3 Message-ID: <8aa524530805171241l1a013f13n973adeadc2364d@mail.gmail.com> I have question on mapping some Haskell concepts to C# 3 ones. Maybe there are not any strict equivalents; yet it helps: 1 - What is the equivalent of "Type Constructor" in C#? 2 - What is the equivalent of "Data Constructor" in C#? 3 - What is the logical implementation of pattern matching in C#? (For example using structures with indicator fields or using interfaces and inheritance and dynamically dispatch in calling overloaded methods. Also this question contain a hidden one...GADTs!) Best Regards -- Kaveh Shahbazian email: kaveh.shahbazian@gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080517/aa0c24ac/attachment.htm From sebastian.sylvan at gmail.com Sat May 17 15:51:59 2008 From: sebastian.sylvan at gmail.com (Sebastian Sylvan) Date: Sat May 17 15:45:32 2008 Subject: [Haskell-cafe] Mapping Haskell Concepts To C# 3 In-Reply-To: <8aa524530805171241l1a013f13n973adeadc2364d@mail.gmail.com> References: <8aa524530805171241l1a013f13n973adeadc2364d@mail.gmail.com> Message-ID: <3d96ac180805171251y53c535ffu2b228c95a23b4154@mail.gmail.com> 2008/5/17 Kaveh Shahbazian : > I have question on mapping some Haskell concepts to C# 3 ones. Maybe there > are not any strict equivalents; yet it helps: > > 1 - What is the equivalent of "Type Constructor" in C#? Class declaration. Generic ones. E.g. List, is a type where the type constructor List has been applied to the type int. > > 2 - What is the equivalent of "Data Constructor" in C#? Constructors, I guess. > > 3 - What is the logical implementation of pattern matching in C#? (For > example using structures with indicator fields or using interfaces and > inheritance and dynamically dispatch in calling overloaded methods. Also > this question contain a hidden one...GADTs!) > You can use an abstract base class, and then inherit one class for each constructor (e.g. base class Expression, and concrete subclasses Mul, Add, etc.). Then you can use runtime type reflection to figure out which kind of Expression you have and branch on it. -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080517/91799cc2/attachment.htm From avatar at hot.ee Sat May 17 15:54:53 2008 From: avatar at hot.ee (Misha Aizatulin) Date: Sat May 17 15:48:26 2008 Subject: [Haskell-cafe] Calling haddock in a portable way Message-ID: <482F380D.8010607@hot.ee> hello, the new version of haddock (2.0.0) needs a new option -B that tells it the GHC lib directory. How do I find out the correct value for this option in a makefile, so that the makefile stays portable? Cheers, Misha From keith at oreilly.com Sat May 17 16:10:57 2008 From: keith at oreilly.com (Keith Fahlgren) Date: Sat May 17 16:04:31 2008 Subject: [Haskell-cafe] [ANN] Next Bay FP Meeting: Bryan O'Sullivan on Concurrent and multicore programming in Haskell In-Reply-To: References: <481B72EC.3070502@oreilly.com> Message-ID: <482F3BD1.6070907@oreilly.com> On 5/2/08 8:50 PM, Vimal wrote: > On 03/05/2008, Keith Fahlgren wrote: >> Hi, >> >> >> Our next BayFP meeting will be this Thursday, May 8th, 2008 at 7:30pm. >> We'll feature Bryan O'Sullivan on Concurrent and multicore programming >> in Haskell. Bryan is a co-author of the upcoming O'Reilly book Real > > Cant wait for the video! How long before the video comes up on the website? The video is now available: http://www.bayfp.org/blog/2008/05/17/video-and-slides-from-bryan-o%e2%80%99sullivans-talk/ HTH, Keith From antonmuhin at gmail.com Sat May 17 16:48:30 2008 From: antonmuhin at gmail.com (anton muhin) Date: Sat May 17 16:42:02 2008 Subject: [Haskell-cafe] Another optimization question In-Reply-To: <200805172040.05086.daniel.is.fischer@web.de> References: <5953a1d00805171052o6445ee4ue929243f2ac9341f@mail.gmail.com> <200805172040.05086.daniel.is.fischer@web.de> Message-ID: <5953a1d00805171348x1684c487wce4ceed24f08ca91@mail.gmail.com> On Sat, May 17, 2008 at 10:40 PM, Daniel Fischer wrote: > Am Samstag, 17. Mai 2008 19:52 schrieb anton muhin: >> On Sat, May 17, 2008 at 8:19 PM, Jeroen wrote: >> > Hi, I know there's been quite some performance/optimization post lately, >> > so I hope there still room for one more. While solving a ProjectEuler >> > problem (27), I saw a performance issue I cannot explain. I narrowed it >> > down to the following code (never mind that 'primes' is just [1..], >> > the problem is the same or worse with real primes): >> > >> > primes :: [Int] >> > primes = [1..] >> > >> > isPrime :: Int -> Bool >> > isPrime x = isPrime' x primes >> > where isPrime' x (p:ps) | x == p = True >> > >> > | x > p = isPrime' x ps >> > | otherwise = False >> > >> > main = print $ length (filter (== True) (map isPrime [1..5000])) >> > >> > $ time ./experiment1 >> > 5000 >> > >> > real 0m4.037s >> > user 0m3.378s >> > sys 0m0.060s >> > >> > >> > All good, but if I change isPrime to the simpeler >> > >> > isPrime x = elem x (takeWhile (<= x) primes) >> > >> > it takes twice as long: >> > >> > time ./experiment2 >> > 5000 >> > >> > real 0m7.837s >> > user 0m6.532s >> > sys 0m0.141s >> > >> > With real primes, it even takes 10 times as long. >> > I tried looking at the output of ghc -ddump-simpl, >> > as suggested in a previous post, but it's a bit over >> > my head (newby here...). >> > >> > Any suggestions? >> >> Just a thought: in your first approach you compare any element of the >> list once. In second---twice: once to check if <= x and second time >> to check if it is equal to x. That's a hypothesis, > > I thought so, too, but I couldn't reproduce the behaviour, so I'm not sure > what happens. In fact, compiling without optimisations, the first version > takes almost twice as long as the second. Compiled with -O2, the second takes > about 13% more time. Why not -O3? > Using a real list of primes, What's the size of the real list? > dafis@linux:~/EulerProblems/Testing> ghc --make experiment -o expleriment3 > [1 of 1] Compiling Main ( experiment.hs, experiment.o ) > Linking experiment3 ... > dafis@linux:~/EulerProblems/Testing> time ./experiment3 > 669 > > real 0m0.222s > user 0m0.220s > sys 0m0.000s > dafis@linux:~/EulerProblems/Testing> ghc --make experiment -o experiment4 > [1 of 1] Compiling Main ( experiment.hs, experiment.o ) > Linking experiment4 ... > dafis@linux:~/EulerProblems/Testing> time ./experiment4 > 669 > > real 0m0.299s > user 0m0.290s > sys 0m0.000s > > But > dafis@linux:~/EulerProblems/Testing> ghc -O2 --make experiment -o experiment3 > [1 of 1] Compiling Main ( experiment.hs, experiment.o ) > Linking experiment3 ... > dafis@linux:~/EulerProblems/Testing> ghc -O2 --make experiment -o experiment4 > [1 of 1] Compiling Main ( experiment.hs, experiment.o ) > Linking experiment4 ... > dafis@linux:~/EulerProblems/Testing> time ./experiment3 > 669 > > real 0m0.053s > user 0m0.040s > sys 0m0.010s > dafis@linux:~/EulerProblems/Testing> time ./experiment4 > 669 > > real 0m0.257s > user 0m0.250s > sys 0m0.010s > > Wow! > I've no idea what optimising did to the first version, but apparently it > couldn't do much for the second. > >> but another >> implementation of isPrime: >> >> isPrime x = (== x) $ head $ dropWhile (< x) primes > > With -O2, this is about 20% slower than the Jeroen's first version, without > optimisations 50% faster. > Strange. Well, head has its overhead as well. Cf. two variants: firstNotLess :: Int -> [Int] -> Int firstNotLess s (x:xs) = if x < s then firstNotLess s xs else x dropLess :: Int -> [Int] -> [Int] dropLess s l@(x:xs) = if x < s then dropLess s xs else l isPrime :: Int -> Bool isPrime x = x == (firstNotLess x primes) isPrime' :: Int -> Bool isPrime' x = x == (head $ dropLess x primes) On my box firstNotLess gives numbers pretty close (if not better) than Jeroen's first variant, while head $ dropLess notably worse. > isPrime :: Int -> Bool > isPrime x = go primes > where > go (p:ps) = case compare x p of > LT -> False > EQ -> True > GT -> go ps > > does best (on my box), with and without optimisations (very very slightly with > -O2) for a list of real primes, but not for [1 .. ]. And what happens for [1..]? > However, more than can be squished out of fiddling with these versions could > be gained from a better algorithm. Definitely. yours, anton. From allbery at ece.cmu.edu Sat May 17 16:51:15 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sat May 17 16:44:48 2008 Subject: [Haskell-cafe] Another optimization question In-Reply-To: <5953a1d00805171348x1684c487wce4ceed24f08ca91@mail.gmail.com> References: <5953a1d00805171052o6445ee4ue929243f2ac9341f@mail.gmail.com> <200805172040.05086.daniel.is.fischer@web.de> <5953a1d00805171348x1684c487wce4ceed24f08ca91@mail.gmail.com> Message-ID: <7A9D8C55-093D-4FC5-9524-2FA5B03BA3BB@ece.cmu.edu> On 2008 May 17, at 16:48, anton muhin wrote: > Why not -O3? -O3 doesn't do anything over -O2 in ghc. -fvia-c -optc-O3 *might* be an improvement, or might not. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From gwern0 at gmail.com Sat May 17 17:00:27 2008 From: gwern0 at gmail.com (Gwern Branwen) Date: Sat May 17 16:54:33 2008 Subject: [Haskell-cafe] Calling haddock in a portable way In-Reply-To: <482F380D.8010607@hot.ee> References: <482F380D.8010607@hot.ee> Message-ID: <20080517210027.GA25760@localhost> On 2008.05.17 21:54:53 +0200, Misha Aizatulin scribbled 0.2K characters: > hello, > > the new version of haddock (2.0.0) needs a new option -B that tells it > the GHC lib directory. How do I find out the correct value for this option > in a makefile, so that the makefile stays portable? > > Cheers, > Misha Maybe you could do something like call out to a shell and ask it to run 'ghc --print-libdir'? That for me prints to stdout a string like '/usr/lib64/ghc-6.8.2'. -- gwern Rivera Peering Intiso SAMF facsimile Submarine redheads AHPCRC DJC Sears -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080517/64ae173a/attachment.bin From lrpalmer at gmail.com Sat May 17 17:07:40 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Sat May 17 17:01:12 2008 Subject: [Haskell-cafe] another Newbie performance question In-Reply-To: <482F145C.6040908@philip.in-aachen.net> References: <482F145C.6040908@philip.in-aachen.net> Message-ID: <7ca3f0160805171407h29f20461rde42aebb260f0ec@mail.gmail.com> On Sat, May 17, 2008 at 5:22 PM, Philip M?ller wrote: > If someone here finds the time to look at my code and give me some hints, > that would really be nice. A little experimentation reveals that your main bottleneck is readCSVLine: readCSVLine = read . (\x -> "[" ++ x ++ "]") (I just replaced it with (:[]) and it sped up enormously) Thus, I rewrote it myself instead of with read. readCSVLine = unfoldr builder where builder [] = Nothing builder xs = Just $ readField xs readField [] = ([],[]) readField (',':xs) = ([],xs) readField ('"':xs) = let (l,'"':r) = span (/= '"') xs (field,rest) = readField r And decreased the runtime from 17 seconds to 4.2. It probably admits an even better implementation, but it's likely that this is not the bottleneck anymore. The other thing is that the whole table is stored in memory because of your call to "length csv" in doInteraction. This may have been the intent. But if not, you can cut another 1 second off the runtime by "streaming" the file using a function that lazily inserts the line in the second-to-last position. insertLine line csv = let (l,r) = splitLast csv in l ++ [readCSVLine line] ++ r where splitLast [x] = ([],[x]) splitLast (x:xs) = let (l,r) = splitLast xs in (x:l,r) (Note that I got rid of the "pos" parameter) Presumably in a real application you are scanning until you see something and then inserting near that, which is a lazy streamlike operation. There are probably a few other tricks you could do, but I think I identified the main factors. Luke From avatar at hot.ee Sat May 17 17:52:12 2008 From: avatar at hot.ee (Misha Aizatulin) Date: Sat May 17 17:45:46 2008 Subject: [Haskell-cafe] Calling haddock in a portable way In-Reply-To: <20080517210027.GA25760@localhost> References: <482F380D.8010607@hot.ee> <20080517210027.GA25760@localhost> Message-ID: <482F538C.8010500@hot.ee> >Maybe you could do something like call out to a shell and ask it to run >'ghc --print-libdir'? That for me prints to stdout a string like >'/usr/lib64/ghc-6.8.2'. Yes, this looks like a solution. Thanks a lot! From daniel.is.fischer at web.de Sat May 17 18:00:48 2008 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Sat May 17 17:52:29 2008 Subject: [Haskell-cafe] Another optimization question In-Reply-To: <5953a1d00805171348x1684c487wce4ceed24f08ca91@mail.gmail.com> References: <200805172040.05086.daniel.is.fischer@web.de> <5953a1d00805171348x1684c487wce4ceed24f08ca91@mail.gmail.com> Message-ID: <200805180000.48096.daniel.is.fischer@web.de> Am Samstag, 17. Mai 2008 22:48 schrieb anton muhin: > > Why not -O3? As far as I know - and Brandon S.Allbery said so, too - -O3 isn't better than -O2. > > > Using a real list of primes, > > What's the size of the real list? arbitrary, however, since it's [Int], it will actually be at most 105097565 primes long, but since only numbers up to 5000 are checked, only 670 primes will ever be considered - When I check numbers 1 to 50000 (5133 primes, so 5134 primes evaluated), with -O0 / -O2, it's Jeroen 1 : 14.5 s / 2.4 s Jeroen 2 : 52.5 s / 49.7 s (== x) . head . dropWhile (< x) : 8.2 s /4.1 s go primes : 5.5 s / 2.5 s So Jeroen 1 is the best to be optimised :) > >> but another > >> implementation of isPrime: > >> > >> isPrime x = (== x) $ head $ dropWhile (< x) primes > > > > With -O2, this is about 20% slower than the Jeroen's first version, > > without optimisations 50% faster. > > Strange. > > Well, head has its overhead as well. Cf. two variants: > > firstNotLess :: Int -> [Int] -> Int > firstNotLess s (x:xs) = if x < s then firstNotLess s xs else x > > dropLess :: Int -> [Int] -> [Int] > dropLess s l@(x:xs) = if x < s then dropLess s xs else l > > isPrime :: Int -> Bool > isPrime x = x == (firstNotLess x primes) > > isPrime' :: Int -> Bool > isPrime' x = x == (head $ dropLess x primes) > > On my box firstNotLess gives numbers pretty close (if not better) than for primes up to 50000, that's 6.8 s / 2.1 s with -O0 / -O2 respectively on mine > Jeroen's first variant, while head $ dropLess notably worse. 5.8 s / 2.4 s here. > > > isPrime :: Int -> Bool > > isPrime x = go primes > > where > > go (p:ps) = case compare x p of > > LT -> False > > EQ -> True > > GT -> go ps > > > > does best (on my box), with and without optimisations (very very slightly > > with -O2) for a list of real primes, but not for [1 .. ]. > > And what happens for [1..]? With -O2, Jeroen 1 was best (1.62), nex firstNotLess (1.63), head . dropLess (1.74), then in close succesion Jeroen 2 (1.92), go primes (1.96) and head . dropWhile (1.99), with -O0, it's head . dropWhile (1.7 s, YES, that actually is faster with -O0 than with -O2!), head . dropLess (2.0), Jeroen 2 and firstNotLess (2.1 s), go primes (2.3 s), Jeroen 1 (3.2 s). Weirder and weirder. > > > However, more than can be squished out of fiddling with these versions > > could be gained from a better algorithm. > > Definitely. > > yours, > anton. From vigalchin at gmail.com Sat May 17 21:24:38 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Sat May 17 21:18:10 2008 Subject: [Haskell-cafe] Re: ghc on Ubuntu Linux? In-Reply-To: <8dde104f0805170902t198246f9s3ef234ae66ab86a7@mail.gmail.com> References: <5ae4f2ba0805162151l9ada3fdy7288ca8dda8776e5@mail.gmail.com> <5ae4f2ba0805162201y1f05dbb4r4b4ee04c7783c249@mail.gmail.com> <5ae4f2ba0805162307w666a68eerfaf5aaf170ade4a6@mail.gmail.com> <8dde104f0805170301t7941aca7y3847a31267f55bd0@mail.gmail.com> <5ae4f2ba0805170400m102158d7obce55bb3108aef3c@mail.gmail.com> <8dde104f0805170902t198246f9s3ef234ae66ab86a7@mail.gmail.com> Message-ID: <5ae4f2ba0805171824y35412927r46c7b7614da42c29@mail.gmail.com> Hi Josef, What generates dist/setup-config? When I run "runhaskell Setup.hs configure", nothing including dist/setup.config gets generated. ?? Regards, Vasili On Sat, May 17, 2008 at 11:02 AM, Josef Svenningsson < josef.svenningsson@gmail.com> wrote: > On Sat, May 17, 2008 at 1:00 PM, Galchin, Vasili > wrote: > > Josef, > > > > E.g. > > vigalchin@ubuntu:~/FTP/Haskell/unix-2.2.0.0$ runhaskell Setup.hs > configure > > Configuring unix-2.3.0.0... > > > > Normally copious output ... ??? > > > That's what it should look like! It just means you have a recent > version of cabal which doesn't spit out tons of information when > configuring. Happily all is well. > > /Josef > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080517/2ea3b1ce/attachment.htm From vigalchin at gmail.com Sun May 18 00:30:21 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Sun May 18 00:23:53 2008 Subject: [Haskell-cafe] more runhaskell question Message-ID: <5ae4f2ba0805172130s6feedc8cgec35bc1cd3619c17@mail.gmail.com> vigalchin@ubuntu:~/FTP/Haskell/unix-2.2.0.0/tests/mlock$ runhaskell Setup.lhs configure --prefix=$HOME Configuring mlock-1.0... vigalchin@ubuntu:~/FTP/Haskell/unix-2.2.0.0/tests/mlock$ runhaskell Setup.lhs build Setup.lhs: error reading dist/setup-config; run "setup configure" command? No dist/setup-config is being generated! what is the "setup configure" command?? Regards, Vasili -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080517/191e15c7/attachment.htm From yrn001 at gmail.com Sun May 18 01:45:49 2008 From: yrn001 at gmail.com (Jeroen) Date: Sun May 18 01:39:38 2008 Subject: [Haskell-cafe] Re: Another optimization question References: <200805172040.05086.daniel.is.fischer@web.de> <5953a1d00805171348x1684c487wce4ceed24f08ca91@mail.gmail.com> <200805180000.48096.daniel.is.fischer@web.de> Message-ID: Daniel Fischer web.de> writes: > > Am Samstag, 17. Mai 2008 22:48 schrieb anton muhin: > > > > Why not -O3? > > As far as I know - and Brandon S.Allbery said so, too - -O3 isn't better than > -O2. > > > > > Using a real list of primes, > > > > What's the size of the real list? > > arbitrary, however, since it's [Int], it will actually be at most 105097565 > primes long, but since only numbers up to 5000 are checked, only 670 primes > will ever be considered - When I check numbers 1 to 50000 (5133 primes, so > 5134 primes evaluated), with -O0 / -O2, it's > Jeroen 1 : 14.5 s / 2.4 s > Jeroen 2 : 52.5 s / 49.7 s > (== x) . head . dropWhile (< x) : 8.2 s /4.1 s > go primes : 5.5 s / 2.5 s > > So Jeroen 1 is the best to be optimised :) > > > >> but another > > >> implementation of isPrime: > > >> > > >> isPrime x = (== x) $ head $ dropWhile (< x) primes > > > > > > With -O2, this is about 20% slower than the Jeroen's first version, > > > without optimisations 50% faster. > > > Strange. > > > > Well, head has its overhead as well. Cf. two variants: > > > > firstNotLess :: Int -> [Int] -> Int > > firstNotLess s (x:xs) = if x < s then firstNotLess s xs else x > > > > dropLess :: Int -> [Int] -> [Int] > > dropLess s l@(x:xs) = if x < s then dropLess s xs else l > > > > isPrime :: Int -> Bool > > isPrime x = x == (firstNotLess x primes) > > > > isPrime' :: Int -> Bool > > isPrime' x = x == (head $ dropLess x primes) > > > > On my box firstNotLess gives numbers pretty close (if not better) than > > for primes up to 50000, that's > 6.8 s / 2.1 s with -O0 / -O2 respectively on mine > > > Jeroen's first variant, while head $ dropLess notably worse. > > 5.8 s / 2.4 s here. > > > > > isPrime :: Int -> Bool > > > isPrime x = go primes > > > where > > > go (p:ps) = case compare x p of > > > LT -> False > > > EQ -> True > > > GT -> go ps > > > > > > does best (on my box), with and without optimisations (very very slightly > > > with -O2) for a list of real primes, but not for [1 .. ]. > > > > And what happens for [1..]? > > With -O2, Jeroen 1 was best (1.62), nex firstNotLess (1.63), head . dropLess > (1.74), then in close succesion Jeroen 2 (1.92), go primes (1.96) and head . > dropWhile (1.99), > with -O0, it's > head . dropWhile (1.7 s, YES, that actually is faster with -O0 than with > -O2!), head . dropLess (2.0), Jeroen 2 and firstNotLess (2.1 s), go primes > (2.3 s), Jeroen 1 (3.2 s). > > Weirder and weirder. > > > > > > However, more than can be squished out of fiddling with these versions > > > could be gained from a better algorithm. > > > > Definitely. > > > > yours, > > anton. > Thanks for the responses so far! I only tested with -O2 and my primes implementation is the Sieve of Eratosthenes and has signature primes :: Integral a => [a] What's also quite strange is that experiment2 is about 10 times time slower than experiment1 when using primes (with the Eratosthenes formula) instead of [1..]. I redid the experiments with -prof and the output was quite revealing: experiment1 (fastest): total time = 2.64 secs (132 ticks @ 20 ms) total alloc = 323,356 bytes (excludes profiling overheads) individual inherited COST CENTRE entries %time %alloc %time %alloc MAIN 0 0.0 0.0 100.0 100.0 main 1 0.0 0.5 0.0 0.5 CAF 4 0.0 0.0 100.0 99.0 primes 1 9.8 61.9 9.8 61.9 main 0 0.0 37.1 90.2 37.1 isPrime 5000 90.2 0.0 90.2 0.0 CAF 4 0.0 0.4 0.0 0.4 experiment2 (slowest): total time = 6.12 secs (306 ticks @ 20 ms) total alloc = 350,473,356 bytes (excludes profiling overheads) individual inherited COST CENTRE entries %time %alloc %time %alloc MAIN 0 0.0 0.0 100.0 100.0 main 1 0.0 0.0 0.0 0.0 CAF 4 0.0 0.0 100.0 100.0 primes 1 0.0 0.1 0.0 0.1 main 0 0.0 0.0 100.0 99.9 isPrime 5000 100.0 99.9 100.0 99.9 CAF 4 0.0 0.0 0.0 0.0 Would this be only because isPrime of experiment 2 builds this temporary list (takeWhile) all the time? Jeroen Baekelandt From vigalchin at gmail.com Sun May 18 03:33:45 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Sun May 18 03:27:18 2008 Subject: [Haskell-cafe] Mapping Haskell Concepts to C# 3 In-Reply-To: <5ae4f2ba0805172328t64918424gac10530fc00276d8@mail.gmail.com> References: <5ae4f2ba0805172328t64918424gac10530fc00276d8@mail.gmail.com> Message-ID: <5ae4f2ba0805180033o55d282acy7d96c540f893f9fb@mail.gmail.com> Kaveh, Maybe I am misguessing why you are asking your question, but wouldn't it be better to ask how to map these Haskell concepts to CLR? If so, check out work on Mondrian. Vasili -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080518/45d12f83/attachment.htm From apfelmus at quantentunnel.de Sun May 18 03:41:22 2008 From: apfelmus at quantentunnel.de (apfelmus) Date: Sun May 18 03:35:10 2008 Subject: [Haskell-cafe] Re: another Newbie performance question In-Reply-To: <7ca3f0160805171407h29f20461rde42aebb260f0ec@mail.gmail.com> References: <482F145C.6040908@philip.in-aachen.net> <7ca3f0160805171407h29f20461rde42aebb260f0ec@mail.gmail.com> Message-ID: Achim Schneider wrote: > 1) traverse the list less often. Luke Palmer wrote: > Philip M?ller wrote: >> If someone here finds the time to look at my code and give me some hints, >> that would really be nice. > > There are probably a few other tricks you could do, but I think I > identified the main factors. List concatenation (++) takes time proportional to the length of the first list. In other words, every (xs ++) traverses xs again. So, things like (x ++ "\n") are expensive. Better write writeCSV as writeCSV = unlines . map (concat . intersperse "," . map show) Here, unlines is a library function which implements your (\x -> x ++ "\n") . concat . intersperse "\n" but slightly more efficiently. In general, difference lists are better for output (concatenation) than Strings and ByteStrings. So, if you want to squeeze even more speed out of your program, use those. Regards, apfelmus From andrewcoppin at btinternet.com Sun May 18 04:40:20 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Sun May 18 04:33:30 2008 Subject: [Haskell-cafe] Performance: MD5 In-Reply-To: <296039281.20080517195217@gmail.com> References: <482EF0EF.2090207@btinternet.com> <296039281.20080517195217@gmail.com> Message-ID: <482FEB74.3090909@btinternet.com> Bulat Ziganshin wrote: > if you need maximum efficiency, > drop all this high-level code and map md5.c to haskell as it was done > in Don's blog > Wait... you're telling me to give up? To not even try?? So all that bravado about Haskell enabling higher-level optimisations to produce a result faster than C is actually complete nonesense? What an awesome "community" this language has behind it... I'm not sure why I bother. From bulat.ziganshin at gmail.com Sun May 18 04:52:36 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sun May 18 04:47:43 2008 Subject: [Haskell-cafe] Performance: MD5 In-Reply-To: <482FEB74.3090909@btinternet.com> References: <482EF0EF.2090207@btinternet.com> <296039281.20080517195217@gmail.com> <482FEB74.3090909@btinternet.com> Message-ID: <277858879.20080518125236@gmail.com> Hello Andrew, Sunday, May 18, 2008, 12:40:20 PM, you wrote: > So all that bravado about Haskell enabling higher-level optimisations to > produce a result faster than C is actually complete nonesense? yes. look at bytestring implementation, for example. sorry, but you shouldn't believe in something until you tried it yourself :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From ndmitchell at gmail.com Sun May 18 04:54:30 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Sun May 18 04:50:35 2008 Subject: [Haskell-cafe] Performance: MD5 In-Reply-To: <482FEB74.3090909@btinternet.com> References: <482EF0EF.2090207@btinternet.com> <296039281.20080517195217@gmail.com> <482FEB74.3090909@btinternet.com> Message-ID: <404396ef0805180154p645f6abcw40f21d55d95c5c46@mail.gmail.com> Hi >> if you need maximum efficiency, >> drop all this high-level code and map md5.c to haskell as it was done >> in Don's blog > > Wait... you're telling me to give up? To not even try?? He's saying use the resources the community have already provided, to write it in a lower-level style, following much the same pattern as Don did. > So all that bravado about Haskell enabling higher-level optimisations to > produce a result faster than C is actually complete nonesense? Nope. If you just code up a simple algorithm in C and in Haskell, it is pretty unlikely the Haskell one will go as fast as the C one. But Haskell (in particular GHC) does have powerful low-level features that means you can probably draw with C. One day, I hope that high-level Haskell will outperform C all the time. It's already true with some of the ByteString stuff, but hopefully one day it will be a normal result. It's pretty much the goal of this optimiser: http://www-users.cs.york.ac.uk/~ndm/supero/ Thanks Neil From bulat.ziganshin at gmail.com Sun May 18 05:13:41 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sun May 18 05:08:54 2008 Subject: [Haskell-cafe] Performance: MD5 In-Reply-To: <404396ef0805180154p645f6abcw40f21d55d95c5c46@mail.gmail.com> References: <482EF0EF.2090207@btinternet.com> <296039281.20080517195217@gmail.com> <482FEB74.3090909@btinternet.com> <404396ef0805180154p645f6abcw40f21d55d95c5c46@mail.gmail.com> Message-ID: <639490412.20080518131341@gmail.com> Hello Neil, Sunday, May 18, 2008, 12:54:30 PM, you wrote: > One day, I hope that high-level Haskell will outperform C all the > time. It's already true with some of the ByteString stuff, but i don't think so. all the tests where Haskell "outperform" C i've seen was just unfair - for example they compare results of MANUALLY-unrolled Haskell loops with rolled C ones - totally ignoring the fact that gcc can unroll loops just by enabling option while with ghc this can be done only by hand. many tests that show "equal performance" just limited by memory bandwidth. and so on it's hard to write program that outperforms gcc-generated code even using assembler, and ghc is limited to this fact, too :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From dons at galois.com Sun May 18 05:17:16 2008 From: dons at galois.com (Don Stewart) Date: Sun May 18 05:10:56 2008 Subject: [Haskell-cafe] Performance: MD5 In-Reply-To: <482FEB74.3090909@btinternet.com> References: <482EF0EF.2090207@btinternet.com> <296039281.20080517195217@gmail.com> <482FEB74.3090909@btinternet.com> Message-ID: <20080518091716.GA22995@scytale.galois.com> andrewcoppin: > Bulat Ziganshin wrote: > >if you need maximum efficiency, > >drop all this high-level code and map md5.c to haskell as it was done > >in Don's blog > > > > Wait... you're telling me to give up? To not even try?? > > So all that bravado about Haskell enabling higher-level optimisations to > produce a result faster than C is actually complete nonesense? What optimisations were operating in your md5 implementation that you could expect it do match the C version? > What an awesome "community" this language has behind it... I'm not sure > why I bother. Andrew, take the time to understand what you're code actually does when you write it. If you want to write code that matches some heavily optimised md5 in C (did you look at the C implementation?) then your Haskell will need to compile down to similar data and control structures. Does it? So, as Bulat says, explain why your code should have similar performance to the C version. It would be much more useful than complaining about the community who patiently help you day in and out. -- Don From levi.stephen at gmail.com Thu May 8 19:22:37 2008 From: levi.stephen at gmail.com (Levi Stephen) Date: Sun May 18 05:17:35 2008 Subject: [Haskell-cafe] hmp3 compilation problem Message-ID: <8341e4f40805081622k5e947b36jf8d40464fa93b155@mail.gmail.com> Hi, I am trying to compile hmp3. I have the version from darcs at http://code.haskell.org/~dons/code/hmp3 I am getting the following errors: Tree.hs:190:14: No instance for (Binary FilePathP) arising from a use of `get' at Tree.hs:190:14-16 Possible fix: add an instance declaration for (Binary FilePathP) In a 'do' expression: nm <- get In the expression: do nm <- get i <- get return (File nm i) In the definition of `get': get = do nm <- get i <- get return (File nm i) Tree.hs:236:31: Couldn't match expected type `L.ByteString' against inferred type `bytestring-0.9.0.1:Data.ByteString.Lazy.Internal.ByteString' In the second argument of `L.writeFile', namely `(compress (encode s))' In the expression: L.writeFile f (compress (encode s)) In the definition of `writeTree': writeTree f s = L.writeFile f (compress (encode s)) Tree.hs:240:46: Couldn't match expected type `bytestring-0.9.0.1:Data.ByteString.Lazy.Internal.ByteString' against inferred type `L.ByteString' In the first argument of `decompress', namely `s' In the first argument of `decode', namely `(decompress s)' In the first argument of `return', namely `(decode (decompress s))' Any help is much appreciated. Thanks, Levi From andrewcoppin at btinternet.com Sun May 18 06:20:49 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Sun May 18 06:13:58 2008 Subject: [Haskell-cafe] Performance: MD5 In-Reply-To: <20080518091716.GA22995@scytale.galois.com> References: <482EF0EF.2090207@btinternet.com> <296039281.20080517195217@gmail.com> <482FEB74.3090909@btinternet.com> <20080518091716.GA22995@scytale.galois.com> Message-ID: <48300301.2030906@btinternet.com> Don Stewart wrote: > andrewcoppin: > >> Wait... you're telling me to give up? To not even try?? >> >> So all that bravado about Haskell enabling higher-level optimisations to >> produce a result faster than C is actually complete nonesense? >> > > What optimisations were operating in your md5 implementation that you > could expect it do match the C version? > I was hoping that things would be inlined, small loops unrolled, and I'd end up with more or less the same imperative loops as the C version has. I wasn't expecting to *beat* C in this particular case, but I expected to get somewhere fairly near it. > If you want to write code that matches some heavily > optimised md5 in C then your > Haskell will need to compile down to similar data and control structures. > Agreed. > (did you look at the C implementation?) > I can't read C. (FWIW, I think I did briefly stare at the sources, but eventually gave up because I simply had no clue what's going on.) > Does it? > I'm still figuring out how to answe that question. [As in, "the profiler says 60% of my time is spent inside one function, I've now tried writing that function 6 different ways, and currently it compiles to about 3 pages of Core that I'm still attempting to decypher". Given the size of the Core for this function, I'd say it's probably inlining and unrolling just fine...] > So, as Bulat says, explain why your code should have similar performance > to the C version. Because it executes the same algorithm? I mean, there's essentially only one way round that you can perform the MD5 algorithm, so it just comes down to how efficiently you execute the steps involved. > It would be much more useful than complaining about > the community who patiently help you day in and out. > Telling somebody "don't bother trying, it's impossible" doesn't strike me as terribly helpful. It doesn't make my code go any faster, and it certainly doesn't help me learn anything. I guess my responce was a little harsh. But when you invest a lot of time and effort in something, and somebody off-handedly tells you you're wasting your time... it's quite upsetting. From lassoken at gmail.com Sun May 18 06:25:58 2008 From: lassoken at gmail.com (Lauri Oksanen) Date: Sun May 18 06:19:29 2008 Subject: [Haskell-cafe] Random numbers and splitting Message-ID: <22dc08990805180325w32cc9d93rd69ca00f05c717df@mail.gmail.com> Hi, Does there exists any random number generator in Haskell that is suitable for doing heavy simulations and that can be splitted? At least there exists some c implementations of such generators, see http://www.iro.umontreal.ca/~lecuyer/myftp/papers/streams00.pdf Also some new theory for Mersenne Twister and its relatives exists, see http://www.iro.umontreal.ca/~lecuyer/myftp/papers/jumpf2.pdf http://www.iro.umontreal.ca/~lecuyer/myftp/papers/jumpmt.pdf I'm trying to implement Metropolis algorithm with lazy mutations and a state space that is infinite dimensional in theory (although, of course, not in practice). Without good splitting I'm forced to write as ugly code as with non-lazy language. Thanks in advance, Lauri -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080518/58a54f63/attachment.htm From antonmuhin at gmail.com Sun May 18 07:21:14 2008 From: antonmuhin at gmail.com (anton muhin) Date: Sun May 18 07:14:44 2008 Subject: [Haskell-cafe] Another optimization question In-Reply-To: <7A9D8C55-093D-4FC5-9524-2FA5B03BA3BB@ece.cmu.edu> References: <5953a1d00805171052o6445ee4ue929243f2ac9341f@mail.gmail.com> <200805172040.05086.daniel.is.fischer@web.de> <5953a1d00805171348x1684c487wce4ceed24f08ca91@mail.gmail.com> <7A9D8C55-093D-4FC5-9524-2FA5B03BA3BB@ece.cmu.edu> Message-ID: <5953a1d00805180421l2edd576ened8293b6f6671ef9@mail.gmail.com> Thank you, Brandon! yours, anton. On Sun, May 18, 2008 at 12:51 AM, Brandon S. Allbery KF8NH wrote: > > On 2008 May 17, at 16:48, anton muhin wrote: >> >> Why not -O3? > > -O3 doesn't do anything over -O2 in ghc. -fvia-c -optc-O3 *might* be an > improvement, or might not. > > -- > brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com > system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu > electrical and computer engineering, carnegie mellon university KF8NH > > > From duncan.coutts at worc.ox.ac.uk Sun May 18 07:24:44 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun May 18 07:16:11 2008 Subject: [Haskell-cafe] Performance: MD5 In-Reply-To: <48300301.2030906@btinternet.com> References: <482EF0EF.2090207@btinternet.com> <296039281.20080517195217@gmail.com> <482FEB74.3090909@btinternet.com> <20080518091716.GA22995@scytale.galois.com> <48300301.2030906@btinternet.com> Message-ID: <1211109884.5824.233.camel@localhost> On Sun, 2008-05-18 at 11:20 +0100, Andrew Coppin wrote: > > So, as Bulat says, explain why your code should have similar performance > > to the C version. > > Because it executes the same algorithm? I mean, there's essentially only > one way round that you can perform the MD5 algorithm, so it just comes > down to how efficiently you execute the steps involved. Ah if only computation were that simple. One might say that the ultimate perfect compiler would have this property. However it's provably impossible. See for example the Full Employment Theorem for Compiler Writers[1]. Duncan [1] http://en.wikipedia.org/wiki/Full_employment_theorem From andrewcoppin at btinternet.com Sun May 18 07:42:23 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Sun May 18 07:35:32 2008 Subject: [Haskell-cafe] Performance: MD5 In-Reply-To: <482EF0EF.2090207@btinternet.com> References: <482EF0EF.2090207@btinternet.com> Message-ID: <4830161F.4050403@btinternet.com> Andrew Coppin wrote: > If anybody has any interesting insights as to why my version is so > damned slow, I'd like to hear them. OK, so I am now officially talking to myself. Profiling indicates that 60% of my program's time is spent inside one function: make_block_bs :: ByteString -> Block In other words, the program spends 60% of its running time converting an array of Word8 into an array of Word32. [Note that the MD5 algorithm incorrectly specifies that little-endian ordering should be used, so I do the byte-swapping in here too.] The code for breading the file into correctly-sized pieces and adding padding is a ful 3% of the runtime, so it's not even the copying overhead. It's *all* in the array conversions. How much do you want to bet that the C version just reads a chunk of data into RAM and then does a simple type-cast? (If I'm not very much mistaken, in C a type-cast is an O(0) operation.) Anyway, wading through the 3-page Core output for this function, I'm seeing a lot of stuff of the form case GHC.Prim.<=# 0 whuhrjhsd of wild3784_hguhse { GHC.Base.False -> (GHC.Err.error @ GHC.Base.Int MD5.Types.lvl `cast` (CoUnsafe ... I'd be lying if I had I had any real idea what that does. But it occurs to me that the code is probably performing runtime checks that every single array access is within bounds, and that every single bit shift operation is similarly within bounds. This is obviously very *safe*, but possibly not very performant. Isn't there some function kicking around somewhere for acessing arrays without the bounds check? Similarly, I'm sure I remember the Data.Bits bounds check being mentioned before, and somebody saying they had [or were going to?] make an unsafe variant available. I've looked around the library documentation and I'm not seeing anything... any hints? (Obviously I could attempt to dig through GHC.Prim and find what I'm after there, but... it looks pretty scary in there! I'm hoping for something slightly higher-level if possible.) The alternative, obviously, is to just perform an evil type cast. Trouble is, that'll work just fine on any architecture with a little-endian data order [conspicuously IA32 and AMD64], and malfunction horribly on any architecture that works correctly. (At which point I start wondering how C manages to overcome this problem...) From bulat.ziganshin at gmail.com Sun May 18 07:52:12 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sun May 18 07:46:47 2008 Subject: [Haskell-cafe] Performance: MD5 In-Reply-To: <4830161F.4050403@btinternet.com> References: <482EF0EF.2090207@btinternet.com> <4830161F.4050403@btinternet.com> Message-ID: <551179706.20080518155212@gmail.com> Hello Andrew, Sunday, May 18, 2008, 3:42:23 PM, you wrote: > How much do you want to bet that the C version just reads a chunk of > data into RAM and then does a simple type-cast? (If I'm not very much > mistaken, in C a type-cast is an O(0) operation.) try unsafeCoerce# for that. or just use hGetArray to read directly into array of type you need -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From bulat.ziganshin at gmail.com Sun May 18 07:56:52 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sun May 18 07:51:35 2008 Subject: [Haskell-cafe] Performance: MD5 In-Reply-To: <4830161F.4050403@btinternet.com> References: <482EF0EF.2090207@btinternet.com> <4830161F.4050403@btinternet.com> Message-ID: <659443196.20080518155652@gmail.com> Hello Andrew, Sunday, May 18, 2008, 3:42:23 PM, you wrote: > Isn't there some function kicking around somewhere for acessing arrays > without the bounds check? Similarly, I'm sure I remember the Data.Bits > bounds check being mentioned before, and somebody saying they had [or > were going to?] make an unsafe variant available. I've looked around the > library documentation and I'm not seeing anything... any hints? unsafeRead/Write (I# a) <<# (I# b) = (I# (a `iShiftL#` b)) (I# a) >># (I# b) = (I# (a `uncheckedIShiftRL#` b)) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From andrewcoppin at btinternet.com Sun May 18 08:05:17 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Sun May 18 07:58:26 2008 Subject: [Haskell-cafe] Performance: MD5 In-Reply-To: <551179706.20080518155212@gmail.com> References: <482EF0EF.2090207@btinternet.com> <4830161F.4050403@btinternet.com> <551179706.20080518155212@gmail.com> Message-ID: <48301B7D.60104@btinternet.com> Bulat Ziganshin wrote: > Hello Andrew, > > Sunday, May 18, 2008, 3:42:23 PM, you wrote: > > >> How much do you want to bet that the C version just reads a chunk of >> data into RAM and then does a simple type-cast? (If I'm not very much >> mistaken, in C a type-cast is an O(0) operation.) >> > > try unsafeCoerce# for that. Yeah, I might end up being forced to do that. [Although obviously it'll break on big-endian architectures.] > or just use hGetArray to read directly into array of type you need > hGetArray :: Handle -> IOUArray Int Word8 -> Int -> IO Int (But yeah, I can coerce it afterwards.) From andrewcoppin at btinternet.com Sun May 18 08:08:02 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Sun May 18 08:01:12 2008 Subject: [Haskell-cafe] Performance: MD5 In-Reply-To: <659443196.20080518155652@gmail.com> References: <482EF0EF.2090207@btinternet.com> <4830161F.4050403@btinternet.com> <659443196.20080518155652@gmail.com> Message-ID: <48301C22.7020902@btinternet.com> Bulat Ziganshin wrote: > Hello Andrew, > > Sunday, May 18, 2008, 3:42:23 PM, you wrote: > > >> Isn't there some function kicking around somewhere for acessing arrays >> without the bounds check? Similarly, I'm sure I remember the Data.Bits >> bounds check being mentioned before, and somebody saying they had [or >> were going to?] make an unsafe variant available. I've looked around the >> library documentation and I'm not seeing anything... any hints? >> > > unsafeRead/Write > Found in Data.Array.Base, apparently. (I managed to find an example in the Gtk2hs "fastdraw" demo.) Oddly, this seems to make virtually no performance difference. I find this highly surprising. But then, I perform 16 write to the array, and 64 reads from the ByteString, so maybe that's where I should be worrying about bounds checks... > (I# a) <<# (I# b) = (I# (a `iShiftL#` b)) > (I# a) >># (I# b) = (I# (a `uncheckedIShiftRL#` b)) > Does it make a difference if I want Word32 instead of Int? From peteg42 at gmail.com Sun May 18 08:36:24 2008 From: peteg42 at gmail.com (Peter Gammie) Date: Sun May 18 08:30:11 2008 Subject: [Haskell-cafe] another Newbie performance question In-Reply-To: <7ca3f0160805171407h29f20461rde42aebb260f0ec@mail.gmail.com> References: <482F145C.6040908@philip.in-aachen.net> <7ca3f0160805171407h29f20461rde42aebb260f0ec@mail.gmail.com> Message-ID: You want to lazily read a CSV file? I had a crack at writing a module for that: http://peteg.org/blog/AYAD/Project/2008-04-11-LazyCSVParser.autumn It is not quite RFC compliant (I believe that is clearly commented upon). As I say there, anything based on (older versions of) Parsec is likely to be too strict in the general case. cheers peter From bf3 at telenet.be Sun May 18 08:47:22 2008 From: bf3 at telenet.be (Peter Verswyvelen) Date: Sun May 18 08:41:04 2008 Subject: [Haskell-cafe] Multi threaded garbage collector Message-ID: <4830255A.5020309@telenet.be> Hi all, I did some experiments with concurrent Haskell, and unfortunately I couldn't get my code run faster when using more cores, actually it ran a bit slower. Now I noticed after profiling that about 70% of the time my program was performing garbage collection (I had lists of 50000 tiny objects that got recreated 100 times per second). If I understood it correctly, the current garbage collector of GHC is single threaded, which really hinders SMP Any plans on improving this or workarounds? Thanks, Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080518/43ba4188/attachment.htm From antonmuhin at gmail.com Sun May 18 08:50:59 2008 From: antonmuhin at gmail.com (anton muhin) Date: Sun May 18 08:44:29 2008 Subject: [Haskell-cafe] Another optimization question In-Reply-To: <200805180000.48096.daniel.is.fischer@web.de> References: <200805172040.05086.daniel.is.fischer@web.de> <5953a1d00805171348x1684c487wce4ceed24f08ca91@mail.gmail.com> <200805180000.48096.daniel.is.fischer@web.de> Message-ID: <5953a1d00805180550l3c33259bt77a7c1a298b039e8@mail.gmail.com> On Sun, May 18, 2008 at 2:00 AM, Daniel Fischer wrote: > Am Samstag, 17. Mai 2008 22:48 schrieb anton muhin: >> >> Why not -O3? > > As far as I know - and Brandon S.Allbery said so, too - -O3 isn't better than > -O2. I didn't know that, sorry. >> > Using a real list of primes, >> >> What's the size of the real list? > > arbitrary, however, since it's [Int], it will actually be at most 105097565 > primes long, but since only numbers up to 5000 are checked, only 670 primes > will ever be considered - When I check numbers 1 to 50000 (5133 primes, so > 5134 primes evaluated), So it's just a relatively sparsed sorted list of 5134 numbers and the greatest of them still fits into Int, correct? > with -O0 / -O2, it's > Jeroen 1 : 14.5 s / 2.4 s > Jeroen 2 : 52.5 s / 49.7 s probably Jeroen's hypothesis about temporary list built might explain that slowdown, what do you think? > (== x) . head . dropWhile (< x) : 8.2 s /4.1 s > go primes : 5.5 s / 2.5 s > > So Jeroen 1 is the best to be optimised :) :) >> >> but another >> >> implementation of isPrime: >> >> >> >> isPrime x = (== x) $ head $ dropWhile (< x) primes >> > >> > With -O2, this is about 20% slower than the Jeroen's first version, >> > without optimisations 50% faster. >> > Strange. >> >> Well, head has its overhead as well. Cf. two variants: >> >> firstNotLess :: Int -> [Int] -> Int >> firstNotLess s (x:xs) = if x < s then firstNotLess s xs else x >> >> dropLess :: Int -> [Int] -> [Int] >> dropLess s l@(x:xs) = if x < s then dropLess s xs else l >> >> isPrime :: Int -> Bool >> isPrime x = x == (firstNotLess x primes) >> >> isPrime' :: Int -> Bool >> isPrime' x = x == (head $ dropLess x primes) >> >> On my box firstNotLess gives numbers pretty close (if not better) than > > for primes up to 50000, that's > 6.8 s / 2.1 s with -O0 / -O2 respectively on mine So it seems to be reproducible. >> Jeroen's first variant, while head $ dropLess notably worse. > > 5.8 s / 2.4 s here. >> >> > isPrime :: Int -> Bool >> > isPrime x = go primes >> > where >> > go (p:ps) = case compare x p of >> > LT -> False >> > EQ -> True >> > GT -> go ps >> > >> > does best (on my box), with and without optimisations (very very slightly >> > with -O2) for a list of real primes, but not for [1 .. ]. >> >> And what happens for [1..]? > > With -O2, Jeroen 1 was best (1.62), nex firstNotLess (1.63), head . dropLesst > (1.74), then in close succesion Jeroen 2 (1.92), go primes (1.96) and head . > dropWhile (1.99), go primes ran 1.96? Indeed weird, does anybody know if it's due to pattern matching? > with -O0, it's > head . dropWhile (1.7 s, YES, that actually is faster with -O0 than with > -O2!), head . dropLess (2.0), Jeroen 2 and firstNotLess (2.1 s), go primes > (2.3 s), Jeroen 1 (3.2 s). > > Weirder and weirder. agree yours, anton From antonmuhin at gmail.com Sun May 18 08:54:12 2008 From: antonmuhin at gmail.com (anton muhin) Date: Sun May 18 08:47:42 2008 Subject: [Haskell-cafe] Re: Another optimization question In-Reply-To: References: <200805172040.05086.daniel.is.fischer@web.de> <5953a1d00805171348x1684c487wce4ceed24f08ca91@mail.gmail.com> <200805180000.48096.daniel.is.fischer@web.de> Message-ID: <5953a1d00805180554yfd03192l499ae5bf6e48f2a2@mail.gmail.com> Any chances you're using Integer instead of Int? On my box switch to Integer is quite expensive (as one could expect). yours, anton. On Sun, May 18, 2008 at 9:45 AM, Jeroen wrote: > Daniel Fischer web.de> writes: >> >> Am Samstag, 17. Mai 2008 22:48 schrieb anton muhin: >> > >> > Why not -O3? >> >> As far as I know - and Brandon S.Allbery said so, too - -O3 isn't better than >> -O2. >> > >> > > Using a real list of primes, >> > >> > What's the size of the real list? >> >> arbitrary, however, since it's [Int], it will actually be at most 105097565 >> primes long, but since only numbers up to 5000 are checked, only 670 primes >> will ever be considered - When I check numbers 1 to 50000 (5133 primes, so >> 5134 primes evaluated), with -O0 / -O2, it's >> Jeroen 1 : 14.5 s / 2.4 s >> Jeroen 2 : 52.5 s / 49.7 s >> (== x) . head . dropWhile (< x) : 8.2 s /4.1 s >> go primes : 5.5 s / 2.5 s >> >> So Jeroen 1 is the best to be optimised :) >> >> > >> but another >> > >> implementation of isPrime: >> > >> >> > >> isPrime x = (== x) $ head $ dropWhile (< x) primes >> > > >> > > With -O2, this is about 20% slower than the Jeroen's first version, >> > > without optimisations 50% faster. >> > > Strange. >> > >> > Well, head has its overhead as well. Cf. two variants: >> > >> > firstNotLess :: Int -> [Int] -> Int >> > firstNotLess s (x:xs) = if x < s then firstNotLess s xs else x >> > >> > dropLess :: Int -> [Int] -> [Int] >> > dropLess s l@(x:xs) = if x < s then dropLess s xs else l >> > >> > isPrime :: Int -> Bool >> > isPrime x = x == (firstNotLess x primes) >> > >> > isPrime' :: Int -> Bool >> > isPrime' x = x == (head $ dropLess x primes) >> > >> > On my box firstNotLess gives numbers pretty close (if not better) than >> >> for primes up to 50000, that's >> 6.8 s / 2.1 s with -O0 / -O2 respectively on mine >> >> > Jeroen's first variant, while head $ dropLess notably worse. >> >> 5.8 s / 2.4 s here. >> > >> > > isPrime :: Int -> Bool >> > > isPrime x = go primes >> > > where >> > > go (p:ps) = case compare x p of >> > > LT -> False >> > > EQ -> True >> > > GT -> go ps >> > > >> > > does best (on my box), with and without optimisations (very very slightly >> > > with -O2) for a list of real primes, but not for [1 .. ]. >> > >> > And what happens for [1..]? >> >> With -O2, Jeroen 1 was best (1.62), nex firstNotLess (1.63), head . dropLess >> (1.74), then in close succesion Jeroen 2 (1.92), go primes (1.96) and head . >> dropWhile (1.99), >> with -O0, it's >> head . dropWhile (1.7 s, YES, that actually is faster with -O0 than with >> -O2!), head . dropLess (2.0), Jeroen 2 and firstNotLess (2.1 s), go primes >> (2.3 s), Jeroen 1 (3.2 s). >> >> Weirder and weirder. >> >> > >> > > However, more than can be squished out of fiddling with these versions >> > > could be gained from a better algorithm. >> > >> > Definitely. >> > >> > yours, >> > anton. >> > > Thanks for the responses so far! > > I only tested with -O2 and my primes implementation > is the Sieve of Eratosthenes and has signature > > primes :: Integral a => [a] > > What's also quite strange is that experiment2 is about > 10 times time slower than experiment1 when > using primes (with the Eratosthenes formula) instead of [1..]. > > I redid the experiments with -prof and the output was quite revealing: > > experiment1 (fastest): > total time = 2.64 secs (132 ticks @ 20 ms) > total alloc = 323,356 bytes (excludes profiling overheads) > > individual inherited > COST CENTRE entries %time %alloc %time %alloc > > MAIN 0 0.0 0.0 100.0 100.0 > main 1 0.0 0.5 0.0 0.5 > CAF 4 0.0 0.0 100.0 99.0 > primes 1 9.8 61.9 9.8 61.9 > main 0 0.0 37.1 90.2 37.1 > isPrime 5000 90.2 0.0 90.2 0.0 > CAF 4 0.0 0.4 0.0 0.4 > > > experiment2 (slowest): > total time = 6.12 secs (306 ticks @ 20 ms) > total alloc = 350,473,356 bytes (excludes profiling overheads) > > individual inherited > COST CENTRE entries %time %alloc %time %alloc > > MAIN 0 0.0 0.0 100.0 100.0 > main 1 0.0 0.0 0.0 0.0 > CAF 4 0.0 0.0 100.0 100.0 > primes 1 0.0 0.1 0.0 0.1 > main 0 0.0 0.0 100.0 99.9 > isPrime 5000 100.0 99.9 100.0 99.9 > CAF 4 0.0 0.0 0.0 0.0 > > > Would this be only because isPrime of experiment 2 builds > this temporary list (takeWhile) all the time? > > Jeroen Baekelandt > > > > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From bulat.ziganshin at gmail.com Sun May 18 09:01:43 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sun May 18 08:56:39 2008 Subject: [Haskell-cafe] Multi threaded garbage collector In-Reply-To: <4830255A.5020309@telenet.be> References: <4830255A.5020309@telenet.be> Message-ID: <610391985.20080518170143@gmail.com> Hello Peter, Sunday, May 18, 2008, 4:47:22 PM, you wrote: > If I understood it correctly, the current garbage collector of GHC > is single threaded, which really hinders SMP > > Any plans on improving this or workarounds? workaround - decrease GC times. read GHC manual for switches that control it. in particular, try +RTS -A10m afair, multithreaded gc was already implemented and should be shipped with ghc 6.10 -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From lemming at henning-thielemann.de Sun May 18 09:06:59 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun May 18 08:59:00 2008 Subject: [Haskell-cafe] Commutative monads vs Applicative functors In-Reply-To: <49a77b7a0805140959v39462883g5950e652f65b5494@mail.gmail.com> References: <62728db30805131806q232cc251g24bf64acadd033af@mail.gmail.com> <49a77b7a0805140959v39462883g5950e652f65b5494@mail.gmail.com> Message-ID: On Wed, 14 May 2008, David Menendez wrote: > On Tue, May 13, 2008 at 9:06 PM, Ronald Guida wrote: >> I have a few questions about commutative monads and applicative functors. >> >> >From what I have read about applicative functors, they are weaker than >> monads because with a monad, I can use the results of a computation to >> select between alternative future computations and their side effects, >> whereas with an applicative functor, I can only select between the >> results of computations, while the structure of those computations and >> their side effects are fixed in advance. >> >> But then there are commutative monads. I'm not exactly sure what a >> commutative monad is, but my understanding is that in a commutative >> monad the order of side effects does not matter. >> >> This leads me to wonder, are commutative monads still stronger than >> applicative functors, or are they equivalent? >> >> And by the way, what exactly is a commutative monad? Interestingly I used a Writer monad with a commutative monoid recently, which is also an example of a commutative monad. From stansife at caltech.edu Sun May 18 09:11:29 2008 From: stansife at caltech.edu (Eric Stansifer) Date: Sun May 18 09:04:59 2008 Subject: [Haskell-cafe] Short circuiting and the Maybe monad In-Reply-To: <482DDA83.4070907@btinternet.com> References: <65113aef0805121509s6b4e76bbxd23e86070a2a0be3@mail.gmail.com> <482A7AF0.6020008@tcs.inf.tu-dresden.de> <482B378E.802@btinternet.com> <482DDA83.4070907@btinternet.com> Message-ID: <2e58fd390805180611i6a2ef0b1jd08e950ee0fded97@mail.gmail.com> > Since a tree is a kind of container, yes, it should be a monad. [I'm still > not really sure whether it's "useful".] I have a use for the tree monad -- well, I have a use for the monadic `join' operation (but I don't use any of the monadic operations other than `return'). My program is making a file. It stores the lines in the file (I need the individual lines, for operations like "indent all lines by four spaces"): *> type File = [Line] And each line is a ordered collection of String s, waiting to be concatenated: *> type Line = [String] At the end of the day I need one long string: *> finish :: File -> String *> finish file = concat (concat file) (I'm eliding dealing with endlines, etc.) But elsewhere in my program, I would like to have an O(1) (++) operation, i.e., I would like to be able to do "line1 ++ line2" and "file1 ++ file2" in O(1) time. So I use a "Tree a" instead of "[a]": > type File = Tree Line > type Line = Tree String > finish file = concat (tree_to_list (tree_flatten file)) Admittedly, I'm not really doing anything actually "monadic" here -- I just happen to be using the `join' operation. I am sure others can come up with better examples. While we're at it, an example use for the ((->) a) monad. For any set S and ring R, the abelian group of functions f :: S -> R is a free module (in the mathematical sense of the word "module") over the ring R. The group and module operations are easily defined in terms of the monadic operations: > data FreeModule s r = FreeModule (s -> r) > instance Functor (FreeModule s) where ... > instance Monad (FreeModule s) where ... > instance Ring r => Group (FreeModule s r) where > (+) m1 m2 = liftM2 (+) m1 m2 > negative m = fmap negative m > zero = return zero > > instance Ring r => Module r (FreeModule s r) where > r *> m = fmap (r *) m (Here I write `r *> m' to mean the module element `m' left-multiplied by the ring element `r'.) I have another implementation of FreeModule which specializes S to the natural numbers: but the set of functions f :: \mathbb{N} -> R are isomorphic with f :: [R] (provided we only permit infinite lists), in the same way that Dave Menendez describes how f :: Bool -> a is isomorphic to f :: Diag a. Under this isomorphism, we translate the monadic operations from ((->) \mathbb{N}) to monadic operations on lists -- but the resulting monad is different from the usual list monad (where join = concat is the "structure flattening" operation). After all, the `concat' operation is pretty boring if you only permit infinite lists (for then `concat' is the same as `head'). Eric From ndmitchell at gmail.com Sun May 18 09:11:46 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Sun May 18 09:05:16 2008 Subject: [Haskell-cafe] Multi threaded garbage collector In-Reply-To: <4830255A.5020309@telenet.be> References: <4830255A.5020309@telenet.be> Message-ID: <404396ef0805180611m5777c89rc6b7c0aa0ebfa524@mail.gmail.com> Hi > Any plans on improving this or workarounds? http://research.microsoft.com/~simonpj/papers/parallel-gc/index.htm Thanks Neil From lemming at henning-thielemann.de Sun May 18 09:15:10 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun May 18 09:07:10 2008 Subject: [Haskell-cafe] another Newbie performance question In-Reply-To: <7ca3f0160805171407h29f20461rde42aebb260f0ec@mail.gmail.com> References: <482F145C.6040908@philip.in-aachen.net> <7ca3f0160805171407h29f20461rde42aebb260f0ec@mail.gmail.com> Message-ID: On Sat, 17 May 2008, Luke Palmer wrote: > insertLine line csv = let (l,r) = > splitLast csv in l ++ [readCSVLine line] ++ r > where > splitLast [x] = ([],[x]) > splitLast (x:xs) = let (l,r) = splitLast xs in (x:l,r) > > (Note that I got rid of the "pos" parameter) I'd like to have a function like Data.List.viewR :: [a] -> Maybe ([a], a) analogously to Data.Sequence, which is a safe replacement for 'init' and 'last'. From stansife at caltech.edu Sun May 18 09:17:45 2008 From: stansife at caltech.edu (Eric Stansifer) Date: Sun May 18 09:11:16 2008 Subject: [Haskell-cafe] Short circuiting and the Maybe monad In-Reply-To: <2e58fd390805180611i6a2ef0b1jd08e950ee0fded97@mail.gmail.com> References: <65113aef0805121509s6b4e76bbxd23e86070a2a0be3@mail.gmail.com> <482A7AF0.6020008@tcs.inf.tu-dresden.de> <482B378E.802@btinternet.com> <482DDA83.4070907@btinternet.com> <2e58fd390805180611i6a2ef0b1jd08e950ee0fded97@mail.gmail.com> Message-ID: <2e58fd390805180617we818145h79a31aea51c6e64c@mail.gmail.com> > I have another implementation of FreeModule which specializes S to the > natural numbers: but the set of functions f :: \mathbb{N} -> R are > isomorphic with f :: [R] (provided we only permit infinite lists), in > the same way that Dave Menendez describes how f :: Bool -> a is > isomorphic to f :: Diag a. This is what I get for reading only the first half of Dave Menendez's email... I saw the words "Here's a more complex example" and skipped the rest. Read his explanation -- it's a lot more coherent than mine. Eric From andrewcoppin at btinternet.com Sun May 18 09:46:06 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Sun May 18 09:39:25 2008 Subject: [Haskell-cafe] Multi threaded garbage collector In-Reply-To: <4830255A.5020309@telenet.be> References: <4830255A.5020309@telenet.be> Message-ID: <4830331E.1050303@btinternet.com> Peter Verswyvelen wrote: > Hi all, > > I did some experiments with concurrent Haskell, and unfortunately I > couldn't get my code run faster when using more cores, actually it ran > a bit slower. > > Now I noticed after profiling that about 70% of the time my program > was performing garbage collection (I had lists of 50000 tiny objects > that got recreated 100 times per second). > > If I understood it correctly, the current garbage collector of GHC is > single threaded, which really hinders SMP > > Any plans on improving this or workarounds? Parallel or not, if you can figure out a way to make your program require less GC work, it will go faster. The current GC requires all Haskell threads to be halted while it does its work. I understand there is a new GC under development that uses multiple cores [i.e., a GC pass now takes less time]. However, it still required all Haskell threads to be halted while it runs. (It's just that it takes less time to run now.) Either way, if you can somehow figure out how to do less GC, you'll win. Notice that sometimes just doing work in a different order can significantly reduce GC load. From allbery at ece.cmu.edu Sun May 18 09:48:48 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sun May 18 09:42:18 2008 Subject: [Haskell-cafe] Performance: MD5 In-Reply-To: <482FEB74.3090909@btinternet.com> References: <482EF0EF.2090207@btinternet.com> <296039281.20080517195217@gmail.com> <482FEB74.3090909@btinternet.com> Message-ID: On 2008 May 18, at 4:40, Andrew Coppin wrote: > Bulat Ziganshin wrote: >> if you need maximum efficiency, >> drop all this high-level code and map md5.c to haskell as it was done >> in Don's blog > > Wait... you're telling me to give up? To not even try?? Bulat is the naysayer of the group; according to him Haskell is a nice idea that will never actually work (but he uses it anyway, who knows how he rationalizes it to himself). -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From barsoap at web.de Sun May 18 09:49:23 2008 From: barsoap at web.de (Achim Schneider) Date: Sun May 18 09:43:04 2008 Subject: [Haskell-cafe] Re: Random numbers and splitting References: <22dc08990805180325w32cc9d93rd69ca00f05c717df@mail.gmail.com> Message-ID: <20080518154923.109be13e@solaris> "Lauri Oksanen" wrote: > Hi, > > Does there exists any random number generator in Haskell that is > suitable for doing heavy simulations and that can be splitted? > At least there exists some c implementations of such generators, see > http://www.iro.umontreal.ca/~lecuyer/myftp/papers/streams00.pdf > > Also some new theory for Mersenne Twister and its relatives exists, > see http://www.iro.umontreal.ca/~lecuyer/myftp/papers/jumpf2.pdf > http://www.iro.umontreal.ca/~lecuyer/myftp/papers/jumpmt.pdf > > I'm trying to implement Metropolis algorithm with lazy mutations and > a state space that is infinite dimensional in theory (although, of > course, not in practice). > Without good splitting I'm forced to write as ugly code as with > non-lazy language. > All built-in random generators Haskell has are atrociously slow. I ended up calling sfmt via the ffi for some midpoint replacement I did, it's on hackage now (thanks to Don): http://hackage.haskell.org/cgi-bin/hackage-scripts/package/mersenne-random I don't know if it's usable for your case, an uneducated game programmer like me just doesn't care about distribution properties and such as long as it's random. However, you might be able to implement split in http://hackage.haskell.org/packages/archive/mersenne-random-pure64/0.1.1/doc/html/System-Random-Mersenne-Pure64.html , and it might be fast enough for your work. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. From andrewcoppin at btinternet.com Sun May 18 09:55:36 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Sun May 18 09:48:50 2008 Subject: [Haskell-cafe] Performance: MD5 In-Reply-To: References: <482EF0EF.2090207@btinternet.com> <296039281.20080517195217@gmail.com> <482FEB74.3090909@btinternet.com> Message-ID: <48303558.3010207@btinternet.com> Brandon S. Allbery KF8NH wrote: > > Bulat is the naysayer of the group; according to him Haskell is a nice > idea that will never actually work (but he uses it anyway, who knows > how he rationalizes it to himself). > Bulat is apparently not alone in this belief. I seem to spend all my time on other forums dealing with people who have exactly the same opinion. Of course, being able to come up with clean, elegant code which never the less performs well is a good way to counter this. Pity I haven't succeeded in producing any yet. :-S From gale at sefer.org Sun May 18 09:58:39 2008 From: gale at sefer.org (Yitzchak Gale) Date: Sun May 18 09:52:15 2008 Subject: [Haskell-cafe] Std lib equivalent for liftM concat . sequence In-Reply-To: <1116962427.20080516143249@gmail.com> References: <79d7c4980805160312h4bd702d6tdd1262749a1aae3a@mail.gmail.com> <1116962427.20080516143249@gmail.com> Message-ID: <2608b8a80805180658s2a5f9efeod1682fb2d9244c8@mail.gmail.com> Alistair Bayley wrote: >> A couple of days ago I had need for: >> concatM :: Monad m => [m [a]] -> m [a] >> concatM = liftM concat . sequence >> but found no such thing in the std libs It used to be in an older version of Haskell, but it was removed in Haskell 98. Bulat Ziganshin wrote: > 2. it's not widely used. Bulat is justifiably concerned about backwards compatibility issues when changing the core standard libraries, including when adding new functions. Despite Bulat's best efforts, there has been a trend lately of adding those kinds of things. If so, nowadays it can be made more general. In this case, you could at least generalize it to: concatM :: (Monad m, Traversable t, Foldable t, MonadPlus p) => t (m (p a)) -> m (p a) or concatA :: (Applicative f, Traversable t, Foldable t, MonadPlus p) => t (f (p a)) -> f (p a) I'm sure someone can do better than that. :) Regards, Yitz From kaveh.shahbazian at gmail.com Sun May 18 09:59:28 2008 From: kaveh.shahbazian at gmail.com (Kaveh Shahbazian) Date: Sun May 18 09:53:00 2008 Subject: [Haskell-cafe] Mapping Haskell Concepts To C# 3 In-Reply-To: <3d96ac180805171251y53c535ffu2b228c95a23b4154@mail.gmail.com> References: <8aa524530805171241l1a013f13n973adeadc2364d@mail.gmail.com> <3d96ac180805171251y53c535ffu2b228c95a23b4154@mail.gmail.com> Message-ID: <8aa524530805180659h358c5152w16b3437bc5100669@mail.gmail.com> Hi (I did not received your message in my mail box and I have seen it on mailing list. I dot know why this happened (?).) /* Maybe I am misguessing why you are asking your question, but wouldn't it be better to ask how to map these Haskell concepts to CLR? If so, check out work on Mondrian. */ My intention is to employ Haskell techniques in C# where it fits. If I were going to implement Haskell on CLR the way you mentioned was proper. For something like: type Thing a b = ThisWay a | ThatWay b | NoWay actually there is no equivalents for data constructor in C# 3 (I think). I asked it if there are other ideas about this: Controlling the execution path by deciding based of structure of data with a trick other than reflecting! Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080518/a8cda8bc/attachment.htm From gale at sefer.org Sun May 18 10:05:19 2008 From: gale at sefer.org (Yitzchak Gale) Date: Sun May 18 09:58:50 2008 Subject: [Haskell-cafe] Std lib equivalent for liftM concat . sequence In-Reply-To: References: <79d7c4980805160312h4bd702d6tdd1262749a1aae3a@mail.gmail.com> <2C43B99C-0DAB-4674-9E5A-296B6BBBC46C@yandex.ru> Message-ID: <2608b8a80805180705g116146cdy93aef6f8e5108dac@mail.gmail.com> Alistair Bayley wrote: >> concatM :: Monad m => [m [a]] -> m [a] >> concatM = liftM concat . sequence Miguel Mitrofanov wrote: > Seems to be close to > sequence :: [ListT m a] -> ListT m a > Hmm? Yes. It is close to something like that for the old broken ListT - but let's not talk about that one. For "ListT done right", how about: concatM :: Monad m => [ListT m a] -> List m a concatM = join . liftList (http://www.haskell.org/haskellwiki/ListT_done_right) Regards, Yitz From bulat.ziganshin at gmail.com Sun May 18 10:13:15 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sun May 18 10:09:13 2008 Subject: [Haskell-cafe] Performance: MD5 In-Reply-To: References: <482EF0EF.2090207@btinternet.com> <296039281.20080517195217@gmail.com> <482FEB74.3090909@btinternet.com> Message-ID: <4610094475.20080518181315@gmail.com> Hello Brandon, Sunday, May 18, 2008, 5:48:48 PM, you wrote: >> Bulat Ziganshin wrote: >>> if you need maximum efficiency, >>> drop all this high-level code and map md5.c to haskell as it was done >>> in Don's blog > Bulat is the naysayer of the group; according to him Haskell is a nice > idea that will never actually work (but he uses it anyway, who knows > how he rationalizes it to himself). it significantly depends on the group, actually :) a few weeks ago i tried to convince managers of large software company to use haskell for development of complex algorithms. but they don't believe that using new language instead of C++ can raise productivity several times and told me that for real programmer it should be no matter which language to use. OTOH when i say here that haskell produce slow code, you can't belive me and saying that haskell is so great that it can't have any shortages. well, i use Haskell for complex algorithms and C++ for performance-critical parts of program which resulted in development of world-fastest archiver. if you know how to write high-level haskell programs that are as fast as C++ code - please tell us just now -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From allbery at ece.cmu.edu Sun May 18 10:25:31 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sun May 18 10:19:01 2008 Subject: [Haskell-cafe] Performance: MD5 In-Reply-To: <48303558.3010207@btinternet.com> References: <482EF0EF.2090207@btinternet.com> <296039281.20080517195217@gmail.com> <482FEB74.3090909@btinternet.com> <48303558.3010207@btinternet.com> Message-ID: <33BBF65E-DA62-4988-BDFE-04705A615529@ece.cmu.edu> On 2008 May 18, at 9:55, Andrew Coppin wrote: > Brandon S. Allbery KF8NH wrote: >> >> Bulat is the naysayer of the group; according to him Haskell is a >> nice idea that will never actually work (but he uses it anyway, who >> knows how he rationalizes it to himself). >> > > Bulat is apparently not alone in this belief. I seem to spend all my > time on other forums dealing with people who have exactly the same > opinion. There's a difference. When I started (GHC 6.4.2 was current), Bulat was spending his mailing list time denying the possibility of what DPH does now, and claiming that what GHC 6.8.2 does now was unlikely. (Meanwhile, I can't say much for "oh, i didn't understand that code, but surely we should be able to do at least as good without performance hacks?" when the code you didn't understand is all performance hacks.... You really have no business trying to draw comparisons when you don't even know when you're comparing apples to aardvarks, let alone apples to oranges.) Optimization is hard. Don't like it? Become a compiler researcher and find better ways to do it. Note that C / procedural language optimization research has at least a 20-year head start on functional programming optimization, and that the problems are very different: the C world would love to be at the point where optimizing the C equivalent of "sum xs / length xs" is worth thinking about; they're still not really in a position to *detect* it unless the language is simple enough to make such reasoning relatively easy (e.g. FORTRAN). -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From bulat.ziganshin at gmail.com Sun May 18 10:42:47 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sun May 18 10:38:15 2008 Subject: [Haskell-cafe] Performance: MD5 In-Reply-To: <33BBF65E-DA62-4988-BDFE-04705A615529@ece.cmu.edu> References: <482EF0EF.2090207@btinternet.com> <296039281.20080517195217@gmail.com> <482FEB74.3090909@btinternet.com> <48303558.3010207@btinternet.com> <33BBF65E-DA62-4988-BDFE-04705A615529@ece.cmu.edu> Message-ID: <1964257741.20080518184247@gmail.com> Hello Brandon, Sunday, May 18, 2008, 6:25:31 PM, you wrote: > There's a difference. When I started (GHC 6.4.2 was current), Bulat > was spending his mailing list time denying the possibility of what DPH > does now, and claiming that what GHC 6.8.2 does now was unlikely. what DPH and 6.8.2 does? i said that ghc can't reach the same level of optimization as gcc and it's still true - for example, it can't unroll loops. ghc 6.6 generates very simple code which holds all the vars in the memory, 6.8 can hold them in registers. gcc implements much more sophisticated optimizations, just try to implement something larger than one-liners in imperative haskell and C and compare results. it seems that you never developed highly-optimized programs in C, so all your reasoning is just product of haskell-fanatic imagination show me your code. or shut up, please -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From bulat.ziganshin at gmail.com Sun May 18 10:45:37 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sun May 18 10:40:51 2008 Subject: [Haskell-cafe] Performance: MD5 In-Reply-To: <33BBF65E-DA62-4988-BDFE-04705A615529@ece.cmu.edu> References: <482EF0EF.2090207@btinternet.com> <296039281.20080517195217@gmail.com> <482FEB74.3090909@btinternet.com> <48303558.3010207@btinternet.com> <33BBF65E-DA62-4988-BDFE-04705A615529@ece.cmu.edu> Message-ID: <222927966.20080518184537@gmail.com> Hello Brandon, Sunday, May 18, 2008, 6:25:31 PM, you wrote: > Optimization is hard. Don't like it? Become a compiler researcher > and find better ways to do it. Note that C / procedural language > optimization research has at least a 20-year head start on functional > programming optimization, and that the problems are very different: > the C world would love to be at the point where optimizing the C > equivalent of "sum xs / length xs" is worth thinking about; they're > still not really in a position to *detect* it unless the language is > simple enough to make such reasoning relatively easy (e.g. FORTRAN). and a few lines later you repeat what i said few years ago - ghc optimization research has got 100x times less attention than C++ optimization so we can't expect the same results in the next 5-10 years at least. strange that you still believe that ghc can optimize as good as gcc -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From allbery at ece.cmu.edu Sun May 18 10:55:33 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sun May 18 10:49:03 2008 Subject: [Haskell-cafe] Mapping Haskell Concepts To C# 3 In-Reply-To: <8aa524530805180659h358c5152w16b3437bc5100669@mail.gmail.com> References: <8aa524530805171241l1a013f13n973adeadc2364d@mail.gmail.com> <3d96ac180805171251y53c535ffu2b228c95a23b4154@mail.gmail.com> <8aa524530805180659h358c5152w16b3437bc5100669@mail.gmail.com> Message-ID: <24F91F59-672D-4FEC-A113-1415F96CCDB2@ece.cmu.edu> On 2008 May 18, at 9:59, Kaveh Shahbazian wrote: > For something like: type Thing a b = ThisWay a | ThatWay b | NoWay > actually there is no equivalents for data constructor I presume you mean "data" instead of "type". Not that I can address your question directly, as I don't know C#. In C it's a union; in C++ you would export constructors ThisWay(), ThatWay(), NoWay() from class Thing. I presume C# is similar. Haskell syntax is decidedly more compact than any of them. > in C# 3 (I think). I asked it if there are other ideas about this: > Controlling the execution path by deciding based of structure of > data with a trick other than reflecting! in C-like languages, the class includes a structure tag which is set by the constructor. Guess what? That's how Haskell does it, just implicitly (hence, again, nicely compact syntax). (You can actually experiment with this in GHC; using internal stuff like UnsafeCoerce# you can coerce one datum to another if they have the same (0-based, assigned in order of definition) constructor tag and the same representation for the data value. IIRC in GHC the internal constructor tag is an 8-bit unsigned value.) To make the above a bit clearer (I hope), here's a rough C approximation of a simple Haskell type: /* data Foo = FooInt Int | FooDouble Double */ struct Foo { unsigned char _FooTag; union { #define _FooTag_FooInt 0 int _FooInt; #define _FooTag_FooDouble 1 double _FooDouble; } _Foo_u; }; /* here I assume unboxed basic types for simplicity */ struct Foo *FooInt(int param) { Foo *foo = malloc(sizeof *foo); /* assume sane error checking here */ foo->_FooTag = _FooTag_FooInt; foo->_Foo_u._FooInt = param; } struct Foo *FooDouble(int param) { Foo *foo = malloc(sizeof *foo); /* assume sane error checking here */ foo->_FooTag = _FooTag_FooDouble; foo->_Foo_u._FooDouble = param; } /* * bar (FooInt i) = ... * desugars to * bar x = case x of { FooInt i -> ... } * which is very roughly (pretend I catch x == 0 and invoke error("Undefined")) * bar(Foo x) { switch (x->_FooTag) { case _FooTag_FooInt: i = x->_Foo_u._FooInt; ... } } */ -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080518/abc5e03c/attachment.htm From allbery at ece.cmu.edu Sun May 18 10:58:34 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sun May 18 10:52:04 2008 Subject: [Haskell-cafe] Performance: MD5 In-Reply-To: <222927966.20080518184537@gmail.com> References: <482EF0EF.2090207@btinternet.com> <296039281.20080517195217@gmail.com> <482FEB74.3090909@btinternet.com> <48303558.3010207@btinternet.com> <33BBF65E-DA62-4988-BDFE-04705A615529@ece.cmu.edu> <222927966.20080518184537@gmail.com> Message-ID: <0D253CD1-444D-4987-A3C4-1971FB1C020C@ece.cmu.edu> On 2008 May 18, at 10:45, Bulat Ziganshin wrote: > and a few lines later you repeat what i said few years ago - ghc > optimization research has got 100x times less attention than C++ > optimization so we can't expect the same results in the next 5-10 Mmm, no. You tend to say, or at least very strongly imply, "never" --- *not* "5-10 years". (Perhaps this is why you are rarely listened to. Also, perhaps you need to consider how you present things, if that's not actually what you mean.) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From lrpalmer at gmail.com Sun May 18 11:11:13 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Sun May 18 11:04:43 2008 Subject: [Haskell-cafe] Re: Another optimization question In-Reply-To: References: <200805172040.05086.daniel.is.fischer@web.de> <5953a1d00805171348x1684c487wce4ceed24f08ca91@mail.gmail.com> <200805180000.48096.daniel.is.fischer@web.de> Message-ID: <7ca3f0160805180811k4afb44b0vfaa41cbb7da68f2@mail.gmail.com> On Sat, May 17, 2008 at 11:45 PM, Jeroen wrote: > I only tested with -O2 and my primes implementation > is the Sieve of Eratosthenes and has signature > > primes :: Integral a => [a] I'm guessing that you already know this, but this declares that primes should *not* be cached globally (and is the reason for the monomorphism restriction). Depending on how it is used, it means that you might be computing the list of primes many times. Using a monomorphic signature like [Int] or [Integer] will allow primes to be cached, probably increasing the performance quite dramatically. Luke From bulat.ziganshin at gmail.com Sun May 18 11:10:07 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sun May 18 11:05:18 2008 Subject: [Haskell-cafe] Performance: MD5 In-Reply-To: <0D253CD1-444D-4987-A3C4-1971FB1C020C@ece.cmu.edu> References: <482EF0EF.2090207@btinternet.com> <296039281.20080517195217@gmail.com> <482FEB74.3090909@btinternet.com> <48303558.3010207@btinternet.com> <33BBF65E-DA62-4988-BDFE-04705A615529@ece.cmu.edu> <222927966.20080518184537@gmail.com> <0D253CD1-444D-4987-A3C4-1971FB1C020C@ece.cmu.edu> Message-ID: <88515684.20080518191007@gmail.com> Hello Brandon, Sunday, May 18, 2008, 6:58:34 PM, you wrote: >> and a few lines later you repeat what i said few years ago - ghc >> optimization research has got 100x times less attention than C++ >> optimization so we can't expect the same results in the next 5-10 > Mmm, no. You tend to say, or at least very strongly imply, "never" > --- *not* "5-10 years". (Perhaps this is why you are rarely listened > to. Also, perhaps you need to consider how you present things, if > that's not actually what you mean.) we don't have ghc optimized as good as gcc. when i tell about it, you tell that i'm not right. then you tell that ghc may be improved in some future - you don't know exactly. and now you started to watch out every word i say. well, i can do the same - why you sure that C optimization was started 20 years before FP optimization? why you sure that DPH does that i said will be never possible. please answer each question in detail before trying to critique me. and don't forget that we still wait from you your great strategy of optimization for C-like performance using all those fancy DPH/6.8.2 features. or you can only tell, and tell, and tell but never actually optimized anything? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From allbery at ece.cmu.edu Sun May 18 11:15:17 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sun May 18 11:08:48 2008 Subject: [Haskell-cafe] Performance: MD5 In-Reply-To: <88515684.20080518191007@gmail.com> References: <482EF0EF.2090207@btinternet.com> <296039281.20080517195217@gmail.com> <482FEB74.3090909@btinternet.com> <48303558.3010207@btinternet.com> <33BBF65E-DA62-4988-BDFE-04705A615529@ece.cmu.edu> <222927966.20080518184537@gmail.com> <0D253CD1-444D-4987-A3C4-1971FB1C020C@ece.cmu.edu> <88515684.20080518191007@gmail.com> Message-ID: On 2008 May 18, at 11:10, Bulat Ziganshin wrote: > we don't have ghc optimized as good as gcc. when i tell about it, you > tell that i'm not right. then you tell that ghc may be improved in You're doing a remarkably good job of not hearing what I say. Hard numbers or etc. do nothing whatsoever in the face of "my oresentation style is relentless negativity", because I have every expectation based on past experience that you will find something else to be negative about. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From bulat.ziganshin at gmail.com Sun May 18 11:14:33 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sun May 18 11:09:27 2008 Subject: [Haskell-cafe] Re: Another optimization question In-Reply-To: <7ca3f0160805180811k4afb44b0vfaa41cbb7da68f2@mail.gmail.com> References: <200805172040.05086.daniel.is.fischer@web.de> <5953a1d00805171348x1684c487wce4ceed24f08ca91@mail.gmail.com> <200805180000.48096.daniel.is.fischer@web.de> <7ca3f0160805180811k4afb44b0vfaa41cbb7da68f2@mail.gmail.com> Message-ID: <36765558.20080518191433@gmail.com> Hello Luke, Sunday, May 18, 2008, 7:11:13 PM, you wrote: >> primes :: Integral a => [a] > you might be computing the list of primes many times. Using a > monomorphic signature like [Int] or [Integer] will allow primes to be > cached, probably increasing the performance quite dramatically. besides caching, polymorphism decreases performance many tens times -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From bulat.ziganshin at gmail.com Sun May 18 11:21:20 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sun May 18 11:16:42 2008 Subject: [Haskell-cafe] Performance: MD5 In-Reply-To: References: <482EF0EF.2090207@btinternet.com> <296039281.20080517195217@gmail.com> <482FEB74.3090909@btinternet.com> <48303558.3010207@btinternet.com> <33BBF65E-DA62-4988-BDFE-04705A615529@ece.cmu.edu> <222927966.20080518184537@gmail.com> <0D253CD1-444D-4987-A3C4-1971FB1C020C@ece.cmu.edu> <88515684.20080518191007@gmail.com> Message-ID: <8910241854.20080518192120@gmail.com> Hello Brandon, Sunday, May 18, 2008, 7:15:17 PM, you wrote: >> we don't have ghc optimized as good as gcc. when i tell about it, you >> tell that i'm not right. then you tell that ghc may be improved in > You're doing a remarkably good job of not hearing what I say. Hard may be. so, when i proposed to use low-level optimization, you contradicted me. lets show us the better way to optimize this particular program if you know one or stop bothering me -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From allbery at ece.cmu.edu Sun May 18 11:24:12 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sun May 18 11:17:43 2008 Subject: [Haskell-cafe] Performance: MD5 In-Reply-To: <8910241854.20080518192120@gmail.com> References: <482EF0EF.2090207@btinternet.com> <296039281.20080517195217@gmail.com> <482FEB74.3090909@btinternet.com> <48303558.3010207@btinternet.com> <33BBF65E-DA62-4988-BDFE-04705A615529@ece.cmu.edu> <222927966.20080518184537@gmail.com> <0D253CD1-444D-4987-A3C4-1971FB1C020C@ece.cmu.edu> <88515684.20080518191007@gmail.com> <8910241854.20080518192120@gmail.com> Message-ID: On 2008 May 18, at 11:21, Bulat Ziganshin wrote: > Hello Brandon, > > Sunday, May 18, 2008, 7:15:17 PM, you wrote: >>> we don't have ghc optimized as good as gcc. when i tell about it, >>> you >>> tell that i'm not right. then you tell that ghc may be improved in > >> You're doing a remarkably good job of not hearing what I say. Hard > > may be. so, when i proposed to use low-level optimization, you > contradicted me. lets show us the better way to optimize this > particular program if you know one or stop bothering me Elide the part that says that it's not worth it and repeat yourself yet again? Bah. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From bf3 at telenet.be Sun May 18 11:27:35 2008 From: bf3 at telenet.be (Peter Verswyvelen) Date: Sun May 18 11:21:16 2008 Subject: [Haskell-cafe] Performance: MD5 In-Reply-To: <33BBF65E-DA62-4988-BDFE-04705A615529@ece.cmu.edu> References: <482EF0EF.2090207@btinternet.com> <296039281.20080517195217@gmail.com> <482FEB74.3090909@btinternet.com> <48303558.3010207@btinternet.com> <33BBF65E-DA62-4988-BDFE-04705A615529@ece.cmu.edu> Message-ID: <48304AE7.6010101@telenet.be> As a side note on this discussion, isn't it so that the current CPU hardware evolved in such a way that it is better suited for imperative programs? (I'm not talking about the GPU, that's another story). I mean, hardware gets optimized to run applications faster, but these applications are mainly written in C/C++, so you get a nice feedback loop here... Is it possible to design hardware that is better suitable for functional languages? From lrpalmer at gmail.com Sun May 18 11:33:56 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Sun May 18 11:27:25 2008 Subject: [Haskell-cafe] Mapping Haskell Concepts To C# 3 In-Reply-To: <8aa524530805171241l1a013f13n973adeadc2364d@mail.gmail.com> References: <8aa524530805171241l1a013f13n973adeadc2364d@mail.gmail.com> Message-ID: <7ca3f0160805180833w5bb5fd20s6b19d3af7b0d526c@mail.gmail.com> 2008/5/17 Kaveh Shahbazian : > 3 - What is the logical implementation of pattern matching in C#? (For > example using structures with indicator fields or using interfaces and > inheritance and dynamically dispatch in calling overloaded methods. Also > this question contain a hidden one...GADTs!) C# is missing ADT's, so the most straightforward way to do it is using open derived classes. (Forgive if my syntax is a bit wrong, you get the idea) class Thing { } class ThisWay : Thing { public a value; } class ThatWay : Thing { public b value; } class NoWay : Thing { } Annoyances include having to parameterize the, ahem, "constructors" on all type parameters, and the openness of the cases. That is, there is nothing stopping someone from adding "class TwoWay" later and making your pattern-matches partial. Scala is very much like C#, but gets this point right, FWIW. A more subtle trick is to use the fold of the ADT as its representation. delegate c Thing(Func thisWay, Func thatWay, c noWay) Then your constructors look like this (if I remember C#'s lambda syntax correctly): ThisWay thisWay(a value) { return new ThisWay((thisC, thatC, noC) => thisC(value)); } ... And a pattern match looks like this: String desc = thing( x => "ThisWay " + x.toString(), x => "ThatWay " + x.toString(), () => "NoWay"); Which isn't all that bad, actually. An advantage is that this approach does in fact keep the data type closed: you can be sure that the thing() pattern match does in fact cover all cases of the data type. A disadvantage is that there is rather a lot of plumbing (not really in comparison to the open derived approach though, I suppose). After those C# guys went to all the trouble to add lambdas and half-assed type-inference (not that "full-assed" was possible in their type system, but there are more complete strategies than the one they took), they could have at least added some half-assed (read: non-G) ADTs for us too :-). Luke From ketil at malde.org Sun May 18 11:36:47 2008 From: ketil at malde.org (Ketil Malde) Date: Sun May 18 11:30:03 2008 Subject: [Haskell-cafe] Re: Write Haskell as fast as C. In-Reply-To: <874p8xmhfp.fsf@nmd9999.imr.no> (Ketil Malde's message of "Sat\, 17 May 2008 11\:02\:50 +0200") References: <20080515183132.GD31635@scytale.galois.com> <482DD8E4.2060509@btinternet.com> <482DDB38.2040108@serpentine.com> <482DDDC4.4020002@btinternet.com> <87mympnc83.fsf@nmd9999.imr.no> <20080516215933.GH13340@scytale.galois.com> <874p8xmhfp.fsf@nmd9999.imr.no> Message-ID: <87mymnlj3k.fsf@nmd9999.imr.no> Ketil Malde writes: >> data EvidenceCode = IAC | IUG | IFR | NAC | NR | ... deriving Show > Could it be that this derived read instance is somehow very inefficient? To answer my own question: this is exactly it, ghc derives less than optimal code in this case. Rather than reiterate the case here, I did a quick writeup at http://blog.malde.org/, and would be quite happy about any feedback or suggestions. -k -- If I haven't seen further, it is by standing in the footprints of giants From jon at ffconsultancy.com Sun May 18 11:33:25 2008 From: jon at ffconsultancy.com (Jon Harrop) Date: Sun May 18 11:31:25 2008 Subject: [Haskell-cafe] Mapping Haskell Concepts To C# 3 In-Reply-To: <7ca3f0160805180833w5bb5fd20s6b19d3af7b0d526c@mail.gmail.com> References: <8aa524530805171241l1a013f13n973adeadc2364d@mail.gmail.com> <7ca3f0160805180833w5bb5fd20s6b19d3af7b0d526c@mail.gmail.com> Message-ID: <200805181633.25682.jon@ffconsultancy.com> On Sunday 18 May 2008 16:33:56 Luke Palmer wrote: > Scala is very much like C#, but gets this point right, FWIW. Only for certain types, IIRC. Scala was broken with respect to bools the last time I looked. -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e From bulat.ziganshin at gmail.com Sun May 18 11:38:40 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sun May 18 11:34:38 2008 Subject: [Haskell-cafe] Performance: MD5 In-Reply-To: References: <482EF0EF.2090207@btinternet.com> <296039281.20080517195217@gmail.com> <482FEB74.3090909@btinternet.com> <48303558.3010207@btinternet.com> <33BBF65E-DA62-4988-BDFE-04705A615529@ece.cmu.edu> <222927966.20080518184537@gmail.com> <0D253CD1-444D-4987-A3C4-1971FB1C020C@ece.cmu.edu> <88515684.20080518191007@gmail.com> <8910241854.20080518192120@gmail.com> Message-ID: <1088779214.20080518193840@gmail.com> Hello Brandon, Sunday, May 18, 2008, 7:24:12 PM, you wrote: >>> You're doing a remarkably good job of not hearing what I say. Hard > Elide the part that says that it's not worth it and repeat yourself > yet again? Bah. Brandon, you've contradicted to my USEFUL suggestion with a tons of USELESS sheet and still believe that you are right. well, you are fanatic which doesn't can't make anything useful but prefer to believe that his great thoughts was not heard. you can continue to believe, i will continue to help haskellers. RIP -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From ketil at malde.org Sun May 18 11:44:38 2008 From: ketil at malde.org (Ketil Malde) Date: Sun May 18 11:37:54 2008 Subject: [Haskell-cafe] Performance: MD5 In-Reply-To: <48304AE7.6010101@telenet.be> (Peter Verswyvelen's message of "Sun\, 18 May 2008 17\:27\:35 +0200") References: <482EF0EF.2090207@btinternet.com> <296039281.20080517195217@gmail.com> <482FEB74.3090909@btinternet.com> <48303558.3010207@btinternet.com> <33BBF65E-DA62-4988-BDFE-04705A615529@ece.cmu.edu> <48304AE7.6010101@telenet.be> Message-ID: <87iqxbliqh.fsf@nmd9999.imr.no> Peter Verswyvelen writes: > Is it possible to design hardware that is better suitable for > functional languages? As I recall, Lisp machines went out of business when Lisp ran faster on industry standard, 68000-based Suns and Apollos, than on their custom hardware with tags and whatnot. Anyway - with more and more aggressive caching, and ever increasing number of cores, it looks like C is an even poorer fit for the hardware than it used to be - and the Vax model has been a gross approximation for some time now. Threading and immutable data is getting popular even in the bare-metal imperative camp. Perhaps it is time to break out of the loop? -k -- If I haven't seen further, it is by standing in the footprints of giants From bulat.ziganshin at gmail.com Sun May 18 11:42:24 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sun May 18 11:38:32 2008 Subject: [Haskell-cafe] Performance: MD5 In-Reply-To: <48304AE7.6010101@telenet.be> References: <482EF0EF.2090207@btinternet.com> <296039281.20080517195217@gmail.com> <482FEB74.3090909@btinternet.com> <48303558.3010207@btinternet.com> <33BBF65E-DA62-4988-BDFE-04705A615529@ece.cmu.edu> <48304AE7.6010101@telenet.be> Message-ID: <9610139249.20080518194224@gmail.com> Hello Peter, Sunday, May 18, 2008, 7:27:35 PM, you wrote: > As a side note on this discussion, isn't it so that the current CPU > hardware evolved in such a way that it is better suited for imperative > programs? (I'm not talking about the GPU, that's another story). I mean, > hardware gets optimized to run applications faster, but these > applications are mainly written in C/C++, so you get a nice feedback > loop here... i don't think it's fundamental limit. hardware is better suited to assembler, naturally, but C++ compilers overruled asm. haskell-like languages can be theoretically compiled to the code which is as good as asm, it's just not the current state-of-the-art nevertheless, it's true that new hardware arise and it's two-way road: FP languages are used more due to multi-core hardware, and new hardware becomes practically useful due to new ways of programming -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From daniel.is.fischer at web.de Sun May 18 12:03:13 2008 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Sun May 18 11:54:53 2008 Subject: [Haskell-cafe] Another optimization question In-Reply-To: <5953a1d00805180550l3c33259bt77a7c1a298b039e8@mail.gmail.com> References: <200805180000.48096.daniel.is.fischer@web.de> <5953a1d00805180550l3c33259bt77a7c1a298b039e8@mail.gmail.com> Message-ID: <200805181803.13606.daniel.is.fischer@web.de> Am Sonntag, 18. Mai 2008 14:50 schrieb anton muhin: > On Sun, May 18, 2008 at 2:00 AM, Daniel Fischer > > wrote: > > Am Samstag, 17. Mai 2008 22:48 schrieb anton muhin: > >> Why not -O3? > > > > As far as I know - and Brandon S.Allbery said so, too - -O3 isn't better > > than -O2. > > I didn't know that, sorry. No need to apologise. It was a perfectly reasonable question. Fortunately, Brandon just a few minutes before confirmed that my recollection was probably correct, otherwise I would've added "must check that, though". > > >> > Using a real list of primes, > >> > >> What's the size of the real list? > > > > arbitrary, however, since it's [Int], it will actually be at most > > 105097565 primes long, but since only numbers up to 5000 are checked, > > only 670 primes will ever be considered - When I check numbers 1 to 50000 > > (5133 primes, so 5134 primes evaluated), > > So it's just a relatively sparsed sorted list of 5134 numbers and the > greatest of them still fits into Int, correct? Technically, I think, it's a partially evaluated list with a thunk at the end that says how to get more when needed. But at the end, it's basically a list of 5134 Ints. > > > with -O0 / -O2, it's > > Jeroen 1 : 14.5 s / 2.4 s > > Jeroen 2 : 52.5 s / 49.7 s > > probably Jeroen's hypothesis about temporary list built might explain > that slowdown, what do you think? Probably, but I'm a bit surprised how much that building of lists costs. > > > (== x) . head . dropWhile (< x) : 8.2 s /4.1 s > > go primes : 5.5 s / 2.5 s > > > > So Jeroen 1 is the best to be optimised :) > > > :) > : > >> >> but another > >> >> implementation of isPrime: > >> >> > >> >> isPrime x = (== x) $ head $ dropWhile (< x) primes > >> > > >> > With -O2, this is about 20% slower than the Jeroen's first version, > >> > without optimisations 50% faster. > >> > Strange. > >> > >> Well, head has its overhead as well. Cf. two variants: > >> > >> firstNotLess :: Int -> [Int] -> Int > >> firstNotLess s (x:xs) = if x < s then firstNotLess s xs else x > >> > >> dropLess :: Int -> [Int] -> [Int] > >> dropLess s l@(x:xs) = if x < s then dropLess s xs else l > >> > >> isPrime :: Int -> Bool > >> isPrime x = x == (firstNotLess x primes) > >> > >> isPrime' :: Int -> Bool > >> isPrime' x = x == (head $ dropLess x primes) > >> > >> On my box firstNotLess gives numbers pretty close (if not better) than > > > > for primes up to 50000, that's > > 6.8 s / 2.1 s with -O0 / -O2 respectively on mine > > So it seems to be reproducible. Yes, though with -O0 there's a big difference. > > >> Jeroen's first variant, while head $ dropLess notably worse. > > > > 5.8 s / 2.4 s here. So that doesn't perform notably worse than Jeroen's first variant on my box > > > >> > isPrime :: Int -> Bool > >> > isPrime x = go primes > >> > where > >> > go (p:ps) = case compare x p of > >> > LT -> False > >> > EQ -> True > >> > GT -> go ps > >> > > >> > does best (on my box), with and without optimisations (very very > >> > slightly with -O2) for a list of real primes, but not for [1 .. ]. > >> > >> And what happens for [1..]? > > > > With -O2, Jeroen 1 was best (1.62), nex firstNotLess (1.63), head . > > dropLesst (1.74), then in close succesion Jeroen 2 (1.92), go primes > > (1.96) and head . dropWhile (1.99), > > go primes ran 1.96? Indeed weird, does anybody know if it's due to > pattern matching? I also tried a version with go (p:ps) | p < x = go ps | otherwise = p == x that did worse (not much). > > > with -O0, it's > > head . dropWhile (1.7 s, YES, that actually is faster with -O0 than with > > -O2!), head . dropLess (2.0), Jeroen 2 and firstNotLess (2.1 s), go > > primes (2.3 s), Jeroen 1 (3.2 s). > > > > Weirder and weirder. > > agree > > yours, > anton Cheers, Daniel From andrewcoppin at btinternet.com Sun May 18 12:04:52 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Sun May 18 11:58:03 2008 Subject: [Haskell-cafe] Performance: MD5 In-Reply-To: <48304AE7.6010101@telenet.be> References: <482EF0EF.2090207@btinternet.com> <296039281.20080517195217@gmail.com> <482FEB74.3090909@btinternet.com> <48303558.3010207@btinternet.com> <33BBF65E-DA62-4988-BDFE-04705A615529@ece.cmu.edu> <48304AE7.6010101@telenet.be> Message-ID: <483053A4.7000803@btinternet.com> Peter Verswyvelen wrote: > As a side note on this discussion, isn't it so that the current CPU > hardware evolved in such a way that it is better suited for imperative > programs? (I'm not talking about the GPU, that's another story). I > mean, hardware gets optimized to run applications faster, but these > applications are mainly written in C/C++, so you get a nice feedback > loop here... > > Is it possible to design hardware that is better suitable for > functional languages? I wondered about that myself a few times. For example, current computer designs revolve around a single complex, fast CPU connected to some slow RAM. [Or, more recently, a very small number of seperate CPUs.] I wonder what would happen if you instead had a vast number of very simple proto-processors connected in a vast network. [But I'm guessing the first thing that'll happen is that the data is never where you want it to be...] At any rate, custom hardware vs IA32 is rather like GHC vs GCC - one has been around for a hell of a lot longer, and had vastly more R&D thrown at it. Unless you can find some crucial insight that gives you a very big advantage, you're not going to get anywhere near the market leader with anything you can come up with by yourself. (It does seem to be that the major trouble with modern processors is that they only go fast if there are no cache misses. Back in the days when RAM was as fast as CPU, you could structure your program any way you like and it would just work. Today you have to jump through loops to make sure the cache behaviour is good, or you can just forget it and go home now. That tends to be a pretty big problem for any programming language with automatic memory management - Java immediately springs to mind, but of course Haskell is in the same boat. I get the vague impression that hardware designers are starting to take notice of the problem, but it's difficult to see how they could design anything differently. We'll see I guess... Certainly if hardware appears that handles OOP languages better, it's likely to handle Haskell better too.) From antonmuhin at gmail.com Sun May 18 12:09:40 2008 From: antonmuhin at gmail.com (anton muhin) Date: Sun May 18 12:03:09 2008 Subject: [Haskell-cafe] Another optimization question In-Reply-To: <200805172040.05086.daniel.is.fischer@web.de> References: <5953a1d00805171052o6445ee4ue929243f2ac9341f@mail.gmail.com> <200805172040.05086.daniel.is.fischer@web.de> Message-ID: <5953a1d00805180909h6c040f57wba40e71760d6dfcf@mail.gmail.com> On Sat, May 17, 2008 at 10:40 PM, Daniel Fischer wrote: > However, more than can be squished out of fiddling with these versions could > be gained from a better algorithm. Just for fun and there probably should be better implementation for the same idea: module Main where data Tree a = Nil | Tree { el :: a, lft :: Tree a, rgt :: Tree a } deriving (Eq, Ord, Show) fromDistinctAscListN :: Int -> [a] -> ([a], Tree a) fromDistinctAscListN 0 xs = (xs, Nil) fromDistinctAscListN n xs = let ((e:xs'), l) = fromDistinctAscListN (n - 1) xs in let (xs'', r) = fromDistinctAscListN (n - 1) xs' in (xs'', Tree { el = e, lft = l, rgt = r }) branch :: Ord a => a -> a -> (a -> b) -> (a -> b) -> (a -> b) -> b branch x y lt eq gt = case (compare x y) of LT -> lt x EQ -> eq x GT -> gt x dispatch :: Ord a => a -> a -> (a -> Bool) -> (a -> Bool) -> Bool dispatch x y lt gt = branch x y lt (const True) gt member :: Ord a => a -> Tree a -> Bool member _ Nil = False member x t = dispatch x (el t) (`member` (lft t)) (`member` (rgt t)) type Forest a = [(a, Tree a)] memberOfForest :: Ord a => a -> Forest a -> Bool memberOfForest x ((y, t):fs) = dispatch x y (`member` t) (`memberOfForest` fs) fromDistAscList :: [a] -> Forest a fromDistAscList l = go 0 l where go n xs = let ((x:xs'), t) = fromDistinctAscListN n xs in (x, t):go (n + 1) xs' primes :: [Int] primes = [1..] primes' = fromDistAscList primes isPrime :: Int -> Bool isPrime = (`memberOfForest` primes') main = print $ length (filter isPrime [1..5000]) yours, anton. From barsoap at web.de Sun May 18 12:09:42 2008 From: barsoap at web.de (Achim Schneider) Date: Sun May 18 12:03:32 2008 Subject: [Haskell-cafe] Re: Performance: MD5 References: <482EF0EF.2090207@btinternet.com> <296039281.20080517195217@gmail.com> <482FEB74.3090909@btinternet.com> <48303558.3010207@btinternet.com> <33BBF65E-DA62-4988-BDFE-04705A615529@ece.cmu.edu> <48304AE7.6010101@telenet.be> <483053A4.7000803@btinternet.com> Message-ID: <20080518180942.7d87f101@solaris> Andrew Coppin wrote: > I wonder what would happen if you instead had > a vast number of very simple proto-processors connected in a vast > network. [But I'm guessing the first thing that'll happen is that the > data is never where you want it to be...] > You're not thinking of neuronal networks, are you? The interesting thing there is that they unite code and data. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. From bf3 at telenet.be Sun May 18 12:12:46 2008 From: bf3 at telenet.be (Peter Verswyvelen) Date: Sun May 18 12:06:28 2008 Subject: [Haskell-cafe] Type inference; always Message-ID: <4830557E.6040605@telenet.be> In Haskell, I sometimes have to annotate code with type info because the type-inferer otherwise fails (even with |-XNoMonomorphismRestriction)|. Surely, most of the time this is because I was writing buggy code, but sometimes, type annotation just seems needed to get a successful compilation (luckily not as often as in C# 3.0) It seems some new papers appeared regarding this, e.g. http://research.microsoft.com/~simonpj/papers/boxy Is this work being incorporated into GHC? Unfortunately I'm not able to read those papers, so I'm not really sure what it means anyway and what implications (example code?) it would have ;-) Cheers, Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080518/fd3156e3/attachment.htm From andrewcoppin at btinternet.com Sun May 18 12:18:19 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Sun May 18 12:11:28 2008 Subject: [Haskell-cafe] Re: Performance: MD5 In-Reply-To: <20080518180942.7d87f101@solaris> References: <482EF0EF.2090207@btinternet.com> <296039281.20080517195217@gmail.com> <482FEB74.3090909@btinternet.com> <48303558.3010207@btinternet.com> <33BBF65E-DA62-4988-BDFE-04705A615529@ece.cmu.edu> <48304AE7.6010101@telenet.be> <483053A4.7000803@btinternet.com> <20080518180942.7d87f101@solaris> Message-ID: <483056CB.8030506@btinternet.com> Achim Schneider wrote: > Andrew Coppin wrote: > > >> I wonder what would happen if you instead had >> a vast number of very simple proto-processors connected in a vast >> network. [But I'm guessing the first thing that'll happen is that the >> data is never where you want it to be...] >> >> > You're not thinking of neuronal networks, are you? The interesting > thing there is that they unite code and data. > Damn; you've seen through my cunning disguise. ;-) In all seriousness, it's easy enough to build an artificial neural network that computes a continuous function of several continuous inputs. But it's much harder to see how, for example, you'd build a text parser or something. It's really not clear how you implement flow control with this kind of thing. It's so different to a Turing machine is appears to render most of current computer science irrelevant. And that's *a lot* of work to redo. Now, if you had a network of something a bit more complicated than artificial neurons, but less complicated than an actual CPU... you'd have... I don't know, maybe something useful? It's hard to say. From bf3 at telenet.be Sun May 18 12:18:56 2008 From: bf3 at telenet.be (Peter Verswyvelen) Date: Sun May 18 12:12:38 2008 Subject: [Haskell-cafe] Performance: MD5 In-Reply-To: <483053A4.7000803@btinternet.com> References: <482EF0EF.2090207@btinternet.com> <296039281.20080517195217@gmail.com> <482FEB74.3090909@btinternet.com> <48303558.3010207@btinternet.com> <33BBF65E-DA62-4988-BDFE-04705A615529@ece.cmu.edu> <48304AE7.6010101@telenet.be> <483053A4.7000803@btinternet.com> Message-ID: <483056F0.60205@telenet.be> Yes, some things might be good for both language paradigms, e.g. * hardware garbage collection * hardware transactional memory With a bit of Googling, both seem to exists, the latter even being supported by SUN Andrew Coppin wrote: > Peter Verswyvelen wrote: >> As a side note on this discussion, isn't it so that the current CPU >> hardware evolved in such a way that it is better suited for >> imperative programs? (I'm not talking about the GPU, that's another >> story). I mean, hardware gets optimized to run applications faster, >> but these applications are mainly written in C/C++, so you get a nice >> feedback loop here... >> >> Is it possible to design hardware that is better suitable for >> functional languages? > > I wondered about that myself a few times. > > For example, current computer designs revolve around a single complex, > fast CPU connected to some slow RAM. [Or, more recently, a very small > number of seperate CPUs.] I wonder what would happen if you instead > had a vast number of very simple proto-processors connected in a vast > network. [But I'm guessing the first thing that'll happen is that the > data is never where you want it to be...] > > At any rate, custom hardware vs IA32 is rather like GHC vs GCC - one > has been around for a hell of a lot longer, and had vastly more R&D > thrown at it. Unless you can find some crucial insight that gives you > a very big advantage, you're not going to get anywhere near the market > leader with anything you can come up with by yourself. > > (It does seem to be that the major trouble with modern processors is > that they only go fast if there are no cache misses. Back in the days > when RAM was as fast as CPU, you could structure your program any way > you like and it would just work. Today you have to jump through loops > to make sure the cache behaviour is good, or you can just forget it > and go home now. That tends to be a pretty big problem for any > programming language with automatic memory management - Java > immediately springs to mind, but of course Haskell is in the same > boat. I get the vague impression that hardware designers are starting > to take notice of the problem, but it's difficult to see how they > could design anything differently. We'll see I guess... Certainly if > hardware appears that handles OOP languages better, it's likely to > handle Haskell better too.) > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From andrewcoppin at btinternet.com Sun May 18 12:21:44 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Sun May 18 12:14:53 2008 Subject: [Haskell-cafe] Re: Write Haskell as fast as C. In-Reply-To: <87mymnlj3k.fsf@nmd9999.imr.no> References: <20080515183132.GD31635@scytale.galois.com> <482DD8E4.2060509@btinternet.com> <482DDB38.2040108@serpentine.com> <482DDDC4.4020002@btinternet.com> <87mympnc83.fsf@nmd9999.imr.no> <20080516215933.GH13340@scytale.galois.com> <874p8xmhfp.fsf@nmd9999.imr.no> <87mymnlj3k.fsf@nmd9999.imr.no> Message-ID: <48305798.7060707@btinternet.com> Ketil Malde wrote: > Ketil Malde writes: > > >>> data EvidenceCode = IAC | IUG | IFR | NAC | NR | ... deriving Show >>> > > >> Could it be that this derived read instance is somehow very inefficient? >> > > To answer my own question: this is exactly it, ghc derives less than > optimal code in this case. Rather than reiterate the case here, I did > a quick writeup at http://blog.malde.org/, and would be quite happy > about any feedback or suggestions. > I think you'll find the code that GHC derives for a Read instance handles extra whitespace and all kinds of other whatnot that you don't actually need in this specific case. I suspect this is what's up - but I don't have any hard proof for that. ;-) From bulat.ziganshin at gmail.com Sun May 18 12:20:04 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sun May 18 12:15:22 2008 Subject: [Haskell-cafe] Performance: MD5 In-Reply-To: <87iqxbliqh.fsf@nmd9999.imr.no> References: <482EF0EF.2090207@btinternet.com> <296039281.20080517195217@gmail.com> <482FEB74.3090909@btinternet.com> <48303558.3010207@btinternet.com> <33BBF65E-DA62-4988-BDFE-04705A615529@ece.cmu.edu> <48304AE7.6010101@telenet.be> <87iqxbliqh.fsf@nmd9999.imr.no> Message-ID: <501492988.20080518202004@gmail.com> Hello Ketil, Sunday, May 18, 2008, 7:44:38 PM, you wrote: > Anyway - with more and more aggressive caching, and ever increasing > number of cores, it looks like C is an even poorer fit for the > hardware than it used to be doubling number of cores every 1.5 years, we should see 1000-core monsters just next decade. so, i believe that next decade we will see the next big language shift and it will be shift toward FP languages. but Erlang still has more chances - Haskell is too complex, too slow and not advertised as multithreading language as wide as Erlang was just now, MS pushes F#. waiting for Sun :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From aslatter at gmail.com Sun May 18 12:23:10 2008 From: aslatter at gmail.com (Antoine Latter) Date: Sun May 18 12:16:40 2008 Subject: [Haskell-cafe] Re: Parsec3 performance issues (in relation to v2) In-Reply-To: References: <62634.86.145.154.157.1210712205.squirrel@www.gradwell.com> Message-ID: <694519c50805180923i55aa35e2p1c19ee63b64891d1@mail.gmail.com> On Tue, May 13, 2008 at 9:23 PM, Neal Alexander wrote: > I stripped the code down to just the parsec related stuff and retested it. > > http://72.167.145.184:8000/parsec_test/Parsec2.prof > http://72.167.145.184:8000/parsec_test/Parsec3.prof > > And the parser with a 9mb (800 kb gziped) sample log file: > http://72.167.145.184:8000/parsec_test.tar.gz > Neal, those two profiling results aren't really comparable, because your Parsec2 profiling doesn't include any cost-centers from the Parsec library - so all of the costs associated with Parsec2 will be assigned to cost-centers in EQ2Parse. I've tried running this profiling on my own computer, and using the same Cabal options for Parsec2 as Parsec3, I never seem to get CAFs from Parsec2 to show up in the profiling result this this test. Can anyone help me out? I configure parsec (2 and 3) as follows: $ runghc Setup.hs configure --prefix=${HOME}/usr --enable-library-profiling --user --enable-optimization and then I build the "Main" as follows: $ ghc --make -O2 -prof -auto Main -package parsec-2.1.0.0 - or - $ ghc --make -O2 -prof -auto Main And I run main as: $ ./Main +RTS -p -RTS When I specify the parsec-2.1.0.0 on the command-line, the Main.prof doesn't include any parsec CAFs. Thanks, Antoine From gwern0 at gmail.com Sun May 18 12:33:20 2008 From: gwern0 at gmail.com (Gwern Branwen) Date: Sun May 18 12:28:30 2008 Subject: [Haskell-cafe] Starting Haskell with a web application In-Reply-To: <92952f860805160851p6e3e5239haf63b68cc10f21d3@mail.gmail.com> References: <6cc20cea0803051009y7fedd8a2i304f63ac867c3c23@mail.gmail.com> <47CEEBD7.30005@serpentine.com> <20080306130245.GB22702@shaka.acc.umu.se> <92952f860805160851p6e3e5239haf63b68cc10f21d3@mail.gmail.com> Message-ID: <20080518163320.GA6726@localhost> On 2008.05.16 17:51:33 +0200, Immanuel Normann scribbled 3.1K characters: > Where can I find the sources of the latest WASH? I couldn't find them in HackageDB (and > neither with Google). > > -- > Immanuel Normann Did you find its homepage at ? I'm afraid I dunno if there are any more recent versions. It is an old collection, as someone mentioned. -- gwern Clandestine SBS electronic NADDIS Intelligence WHCA Chavez real E.T. boobytraps -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080518/534cbdf8/attachment.bin From aslatter at gmail.com Sun May 18 12:37:27 2008 From: aslatter at gmail.com (Antoine Latter) Date: Sun May 18 12:30:59 2008 Subject: [Haskell-cafe] Re: Parsec3 performance issues (in relation to v2) In-Reply-To: <694519c50805180923i55aa35e2p1c19ee63b64891d1@mail.gmail.com> References: <62634.86.145.154.157.1210712205.squirrel@www.gradwell.com> <694519c50805180923i55aa35e2p1c19ee63b64891d1@mail.gmail.com> Message-ID: <694519c50805180937m2624af3co3ecb4441fc27d39e@mail.gmail.com> On Sun, May 18, 2008 at 11:23 AM, Antoine Latter wrote: > Neal, those two profiling results aren't really comparable, because > your Parsec2 profiling doesn't include any cost-centers from the > Parsec library - so all of the costs associated with Parsec2 will be > assigned to cost-centers in EQ2Parse. Self-reply: Or is it possible that Parsec2 is so much faster that it doesn't even show up in the .prof results? + The largest cost center in the Parsec2 results is the EQ2Parse function "until" + The largest cost center in the Parsec3 result is the Parsec function "manyTill", which (in the prof results) is only called by "until" in EQ2Parse. Which is consistent with my previous reasoning, at least. Antoine From ketil at malde.org Sun May 18 12:42:46 2008 From: ketil at malde.org (Ketil Malde) Date: Sun May 18 12:36:02 2008 Subject: [Haskell-cafe] Re: Parsec3 performance issues (in relation to v2) In-Reply-To: <694519c50805180923i55aa35e2p1c19ee63b64891d1@mail.gmail.com> (Antoine Latter's message of "Sun\, 18 May 2008 11\:23\:10 -0500") References: <62634.86.145.154.157.1210712205.squirrel@www.gradwell.com> <694519c50805180923i55aa35e2p1c19ee63b64891d1@mail.gmail.com> Message-ID: <87d4njlg1l.fsf@nmd9999.imr.no> "Antoine Latter" writes: > When I specify the parsec-2.1.0.0 on the command-line, the Main.prof > doesn't include any parsec CAFs. You need to add -auto-all to the build of Parsec as well. -k -- If I haven't seen further, it is by standing in the footprints of giants From lrpalmer at gmail.com Sun May 18 12:57:08 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Sun May 18 12:50:39 2008 Subject: [Haskell-cafe] Type inference; always In-Reply-To: <4830557E.6040605@telenet.be> References: <4830557E.6040605@telenet.be> Message-ID: <7ca3f0160805180957p368b06e2tb8ec97234f57fb5e@mail.gmail.com> 2008/5/18 Peter Verswyvelen : > In Haskell, I sometimes have to annotate code with type info because the > type-inferer otherwise fails (even with -XNoMonomorphismRestriction). > Surely, most of the time this is because I was writing buggy code, but > sometimes, type annotation just seems needed to get a successful compilation > (luckily not as often as in C# 3.0) Then you must either be programming using extensions or you have found a bug. Haskell 98 should never require annotations (modulo monomorphism). In particular with either higher rank polymorphism or GADTs, full inference is undecidable, so it is perfectly reasonable to have to put a few annotations here and there. > It seems some new papers appeared regarding this, e.g. > http://research.microsoft.com/~simonpj/papers/boxy > > Is this work being incorporated into GHC? IIRC that work is already in 6.8. I can't be sure though. > Unfortunately I'm not able to read those papers, so I'm not really sure what > it means anyway and what implications (example code?) it would have ;-) There are some type inference algorithms (Colored Local Type Inference of Scala comes to mind) which can infer quite a lot, but it is pretty difficult to tell when it won't be able to. The main contribution of the FPH is an algorithm which is predictable in that respect. From the paper: "FPH ... has the following delightfully simple rule for when a type annotation is required: a type annotation may be required only for a let-binding or lambda-abstraction that has a non-Damas-Milner type" Here the paper is only referring to higher-rank polymorphism, so its interaction with other extensions can still be tricky. Essentially non-Damas-Milner types are the ones that you wouldn't be able to write down in Haskell without the 'forall' keyword; the ones whose quantification is somewhere besides the top level. Do you have an example of code that required an annotation to compile? Luke From nehir.sonmez at bsc.es Sun May 18 12:57:54 2008 From: nehir.sonmez at bsc.es (Nehir Sonmez) Date: Sun May 18 12:51:27 2008 Subject: [Haskell-cafe] STM applications Message-ID: <48306012.70606@bsc.es> Good day all, We are Haskell STM researchers, looking for Haskell applications written using STM for profiling their STM behaviour. The benchmark currently consists of the ones in: www.cs.rochester.edu/meetings/TRANSACT07/papers/perfumo.pdf (3rd page) + binary trees + parallel sudoku and additional programs would be greatly greatly appreciated... Cheers, Nehir Sonmez Barcelona Supercomputing Center PS: We also know of Conjure and Happs. From andrewcoppin at btinternet.com Sun May 18 13:04:12 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Sun May 18 12:57:21 2008 Subject: [Haskell-cafe] Re: Write Haskell as fast as C. In-Reply-To: <48305798.7060707@btinternet.com> References: <20080515183132.GD31635@scytale.galois.com> <482DD8E4.2060509@btinternet.com> <482DDB38.2040108@serpentine.com> <482DDDC4.4020002@btinternet.com> <87mympnc83.fsf@nmd9999.imr.no> <20080516215933.GH13340@scytale.galois.com> <874p8xmhfp.fsf@nmd9999.imr.no> <87mymnlj3k.fsf@nmd9999.imr.no> <48305798.7060707@btinternet.com> Message-ID: <4830618C.1010706@btinternet.com> Andrew Coppin wrote: > Ketil Malde wrote: >> Ketil Malde writes: >> >> >>>> data EvidenceCode = IAC | IUG | IFR | NAC | NR | ... deriving Show >>>> >> >> >>> Could it be that this derived read instance is somehow very >>> inefficient? >>> >> >> To answer my own question: this is exactly it, ghc derives less than >> optimal code in this case. Rather than reiterate the case here, I did >> a quick writeup at http://blog.malde.org/, and would be quite happy >> about any feedback or suggestions. >> > > I think you'll find the code that GHC derives for a Read instance > handles extra whitespace and all kinds of other whatnot that you don't > actually need in this specific case. I suspect this is what's up - but > I don't have any hard proof for that. ;-) I wrote three programs: One does data Tag = Orange | Lemon | Lime | Apple | Banana | Pear | Peach deriving Read The other two use get_tag :: String -> Tag get_tag "Orange" = Orange get_tag "Lemon" = Lemon get_tag "Lime" = Lime get_tag "Apple" = Apple get_tag "Banana" = Banana get_tag "Pear" = Pear get_tag "Peach" = Peach get_tag _ = error "not a tag" and get_tag :: String -> Tag get_tag xs = case xs of [] -> bad (x:xs1) -> case x of 'A' -> case xs1 of "pple" -> Apple _ -> bad 'B' -> case xs1 of "anana" -> Banana _ -> bad 'L' -> case xs1 of "emon" -> Lemon "ime" -> Lime _ -> bad 'O' -> case xs1 of "range" -> Orange _ -> bad 'P' -> case xs1 of ('e':'r':xs2) -> case xs2 of "r" -> Pear "ch" -> Peach _ -> bad _ -> bad _ -> bad bad = error "not a tag" I wrote a driver program that reads a file of 1,000,000 tag values. Using the first version (GHC-derived Read instance) it took about 32 seconds to process. Using the second version (just a bunch of strings to match, no cleaverness at all) took approximately 1 second. The 3rd version was so fast I didn't have time to see the window open before it closed again. Note that all of this was using plain ordinary Strings, not ByteString or anything fancy like that. Note also that the actual documentation for the Prelude even says that Read is very slow. [Although it says it's slow for reading large structures, not large numbers of trivial structures.] None of this is really all that surprising; in the general case, a Read instance might have to skip over spaces or parse deeply nested brackets or any number of other things. If you know you don't need to handle all those cases, write your own parser. It shouldn't be hard to come up with something faster. [Altough obviously it's kinda tedious.] From ndmitchell at gmail.com Sun May 18 13:06:49 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Sun May 18 13:00:19 2008 Subject: [Haskell-cafe] Re: Write Haskell as fast as C. In-Reply-To: <4830618C.1010706@btinternet.com> References: <20080515183132.GD31635@scytale.galois.com> <482DD8E4.2060509@btinternet.com> <482DDB38.2040108@serpentine.com> <482DDDC4.4020002@btinternet.com> <87mympnc83.fsf@nmd9999.imr.no> <20080516215933.GH13340@scytale.galois.com> <874p8xmhfp.fsf@nmd9999.imr.no> <87mymnlj3k.fsf@nmd9999.imr.no> <48305798.7060707@btinternet.com> <4830618C.1010706@btinternet.com> Message-ID: <404396ef0805181006v39f467a3ub911db5fbc37367a@mail.gmail.com> Hi > None of this is really all that surprising; in the general case, a Read > instance might have to skip over spaces or parse deeply nested brackets or > any number of other things. If you know you don't need to handle all those > cases, write your own parser. It shouldn't be hard to come up with something > faster. [Altough obviously it's kinda tedious.] Feel free to automate it using Derive: http://www-users.cs.york.ac.uk/~ndm/derive/ Should be fairly easy for someone to do, and you can go as high-performance as you want. Thanks Neil From barsoap at web.de Sun May 18 13:07:46 2008 From: barsoap at web.de (Achim Schneider) Date: Sun May 18 13:01:24 2008 Subject: [Haskell-cafe] Re: Performance: MD5 References: <482EF0EF.2090207@btinternet.com> <296039281.20080517195217@gmail.com> <482FEB74.3090909@btinternet.com> <48303558.3010207@btinternet.com> <33BBF65E-DA62-4988-BDFE-04705A615529@ece.cmu.edu> <48304AE7.6010101@telenet.be> <483053A4.7000803@btinternet.com> <20080518180942.7d87f101@solaris> <483056CB.8030506@btinternet.com> Message-ID: <20080518190746.62a8b384@solaris> Andrew Coppin wrote: > Achim Schneider wrote: > > Andrew Coppin wrote: > > > > > >> I wonder what would happen if you instead had > >> a vast number of very simple proto-processors connected in a vast > >> network. [But I'm guessing the first thing that'll happen is that > >> the data is never where you want it to be...] > >> > >> > > You're not thinking of neuronal networks, are you? The interesting > > thing there is that they unite code and data. > > > > Damn; you've seen through my cunning disguise. ;-) > > In all seriousness, it's easy enough to build an artificial neural > network that computes a continuous function of several continuous > inputs. But it's much harder to see how, for example, you'd build a > text parser or something. It's really not clear how you implement > flow control with this kind of thing. It's so different to a Turing > machine is appears to render most of current computer science > irrelevant. And that's *a lot* of work to redo. > Hmmm... fuzzy logic, plus a lot of serialisation of parallel (that is, right now saved in linear ram) data. Don't make me think about it, or I'll be forced to confuse you with ramblings about how the brain works. (Is that control flow? ;) > Now, if you had a network of something a bit more complicated than > artificial neurons, but less complicated than an actual CPU... you'd > have... I don't know, maybe something useful? It's hard to say. You'd have something like a cell processor, if you go for (more or less) normal control flow. Maybe we will soon see dedicated pointer rams, because hardware manufacturers despair while trying to design a cache manager for 1024 cores: That would make it easy to spot which core holds which pointer, and thus also easy to move the data to it. How would a Haskell compiler look like that targets a FPGA? That is, compiling down to configware, not to a RTS built on top of it. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. From andrewcoppin at btinternet.com Sun May 18 13:11:11 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Sun May 18 13:04:19 2008 Subject: [Haskell-cafe] Type inference; always In-Reply-To: <7ca3f0160805180957p368b06e2tb8ec97234f57fb5e@mail.gmail.com> References: <4830557E.6040605@telenet.be> <7ca3f0160805180957p368b06e2tb8ec97234f57fb5e@mail.gmail.com> Message-ID: <4830632F.3050402@btinternet.com> Luke Palmer wrote: > Do you have an example of code that required an annotation to compile? > There is some trickiness around functions like "read" that can demand explicit type signatures. You also sometimes get this with numeric literals, array types, etc. From derek.a.elkins at gmail.com Sat May 17 16:27:52 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Sun May 18 13:04:34 2008 Subject: [Haskell-cafe] Mapping Haskell Concepts To C# 3 In-Reply-To: <3d96ac180805171251y53c535ffu2b228c95a23b4154@mail.gmail.com> References: <8aa524530805171241l1a013f13n973adeadc2364d@mail.gmail.com> <3d96ac180805171251y53c535ffu2b228c95a23b4154@mail.gmail.com> Message-ID: <1211056072.5514.128.camel@derek-laptop> On Sat, 2008-05-17 at 20:51 +0100, Sebastian Sylvan wrote: > > > 2008/5/17 Kaveh Shahbazian : > I have question on mapping some Haskell concepts to C# 3 ones. > Maybe there are not any strict equivalents; yet it helps: > > 1 - What is the equivalent of "Type Constructor" in C#? > > Class declaration. Generic ones. E.g. List, is a type where the > type constructor List has been applied to the type int. > > > 2 - What is the equivalent of "Data Constructor" in C#? > > Constructors, I guess. > > > 3 - What is the logical implementation of pattern matching in > C#? (For example using structures with indicator fields or > using interfaces and inheritance and dynamically dispatch in > calling overloaded methods. Also this question contain a > hidden one...GADTs!) > > You can use an abstract base class, and then inherit one class for > each constructor (e.g. base class Expression, and concrete subclasses > Mul, Add, etc.). Then you can use runtime type reflection to figure > out which kind of Expression you have and branch on it. Ideally you would use dynamic dispatch, not "type reflection" for this, e.g. abstract class List { public abstract int Length(); public abstract List Append(List xs); public abstract B Foldr(Func cons, B nil); } class Nil : List { public Nil() {} public override int Length() { return 0; } public override List Append(List xs) { return xs; } public override B Foldr(Func cons, B nil) { return nil; } } class Cons : List { public Cons(A a, List as) { Head = a; Tail = as; } public override int Length() { return 1 + Tail.Length(); } public override List Append(List xs) { return new Cons(Head, Tail.Append(xs)); } public override B Foldr(Func cons, B nil) { return cons(Head,Tail.Foldr(cons,nil)); } public readonly A Head; public readonly List Tail; } The Foldr method does make some constructors a bit special, but not too much. class Append : List { public Append(List xs, List ys) { Front = xs; Back = ys; } public override int Length() { return Front.Length() + Back.Length(); } public override List Append(List ys) { return new Append(this, ys); } public override B Foldr(Func cons, B nil) { Front.Foldr(cons, Back.Foldr(cons, nil)); } public readonly List Front, Back; } We could, of course, define Cons.Append to use the Append class instead. From derek.a.elkins at gmail.com Sun May 18 13:10:38 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Sun May 18 13:04:50 2008 Subject: [Haskell-cafe] Type inference; always In-Reply-To: <7ca3f0160805180957p368b06e2tb8ec97234f57fb5e@mail.gmail.com> References: <4830557E.6040605@telenet.be> <7ca3f0160805180957p368b06e2tb8ec97234f57fb5e@mail.gmail.com> Message-ID: <1211130639.5514.132.camel@derek-laptop> On Sun, 2008-05-18 at 16:57 +0000, Luke Palmer wrote: > 2008/5/18 Peter Verswyvelen : > > In Haskell, I sometimes have to annotate code with type info because the > > type-inferer otherwise fails (even with -XNoMonomorphismRestriction). > > Surely, most of the time this is because I was writing buggy code, but > > sometimes, type annotation just seems needed to get a successful compilation > > (luckily not as often as in C# 3.0) > > Then you must either be programming using extensions or you have found > a bug. Haskell 98 should never require annotations (modulo > monomorphism). This is incorrect. There are two (other) situations where you need type annotations in Haskell 98. One situation is when you use polymorphic recursion, but that is pretty rare unless you are writing nested data types. The other situation is when not enough information is provided to resolve a typeclass constraint, e.g. good ole show . read. From ndmitchell at gmail.com Sun May 18 13:11:30 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Sun May 18 13:05:08 2008 Subject: [Haskell-cafe] Re: Performance: MD5 In-Reply-To: <20080518190746.62a8b384@solaris> References: <482EF0EF.2090207@btinternet.com> <482FEB74.3090909@btinternet.com> <48303558.3010207@btinternet.com> <33BBF65E-DA62-4988-BDFE-04705A615529@ece.cmu.edu> <48304AE7.6010101@telenet.be> <483053A4.7000803@btinternet.com> <20080518180942.7d87f101@solaris> <483056CB.8030506@btinternet.com> <20080518190746.62a8b384@solaris> Message-ID: <404396ef0805181011r6103558cp6f193bfc9c6cdb3e@mail.gmail.com> Hi > How would a Haskell compiler look like that targets a FPGA? That is, > compiling down to configware, not to a RTS built on top of it. http://www-users.cs.york.ac.uk/~mfn/reduceron2/ Thanks Neil From bulat.ziganshin at gmail.com Sun May 18 13:16:31 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sun May 18 13:11:39 2008 Subject: [Haskell-cafe] Type inference; always In-Reply-To: <1211130639.5514.132.camel@derek-laptop> References: <4830557E.6040605@telenet.be> <7ca3f0160805180957p368b06e2tb8ec97234f57fb5e@mail.gmail.com> <1211130639.5514.132.camel@derek-laptop> Message-ID: <1493762511.20080518211631@gmail.com> Hello Derek, Sunday, May 18, 2008, 9:10:38 PM, you wrote: > This is incorrect. There are two (other) situations where you need type > annotations in Haskell 98. One situation is when you use polymorphic > recursion, but that is pretty rare unless you are writing nested data > types can you give examples? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From mail at philip.in-aachen.net Sun May 18 13:29:40 2008 From: mail at philip.in-aachen.net (=?ISO-8859-15?Q?Philip_M=FCller?=) Date: Sun May 18 13:23:10 2008 Subject: [Haskell-cafe] ByteString comparison question (was: another Newbie performance question) Message-ID: <48306784.9010008@philip.in-aachen.net> Hi, I'm changing my CSV program to use ByteStrings, but I have problems with this: readCSVLine :: String -- line as String -> [String] -- line broken down into the value Strings readCSVLine = unfoldr builder where builder [] = Nothing builder xs = Just $ readField xs readField [] = ([],[]) readField (',':xs) = ([],xs) readField ('"':xs) = (field,rest) where (field,'"':rest) = break (== '"') xs So far, I have something like this - doesn't look too good to me, and doesn't compile: import qualified Data.ByteString as B import qualified Data.ByteString.Char8 as C8 type CSV = [[B.ByteString]] readCSVLine :: B.ByteString -- line as String -> [B.ByteString] -- line broken down into the value Strings readCSVLine = unfoldr builder where builder xs | xs == B.empty = Nothing | otherwise = Just $ readField xs readField xs | xs == B.empty = ([],[]) | B.head xs == ',' = ([], B.tail xs) | B.head xs == '"' = (field, B.tail rest) where field,rest) = B.break (== '"') xs I do not know how to compare a Word8 to a Char. Or maybe I don't need to? Regards Philip From barsoap at web.de Sun May 18 13:29:53 2008 From: barsoap at web.de (Achim Schneider) Date: Sun May 18 13:23:31 2008 Subject: [Haskell-cafe] Re: Performance: MD5 References: <482EF0EF.2090207@btinternet.com> <482FEB74.3090909@btinternet.com> <48303558.3010207@btinternet.com> <33BBF65E-DA62-4988-BDFE-04705A615529@ece.cmu.edu> <48304AE7.6010101@telenet.be> <483053A4.7000803@btinternet.com> <20080518180942.7d87f101@solaris> <483056CB.8030506@btinternet.com> <20080518190746.62a8b384@solaris> <404396ef0805181011r6103558cp6f193bfc9c6cdb3e@mail.gmail.com> Message-ID: <20080518192953.6637e153@solaris> "Neil Mitchell" wrote: > > How would a Haskell compiler look like that targets a FPGA? That is, > > compiling down to configware, not to a RTS built on top of it. > > http://www-users.cs.york.ac.uk/~mfn/reduceron2/ > I'm only on page 5 and already drooling. fact n = 1 (n (==)) 1 (fact (1 (n (-))) (n (*))) looks somewhat suspiciously like forth to me. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. From barsoap at web.de Sun May 18 13:34:18 2008 From: barsoap at web.de (Achim Schneider) Date: Sun May 18 13:28:32 2008 Subject: [Haskell-cafe] Re: ByteString comparison question (was: another Newbie performance question) References: <48306784.9010008@philip.in-aachen.net> Message-ID: <20080518193418.0a013e0e@solaris> Philip M?ller wrote: > I do not know how to compare a Word8 to a Char. Or maybe I don't need > to? > You don't need to, just use ByteString.Char8 or ByteString.Lazy.Char8. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. From derek.a.elkins at gmail.com Sun May 18 13:51:18 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Sun May 18 13:44:50 2008 Subject: [Haskell-cafe] Type inference; always In-Reply-To: <1493762511.20080518211631@gmail.com> References: <4830557E.6040605@telenet.be> <7ca3f0160805180957p368b06e2tb8ec97234f57fb5e@mail.gmail.com> <1211130639.5514.132.camel@derek-laptop> <1493762511.20080518211631@gmail.com> Message-ID: <1211133078.5514.145.camel@derek-laptop> On Sun, 2008-05-18 at 21:16 +0400, Bulat Ziganshin wrote: > Hello Derek, > > Sunday, May 18, 2008, 9:10:38 PM, you wrote: > > This is incorrect. There are two (other) situations where you need type > > annotations in Haskell 98. One situation is when you use polymorphic > > recursion, but that is pretty rare unless you are writing nested data > > types > > can you give examples? -- untested -- all type annotations are necessary -- A nested data type example data PerfectTree a = Leaf a | Succ (PerfectTree (a,a)) size :: PerfectTree a -> Int size (Leaf _) = 1 size (Succ t) = 2 * size t -- a toy example without nested data types f :: Show a => Int -> a -> String f 0 x = show x f n x = f (n-1) (x,x) -- a less toy example bitReverse :: [a] -> [a] bitReverse [x] = [x] bitReverse xs = uncurry (++) . unzip . bitReverse . pairUp $ xs where pairUp [] = [] pairUp (x:y:xs) = (x,y):pairUp xs From ketil at malde.org Sun May 18 13:53:25 2008 From: ketil at malde.org (Ketil Malde) Date: Sun May 18 13:46:39 2008 Subject: [Haskell-cafe] ByteString comparison question In-Reply-To: <48306784.9010008@philip.in-aachen.net> ("Philip =?utf-8?Q?M?= =?utf-8?Q?=C3=BCller=22's?= message of "Sun\, 18 May 2008 19\:29\:40 +0200") References: <48306784.9010008@philip.in-aachen.net> Message-ID: <877idrlcru.fsf@nmd9999.imr.no> Philip M?ller writes: > import qualified Data.ByteString as B > import qualified Data.ByteString.Char8 as C8 Note that these use the same underlying data structure, but Char8 interprets the contents as Char instead of Word8. So the B.heads and B.break should be CS8 - for consistency's sake, you could replace them all and drop the "B" import. > readField xs | xs == B.empty = ([],[]) > | B.head xs == ',' = ([], B.tail xs) > | B.head xs == '"' = (field, B.tail rest) > where > field,rest) = B.break (== '"') xs -k -- If I haven't seen further, it is by standing in the footprints of giants From mail at philip.in-aachen.net Sun May 18 13:56:19 2008 From: mail at philip.in-aachen.net (=?ISO-8859-1?Q?Philip_M=FCller?=) Date: Sun May 18 13:49:39 2008 Subject: [Haskell-cafe] Re: ByteString comparison question (was: another Newbie performance question) In-Reply-To: <20080518193418.0a013e0e@solaris> References: <48306784.9010008@philip.in-aachen.net> <20080518193418.0a013e0e@solaris> Message-ID: <48306DC3.8090705@philip.in-aachen.net> Achim Schneider schrieb: > Philip M?ller wrote: > >> I do not know how to compare a Word8 to a Char. Or maybe I don't need >> to? >> > You don't need to, just use ByteString.Char8 or ByteString.Lazy.Char8. Could you give a short example of how to check whether a ByteString starts with a comma (',')? I tried this import qualified Data.ByteString.Char8 as B readCSVLine :: B.ByteString -- line as String -> [B.ByteString] -- line broken down into the value Strings readCSVLine = unfoldr builder where builder xs | xs == B.empty = Nothing | otherwise = Just $ readField xs readField xs | xs == B.empty = (B.empty,B.empty) | B.head xs == ',' = (B.empty, B.tail xs) | B.head xs == '"' = (field, B.tail rest) where (field,rest) = B.break (== '"') xs But now I get strange errors when compiling, like Main.o: In function `rTD_info': (.text+0x5a): undefined reference to `bytestringzm0zi9zi1zi0_DataziByteStringziInternal_zdf2_closure' Is this a problem with my Code or is it just GHC unable to find the ByteString package? Regards Philip From barsoap at web.de Sun May 18 14:11:10 2008 From: barsoap at web.de (Achim Schneider) Date: Sun May 18 14:04:58 2008 Subject: [Haskell-cafe] Re: ByteString comparison question (was: another Newbie performance question) References: <48306784.9010008@philip.in-aachen.net> <20080518193418.0a013e0e@solaris> <48306DC3.8090705@philip.in-aachen.net> Message-ID: <20080518201110.51dac75f@solaris> Philip M?ller wrote: > Achim Schneider schrieb: > > Philip M?ller wrote: > > > >> I do not know how to compare a Word8 to a Char. Or maybe I don't > >> need to? > >> > > You don't need to, just use ByteString.Char8 or > > ByteString.Lazy.Char8. > > Could you give a short example of how to check whether a ByteString > starts with a comma (',')? > import Parsec import Parsec.ByteString.Lazy check s = runParser (char ',') () "" s ;) > But now I get strange errors when compiling, like > > Main.o: In function `rTD_info': > (.text+0x5a): undefined reference to > `bytestringzm0zi9zi1zi0_DataziByteStringziInternal_zdf2_closure' > > Is this a problem with my Code or is it just GHC unable to find the > ByteString package? > No, it can find it, or you would have gotten errors beforehand. The linker can't find it because GHC can be kind of demented when it comes to remembering which packages it used while compiling, depending on options/processing mode. use ghc -package bytestring or, preferably, ghc --make -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. From bertram.felgenhauer at googlemail.com Sun May 18 14:22:38 2008 From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer) Date: Sun May 18 14:16:16 2008 Subject: [Haskell-cafe] Re: Write Haskell as fast as C. In-Reply-To: <48305798.7060707@btinternet.com> References: <20080515183132.GD31635@scytale.galois.com> <482DD8E4.2060509@btinternet.com> <482DDB38.2040108@serpentine.com> <482DDDC4.4020002@btinternet.com> <87mympnc83.fsf@nmd9999.imr.no> <20080516215933.GH13340@scytale.galois.com> <874p8xmhfp.fsf@nmd9999.imr.no> <87mymnlj3k.fsf@nmd9999.imr.no> <48305798.7060707@btinternet.com> Message-ID: <20080518182238.GA4211@zombie.inf.tu-dresden.de> Andrew Coppin wrote: [...] > I think you'll find the code that GHC derives for a Read instance handles > extra whitespace and all kinds of other whatnot that you don't actually > need in this specific case. I suspect this is what's up - but I don't have > any hard proof for that. ;-) Parentheses are handled as well. It's worse than that - derived read instances are defined in terms of 'lex' (via lexP in GHC.Read) which, among other things, recognizes numerical and string constants. The latter has the odd effect that with the following declaration, > data A = A deriving (Read, Show) the expression read ('"' : repeat ' ') :: A is the wrong kind of bottom - instead of a parse error, you get an infinite loop. Bertram From benedict.arnold at gmail.com Sun May 18 14:26:09 2008 From: benedict.arnold at gmail.com (Ben Arnold) Date: Sun May 18 14:19:41 2008 Subject: [Haskell-cafe] My experience setting up Haskell up for GUI development Message-ID: <17676a590805181126g676144ebt491c20882b337cf1@mail.gmail.com> I'm running Windows Vista and I've been trying to set up an environment for writing GUI applications. A Google search pointed me at two major GUI toolkits for Haskell: gtk2hs and wxHaskell. I started with gtk2hs. The installation instructions were straightfoward and easy to follow, but they just didn't work. The installer did nothing. It opened a command window and immediately terminated. When I ran it from a command window it terminated immediately, apparently doing nothing at all. Running as Administrator didn't help. There was no error message, the log file option didn't generate a log file and Googling for a solution didn't come up with anything. So I gave up on gtk2hs. WxHaskell was a little trickier but more successful. There didn't appear to be any installation instructions on the website, but it did imply that I needed to install wxWidgets first. I did that, and made sure the paths didn't have spaces in them (yawn). And after restarting the PC eventually I got a working Hello World dialogue box. Which is nice, except that when I call "main" twice in succession from GHCi, ghc.exe crashes. So I have no confidence in the wxHaskell libraries either. I don't want to invest time in programming with libraries that perform illegal operations on my operating system. I like Haskell; I really do. I've toyed around with it before a few times and I want to learn more about it, but I can't confine myself to command-line applications forever and for better or worse I run a Windows box. So, in practice, do other people write GUI apps with Haskell on Windows? And if they do, how do they do it? I feel I've got to the stage where I need a concrete recommendation from the experts. My installation: - Windows Vista Home Premium 32-bit 6.0.6001 First attempt - GHC 6.6.1 - gtk2hs-09.12.exe Second attempt - GHC 6.8.2 - wxMSW 2.6.3 - wxHaskell 0.10.3 Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080518/028dd419/attachment.htm From ndmitchell at gmail.com Sun May 18 14:35:41 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Sun May 18 14:29:11 2008 Subject: [Haskell-cafe] My experience setting up Haskell up for GUI development In-Reply-To: <17676a590805181126g676144ebt491c20882b337cf1@mail.gmail.com> References: <17676a590805181126g676144ebt491c20882b337cf1@mail.gmail.com> Message-ID: <404396ef0805181135x3b77d371v8585fad10f524ac1@mail.gmail.com> Hi > A Google search pointed me at two major GUI toolkits for Haskell: gtk2hs and > wxHaskell. My answer is to use Gtk2hs. Unfortunately, the releases are somewhat behind so you usually need to grab a special preview release to get it working on Windows. That's a very sad state of affairs, and as is easy to tell from this email, it gives the impression that Gtk2hs is busted on Windows. The *only* way to fix this is to have Gtk2hs builds go live within minutes of a GHC release going live - and I've been pushing for that for a while (but tend to give up once my computer is fixed...) Hopefully Duncan will know if your problem is due to using an old installer, or just a Vista thing - either way its a safe bet that Duncan will fix it in due course. > So, in practice, do other people write GUI apps with Haskell on Windows? And > if they do, how do they do it? I feel I've got to the stage where I need a > concrete recommendation from the experts. Typically you need to use GHC and not GHCi - or at least you get more success that way. If the installation instructions for wxHaskell need improving, do tell the team behind it. wxHaskell was unmaintained for a while, so they are still picking up speed, getting the basics working - before tackling the polish issues. As a reference point, I still do all my GUI programming in C# - although am slowly taking pot shots at Haskell/Gtk2hs as new things crop up. Although I suspect I'm likely to try F# for GUI programming with my next project. Thanks Neil From bulat.ziganshin at gmail.com Sun May 18 14:48:12 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sun May 18 14:43:23 2008 Subject: [Haskell-cafe] My experience setting up Haskell up for GUI development In-Reply-To: <17676a590805181126g676144ebt491c20882b337cf1@mail.gmail.com> References: <17676a590805181126g676144ebt491c20882b337cf1@mail.gmail.com> Message-ID: <1494060431.20080518224812@gmail.com> Hello Ben, Sunday, May 18, 2008, 10:26:09 PM, you wrote: > I'm running Windows Vista and I've been trying to set up an > environment for writing GUI applications. i'm a XP user, nevertheless try this for gtk2hs: 6.6.1: http://haskell.org/ghc/dist/6.6.1/ghc-6.6.1-i386-windows.exe http://sourceforge.net/project/showfiles.php?group_id=49207&package_id=42440 6.8.2: http://haskell.org/ghc/dist/6.8.2/ghc-6.8.2-i386-windows.exe http://haskell.org/~duncan/gtk2hs/gtk2hs-0.9.12.1.exe the first way is my working environment -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From barsoap at web.de Sun May 18 14:52:17 2008 From: barsoap at web.de (Achim Schneider) Date: Sun May 18 14:45:56 2008 Subject: [Haskell-cafe] Re: My experience setting up Haskell up for GUI development References: <17676a590805181126g676144ebt491c20882b337cf1@mail.gmail.com> Message-ID: <20080518205217.287fb8d8@solaris> "Ben Arnold" wrote: > [...] Which is nice, except that when I call "main" twice in > succession from GHCi, ghc.exe crashes. So I have no confidence in the > wxHaskell libraries either. I don't want to invest time in > programming with libraries that perform illegal operations on my > operating system. > I assume that you didn't use :main, but just evaluated "main"... and that either wx or the native windoze gui doesn't like you reinitialising it without unloading the executable that does it or whatever: That's the problem if you call into C code, all kind of things might go wrong. If you don't want to invest time in programming with stuff that can perform illegal operations, or at least be sure that you don't do illegal operations, you are kind of stuck with Haskell, though. You might to try out things like Fruit, which isolate you from all this stuff. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. From benedict.arnold at gmail.com Sun May 18 15:21:39 2008 From: benedict.arnold at gmail.com (Ben Arnold) Date: Sun May 18 15:15:07 2008 Subject: [Haskell-cafe] My experience setting up Haskell up for GUI development In-Reply-To: <404396ef0805181135x3b77d371v8585fad10f524ac1@mail.gmail.com> References: <17676a590805181126g676144ebt491c20882b337cf1@mail.gmail.com> <404396ef0805181135x3b77d371v8585fad10f524ac1@mail.gmail.com> Message-ID: <17676a590805181221s2dd09e53jcfad3a87cd77fb33@mail.gmail.com> Thanks for such a quick response! There seems to be a new version of Gtk2hs now (or I accidentally downloaded an old one earlier). Either way the installer was easy to use and the Hello World program ran (even within GHCi). Thanks for your help. I'm very appreciative to all those who work on these projects, sorry for sounding frustrated. Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080518/aeb0065e/attachment.htm From wnoise at ofb.net Sun May 18 15:43:09 2008 From: wnoise at ofb.net (Aaron Denney) Date: Sun May 18 15:36:48 2008 Subject: [Haskell-cafe] Re: Performance: MD5 References: <482EF0EF.2090207@btinternet.com> <296039281.20080517195217@gmail.com> <482FEB74.3090909@btinternet.com> <20080518091716.GA22995@scytale.galois.com> <48300301.2030906@btinternet.com> Message-ID: On 2008-05-18, Andrew Coppin wrote: >> (did you look at the C implementation?) >> > > I can't read C. (FWIW, I think I did briefly stare at the sources, but > eventually gave up because I simply had no clue what's going on.) It's worth learning. It's still the only widely used abstract portable assembler with fairly standard ABIs for each platform. Go read K&R[1]. It shouldn't take more than a week's worth of spare time. [1] The C Programming Language (2nd Edition), Kernigan and Ritchie, Prentice Hall, 1998 http://www.amazon.com/Programming-Language-Prentice-Hall-Software/dp/0131103628/ -- Aaron Denney -><- From barsoap at web.de Sun May 18 15:52:42 2008 From: barsoap at web.de (Achim Schneider) Date: Sun May 18 15:46:24 2008 Subject: [Haskell-cafe] Re: Performance: MD5 References: <482EF0EF.2090207@btinternet.com> <296039281.20080517195217@gmail.com> <482FEB74.3090909@btinternet.com> <20080518091716.GA22995@scytale.galois.com> <48300301.2030906@btinternet.com> Message-ID: <20080518215242.0c16b017@solaris> Aaron Denney wrote: > Go read K&R[1]. It shouldn't take more than a week's worth of spare > time. > HELL NO! There's a reason why my lecturer always refered to it as "Knall & Rauch C" (Bang and Smoke C). Get the Harbison & Steele instead: http://careferencemanual.com/ -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. From valgarv at gmx.net Sun May 18 15:57:43 2008 From: valgarv at gmx.net (Ariel J. Birnbaum) Date: Sun May 18 15:51:15 2008 Subject: [Haskell-cafe] Re: Control.Exception.evaluate - 'correct definition' not so correct In-Reply-To: <5ab17e790805041730o33b378e4u74f4f1f9e813e72b@mail.gmail.com> References: <20080503091917.GA5333@shion.is.fushizen.net> <5ab17e790805041730o33b378e4u74f4f1f9e813e72b@mail.gmail.com> Message-ID: <200805182257.43931.valgarv@gmx.net> > > According to the monad law > > > > f >>= return = f > > [... snip ...] > > So, "(undefined >> return 2) = (return 2)" > *scratching head* I don't see how that's a counterexample of the monad law. Instantiating the law for undefined would IMO yield something like: (undefined >>= return) = \r -> return (undefined r) r = \r -> undefined r = undefined (considering "undefined" as equivalent to "const undefined", which iirc was the definition of _|_ for function types). What am I missing? -- Ariel J. Birnbaum From andrewcoppin at btinternet.com Sun May 18 16:01:54 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Sun May 18 15:55:03 2008 Subject: [Haskell-cafe] My experience setting up Haskell up for GUI development In-Reply-To: <17676a590805181126g676144ebt491c20882b337cf1@mail.gmail.com> References: <17676a590805181126g676144ebt491c20882b337cf1@mail.gmail.com> Message-ID: <48308B32.3030400@btinternet.com> Ben Arnold wrote: > So, in practice, do other people write GUI apps with Haskell on > Windows? And if they do, how do they do it? I feel I've got to the > stage where I need a concrete recommendation from the experts. Yeah, this kind of thing is annoyingly common in Haskell circles. It's not insurmountable though. wxHaskell has been "dead" for a while. It recently came back to life, but I imagine it's still a little dusty round the edges. [FWIW, I'm really happy to see this being revived! I've never used it, but I've heard good things about it...] I do all my work with Gtk2hs. Yes, GTK isn't very common on Windows. But it seems to work the nicest. There's an on-going problem though that each release of Gtk2hs only works with one (or maybe two) releases of GHC, and every time a new release of GHC comes out, you gotta wait a while before Gtk2hs catches up. However, the installer usually *tells* you that's the problem; what you're seeing sounds more like the installer program doesn't like Vista. I can't offer any help in that direction, unfortunately... As for your program crashing when run twice, wxWidgets probably doesn't like being initialised twice. I've never used wxHaskell, and I don't know how your program is structured, but if you can avoid initialising the library twice, you could be able to rerun the core of your program over and over. Otherwise you're kind of stuck with the tedious edit-compile-run cycle. From andrewcoppin at btinternet.com Sun May 18 16:09:46 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Sun May 18 16:02:55 2008 Subject: [Haskell-cafe] Re: Reduceron (was Performance: MD5) In-Reply-To: <20080518192953.6637e153@solaris> References: <482EF0EF.2090207@btinternet.com> <482FEB74.3090909@btinternet.com> <48303558.3010207@btinternet.com> <33BBF65E-DA62-4988-BDFE-04705A615529@ece.cmu.edu> <48304AE7.6010101@telenet.be> <483053A4.7000803@btinternet.com> <20080518180942.7d87f101@solaris> <483056CB.8030506@btinternet.com> <20080518190746.62a8b384@solaris> <404396ef0805181011r6103558cp6f193bfc9c6cdb3e@mail.gmail.com> <20080518192953.6637e153@solaris> Message-ID: <48308D0A.7060507@btinternet.com> Achim Schneider wrote: > "Neil Mitchell" wrote: > > >>> How would a Haskell compiler look like that targets a FPGA? That is, >>> compiling down to configware, not to a RTS built on top of it. >>> >> http://www-users.cs.york.ac.uk/~mfn/reduceron2/ >> >> > I'm only on page 5 and already drooling. > Damnit, this paper is making me hungry! :-( I almost want to run out into the street and purchase some FPGA hardware right now! [I mean, I wanted to before, but this makes me want to even more.] But hey, let's not get crazy here. (Yet.) From kolar at fit.vutbr.cz Sun May 18 16:14:41 2008 From: kolar at fit.vutbr.cz (=?ISO-8859-2?Q?Du=B9an_Kol=E1=F8?=) Date: Sun May 18 16:05:22 2008 Subject: [Haskell-cafe] ByteString.pack behavior Message-ID: <48308E31.5080807@fit.vutbr.cz> Hello all, Maybe there is something obvious I can't see, but I have this behavior for 6.8.2 ghci: $ghci ttest1p.hs GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. [1 of 1] Compiling Main ( ttest1p.hs, interpreted ) Ok, modules loaded: Main. *Main> encode' [1..100] Loading package array-0.1.0.0 ... linking ... done. Loading package bytestring-0.9.0.1 ... linking ... done. [1,0,2,0,3,0,4,0,5,0,6,0,7,0,8,0,9,0,10,0,11,0,12,0,13,0,... // deleted *Main> B.pack [0..100] "\NUL\SOH\STX\ETX\EOT\ENQ\ACK\a\b\t\n\v\f\r\SO\SI\DLE\DC1\DC2\DC3\DC4\NAK\SYN\ETB\CAN\EM\SUB\ESC\FS\GS\RS\US !\"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcd" *Main> B.pack $ encode' [1..100] "*** Exception: divide by zero where ttest1p.hs: import qualified Data.ByteString as B encode' [] = [] encode' (x:xs) = if x==0 then 0:0:encode' xs else (x `mod` 256) : (x `div` 256) : encode' xs What is the difference, except list length and value structure? Where is my error? Thanks for any hint, Dusan From bulat.ziganshin at gmail.com Sun May 18 16:13:09 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sun May 18 16:08:37 2008 Subject: [Haskell-cafe] My experience setting up Haskell up for GUI development In-Reply-To: <17676a590805181126g676144ebt491c20882b337cf1@mail.gmail.com> References: <17676a590805181126g676144ebt491c20882b337cf1@mail.gmail.com> Message-ID: <892648598.20080519001309@gmail.com> Hello Ben, Sunday, May 18, 2008, 10:26:09 PM, you wrote: > So, in practice, do other people write GUI apps with Haskell on > Windows? And if they do, how do they do it? I feel I've got to the > stage where I need a concrete recommendation from the experts. after i've wrote a few thousands lines with gtk2hs, i think the following: if main part of your program is GUI - it's better to stick with C# and all its visual bells and whistles. the only good thing with gtk2hs is that you got Linux portability for free. actually, people will think that you have developed it on linux and ported to windows at the last day :D look at http://freearc.org screenshots or install program itself to see that i mean if you are developing large haskell program and just need to add GUI frontend to it - you are on the right way if you develop serious (say, commercial) application - consider developing algorithm in Haskell and writing GUI in C# or C++ to take best of both worlds. look for example at http://www.bcgsoft.com/ - does this make difference compared to my program? :D -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From dons at galois.com Sun May 18 16:23:10 2008 From: dons at galois.com (Don Stewart) Date: Sun May 18 16:16:53 2008 Subject: [Haskell-cafe] ByteString.pack behavior In-Reply-To: <48308E31.5080807@fit.vutbr.cz> References: <48308E31.5080807@fit.vutbr.cz> Message-ID: <20080518202310.GB7494@scytale.galois.com> kolar: > Hello all, > > Maybe there is something obvious I can't see, but I have this behavior > for 6.8.2 ghci: > > $ghci ttest1p.hs > GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help > Loading package base ... linking ... done. > [1 of 1] Compiling Main ( ttest1p.hs, interpreted ) > Ok, modules loaded: Main. > *Main> encode' [1..100] > Loading package array-0.1.0.0 ... linking ... done. > Loading package bytestring-0.9.0.1 ... linking ... done. > [1,0,2,0,3,0,4,0,5,0,6,0,7,0,8,0,9,0,10,0,11,0,12,0,13,0,... // deleted > *Main> B.pack [0..100] > "\NUL\SOH\STX\ETX\EOT\ENQ\ACK\a\b\t\n\v\f\r\SO\SI\DLE\DC1\DC2\DC3\DC4\NAK\SYN\ETB\CAN\EM\SUB\ESC\FS\GS\RS\US > !\"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcd" > *Main> B.pack $ encode' [1..100] > "*** Exception: divide by zero > > where ttest1p.hs: > > import qualified Data.ByteString as B > > encode' [] = [] > encode' (x:xs) = > if x==0 then 0:0:encode' xs > else (x `mod` 256) : (x `div` 256) : encode' xs > > > What is the difference, except list length and value structure? Where is > my error? > ByteStrings take Word8 values as input, so x `div` 256 , where 256 :: Word8, overflows to 0. -- Don From miguelimo38 at yandex.ru Sun May 18 16:24:44 2008 From: miguelimo38 at yandex.ru (Miguel Mitrofanov) Date: Sun May 18 16:18:23 2008 Subject: [Haskell-cafe] ByteString.pack behavior In-Reply-To: <48308E31.5080807@fit.vutbr.cz> References: <48308E31.5080807@fit.vutbr.cz> Message-ID: Yes, this is obvious B.pack :: [GHC.Word.Word8] -> B.ByteString So, in B.pack $ encode' [1..100] GHCi expects "encode' [1..100]" to be of type [GHC.Word.Word8] Now, your encode' has type encode' :: Integral a => [a] -> [a] So, in encode' definition, all calculations are in Word8. Now, (256 :: Word8) is zero. No wonder you get a "divide by zero" error when trying to calculate "something `mod` 256" On 19 May 2008, at 00:14, Du?an Kol?? wrote: > Hello all, > > Maybe there is something obvious I can't see, but I have this > behavior for 6.8.2 ghci: > > $ghci ttest1p.hs > GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help > Loading package base ... linking ... done. > [1 of 1] Compiling Main ( ttest1p.hs, interpreted ) > Ok, modules loaded: Main. > *Main> encode' [1..100] > Loading package array-0.1.0.0 ... linking ... done. > Loading package bytestring-0.9.0.1 ... linking ... done. > [1,0,2,0,3,0,4,0,5,0,6,0,7,0,8,0,9,0,10,0,11,0,12,0,13,0,... // > deleted > *Main> B.pack [0..100] > "\NUL\SOH\STX\ETX\EOT\ENQ\ACK\a\b\t\n\v\f\r\SO\SI\DLE > \DC1\DC2\DC3\DC4\NAK\SYN\ETB\CAN\EM\SUB\ESC\FS\GS\RS\US !\"#$%&'()* > +,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcd" > *Main> B.pack $ encode' [1..100] > "*** Exception: divide by zero > > where ttest1p.hs: > > import qualified Data.ByteString as B > > encode' [] = [] > encode' (x:xs) = > if x==0 then 0:0:encode' xs > else (x `mod` 256) : (x `div` 256) : encode' xs > > > What is the difference, except list length and value structure? > Where is my error? > > Thanks for any hint, > > Dusan > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From duncan.coutts at worc.ox.ac.uk Sun May 18 16:10:42 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun May 18 16:21:33 2008 Subject: [Haskell-cafe] My experience setting up Haskell up for GUI development In-Reply-To: <17676a590805181126g676144ebt491c20882b337cf1@mail.gmail.com> References: <17676a590805181126g676144ebt491c20882b337cf1@mail.gmail.com> Message-ID: <1211141442.5824.243.camel@localhost> On Sun, 2008-05-18 at 19:26 +0100, Ben Arnold wrote: > I'm running Windows Vista and I've been trying to set up an > environment for writing GUI applications. > > A Google search pointed me at two major GUI toolkits for Haskell: > gtk2hs and wxHaskell. > > I started with gtk2hs. The installation instructions were > straightfoward and easy to follow, but they just didn't work. The > installer did nothing. It opened a command window and immediately > terminated. When I ran it from a command window it terminated > immediately, apparently doing nothing at all. Running as Administrator > didn't help. There was no error message, the log file option didn't > generate a log file and Googling for a solution didn't come up with > anything. There's definitely something weird going on there. I've not personally tested on Vista but I've not heard any other reports of it not working. Are you sure the download of the installed completed successfully? If it exits immediately it sounds like a busted download. Do you have any way of checking it? Perhaps just the file length if there's no easy way of doing md5 on windows. Since you're now using ghc 6.8.2 you'll want this build of gtk2hs which works with that version of ghc: http://haskell.org/~duncan/gtk2hs/gtk2hs-0.9.12.1.exe length: 13,651,002 bytes md5: e48ea30426396bf162106ffcda02847f > Which is nice, except that when I call "main" twice in succession from > GHCi, ghc.exe crashes. So I have no confidence in the wxHaskell > libraries either. I don't want to invest time in programming with > libraries that perform illegal operations on my operating system. Note that Gtk2Hs does not suffer from the problem of calling main twice in ghci. Duncan From bulat.ziganshin at gmail.com Sun May 18 16:35:33 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sun May 18 16:31:19 2008 Subject: [Haskell-cafe] Fun with Darcs In-Reply-To: <1210889153.5824.137.camel@localhost> References: <93BECC602E286B499D5443ECB850D2FF01331E95@newman.usa.aitgroupad.com> <482B3022.2050303@btinternet.com> <482B38FC.2000705@btinternet.com> <482B3F91.7050602@btinternet.com> <20080514201346.GP8845@darcs.net> <482B505C.3020300@btinternet.com> <259058831.20080515010114@gmail.com> <1210889153.5824.137.camel@localhost> Message-ID: <1578946504.20080519003533@gmail.com> Hello Duncan, Friday, May 16, 2008, 2:05:53 AM, you wrote: > Of course if you're deploying a Windows program that uses gtk2hs then > using just the runtime dlls is just the right thing to do. Though for > that case we provide the runtime dlls: > http://haskell.org/gtk2hs/win32/ > As an example, here's an installer for a standalone prog that uses > gtk2hs but doesn't need ghc or gtk2hs to be installed already: > http://haskell.org/~duncan/gtk2hs/LSystemSetup.exe i've just tried that. for me there is still one problem - my program includes a lot of other files beside exe and i will be glad to have gtk2hs put to separate subtree. is it possible? say, c:/Program Files/WinArc/winarc.* c:/Program Files/WinArc/gtk2hs/bin/*.dll c:/Program Files/WinArc/gtk2hs/etc/* c:/Program Files/WinArc/gtk2hs/lib/* and so on -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From andrewcoppin at btinternet.com Sun May 18 16:39:17 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Sun May 18 16:32:36 2008 Subject: [Haskell-cafe] My experience setting up Haskell up for GUI development In-Reply-To: <1211141442.5824.243.camel@localhost> References: <17676a590805181126g676144ebt491c20882b337cf1@mail.gmail.com> <1211141442.5824.243.camel@localhost> Message-ID: <483093F5.8010301@btinternet.com> Duncan Coutts wrote: > Are you sure the download of the installed completed successfully? If it > exits immediately it sounds like a busted download. Do you have any way > of checking it? Perhaps just the file length if there's no easy way of > doing md5 on windows. > http://www.toast442.org/md5/ Useful little program for quickly finding [or checking] the MD5 hash of any file under Windows, using simple drag and drop. From josef.svenningsson at gmail.com Sun May 18 16:49:31 2008 From: josef.svenningsson at gmail.com (Josef Svenningsson) Date: Sun May 18 16:43:00 2008 Subject: [Haskell-cafe] Re: ghc on Ubuntu Linux? In-Reply-To: <5ae4f2ba0805171824y35412927r46c7b7614da42c29@mail.gmail.com> References: <5ae4f2ba0805162151l9ada3fdy7288ca8dda8776e5@mail.gmail.com> <5ae4f2ba0805162201y1f05dbb4r4b4ee04c7783c249@mail.gmail.com> <5ae4f2ba0805162307w666a68eerfaf5aaf170ade4a6@mail.gmail.com> <8dde104f0805170301t7941aca7y3847a31267f55bd0@mail.gmail.com> <5ae4f2ba0805170400m102158d7obce55bb3108aef3c@mail.gmail.com> <8dde104f0805170902t198246f9s3ef234ae66ab86a7@mail.gmail.com> <5ae4f2ba0805171824y35412927r46c7b7614da42c29@mail.gmail.com> Message-ID: <8dde104f0805181349m11bd55bft39b40abac6893636@mail.gmail.com> On Sun, May 18, 2008 at 3:24 AM, Galchin, Vasili wrote: > Hi Josef, > > What generates dist/setup-config? When I run "runhaskell Setup.hs > configure", nothing including dist/setup.config gets generated. ?? > Ok, that sounds more alarming. Unfortunately I have no idea what could be the cause of this. Hopefully someone with a bit more cabal knowledge can help out. Good luck, Josef > On Sat, May 17, 2008 at 11:02 AM, Josef Svenningsson > wrote: >> >> On Sat, May 17, 2008 at 1:00 PM, Galchin, Vasili >> wrote: >> > Josef, >> > >> > E.g. >> > vigalchin@ubuntu:~/FTP/Haskell/unix-2.2.0.0$ runhaskell Setup.hs >> > configure >> > Configuring unix-2.3.0.0... >> > >> > Normally copious output ... ??? >> > >> That's what it should look like! It just means you have a recent >> version of cabal which doesn't spit out tons of information when >> configuring. Happily all is well. >> >> /Josef > > From lordgeoffrey at optushome.com.au Sun May 18 16:53:22 2008 From: lordgeoffrey at optushome.com.au (geoffrey) Date: Sun May 18 16:46:50 2008 Subject: [Haskell-cafe] cabal Setup.hs configure - cabal doesnt produce a setup-config Message-ID: <1211144002.5528.16.camel@geoffrey> Hi, I am trying to install nanocurses, but cabal isn't creating the setup-config file in dist/ I have run (and re-run) runghc Setup.hs configure The first time it complained about mpg123 (whatever that is) so i installed the other dependencies - unix & bytestring Then i tried to re-run setup configure for nano again. Configure creates the dist directory but no files. I have deleted and untarred the files and retried,but to no avail. Any clues? ?Thanks. (OS: Ubuntu hardy, GHC: 6.8.2) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080519/e703614a/attachment.htm From sebastian.sylvan at gmail.com Sun May 18 17:00:04 2008 From: sebastian.sylvan at gmail.com (Sebastian Sylvan) Date: Sun May 18 16:53:34 2008 Subject: [Haskell-cafe] Re: Reduceron (was Performance: MD5) In-Reply-To: <48308D0A.7060507@btinternet.com> References: <482EF0EF.2090207@btinternet.com> <33BBF65E-DA62-4988-BDFE-04705A615529@ece.cmu.edu> <48304AE7.6010101@telenet.be> <483053A4.7000803@btinternet.com> <20080518180942.7d87f101@solaris> <483056CB.8030506@btinternet.com> <20080518190746.62a8b384@solaris> <404396ef0805181011r6103558cp6f193bfc9c6cdb3e@mail.gmail.com> <20080518192953.6637e153@solaris> <48308D0A.7060507@btinternet.com> Message-ID: <3d96ac180805181400y49d1ba0h83639784cddb2076@mail.gmail.com> On Sun, May 18, 2008 at 9:09 PM, Andrew Coppin wrote: > Achim Schneider wrote: > >> "Neil Mitchell" wrote: >> >> >> >>> How would a Haskell compiler look like that targets a FPGA? That is, >>>> compiling down to configware, not to a RTS built on top of it. >>>> >>>> >>> http://www-users.cs.york.ac.uk/~mfn/reduceron2/ >>> >>> >>> >> I'm only on page 5 and already drooling. >> >> > > Damnit, this paper is making me hungry! :-( > > I almost want to run out into the street and purchase some FPGA hardware > right now! [I mean, I wanted to before, but this makes me want to even > more.] But hey, let's not get crazy here. (Yet.) > > Video presentation: http://video.google.com/videoplay?docid=-1518197558546337776 -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080518/05811066/attachment.htm From gale at sefer.org Sun May 18 17:02:13 2008 From: gale at sefer.org (Yitzchak Gale) Date: Sun May 18 16:55:44 2008 Subject: [Haskell-cafe] My experience setting up Haskell up for GUI development In-Reply-To: <892648598.20080519001309@gmail.com> References: <17676a590805181126g676144ebt491c20882b337cf1@mail.gmail.com> <892648598.20080519001309@gmail.com> Message-ID: <2608b8a80805181402v3a346faeqe14399a99d3006ce@mail.gmail.com> Hi Bulat, Bulat Ziganshin wrote: > if main part of your program is GUI - it's better to stick with C# and > all its visual bells and whistles. the only good thing with gtk2hs is > that you got Linux portability for free. actually, people will think > that you have developed it on linux and ported to windows at the last > day :D Isn't there now a Windows native look for gtk2? When will gtk2hs support it? In the meantime, I guess that is an advantage of wxHaskell. > look at http://freearc.org screenshots Bulat - very, very nice app! Why haven't I noticed that link here before? > if you develop serious (say, commercial) application - consider > developing algorithm in Haskell and writing GUI in C# or C++ to take > best of both worlds. But then you need to rewrite the GUI part from scratch to get it to run on other platforms. Regards, Yitz From gwern0 at gmail.com Sun May 18 17:11:50 2008 From: gwern0 at gmail.com (Gwern Branwen) Date: Sun May 18 17:05:50 2008 Subject: [Haskell-cafe] cabal Setup.hs configure - cabal doesnt produce a setup-config In-Reply-To: <1211144002.5528.16.camel@geoffrey> References: <1211144002.5528.16.camel@geoffrey> Message-ID: <20080518211150.GA19273@localhost> On 2008.05.19 06:53:22 +1000, geoffrey scribbled 1.8K characters: > Hi, > I am trying to install nanocurses, but cabal isn't creating the setup-config file in dist/ > > I have run (and re-run) runghc Setup.hs configure > The first time it complained about mpg123 (whatever that is) so i installed the other > dependencies - unix & bytestring The mpg123 warning is leftover from hmp3; mpg123 is a media player hmp3 needs to actually play the audio files. I hadn't noticed it. Obviously it has no relevance to a curses binding, so I've edited that out and uploaded a small version bump. > Then i tried to re-run setup configure for nano again. Configure creates the dist directory > but no files. > I have deleted and untarred the files and retried,but to no avail. > > Any clues? > Thanks. > > (OS: Ubuntu hardy, GHC: 6.8.2) Dunno. If Cabal usually works for you, but just no with nanocurses, my guess would be perhaps the mpg123 check is causing the configure script to bail out? -- gwern AVIP DCSS SAS PGP Scud counter rs9512c Meta-hackers Fax IW -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080518/63bf6854/attachment.bin From duncan.coutts at worc.ox.ac.uk Sun May 18 17:06:35 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun May 18 17:06:21 2008 Subject: [Haskell-cafe] Fun with Darcs In-Reply-To: <1578946504.20080519003533@gmail.com> References: <93BECC602E286B499D5443ECB850D2FF01331E95@newman.usa.aitgroupad.com> <482B3022.2050303@btinternet.com> <482B38FC.2000705@btinternet.com> <482B3F91.7050602@btinternet.com> <20080514201346.GP8845@darcs.net> <482B505C.3020300@btinternet.com> <259058831.20080515010114@gmail.com> <1210889153.5824.137.camel@localhost> <1578946504.20080519003533@gmail.com> Message-ID: <1211144795.5824.258.camel@localhost> On Mon, 2008-05-19 at 00:35 +0400, Bulat Ziganshin wrote: > Hello Duncan, > > Friday, May 16, 2008, 2:05:53 AM, you wrote: > > > Of course if you're deploying a Windows program that uses gtk2hs then > > using just the runtime dlls is just the right thing to do. Though for > > that case we provide the runtime dlls: > > > http://haskell.org/gtk2hs/win32/ > > > As an example, here's an installer for a standalone prog that uses > > gtk2hs but doesn't need ghc or gtk2hs to be installed already: > > > http://haskell.org/~duncan/gtk2hs/LSystemSetup.exe > > i've just tried that. for me there is still one problem - my program > includes a lot of other files beside exe and i will be glad to have > gtk2hs put to separate subtree. is it possible? say, > > c:/Program Files/WinArc/winarc.* > c:/Program Files/WinArc/gtk2hs/bin/*.dll > c:/Program Files/WinArc/gtk2hs/etc/* > c:/Program Files/WinArc/gtk2hs/lib/* > > and so on Not easily. Windows looks first for dlls in the same directory as your .exe program. So in the above layout you'd need your .exe to live in that bin directory. If we were able to use windows assembly manifests with ghc on Windows then it would be possible to put the dlls in a sub directory relative to your .exe program. At the moment I think we don't have any real support for assemblies with ghc, mostly because gcc itself doesn't help us there. Using assemblies is the right long term solution I think. Using an "isolated" assembly would also allow us to install Gtk2Hs without having to mess with the $PATH. Duncan From duncan.coutts at worc.ox.ac.uk Sun May 18 17:14:49 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun May 18 17:06:41 2008 Subject: [Haskell-cafe] My experience setting up Haskell up for GUI development In-Reply-To: <892648598.20080519001309@gmail.com> References: <17676a590805181126g676144ebt491c20882b337cf1@mail.gmail.com> <892648598.20080519001309@gmail.com> Message-ID: <1211145289.5824.265.camel@localhost> On Mon, 2008-05-19 at 00:13 +0400, Bulat Ziganshin wrote: > Hello Ben, > > Sunday, May 18, 2008, 10:26:09 PM, you wrote: > > > So, in practice, do other people write GUI apps with Haskell on > > Windows? And if they do, how do they do it? I feel I've got to the > > stage where I need a concrete recommendation from the experts. > > after i've wrote a few thousands lines with gtk2hs, i think the > following: > > if main part of your program is GUI - it's better to stick with C# and > all its visual bells and whistles. the only good thing with gtk2hs is > that you got Linux portability for free. actually, people will think > that you have developed it on linux and ported to windows at the last > day :D look at http://freearc.org screenshots or install program > itself to see that i mean Yeah, there are a couple visual improvements you could make. For one thing you could use your own icon rather than the default Gtk+ window icon. Do you use glade to design the UI layout or do you do it by hand in code? It's usually pretty easy to spot UIs that are built by hand or using layout combinators. A good guide here is the GNOME HIG (Human Interface Guidelines). http://developer.gnome.org/projects/gup/hig/ Duncan From duncan.coutts at worc.ox.ac.uk Sun May 18 17:18:10 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun May 18 17:09:39 2008 Subject: [Haskell-cafe] My experience setting up Haskell up for GUI development In-Reply-To: <2608b8a80805181402v3a346faeqe14399a99d3006ce@mail.gmail.com> References: <17676a590805181126g676144ebt491c20882b337cf1@mail.gmail.com> <892648598.20080519001309@gmail.com> <2608b8a80805181402v3a346faeqe14399a99d3006ce@mail.gmail.com> Message-ID: <1211145490.5824.268.camel@localhost> On Mon, 2008-05-19 at 00:02 +0300, Yitzchak Gale wrote: > Hi Bulat, > > Bulat Ziganshin wrote: > > if main part of your program is GUI - it's better to stick with C# and > > all its visual bells and whistles. the only good thing with gtk2hs is > > that you got Linux portability for free. actually, people will think > > that you have developed it on linux and ported to windows at the last > > day :D > > Isn't there now a Windows native look for gtk2? Yep. > When will gtk2hs support it? It has done for several years now. > In the meantime, I guess that is an advantage of wxHaskell. As far as I know the visual differences are pretty small. If you know of anything specific we can file bugs with the Gtk+ folk, they've fixed lots of little differences over the last few years. Duncan From duncan.coutts at worc.ox.ac.uk Sun May 18 17:21:59 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun May 18 17:13:35 2008 Subject: [Haskell-cafe] Re: ghc on Ubuntu Linux? In-Reply-To: <8dde104f0805181349m11bd55bft39b40abac6893636@mail.gmail.com> References: <5ae4f2ba0805162151l9ada3fdy7288ca8dda8776e5@mail.gmail.com> <5ae4f2ba0805162201y1f05dbb4r4b4ee04c7783c249@mail.gmail.com> <5ae4f2ba0805162307w666a68eerfaf5aaf170ade4a6@mail.gmail.com> <8dde104f0805170301t7941aca7y3847a31267f55bd0@mail.gmail.com> <5ae4f2ba0805170400m102158d7obce55bb3108aef3c@mail.gmail.com> <8dde104f0805170902t198246f9s3ef234ae66ab86a7@mail.gmail.com> <5ae4f2ba0805171824y35412927r46c7b7614da42c29@mail.gmail.com> <8dde104f0805181349m11bd55bft39b40abac6893636@mail.gmail.com> Message-ID: <1211145719.5824.272.camel@localhost> On Sun, 2008-05-18 at 22:49 +0200, Josef Svenningsson wrote: > On Sun, May 18, 2008 at 3:24 AM, Galchin, Vasili wrote: > > Hi Josef, > > > > What generates dist/setup-config? When I run "runhaskell Setup.hs > > configure", nothing including dist/setup.config gets generated. ?? > > > Ok, that sounds more alarming. Unfortunately I have no idea what could > be the cause of this. Hopefully someone with a bit more cabal > knowledge can help out. We've been through it off-list. It's failing when calling ghc for the first time but we cannot track down why. To help in future cases I've changed the logging of calling external programs slightly so that at the maximum verbosity level we now report the error code that the process returned if it was non-0. That'll help us confirm if it really was the external process failing or if it failed sometime after that but before the next log message. Duncan From bulat.ziganshin at gmail.com Sun May 18 17:28:02 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sun May 18 17:22:41 2008 Subject: [Haskell-cafe] My experience setting up Haskell up for GUI development In-Reply-To: <1211145490.5824.268.camel@localhost> References: <17676a590805181126g676144ebt491c20882b337cf1@mail.gmail.com> <892648598.20080519001309@gmail.com> <2608b8a80805181402v3a346faeqe14399a99d3006ce@mail.gmail.com> <1211145490.5824.268.camel@localhost> Message-ID: <595312930.20080519012802@gmail.com> Hello Duncan, Monday, May 19, 2008, 1:18:10 AM, you wrote: > As far as I know the visual differences are pretty small. If you know of > anything specific we can file bugs with the Gtk+ folk, they've fixed > lots of little differences over the last few years. file open dialogs; treeview -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From wnoise at ofb.net Sun May 18 18:36:31 2008 From: wnoise at ofb.net (Aaron Denney) Date: Sun May 18 18:30:12 2008 Subject: [Haskell-cafe] Re: Performance: MD5 References: <482EF0EF.2090207@btinternet.com> <296039281.20080517195217@gmail.com> <482FEB74.3090909@btinternet.com> <20080518091716.GA22995@scytale.galois.com> <48300301.2030906@btinternet.com> <20080518215242.0c16b017@solaris> Message-ID: On 2008-05-18, Achim Schneider wrote: > Aaron Denney wrote: > >> Go read K&R[1]. It shouldn't take more than a week's worth of spare >> time. >> > HELL NO! > > There's a reason why my lecturer always refered to it as "Knall & Rauch > C" (Bang and Smoke C). > > Get the Harbison & Steele instead: > http://careferencemanual.com/ C is a little language. It doesn't /need/ a 500 page tome. K&R is not something to learn programming, and of course, does quite poorly when used as a textbook for that purpose. It is, instead, for programmers to learn C. -- Aaron Denney -><- From wqeqweuqy at hotmail.com Sun May 18 18:37:01 2008 From: wqeqweuqy at hotmail.com (Neal Alexander) Date: Sun May 18 18:31:02 2008 Subject: [Haskell-cafe] Re: Parsec3 performance issues (in relation to v2) In-Reply-To: <694519c50805180923i55aa35e2p1c19ee63b64891d1@mail.gmail.com> References: <62634.86.145.154.157.1210712205.squirrel@www.gradwell.com> <694519c50805180923i55aa35e2p1c19ee63b64891d1@mail.gmail.com> Message-ID: Antoine Latter wrote: > On Tue, May 13, 2008 at 9:23 PM, Neal Alexander wrote: >> I stripped the code down to just the parsec related stuff and retested it. >> >> http://72.167.145.184:8000/parsec_test/Parsec2.prof >> http://72.167.145.184:8000/parsec_test/Parsec3.prof >> >> And the parser with a 9mb (800 kb gziped) sample log file: >> http://72.167.145.184:8000/parsec_test.tar.gz >> > > Neal, those two profiling results aren't really comparable, because > your Parsec2 profiling doesn't include any cost-centers from the > Parsec library - so all of the costs associated with Parsec2 will be > assigned to cost-centers in EQ2Parse. > > I've tried running this profiling on my own computer, and using the > same Cabal options for Parsec2 as Parsec3, I never seem to get CAFs > from Parsec2 to show up in the profiling result this this test. > > Can anyone help me out? > > I configure parsec (2 and 3) as follows: > $ runghc Setup.hs configure --prefix=${HOME}/usr > --enable-library-profiling --user --enable-optimization > > and then I build the "Main" as follows: > $ ghc --make -O2 -prof -auto Main -package parsec-2.1.0.0 > - or - > $ ghc --make -O2 -prof -auto Main > > And I run main as: > $ ./Main +RTS -p -RTS > > When I specify the parsec-2.1.0.0 on the command-line, the Main.prof > doesn't include any parsec CAFs. > > > Thanks, > Antoine Sorry about that. Hopefully this fixes it: http://72.167.145.184:8000/parsec_test/Parsec2_02.prof From wqeqweuqy at hotmail.com Sun May 18 19:47:08 2008 From: wqeqweuqy at hotmail.com (Neal Alexander) Date: Sun May 18 19:41:03 2008 Subject: [Haskell-cafe] Re: Parsec3 performance issues (in relation to v2) In-Reply-To: References: <62634.86.145.154.157.1210712205.squirrel@www.gradwell.com> <694519c50805180923i55aa35e2p1c19ee63b64891d1@mail.gmail.com> Message-ID: I also redid the profiling for Parsec3 using ByteStrings directly (Its slower than manually unpacking and feeding it a [Char]): http://72.167.145.184:8000/parsec_test/Parsec3_BStr.prof The code for EQ2Parse.hs is identical, aside from changing the type signature of "init" to use the ByteString ParsecT, and removing the line unpack. From jvlask at hotmail.com Sun May 18 22:02:32 2008 From: jvlask at hotmail.com (john lask) Date: Sun May 18 21:56:01 2008 Subject: [Haskell-cafe] Question on declaring an instance Message-ID: Consider the data type: Foo i o a = ... we want to declare an instance of Monad and Arrow for Foo without using a newtype (repackaging). The effect we want is to be able to construct an expression like: ( f>> g )>>> ( h>> i ) where f, g, h, i :: Foo i o a, for some i o a it is easy to declare instance Monad (Foo i o) where ... but how do we declare instance Arrow (Foo ... ), this instance takes a kind * -> * -> * it is easy to declare instance Arrow (Bar a) where ... where Bar a i o is a flipping of the order of the arguments to Foo i.e. Bar = ((flip . (flip .)) Foo Can Foo be declared an instance of both Arrow and Monad ? _________________________________________________________________ It's simple! Sell your car for just $30 at CarPoint.com.au http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fsecure%2Dau%2Eimrworldwide%2Ecom%2Fcgi%2Dbin%2Fa%2Fci%5F450304%2Fet%5F2%2Fcg%5F801459%2Fpi%5F1004813%2Fai%5F859641&_t=762955845&_r=tig_OCT07&_m=EXT From lrpalmer at gmail.com Sun May 18 22:11:14 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Sun May 18 22:04:42 2008 Subject: [Haskell-cafe] Question on declaring an instance In-Reply-To: References: Message-ID: <7ca3f0160805181911y59288b11y349de7c8b2b25144@mail.gmail.com> On Mon, May 19, 2008 at 2:02 AM, john lask wrote: > Consider the data type: > > Foo i o a = ... > > we want to declare an instance of Monad and Arrow for Foo without using a newtype (repackaging). > The effect we want is to be able to construct an expression like: > > ( f>> g )>>> ( h>> i ) > > where f, g, h, i :: Foo i o a, for some i o a [...] > Can Foo be declared an instance of both Arrow and Monad ? I think not. However, it's not unreasonable for data Foo i o To be both monad and arrow, since arrows are functors in their second argument. Luke From Braden.Shepherdson at gmail.com Sun May 18 23:09:08 2008 From: Braden.Shepherdson at gmail.com (Braden Shepherdson) Date: Sun May 18 23:02:33 2008 Subject: [Haskell-cafe] Re: My experience setting up Haskell up for GUI development In-Reply-To: <17676a590805181126g676144ebt491c20882b337cf1@mail.gmail.com> References: <17676a590805181126g676144ebt491c20882b337cf1@mail.gmail.com> Message-ID: Ben Arnold wrote: > I'm running Windows Vista and I've been trying to set up an environment > for writing GUI applications. > > > > So, in practice, do other people write GUI apps with Haskell on Windows? > And if they do, how do they do it? I feel I've got to the stage where I > need a concrete recommendation from the experts. > > My installation: > > - Windows Vista Home Premium 32-bit 6.0.6001 > I run Vista Business 32-bit on my desktop, and I installed Gtk2Hs using that LSystemSetup.exe installer. I don't have a link handy, I apologize. That's a handy way to install with a few clicks for non-programmers. Then I have my users launch my app using a .bat file that adds Gtk2Hs to the path (this assumes they installed to the standard location, sadly) so they don't have to go fiddling with their PATH. The good news is that my app (which uses networking, threading, STM and GTK) works with the same code (though obviously different binaries) on Linux and Windows, using GHC 6.8.2. I know that doesn't throw much light on your problem, but Gtk2Hs certainly does work on Vista, and XP as well, and with 6.8.2 even. Hope you find a solution, Braden Shepherdson shepheb From kolar at fit.vutbr.cz Mon May 19 00:25:42 2008 From: kolar at fit.vutbr.cz (Dusan Kolar) Date: Mon May 19 00:18:51 2008 Subject: [Haskell-cafe] ByteString.pack behavior In-Reply-To: <20080518202310.GB7494@scytale.galois.com> References: <48308E31.5080807@fit.vutbr.cz> <20080518202310.GB7494@scytale.galois.com> Message-ID: <48310146.3060700@fit.vutbr.cz> Thanks. I've realized that as soon as I was in my bed. ;-) Nevertheless, a question comes to me - shouldn't compiler report a warning? I know it cannot in the current state, but it should. :-) Quite dummy C compilers tell me I'm "loosing significant digits of number literals" if I'm doing that. Maybe, already seen in some other thread some time ago, the compiler should be less general/should know more about data types... Thanks and regards Dusan Don Stewart wrote: > kolar: > >> Hello all, >> >> Maybe there is something obvious I can't see, but I have this behavior >> for 6.8.2 ghci: >> >> $ghci ttest1p.hs >> GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help >> Loading package base ... linking ... done. >> [1 of 1] Compiling Main ( ttest1p.hs, interpreted ) >> Ok, modules loaded: Main. >> *Main> encode' [1..100] >> Loading package array-0.1.0.0 ... linking ... done. >> Loading package bytestring-0.9.0.1 ... linking ... done. >> [1,0,2,0,3,0,4,0,5,0,6,0,7,0,8,0,9,0,10,0,11,0,12,0,13,0,... // deleted >> *Main> B.pack [0..100] >> "\NUL\SOH\STX\ETX\EOT\ENQ\ACK\a\b\t\n\v\f\r\SO\SI\DLE\DC1\DC2\DC3\DC4\NAK\SYN\ETB\CAN\EM\SUB\ESC\FS\GS\RS\US >> !\"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcd" >> *Main> B.pack $ encode' [1..100] >> "*** Exception: divide by zero >> >> where ttest1p.hs: >> >> import qualified Data.ByteString as B >> >> encode' [] = [] >> encode' (x:xs) = >> if x==0 then 0:0:encode' xs >> else (x `mod` 256) : (x `div` 256) : encode' xs >> >> >> What is the difference, except list length and value structure? Where is >> my error? >> >> > > ByteStrings take Word8 values as input, so x `div` 256 , where 256 :: > Word8, overflows to 0. > > -- Don > -- Dusan Kolar tel: +420 54 114 1238 UIFS FIT VUT Brno fax: +420 54 114 1270 Bozetechova 2 e-mail: kolar@fit.vutbr.cz Brno 612 66 Czech Republic -- From golubovsky at gmail.com Mon May 19 00:33:53 2008 From: golubovsky at gmail.com (Dimitry Golubovsky) Date: Mon May 19 00:28:09 2008 Subject: [Haskell-cafe] Experimental compilation of Haskell to Erlang Message-ID: Hi, Some time ago I became interested in compilation of Haskell programs (via Yhc Core) to Erlang to be able to run Haskell code in Erlang environment. This experiment seems to have been successful, so I'd like to publish its results for everyone to read and criticize. Results of the experiment are described in this Haskell Wiki article: http://www.haskell.org/haskellwiki/Yhc/Erlang/Proof_of_concept Any feedback is appreciated. Thanks. -- Dimitry Golubovsky Anywhere on the Web From sjanssen at cse.unl.edu Mon May 19 03:22:58 2008 From: sjanssen at cse.unl.edu (Spencer Janssen) Date: Mon May 19 03:16:14 2008 Subject: [Haskell-cafe] Two-iteration optimisation (was: GHC Predictability) In-Reply-To: <482B1C8C.4060509@cogito.org.uk> References: <482B1C8C.4060509@cogito.org.uk> Message-ID: <20080519072258.GA2988@celeborn> On Wed, May 14, 2008 at 06:08:28PM +0100, Paul Johnson wrote: > We've had a big debate over > > > mean xs = foldl' (+) 0 xs / fromIntegral (length xs) > > For anyone who didn't follow it, the problem is that "mean" needs to > traverse its argument twice, so the entire list has to be held in > memory. So if "xs = [1..1000000000]" then "mean xs" uses all your > memory, but "foldl' (+) 0 xs" and "length xs" by themselves do not. > > The solution is for the programmer to rewrite "mean" to accumulate a > pair containing the running total and count together, then do the > division. This makes me wonder: could there be a compiler optimisation > rule for this, collapsing two iterations over a list into one. I've > never tried writing GHC rules, but something like: > > > f (foldl' g x) (foldl' h x) = (uncurry f) (foldl' (\i (gt,ht) -> (g i > gt, h i ht))) > > The first problem that occurs to me is the number of permutations of > fold and map functions. > > Paul. There are two problems with this rule. The first is that the function is not strict in 'gt' and 'ht' -- this is easily fixed with a little bit of seq. The other problem is that 'f' must be strict in both parameters for this rule to hold. As far as I know, there is no access to strictness information in rule pragmas. Cheers, Spencer Janssen From voigt at tcs.inf.tu-dresden.de Mon May 19 03:31:18 2008 From: voigt at tcs.inf.tu-dresden.de (Janis Voigtlaender) Date: Mon May 19 03:22:02 2008 Subject: [Haskell-cafe] Re: Control.Exception.evaluate - 'correct definition' not so correct In-Reply-To: <200805182257.43931.valgarv@gmx.net> References: <20080503091917.GA5333@shion.is.fushizen.net> <5ab17e790805041730o33b378e4u74f4f1f9e813e72b@mail.gmail.com> <200805182257.43931.valgarv@gmx.net> Message-ID: <48312CC6.3040706@tcs.inf.tu-dresden.de> Ariel J. Birnbaum wrote: > (considering "undefined" as equivalent to "const undefined", which iirc was > the definition of _|_ for function types). > > What am I missing? undefined /= const undefined in Haskell, due to seq. -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:voigt@tcs.inf.tu-dresden.de From lordgeoffrey at optushome.com.au Mon May 19 04:14:40 2008 From: lordgeoffrey at optushome.com.au (geoffrey) Date: Mon May 19 04:08:14 2008 Subject: [Haskell-cafe] cabal Setup.hs configure - cabal doesnt produce a setup-config In-Reply-To: <20080518211150.GA19273@localhost> References: <1211144002.5528.16.camel@geoffrey> <20080518211150.GA19273@localhost> Message-ID: <1211184880.5706.6.camel@geoffrey> I did a complete uninstall and reinstall of GHC and that seems to have fixed it. So i probably broke things (i guess). On Sun, 2008-05-18 at 17:11 -0400, Gwern Branwen wrote: > On 2008.05.19 06:53:22 +1000, geoffrey scribbled 1.8K characters: > > Hi, > > I am trying to install nanocurses, but cabal isn't creating the setup-config file in dist/ > > > > I have run (and re-run) runghc Setup.hs configure > > The first time it complained about mpg123 (whatever that is) so i installed the other > > dependencies - unix & bytestring > > The mpg123 warning is leftover from hmp3; mpg123 is a media player hmp3 needs to actually play the audio files. I hadn't noticed it. Obviously it has no relevance to a curses binding, so I've edited that out and uploaded a small version bump. > > > Then i tried to re-run setup configure for nano again. Configure creates the dist directory > > but no files. > > I have deleted and untarred the files and retried,but to no avail. > > > > Any clues? > > Thanks. > > > > (OS: Ubuntu hardy, GHC: 6.8.2) > > Dunno. If Cabal usually works for you, but just no with nanocurses, my guess would be perhaps the mpg123 check is causing the configure script to bail out? > > -- > gwern > AVIP DCSS SAS PGP Scud counter rs9512c Meta-hackers Fax IW -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080519/e763c42a/attachment.htm From duncan.coutts at worc.ox.ac.uk Mon May 19 04:45:11 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon May 19 04:36:30 2008 Subject: [Haskell-cafe] Re: My experience setting up Haskell up for GUI development In-Reply-To: References: <17676a590805181126g676144ebt491c20882b337cf1@mail.gmail.com> Message-ID: <1211186711.5824.283.camel@localhost> On Sun, 2008-05-18 at 23:09 -0400, Braden Shepherdson wrote: > I run Vista Business 32-bit on my desktop, and I installed Gtk2Hs using > that LSystemSetup.exe installer. I don't have a link handy, I apologize. > That's a handy way to install with a few clicks for non-programmers. I had no idea people were using that just to install the Gtk+ dlls. > Then I have my users launch my app using a .bat file that adds Gtk2Hs to > the path (this assumes they installed to the standard location, sadly) > so they don't have to go fiddling with their PATH. You can make it much easier for your users. The LSystemSetup.exe installer just unpacks http://haskell.org/gtk2hs/win32/gtk+-2.10.14-win32.zip along with a demo .exe in the bin dir. Because the .exe is in the same dir as the Gtk+ dlls there is no need to use a bat file or change the path. I used innosetup (which is Free Sofware, BSD style license). http://www.jrsoftware.org/isinfo.php It could hardly be easier. I half wrote a blog post on this some time ago. Clearly I should finish it off. Duncan From quarantedeux42 at yahoo.fr Mon May 19 06:07:00 2008 From: quarantedeux42 at yahoo.fr (Fernand) Date: Mon May 19 06:00:41 2008 Subject: [Haskell-cafe] [tagsoup] is it the expected behaviour ? Message-ID: <48315144.8000207@yahoo.fr> Hi, Experimenting with tagsoup (I'm using GHC 6.8.2 and tagsoup-0.6), I found something which appears to me as strange behaviour : when parsing tag's attributes that have spaces enclosing the "=" sign, tagsoup seems to interpret these as empty attributes' names and values. For instance (notice the spaces enclosing the equal sign) : $ ghcii.sh -package tagsoup [...] Loading package tagsoup-0.6 ... linking ... done. Prelude> :m +Text.HTML.TagSoup Prelude Text.HTML.TagSoup> parseTags "uh ?" [TagOpen "a" [("href",""),("","what")],TagText "uh ?",TagClose "a"] Here, am I wrong when expecting [TagOpen "a" [("href","what")],TagText "uh ?",TagClose "a"], or is there some HTML interpretation I don't know on the parsing of attributes ? Sincerely yours, Fernand From ndmitchell at gmail.com Mon May 19 06:17:56 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon May 19 06:11:23 2008 Subject: [Haskell-cafe] [tagsoup] is it the expected behaviour ? In-Reply-To: <48315144.8000207@yahoo.fr> References: <48315144.8000207@yahoo.fr> Message-ID: <404396ef0805190317g4bb46aa9le95469ac105afdd6@mail.gmail.com> Hi Fernand, > Experimenting with tagsoup (I'm using GHC 6.8.2 and tagsoup-0.6), I found > something which appears to me as strange behaviour : when parsing tag's > attributes that have spaces enclosing the "=" sign, tagsoup seems to > interpret these as empty attributes' names and values. Yep, that's the wrong behaviour. I'm just writing a patch now, and will email back once its in the development version. Many thanks for reporting the bug - it will go in the regression test and will never be broken again :-) Thanks Neil From ndmitchell at gmail.com Mon May 19 06:41:51 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon May 19 06:35:18 2008 Subject: [Haskell-cafe] [tagsoup] is it the expected behaviour ? In-Reply-To: <404396ef0805190317g4bb46aa9le95469ac105afdd6@mail.gmail.com> References: <48315144.8000207@yahoo.fr> <404396ef0805190317g4bb46aa9le95469ac105afdd6@mail.gmail.com> Message-ID: <404396ef0805190341j2269b95et8b6fea279ad1c05a@mail.gmail.com> Hi Fernand, Using the darcs version: *Text.HTML.TagSoup> parseTags "uh ?" [TagOpen "a" [("href","what")],TagText "uh ?",TagClose "a"] Which you can get from: http://www.cs.york.ac.uk/fp/darcs/tagsoup This will be bundled up in the next release. If the problem is more urgent for you, let me know and I'll release a new version. I appreciate any bugs, or just weird things tagsoup does on malformed HTML, so I can build up a more comprehensive regression suite. Thanks Neil On Mon, May 19, 2008 at 11:17 AM, Neil Mitchell wrote: > Hi Fernand, > >> Experimenting with tagsoup (I'm using GHC 6.8.2 and tagsoup-0.6), I found >> something which appears to me as strange behaviour : when parsing tag's >> attributes that have spaces enclosing the "=" sign, tagsoup seems to >> interpret these as empty attributes' names and values. > > Yep, that's the wrong behaviour. I'm just writing a patch now, and > will email back once its in the development version. > > Many thanks for reporting the bug - it will go in the regression test > and will never be broken again :-) > > Thanks > > Neil > From ketil at malde.org Mon May 19 06:44:32 2008 From: ketil at malde.org (Ketil Malde) Date: Mon May 19 06:37:45 2008 Subject: [Haskell-cafe] [tagsoup] is it the expected behaviour ? In-Reply-To: <48315144.8000207@yahoo.fr> (Fernand's message of "Mon\, 19 May 2008 12\:07\:00 +0200") References: <48315144.8000207@yahoo.fr> Message-ID: <87hccuine7.fsf@nmd9999.imr.no> Fernand writes: > Experimenting with tagsoup (I'm using GHC 6.8.2 and tagsoup-0.6), I > found something which appears to me as strange behaviour : when > parsing tag's attributes that have spaces enclosing the "=" sign, > tagsoup seems to interpret these as empty attributes' names and > values. For instance (notice the spaces enclosing the equal sign) : I don't think that is legal XML. The definitions of STag and Attribute from http://www.w3.org/TR/xml11/#NT-STag are: [40] STag ::= '<' Name (S Attribute)* S? '>' [41] Attribute ::= Name Eq AttValue And 'S' represents one or more whitespace characters, so it seems clear that they are not allowed between Name, Eq, and AttValue. Whether this is the right behavior for TagSoup, which is styled as a fast-and-loose XML/HTML processor, is another matter. -k -- If I haven't seen further, it is by standing in the footprints of giants From ndmitchell at gmail.com Mon May 19 06:51:30 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon May 19 06:44:58 2008 Subject: [Haskell-cafe] [tagsoup] is it the expected behaviour ? In-Reply-To: <87hccuine7.fsf@nmd9999.imr.no> References: <48315144.8000207@yahoo.fr> <87hccuine7.fsf@nmd9999.imr.no> Message-ID: <404396ef0805190351o22677d3q1fb08d80bffd9f53@mail.gmail.com> Hi Ketil, > I don't think that is legal XML. The definitions of STag and Attribute > from http://www.w3.org/TR/xml11/#NT-STag are: > > [40] STag ::= '<' Name (S Attribute)* S? '>' > [41] Attribute ::= Name Eq AttValue > > And 'S' represents one or more whitespace characters, so it seems > clear that they are not allowed between Name, Eq, and AttValue. > > Whether this is the right behavior for TagSoup, which is styled as a > fast-and-loose XML/HTML processor, is another matter. It seems that both Firefox and IE accept the attribute values with spaces around the equals, so I think that's a sensible choice for tagsoup. I must confess I haven't actually read the XML definition in the last 5 years, but probably should! Thanks Neil From jeremy.odonoghue at gmail.com Mon May 19 09:15:56 2008 From: jeremy.odonoghue at gmail.com (Jeremy O'Donoghue) Date: Mon May 19 09:09:39 2008 Subject: [Haskell-cafe] My experience setting up Haskell up for GUI development In-Reply-To: <17676a590805181126g676144ebt491c20882b337cf1@mail.gmail.com> References: <17676a590805181126g676144ebt491c20882b337cf1@mail.gmail.com> Message-ID: <48317D8C.9070306@gmail.com> Ben Arnold wrote: > WxHaskell was a little trickier but more successful. There didn't > appear to be any installation instructions on the website, but it did > imply that I needed to install wxWidgets first. I did that, and made > sure the paths didn't have spaces in them (yawn). And after restarting > the PC eventually I got a working Hello World dialogue box. > > Which is nice, except that when I call "main" twice in succession from > GHCi, ghc.exe crashes. So I have no confidence in the wxHaskell > libraries either. I don't want to invest time in programming with > libraries that perform illegal operations on my operating system. This is a known wxHaskell problem, and is a consequence of changes in the underlying design of wxWidgets since wxHaskell was designed. The basic problem is that wxWidgets, since around wxWidgets 2.5, uses C++ static constructors and destructors to initialize and destroy some internal data structures. Unfortunately, on Windows, the only way to make these run is to unload the wxWidgets DLL when main terminates, and this is something we do not currently do (I'm working on it, but it is not trivial, and I have little time to work on the problem, so progress is slower than I would like). If this functionality is essential to you, I can only suggest using wxHaskell 0.9.4 with wxWidgets 2.4.2. This older version of wxWidgets does not use static constructors/destructors, and can be used to execute main more than once. This older revision is three years old now, and will require you to use GHC 6.4. In terms of an 'expert' reference - wxHaskell or GtkHs are the only reasonably maintained GUI options for Haskell. GtkHs has a larger team of contributors, but both are capable of producing complex and stable GUI applications - I can certainly vouch for wxHaskell in this respect (and in respect of speed of development), and the reason I work on it is precisely because I didn't want to see such a superb piece of software rot through lack of attention. However, both projects rely on fairly small volunteer teams working on their spare time out of love (or something like it...), and I think it's fair to say that both teams are some way from matching the ease of developing and deploying of, say, C# or Java. Regards Jeremy O'Donoghue From barsoap at web.de Mon May 19 09:19:22 2008 From: barsoap at web.de (Achim Schneider) Date: Mon May 19 09:13:03 2008 Subject: [Haskell-cafe] Re: ByteString.pack behavior References: <48308E31.5080807@fit.vutbr.cz> <20080518202310.GB7494@scytale.galois.com> <48310146.3060700@fit.vutbr.cz> Message-ID: <20080519151922.0fb4ddfb@solaris> Dusan Kolar wrote: > Thanks. I've realized that as soon as I was in my bed. ;-) > > Nevertheless, a question comes to me - shouldn't compiler report a > warning? I know it cannot in the current state, but it should. :-) > Quite dummy C compilers tell me I'm "loosing significant digits of > number literals" if I'm doing that. Maybe, already seen in some other > thread some time ago, the compiler should be less general/should know > more about data types... > While doing that is easy in this case, it becomes quite delicate in the general case. More precisely, it grows into the halting problem. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. From ketil at malde.org Mon May 19 09:32:03 2008 From: ketil at malde.org (Ketil Malde) Date: Mon May 19 09:25:14 2008 Subject: [Haskell-cafe] Re: ByteString.pack behavior In-Reply-To: <20080519151922.0fb4ddfb@solaris> (Achim Schneider's message of "Mon\, 19 May 2008 15\:19\:22 +0200") References: <48308E31.5080807@fit.vutbr.cz> <20080518202310.GB7494@scytale.galois.com> <48310146.3060700@fit.vutbr.cz> <20080519151922.0fb4ddfb@solaris> Message-ID: <87mymmh12k.fsf@nmd9999.imr.no> Achim Schneider writes: >> Nevertheless, a question comes to me - shouldn't compiler report a >> warning? > While doing that is easy in this case, it becomes quite delicate in the > general case. More precisely, it grows into the halting problem. I think it would be nice with a warning when a literal will overflow. I'd also like run time warnings for overflows, the fact that all the finite integral types wrap around is often an annoyance. I believe that for Int (where the exact precision is unspecified) programs that wrap will be non-portable. I wonder if it would be possible to write a debugging Data.Word library, where you could have something like: instance Num Word8 where (+) w1 w2 = let (i :: Integer) = fromIntegral w1 + fromIntegral w2 (w :: Word8) = w1 Word8.plus w2 in if (fromIntegral w /= i) then error ... else w : Then at least it could be used for testing (including QuickCheck) and lower the probability of overflow and wrap-around. I suspect that the Num instances are too tightly coupled with the data definitions to make such a module possible, though. -k -- If I haven't seen further, it is by standing in the footprints of giants From benedict.arnold at gmail.com Mon May 19 10:12:46 2008 From: benedict.arnold at gmail.com (Ben Arnold) Date: Mon May 19 10:06:13 2008 Subject: [Haskell-cafe] My experience setting up Haskell up for GUI development In-Reply-To: <48317D8C.9070306@gmail.com> References: <17676a590805181126g676144ebt491c20882b337cf1@mail.gmail.com> <48317D8C.9070306@gmail.com> Message-ID: <17676a590805190712w1b2c5c20m274b1e35aeb1a581@mail.gmail.com> Thanks. It's actually quite comforting to know that the problems I run into are known issues and gives me a lot more confidence in the tools. As I said I really like Haskell it's a pleasure to program in it and I do appreciate the work that people have put in to make it possible for me to do so! On Mon, May 19, 2008 at 2:15 PM, Jeremy O'Donoghue < jeremy.odonoghue@gmail.com> wrote: > Ben Arnold wrote: > >> WxHaskell was a little trickier but more successful. There didn't appear >> to be any installation instructions on the website, but it did imply that I >> needed to install wxWidgets first. I did that, and made sure the paths >> didn't have spaces in them (yawn). And after restarting the PC eventually I >> got a working Hello World dialogue box. >> >> Which is nice, except that when I call "main" twice in succession from >> GHCi, ghc.exe crashes. So I have no confidence in the wxHaskell libraries >> either. I don't want to invest time in programming with libraries that >> perform illegal operations on my operating system. >> > This is a known wxHaskell problem, and is a consequence of changes in the > underlying design of wxWidgets since wxHaskell was designed. > > The basic problem is that wxWidgets, since around wxWidgets 2.5, uses C++ > static constructors and destructors to initialize and destroy some internal > data structures. Unfortunately, on Windows, the only way to make these run > is to unload the wxWidgets DLL when main terminates, and this is something > we do not currently do (I'm working on it, but it is not trivial, and I have > little time to work on the problem, so progress is slower than I would > like). > > If this functionality is essential to you, I can only suggest using > wxHaskell 0.9.4 with wxWidgets 2.4.2. This older version of wxWidgets does > not use static constructors/destructors, and can be used to execute main > more than once. This older revision is three years old now, and will require > you to use GHC 6.4. > > In terms of an 'expert' reference - wxHaskell or GtkHs are the only > reasonably maintained GUI options for Haskell. GtkHs has a larger team of > contributors, but both are capable of producing complex and stable GUI > applications - I can certainly vouch for wxHaskell in this respect (and in > respect of speed of development), and the reason I work on it is precisely > because I didn't want to see such a superb piece of software rot through > lack of attention. > > However, both projects rely on fairly small volunteer teams working on > their spare time out of love (or something like it...), and I think it's > fair to say that both teams are some way from matching the ease of > developing and deploying of, say, C# or Java. > > Regards > Jeremy O'Donoghue > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080519/68a756f2/attachment.htm From gwern0 at gmail.com Sun May 18 12:36:21 2008 From: gwern0 at gmail.com (Gwern Branwen) Date: Mon May 19 14:10:46 2008 Subject: [Haskell-cafe] hmp3 compilation problem In-Reply-To: <8341e4f40805081622k5e947b36jf8d40464fa93b155@mail.gmail.com> References: <8341e4f40805081622k5e947b36jf8d40464fa93b155@mail.gmail.com> Message-ID: <20080518163621.GB6726@localhost> On 2008.05.09 08:52:37 +0930, Levi Stephen scribbled 1.3K characters: > Hi, > > I am trying to compile hmp3. I have the version from darcs at > http://code.haskell.org/~dons/code/hmp3 > > I am getting the following errors: > > Tree.hs:190:14: > No instance for (Binary FilePathP) > arising from a use of `get' at Tree.hs:190:14-16 > Possible fix: add an instance declaration for (Binary FilePathP) > In a 'do' expression: nm <- get > In the expression: > do nm <- get > i <- get > return (File nm i) > In the definition of `get': > get = do nm <- get > i <- get > return (File nm i) > > Tree.hs:236:31: > Couldn't match expected type `L.ByteString' > against inferred type > `bytestring-0.9.0.1:Data.ByteString.Lazy.Internal.ByteString' > In the second argument of `L.writeFile', namely > `(compress (encode s))' > In the expression: L.writeFile f (compress (encode s)) > In the definition of `writeTree': > writeTree f s = L.writeFile f (compress (encode s)) > > Tree.hs:240:46: > Couldn't match expected type > `bytestring-0.9.0.1:Data.ByteString.Lazy.Internal.ByteString' > against inferred type `L.ByteString' > In the first argument of `decompress', namely `s' > In the first argument of `decode', namely `(decompress s)' > In the first argument of `return', namely `(decode (decompress s))' > > Any help is much appreciated. > > Thanks, > Levi I don't know about the binary problem (perhaps hmp3 needs a more recent Data.Binary than it declares?), but the latter two errors are common and unpleasant. They come from various libraries being linked against different versions of ByteString. Development versions of Cabal can warn you about this in the configure step: ... Warning: This package indirectly depends on multiple versions of the same package. This is highly likely to cause a compile failure. package hmp3-1.5.1 requires bytestring-0.9.0.1 package zlib-0.4.0.4 requires bytestring-0.9.1.0 package pcre-light-0.3.1 requires bytestring-0.9.1.0 package nanocurses-1.5.1 requires bytestring-0.9.1.0 package binary-0.4.2 requires bytestring-0.9.1.0 .... The solution, currently, is to reinstall all conflicting packages, being very careful that they all link in the same version of bytestring. -- gwern Clandestine SBS electronic NADDIS Intelligence WHCA Chavez real E.T. boobytraps -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080518/b638fd36/attachment.bin From andrewcoppin at btinternet.com Mon May 19 13:32:28 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Mon May 19 14:11:08 2008 Subject: [Haskell-cafe] Experimental compilation of Haskell to Erlang In-Reply-To: References: Message-ID: <4831B9AC.20901@btinternet.com> Dimitry Golubovsky wrote: > Hi, > > Some time ago I became interested in compilation of Haskell programs > (via Yhc Core) to Erlang to be able to run Haskell code in Erlang > environment. > Two (somewhat tangental) thoughts come to mind. 1. Should it not, in theory at least, be *relatively* easy to target Haskell at anything that has a graph reduction machine? (You target Erlang, somebody else has targetted JavaScript, I myself attempted to target Java...) 2. How come all these projects use Yhc? According to the wiki, Yhc doesn't even _work_ yet. What gives? From dons at galois.com Mon May 19 14:22:06 2008 From: dons at galois.com (Don Stewart) Date: Mon May 19 14:15:39 2008 Subject: [Haskell-cafe] ByteString.pack behavior In-Reply-To: <48310146.3060700@fit.vutbr.cz> References: <48308E31.5080807@fit.vutbr.cz> <20080518202310.GB7494@scytale.galois.com> <48310146.3060700@fit.vutbr.cz> Message-ID: <20080519182206.GB29658@scytale.galois.com> Safe Num wrappers for primitive types that throw exceptions on overflow would make a useful library. Any takers? -- Don kolar: > Thanks. I've realized that as soon as I was in my bed. ;-) > > Nevertheless, a question comes to me - shouldn't compiler report a > warning? I know it cannot in the current state, but it should. :-) Quite > dummy C compilers tell me I'm "loosing significant digits of number > literals" if I'm doing that. Maybe, already seen in some other thread > some time ago, the compiler should be less general/should know more > about data types... > > Thanks and regards > > Dusan > > Don Stewart wrote: > >kolar: > > > >>Hello all, > >> > >> Maybe there is something obvious I can't see, but I have this behavior > >>for 6.8.2 ghci: > >> > >>$ghci ttest1p.hs > >>GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help > >>Loading package base ... linking ... done. > >>[1 of 1] Compiling Main ( ttest1p.hs, interpreted ) > >>Ok, modules loaded: Main. > >>*Main> encode' [1..100] > >>Loading package array-0.1.0.0 ... linking ... done. > >>Loading package bytestring-0.9.0.1 ... linking ... done. > >>[1,0,2,0,3,0,4,0,5,0,6,0,7,0,8,0,9,0,10,0,11,0,12,0,13,0,... // deleted > >>*Main> B.pack [0..100] > >>"\NUL\SOH\STX\ETX\EOT\ENQ\ACK\a\b\t\n\v\f\r\SO\SI\DLE\DC1\DC2\DC3\DC4\NAK\SYN\ETB\CAN\EM\SUB\ESC\FS\GS\RS\US > >>!\"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcd" > >>*Main> B.pack $ encode' [1..100] > >>"*** Exception: divide by zero > >> > >>where ttest1p.hs: > >> > >>import qualified Data.ByteString as B > >> > >>encode' [] = [] > >>encode' (x:xs) = > >> if x==0 then 0:0:encode' xs > >> else (x `mod` 256) : (x `div` 256) : encode' xs > >> > >> > >>What is the difference, except list length and value structure? Where is > >>my error? > >> > >> > > > >ByteStrings take Word8 values as input, so x `div` 256 , where 256 :: > >Word8, overflows to 0. > > > >-- Don > > > > -- > > Dusan Kolar tel: +420 54 114 1238 > UIFS FIT VUT Brno fax: +420 54 114 1270 > Bozetechova 2 e-mail: kolar@fit.vutbr.cz > Brno 612 66 > Czech Republic > > -- > From ndmitchell at gmail.com Mon May 19 14:52:08 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon May 19 14:45:35 2008 Subject: [Haskell-cafe] Experimental compilation of Haskell to Erlang In-Reply-To: <4831B9AC.20901@btinternet.com> References: <4831B9AC.20901@btinternet.com> Message-ID: <404396ef0805191152t54a30bcvac5e89cd675d587@mail.gmail.com> Hi >> Some time ago I became interested in compilation of Haskell programs >> (via Yhc Core) to Erlang to be able to run Haskell code in Erlang >> environment. >> > > Two (somewhat tangental) thoughts come to mind. > > 1. Should it not, in theory at least, be *relatively* easy to target Haskell > at anything that has a graph reduction machine? (You target Erlang, somebody > else has targetted JavaScript, I myself attempted to target Java...) It's a fair bit of engineering work, there are some design decisions to be made - such as how to interface with the host language (if at all). Theoretically its not that hard to come up with something, but it is a fair amount of effort. > 2. How come all these projects use Yhc? According to the wiki, Yhc doesn't > even _work_ yet. What gives? These projects use Yhc.Core - a Core language to which Haskell can be translated. At the moment, Yhc is the only compiler that can generate Yhc.Core, but Yhc.Core is a complete abstraction layer. There is currently work going on to translate GHC.Core to Yhc.Core, which would mean that you can then translate any GHC program (including rank-2-implicit-polymorphic-linear-super-ADTs etc.) to Yhc.Core, and then on to Erlang. The actual translation is trivial, but getting GHC.Core out of GHC for all the base libraries is hard. The reason I use Yhc.Core is because its a nice standalone library, with useful tools and functionality, which is highly stable. There is no library which is comparable. Thanks Neil From andrewcoppin at btinternet.com Mon May 19 16:00:53 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Mon May 19 16:18:00 2008 Subject: [Haskell-cafe] Experimental compilation of Haskell to Erlang In-Reply-To: <404396ef0805191152t54a30bcvac5e89cd675d587@mail.gmail.com> References: <4831B9AC.20901@btinternet.com> <404396ef0805191152t54a30bcvac5e89cd675d587@mail.gmail.com> Message-ID: <4831DC75.4040809@btinternet.com> Neil Mitchell wrote: > Hi > > >> Two (somewhat tangental) thoughts come to mind. >> >> 1. Should it not, in theory at least, be *relatively* easy to target Haskell >> at anything that has a graph reduction machine? (You target Erlang, somebody >> else has targetted JavaScript, I myself attempted to target Java...) >> > > It's a fair bit of engineering work, there are some design decisions > to be made - such as how to interface with the host language (if at > all). Theoretically its not that hard to come up with something, but > it is a fair amount of effort. > To be sure, I doubt it's what you'd call "trivial". I just ment it looks easier than, say, translating C to Pascal or something. >> 2. How come all these projects use Yhc? According to the wiki, Yhc doesn't >> even _work_ yet. What gives? >> > > These projects use Yhc.Core - a Core language to which Haskell can be > translated. At the moment, Yhc is the only compiler that can generate > Yhc.Core, but Yhc.Core is a complete abstraction layer. There is > currently work going on to translate GHC.Core to Yhc.Core, which would > mean that you can then translate any GHC program (including > rank-2-implicit-polymorphic-linear-super-ADTs etc.) to Yhc.Core, and > then on to Erlang. The actual translation is trivial, but getting > GHC.Core out of GHC for all the base libraries is hard. > > The reason I use Yhc.Core is because its a nice standalone library, > with useful tools and functionality, which is highly stable. There is > no library which is comparable. > I see... [I think.] From pgavin at gmail.com Mon May 19 16:47:13 2008 From: pgavin at gmail.com (Peter Gavin) Date: Mon May 19 16:40:47 2008 Subject: [Haskell-cafe] My experience setting up Haskell up for GUI development In-Reply-To: <17676a590805181126g676144ebt491c20882b337cf1@mail.gmail.com> References: <17676a590805181126g676144ebt491c20882b337cf1@mail.gmail.com> Message-ID: <4831E751.2040101@gmail.com> Ben Arnold wrote: [snip] > My installation: > > - Windows Vista Home Premium 32-bit 6.0.6001 > > First attempt > > - GHC 6.6.1 > - gtk2hs-09.12.exe > > Second attempt > > - GHC 6.8.2 > - wxMSW 2.6.3 > - wxHaskell 0.10.3 > Hi Ben, Sorry for the late reply, I don't check the cafe list often :) Since it looks like I'll be doing the next gtk2hs release, let me assure you that the installer for the next release will be tested on Vista. (I haven't tested it yet, but I didn't realize until now we had Vista users.) Look for it in the next couple weeks. Also, the current development tree builds quite easily with MinGW and MSYS (see http://www.mingw.org/) and any of the GHC binary installers as far back as 6.4.2. If you get the Gtk+ bundle (http://ftp.gnome.org/pub/gnome/binaries/win32/gtk+/2.12/gtk+-bundle-2.12.9.zip) then you'll be all set. (Note that I've done all this under XP, YMMV.) I haven't really tried it, but I understand that if you install Glade you pretty much have a RAD environment, a-la Visual Basic or Delphi. You can't really ask for much more than that! Oh, a request to those of you that frequent the cafe list frequently: Could you direct problem reports like this one to the gtk2hs-devel@sf.net list, since while I am subscribed to cafe, I don't read it on a daily basis? Thanks :) Pete From dokondr at gmail.com Mon May 19 17:04:39 2008 From: dokondr at gmail.com (Dmitri O.Kondratiev) Date: Mon May 19 16:58:07 2008 Subject: [Haskell-cafe] Newbie: State monad example questions Message-ID: <53396d9e0805191404va8cb2d7yeb36954b83ac5ca8@mail.gmail.com> I am trying to understand State monad example15 at: http://www.haskell.org/all_about_monads/html/statemonad.html Example 15 uses getAny that I don't understand at all how it works: getAny :: (Random a) => State StdGen a getAny = do g <- get (x,g') <- return $ random g put g' return x Questions: 1) random has type: random :: (Random a, RandomGen g) => g -> (a, g) and for State monad: return a = State (\s -> (a, s)) then: return (random g) = State (\s -> ((a,g), s)) Is it correct? 2) What x and g' will match to in: do ... (x,g') <- return $ random g which, as I understand equals to: do ... (x,g') <- State (\s -> ((a,g), s)) What x and g' will match to in the last expression? 3) In general, in do expression (pseudo): do { x <- State (\s -> (a, s)); ...} What x will refer to? Will x stand for a whole lambda function: \s -> (a, s) ? 4) How 'g <- get' works in this function (getAny) ? 5) Why we need 'put g'? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080520/29d101ab/attachment-0001.htm From kirby81 at gmail.com Mon May 19 18:22:41 2008 From: kirby81 at gmail.com (Salvatore Insalaco) Date: Mon May 19 18:16:08 2008 Subject: [Haskell-cafe] Performance: MD5 In-Reply-To: <48301C22.7020902@btinternet.com> References: <482EF0EF.2090207@btinternet.com> <4830161F.4050403@btinternet.com> <659443196.20080518155652@gmail.com> <48301C22.7020902@btinternet.com> Message-ID: <5a376f550805191522u61c577e7y5da24dc2b625c8c9@mail.gmail.com> 2008/5/18 Andrew Coppin : >> unsafeRead/Write >> > > Found in Data.Array.Base, apparently. (I managed to find an example in the > Gtk2hs "fastdraw" demo.) > > Oddly, this seems to make virtually no performance difference. I find this > highly surprising. But then, I perform 16 write to the array, and 64 reads > from the ByteString, so maybe that's where I should be worrying about bounds > checks... Hi Andrew, just a profiling suggestion: did you try to use the SCC cost-centre annotations for profiling? If you want to know precisely what takes 60% of time, you can try: bn = {-# SCC "IntegerConversion" #-} 4 * fromIntegral wn b0 = {-# SCC "ByteStringIndexing" #-} B.index bi (bn+0) b1 = {-# SCC "ByteStringIndexing" #-} B.index bi (bn+1) b2 = {-# SCC "ByteStringIndexing" #-} B.index bi (bn+2) b3 = {-# SCC "ByteStringIndexing" #-} B.index bi (bn+3) w = foldl' (\w b -> shiftL w 8 .|. fromIntegral b) 0 [b3,b2,b1,b0] in {-# SCC "ArrayWriting" #-} unsafeWrite temp wn w In profiling the time of all expressions with the same SCC "name" will be summed. You can get more information about SCC here: http://www.haskell.org/ghc/docs/latest/html/users_guide/profiling.html#cost-centres Obviously, even ultra-optimizing this function to be 60 times faster (assuming that this is possible) will only make your program go about 2 time faster. One advice: I've seen various md5sum implementations in C, all using about the same algorithms and data structures, and they performed even with 10x time differences between them; md5summing fast is not a really simple problem. If I were you I would drop the comparison with ultra-optimized C and concentrate on "does my high-level-good-looking-super-readable implementation perform acceptably?". What "acceptably" means is left as an exercise to the reader. Salvatore From wagner.andrew at gmail.com Mon May 19 18:25:40 2008 From: wagner.andrew at gmail.com (Andrew Wagner) Date: Mon May 19 18:19:05 2008 Subject: [Haskell-cafe] Newbie: State monad example questions In-Reply-To: <53396d9e0805191404va8cb2d7yeb36954b83ac5ca8@mail.gmail.com> References: <53396d9e0805191404va8cb2d7yeb36954b83ac5ca8@mail.gmail.com> Message-ID: Dmitri, Excellent questions. There's one step you're missing. Most of your questions revolve around 'foo <- bar' constructs within a monad. I would suggest that you review the de-sugaring rules at http://en.wikibooks.org/wiki/Haskell/Syntactic_sugar#Do_and_proc_notation and see if that helps you out some. The best process would be for you to 1.) De-sugar this function completely and 2.) look at bind (denoted as >>=), and substitute it in. Hope this helps! 2008/5/19 Dmitri O.Kondratiev : > I am trying to understand State monad example15 at: > http://www.haskell.org/all_about_monads/html/statemonad.html > > Example 15 uses getAny that I don't understand at all how it works: > > getAny :: (Random a) => State StdGen a > getAny = do g <- get > (x,g') <- return $ random g > put g' > return x > > > Questions: > 1) random has type: > random :: (Random a, RandomGen g) => g -> (a, g) > > and for State monad: > > return a = State (\s -> (a, s)) > > then: > return (random g) = State (\s -> ((a,g), s)) > > Is it correct? > > 2) What x and g' will match to in: > do ... > (x,g') <- return $ random g > > which, as I understand equals to: > do ... > (x,g') <- State (\s -> ((a,g), s)) > > What x and g' will match to in the last expression? > > 3) In general, in do expression (pseudo): > do { x <- State (\s -> (a, s)); ...} > > What x will refer to? Will x stand for a whole lambda function: \s -> (a, s) > ? > > 4) How 'g <- get' works in this function (getAny) ? > 5) Why we need 'put g'? > > Thanks! > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From lrpalmer at gmail.com Mon May 19 19:27:14 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Mon May 19 19:20:39 2008 Subject: [Haskell-cafe] Newbie: State monad example questions In-Reply-To: <7ca3f0160805191626jd65d7c9off5010935915f5c7@mail.gmail.com> References: <53396d9e0805191404va8cb2d7yeb36954b83ac5ca8@mail.gmail.com> <7ca3f0160805191626jd65d7c9off5010935915f5c7@mail.gmail.com> Message-ID: <7ca3f0160805191627p16c26f7pba181a7baaedbf26@mail.gmail.com> Hi Dmitri. I'm just going to ramble on about what I know and how I think of things, and maybe you'll pick something up :-) On 5/19/08, Dmitri O.Kondratiev wrote: > getAny :: (Random a) => State StdGen a > getAny = do g <- get > (x,g') <- return $ random g > put g' > return x > > Questions: > return (random g) = State (\s -> ((a,g), s)) > > Is it correct? Yes, where a is a random value and g is a new generator. > 2) What x and g' will match to in: > do ... > (x,g') <- return $ random g > > which, as I understand equals to: > do ... > (x,g') <- State (\s -> ((a,g), s)) > > What x and g' will match to in the last expression? Well, I also suggest working through the desugared version of >>= as the other poster suggested: State (\s -> ((a,g), s)) >>= (\(x,g') -> ...) The question is, what values do x and g' have in '...'. Expand out the definition and see. State is kind of complicated, but you will get an answer. But I can provide some intuition aside from the formality. x <- action "Does" the action and names the return value "x". Your action is "return $ random g", namely it's an action that doesn't have any effects and just returns a value. So: (x,g') <- return $ random g Is equivalent to: let (x,g') = random g Nothing particular to State is happening here. > 3) In general, in do expression (pseudo): > do { x <- State (\s -> (a, s)); ...} > > What x will refer to? Will x stand for a whole lambda function: \s -> (a, s) > ? Here x will be equal to a, and the implicit state will be unchanged after the binding. > 4) How 'g <- get' works in this function (getAny) ? The representation of a state action is "State f", where f takes the current state as an argument and returns the result of the computation along with the new state. "get" is defined as: get = State $ \s -> (s,s) So its function takes a state, and returns the current state as the return value as well as the next state; that is to say, it does not update the state and it also returns it. So: x <- get ... Gives the name "x" to the implicit state at the time "get" was called. > 5) Why we need 'put g'? Otherwise this function would not modify the implicit state, and you'd always get the same random number back when you called it. Something to keep in mind: If you have an "action :: m a" for some monad m, then in: x <- action x will name a value of type Foo. Luke From alfonso.acosta at gmail.com Mon May 19 20:45:44 2008 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Mon May 19 20:39:10 2008 Subject: [Haskell-cafe] Link to Hierarchical-libraries documentation generated with haddock 2.0? Message-ID: <6a7c66fc0805191745g1bf94916i37d3824e31e7b3ae@mail.gmail.com> Hi all, GHC's documentation page [1] only points to hierarchical-libraries documentation generated by haddock-0.8 [2]. I need the 2.0 version in order to get links in the documentation of the project I'm working on (which needs haddock 2.0 due to the use of quite a few GHC extensions). Before I proceed to generate them myself, has anyone done it already? (I guess that must be the case since HackageDB users haddock 2.0 and gets all the links right) I would be more than happy to just click a link instead :) Either way, I think it would be a good idea to provide an alternative link to the 2.0 version. Thanks, Fons [1] http://www.haskell.org/ghc/documentation.html [2] http://www.haskell.org/ghc/docs/latest/libraries.html.tar.gz From leaveye.guo at gmail.com Mon May 19 22:32:45 2008 From: leaveye.guo at gmail.com (L.Guo) Date: Mon May 19 22:26:11 2008 Subject: [Haskell-cafe] How does GHC read UNICODE. Message-ID: <200805201032432183409@gmail.com> Hi Haskellers: I am a Chinese. Mostly, it is needed to read/write UNICODE charactors. Currently, I can only use the ByteString module in GHC 6, 2007. But I feel it is not an easy method. Does GHC support it now ? or, is there any other way to do this ? Regards -------------- L.Guo 2008-05-20 From dons at galois.com Mon May 19 22:43:48 2008 From: dons at galois.com (Don Stewart) Date: Mon May 19 22:37:15 2008 Subject: [Haskell-cafe] How does GHC read UNICODE. In-Reply-To: <200805201032432183409@gmail.com> References: <200805201032432183409@gmail.com> Message-ID: <20080520024348.GB2787@scytale.galois.com> leaveye.guo: > Hi Haskellers: > > I am a Chinese. > > Mostly, it is needed to read/write UNICODE charactors. > > Currently, I can only use the ByteString module in GHC 6, 2007. > But I feel it is not an easy method. > > Does GHC support it now ? or, is there any other way to do this ? > > Regards Hello! Chars in Haskell are 32 bit wide values, so they can happily accept various unicode encodings. The main issue then is doing IO with Chars. You can use either bytestrings, which will ignore any encoding, or the utf8-string package for Strings, which will properly encode and decode utf8 values to Char. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/utf8-string -- Don From aslatter at gmail.com Mon May 19 22:44:45 2008 From: aslatter at gmail.com (Antoine Latter) Date: Mon May 19 22:38:09 2008 Subject: [Haskell-cafe] ByteString.pack behavior In-Reply-To: <20080519182206.GB29658@scytale.galois.com> References: <48308E31.5080807@fit.vutbr.cz> <20080518202310.GB7494@scytale.galois.com> <48310146.3060700@fit.vutbr.cz> <20080519182206.GB29658@scytale.galois.com> Message-ID: <694519c50805191944h3197ff4fr93455c477541add5@mail.gmail.com> On Mon, May 19, 2008 at 1:22 PM, Don Stewart wrote: > Safe Num wrappers for primitive types that throw exceptions on overflow > would make a useful library. > > Any takers? > Sounds like fun. Neither the error messages nor the code will be pretty. Are we just interested in the Data.Int types and the Data.Word types? -Antoine From zs.szalai at gmail.com Tue May 20 01:54:33 2008 From: zs.szalai at gmail.com (Zsolt SZALAI) Date: Tue May 20 01:47:57 2008 Subject: [Haskell-cafe] one-way monads Message-ID: Hi! Now, i'm getting familiar with monads, but there is a little discredit about one-way monads. For example, in monads presented in Monads for Functional Programming by Philip Wadler, they are all two-way monads, internal data can be extracted from the monad, and these data, call them state, are in deed _local_ to a function using the monadic computation, so the state there is just a little magic, and they are really just functions(as in a pure language). An other example is Random. I've figured out, that when initializing a generator, it uses the actual timestamp and cputime to initialize. If it wouldnt happen, two distinct uses of Random in a program would result the same random number sequence. Here comes IO and one-way monads, where the internal state can not be extacted, and seems, that the internal data is global to the program. Hows that could be? Is it just because main::IO() or because the implementation of IO uses external C functions and there are no internal state in the monad itself at all? And why one can not write a function that makes an IO computation and the return type does not include and IO contructor? It is a feature of the language and specific to IO, or anybody could write a monad with this property(one-way), assuming the implementation does not use external languages? Or the one-way property is just that, there is no such functions, that allow extracting internal data? Also, is there any other monad, that has the one-way property? Thanks, -- Zsolt From tmorris at tmorris.net Tue May 20 02:38:52 2008 From: tmorris at tmorris.net (Tony Morris) Date: Tue May 20 02:32:35 2008 Subject: [Haskell-cafe] lambdabot on GHC 6.8.2 Message-ID: <483271FC.8020407@tmorris.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 So after some effort, I managed to get lambdabot installed on a ubuntu machine using GHC 6.8.2, however, it fails when evaluating an expression: > 1 + 1 setResourceLimit: invalid argument (Invalid argument) Googling around brings up a bug (#2038) against GHC 6.8.2. Am I hitting this bug? If so, can I get around it to get a working lambdabot? Thanks for any tips. - -- Tony Morris http://tmorris.net/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIMnFnmnpgrYe6r60RAp7DAJ9JhFsWwL05eyrcECf6C9Z/ML+h0gCgt5/I 3E7eOjVMm+RSXumbYiCsgR8= =bpjW -----END PGP SIGNATURE----- From si at fh-wedel.de Tue May 20 03:11:50 2008 From: si at fh-wedel.de (Uwe Schmidt) Date: Tue May 20 03:05:15 2008 Subject: [Haskell-cafe] [tagsoup] is it the expected behaviour ? In-Reply-To: <87hccuine7.fsf@nmd9999.imr.no> References: <48315144.8000207@yahoo.fr> <87hccuine7.fsf@nmd9999.imr.no> Message-ID: <200805200911.50251.si@fh-wedel.de> Ketil Malde wrote: > I don't think that is legal XML. The definitions of STag and Attribute > from http://www.w3.org/TR/xml11/#NT-STag are: > > [40] STag ::= '<' Name (S Attribute)* S? '>' > [41] Attribute ::= Name Eq AttValue > > And 'S' represents one or more whitespace characters, so it seems > clear that they are not allowed between Name, Eq, and AttValue. indeed it's legal because of rule [25] (http://www.w3.org/TR/xml11/#NT-Eq) [25] Eq ::= S? '=' S? and rule [3] [3] S ::= (#x20 | #x9 | #xD | #xA)+ Cheers, Uwe From Ben.Lippmeier at anu.edu.au Tue May 20 03:19:07 2008 From: Ben.Lippmeier at anu.edu.au (Ben Lippmeier) Date: Tue May 20 03:12:35 2008 Subject: [Haskell-cafe] one-way monads In-Reply-To: References: Message-ID: <1347C922-F8E7-414C-9675-363EC22CA65A@anu.edu.au> On 20/05/2008, at 3:54 PM, Zsolt SZALAI wrote: > Here comes IO and one-way monads, where the internal state can not be > extacted, and seems, that the internal data is global to the program. > Hows that could be? Is it just because main::IO() or because the > implementation of IO uses external C functions and there are no > internal state in the monad itself at all? Operationally, the IO monad doesn't have any internal state. The 'state' would be the outside world - which can't really be represented at runtime. The IO monad is a state monad that passes around a special token that / represents/ the outside world. What the token actually is doesn't matter, but passing it around in a single threaded manner in the Core IR provides data dependencies that ensure that operations on the world happen in the correct order. References to this token actually get erased before code generation. In GHC this erasure is called the 'state-hack'. > And why one can not write a function that makes an IO computation and > the return type does not include and IO contructor? It is a feature of > the language and specific to IO, or anybody could write a monad with > this property(one-way), assuming the implementation does not use > external languages? IO isn't a feature of the language, it's a type defined in the library. You can define your own IO-style monads if you like. > Or the one-way property is just that, there is no such functions, that > allow extracting internal data? Just that. It's one way because there are no functions convert an 'IO a' into an 'a' (mostly). Doing that would break the desired single- threadedness property. If you're convinced that violating this single-threadedness won't break your program you can use unsafePerformIO :: IO a -> a, but this performs the action, it doesn't give you the actual world token. Ben. From jeremy at n-heptane.com Tue May 20 03:29:18 2008 From: jeremy at n-heptane.com (Jeremy Shaw) Date: Tue May 20 03:22:03 2008 Subject: [Haskell-cafe] one-way monads In-Reply-To: References: Message-ID: <87zlqlph69.wl%jeremy@n-heptane.com> Hello, You *can* get things out of the IO monad with: System.IO.Unsafe.unsafePerformIO :: IO a -> a but, in almost all cases you shouldn't. The name 'unsafe' is there for a reason :) The IO monad does not explicitly contain any state -- it's entire purpose is to ensure that operations which can have side-effects happen in a specific order. So, if you do: do writeFile "foo.txt" moveFile "foo.txt" "bar.txt" it is *really* important than the writeFile is run first and moveFile is run second. If you did: let a = unsafePerformIO (writeFile "foo.txt") b = unsafePerformIO (moveFile "foo.txt" "bar.txt") in (a,b) Then the order the actions occured in would depend on how the result was used. You will notice that many of the monads have a functions like, execWriter, execReader, execState, etc, to convert the monadic values into non monadic values. If you create your own monad you can make it 'one-way' by simply not exporting execYourMonad. Of course, that may make your monad pretty useless. The IO monad is useful because the code that calls main knows what to do with something of type 'IO ()'. The exact internals of the IO monad depend on the compiler, but it is usually a bit like: newtype RealWorld = RealWorld newtype IO a = IO { unIO :: RealWorld -> (a, RealWorld) } instance Monad IO where return a = IO (\rw -> (a, rw)) m >>= f = IO $ \rw -> let (a, rw') = (unIO m) rw in (unIO (f a)) rw' (or something close to that). RealWorld is basically just a token that gets pass around to enforce the ordering of the IO actions. It contains no explicit state. However, it implicitly represents that state of everything in the real world (file handles, RAM, what you are about to type on the keyboard). This is why you might still consider Haskell to be 'pure' even with the addition of the IO monad. main is basically a function: main :: RealWorld -> ((), RealWorld) main = ... and functions like getLine would be like: getLine :: RealWorld -> (String, RealWorld) In theory, getLine takes the RealWorld that was passed in, extracts the String, and returns a new RealWorld where the String has been read. Assuming you pass in the same "real world" you should always get the same answer. However, there in no instance of Eq for the real world, so ensuring things are equal is left up to the operator. For a simple application, such as a haskell version of 'echo', that might just mean ensuring it is called with the same command-line arguments, enough free memory, etc. For other apps, it would be impossible to recreate the a suitably equal "real world". In summary, the IO monad is pretty much like an other Monad, and there is even a function to get things out of the IO monad. But, for the most part, we pretend that unsafePerformIO does not exist, because that lets us safely pretend that the RealWorld type actually does contain (and determine) the state of the real world. If you want to use unsafePeformIO, it is your responsibility to ensure the illusion is not destroyed. In concurrent clean, they use a similar abstraction, but instead of using monads to pass around RealWorld, they explicity pass it around. A bit like: main world = let world' = getLine world world'' = putStr "foo" world' in world'' However, you have to be careful not to write: main world = let world' = getLine world world'' = putStr "foo" world' world''' = putStr "boo" world' in (world'', world''') because that would create two parallel universes, one where "foo" was written stdout and one where "boo" was written to stdout. Because they both start with the same world' but ended up with different worlds (aka, world'' and world'''). The designers of clean decided that letting programmers create parallel universes was too much power and might destroy the space-time continuum. So the clean type system uses 'uniqueness typing' to ensure that you can only alter world' once, limiting your impact to a single universe. So, if you tried to compile the second example, it would abort when it saw, putStr "boo" world', because you already altered that state of the universe in the previous line. You don't get to travel back in time and make a second parallel universe where the other choice was taken instead. Anyway, I hope this helps. j. At Tue, 20 May 2008 07:54:33 +0200, Zsolt SZALAI wrote: > > Hi! > > Now, i'm getting familiar with monads, but there is a little discredit > about one-way monads. > For example, in monads presented in Monads for Functional Programming > by Philip Wadler, they are all two-way monads, internal data can be > extracted from the monad, and these data, call them state, are in deed > _local_ to a function using the monadic computation, so the state > there is just a little magic, and they are really just functions(as in > a pure language). > An other example is Random. I've figured out, that when initializing a > generator, it uses the actual timestamp and cputime to initialize. If > it wouldnt happen, two distinct uses of Random in a program would > result the same random number sequence. > > Here comes IO and one-way monads, where the internal state can not be > extacted, and seems, that the internal data is global to the program. > Hows that could be? Is it just because main::IO() or because the > implementation of IO uses external C functions and there are no > internal state in the monad itself at all? > And why one can not write a function that makes an IO computation and > the return type does not include and IO contructor? It is a feature of > the language and specific to IO, or anybody could write a monad with > this property(one-way), assuming the implementation does not use > external languages? > Or the one-way property is just that, there is no such functions, that > allow extracting internal data? > Also, is there any other monad, that has the one-way property? > > Thanks, > -- > Zsolt > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From ketil at malde.org Tue May 20 03:30:57 2008 From: ketil at malde.org (Ketil Malde) Date: Tue May 20 03:24:07 2008 Subject: [Haskell-cafe] How does GHC read UNICODE. In-Reply-To: <20080520024348.GB2787@scytale.galois.com> (Don Stewart's message of "Mon\, 19 May 2008 19\:43\:48 -0700") References: <200805201032432183409@gmail.com> <20080520024348.GB2787@scytale.galois.com> Message-ID: <87hcctfn4e.fsf@nmd9999.imr.no> Don Stewart writes: > You can use either bytestrings, which will ignore any encoding, Uh, I am hesitant to voice my protest here, but I think this bears some elaboration: Bytestrings are exactly that, strings of bytes. There are basically two interfaces, one (Data.ByteString[.Lazy]), which operates on raw bytes (and gives you Word8s), and another (Data.ByteString[.Lazy].Char8), which treats the contents as Chars. The latter will only deal with Unicode code points 0..255 (or ISO_8859-1) -- and truncate higher code point values to fit this range. Basically, bytestrings are the wrong tool for the job if you need more than 8 bits per character. I think the predecessors of bytestring (FPS?) had support for other fixed-size encodings, that is, two-byte and four-byte characters. Perhaps writing a Data.Word16String bytestrings-alike using UCS-2 would be an option? -k -- If I haven't seen further, it is by standing in the footprints of giants From yann at kierun.org Tue May 20 04:15:57 2008 From: yann at kierun.org (Yann Golanski) Date: Tue May 20 04:09:23 2008 Subject: [Haskell-cafe] Rotating backdrop (aka learning Haskell) Message-ID: <20080520081557.GA18833@kierun.org> To help me learn Haskell, I decided on a simple (AH!) problem: given a list of images, display a random one as my desktop backdrop. After some time, change the image. Simple? What I actually want to do is a little more specific: Read a list of images (one per line) from a file. Given that a working day is about 8 hours, I want to see all the images during the day. So, the time between changes should be (nbr_of_images) / (8 * 60 * 60) seconds. Of course, if the file changes (I add or remove any number of images) this need to change and be recalculated. Clearly, I want some interaction with a pseudo-random number generator. Because this is a learning exercise, I want to have a pretty GUI for this. Three buttons: Exit (which quits the application), Reset (re-reads the file whether it changed or not) and Next (display the next image). Then I want a counter and a progress bar telling me when the next change will occur. 1- Get a list out of a file: I managed to do that using the following: parseImageFile :: FilePath -> IO [String] parseImageFile file = do inpStr <- readFile file return $ filter (/="") (breaks (=='\n') inpStr) Nice, simple and I understand what it is doing. 2- Get a random element from a list and remove it: Okay, this I understand less well. I looked at the solutions of problems 23 and 20 in http://www.haskell.org/haskellwiki/99_questions so there is a skeleton there. However, my list is IO [String].... Hum, monads. Any pointers as to how to do that? 3- Wait and do something later.... How, I have no idea how to do that! Help? 4- I guess that progress bars and updating text will be somewhere in the GUI (I chose wxHaskell)... Again, no idea where. 5- How do you call an external program in Haskell? Either xv or Esetroot will do the job of displaying the image. Is there a Haskell native way to do that? Once this is done and I have commented to the code, I will be happy to put it onto the wiki as a teaching aid. Thanks. -- yann@kierun.org -= H+ =- www.kierun.org PGP: 009D 7287 C4A7 FD4F 1680 06E4 F751 7006 9DE2 6318 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080520/ef7954cd/attachment.bin From ketil at malde.org Tue May 20 04:55:39 2008 From: ketil at malde.org (Ketil Malde) Date: Tue May 20 04:48:49 2008 Subject: [Haskell-cafe] Rotating backdrop (aka learning Haskell) In-Reply-To: <20080520081557.GA18833@kierun.org> (Yann Golanski's message of "Tue\, 20 May 2008 09\:15\:57 +0100") References: <20080520081557.GA18833@kierun.org> Message-ID: <871w3xfj78.fsf@nmd9999.imr.no> Yann Golanski writes: > 1- Get a list out of a file: I managed to do that using the following: > > parseImageFile :: FilePath -> IO [String] > parseImageFile file = do inpStr <- readFile file > return $ filter (/="") (breaks (=='\n') inpStr) > > Nice, simple and I understand what it is doing. Can be improved: breaks (=='\n') == lines -- easier to read, no? filter (/="") == filter (not . null) -- more polymorphic, not important here do x <- expr1 == expr1 >>= return . expr2 return $ expr2 x -- i.e. "readFile f >>= return . filter (not.null) . lines" > 2- Get a random element from a list and remove it: Okay, this I > understand less well. I looked at the solutions of problems 23 and 20 > in http://www.haskell.org/haskellwiki/99_questions so there is a > skeleton there. However, my list is IO [String].... Hum, monads. Since you really want to shuffle the list, how about assigning each entry a random number, and sorting the list? shuffle :: [String] -> IO [String] shuffle fs = do rs <- randoms return (map snd $ sort $ zipWith rs fs) > 5- How do you call an external program in Haskell? See the 'System.Process' or 'System.Cmd' modules. -k -- If I haven't seen further, it is by standing in the footprints of giants From sjanssen at cse.unl.edu Tue May 20 04:57:59 2008 From: sjanssen at cse.unl.edu (Spencer Janssen) Date: Tue May 20 04:51:05 2008 Subject: [Haskell-cafe] Rotating backdrop (aka learning Haskell) In-Reply-To: <20080520081557.GA18833@kierun.org> References: <20080520081557.GA18833@kierun.org> Message-ID: <20080520085759.GA16525@celeborn> On Tue, May 20, 2008 at 09:15:57AM +0100, Yann Golanski wrote: > To help me learn Haskell, I decided on a simple (AH!) problem: given a > list of images, display a random one as my desktop backdrop. After some > time, change the image. Simple? > > What I actually want to do is a little more specific: Read a list of > images (one per line) from a file. Given that a working day is about 8 > hours, I want to see all the images during the day. So, the time > between changes should be (nbr_of_images) / (8 * 60 * 60) seconds. Of > course, if the file changes (I add or remove any number of images) this > need to change and be recalculated. Clearly, I want some interaction > with a pseudo-random number generator. > > Because this is a learning exercise, I want to have a pretty GUI for > this. Three buttons: Exit (which quits the application), Reset > (re-reads the file whether it changed or not) and Next (display the next > image). Then I want a counter and a progress bar telling me when the > next change will occur. > > 1- Get a list out of a file: I managed to do that using the following: > > parseImageFile :: FilePath -> IO [String] > parseImageFile file = do inpStr <- readFile file > return $ filter (/="") (breaks (=='\n') inpStr) > > Nice, simple and I understand what it is doing. > > 2- Get a random element from a list and remove it: Okay, this I > understand less well. I looked at the solutions of problems 23 and 20 > in http://www.haskell.org/haskellwiki/99_questions so there is a > skeleton there. However, my list is IO [String].... Hum, monads. > > Any pointers as to how to do that? > > 3- Wait and do something later.... How, I have no idea how to do that! > Help? One way is System.Concurrent.threadDelay, though there might be another way that integrates more nicely with wxHaskell. Hopefully you can find it in their documentation. http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Concurrent.html#v%3AthreadDelay > 4- I guess that progress bars and updating text will be somewhere in the > GUI (I chose wxHaskell)... Again, no idea where. > > 5- How do you call an external program in Haskell? Either xv or > Esetroot will do the job of displaying the image. Is there a Haskell > native way to do that? Try the System.Cmd.system function. http://www.haskell.org/ghc/docs/latest/html/libraries/process/System-Cmd.html#v%3Asystem > Once this is done and I have commented to the code, I will be happy to > put it onto the wiki as a teaching aid. > > Thanks. > > -- > yann@kierun.org -= H+ =- www.kierun.org > PGP: 009D 7287 C4A7 FD4F 1680 06E4 F751 7006 9DE2 6318 Cheers, Spencer Janssen From bulat.ziganshin at gmail.com Tue May 20 05:14:25 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue May 20 05:09:13 2008 Subject: [Haskell-cafe] Rotating backdrop (aka learning Haskell) In-Reply-To: <20080520081557.GA18833@kierun.org> References: <20080520081557.GA18833@kierun.org> Message-ID: <1788309410.20080520131425@gmail.com> Hello Yann, Tuesday, May 20, 2008, 12:15:57 PM, you wrote: > To help me learn Haskell, I decided on a simple (AH!) problem: given a > list of images, display a random one as my desktop backdrop. After some > time, change the image. Simple? what you try to implements looks like too large problem for one step in learning, i suggest to split it into two parts - first, write console app that does all the stuff, and then add GUI frontend to it for learning IO, i can suggest http://haskell.org/haskellwiki/IO_inside although it's rather large and deep tutorial while wxHaskell is easier to use, for learning purposes gtk2hs may be better since it has good tutorial a few links for gtk2hs: Home: http://haskell.org/gtk2hs/overview/ Paper: http://haskell.org/~shae/memory.pdf Glade intro: http://haskell.org/gtk2hs/docs/tutorial/glade/ Tutorial: http://home.telfort.nl/sp969709/gtk2hs/index.html the same for wxHaskell: paper about high-level wxHaskell features: http://research.microsoft.com/users/daan/download/papers/wxhaskell.pdf slides on the same topic: http://www.cse.unsw.edu.au/~cs4132/lecture/wlta543.pdf -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From john at repetae.net Tue May 20 05:23:38 2008 From: john at repetae.net (John Meacham) Date: Tue May 20 05:17:02 2008 Subject: [Haskell-cafe] Experimental compilation of Haskell to Erlang In-Reply-To: <4831DC75.4040809@btinternet.com> References: <4831B9AC.20901@btinternet.com> <404396ef0805191152t54a30bcvac5e89cd675d587@mail.gmail.com> <4831DC75.4040809@btinternet.com> Message-ID: <20080520092338.GH6620@sliver.repetae.net> On Mon, May 19, 2008 at 09:00:53PM +0100, Andrew Coppin wrote: >> It's a fair bit of engineering work, there are some design decisions >> to be made - such as how to interface with the host language (if at >> all). Theoretically its not that hard to come up with something, but >> it is a fair amount of effort. >> > > To be sure, I doubt it's what you'd call "trivial". I just ment it looks > easier than, say, translating C to Pascal or something. Actually, It is generally harder. The ghc back end for jhc was far more problematic than the C backend to keep working. The simple reason is what I call 'impedance mismatch'. ghc and jhc have sightly different semantics for unboxed values, the primitives don't quite map one to one. optimizations that are needed for jhc's back end hurt when translated to ghc. The high level of haskell is a hinderance more, because it means compilers do a lot more behind the scenes so there is a lot more "stuff" to cause conflicts. A graph reduction machine in C is fairly easy and only needs to be done once, but one size doesn't fit all and starting from scratch can be much easier than trying to shoehorn another back end onto your code. John -- John Meacham - ?repetae.net?john? From kirby81 at gmail.com Tue May 20 05:41:32 2008 From: kirby81 at gmail.com (Salvatore Insalaco) Date: Tue May 20 05:34:57 2008 Subject: [Haskell-cafe] MD5 performance optimizations, and GHC -via-C producing segfaulting binary Message-ID: <5a376f550805200241i3bb57e39sa0cb56e9fb28624b@mail.gmail.com> 2008/5/17 Andrew Coppin : > Hi folks. > > OK, try this: > > darcs get http://darcs.orphi.me.uk/MyMD5 > cd MyMD5 > ghc -O2 --make md5sum > md5sum I've got some time to take a look at the code. It's very nice, readable and declarative, but obviously not optimized for "raw speed". There're a few things to do to have a speed-up of 2x, without going "low-level". 1) There's a lazyness leak in Pad.hs. The sum in: else make_block_bs bs0 : work (n + block_size_bytes) bs1 is not strict. With a very large file (e.g. 100 mb) it means stack overflow. [roxas:~/Desktop/test2/MyMD5] kirby% ghc -O2 --make md5sum.hs [roxas:~/Desktop/test2/MyMD5] kirby% time ./md5sum ../../jboss-4.2.2.GA.zip Stack space overflow: current size 8388608 bytes. Use `+RTS -Ksize' to increase it. To solve it just add a bang (!) before the n parameter: work !n bs = You've got to add {-# LANGUAGE BangPatterns #-} at the top of the file too. There're solutions that don't imply BangPatterns, and use only seq, but I like bang patterns! Now it works: [roxas:~/Desktop/test2/MyMD5] kirby% time ./md5sum ../../jboss-4.2.2.GA.zip E6542028D538BAEC180A96A5D1E6EC3A 11.958u 0.210s 0:12.19 99.7% 0+0k 0+2io 0pf+0w 2) make_block_bs is sub-optimal, and very critical to performance. I decided to use Data.Binary for it (it's also more readable, and you get rid of the unsafeWrite): import Data.Binary import Data.Binary.Get import Control.Monad // ... instance Binary Block where put _ = undefined get = do xs <- replicateM 16 getWord32le return $ Block $ listArray (0, 15) xs make_block_bs :: B.ByteString -> Block make_block_bs = decode Now we are getting faster: [roxas:~/Desktop/test2/MyMD5] kirby% time ./md5sum ../../jboss-4.2.2.GA.zip E6542028D538BAEC180A96A5D1E6EC3A 8.063u 0.174s 0:08.23 100.0% 0+0k 0+0io 0pf+0w 3) You are doing a lot of access to fields of a strict data type (State). You can at least ask the compiler to help you a bit with -funbox-strict-fields. Now we have: [roxas:~/Desktop/test2/MyMD5] kirby% time ./md5sum ../../jboss-4.2.2.GA.zip E6542028D538BAEC180A96A5D1E6EC3A 6.780u 0.133s 0:06.91 100.0% 0+0k 0+1io 0pf+0w We have got a good, nearly 2x, speed-up with very few optimizations, and we run in a very small constant amount of memory. Probably compiling with -fvia-C could help even more, but strangely: [roxas:~/Desktop/test2/MyMD5] kirby% ghc -fvia-C -funbox-strict-fields -O2 --make md5sum.hs [roxas:~/Desktop/test2/MyMD5] kirby% time ./md5sum ../../jboss-4.2.2.GA.zip Segmentation fault Is this supposed to happen? There're no "unsafe" functions or imports used in the program. Maybe a bug in GHC? Salvatore From la at iki.fi Tue May 20 06:09:48 2008 From: la at iki.fi (Lauri Alanko) Date: Tue May 20 06:03:12 2008 Subject: [Haskell-cafe] one-way monads In-Reply-To: References: Message-ID: <20080520100948.GB31349@cs.helsinki.fi> On Tue, May 20, 2008 at 07:54:33AM +0200, Zsolt SZALAI wrote: > Here comes IO and one-way monads, where the internal state can not be > extacted, and seems, that the internal data is global to the program. > Hows that could be? Is it just because main::IO() or because the > implementation of IO uses external C functions and there are no > internal state in the monad itself at all? There's nothing magical about the IO monad as a concept. It is true that it is handled specially by the library and the compiler, but this is just for performance reasons. IO _could_ well be an ordinary datatype: data IO a where Return :: a -> IO a Bind :: IO a -> (a -> IO b) -> IO b OpenFile :: FilePath -> IOMode -> IO Handle HPutChar :: Handle -> Char -> IO () HGetChar :: Handle -> IO Char HClose :: Handle -> IO () -- etc. If it were implemented like this, then the only magic would be in the runtime, which would take the IO value returned by the main function and somehow execute it. But if the implementation of IO were like this, and the datatype were exposed, then we could perfectly well write a userlevel "sandboxing" function: runVirtual :: IO a -> VirtualWorld -> (a, VirtualWorld) Where "VirtualWorld" would be a sandbox that contains all the state that IO operations can access: at least a filesystem, maybe something else too. This would probably count as "extraction". As it happens, the IO monad is usually not implemented this way, but more directly. Performance is here more important than transparency... Lauri From voigt at tcs.inf.tu-dresden.de Tue May 20 06:19:02 2008 From: voigt at tcs.inf.tu-dresden.de (Janis Voigtlaender) Date: Tue May 20 06:09:38 2008 Subject: [Haskell-cafe] one-way monads In-Reply-To: <20080520100948.GB31349@cs.helsinki.fi> References: <20080520100948.GB31349@cs.helsinki.fi> Message-ID: <4832A596.5030703@tcs.inf.tu-dresden.de> Lauri Alanko wrote: > On Tue, May 20, 2008 at 07:54:33AM +0200, Zsolt SZALAI wrote: > >>Here comes IO and one-way monads, where the internal state can not be >>extacted, and seems, that the internal data is global to the program. >>Hows that could be? Is it just because main::IO() or because the >>implementation of IO uses external C functions and there are no >>internal state in the monad itself at all? > > > There's nothing magical about the IO monad as a concept. It is true > that it is handled specially by the library and the compiler, but this > is just for performance reasons. > > IO _could_ well be an ordinary datatype: > > data IO a where > Return :: a -> IO a > Bind :: IO a -> (a -> IO b) -> IO b > OpenFile :: FilePath -> IOMode -> IO Handle > HPutChar :: Handle -> Char -> IO () > HGetChar :: Handle -> IO Char > HClose :: Handle -> IO () > -- etc. > > If it were implemented like this, then the only magic would be in the > runtime, which would take the IO value returned by the main function > and somehow execute it. But if the implementation of IO were like > this, and the datatype were exposed, then we could perfectly well > write a userlevel "sandboxing" function: > > runVirtual :: IO a -> VirtualWorld -> (a, VirtualWorld) > > Where "VirtualWorld" would be a sandbox that contains all the state > that IO operations can access: at least a filesystem, maybe something > else too. This would probably count as "extraction". In this context, the IOSpec library springs to mind: http://www.cs.nott.ac.uk/~wss/repos/IOSpec/ -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:voigt@tcs.inf.tu-dresden.de From duncan.coutts at worc.ox.ac.uk Tue May 20 07:03:27 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue May 20 06:54:37 2008 Subject: [Haskell-cafe] How does GHC read UNICODE. In-Reply-To: <87hcctfn4e.fsf@nmd9999.imr.no> References: <200805201032432183409@gmail.com> <20080520024348.GB2787@scytale.galois.com> <87hcctfn4e.fsf@nmd9999.imr.no> Message-ID: <1211281407.5824.489.camel@localhost> On Tue, 2008-05-20 at 09:30 +0200, Ketil Malde wrote: > Don Stewart writes: > > > You can use either bytestrings, which will ignore any encoding, > > Uh, I am hesitant to voice my protest here, but I think this bears > some elaboration: > > Bytestrings are exactly that, strings of bytes. Yes, we tried to make it explicit. > Basically, bytestrings are the wrong tool for the job if you need more > than 8 bits per character. Right. It's not intended for text, except for those 8-bit mixed binary ASCII network protocols, file formats etc. > I think the predecessors of bytestring (FPS?) had support for other > fixed-size encodings, that is, two-byte and four-byte characters. I'm not sure about that, but there is the old Data.PackedString which uses UTF-32. There is no fixed size two-byte Unicode encoding (there is only UTF-16 which is variable width.) > Perhaps writing a Data.Word16String bytestrings-alike using UCS-2 > would be an option? I'm supervising a masters student who is working on a proper Unicode ADT with a similar API and underlying implementation to that of ByteString. Hopefully people will be able to start using that for an internal representation of text instead of ByteString. Duncan From vigalchin at gmail.com Tue May 20 07:53:45 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Tue May 20 07:47:09 2008 Subject: [Haskell-cafe] question on ghc-pkg database Message-ID: <5ae4f2ba0805200453y71ddf18atf342605b109b8c72@mail.gmail.com> Hello, What is the difference between the following two ghc-pkg database instances: /usr/lib/ghc-6.8.2/package.conf /usr/local/lib/ghc-6.8.2/package.conf ?? Thanks, Vasili -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080520/067a898f/attachment.htm From allbery at ece.cmu.edu Tue May 20 08:10:23 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Tue May 20 08:03:52 2008 Subject: [Haskell-cafe] question on ghc-pkg database In-Reply-To: <5ae4f2ba0805200453y71ddf18atf342605b109b8c72@mail.gmail.com> References: <5ae4f2ba0805200453y71ddf18atf342605b109b8c72@mail.gmail.com> Message-ID: <7FA4A02B-1A6C-4CD7-928E-424B0DDB6F6A@ece.cmu.edu> On 2008 May 20, at 7:53, Galchin, Vasili wrote: > What is the difference between the following two ghc-pkg > database instances: > > /usr/lib/ghc-6.8.2/package.conf > /usr/local/lib/ghc-6.8.2/package.conf You somehow have two different ghc 6.8.2 packages installed, and the two package databases are related to the two packages (and not to each other). I suspect one is a vendor package and the other is from the generic binary package on haskell.org. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080520/ce2efea8/attachment.htm From jules at jellybean.co.uk Tue May 20 08:40:40 2008 From: jules at jellybean.co.uk (Jules Bean) Date: Tue May 20 08:34:06 2008 Subject: [Haskell-cafe] Performance: MD5 In-Reply-To: <482FEB74.3090909@btinternet.com> References: <482EF0EF.2090207@btinternet.com> <296039281.20080517195217@gmail.com> <482FEB74.3090909@btinternet.com> Message-ID: <4832C6C8.90102@jellybean.co.uk> Andrew Coppin wrote: > > So all that bravado about Haskell enabling higher-level optimisations to > produce a result faster than C is actually complete nonesense? Nonsense? No. Something that actually exists? No. Haskell enables optimisations. Writing a SufficientlySmartCompiler ( http://c2.com/cgi/wiki?SufficientlySmartCompiler ) still requires work. Jules From olivier.boudry at gmail.com Tue May 20 09:11:30 2008 From: olivier.boudry at gmail.com (Olivier Boudry) Date: Tue May 20 09:04:59 2008 Subject: [Haskell-cafe] How does GHC read UNICODE. In-Reply-To: <200805201032432183409@gmail.com> References: <200805201032432183409@gmail.com> Message-ID: On Mon, May 19, 2008 at 10:32 PM, L.Guo wrote: > > > Does GHC support it now ? or, is there any other way to do this ? > > Hi, The following blog article may help: http://blog.kfish.org/2007/10/survey-haskell-unicode-support.html It's a comparison of the different libraries for dealing with Unicode in Haskell (utf8 in source, iconv, utf8-string, encoding). Best regards, Olivier. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080520/efb8e809/attachment.htm From aslatter at gmail.com Tue May 20 09:44:24 2008 From: aslatter at gmail.com (Antoine Latter) Date: Tue May 20 09:37:50 2008 Subject: [Haskell-cafe] ByteString.pack behavior In-Reply-To: <694519c50805191944h3197ff4fr93455c477541add5@mail.gmail.com> References: <48308E31.5080807@fit.vutbr.cz> <20080518202310.GB7494@scytale.galois.com> <48310146.3060700@fit.vutbr.cz> <20080519182206.GB29658@scytale.galois.com> <694519c50805191944h3197ff4fr93455c477541add5@mail.gmail.com> Message-ID: <694519c50805200644h1505acbeh303520f8109152e8@mail.gmail.com> On Mon, May 19, 2008 at 9:44 PM, Antoine Latter wrote: > Sounds like fun. Neither the error messages nor the code will be pretty. > > Are we just interested in the Data.Int types and the Data.Word types? > It's up on hackage here: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/checked I'm not sure how easy it would be to track down the error once you get it, but I suppose knowing is better than not knowing. I haven't made any attempt towards making the bounds-checking cheap, so this isn't a solution for deploying an application which needs fast integer operations with bounds checking. This is more for testing or verification. Let me know if you find this useful, or if you think it needs any work. -Antoine From aslatter at gmail.com Tue May 20 09:47:18 2008 From: aslatter at gmail.com (Antoine Latter) Date: Tue May 20 09:40:44 2008 Subject: [Haskell-cafe] ByteString.pack behavior In-Reply-To: <694519c50805200644h1505acbeh303520f8109152e8@mail.gmail.com> References: <48308E31.5080807@fit.vutbr.cz> <20080518202310.GB7494@scytale.galois.com> <48310146.3060700@fit.vutbr.cz> <20080519182206.GB29658@scytale.galois.com> <694519c50805191944h3197ff4fr93455c477541add5@mail.gmail.com> <694519c50805200644h1505acbeh303520f8109152e8@mail.gmail.com> Message-ID: <694519c50805200647o738e1e87yc7dac8cb531ac73f@mail.gmail.com> On Tue, May 20, 2008 at 8:44 AM, Antoine Latter wrote: > > It's up on hackage here: > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/checked > One more thing - there's no "Data" instance for these types. Presumably it wouldn't be hard to add, I just wasn't familiar with the class, and the technique (if any) for lifting an instance of Data through a newtype wasn't immediately obvious form the class interface. From olivier.boudry at gmail.com Tue May 20 11:01:21 2008 From: olivier.boudry at gmail.com (Olivier Boudry) Date: Tue May 20 10:54:47 2008 Subject: [Haskell-cafe] Newbie: State monad example questions In-Reply-To: <53396d9e0805191404va8cb2d7yeb36954b83ac5ca8@mail.gmail.com> References: <53396d9e0805191404va8cb2d7yeb36954b83ac5ca8@mail.gmail.com> Message-ID: 2008/5/19 Dmitri O.Kondratiev : > I am trying to understand State monad example15 at: > http://www.haskell.org/all_about_monads/html/statemonad.html > > Hi Dmitri, I'm not sure you need to understand everything about Monad and do-notation to use the State Monad. So I will try to explain its use without talking about those scary topics. ;-) In Haskell you use the state monad when you want to hide state passing between function calls. As Haskell is pure you cannot change state. You can just create a new state and return it along with the value. In haskell you would do this by returning the value and new state in a tuple. State passing functions usually have the type `s -> (a, s)` where a is the type of the return value and s is the type of the State. This is exactly what the `random` function does. It gets a state and returns a tuple made of a value and a new state (StdGen: is a new seed for the random generator) to be used on the next `random` function call . Without the state monad you have to explicitely pass the new seed between calls to `random` as using the same seed for all function calls would always give you the same "not so random" number. Explicit state passing would look like this. get3RandomInts :: StdGen -> (Int, Int, Int) get3RandomInts g1 = let (r1, g2) = random g1 (r2, g3) = random g2 (r3, _) = random g3 in (r1, r2, r3) It's tedious, unreadable and error prone as it's easy to mess up the numbering (based on my experience). The State Monad allow you to hide the state passing. You don't have to give the state as an argument and your function won't return a changed state along with the data. Code running in the State Monad will look like this: getAny :: (Random a) => State StdGen a getAny = do g <- get -- magically get the current StdGen let (x, g') = random g put g' -- magically save the new StdGen for later return x get3RandomIntsWithState :: State StdGen (Int, Int, Int) get3RandomIntsWithState = do r1 <- getAny -- you don't care about stdgen passing r2 <- getAny r3 <- getAny return (r1, r2, r3) To use your get3RandomIntsWithState function you need to run it using one of runState (returns the (value, state)) or evalState (returns the value). main :: IO () main = do g <- getStdGen let t = evalState get3RandomsWithState g print t The interesting bits are in the getAny function. The State Monad provides you with 2 new function, get and set. If you look at this function as blackboxes; `get` will retrieve the current State and `put` will save a new State. You don't need to worry about how the State is passed from one getAny function call to another as long as they're run in the same `evalState` call. Now getAny can be simplified. If you look at the random function and at the State newtype declaration you will see that a State is a `s -> (a, s)` function "hidden" in the State constructor. newtype State s a = State {runState :: s -> (a, s)} random is also of the type `s -> (a, s)` even if variables are labelled `g` and `a` random :: (RandomGen g, Random a) => g -> (a, g) So wrapping the random function into the State constructor will just give you a getAny function for free. getAny :: (Random a) => State StdGen a getAny = State random I put a copy of the code in http://hpaste.org/7768 In short to use the State monad, you just need to care about a couple of details. The type of your functions running in the State Monad must end in `State s a` where `s` is the type of the state and `a` the type of the return value. You have to run it using either runState, execState or evalState. runState will return both the value and the state, execState will return the state and evalState will return just the value. You must use put and get to retrieve and store the State but don't need to care about the details of how the state is passed. As long as your function calls are all part of the same action. I hope it helps. I'm also quite new at Haskell and the terminology used is probably not very accurate. Best regards, Olivier. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080520/f0799462/attachment.htm From derek.a.elkins at gmail.com Tue May 20 12:45:57 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Tue May 20 12:39:23 2008 Subject: [Haskell-cafe] Rotating backdrop (aka learning Haskell) In-Reply-To: <871w3xfj78.fsf@nmd9999.imr.no> References: <20080520081557.GA18833@kierun.org> <871w3xfj78.fsf@nmd9999.imr.no> Message-ID: <1211301957.5514.186.camel@derek-laptop> On Tue, 2008-05-20 at 10:55 +0200, Ketil Malde wrote: > Yann Golanski writes: > > > 1- Get a list out of a file: I managed to do that using the following: > > > > parseImageFile :: FilePath -> IO [String] > > parseImageFile file = do inpStr <- readFile file > > return $ filter (/="") (breaks (=='\n') inpStr) > > > > Nice, simple and I understand what it is doing. > > Can be improved: > > breaks (=='\n') == lines -- easier to read, no? > filter (/="") == filter (not . null) -- more polymorphic, not important here > do x <- expr1 == expr1 >>= return . expr2 > return $ expr2 x -- i.e. "readFile f >>= return . filter (not.null) . lines" do x <- expr1; return $ expr2 x == expr1 >>= return . expr2 == liftM expr2 expr1 -- or fmap (a.k.a. <$>) if you like So, liftM (filter (not . null) . lines) readFile alternatively, filter (not . null) . lines <$> readFile From ryani.spam at gmail.com Tue May 20 13:31:25 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Tue May 20 13:24:47 2008 Subject: [Haskell-cafe] Rotating backdrop (aka learning Haskell) In-Reply-To: <20080520081557.GA18833@kierun.org> References: <20080520081557.GA18833@kierun.org> Message-ID: <2f9b2d30805201031ha65f56cp67bd045f6102e2c0@mail.gmail.com> Rather than golfing your questions (which seems popular), I'll try to give you some concrete answers. First off, I agree with Bulat that this is probably too large of a first project; doing it in pieces seems like it would be a lot simpler. In particular "if the file changes, ..." isn't a requirement I'd put on the project for a "first attempt". And just getting the non-GUI version to work is a good start; then you can go about learning a GUI library, which can be a project all by itself :) 2008/5/20 Yann Golanski : > 2- Get a random element from a list and remove it: Okay, this I > understand less well. I looked at the solutions of problems 23 and 20 > in http://www.haskell.org/haskellwiki/99_questions so there is a > skeleton there. However, my list is IO [String].... Hum, monads. There's nothing tricky about that, though (although 'and remove it' is a bit odd from a Haskeller's point of view; you would instead make a new list without that element). Lets break this out into some a function to solve the problem. I'll leave the implementation to you. removeElement :: [String] -> Int -> (String, [String]) This is a pure function, but you are, as you mentioned, inside IO. But that's no problem; in your higher level code (where you call parseImageFile) you should also be inside IO: main = do images <- parseImageFile path -- now, images :: [String] -- simple! you are living inside of IO here, so you can get at the values returned! n <- getRandomNumber (length images) let (image, rest) = removeElement images n changeDesktop image Note the difference between the lines with "<-" and the line with "let"; "x <- m" takes "m :: IO a" and gives you an "x :: a". Whereas "let x = z" takes "z :: a" and gives "x :: a"; it just labels the result of a non-IO call. Now you just have to write the other functions: getRandomNumber :: Int -> IO Int changeDesktop :: String -> IO () path :: String -- not really a function! To loop, you can write an IO action that calls itself as the last element of the "do" statement. -- ryan From dons at galois.com Tue May 20 13:36:50 2008 From: dons at galois.com (Don Stewart) Date: Tue May 20 13:30:15 2008 Subject: [Haskell-cafe] ByteString.pack behavior In-Reply-To: <694519c50805200647o738e1e87yc7dac8cb531ac73f@mail.gmail.com> References: <48308E31.5080807@fit.vutbr.cz> <20080518202310.GB7494@scytale.galois.com> <48310146.3060700@fit.vutbr.cz> <20080519182206.GB29658@scytale.galois.com> <694519c50805191944h3197ff4fr93455c477541add5@mail.gmail.com> <694519c50805200644h1505acbeh303520f8109152e8@mail.gmail.com> <694519c50805200647o738e1e87yc7dac8cb531ac73f@mail.gmail.com> Message-ID: <20080520173650.GC9426@scytale.galois.com> aslatter: > On Tue, May 20, 2008 at 8:44 AM, Antoine Latter wrote: > > > > It's up on hackage here: > > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/checked > > > > One more thing - there's no "Data" instance for these types. > Presumably it wouldn't be hard to add, I just wasn't familiar with the > class, and the technique (if any) for lifting an instance of Data > through a newtype wasn't immediately obvious form the class interface. With generalised newtype deriving, it should be fine to derive Data and Typeable: {-# LANGUAGE DeriveDataTypeable #-} {-# LANGUAGE GeneralizedNewtypeDeriving #-} module M where import Data.Generics newtype T = T Int deriving (Eq,Ord,Show,Read,Bounded,Enum,Num,Data,Typeable) x :: T x = 1 + 2 -- Don From dpiponi at gmail.com Tue May 20 13:47:30 2008 From: dpiponi at gmail.com (Dan Piponi) Date: Tue May 20 13:40:53 2008 Subject: [Haskell-cafe] one-way monads In-Reply-To: References: Message-ID: <625b74080805201047i3ab1b099p929fec3dc3932d48@mail.gmail.com> On Mon, May 19, 2008 at 10:54 PM, Zsolt SZALAI wrote: > Now, i'm getting familiar with monads, but there is a little discredit > about one-way monads. If someone claims that monads are "one-way" they are probably referring to the fact that it is impossible (without cheating!) to write a function of signature Monad m => m a -> a. So I think there's no 'discredit' here. For any specific monad, m, it's usually possible to write a function m a -> a. But that's a distinct claim. -- Dan From dons at galois.com Tue May 20 13:48:37 2008 From: dons at galois.com (Don Stewart) Date: Tue May 20 13:42:07 2008 Subject: [Haskell-cafe] MD5 performance optimizations, and GHC -via-C producing segfaulting binary In-Reply-To: <5a376f550805200241i3bb57e39sa0cb56e9fb28624b@mail.gmail.com> References: <5a376f550805200241i3bb57e39sa0cb56e9fb28624b@mail.gmail.com> Message-ID: <20080520174837.GD9426@scytale.galois.com> Thanks for taking a look at this. kirby81: > 2008/5/17 Andrew Coppin : > > Hi folks. > > > > OK, try this: > > > > darcs get http://darcs.orphi.me.uk/MyMD5 > > cd MyMD5 > > ghc -O2 --make md5sum > > md5sum > > I've got some time to take a look at the code. It's very nice, > readable and declarative, but obviously not optimized for "raw speed". > There're a few things to do to have a speed-up of 2x, without going "low-level". > > 1) There's a lazyness leak in Pad.hs. The sum in: > else make_block_bs bs0 : work (n + block_size_bytes) bs1 > is not strict. With a very large file (e.g. 100 mb) it means stack overflow. > > [roxas:~/Desktop/test2/MyMD5] kirby% ghc -O2 --make md5sum.hs > > [roxas:~/Desktop/test2/MyMD5] kirby% time ./md5sum ../../jboss-4.2.2.GA.zip > Stack space overflow: current size 8388608 bytes. > Use `+RTS -Ksize' to increase it. > > To solve it just add a bang (!) before the n parameter: > > work !n bs = > > You've got to add {-# LANGUAGE BangPatterns #-} at the top of the file > too. There're solutions that don't imply BangPatterns, and use only > seq, but I like bang patterns! > > Now it works: > [roxas:~/Desktop/test2/MyMD5] kirby% time ./md5sum ../../jboss-4.2.2.GA.zip > E6542028D538BAEC180A96A5D1E6EC3A > 11.958u 0.210s 0:12.19 99.7% 0+0k 0+2io 0pf+0w Good idea. I saw some lazy left folds in there too, which look suspicious. > > 2) make_block_bs is sub-optimal, and very critical to performance. I > decided to use Data.Binary for it (it's also more readable, and you > get rid of the unsafeWrite): > import Data.Binary > import Data.Binary.Get > import Control.Monad > > // ... > > instance Binary Block where > put _ = undefined > get = do > xs <- replicateM 16 getWord32le > return $ Block $ listArray (0, 15) xs > > make_block_bs :: B.ByteString -> Block > make_block_bs = decode > > Now we are getting faster: > [roxas:~/Desktop/test2/MyMD5] kirby% time ./md5sum ../../jboss-4.2.2.GA.zip > E6542028D538BAEC180A96A5D1E6EC3A > 8.063u 0.174s 0:08.23 100.0% 0+0k 0+0io 0pf+0w Definitely a good idea. > 3) You are doing a lot of access to fields of a strict data type > (State). You can at least ask the compiler to help you a bit with > -funbox-strict-fields. > > Now we have: > [roxas:~/Desktop/test2/MyMD5] kirby% time ./md5sum ../../jboss-4.2.2.GA.zip > E6542028D538BAEC180A96A5D1E6EC3A > 6.780u 0.133s 0:06.91 100.0% 0+0k 0+1io 0pf+0w > > We have got a good, nearly 2x, speed-up with very few optimizations, > and we run in a very small constant amount of memory. Great. > > Probably compiling with -fvia-C could help even more, but strangely: > > [roxas:~/Desktop/test2/MyMD5] kirby% ghc -fvia-C -funbox-strict-fields > -O2 --make md5sum.hs > [roxas:~/Desktop/test2/MyMD5] kirby% time ./md5sum ../../jboss-4.2.2.GA.zip > Segmentation fault > > Is this supposed to happen? There're no "unsafe" functions or imports > used in the program. Maybe a bug in GHC? That could be a gcc bug, in fact. Can you provide the final source? Does changing the gcc optimisation level help? (i.e. -fvia-C -optc-O2 ) Andrew, I hope you look carefully at the suggestions here, and use them to improve the code you were working on. -- Don From andrewcoppin at btinternet.com Tue May 20 14:44:10 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Tue May 20 14:49:09 2008 Subject: [Haskell-cafe] Performance: MD5 In-Reply-To: <5a376f550805191522u61c577e7y5da24dc2b625c8c9@mail.gmail.com> References: <482EF0EF.2090207@btinternet.com> <4830161F.4050403@btinternet.com> <659443196.20080518155652@gmail.com> <48301C22.7020902@btinternet.com> <5a376f550805191522u61c577e7y5da24dc2b625c8c9@mail.gmail.com> Message-ID: <48331BFA.3020501@btinternet.com> Salvatore Insalaco wrote: > Hi Andrew, > just a profiling suggestion: did you try to use the SCC cost-centre > annotations for profiling? > If you want to know precisely what takes 60% of time, you can try: > bn = {-# SCC "IntegerConversion" #-} 4 * fromIntegral wn > b0 = {-# SCC "ByteStringIndexing" #-} B.index bi (bn+0) > b1 = {-# SCC "ByteStringIndexing" #-} B.index bi (bn+1) > b2 = {-# SCC "ByteStringIndexing" #-} B.index bi (bn+2) > b3 = {-# SCC "ByteStringIndexing" #-} B.index bi (bn+3) > w = foldl' (\w b -> shiftL w 8 .|. fromIntegral b) 0 [b3,b2,b1,b0] > in {-# SCC "ArrayWriting" #-} unsafeWrite temp wn w > > In profiling the time of all expressions with the same SCC "name" will > be summed. > You can get more information about SCC here: > http://www.haskell.org/ghc/docs/latest/html/users_guide/profiling.html#cost-centres > OK, I'll give that a try... > One advice: I've seen various md5sum implementations in C, all using > about the same algorithms and data structures, and they performed even > with 10x time differences between them; md5summing fast is not a > really simple problem. If I were you I would drop the comparison with > ultra-optimized C and concentrate on "does my > high-level-good-looking-super-readable implementation perform > acceptably?". > > What "acceptably" means is left as an exercise to the reader. > Well, so long as it can hash 500 MB of data in a few minutes without using absurd amounts of RAM, that'll do for me. ;-) [I actually wanted to do this for a project at work. When I discovered that none of the available Haskell implementations are fast enough, I tried to write my own. But that wasn't fast enough either. So I ended up being forced to call md5sum.exe and attempt to parse its output. Obviously having a real Haskell function would be infinitely more portable and convinient...] From andrewcoppin at btinternet.com Tue May 20 14:55:48 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Tue May 20 14:49:19 2008 Subject: [Haskell-cafe] MD5 performance optimizations In-Reply-To: <20080520174837.GD9426@scytale.galois.com> References: <5a376f550805200241i3bb57e39sa0cb56e9fb28624b@mail.gmail.com> <20080520174837.GD9426@scytale.galois.com> Message-ID: <48331EB4.9010000@btinternet.com> Don Stewart wrote: > Andrew, I hope you look carefully at the suggestions here, and use them > to improve the code you were working on. > Indeed, this is just the sort of stuff I was hoping to get... [Top marks for spotting the laziness leak in "pad" BTW! I totally missed that.] While I'm here, can I just clarify *exactly* what -funbox-strict-fields actually does? I was under the impression that if you have a single-constructor type with all strict fields, GHC would automatically try to avoid boxing and unboxing it. However, the existence of this flag seems to indicate that it only performs this particular optimisation if you ask for it. But on the third hand, turning this flag on or off makes no measurable performance difference. (At least, in the tests I did. Maybe that's because it was swamped by all the other inefficiencies mentioned?) Some clarification? From dons at galois.com Tue May 20 14:57:34 2008 From: dons at galois.com (Don Stewart) Date: Tue May 20 14:51:01 2008 Subject: [Haskell-cafe] Performance: MD5 In-Reply-To: <48331BFA.3020501@btinternet.com> References: <482EF0EF.2090207@btinternet.com> <4830161F.4050403@btinternet.com> <659443196.20080518155652@gmail.com> <48301C22.7020902@btinternet.com> <5a376f550805191522u61c577e7y5da24dc2b625c8c9@mail.gmail.com> <48331BFA.3020501@btinternet.com> Message-ID: <20080520185734.GG9426@scytale.galois.com> andrewcoppin: > Salvatore Insalaco wrote: > >Hi Andrew, > >just a profiling suggestion: did you try to use the SCC cost-centre > >annotations for profiling? > >If you want to know precisely what takes 60% of time, you can try: > > bn = {-# SCC "IntegerConversion" #-} 4 * fromIntegral wn > > b0 = {-# SCC "ByteStringIndexing" #-} B.index bi (bn+0) > > b1 = {-# SCC "ByteStringIndexing" #-} B.index bi (bn+1) > > b2 = {-# SCC "ByteStringIndexing" #-} B.index bi (bn+2) > > b3 = {-# SCC "ByteStringIndexing" #-} B.index bi (bn+3) > > w = foldl' (\w b -> shiftL w 8 .|. fromIntegral b) 0 > > [b3,b2,b1,b0] > > in {-# SCC "ArrayWriting" #-} unsafeWrite temp wn w > > > >In profiling the time of all expressions with the same SCC "name" > >will > >be summed. > >You can get more information about SCC here: > >http://www.haskell.org/ghc/docs/latest/html/users_guide/profiling.html#cost-centres > > > > OK, I'll give that a try... > > >One advice: I've seen various md5sum implementations in C, all using > >about the same algorithms and data structures, and they performed > >even > >with 10x time differences between them; md5summing fast is not a > >really simple problem. If I were you I would drop the comparison with > >ultra-optimized C and concentrate on "does my > >high-level-good-looking-super-readable implementation perform > >acceptably?". > > > >What "acceptably" means is left as an exercise to the reader. > > > > Well, so long as it can hash 500 MB of data in a few minutes without > using absurd amounts of RAM, that'll do for me. ;-) > > [I actually wanted to do this for a project at work. When I > discovered that none of the available Haskell implementations are > fast enough, How hard did you look? import System.Environment import Data.Digest.OpenSSL.MD5 import System.IO.Posix.MMap main = do [f] <- getArgs putStrLn . md5sum =<< mmapFile f Take the md5 of a 600M file: $ time ./A /home/dons/tmp/600M 24a04fdf3f629a42b5baed52ed793a51 ./A /home/dons/tmp/600M 3.61s user 1.65s system 20% cpu 25.140 total Easy. -- Don From dons at galois.com Tue May 20 14:59:00 2008 From: dons at galois.com (Don Stewart) Date: Tue May 20 14:52:26 2008 Subject: [Haskell-cafe] MD5 performance optimizations In-Reply-To: <48331EB4.9010000@btinternet.com> References: <5a376f550805200241i3bb57e39sa0cb56e9fb28624b@mail.gmail.com> <20080520174837.GD9426@scytale.galois.com> <48331EB4.9010000@btinternet.com> Message-ID: <20080520185900.GH9426@scytale.galois.com> andrewcoppin: > Don Stewart wrote: > >Andrew, I hope you look carefully at the suggestions here, and use them > >to improve the code you were working on. > > > > Indeed, this is just the sort of stuff I was hoping to get... [Top marks > for spotting the laziness leak in "pad" BTW! I totally missed that.] > > While I'm here, can I just clarify *exactly* what -funbox-strict-fields > actually does? If in doubt, ask the user's guide: http://www.haskell.org/ghc/docs/latest/html/users_guide/pragmas.html#unpack-pragma -- Don From andrewcoppin at btinternet.com Tue May 20 15:05:52 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Tue May 20 15:31:35 2008 Subject: [Haskell-cafe] Re: MD5 performance optimizations, and GHC -via-C producing segfaulting binary In-Reply-To: <5a376f550805200241i3bb57e39sa0cb56e9fb28624b@mail.gmail.com> References: <5a376f550805200241i3bb57e39sa0cb56e9fb28624b@mail.gmail.com> Message-ID: <48332110.7020404@btinternet.com> Salvatore Insalaco wrote: > I've got some time to take a look at the code. It's very nice, > readable and declarative, but obviously not optimized for "raw speed". > There're a few things to do to have a speed-up of 2x, without going "low-level". > You have my individed attention... > 1) There's a lazyness leak in Pad.hs. The sum in: > else make_block_bs bs0 : work (n + block_size_bytes) bs1 > is not strict. With a very large file (e.g. 100 mb) it means stack overflow. > Oops! Well spotted... > To solve it just add a bang (!) before the n parameter: > > work !n bs = > > You've got to add {-# LANGUAGE BangPatterns #-} at the top of the file > too. There're solutions that don't imply BangPatterns, and use only > seq, but I like bang patterns! > Ah, so *that's* what bang patterns do? > 2) make_block_bs is sub-optimal, and very critical to performance. Yeah, so I see. (60% time spent here... ouch!) I'll bet that's where C is beating me... > I decided to use Data.Binary for it I'm not familiar with that library (i.e. what it does or how you use it). > import Data.Binary > import Data.Binary.Get > import Control.Monad > > // ... > > instance Binary Block where > put _ = undefined > get = do > xs <- replicateM 16 getWord32le > return $ Block $ listArray (0, 15) xs > > make_block_bs :: B.ByteString -> Block > make_block_bs = decode > Mmm, OK. Doesn't look too bad... > 3) You are doing a lot of access to fields of a strict data type > (State). You can at least ask the compiler to help you a bit with > -funbox-strict-fields. > I did try that, but it didn't seem to make any difference for me. [Maybe it does now because of your other improvements? Which version of GHC and which platform are you running on? I'm GHC 6.8.2 on Windows...] > We have got a good, nearly 2x, speed-up with very few optimizations, > and we run in a very small constant amount of memory. > I'm liking the sound of that. :-D > Probably compiling with -fvia-C could help even more ...oh yeah, that's no longer default for -O2. I forgot about that! > but strangely: > > Segmentation fault > > Is this supposed to happen? There're no "unsafe" functions or imports > used in the program. Maybe a bug in GHC? > GAH! o_O That's not good(tm)... Any chance you could email me a Darcs patch (or 2 seperate ones?) I'll add it to the repo on my website, and test to see what numbers I get on my PC. From necrobious at gmail.com Tue May 20 15:38:14 2008 From: necrobious at gmail.com (Kirk Peterson) Date: Tue May 20 15:31:49 2008 Subject: [Haskell-cafe] whhaskell on osx 10.5 Message-ID: I had a difficult time getting wxhaskell installed and working on a mac running os x 10.5. I did a quick write up of the process I got working here: http://necrobious.blogspot.com/2008/05/wxhaskell-go-go.html Im pretty new to haskell, so if if you see anything that needs correcting please let me know, hope this helps cheers, -kirk From bulat.ziganshin at gmail.com Tue May 20 16:01:00 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue May 20 15:57:00 2008 Subject: [Haskell-cafe] Re: MD5 performance optimizations, and GHC -via-C producing segfaulting binary In-Reply-To: <48332110.7020404@btinternet.com> References: <5a376f550805200241i3bb57e39sa0cb56e9fb28624b@mail.gmail.com> <48332110.7020404@btinternet.com> Message-ID: <12951033.20080521000100@gmail.com> Hello Andrew, Tuesday, May 20, 2008, 11:05:52 PM, you wrote: >> -funbox-strict-fields. >> > I did try that, but it didn't seem to make any difference for me. [Maybe it may be that ghc just not recompiled program when you supplied this switch. as i wrote, this switch by itself made your original program 1.5x faster on my box. try to delete .o/.exe before rebuilding and, without this switch representation for !Int32 is the same as for Int32 - only difference is that when data is assigned to such field they are evaluated first (and then boxed) it is not enabled by default, because for *non-primitive* datatypes such as B below automatic unboxing of strict fields of this type may decrease sharing and thus memory/performance. imagine for example: data A = A !B !B data B = B !Int !Int !Int !Int !Int b = B 1 1 1 1 1 a = A b b jhc automatically unboxes strict fields of primitive datatypes, which is guaranteed to provide only positive effects. may be somesay the same will be added to ghc -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From kirby81 at gmail.com Tue May 20 16:12:08 2008 From: kirby81 at gmail.com (Salvatore Insalaco) Date: Tue May 20 16:05:31 2008 Subject: [Haskell-cafe] MD5 performance optimizations, and GHC -via-C producing segfaulting binary In-Reply-To: <20080520174837.GD9426@scytale.galois.com> References: <5a376f550805200241i3bb57e39sa0cb56e9fb28624b@mail.gmail.com> <20080520174837.GD9426@scytale.galois.com> Message-ID: <5a376f550805201312l5ff5ff40g7f84e776ba05cf6c@mail.gmail.com> 2008/5/20 Don Stewart : >> >> Probably compiling with -fvia-C could help even more, but strangely: >> >> [roxas:~/Desktop/test2/MyMD5] kirby% ghc -fvia-C -funbox-strict-fields >> -O2 --make md5sum.hs >> [roxas:~/Desktop/test2/MyMD5] kirby% time ./md5sum ../../jboss-4.2.2.GA.zip >> Segmentation fault >> >> Is this supposed to happen? There're no "unsafe" functions or imports >> used in the program. Maybe a bug in GHC? > > That could be a gcc bug, in fact. Can you provide the final source? > Does changing the gcc optimisation level help? (i.e. -fvia-C -optc-O2 ) I tried with and without gcc optimizations, but it always segfaults. It happened to me even before my optimizations. I've got GHC 6.8.2 on Mac OS X 10.5.2, GCC 4.0.1. -fvia-C works well for other libraries and applications, so I don't think it's a problem of my specific setting. Salvatore -------------- next part -------------- A non-text attachment was scrubbed... Name: MyMD5.tar.gz Type: application/x-gzip Size: 2471 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080520/ac4a29e6/MyMD5.tar.bin From dons at galois.com Tue May 20 16:13:14 2008 From: dons at galois.com (Don Stewart) Date: Tue May 20 16:06:40 2008 Subject: [Haskell-cafe] Re: MD5 performance optimizations, and GHC -via-C producing segfaulting binary In-Reply-To: <12951033.20080521000100@gmail.com> References: <5a376f550805200241i3bb57e39sa0cb56e9fb28624b@mail.gmail.com> <48332110.7020404@btinternet.com> <12951033.20080521000100@gmail.com> Message-ID: <20080520201314.GI9426@scytale.galois.com> bulat.ziganshin: > Hello Andrew, > > Tuesday, May 20, 2008, 11:05:52 PM, you wrote: > > >> -funbox-strict-fields. > >> > > > I did try that, but it didn't seem to make any difference for me. [Maybe > > it may be that ghc just not recompiled program when you supplied this > switch. as i wrote, this switch by itself made your original program > 1.5x faster on my box. try to delete .o/.exe before rebuilding > > and, without this switch representation for !Int32 is the same as for > Int32 - only difference is that when data is assigned to such field > they are evaluated first (and then boxed) > > it is not enabled by default, because for *non-primitive* datatypes > such as B below automatic unboxing of strict fields of this type may > decrease sharing and thus memory/performance. imagine for example: > > data A = A !B !B > data B = B !Int !Int !Int !Int !Int > > b = B 1 1 1 1 1 > a = A b b > > jhc automatically unboxes strict fields of primitive datatypes, which > is guaranteed to provide only positive effects. may be somesay the > same will be added to ghc I'm confused. GHC of course unboxes strict fields of primitive data types. {-# OPTIONS -O2 -fvia-C -optc-O2 -funbox-strict-fields #-} data A = A !B !B data B = B !Int !Int !Int !Int !Int b = B 1 2 3 4 5 a = A b b go :: Int -> A go 0 = a go n = go (n-1) main = print $ case go 10 of A (B a b c d e) (B a' b' c' d' e') -> a + b + c + d + e + a' + b' + c' + d' + e' For example, go compiles to: $wgo :: Int# -> (# Int#, Int#, Int#, Int#, Int#, Int#, Int#, Int#, Int#, Int# #) $wgo = \ (ww_svf :: Int#) -> case ww_svf of ds_Xmw { __DEFAULT -> $wgo (-# ds_Xmw 1); 0 -> (# 1, 2, 3, 4, 5, 1, 2, 3, 4, 5 #) Values are passed in registers, the structures are entirely unpacked into registers or stack for return. Were you not aware of this Bulat? -- Don From allbery at ece.cmu.edu Tue May 20 16:23:33 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Tue May 20 16:16:57 2008 Subject: [Haskell-cafe] Re: MD5 performance optimizations, and GHC -via-C producing segfaulting binary In-Reply-To: <20080520201314.GI9426@scytale.galois.com> References: <5a376f550805200241i3bb57e39sa0cb56e9fb28624b@mail.gmail.com> <48332110.7020404@btinternet.com> <12951033.20080521000100@gmail.com> <20080520201314.GI9426@scytale.galois.com> Message-ID: On May 20, 2008, at 16:13 , Don Stewart wrote: > bulat.ziganshin: >> Hello Andrew, >> >> Tuesday, May 20, 2008, 11:05:52 PM, you wrote: >> >>>> -funbox-strict-fields. >>>> >> >>> I did try that, but it didn't seem to make any difference for me. >>> [Maybe >> >> jhc automatically unboxes strict fields of primitive datatypes, which >> is guaranteed to provide only positive effects. may be somesay the >> same will be added to ghc > > I'm confused. GHC of course unboxes strict fields of primitive data > types. > > {-# OPTIONS -O2 -fvia-C -optc-O2 -funbox-strict-fields #-} I think "automatically" means "without -funbox-strict-fields".... -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From kirby81 at gmail.com Tue May 20 16:24:20 2008 From: kirby81 at gmail.com (Salvatore Insalaco) Date: Tue May 20 16:17:43 2008 Subject: [Haskell-cafe] Re: MD5 performance optimizations, and GHC -via-C producing segfaulting binary In-Reply-To: <48332110.7020404@btinternet.com> References: <5a376f550805200241i3bb57e39sa0cb56e9fb28624b@mail.gmail.com> <48332110.7020404@btinternet.com> Message-ID: <5a376f550805201324t350f9af2q2fab48b7eadeea8a@mail.gmail.com> 2008/5/20 Andrew Coppin : > Ah, so *that's* what bang patterns do? Exactly. If you have a pattern (even a simple one like 'n'), and you prefix it with a bang (!), the function will force its evaluation. >> 2) make_block_bs is sub-optimal, and very critical to performance. > > Yeah, so I see. (60% time spent here... ouch!) I'll bet that's where C is > beating me... Maybe that's a bit optimistic, but it's a start :). > >> I decided to use Data.Binary for it > > I'm not familiar with that library (i.e. what it does or how you use it). It's a library to serialize / deserialize haskell values. It uses ByteStrings, and it's very fast. I suggest to take a look at it (it's on Hackage). > I did try that, but it didn't seem to make any difference for me. [Maybe it > does now because of your other improvements? Which version of GHC and which > platform are you running on? I'm GHC 6.8.2 on Windows...] If you recompiled the executable correctly, maybe you were doing profiling? Profiling slows some simple operations so much, that the benefits of a low-level optimization like this can be lost. Salvatore From isaacdupree at charter.net Tue May 20 16:31:09 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Tue May 20 16:24:26 2008 Subject: [Haskell-cafe] Re: MD5 performance optimizations, and GHC -via-C producing segfaulting binary In-Reply-To: <20080520201314.GI9426@scytale.galois.com> References: <5a376f550805200241i3bb57e39sa0cb56e9fb28624b@mail.gmail.com> <48332110.7020404@btinternet.com> <12951033.20080521000100@gmail.com> <20080520201314.GI9426@scytale.galois.com> Message-ID: <4833350D.2030006@charter.net> Don Stewart wrote: > I'm confused. GHC of course unboxes strict fields of primitive data types. > > {-# OPTIONS -O2 -fvia-C -optc-O2 -funbox-strict-fields #-} ... but only when you give -funbox-strict-fields, as there, or UNPACK. The point is that it never loses sharing to unbox a strict Int field [1], so it should do that with -O, even without either of the above overrides. [1] I'm not sure if this is true... if it has to rebox the Int, you get another copy floating around, not the original, right? -Isaac From dons at galois.com Tue May 20 16:36:12 2008 From: dons at galois.com (Don Stewart) Date: Tue May 20 16:29:42 2008 Subject: [Haskell-cafe] Re: MD5 performance optimizations, and GHC -via-C producing segfaulting binary In-Reply-To: <4833350D.2030006@charter.net> References: <5a376f550805200241i3bb57e39sa0cb56e9fb28624b@mail.gmail.com> <48332110.7020404@btinternet.com> <12951033.20080521000100@gmail.com> <20080520201314.GI9426@scytale.galois.com> <4833350D.2030006@charter.net> Message-ID: <20080520203612.GJ9426@scytale.galois.com> isaacdupree: > Don Stewart wrote: > >I'm confused. GHC of course unboxes strict fields of > >primitive data types. > > > > {-# OPTIONS -O2 -fvia-C -optc-O2 -funbox-strict-fields > > #-} > > ... but only when you give -funbox-strict-fields, as there, > or UNPACK. The point is that it never loses sharing to unbox > a strict Int field [1], so it should do that with -O, even > without either of the above overrides. > > [1] I'm not sure if this is true... if it has to rebox the > Int, you get another copy floating around, not the original, > right? See section 8.12.10. UNPACK pragma: "if the T constructor is scrutinised and the floats passed to a non-strict function for example, they will have to be reboxed" That said, the strictness analyser is beefy enough, and strict data structures commone enough, that this seems to almost ubiquitously be a win. Enabling it at -O or -O2 makes perfect sense. -- Don From andrewcoppin at btinternet.com Tue May 20 16:05:51 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Tue May 20 16:32:09 2008 Subject: [Haskell-cafe] MD5 performance optimizations In-Reply-To: <20080520185900.GH9426@scytale.galois.com> References: <5a376f550805200241i3bb57e39sa0cb56e9fb28624b@mail.gmail.com> <20080520174837.GD9426@scytale.galois.com> <48331EB4.9010000@btinternet.com> <20080520185900.GH9426@scytale.galois.com> Message-ID: <48332F1F.70408@btinternet.com> Don Stewart wrote: > andrewcoppin: > >> While I'm here, can I just clarify *exactly* what -funbox-strict-fields >> actually does? >> > > If in doubt, ask the user's guide: > > http://www.haskell.org/ghc/docs/latest/html/users_guide/pragmas.html#unpack-pragma > ...so making a field strict causes it to be automatically forced when the constructor is forced, but doesn't actually unbox it? So there's still a level of indirection, and no register allocation? From andrewcoppin at btinternet.com Tue May 20 16:09:39 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Tue May 20 16:32:19 2008 Subject: [Haskell-cafe] Re: MD5 performance optimizations In-Reply-To: <12951033.20080521000100@gmail.com> References: <5a376f550805200241i3bb57e39sa0cb56e9fb28624b@mail.gmail.com> <48332110.7020404@btinternet.com> <12951033.20080521000100@gmail.com> Message-ID: <48333003.9060803@btinternet.com> Bulat Ziganshin wrote: > Hello Andrew, > > Tuesday, May 20, 2008, 11:05:52 PM, you wrote: > > >>> -funbox-strict-fields. >>> >>> > > >> I did try that, but it didn't seem to make any difference for me. [Maybe >> > > it may be that ghc just not recompiled program when you supplied this > switch. > Possibly. I notice that adding *some* switches makes GHC recompile everything, while others don't. [It's probably documented in the manual somewhere...] > and, without this switch representation for !Int32 is the same as for > Int32 - only difference is that when data is assigned to such field > they are evaluated first (and then boxed) > Right, OK - so strict evaluation, but some bitpattern in RAM. > it is not enabled by default, because for *non-primitive* datatypes > such as B below automatic unboxing of strict fields of this type may > decrease sharing and thus memory/performance. Yeah, I can imagine... From bulat.ziganshin at gmail.com Tue May 20 16:43:47 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue May 20 16:46:45 2008 Subject: [Haskell-cafe] Re: MD5 performance optimizations, and GHC -via-C producing segfaulting binary In-Reply-To: <20080520201314.GI9426@scytale.galois.com> References: <5a376f550805200241i3bb57e39sa0cb56e9fb28624b@mail.gmail.com> <48332110.7020404@btinternet.com> <12951033.20080521000100@gmail.com> <20080520201314.GI9426@scytale.galois.com> Message-ID: <581592749.20080521004347@gmail.com> Hello Don, Wednesday, May 21, 2008, 12:13:14 AM, you wrote: >> it is not enabled by default, because for *non-primitive* datatypes > I'm confused. GHC of course unboxes strict fields of primitive data types. > {-# OPTIONS -O2 -fvia-C -optc-O2 -funbox-strict-fields #-} it is not enabled by default... -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From bulat.ziganshin at gmail.com Tue May 20 16:50:04 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue May 20 16:47:20 2008 Subject: [Haskell-cafe] Re: MD5 performance optimizations In-Reply-To: <48333003.9060803@btinternet.com> References: <5a376f550805200241i3bb57e39sa0cb56e9fb28624b@mail.gmail.com> <48332110.7020404@btinternet.com> <12951033.20080521000100@gmail.com> <48333003.9060803@btinternet.com> Message-ID: <669314024.20080521005004@gmail.com> Hello Andrew, Wednesday, May 21, 2008, 12:09:39 AM, you wrote: > Right, OK - so strict evaluation, but some bitpattern in RAM. yes. in particular this allows to designate fields that should de initialized: data A = A {a :: Int, b :: !Int} main = print A{} >> it is not enabled by default, because for *non-primitive* datatypes >> such as B below automatic unboxing of strict fields of this type may >> decrease sharing and thus memory/performance. > Yeah, I can imagine... sometime i've seriously optimized my program by removing this switch and adding manual unboxing directives to the sources. it will be great if ghc will catch jhc here -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From dons at galois.com Tue May 20 17:02:49 2008 From: dons at galois.com (Don Stewart) Date: Tue May 20 16:56:19 2008 Subject: [Haskell-cafe] Re: MD5 performance optimizations In-Reply-To: <669314024.20080521005004@gmail.com> References: <5a376f550805200241i3bb57e39sa0cb56e9fb28624b@mail.gmail.com> <48332110.7020404@btinternet.com> <12951033.20080521000100@gmail.com> <48333003.9060803@btinternet.com> <669314024.20080521005004@gmail.com> Message-ID: <20080520210249.GK9426@scytale.galois.com> bulat.ziganshin: > Hello Andrew, > > Wednesday, May 21, 2008, 12:09:39 AM, you wrote: > > > Right, OK - so strict evaluation, but some bitpattern in RAM. > > yes. in particular this allows to designate fields that should de > initialized: > > data A = A {a :: Int, b :: !Int} > main = print A{} > > >> it is not enabled by default, because for *non-primitive* datatypes > >> such as B below automatic unboxing of strict fields of this type may > >> decrease sharing and thus memory/performance. > > > Yeah, I can imagine... > > sometime i've seriously optimized my program by removing this switch > and adding manual unboxing directives to the sources. it will be great > if ghc will catch jhc here Would you like to file a feature request? http://hackage.haskell.org/trac/ghc/newticket?type=bug Particularly if you have an example where JHC has done a better job optimising some simple example. So far I've seen no ticke Unless tickets are opened, progress will not be made. -- Don From marco-oweber at gmx.de Tue May 20 17:23:57 2008 From: marco-oweber at gmx.de (Marc Weber) Date: Tue May 20 17:17:22 2008 Subject: [Haskell-cafe] whhaskell on osx 10.5 In-Reply-To: References: Message-ID: <20080520212357.GA10095@gmx.de> On Tue, May 20, 2008 at 12:38:14PM -0700, Kirk Peterson wrote: > I had a difficult time getting wxhaskell installed and working on a > mac running os x 10.5. I did a quick write up of the process I got > working here: > > http://necrobious.blogspot.com/2008/05/wxhaskell-go-go.html $ cd ../samples/wx $ ghc -package wx -o helloworld HelloWorld.hs $ /opt/local/bin/macosx-app -v helloworld $ open helloworld.app I've never used a Mac.. Why do you run macosx-app ? Doesn't $ ./helloworld work? Marc Weber From conal at conal.net Tue May 20 17:25:51 2008 From: conal at conal.net (Conal Elliott) Date: Tue May 20 17:19:16 2008 Subject: [Haskell-cafe] RealFloat constraint on Complex type Message-ID: GHC's (maybe Haskell98's?) Complex type is defined with a RealFloat constraint on type type itself, rather than on some of the instances and functions: data (RealFloat a) => Complex a = !a :+ !a I think the practice of constraint in type definitions is generally discouraged, and I'm wondering if there are reasons other than history for having the constraint here. Is removing it on the table for Haskell'? I just got bit by what I think is a typical problem. I added a VectorSpace instance for 'Complex a' and discovered that my 'a' must be in RealFloat, even though I use only zero, addition, subtraction, and scaling. I suspect this gripe has been raised before ... Thanks, - Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080520/e8efce5a/attachment.htm From alexander.fuchs at uni-koblenz.de Tue May 20 17:37:46 2008 From: alexander.fuchs at uni-koblenz.de (Alexander Fuchs) Date: Tue May 20 17:31:11 2008 Subject: [Haskell-cafe] FD Int Constraint Solving Library Message-ID: <483344AA.6070707@uni-koblenz.de> Hi, I was wondering if someone could point me to a Haskell library for constraint solving over finite domains with integer arithmetic, i.e. something like FaCiLe ( http://www.recherche.enac.fr/log/facile/ ). A Haskell FF interface to such a library would probably be fine as well. It seems to me that such a library/wrapper should exist, but I couldn't find one. Thanks, Alexander From tux_rocker at reinier.de Tue May 20 17:47:13 2008 From: tux_rocker at reinier.de (Reinier Lamers) Date: Tue May 20 17:40:46 2008 Subject: [Haskell-cafe] whhaskell on osx 10.5 In-Reply-To: <20080520212357.GA10095@gmx.de> References: <20080520212357.GA10095@gmx.de> Message-ID: <200805202347.13925.tux_rocker@reinier.de> Op Tuesday 20 May 2008 23:23:57 schreef Marc Weber: > On Tue, May 20, 2008 at 12:38:14PM -0700, Kirk Peterson wrote: > > I had a difficult time getting wxhaskell installed and working on a > > mac running os x 10.5. I did a quick write up of the process I got > > working here: > > > > http://necrobious.blogspot.com/2008/05/wxhaskell-go-go.html > > $ cd ../samples/wx > $ ghc -package wx -o helloworld HelloWorld.hs > $ /opt/local/bin/macosx-app -v helloworld > $ open helloworld.app > > I've never used a Mac.. Why do you run macosx-app ? > > Doesn't > $ ./helloworld > work? It works, but it doesn't look right. The nice colory drop-like minimization/maximization buttons are missing, for example. At least, that's my experience using wxHaskell on the Mac (OS X 10.4). Reinier From necrobious at gmail.com Tue May 20 17:50:20 2008 From: necrobious at gmail.com (Kirk Peterson) Date: Tue May 20 17:43:42 2008 Subject: [Haskell-cafe] whhaskell on osx 10.5 In-Reply-To: <20080520212357.GA10095@gmx.de> References: <20080520212357.GA10095@gmx.de> Message-ID: just running: $ ./helloworld will work fine on windows and linux, under mac os, I ran into issues with window focus and click events not firing. Upon looking further, I found this page on the wxhaskell site: http://wxhaskell.sourceforge.net/building-macosx.html which explains the need to the macosx-app step in compiling a whhaskell app, and why I include it in my example. Hope this helps. cheers, -kirk On Tue, May 20, 2008 at 2:23 PM, Marc Weber wrote: > On Tue, May 20, 2008 at 12:38:14PM -0700, Kirk Peterson wrote: >> I had a difficult time getting wxhaskell installed and working on a >> mac running os x 10.5. I did a quick write up of the process I got >> working here: >> >> http://necrobious.blogspot.com/2008/05/wxhaskell-go-go.html > $ cd ../samples/wx > $ ghc -package wx -o helloworld HelloWorld.hs > $ /opt/local/bin/macosx-app -v helloworld > $ open helloworld.app > > I've never used a Mac.. Why do you run macosx-app ? > > Doesn't > $ ./helloworld > work? > > Marc Weber > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From qdunkan at gmail.com Tue May 20 18:34:07 2008 From: qdunkan at gmail.com (Evan Laforge) Date: Tue May 20 18:27:30 2008 Subject: [Haskell-cafe] status of dynamic loading Message-ID: <2518b95d0805201534g582fa2c9x3e310737cd20740b@mail.gmail.com> I have an application where I'd like to load and run code at runtime. As far as I know, the possibilities are: Use hs-plugins. I'm not sure if this still works on modern ghc, or if it works on my platform (darwin intel), but I managed to get this compiled after "fixing" a use of STArray whose arity apparently changed, but I probably broke it because now I get "Error in array index" all the time. I gather Austin Seipp has been doing some work on this. Is there a newer version that should work? An easy fix for the error? Then there's the ghc api, which I gather is seen as the way forward from hs-plugins, saving it from hi-parsing brittleness and platform specific breakage. I think Yi uses this, apparently in in the Shim package. I poked around some, but wasn't too clear to me what was going on, if I was looking in the right place, and if this is a reasonable way forward. lambdabot also appears to have its own dynamic loading mechanism, I haven't looked at the source enough yet to understand what it's doing. Maybe there's some documentation out there. The low-tech solution, used by xmonad, would be to pass the "dynamic" code to main and just recompile the app for each instance, passing in an instance specific set of config arguments. Of course, this isn't really dynamic at all, and compiling all the various instances could be clunky and awkward, but I know it works and could possibly be reasonable if I also write my own little language for the stuff that really has to be dynamic (anyone got one of these? lisplike would be easy and ok, an haskell subset might be nicer... I would like to avoid having *two* languages to write extensions in). The last solution I can think of is to export an RPC API instead of dynamically loading code. The difficulty here is coming up with a vocabulary that can be flattened and shipped to another program without becoming an excessive maintenance issue or being too inflexible. All in all, the dynamic loading approach of hs-plugins seems like the easiest and most flexible, provided I can get its staged type checking. Before I go trying to hack hs-plugins into working, or poking around inside yi or lambdabot, can anyone point me at some documentation, resources, advice, etc.? Thanks! From alfonso.acosta at gmail.com Tue May 20 19:20:37 2008 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Tue May 20 19:14:12 2008 Subject: [Haskell-cafe] Re: Link to Hierarchical-libraries documentation generated with haddock 2.0? In-Reply-To: <6a7c66fc0805191745g1bf94916i37d3824e31e7b3ae@mail.gmail.com> References: <6a7c66fc0805191745g1bf94916i37d3824e31e7b3ae@mail.gmail.com> Message-ID: <6a7c66fc0805201620l910458cyf6c8fe447db1ad4b@mail.gmail.com> Since nobody answered I just compiled ghc-6.8.2 with haddock2 and put the resulting documentation at http://code.haskell.org/~fons/libraries.html-haddock2.tgz On Tue, May 20, 2008 at 2:45 AM, Alfonso Acosta wrote: > Hi all, > > GHC's documentation page [1] only points to hierarchical-libraries > documentation generated by haddock-0.8 [2]. > > I need the 2.0 version in order to get links in the documentation of > the project I'm working on (which needs haddock 2.0 due to the use of > quite a few GHC extensions). > > Before I proceed to generate them myself, has anyone done it already? > (I guess that must be the case since HackageDB users haddock 2.0 and > gets all the links right) > > I would be more than happy to just click a link instead :) > > Either way, I think it would be a good idea to provide an alternative > link to the 2.0 version. > > > Thanks, > > Fons > > > [1] http://www.haskell.org/ghc/documentation.html > [2] http://www.haskell.org/ghc/docs/latest/libraries.html.tar.gz > From thomas.dubuisson at gmail.com Tue May 20 19:40:15 2008 From: thomas.dubuisson at gmail.com (Thomas M. DuBuisson) Date: Tue May 20 19:30:19 2008 Subject: [Haskell-cafe] Performance: MD5 In-Reply-To: <48331BFA.3020501@btinternet.com> References: <482EF0EF.2090207@btinternet.com> <4830161F.4050403@btinternet.com> <659443196.20080518155652@gmail.com> <48301C22.7020902@btinternet.com> <5a376f550805191522u61c577e7y5da24dc2b625c8c9@mail.gmail.com> <48331BFA.3020501@btinternet.com> Message-ID: <1211326816.2679.5.camel@Clunker> Andrew, What is "fast enough"? My informal understanding of the implementations are: 1) Unoptimized [Word8] implementations (constant space, two or three orders of magnatude slower than C) 2) Bindings to 'C' routines (typically O(n) space due to strict ByteStrings and no split out of initialContext/md5Update/md5Finialize) 3) Native Lazy.ByteString implementation (perhaps more than one?) ~3-6 times slower than 'C'. Tom On Tue, 2008-05-20 at 19:44 +0100, Andrew Coppin wrote: > Salvatore Insalaco wrote: > > Hi Andrew, > > just a profiling suggestion: did you try to use the SCC cost-centre > > annotations for profiling? > > If you want to know precisely what takes 60% of time, you can try: > > bn = {-# SCC "IntegerConversion" #-} 4 * fromIntegral wn > > b0 = {-# SCC "ByteStringIndexing" #-} B.index bi (bn+0) > > b1 = {-# SCC "ByteStringIndexing" #-} B.index bi (bn+1) > > b2 = {-# SCC "ByteStringIndexing" #-} B.index bi (bn+2) > > b3 = {-# SCC "ByteStringIndexing" #-} B.index bi (bn+3) > > w = foldl' (\w b -> shiftL w 8 .|. fromIntegral b) 0 [b3,b2,b1,b0] > > in {-# SCC "ArrayWriting" #-} unsafeWrite temp wn w > > > > In profiling the time of all expressions with the same SCC "name" will > > be summed. > > You can get more information about SCC here: > > http://www.haskell.org/ghc/docs/latest/html/users_guide/profiling.html#cost-centres > > > > OK, I'll give that a try... > > > One advice: I've seen various md5sum implementations in C, all using > > about the same algorithms and data structures, and they performed even > > with 10x time differences between them; md5summing fast is not a > > really simple problem. If I were you I would drop the comparison with > > ultra-optimized C and concentrate on "does my > > high-level-good-looking-super-readable implementation perform > > acceptably?". > > > > What "acceptably" means is left as an exercise to the reader. > > > > Well, so long as it can hash 500 MB of data in a few minutes without > using absurd amounts of RAM, that'll do for me. ;-) > > [I actually wanted to do this for a project at work. When I discovered > that none of the available Haskell implementations are fast enough, I > tried to write my own. But that wasn't fast enough either. So I ended up > being forced to call md5sum.exe and attempt to parse its output. > Obviously having a real Haskell function would be infinitely more > portable and convinient...] > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From niklas.broberg at gmail.com Tue May 20 19:38:55 2008 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Tue May 20 19:32:21 2008 Subject: [Haskell-cafe] status of dynamic loading In-Reply-To: <2518b95d0805201534g582fa2c9x3e310737cd20740b@mail.gmail.com> References: <2518b95d0805201534g582fa2c9x3e310737cd20740b@mail.gmail.com> Message-ID: > Use hs-plugins. I'm not sure if this still works on modern ghc, or if > it works on my platform (darwin intel), but I managed to get this > compiled after "fixing" a use of STArray whose arity apparently > changed, but I probably broke it because now I get "Error in array > index" all the time. I gather Austin Seipp has been doing some work > on this. Is there a newer version that should work? An easy fix for > the error? Which version have you tried to use? plugins-1.2 available on hackage works out of the box with ghc-6.8.2 on both linux and windows, we're using it for happs-hsp. Haven't tried it on Mac though, but I doubt it would contain any arity mismatches there, which leads me to believe that you're using an older one. Cheers, /Niklas From gwern0 at gmail.com Tue May 20 19:39:12 2008 From: gwern0 at gmail.com (Gwern Branwen) Date: Tue May 20 19:33:23 2008 Subject: [Haskell-cafe] status of dynamic loading In-Reply-To: <2518b95d0805201534g582fa2c9x3e310737cd20740b@mail.gmail.com> References: <2518b95d0805201534g582fa2c9x3e310737cd20740b@mail.gmail.com> Message-ID: <20080520233912.GA16572@localhost> On 2008.05.20 15:34:07 -0700, Evan Laforge scribbled 2.2K characters: > I have an application where I'd like to load and run code at runtime. > As far as I know, the possibilities are: > > Use hs-plugins. I'm not sure if this still works on modern ghc, or if > it works on my platform (darwin intel), but I managed to get this > compiled after "fixing" a use of STArray whose arity apparently > changed, but I probably broke it because now I get "Error in array > index" all the time. It's probably going to break again soon; at the very least, newer Cabals break it here. So I don't find that surprising. hs-plugins has been problematic for a long time; I don't think anyone could recommend it (unless they're dons) in good conscience - I certainly couldn't. > I gather Austin Seipp has been doing some work > on this. Is there a newer version that should work? An easy fix for > the error? I personally haven't heard of anything; vaguely something with the GHC API comes to mind, but nothing about hs-plugins. > Then there's the ghc api, which I gather is seen as the way forward > from hs-plugins, saving it from hi-parsing brittleness and platform > specific breakage. I think Yi uses this, apparently in in the Shim > package. I poked around some, but wasn't too clear to me what was > going on, if I was looking in the right place, and if this is a > reasonable way forward. GHC API will be the future, at some point, but it's definitely in flux. I know I had a rough time adapting some of the good docs on the 6.6 GHC API to work with 6.8.2; which I suppose is a good thing in the long run, but causes trouble for the here and now. Yi itself I think uses the API now, yes. The previous reload stuff from 0.3 wasn't too hot, and so JYP went and added in all this Shim stuff I don't understand. > lambdabot also appears to have its own dynamic loading mechanism, I > haven't looked at the source enough yet to understand what it's doing. > Maybe there's some documentation out there. So far as I know, lambdabot uses the 'old' architecture Yi was using: . That is, a small kernel which loads in fresh code and data. (On the other hand, the lambdabot.cabal claims to use plugins, so what do I know?) > The low-tech solution, used by xmonad, would be to pass the "dynamic" > code to main and just recompile the app for each instance, passing in > an instance specific set of config arguments. Of course, this isn't > really dynamic at all, and compiling all the various instances could > be clunky and awkward, but I know it works and could possibly be > reasonable if I also write my own little language for the stuff that > really has to be dynamic (anyone got one of these? lisplike would be > easy and ok, an haskell subset might be nicer... I would like to > avoid having *two* languages to write extensions in). This is actually a very nice solution in many ways; I think it gets you a lot of power and extensibility at a very minimal cost in complexity and bugginess. At least, XMonad has been much better at providing dynamic changes and updates via xmonad.hs, for very few bugs or problems, than anything I see with Yi (which has many, many fewer users). If you can use this solution, you probably should. I added in an XMonad-style of configuration to the autoproc package , and it worked very nicely and was relatively easy to code up. > The last solution I can think of is to export an RPC API instead of > dynamically loading code. The difficulty here is coming up with a > vocabulary that can be flattened and shipped to another program > without becoming an excessive maintenance issue or being too > inflexible. > > All in all, the dynamic loading approach of hs-plugins seems like the > easiest and most flexible, provided I can get its staged type > checking. Before I go trying to hack hs-plugins into working, or > poking around inside yi or lambdabot, can anyone point me at some > documentation, resources, advice, etc.? > > Thanks! -- gwern CACI NSO Al Chelsea UKUSA HTCIA insurgency BUDS Ft. Blacklisted -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080520/d2d5e80c/attachment.bin From mad.one at gmail.com Tue May 20 19:40:04 2008 From: mad.one at gmail.com (Austin Seipp) Date: Tue May 20 19:34:05 2008 Subject: [Haskell-cafe] status of dynamic loading In-Reply-To: <2518b95d0805201534g582fa2c9x3e310737cd20740b@mail.gmail.com> References: <2518b95d0805201534g582fa2c9x3e310737cd20740b@mail.gmail.com> Message-ID: <1211326008-sup-9628@continuum> Excerpts from Evan Laforge's message of Tue May 20 17:34:07 -0500 2008: > Use hs-plugins. I'm not sure if this still works on modern ghc, or if > it works on my platform (darwin intel), but I managed to get this > compiled after "fixing" a use of STArray whose arity apparently > changed, but I probably broke it because now I get "Error in array > index" all the time. What version of GHC, and were are you pulling the hs-plugins code from? If you're using at least 6.8 and you do: darcs get http://code.haskell.org/~dons/code/hs-plugins It should work just fine. Cale replaced a lot of the brittle parts (interface file parsing) with supplements that use the GHC API, so it should be at least a little easier to update, and last time I built it, it installed and worked nicely (I have heard no word on whether it does so for darwin/intel.) If memory serves me, there was a version put on hackage a few weeks ago from that repository that I would think work just as good. > I gather Austin Seipp has been doing some work on this. Just playing around. ;) > Then there's the ghc api, which I gather is seen as the way forward > from hs-plugins, saving it from hi-parsing brittleness and platform > specific breakage. I think Yi uses this, apparently in in the Shim > package. I poked around some, but wasn't too clear to me what was > going on, if I was looking in the right place, and if this is a > reasonable way forward. >From my experiences, getting the GHC API to work properly like I wanted was a bit of a pain point. In many instances, if I just threw away the session after changing the code and making a new session and reloading, the old version is still apparently resides in memory and is still executed. I spent a bit of time playing with this, etc. etc. but never got it to fully work. I did hear later that by simply setting the session you already used to be empty and then compiling modules into it works like what you could get from hs-plugins, though (a la load -> unload -> load or just call reload.) If you still want to give the GHC API a try, I have a package that just does some of the basic, quick stuff and it's on hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/metaplug It's not been updated for a long time though (since way before GHC 6.8.) The code is really small and the changes should be trivial, though. There is also hint which embeds GHC into your code and is a wrapper like my metaplug package: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hint I haven't tried it, but it might be worth investigating if hs-plugins doesn't turn to work out, and it looks far more well done than mine (which was forged in a time of haskell-naivety, for the most part.) -- "It was in the days of the rains that their prayers went up, not from the fingering of knotted prayer cords or the spinning of prayer wheels, but from the great pray-machine in the monastery of Ratri, goddess of the Night." Roger Zelazny From carter.schonwald at gmail.com Tue May 20 21:07:59 2008 From: carter.schonwald at gmail.com (Carter Tazio Schonwald) Date: Tue May 20 21:01:22 2008 Subject: [Haskell-cafe] are there any good c parsers + ast builders available for haskell? Message-ID: <483375EF.1060909@gmail.com> Hello, I'm thinking about having a go at writing some simple static analysis tools for C, and I think using Haskell would make it a happier time coding wise, the question being, are there preexisting parsing tools for C available for haskell? many thanks -Carter From dons at galois.com Tue May 20 21:46:41 2008 From: dons at galois.com (Don Stewart) Date: Tue May 20 21:40:05 2008 Subject: [Haskell-cafe] are there any good c parsers + ast builders available for haskell? In-Reply-To: <483375EF.1060909@gmail.com> References: <483375EF.1060909@gmail.com> Message-ID: <20080521014641.GA13121@scytale.galois.com> carter.schonwald: > Hello, > I'm thinking about having a go at writing some simple static > analysis tools for C, and I think using Haskell would make it a happier > time coding wise, the question being, are there preexisting parsing > tools for C available for haskell? > > many thanks > -Carter See this exciting summer of code project, http://code.google.com/soc/2008/haskell/appinfo.html?csaid=27F0E5995982E2C9 the main thing is to build upon the rather complete parser in http://www.cse.unsw.edu.au/~chak/haskell/c2hs/ -- Don From carter.schonwald at gmail.com Tue May 20 22:06:55 2008 From: carter.schonwald at gmail.com (Carter Tazio Schonwald) Date: Tue May 20 22:00:19 2008 Subject: [Haskell-cafe] are there any good c parsers + ast builders available for haskell? In-Reply-To: <20080521014641.GA13121@scytale.galois.com> References: <483375EF.1060909@gmail.com> <20080521014641.GA13121@scytale.galois.com> Message-ID: <483383BF.1040101@gmail.com> that looks perfect, though I guess I'll have to wait till mid-late summer or early fall to enjoy that. In the mean time, the happy file in c2hs looks like a good place to start, thanks! -Carter Don Stewart wrote: > carter.schonwald: > >> Hello, >> I'm thinking about having a go at writing some simple static >> analysis tools for C, and I think using Haskell would make it a happier >> time coding wise, the question being, are there preexisting parsing >> tools for C available for haskell? >> >> many thanks >> -Carter >> > > See this exciting summer of code project, > > http://code.google.com/soc/2008/haskell/appinfo.html?csaid=27F0E5995982E2C9 > > the main thing is to build upon the rather complete parser in > > http://www.cse.unsw.edu.au/~chak/haskell/c2hs/ > > -- Don > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080520/8f208a30/attachment.htm From qdunkan at gmail.com Tue May 20 23:17:42 2008 From: qdunkan at gmail.com (Evan Laforge) Date: Tue May 20 23:11:04 2008 Subject: [Haskell-cafe] status of dynamic loading In-Reply-To: <1211326008-sup-9628@continuum> References: <2518b95d0805201534g582fa2c9x3e310737cd20740b@mail.gmail.com> <1211326008-sup-9628@continuum> Message-ID: <2518b95d0805202017r4655ddcp2b0d6aa898abf332@mail.gmail.com> Great stuff everyone, thanks so much. I did indeed manage to download an old hs-plugins, and the new one seems to work fine. I'll definitely check out hint and metaplug, and for most of the stuff that doesn't need to be easily changeable at runtime I can do the xmonad thing. On the down side, my binary zoomed up to 25 unstripped MB, but since that's how big ghc is, I sort of expected that. I wonder if hugs could be embedded in a ghc program for the same sort of thing? Idly wondering, of course. From ajb at spamcop.net Tue May 20 23:23:37 2008 From: ajb at spamcop.net (ajb@spamcop.net) Date: Tue May 20 23:16:58 2008 Subject: [Haskell-cafe] one-way monads In-Reply-To: <625b74080805201047i3ab1b099p929fec3dc3932d48@mail.gmail.com> References: <625b74080805201047i3ab1b099p929fec3dc3932d48@mail.gmail.com> Message-ID: <20080520232337.lih626q644kwk08o-nwo@fcnzpbc.arg@webmail.spamcop.net> G'day all. Quoting Dan Piponi : > For any specific monad, m, it's usually possible > to write a function m a -> a. Actually, it's true less than 50% of the time. In particular, it's not true of any monad transformer. Cheers, Andrew Bromage From dan.doel at gmail.com Wed May 21 00:02:05 2008 From: dan.doel at gmail.com (Dan Doel) Date: Tue May 20 23:54:45 2008 Subject: [Haskell-cafe] one-way monads In-Reply-To: <20080520232337.lih626q644kwk08o-nwo@fcnzpbc.arg@webmail.spamcop.net> References: <625b74080805201047i3ab1b099p929fec3dc3932d48@mail.gmail.com> <20080520232337.lih626q644kwk08o-nwo@fcnzpbc.arg@webmail.spamcop.net> Message-ID: <200805210002.06381.dan.doel@gmail.com> On Tuesday 20 May 2008, ajb@spamcop.net wrote: > Actually, it's true less than 50% of the time. In particular, it's > not true of any monad transformer. Sure it is. Any particular transformer t typically comes with some particular way of writing a function of type t m a -> m a (you may have to throw away some t-related stuff, of course). Since a specific transformed monad is built from a specific monad, and a specific transformer, and specific transformers are likely to have a function of type t m a -> m a, and specific monads are likely to have functions of type m a -> a, you can compose them to get a function of type t m a -> a for the specific monad t m. And so on for transformed-transformed monads. :) That only fails if either of the specific pieces fails to have the right function, which happens well under 50% of the time, I think (IO and STM are the ones that immediately occur to me (barring a certain evil function), although you could make a case for ST by technicality; no failing transformers come to mind (except CCT if we're counting ST), but I haven't wracked my brain very hard). -- Dan From ok at cs.otago.ac.nz Wed May 21 00:46:28 2008 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Wed May 21 00:39:55 2008 Subject: [Haskell-cafe] RealFloat constraint on Complex type In-Reply-To: References: Message-ID: On 21 May 2008, at 9:25 am, Conal Elliott wrote: > I think the practice of constraint in type definitions is generally > discouraged, Is this true? If so, why? If I have a data type that simply doesn't make sense unless some of the type variables belong to certain classes, _shouldn't_ that be stated clearly in the declaration rather than hidden elsewhere? -- "I don't want to discuss evidence." -- Richard Dawkins, in an interview with Rupert Sheldrake. (Fortean times 232, p55.) From vigalchin at gmail.com Wed May 21 01:37:03 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Wed May 21 01:30:25 2008 Subject: [Haskell-cafe] ghc-pkg package.conf files? Message-ID: <5ae4f2ba0805202237y122a3795md4ee23d3808e9680@mail.gmail.com> Hello, I fairly innocuous question ;^). How does ghc-pkg know where are the *package.conf files are located? Regards, Vasili -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080521/3eadfc9c/attachment.htm From allbery at ece.cmu.edu Wed May 21 02:22:27 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Wed May 21 02:15:50 2008 Subject: [Haskell-cafe] ghc-pkg package.conf files? In-Reply-To: <5ae4f2ba0805202237y122a3795md4ee23d3808e9680@mail.gmail.com> References: <5ae4f2ba0805202237y122a3795md4ee23d3808e9680@mail.gmail.com> Message-ID: On 2008 May 21, at 1:37, Galchin, Vasili wrote: > I fairly innocuous question ;^). How does ghc-pkg know where are > the *package.conf files are located? The installed ghc-pkg is a shell script, to wit: > #!/bin/sh > GHCPKGBIN=/usr/local/lib/ghc-6.8.2/ghc-pkg.bin > PKGCONF=/usr/local/lib/ghc-6.8.2/package.conf > exec $GHCPKGBIN --global-conf $PKGCONF ${1+"$@"} The user package.conf is constructed from your home directory (~/.ghc/ platform-version/package.conf). -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080521/a56158ab/attachment.htm From vigalchin at gmail.com Wed May 21 02:35:19 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Wed May 21 02:28:41 2008 Subject: [Haskell-cafe] ghc-pkg package.conf files? In-Reply-To: References: <5ae4f2ba0805202237y122a3795md4ee23d3808e9680@mail.gmail.com> Message-ID: <5ae4f2ba0805202335w71b57b16s8318f8158eedb721@mail.gmail.com> hmm ... ;^). I found and read through part of ghc-pkg.hs .. ghc-6.8.2/utils/ghc-pkg/ .. I have 6 "broken" Haskell package databases (not debian) under /usr/lib/haskell-packages/ghc6/lib/. When I run ghc-pkg on them I get vigalchin@ubuntu:/usr/lib/haskell-packages/ghc6/lib/cairo-0.9.12.1$ ghc-pkg --package=cairo.package.conf list ghc-pkg: cairo.package.conf: parse error in package config file On Wed, May 21, 2008 at 1:22 AM, Brandon S. Allbery KF8NH < allbery@ece.cmu.edu> wrote: > > On 2008 May 21, at 1:37, Galchin, Vasili wrote: > > I fairly innocuous question ;^). How does glihc-pkg know where are the > *package.conf files are located? > > > The installed ghc-pkg is a shell script, to wit: > > #!/bin/sh > GHCPKGBIN=/usr/local/lib/ghc-6.8.2/ghc-pkg.bin > PKGCONF=/usr/local/lib/ghc-6.8.2/package.conf > exec $GHCPKGBIN --global-conf $PKGCONF ${1+"$@"} > > > The user package.conf is constructed from your home directory > (~/.ghc/platform-version/package.conf). > > -- > brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com > system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu > electrical and computer engineering, carnegie mellon university KF8NH > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080521/4d363078/attachment.htm From tphyahoo at gmail.com Wed May 21 04:11:36 2008 From: tphyahoo at gmail.com (Thomas Hartman) Date: Wed May 21 04:05:00 2008 Subject: [Haskell-cafe] Newbie: State monad example questions In-Reply-To: <53396d9e0805191404va8cb2d7yeb36954b83ac5ca8@mail.gmail.com> References: <53396d9e0805191404va8cb2d7yeb36954b83ac5ca8@mail.gmail.com> Message-ID: <910ddf450805210111n76f99e7cx43f1f5b84b999217@mail.gmail.com> I would be interested in seeing good motivating examples for use of the state monad, other than that example from All About Monads. Okay, it's good for randomness. What else? Reading the source code for State, I think I saw an example about using state to uniquely label elements of a tree with ascending integers, such that equal leaves in the original tree are also equal in the int-labeled tree. But this struck me as something that could be more elegantly done with some kind of tree fold. So, are there any other simple motivating examples that show what state is really good for? Thomas. Am 19. Mai 2008 16:04 schrieb Dmitri O.Kondratiev : > I am trying to understand State monad example15 at: > http://www.haskell.org/all_about_monads/html/statemonad.html > > Example 15 uses getAny that I don't understand at all how it works: > > getAny :: (Random a) => State StdGen a > getAny = do g <- get > (x,g') <- return $ random g > put g' > return x > > > Questions: > 1) random has type: > random :: (Random a, RandomGen g) => g -> (a, g) > > and for State monad: > > return a = State (\s -> (a, s)) > > then: > return (random g) = State (\s -> ((a,g), s)) > > Is it correct? > > 2) What x and g' will match to in: > do ... > (x,g') <- return $ random g > > which, as I understand equals to: > do ... > (x,g') <- State (\s -> ((a,g), s)) > > What x and g' will match to in the last expression? > > 3) In general, in do expression (pseudo): > do { x <- State (\s -> (a, s)); ...} > > What x will refer to? Will x stand for a whole lambda function: \s -> (a, s) > ? > > 4) How 'g <- get' works in this function (getAny) ? > 5) Why we need 'put g'? > > Thanks! > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From Alistair.Bayley at invesco.com Wed May 21 04:57:29 2008 From: Alistair.Bayley at invesco.com (Bayley, Alistair) Date: Wed May 21 04:50:51 2008 Subject: [Haskell-cafe] RealFloat constraint on Complex type In-Reply-To: References: Message-ID: <125EACD0CAE4D24ABDB4D148C4593DA9049E93A8@GBLONXMB02.corp.amvescap.net> > From: haskell-cafe-bounces@haskell.org > [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of > Richard A. O'Keefe > > On 21 May 2008, at 9:25 am, Conal Elliott wrote: > > I think the practice of constraint in type definitions is > generally > > discouraged, > > Is this true? If so, why? > If I have a data type that simply doesn't make sense unless > some of the > type variables belong to certain classes, _shouldn't_ that be stated > clearly in the declaration rather than hidden elsewhere? I recall this from Graham Klyne, but I think his use case might be a bit different: http://www.ninebynine.org/Software/Learning-Haskell-Notes.html#type-clas ses-and-data I don't know all the pros and cons (are there pros, other than the documentation argument you gave?). I think: 1. adding the constraint has some costs, and very few benefits 2. nobody does it much, if at all. Probably for the first reason. Alistair ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. ***************************************************************** From yann at kierun.org Wed May 21 05:20:13 2008 From: yann at kierun.org (Yann Golanski) Date: Wed May 21 05:13:35 2008 Subject: [Haskell-cafe] Rotating backdrop (aka learning Haskell) In-Reply-To: <1211301957.5514.186.camel@derek-laptop> References: <20080520081557.GA18833@kierun.org> <871w3xfj78.fsf@nmd9999.imr.no> <1211301957.5514.186.camel@derek-laptop> Message-ID: <20080521092013.GA19109@kierun.org> Quoth Derek Elkins on Tue, May 20, 2008 at 11:45:57 -0500 > On Tue, 2008-05-20 at 10:55 +0200, Ketil Malde wrote: > > Yann Golanski writes: > > > > > 1- Get a list out of a file: I managed to do that using the following: > > > > > > parseImageFile :: FilePath -> IO [String] > > > parseImageFile file = do inpStr <- readFile file > > > return $ filter (/="") (breaks (=='\n') inpStr) > > > > > > Nice, simple and I understand what it is doing. > > > > Can be improved: > > > > breaks (=='\n') == lines -- easier to read, no? > > filter (/="") == filter (not . null) -- more polymorphic, not important here > > do x <- expr1 == expr1 >>= return . expr2 > > return $ expr2 x -- i.e. "readFile f >>= return . filter (not.null) . lines" > > do x <- expr1; return $ expr2 x > == expr1 >>= return . expr2 > == liftM expr2 expr1 -- or fmap (a.k.a. <$>) if you like > > So, > liftM (filter (not . null) . lines) readFile > alternatively, > filter (not . null) . lines <$> readFile I'm sorry, this is a little beyond me. Could you elaborate a little more on what this actually does? -- yann@kierun.org -= H+ =- www.kierun.org PGP: 009D 7287 C4A7 FD4F 1680 06E4 F751 7006 9DE2 6318 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080521/aefcc7a5/attachment.bin From peteg42 at gmail.com Wed May 21 05:30:38 2008 From: peteg42 at gmail.com (Peter Gammie) Date: Wed May 21 05:24:13 2008 Subject: [Haskell-cafe] Re: HaXml and the XHTML 1.0 Strict DTD In-Reply-To: <20080430113218.56551fb9.Malcolm.Wallace@cs.york.ac.uk> References: <8F538DFA-79B9-4F65-9536-D117E2F82A5C@gmail.com> <20080430113218.56551fb9.Malcolm.Wallace@cs.york.ac.uk> Message-ID: On 30/04/2008, at 5:32 PM, Malcolm Wallace wrote: > Peter Gammie wrote: > >> The most-recent darcs version relies on a newer ByteString than I >> have, so it is not easy for me to test it. > > I believe there was a patch to fix this. Apparently only one > version of > the bytestring package (0.9.0.1) ever exported the 'join' function, > and > a different version with the same number (but not exporting 'join') > was > uploaded to Hackage! 'Join' has since been replaced by 'intercalate', > which is available in all versions 0.9.x. Thanks. I don't doubt it works with a newer bytestring, I just can't readily use such a thing. >> A recent (this year) darcs version failed to parse the DTD, yielding >> this error: > > I didn't try the full XHTML DTD, but the fragment you included in your > message was parsed just fine by the darcs version of HaXml/ > DtdToHaskell. Can you please try the full XHTML 1.0 Strict DTD? At the same time, can you verify that it handles this part of it properly (circa line 854): Using a slightly hacked HaXml v1.13.3, I get this from DtdToHaskell: data Table = Table Table_Attrs (Maybe Caption) (OneOf2 [Col] [Colgroup]) (Maybe Thead) (Maybe Tfoot) (OneOf2 (List1 Tbody) (List1 Tr)) deriving (Eq,Show) My expectation is that we can have a without a or child. The W3 validator seems to agree with that interpretation. When I use the HaXml validator with this DTD I get this (e.g.): Element
should contain (caption?,(col*| colgroup*),thead?,tfoot?,(tbody+|tr+)) but does not. Element
should contain (col*|colgroup*) but does not. cheers peter From gale at sefer.org Wed May 21 06:34:38 2008 From: gale at sefer.org (Yitzchak Gale) Date: Wed May 21 06:27:59 2008 Subject: [Haskell-cafe] Newbie: State monad example questions In-Reply-To: <910ddf450805210111n76f99e7cx43f1f5b84b999217@mail.gmail.com> References: <53396d9e0805191404va8cb2d7yeb36954b83ac5ca8@mail.gmail.com> <910ddf450805210111n76f99e7cx43f1f5b84b999217@mail.gmail.com> Message-ID: <2608b8a80805210334o36ccc06eycc2969ff15599783@mail.gmail.com> Thomas Hartman wrote: > I would be interested in seeing good motivating examples for use of > the state monad... > Okay, it's good for randomness. What else? > ...I saw an example about > using state to uniquely label elements of a tree > So, are there any other simple motivating examples that show what > state is really good for? I find that there are two basic ways that the State monad is useful for me. One is when functions have an extra parameter, or a tuple return type, that is not really a natural part of the meaning of the function but is only there for keeping state. In those cases, a state monad makes the intention more clear. The examples you mentioned - random generators and tree labeling - are both of this type. This first use is especially helpful when there are several functions that all share the same state. The other use is for backtracking. In the monad StateT s [], the state is re-initialized to its original value for each item of the list. Here is a fully spelled out example: http://haskell.org/haskellwiki/Sudoku#Backtrack_monad_solver The first solver on that page, by Cale Gibbard, is a more elegant way to do the same thing without spelling out so explicitly all the details of how the monad is giving you the backtracking effect. A few other solvers also use a backtracking monad. Have fun, Yitz From Malcolm.Wallace at cs.york.ac.uk Wed May 21 06:44:32 2008 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Wed May 21 06:38:36 2008 Subject: [Haskell-cafe] Re: HaXml and the XHTML 1.0 Strict DTD In-Reply-To: References: <8F538DFA-79B9-4F65-9536-D117E2F82A5C@gmail.com> <20080430113218.56551fb9.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <20080521114432.41ebb021.Malcolm.Wallace@cs.york.ac.uk> Peter Gammie wrote: > (caption?, (col*|colgroup*), thead?, tfoot?, (tbody+|tr+))> > > Using a slightly hacked HaXml v1.13.3, I get this from DtdToHaskell: > > data Table = Table Table_Attrs (Maybe Caption) > (OneOf2 [Col] [Colgroup]) (Maybe Thead) (Maybe Tfoot) > (OneOf2 (List1 Tbody) (List1 Tr)) > deriving (Eq,Show) This looks entirely correct to me. > My expectation is that we can have a
without a or > child. Ah, yes I can see why that is permitted, but I guess HaXml's validator is not yet smart enough to be able to choose whether it has seen an empty list of or an empty list of . :-) Here is a suggested fix. Let me know if it works for you. In src/Text/XML/HaXml/Validate.hs, around line 220, use the following diff over the local defn of 'choice': choice elem ns cps = -- return only those parses that don't give any errors [ rem | ([],rem) <- map (\cp-> checkCP elem (definite cp) ns) cps ] + ++ [ ns | all possEmpty cps ] where definite (TagName n Query) = TagName n None definite (Choice cps Query) = Choice cps None definite (Seq cps Query) = Seq cps None definite (TagName n Star) = TagName n Plus definite (Choice cps Star) = Choice cps Plus definite (Seq cps Star) = Seq cps Plus definite x = x + possEmpty (TagName _ mod) = mod `elem` [Query,Star] + possEmpty (Choice cps None) = all possEmpty cps + possEmpty (Choice _ mod) = mod `elem` [Query,Star] + possEmpty (Seq cps None) = all possEmpty cps + possEmpty (Seq _ mod) = mod `elem` [Query,Star] Are there other places, apart from the validator, where a similar problem arises? Regards, Malcolm From peteg42 at gmail.com Wed May 21 07:50:22 2008 From: peteg42 at gmail.com (Peter Gammie) Date: Wed May 21 07:43:49 2008 Subject: [Haskell-cafe] Re: HaXml and the XHTML 1.0 Strict DTD In-Reply-To: <20080521114432.41ebb021.Malcolm.Wallace@cs.york.ac.uk> References: <8F538DFA-79B9-4F65-9536-D117E2F82A5C@gmail.com> <20080430113218.56551fb9.Malcolm.Wallace@cs.york.ac.uk> <20080521114432.41ebb021.Malcolm.Wallace@cs.york.ac.uk> Message-ID: On 21/05/2008, at 5:44 PM, Malcolm Wallace wrote: > Peter Gammie wrote: > >> > (caption?, (col*|colgroup*), thead?, tfoot?, (tbody+|tr+))> >> >> Using a slightly hacked HaXml v1.13.3, I get this from DtdToHaskell: >> >> data Table = Table Table_Attrs (Maybe Caption) >> (OneOf2 [Col] [Colgroup]) (Maybe Thead) (Maybe >> Tfoot) >> (OneOf2 (List1 Tbody) (List1 Tr)) >> deriving (Eq,Show) > > This looks entirely correct to me. I realised that as soon as I sent it. :-) >> My expectation is that we can have a
without a or >> child. > > Ah, yes I can see why that is permitted, but I guess HaXml's validator > is not yet smart enough to be able to choose whether it has seen an > empty list of or an empty list of . :-) > > Here is a suggested fix. Let me know if it works for you. In > src/Text/XML/HaXml/Validate.hs, around line 220, use the following > diff > over the local defn of 'choice': > > choice elem ns cps = -- return only those parses that don't give > any errors > [ rem | ([],rem) <- map (\cp-> checkCP elem (definite cp) ns) > cps ] > + ++ [ ns | all possEmpty cps ] > where definite (TagName n Query) = TagName n None > definite (Choice cps Query) = Choice cps None > definite (Seq cps Query) = Seq cps None > definite (TagName n Star) = TagName n Plus > definite (Choice cps Star) = Choice cps Plus > definite (Seq cps Star) = Seq cps Plus > definite x = x > + possEmpty (TagName _ mod) = mod `elem` [Query,Star] > + possEmpty (Choice cps None) = all possEmpty cps > + possEmpty (Choice _ mod) = mod `elem` [Query,Star] > + possEmpty (Seq cps None) = all possEmpty cps > + possEmpty (Seq _ mod) = mod `elem` [Query,Star] Fantastic, thanks, that seems to work fine. A couple of nits: your use of `elem` refers to Prelude.elem, so I added the Prelude as a qualified import as P and changed those shadowed references to `P.elem`. I will try to send you a patch against 1.13.3 with all these little bits and pieces, when my project is finished. Can you lay out some kind of plan for HaXml? (is 1.13.x now dead, is 1.19.x stable, ...?) This would help for new-ish projects like mine. > Are there other places, apart from the validator, where a similar > problem arises? I do not know, I am merely using the DTD and HTML parsers, the CFilter combinators, the pretty printer and the validator. They all seem fine on a cursory check. (In general HaXml has been working quite well. Thanks for producing such a long-lived and well-thought-out library.) cheers peter From dokondr at gmail.com Wed May 21 08:42:21 2008 From: dokondr at gmail.com (Dmitri O.Kondratiev) Date: Wed May 21 08:35:41 2008 Subject: [Haskell-cafe] Newbie: State monad example questions In-Reply-To: References: <53396d9e0805191404va8cb2d7yeb36954b83ac5ca8@mail.gmail.com> Message-ID: <53396d9e0805210542n667d6596uca6b8caf89e30219@mail.gmail.com> Thanks everybody for your help! Oliver, you provided an excellent write-up on State monad without going into 'scary' :) details, great work indeed! Alas, in this case I need the details, and in particular the most scary ones! So let's start with fundamental and most intriguing (to me) things: getAny :: (Random a) => State StdGen a getAny = do g <- get -- magically get the current StdGen First line above declares a data type: State StdGen a which is constructed with the function: State {runState :: (StdGen -> (a, StdGen))} Q1: Where in the example ( http://www.haskell.org/all_about_monads/examples/example15.hs) data of this type *actually gets constructed* ? Looking at example15.hs code we see the following sequence: 1) makeRandomValue g -- where g is a StdGen instance, ok 2) makeRandomValue g ~> expands into ~> ~> (runState (do { ...; b <- getAny;...})) g This last expression puzzles me. I can understand, for example, this: State StdGen a :: aState StdGen:: g1 (v, g2) = (runStae aState) g1 -- this returns a state function which is then passed a generator g1, and as result returns pair (value, new generaor) But '(runState (do ...)) g' implies that expression (do ...) must be somehow of type 'State StdGen a' ? Yet, when we call 'makeRandomValue g' we just pass to this function g::StgGen So, my next question: Q2: How (do {...;b <- getAny;...}) becomes an *instance* of type 'State StdGen a' ? On Tue, May 20, 2008 at 7:01 PM, Olivier Boudry wrote: > 2008/5/19 Dmitri O.Kondratiev : > >> I am trying to understand State monad example15 at: >> http://www.haskell.org/all_about_monads/html/statemonad.html >> >> > Hi Dmitri, > > I'm not sure you need to understand everything about Monad and do-notation > to use the State Monad. So I will try to explain its use without talking > about those scary topics. ;-) > > In Haskell you use the state monad when you want to hide state passing > between function calls. As Haskell is pure you cannot change state. You can > just create a new state and return it along with the value. In haskell you > would do this by returning the value and new state in a tuple. State passing > functions usually have the type `s -> (a, s)` where a is the type of the > return value and s is the type of the State. > > This is exactly what the `random` function does. It gets a state and > returns a tuple made of a value and a new state (StdGen: is a new seed for > the random generator) to be used on the next `random` function call . > > Without the state monad you have to explicitely pass the new seed between > calls to `random` as using the same seed for all function calls would always > give you the same "not so random" number. > > Explicit state passing would look like this. > > get3RandomInts :: StdGen -> (Int, Int, Int) > get3RandomInts g1 = > let (r1, g2) = random g1 > (r2, g3) = random g2 > (r3, _) = random g3 > in (r1, r2, r3) > > It's tedious, unreadable and error prone as it's easy to mess up the > numbering (based on my experience). > > The State Monad allow you to hide the state passing. You don't have to give > the state as an argument and your function won't return a changed state > along with the data. Code running in the State Monad will look like this: > > getAny :: (Random a) => State StdGen a > getAny = do g <- get -- magically get the current StdGen > let (x, g') = random g > put g' -- magically save the new StdGen for later > return x > > get3RandomIntsWithState :: State StdGen (Int, Int, Int) > get3RandomIntsWithState = do > r1 <- getAny -- you don't care about stdgen passing > r2 <- getAny > r3 <- getAny > return (r1, r2, r3) > > To use your get3RandomIntsWithState function you need to run it using one > of runState (returns the (value, state)) or evalState (returns the value). > > main :: IO () > main = do > g <- getStdGen > let t = evalState get3RandomsWithState g > print t > > The interesting bits are in the getAny function. The State Monad provides > you with 2 new function, get and set. If you look at this function as > blackboxes; `get` will retrieve the current State and `put` will save a new > State. You don't need to worry about how the State is passed from one getAny > function call to another as long as they're run in the same `evalState` > call. > > Now getAny can be simplified. If you look at the random function and at the > State newtype declaration you will see that a State is a `s -> (a, s)` > function "hidden" in the State constructor. > > newtype State s a = State {runState :: s -> (a, s)} > > random is also of the type `s -> (a, s)` even if variables are labelled `g` > and `a` > > random :: (RandomGen g, Random a) => g -> (a, g) > > So wrapping the random function into the State constructor will just give > you a getAny function for free. > > getAny :: (Random a) => State StdGen a > getAny = State random > > I put a copy of the code in http://hpaste.org/7768 > > In short to use the State monad, you just need to care about a couple of > details. > > The type of your functions running in the State Monad must end in `State s > a` where `s` is the type of the state and `a` the type of the return value. > > You have to run it using either runState, execState or evalState. runState > will return both the value and the state, execState will return the state > and evalState will return just the value. > > You must use put and get to retrieve and store the State but don't need to > care about the details of how the state is passed. As long as your function > calls are all part of the same action. > > I hope it helps. I'm also quite new at Haskell and the terminology used is > probably not very accurate. > > Best regards, > > Olivier. > -- Dmitri O. Kondratiev dokondr@gmail.com http://www.geocities.com/dkondr -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080521/d00e39fe/attachment.htm From Malcolm.Wallace at cs.york.ac.uk Wed May 21 08:40:58 2008 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Wed May 21 08:36:54 2008 Subject: [Haskell-cafe] Re: HaXml and the XHTML 1.0 Strict DTD In-Reply-To: References: <8F538DFA-79B9-4F65-9536-D117E2F82A5C@gmail.com> <20080430113218.56551fb9.Malcolm.Wallace@cs.york.ac.uk> <20080521114432.41ebb021.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <20080521134058.22a2c975.Malcolm.Wallace@cs.york.ac.uk> Peter Gammie wrote: > Can you lay out some kind of plan for HaXml? (is 1.13.x now dead, is > 1.19.x stable, ...?) This would help for new-ish projects like mine. The 1.13.x stable branch sees minimal maintenance only, mostly to repair it to build after each new release of ghc breaks something. Versions 1.14 - 1.19 (i.e. the darcs repo) introduce several API changes. I think those have now pretty-much stablised, but unfortunately the work to realise the benefit of those changes throughout the codebase is still incomplete in some places. That is why I have not frozen and released this branch as 2.0 yet. For forward compatibility I would definitely recommend that a new project using HaXml should start with the 1.19 branch, not 1.13. Regards, Malcolm From lemming at henning-thielemann.de Wed May 21 09:08:23 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed May 21 09:00:15 2008 Subject: [Haskell-cafe] RealFloat constraint on Complex type In-Reply-To: References: Message-ID: On Tue, 20 May 2008, Conal Elliott wrote: > GHC's (maybe Haskell98's?) Complex type is defined with a RealFloat > constraint on type type itself, rather than on some of the instances and > functions: > > data (RealFloat a) => Complex a = !a :+ !a > > I think the practice of constraint in type definitions is generally > discouraged, and I'm wondering if there are reasons other than history for > having the constraint here. Is removing it on the table for Haskell'? > > I just got bit by what I think is a typical problem. I added a VectorSpace > instance for 'Complex a' and discovered that my 'a' must be in RealFloat, > even though I use only zero, addition, subtraction, and scaling. > > I suspect this gripe has been raised before ... Actually, in NumericPrelude there is no such constraint and Complex is an instance of Module and VectorSpace: http://darcs.haskell.org/numericprelude/src/Number/Complex.hs http://hackage.haskell.org/cgi-bin/hackage-scripts/package/numeric-prelude From bos at serpentine.com Wed May 21 09:54:37 2008 From: bos at serpentine.com (Bryan O'Sullivan) Date: Wed May 21 09:48:07 2008 Subject: [Haskell-cafe] RealFloat constraint on Complex type In-Reply-To: References: Message-ID: <4834299D.4060008@serpentine.com> Richard A. O'Keefe wrote: >> I think the practice of constraint in type definitions is generally >> discouraged, > > Is this true? If so, why? As a practical matter, a Haskell 98 constraint infects every place you might like to use the type. They're like prion proteins, corrupting everything they touch, replicating implacably as they go. Here's the usual pattern that leads to the abandonment of constraints on types by the previously innocent coder. You add the constraint in the one place you think you need it, only to find that the type checker insists that three more are now required on previously pristine code that otherwise never mentions your type. You reluctantly add the constraint to those, and the compiler demands another seven uses. Now your code is littered with meaningless spaghetti constraints that obfuscate your original intent. The same contagion also costs you the ability to derive instances of many useful built-in typeclasses, such as Functor. The constraint on the type requires that a function such as fmap must have the constraint, too, and thus the plague continues. Pre-GADT syntax doesn't have this problem. {-# LANGUAGE GADTs #-} data Foo a = Show a => Foo a foo :: Foo a -> a foo (Foo a) = a Notice the change in the location of the constraint, and the lack of a need for a constraint on the function foo. Real GADTs avoid the problem in a similar way. data Bar a where Bar :: Show a => a -> Bar a bar :: Bar a -> a bar (Bar a) = a From olivier.boudry at gmail.com Wed May 21 09:55:46 2008 From: olivier.boudry at gmail.com (Olivier Boudry) Date: Wed May 21 09:49:07 2008 Subject: [Haskell-cafe] Newbie: State monad example questions In-Reply-To: <53396d9e0805210542n667d6596uca6b8caf89e30219@mail.gmail.com> References: <53396d9e0805191404va8cb2d7yeb36954b83ac5ca8@mail.gmail.com> <53396d9e0805210542n667d6596uca6b8caf89e30219@mail.gmail.com> Message-ID: On Wed, May 21, 2008 at 8:42 AM, Dmitri O.Kondratiev wrote: > So let's start with fundamental and most intriguing (to me) things: > > getAny :: (Random a) => State StdGen a > getAny = do g <- get -- magically get the current StdGen > > First line above declares a data type: > > State StdGen a > > which is constructed with the function: > > State {runState :: (StdGen -> (a, StdGen))} > > Q1: Where in the example ( > http://www.haskell.org/all_about_monads/examples/example15.hs) data of > this type *actually gets constructed* ? In getAny and getOne. Their signature has type `State StdGen a`. The use of the do notation to chain the actions and the use of get and put from the State Monad make this function a `State StdGen a`. > Looking at example15.hs code we see the following sequence: > > 1) makeRandomValue g -- where g is a StdGen instance, ok > > 2) makeRandomValue g ~> expands into ~> > > ~> (runState (do { ...; b <- getAny;...})) g > > > This last expression puzzles me. I can understand, for example, this: > > State StdGen a :: aState > StdGen:: g1 > > (v, g2) = (runStae aState) g1 -- this returns a state function which is > then passed a generator g1, and as result returns pair (value, new generaor) > > But '(runState (do ...)) g' implies that expression (do ...) must be > somehow of type 'State StdGen a' ? > Yet, when we call 'makeRandomValue g' we just pass to this function > g::StgGen > > So, my next question: > Q2: How (do {...;b <- getAny;...}) becomes an *instance* of type 'State > StdGen a' ? > In 2) I suppose you're talking of `makeRandomValueST` as `makeRandomValue` is the function that runs without the State Monad. makeRandomValueST does not build a `State StdGen a` it uses `runState` to run the (do block) which has type `State StdGen a`. Using `runState` will run an action which has `State s a` type on an initial state `s` and return a `(a, s)` tuple. `makeRandomValueST` does just the same using its parameter `g :: StdGen` as initial state and returning a tuple of type `(MyType, StdGen)`. Now what makes the do-block used in `runState` an instance of type `State StdGen a` is type inference. `runState` expects a `State s a` as first argument and `s` as second argument. The function signature, the use of `>>=` and `return` (desugared do-block) to combine actions and the use of actions already having that type like `getAny` and `getOne` will make your do block a `State StdGen a`. I'm not sure we can talk of building an instance of `State s a`. It's a "parameterized variant" of `State s a` which itself is an instance of the Monad class. We're just assigning types to the `s` and `a` type variables in `State s a`. In short `runState` takes the value (s -> (a, s)) out of the State monad. In the case of the State Monad that value is a function and it is run on the initial state. Its usually what runXXXXX functions do. They have type `(Monad m) => m a -> a`. Actions in the State Monad have type `State (s -> (a, s))`. The value stored in the State constructor is a function. Combining two actions using the `>>=` and `>>` functions (hidden or not in a do-block) just create a bigger `s -> (a, s)` function. The function is "hidden" in a `State` constructor just to ensure you don't run it when you don't want to. When you whant to run the "big function" you first have to take it out of the State constructor using the accessor `runState` and then run it on the initial state. The end result is of course a (a, s) tuple. Clear as mud, isn't it? It tooks me lots of time to understand how the State Monad works. I read many tutorial and still understood nothing about it. Its only by looking at the source code, playing with it and trying to rewrite the State Monad that I finally got an understanding of it. So I'm not sure you'll get it before you go through the same kind of path. The key to understand this Monad, at least based on my experience, is to keep in mind that `>>=` just assembles small state passing functions into bigger ones, but does not run the built function until you explicitly use the `runState` function on it. Olivier. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080521/c17efded/attachment.htm From allbery at ece.cmu.edu Wed May 21 10:35:18 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Wed May 21 10:28:38 2008 Subject: [Haskell-cafe] ghc-pkg package.conf files? In-Reply-To: <5ae4f2ba0805202335w71b57b16s8318f8158eedb721@mail.gmail.com> References: <5ae4f2ba0805202237y122a3795md4ee23d3808e9680@mail.gmail.com> <5ae4f2ba0805202335w71b57b16s8318f8158eedb721@mail.gmail.com> Message-ID: <2E914982-7693-4378-AC63-4E16A785824C@ece.cmu.edu> On 2008 May 21, at 2:35, Galchin, Vasili wrote: > hmm ... ;^). I found and read through part of ghc-pkg.hs .. > ghc-6.8.2/utils/ghc-pkg/ .. I have 6 "broken" Haskell package > databases (not debian) under /usr/lib/haskell-packages/ghc6/lib/. > When I run ghc-pkg on them I get vigalchin@ubuntu:/usr/lib/haskell- > packages/ghc6/lib/cairo-0.9.12.1$ ghc-pkg -- > package=cairo.package.conf list > ghc-pkg: cairo.package.conf: parse error in package config file ghc doesn't use those; sounds like vendor packages with presumably some way to combine them into the master package.conf. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080521/c355a01f/attachment.htm From jules at jellybean.co.uk Wed May 21 10:54:52 2008 From: jules at jellybean.co.uk (Jules Bean) Date: Wed May 21 10:48:17 2008 Subject: [Haskell-cafe] Newbie: State monad example questions In-Reply-To: <53396d9e0805210542n667d6596uca6b8caf89e30219@mail.gmail.com> References: <53396d9e0805191404va8cb2d7yeb36954b83ac5ca8@mail.gmail.com> <53396d9e0805210542n667d6596uca6b8caf89e30219@mail.gmail.com> Message-ID: <483437BC.9040901@jellybean.co.uk> Dmitri O.Kondratiev wrote: > Thanks everybody for your help! > Oliver, you provided an excellent write-up on State monad without > going into 'scary' :) details, great work indeed! > Alas, in this case I need the details, and in particular the most scary > ones! > > So let's start with fundamental and most intriguing (to me) things: > > getAny :: (Random a) => State StdGen a > getAny = do g <- get -- magically get the current StdGen > > First line above declares a data type: > > State StdGen a > > which is constructed with the function: > > State {runState :: (StdGen -> (a, StdGen))} > > Q1: Where in the example > (http://www.haskell.org/all_about_monads/examples/example15.hs) data of > this type *actually gets constructed* ? Actually get constructed? It gets constructed by >>= and return, both of which construct state objects: instance Monad (State s) where return a = State $ \s -> (a, s) m >>= k = State $ \s -> let (a, s') = runState m s in runState (k a) s' How do >>= and return get called? Well you can see explicit calls to return. The >>= is implicit in the way do-notation is desugared. getAny = do g <- get let (x,g') = random g put g' return x rewrites to getAny = get >>= \g -> ( let (x,g') = random g in (put g' >> return x) ) where I have added some not strictly necessary ()s and taken the liberty of changing the confusing "a <- return x" idiom to "let a = x". So the *actually gets constructed* part is that use of >>= . HTH, Jules From dokondr at gmail.com Wed May 21 11:10:40 2008 From: dokondr at gmail.com (Dmitri O.Kondratiev) Date: Wed May 21 11:04:00 2008 Subject: [Haskell-cafe] Newbie: State monad example questions In-Reply-To: References: <53396d9e0805191404va8cb2d7yeb36954b83ac5ca8@mail.gmail.com> <53396d9e0805210542n667d6596uca6b8caf89e30219@mail.gmail.com> Message-ID: <53396d9e0805210810m6f48596jde8e98f7394403c6@mail.gmail.com> State is a data type. As any other data type it can be instantiated. State instance is a structure of one record that contains (\s ->(a,s)) lambda function. This function can be parametrized by types of its arguments 's' and 'a'. I don't see magic here :) Ok, then from declaration: getAny :: (Random a) => State StdGen a getAny = do g <- get we can say that looking at type 'State StdGen a' compiler concludes that later on in the 'do' block statements like: g <- get will resolve into bind function (>>=) *as bind is defined for State monad*. Fine, I assume compiler is capable of such reasoning. Then g <- get may be written as: get >>= \g -> ... To understand how State monad work, I wrote MyState data type that emulates State and (>=>) 'bind' function that emulates 'real' bind (>>=) implementation for State monad: (>=>) :: MyState StdGen Int -> (Int -> MyState StdGen Int) -> MyState StdGen Int (MyState ms) >=> fn = MyState(\seed -> let(v1, newSeed) = ms seed ms2 = fn v1 in (runState ms2) newSeed) Inserting 'get' into >>= (or >=> in my code) will in fact result in thinking about State instance that 'get' returns as denoted by 'ms' in this code of mine. >From 'get' definition follows that function hiding behind 'ms' State instance is: \s -> (s,s) So when later we will feed generator 'g1' into this function will get: (g1,g1) And we also will get: v1 = g1 newSeed = g1 ms2 = fn g1 and finally 'g' in expression 'g <- get' will be equal to 'g1' that will be later fed in through the function call: 'makeRandomValueST g1' But how will 'g1' actually get delivered from 'makeRandomValueST g1' to invocation of 'getAny' I don't yet understand! On Wed, May 21, 2008 at 5:55 PM, Olivier Boudry wrote: > On Wed, May 21, 2008 at 8:42 AM, Dmitri O.Kondratiev > wrote: > >> So let's start with fundamental and most intriguing (to me) things: >> >> getAny :: (Random a) => State StdGen a >> getAny = do g <- get -- magically get the current StdGen >> >> First line above declares a data type: >> >> State StdGen a >> >> which is constructed with the function: >> >> State {runState :: (StdGen -> (a, StdGen))} >> >> Q1: Where in the example ( >> http://www.haskell.org/all_about_monads/examples/example15.hs) data of >> this type *actually gets constructed* ? > > > In getAny and getOne. Their signature has type `State StdGen a`. The use of > the do notation to chain the actions and the use of get and put from the > State Monad make this function a `State StdGen a`. > > >> Looking at example15.hs code we see the following sequence: >> >> 1) makeRandomValue g -- where g is a StdGen instance, ok >> >> 2) makeRandomValue g ~> expands into ~> >> >> ~> (runState (do { ...; b <- getAny;...})) g >> >> >> This last expression puzzles me. I can understand, for example, this: >> >> State StdGen a :: aState >> StdGen:: g1 >> >> (v, g2) = (runStae aState) g1 -- this returns a state function which is >> then passed a generator g1, and as result returns pair (value, new generaor) >> >> But '(runState (do ...)) g' implies that expression (do ...) must be >> somehow of type 'State StdGen a' ? >> Yet, when we call 'makeRandomValue g' we just pass to this function >> g::StgGen >> >> So, my next question: >> Q2: How (do {...;b <- getAny;...}) becomes an *instance* of type 'State >> StdGen a' ? >> > > In 2) I suppose you're talking of `makeRandomValueST` as `makeRandomValue` > is the function that runs without the State Monad. > > makeRandomValueST does not build a `State StdGen a` it uses `runState` to > run the (do block) which has type `State StdGen a`. > > Using `runState` will run an action which has `State s a` type on an > initial state `s` and return a `(a, s)` tuple. > > `makeRandomValueST` does just the same using its parameter `g :: StdGen` as > initial state and returning a tuple of type `(MyType, StdGen)`. Now what > makes the do-block used in `runState` an instance of type `State StdGen a` > is type inference. `runState` expects a `State s a` as first argument and > `s` as second argument. The function signature, the use of `>>=` and > `return` (desugared do-block) to combine actions and the use of actions > already having that type like `getAny` and `getOne` will make your do block > a `State StdGen a`. > > I'm not sure we can talk of building an instance of `State s a`. It's a > "parameterized variant" of `State s a` which itself is an instance of the > Monad class. We're just assigning types to the `s` and `a` type variables in > `State s a`. > > In short `runState` takes the value (s -> (a, s)) out of the State monad. > In the case of the State Monad that value is a function and it is run on the > initial state. Its usually what runXXXXX functions do. They have type > `(Monad m) => m a -> a`. > > Actions in the State Monad have type `State (s -> (a, s))`. The value > stored in the State constructor is a function. Combining two actions using > the `>>=` and `>>` functions (hidden or not in a do-block) just create a > bigger `s -> (a, s)` function. The function is "hidden" in a `State` > constructor just to ensure you don't run it when you don't want to. When you > whant to run the "big function" you first have to take it out of the State > constructor using the accessor `runState` and then run it on the initial > state. The end result is of course a (a, s) tuple. > > Clear as mud, isn't it? It tooks me lots of time to understand how the > State Monad works. I read many tutorial and still understood nothing about > it. Its only by looking at the source code, playing with it and trying to > rewrite the State Monad that I finally got an understanding of it. So I'm > not sure you'll get it before you go through the same kind of path. > > The key to understand this Monad, at least based on my experience, is to > keep in mind that `>>=` just assembles small state passing functions into > bigger ones, but does not run the built function until you explicitly use > the `runState` function on it. > > Olivier. > -- Dmitri O. Kondratiev dokondr@gmail.com http://www.geocities.com/dkondr -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080521/e0c19de2/attachment.htm From dokondr at gmail.com Wed May 21 11:22:46 2008 From: dokondr at gmail.com (Dmitri O.Kondratiev) Date: Wed May 21 11:16:12 2008 Subject: [Haskell-cafe] Newbie: State monad example questions In-Reply-To: <483437BC.9040901@jellybean.co.uk> References: <53396d9e0805191404va8cb2d7yeb36954b83ac5ca8@mail.gmail.com> <53396d9e0805210542n667d6596uca6b8caf89e30219@mail.gmail.com> <483437BC.9040901@jellybean.co.uk> Message-ID: <53396d9e0805210822g19cb9a83u43cda7f5fbe4a164@mail.gmail.com> Jules, Stupid question, please bear with me: x :: Int -- x declared, but not constructed x = 1 -- x constructed s1 :: State StdGen a -- s1 declared, yes, but why s1 is *also already constructed* ? On Wed, May 21, 2008 at 6:54 PM, Jules Bean wrote: > Dmitri O.Kondratiev wrote: > >> Thanks everybody for your help! >> Oliver, you provided an excellent write-up on State monad without >> going into 'scary' :) details, great work indeed! >> Alas, in this case I need the details, and in particular the most scary >> ones! >> >> So let's start with fundamental and most intriguing (to me) things: >> >> getAny :: (Random a) => State StdGen a >> getAny = do g <- get -- magically get the current StdGen >> >> First line above declares a data type: >> >> State StdGen a >> >> which is constructed with the function: >> >> State {runState :: (StdGen -> (a, StdGen))} >> >> Q1: Where in the example ( >> http://www.haskell.org/all_about_monads/examples/example15.hs) data of >> this type *actually gets constructed* ? >> > > Actually get constructed? > > It gets constructed by >>= and return, both of which construct state > objects: > > instance Monad (State s) where > return a = State $ \s -> (a, s) > m >>= k = State $ \s -> let > (a, s') = runState m s > in runState (k a) s' > > > How do >>= and return get called? Well you can see explicit calls to > return. The >>= is implicit in the way do-notation is desugared. > > getAny = do g <- get > let (x,g') = random g > put g' > return x > > rewrites to > > getAny = get >>= \g -> ( let (x,g') = random g in (put g' >> return x) ) > > where I have added some not strictly necessary ()s and taken the liberty of > changing the confusing "a <- return x" idiom to "let a = x". > > So the *actually gets constructed* part is that use of >>= . > > HTH, > > Jules > -- Dmitri O. Kondratiev dokondr@gmail.com http://www.geocities.com/dkondr -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080521/811ef2d5/attachment.htm From jules at jellybean.co.uk Wed May 21 11:31:04 2008 From: jules at jellybean.co.uk (Jules Bean) Date: Wed May 21 11:24:27 2008 Subject: [Haskell-cafe] Newbie: State monad example questions In-Reply-To: <53396d9e0805210822g19cb9a83u43cda7f5fbe4a164@mail.gmail.com> References: <53396d9e0805191404va8cb2d7yeb36954b83ac5ca8@mail.gmail.com> <53396d9e0805210542n667d6596uca6b8caf89e30219@mail.gmail.com> <483437BC.9040901@jellybean.co.uk> <53396d9e0805210822g19cb9a83u43cda7f5fbe4a164@mail.gmail.com> Message-ID: <48344038.5040801@jellybean.co.uk> Dmitri O.Kondratiev wrote: > Jules, > > Stupid question, please bear with me: > > x :: Int -- x declared, but not constructed > x = 1 -- x constructed > > s1 :: State StdGen a -- s1 declared, yes, but why s1 is *also already > constructed* ? it's not. it's constructed when you do s1 = return 1 ... or ... s1 = get >>= put .. or some other more complex interaction, perhaps using do notation. It's the >>= or the return that construct the State, just as the '1' is enough to construct the Int. Jules From aditya_siram at hotmail.com Wed May 21 12:11:06 2008 From: aditya_siram at hotmail.com (Aditya Siram) Date: Wed May 21 12:04:27 2008 Subject: [Haskell-cafe] Installing Cabal-Install Message-ID: Hi all, I am trying to install cabal-install so I can install xmonad-contrib. I have all the dependancies in place but when I do: runhaskell Setup.lhs build I get: Hackage/Types.hs:19:29: Module `Distribution.Version' does not export `Dependency' Any ideas? Thanks ... Deech _________________________________________________________________ Make every e-mail and IM count. Join the i?m Initiative from Microsoft. http://im.live.com/Messenger/IM/Join/Default.aspx?source=EML_WL_ MakeCount From dbueno at gmail.com Wed May 21 12:22:33 2008 From: dbueno at gmail.com (Denis Bueno) Date: Wed May 21 12:15:54 2008 Subject: [Haskell-cafe] Installing Cabal-Install In-Reply-To: References: Message-ID: <6dbd4d000805210922i738e349asc94ff689390c9b33@mail.gmail.com> On Wed, May 21, 2008 at 12:11 PM, Aditya Siram wrote: > > Hi all, > I am trying to install cabal-install so I can install xmonad-contrib. I have all the dependancies in place but when I do: > runhaskell Setup.lhs build > I get: > Hackage/Types.hs:19:29: > Module `Distribution.Version' does not export `Dependency' > > Any ideas? If you're trying to install cabal-install from its darcs repo, you need the latest Cabal from *its* repo. darcs get --partial http://darcs.haskell.org/cabal/ You'll have to build and install Cabal, then build cabal-install against it. -- Denis From maciej.podgurski at googlemail.com Wed May 21 12:43:59 2008 From: maciej.podgurski at googlemail.com (Maciej Podgurski) Date: Wed May 21 12:35:47 2008 Subject: [Haskell-cafe] Return user state in Parsec Message-ID: <4834514F.5020409@googlemail.com> Hi, I'm currently writing a parser using the Parsec library. What I want is to store the order of each subparser called in a user state. So every single parser will be marked with a label that is stored in a special treelike structure when the parser is run. My problem is to return the last state of this structure when a parse error occurred. This information shall be used to display a kind of stack trace showing the order of the parser calls for debug purposes. Any ideas how to achieve this? Thanks, Maciej From aditya_siram at hotmail.com Wed May 21 13:14:36 2008 From: aditya_siram at hotmail.com (Aditya Siram) Date: Wed May 21 13:07:57 2008 Subject: [Haskell-cafe] [Solved] Installing Cabal-Install In-Reply-To: <6dbd4d000805210922i738e349asc94ff689390c9b33@mail.gmail.com> References: <6dbd4d000805210922i738e349asc94ff689390c9b33@mail.gmail.com> Message-ID: That worked. Thank you. ---------------------------------------- > Date: Wed, 21 May 2008 12:22:33 -0400 > From: dbueno@gmail.com > To: aditya_siram@hotmail.com > Subject: Re: [Haskell-cafe] Installing Cabal-Install > CC: haskell-cafe@haskell.org > > On Wed, May 21, 2008 at 12:11 PM, Aditya Siram wrote: >> >> Hi all, >> I am trying to install cabal-install so I can install xmonad-contrib. I have all the dependancies in place but when I do: >> runhaskell Setup.lhs build >> I get: >> Hackage/Types.hs:19:29: >> Module `Distribution.Version' does not export `Dependency' >> >> Any ideas? > > If you're trying to install cabal-install from its darcs repo, you > need the latest Cabal from *its* repo. > > darcs get --partial http://darcs.haskell.org/cabal/ > > You'll have to build and install Cabal, then build cabal-install against it. > > -- > Denis _________________________________________________________________ E-mail for the greater good. Join the i?m Initiative from Microsoft. http://im.live.com/Messenger/IM/Join/Default.aspx?source=EML_WL_ GreaterGood From barsoap at web.de Wed May 21 14:03:11 2008 From: barsoap at web.de (Achim Schneider) Date: Wed May 21 13:56:45 2008 Subject: [Haskell-cafe] Re: Return user state in Parsec References: <4834514F.5020409@googlemail.com> Message-ID: <20080521200311.0208fb39@solaris> Maciej Podgurski wrote: > Hi, > > I'm currently writing a parser using the Parsec library. What I want > is to store the order of each subparser called in a user state. So > every single parser will be marked with a label that is stored in a > special treelike structure when the parser is run. > > My problem is to return the last state of this structure when a parse > error occurred. This information shall be used to display a kind of > stack trace showing the order of the parser calls for debug purposes. > Any ideas how to achieve this? > Write the parser in a way that can never, ever fail, and return the parse error as part of your tree. That is, write a wrapper that puts optionMaybe's around every parser you call and records label, position and everything, and maybe go ahead and roll your own monad inside of ParsecT PS: don't try to influence the parsing based on state, if you don't feel like despairing. Messy cans of worms lay ahead. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. From westondan at imageworks.com Wed May 21 14:14:52 2008 From: westondan at imageworks.com (Dan Weston) Date: Wed May 21 14:08:12 2008 Subject: [Haskell-cafe] one-way monads In-Reply-To: <200805210002.06381.dan.doel@gmail.com> References: <625b74080805201047i3ab1b099p929fec3dc3932d48@mail.gmail.com> <20080520232337.lih626q644kwk08o-nwo@fcnzpbc.arg@webmail.spamcop.net> <200805210002.06381.dan.doel@gmail.com> Message-ID: <4834669C.5020407@imageworks.com> Dan Doel wrote: > On Tuesday 20 May 2008, ajb@spamcop.net wrote: >> Actually, it's true less than 50% of the time. In particular, it's >> not true of any monad transformer. > > Sure it is. Any particular transformer t typically comes with some particular > way of writing a function of type t m a -> m a (you may have to throw away > some t-related stuff, of course). > > Since a specific transformed monad is built from a specific monad, and a > specific transformer, and specific transformers are likely to have a function > of type t m a -> m a, and specific monads are likely to have functions of > type m a -> a, you can compose them to get a function of type t m a -> a for > the specific monad t m. And so on for transformed-transformed monads. :) > > That only fails if either of the specific pieces fails to have the right > function, which happens well under 50% of the time, I think (IO and STM are > the ones that immediately occur to me (barring a certain evil function), > although you could make a case for ST by technicality; no failing > transformers come to mind (except CCT if we're counting ST), but I haven't > wracked my brain very hard). > > -- Dan The claim was "less than 50% of the time", not "less than 50% of the monads in the standard libraries". I wonder what fraction of monads in real code the IO monad alone accounts for? 50% does not seem implausible to me. Dan Weston From olivier.boudry at gmail.com Wed May 21 14:31:09 2008 From: olivier.boudry at gmail.com (Olivier Boudry) Date: Wed May 21 14:24:29 2008 Subject: [Haskell-cafe] Newbie: State monad example questions In-Reply-To: <53396d9e0805210810m6f48596jde8e98f7394403c6@mail.gmail.com> References: <53396d9e0805191404va8cb2d7yeb36954b83ac5ca8@mail.gmail.com> <53396d9e0805210542n667d6596uca6b8caf89e30219@mail.gmail.com> <53396d9e0805210810m6f48596jde8e98f7394403c6@mail.gmail.com> Message-ID: On Wed, May 21, 2008 at 11:10 AM, Dmitri O.Kondratiev wrote: > But how will 'g1' actually get delivered from 'makeRandomValueST g1' to > invocation of 'getAny' I don't yet understand! > > It may be easier to understand the state passing if you remove the do notation and replace get, put and return with their definition in the instance declarations (Monad and MonadState). getAny :: (Random a) => State StdGen a getAny = do g <- get (x,g') <- return $ random g put g' return x get = State $ \s -> (s, s) -- copy the state as a return value and pass state put s = State $ \_ -> ((), s) -- return unit, ignore the passed state and replace it with the state given as parameter. return a = State $ \s -> (a, s) -- return given value and pass state. getAnyNoSugar :: (Random a) => State StdGen a getAnyNoSugar = (State $ \s -> (s, s)) >>= \g -> (State $ \s -> (random g, s)) >>= \(x,g') -> (State $ \_ -> ((), g')) >> (State $ \s -> (x, s)) The function is still useable this way and the state transformations should be a bit more visible. The first element of the tuple is the value that will be used to call the next function (of type Monad m => a -> m b). The second element of the tuple is the state and the (>>=) operator will handle passing it between actions. Desugaring the (>>=) and (>>) operators would give you something like this (I replaced `s` with `y` in the `put` and `return` desugaring and simplified it): State $ \s = let (g, s') = (\y -> (y,y)) s ((x,g'), s'') = (\y -> (random g, y)) s' (_, s''') = (\_ -> ((), g')) s'' in (x, s''') Which is explict state passing between function calls. Extract the State using `runState`, run it with an initial state and it should give you the expected result. Regards, Olivier. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080521/034151c9/attachment.htm From andrewcoppin at btinternet.com Wed May 21 15:10:45 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Wed May 21 16:21:26 2008 Subject: [Haskell-cafe] MD5 performance optimizations In-Reply-To: <5a376f550805201312l5ff5ff40g7f84e776ba05cf6c@mail.gmail.com> References: <5a376f550805200241i3bb57e39sa0cb56e9fb28624b@mail.gmail.com> <20080520174837.GD9426@scytale.galois.com> <5a376f550805201312l5ff5ff40g7f84e776ba05cf6c@mail.gmail.com> Message-ID: <483473B5.7090509@btinternet.com> Woo! Salvatore kindly sent me a Darcs patch, and applying it does indeed make it run faster. Yay! [Note that -fvia-c works just fine for me. It doesn't appear to produce a huge speed difference, but it compiles just fine.] Thanks for the tips, guys! :-D The changes are in the online Darcs repo. From kirby81 at gmail.com Wed May 21 16:40:11 2008 From: kirby81 at gmail.com (Salvatore Insalaco) Date: Wed May 21 16:33:31 2008 Subject: [Haskell-cafe] MD5 performance optimizations In-Reply-To: <483473B5.7090509@btinternet.com> References: <5a376f550805200241i3bb57e39sa0cb56e9fb28624b@mail.gmail.com> <20080520174837.GD9426@scytale.galois.com> <5a376f550805201312l5ff5ff40g7f84e776ba05cf6c@mail.gmail.com> <483473B5.7090509@btinternet.com> Message-ID: <5a376f550805211340p3b647b11r6dfdeb0452de42b8@mail.gmail.com> 2008/5/21 Andrew Coppin : > Woo! > > Salvatore kindly sent me a Darcs patch, and applying it does indeed make it > run faster. Yay! Hi Andrew, I'm glad that -fvia-c works for you: maybe it's a Mac OS X specific bug? Anyway, did you compile with -fvia-c -optc-O3? I expect register-intensive code like this to be at least 20% faster with gcc. Salvatore From dokondr at gmail.com Wed May 21 18:19:56 2008 From: dokondr at gmail.com (Dmitri O.Kondratiev) Date: Wed May 21 18:13:16 2008 Subject: [Haskell-cafe] Newbie: State monad example questions In-Reply-To: References: <53396d9e0805191404va8cb2d7yeb36954b83ac5ca8@mail.gmail.com> <53396d9e0805210542n667d6596uca6b8caf89e30219@mail.gmail.com> <53396d9e0805210810m6f48596jde8e98f7394403c6@mail.gmail.com> Message-ID: <53396d9e0805211519x71d77df9gb39d7c59203d57ac@mail.gmail.com> -- Jules, Oliver, thanks! Things are getting clarified, I hope. -- Let me summarize how I now understand getAny operation, please correct me if I am wrong. getAny :: (Random a) => State StdGen a getAny = do g <- get (x,g') <- return $ random g put g' return x {-- getAny operation may be abbreviated as: do { -- 1) x calculation, equivalent to (x,g2) = random g1 -- 2) return x ~> State $ \s -> (x,s) -- puts x into State container Thus getAny returns a State instantiated with a function which is a composition of several binds <<= from the above 'do' block and which calculates 'x' --} -- Then we can use this State object (returned by getAny) in a function generating random values such as: makeRnd :: StdGen -> (Int, StdGen) makeRnd = runState (do y <- getAny return y) {-- where: y <- getAny return y passes a first value from the tuple generated by getAny State function into 'y' and puts 'y' into a new State object. After that 'runState' in makeRnd extracts from this new State a function parametrized by 'y' value. As a result we get curried 'makeRnd' which we can call with some generator instance and get a random value. --} On Wed, May 21, 2008 at 10:31 PM, Olivier Boudry wrote: > On Wed, May 21, 2008 at 11:10 AM, Dmitri O.Kondratiev > wrote: > >> But how will 'g1' actually get delivered from 'makeRandomValueST g1' to >> invocation of 'getAny' I don't yet understand! >> >> > It may be easier to understand the state passing if you remove the do > notation and replace get, put and return with their definition in the > instance declarations (Monad and MonadState). > > getAny :: (Random a) => State StdGen a > getAny = do g <- get > (x,g') <- return $ random g > put g' > return x > > get = State $ \s -> (s, s) -- copy the state as a return value and pass > state > put s = State $ \_ -> ((), s) -- return unit, ignore the passed state and > replace it with the state given as parameter. > return a = State $ \s -> (a, s) -- return given value and pass state. > > getAnyNoSugar :: (Random a) => State StdGen a > getAnyNoSugar = (State $ \s -> (s, s)) >>= \g -> > (State $ \s -> (random g, s)) >>= \(x,g') -> > (State $ \_ -> ((), g')) >> > (State $ \s -> (x, s)) > > The function is still useable this way and the state transformations should > be a bit more visible. The first element of the tuple is the value that will > be used to call the next function (of type Monad m => a -> m b). The second > element of the tuple is the state and the (>>=) operator will handle passing > it between actions. > > Desugaring the (>>=) and (>>) operators would give you something like this > (I replaced `s` with `y` in the `put` and `return` desugaring and simplified > it): > > State $ \s = let > (g, s') = (\y -> (y,y)) s > ((x,g'), s'') = (\y -> (random g, y)) s' > (_, s''') = (\_ -> ((), g')) s'' > in (x, s''') > > Which is explict state passing between function calls. Extract the State > using `runState`, run it with an initial state and it should give you the > expected result. > > Regards, > > Olivier. > -- Dmitri O. Kondratiev dokondr@gmail.com http://www.geocities.com/dkondr -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080522/a7eb43b7/attachment.htm From vigalchin at gmail.com Wed May 21 18:32:07 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Wed May 21 18:25:26 2008 Subject: [Haskell-cafe] Ubuntu and ghc Message-ID: <5ae4f2ba0805211532l35bef8eas9a10ff6df3e0f843@mail.gmail.com> Hello, https://bugs.launchpad.net/ubuntu/+source/gtk2hs/+bug/229489 .... this is almost identical to my problem. I am just trying to help others on this list who are using Ubuntu Linux to avoid my predicament! Kind regards, Vasili -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080521/4e162c88/attachment.htm From westondan at imageworks.com Wed May 21 18:45:22 2008 From: westondan at imageworks.com (Dan Weston) Date: Wed May 21 18:38:42 2008 Subject: [Haskell-cafe] Ubuntu and ghc In-Reply-To: <5ae4f2ba0805211532l35bef8eas9a10ff6df3e0f843@mail.gmail.com> References: <5ae4f2ba0805211532l35bef8eas9a10ff6df3e0f843@mail.gmail.com> Message-ID: <4834A602.8070808@imageworks.com> Now you tell me! I also upgraded late last night and got the exact same problem. :( I just uninstalled the ghc from the Update Manager and was going to reinstall tonight. Are you saying that something else is screwed up because of this? Galchin, Vasili wrote: > Hello, > > https://bugs.launchpad.net/ubuntu/+source/gtk2hs/+bug/229489 .... > this is almost identical to my problem. I am just trying to help others > on this list who are using Ubuntu Linux to avoid my predicament! > > Kind regards, Vasili > > > ------------------------------------------------------------------------ > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From vigalchin at gmail.com Wed May 21 18:47:46 2008 From: vigalchin at gmail.com (Galchin, Vasili) Date: Wed May 21 18:41:06 2008 Subject: [Haskell-cafe] Ubuntu and ghc In-Reply-To: <4834A602.8070808@imageworks.com> References: <5ae4f2ba0805211532l35bef8eas9a10ff6df3e0f843@mail.gmail.com> <4834A602.8070808@imageworks.com> Message-ID: <5ae4f2ba0805211547x6a3d65fdwbf80948f403668bc@mail.gmail.com> Hi Dan, I am still looking into this myself. I just stumbled across the URL below. i would suggest keeping an eye on this URL for more news. Vasili On Wed, May 21, 2008 at 5:45 PM, Dan Weston wrote: > Now you tell me! I also upgraded late last night and got the exact same > problem. :( > > I just uninstalled the ghc from the Update Manager and was going to > reinstall tonight. Are you saying that something else is screwed up because > of this? > > Galchin, Vasili wrote: > >> Hello, >> >> https://bugs.launchpad.net/ubuntu/+source/gtk2hs/+bug/229489 .... >> this is almost identical to my problem. I am just trying to help others on >> this list who are using Ubuntu Linux to avoid my predicament! >> >> Kind regards, Vasili >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080521/578237ce/attachment.htm From marco-oweber at gmx.de Wed May 21 19:04:24 2008 From: marco-oweber at gmx.de (Marc Weber) Date: Wed May 21 18:57:46 2008 Subject: [Haskell-cafe] relational data representation in memory using haskell? Message-ID: <20080521230424.GA3729@gmx.de> I'm kind of stuck that's why I'm posting here to ask wether this makes sense at all, maybe someone else has already done it? What I'd like to have: Some way representing relational data which is typically stored in databases such as Postgresql.. Rewriting something like Postgresql in haskell would take ages.. So I'd be satisfied with having in memory representation only (this would fit the HAppS state system very well .. :) Why ? * type safety * less conversions compared to SQL data * no need to switch processes, parse SQL etc so maybe it's even faster? (a small benchmark showed that inserting 20000 Ints into a list was 8 times faster than using MySQL parsing 20000 INSERT INTO x (1) statements ) I'd like to illustrate two different ideas using a small example: (A) data CD = CD { title :: String, tracks :: [ Track ] } data Track = Track { track :: String, cd :: CD } data PDB = PDB { cds :: Set CD, tracks :: Set Track } because it's not using foreign ids but kind of pointers I'll call this the pointer method using uniq ids it would look like this: (B) data CD = CD { id : Int, title :: String, tracks :: [Int ] } data Track = Track { trackId :: Int, track :: String, cd :: Int } data IDB = IDB { cds :: Map Int CD, tracks :: Map Int Track } I will call it I DB (I = using ids) PDB: pro : * less work when doing joins (no need to look foreign rows up) con : * you need uniq ids or such when serializing to disk * When updating a track you'll also have to update the pointer stored in cds. and if you had another table shelfs.. this had to be updated as well.. IDB: the other way round I find the idea not using any lookups when using joins appealing. Of course having a simple data Table = Table Map UniqId Rec isn't enough, sometimes you need more than one index or even a multi index: data Table = Table { byId :: Map Int Rec , byNameAndAge :: Map String (Map Int (Set Rec)) } Note that I've used Set here as well because this index does'nt have to be uniq! starting to write an insertTable :: Table -> Rec -> Table more than twice is getting tedious.. Of course you can start using some type hackery to insert a rec into all maps automatically.. but you'll get into trouble making the type system apply the best index not the first matching one. (I bet this could be done using HList etc somehow as well.. ) So my current attempt is defining the database using some data types and make template haskell derive those insertIntoTable and update functions. I've added the draft below. But before continuing spending much time on it I'd like to get your advice: Is there a chance that it will pay off? Some general considerations: haskell solution con: haskell can get close to C but in general it may be >10 times slower when not caring too much about design or writing low level (see recent thread about md5 or one where David Roundy has said something about a matrix thread: only 10 times slower?) Using a garbage collector on database data (some hundred MB) might not be the optimal way because I feel you can tell exactly when you no longer need a piece of allocated memory here? So some time might be wasted. projects tend to run longer as expected.. And if data no longer fits into memory .. :(... -> bad performance I think systems such as postgresql do scale much better if you have some gbs of data and only use the most recent X records frequently.. So maybe you'll have to spend time later which you've won by using a haskell relational data representation in memory only.. Another solution: use clusters - I don't have any experience. pro: much more safety (STM, type system ..) there are less possibilities making compared to C / PHP etc Do you also think (A) is more interesting because some load (looking up foreign keys) is moved on insert / delete and update operations taking less time in but are called more frequently thus maybe reducing peak load on queries? Of course some time would have to be spend on queries wich might look like this: let queryresult = $(query ( tables + constraints + relations ) ) db automatically generating the query function taking into account expected index cardinality etc.. Any comments, suggestions, links to existing solutions (except coddfish, haskelldb) ? Marc Weber draft ============= types represeting tables and db ======================== module RDMH.Types where import Language.Haskell.TH import Language.Haskell.TH.Syntax data Uniqueness = Uniq | NotUniq deriving (Show, Eq) data ModifyMode = InsertOnly | UpdateInsert | UpdateInsertDelete deriving (Show, Eq) type TypeS = String -- a name of a data type (data A = ..) data Index = I { uniqueness :: Uniqueness , key :: Exp -- a fuction rec -> key , subkeys :: [ Index ] , keyType :: TypeS -- the key type (this *should* be determined by the function.. But I don't know yet how to do it.. Probably using some GHC API magic -- , expectedCardinality :: Int -- how should this look like exactly? This will be used to select the best indexes } deriving (Show, Eq) -- Int is negative weight / cardinality. -- If you issue a query having two contstraints on types beeing indexed the one having biggest cardinality is taken first -- first type:` -- convinient function to get the type of a name - see TestCase.hs t = ConT . mkName -- type (either key or row) k = VarE . mkName -- gets the key -- app (VarE $ mkName "fst" ) -- a table representation data Table = Table { tableName :: String , row :: TypeS -- this row type must be an instance of Eq , indexes :: [ Index ] -- [ ( [ mkName "Int", mkName "String" ]] is represented as Map Int ( Map String rec ) -- , history :: Bool -- to be implemented. Each time a record is updated the original row should be saved somehow somewhere , modify :: ModifyMode -- , insertTimeStamp :: Bool -- , updateTimeStamp :: Bool } deriving (Eq, Show) data DB = DB { dbName :: String , tables :: [ Table ] , oneToN :: [ (Table, Table, String) ] -- String must be set if you want two relations to the same table (eg one ticket has foreign inbound and outbound flight) -- , nToM :: [ ( Table, Table ) ] } ============= example use case ======================================= {-# OPTIONS_GHC -XTemplateHaskell #-} module TestCase where import Language.Haskell.TH import RDMH.Types import RDMH.TH import Data.Time -- the data data RCD = CD { title :: String , artist :: String , year :: Int } data RTrack = Track { trackTitle :: String , recordingDate :: UTCTime } -- a track table with two indexes title and recordingDate trackT = Table "track" (t "RTrack") -- row type -- indexes: [ I NotUniq (k "trackTitle" ) [] (t "String") , I NotUniq (k "recordingDate" ) [] (t "UTCTime") ] UpdateInsertDelete -- a cd table with two indexes title and year cdT = Table "cd" (t "RCD" ) -- row type -- indexes: [ I Uniq (k "title" ) [] (t "String") , I NotUniq (k "year" ) [] (t "Int") ] UpdateInsertDelete -- the db: both tables and a simple relation db = DB "cdDB" [ cdT, trackT ] [ OneToN cdT trackT "" ) ] $(createDB db) From lennart at augustsson.net Wed May 21 19:08:44 2008 From: lennart at augustsson.net (Lennart Augustsson) Date: Wed May 21 19:02:04 2008 Subject: [Haskell-cafe] one-way monads In-Reply-To: <4834669C.5020407@imageworks.com> References: <625b74080805201047i3ab1b099p929fec3dc3932d48@mail.gmail.com> <200805210002.06381.dan.doel@gmail.com> <4834669C.5020407@imageworks.com> Message-ID: I certainly don't use 50% IO monads. I regard any use of the IO monad except at the top level as a failure. :) On Wed, May 21, 2008 at 7:14 PM, Dan Weston wrote: > Dan Doel wrote: >> >> On Tuesday 20 May 2008, ajb@spamcop.net wrote: >>> >>> Actually, it's true less than 50% of the time. In particular, it's >>> not true of any monad transformer. >> >> Sure it is. Any particular transformer t typically comes with some >> particular way of writing a function of type t m a -> m a (you may have to >> throw away some t-related stuff, of course). >> >> Since a specific transformed monad is built from a specific monad, and a >> specific transformer, and specific transformers are likely to have a >> function of type t m a -> m a, and specific monads are likely to have >> functions of type m a -> a, you can compose them to get a function of type t >> m a -> a for the specific monad t m. And so on for transformed-transformed >> monads. :) >> >> That only fails if either of the specific pieces fails to have the right >> function, which happens well under 50% of the time, I think (IO and STM are >> the ones that immediately occur to me (barring a certain evil function), >> although you could make a case for ST by technicality; no failing >> transformers come to mind (except CCT if we're counting ST), but I haven't >> wracked my brain very hard). >> >> -- Dan > > The claim was "less than 50% of the time", not "less than 50% of the monads > in the standard libraries". I wonder what fraction of monads in real code > the IO monad alone accounts for? 50% does not seem implausible to me. > > Dan Weston > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From dons at galois.com Wed May 21 19:15:35 2008 From: dons at galois.com (Don Stewart) Date: Wed May 21 19:09:04 2008 Subject: [Haskell-cafe] one-way monads In-Reply-To: References: <625b74080805201047i3ab1b099p929fec3dc3932d48@mail.gmail.com> <200805210002.06381.dan.doel@gmail.com> <4834669C.5020407@imageworks.com> Message-ID: <20080521231535.GD17923@scytale.galois.com> lennart: > I certainly don't use 50% IO monads. I regard any use of the IO monad > except at the top level as a failure. :) IO fail -- Don Background: http://failblog.org/ From dpiponi at gmail.com Wed May 21 19:34:05 2008 From: dpiponi at gmail.com (Dan Piponi) Date: Wed May 21 19:27:41 2008 Subject: [Haskell-cafe] one-way monads In-Reply-To: References: <625b74080805201047i3ab1b099p929fec3dc3932d48@mail.gmail.com> <200805210002.06381.dan.doel@gmail.com> <4834669C.5020407@imageworks.com> Message-ID: <625b74080805211634i4a59d8c0ia337c7167438206@mail.gmail.com> On Wed, May 21, 2008 at 4:08 PM, Lennart Augustsson wrote: > I certainly don't use 50% IO monads. I regard any use of the IO monad > except at the top level as a failure. :) Real Haskell Programmers Only Use Top Level IO! (But then again, real programmers wouldn't use Haskell: http://www.pbm.com/~lindahl/real.programmers.html) -- Dan From ndmitchell at gmail.com Wed May 21 19:37:57 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Wed May 21 19:31:16 2008 Subject: [Haskell-cafe] one-way monads In-Reply-To: <625b74080805211634i4a59d8c0ia337c7167438206@mail.gmail.com> References: <625b74080805201047i3ab1b099p929fec3dc3932d48@mail.gmail.com> <200805210002.06381.dan.doel@gmail.com> <4834669C.5020407@imageworks.com> <625b74080805211634i4a59d8c0ia337c7167438206@mail.gmail.com> Message-ID: <404396ef0805211637n292410e9yd33307dadb7946c4@mail.gmail.com> Hi > Real Haskell Programmers Only Use Top Level IO! > > (But then again, real programmers wouldn't use Haskell: > http://www.pbm.com/~lindahl/real.programmers.html) It's amazing how many phone interviews I've done where the HR person at the other end tries to tick the "knows Pascal" box, despite me trying my hardest to pronounce Hhhhhhhhhaskell. Maybe Haskell == Pascal, under some fairly light equality.... Thanks Neil From wchogg at gmail.com Wed May 21 19:42:51 2008 From: wchogg at gmail.com (Creighton Hogg) Date: Wed May 21 19:36:10 2008 Subject: [Haskell-cafe] one-way monads In-Reply-To: <404396ef0805211637n292410e9yd33307dadb7946c4@mail.gmail.com> References: <625b74080805201047i3ab1b099p929fec3dc3932d48@mail.gmail.com> <200805210002.06381.dan.doel@gmail.com> <4834669C.5020407@imageworks.com> <625b74080805211634i4a59d8c0ia337c7167438206@mail.gmail.com> <404396ef0805211637n292410e9yd33307dadb7946c4@mail.gmail.com> Message-ID: <814617240805211642q152fdc8eqaeb426dad9c05622@mail.gmail.com> On Wed, May 21, 2008 at 6:37 PM, Neil Mitchell wrote: > Hi > > > Real Haskell Programmers Only Use Top Level IO! > > > > (But then again, real programmers wouldn't use Haskell: > > http://www.pbm.com/~lindahl/real.programmers.html > ) > > It's amazing how many phone interviews I've done where the HR person > at the other end tries to tick the "knows Pascal" box, despite me > trying my hardest to pronounce Hhhhhhhhhaskell. Maybe Haskell == > Pascal, under some fairly light equality.... > > Thanks > > Neil > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > I've had the same experience! I don't swallow my 'h's in the slightest, so I'm presuming that it's just overly eager pattern matching. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080521/4fca2777/attachment.htm From jeremy at n-heptane.com Wed May 21 20:05:21 2008 From: jeremy at n-heptane.com (Jeremy Shaw) Date: Wed May 21 19:57:56 2008 Subject: [Haskell-cafe] relational data representation in memory using haskell? In-Reply-To: <20080521230424.GA3729@gmx.de> References: <20080521230424.GA3729@gmx.de> Message-ID: <87abijp5j2.wl%jeremy@n-heptane.com> At Thu, 22 May 2008 01:04:24 +0200, Marc Weber wrote: > Some way representing relational data which is typically stored in > databases such as Postgresql.. > > Rewriting something like Postgresql in haskell would take ages.. > So I'd be satisfied with having in memory representation only (this > would fit the HAppS state system very well .. :) Are you familiar with the HAppS IxSet library? You would do something like: $( deriveAll [''Ord,''Eq,''Read,''Show,''Default] [d| data CD = CD AlbumTitle Artist [Track] newtype Artist = Artist String newtype AlbumTitle = AlbumTitle String data Track = Track TrackTitle TrackIndex newtype TrackIndex = TrackIndex Int newtype TrackTitle = TrackTitle String |]) $(inferIxSet "CDS" 'noCalcs [''AlbumTitle, ''TrackTitle, ''Artist]) This creates a table with indexs on AlbumTitle, TrackTitle, and Artist. You can do a simple query like: mycds @= (Artist "Wesley Willis") to get all the tracks by Wesley Willis. You should be able to build joins, etc on top of that. j. From darrinth at gmail.com Wed May 21 20:21:09 2008 From: darrinth at gmail.com (Darrin Thompson) Date: Wed May 21 20:14:29 2008 Subject: [Haskell-cafe] Ubuntu and ghc In-Reply-To: <5ae4f2ba0805211547x6a3d65fdwbf80948f403668bc@mail.gmail.com> References: <5ae4f2ba0805211532l35bef8eas9a10ff6df3e0f843@mail.gmail.com> <4834A602.8070808@imageworks.com> <5ae4f2ba0805211547x6a3d65fdwbf80948f403668bc@mail.gmail.com> Message-ID: 2008/5/21 Galchin, Vasili : > Hi Dan, > > I am still looking into this myself. I just stumbled across the URL > below. i would suggest keeping an eye on this URL for more news. > I quit using the ubuntu debs. I've just been downloading the linux binaries and runing them in some odd subdir, and using --prefix=/path/to/my/ghc with cabal, and much happier for it. Is there some value with the official debs that I'm missing? -- Darrin From marco-oweber at gmx.de Wed May 21 20:48:43 2008 From: marco-oweber at gmx.de (Marc Weber) Date: Wed May 21 20:42:04 2008 Subject: [Haskell-cafe] relational data representation in memory using haskell? In-Reply-To: <87abijp5j2.wl%jeremy@n-heptane.com> References: <20080521230424.GA3729@gmx.de> <87abijp5j2.wl%jeremy@n-heptane.com> Message-ID: <20080522004843.GA29778@gmx.de> On Wed, May 21, 2008 at 05:05:21PM -0700, Jeremy Shaw wrote: > At Thu, 22 May 2008 01:04:24 +0200, > Marc Weber wrote: > > > Some way representing relational data which is typically stored in > > databases such as Postgresql.. > > > > Rewriting something like Postgresql in haskell would take ages.. > > So I'd be satisfied with having in memory representation only (this > > would fit the HAppS state system very well .. :) > > Are you familiar with the HAppS IxSet library? Yes - not with all that sybwith-class stuff though. There are some issues: its dynamic : doesn't this waste some CPU cycles? no multi indexes.. maybe some space leaks because the data type containing the Maps is build after each filter maybe leaving unevaluating chunks - Saizan has told me about it on HAppS.. And you can't extend it to the degree I'd like to (eg throw a query at it and let the system figure out which indexes to use) And last but not least: It does'nt support relations at all yet. So all the effort adding / checking foreign keys etc has to be done anyway. Thanks Marc From westondan at imageworks.com Wed May 21 21:07:15 2008 From: westondan at imageworks.com (Dan Weston) Date: Wed May 21 21:00:34 2008 Subject: [Haskell-cafe] relational data representation in memory using haskell? In-Reply-To: <20080522004843.GA29778@gmx.de> References: <20080521230424.GA3729@gmx.de> <87abijp5j2.wl%jeremy@n-heptane.com> <20080522004843.GA29778@gmx.de> Message-ID: <4834C743.5080807@imageworks.com> Consider SQLite [1], which is "a software library that implements a self-contained, serverless, zero-configuration, transactional SQL database engine." It is embeddable, can reside completely in memory (including the data), and can be saved and restored to disk when needed. It neatly fills the niche between maps and a client/server database model. It has a C API which you can wrap as needed with the FFI, and you wouldn't need more than a dozen or so functions to start with (it understands SQL too). [1] http://www.sqlite.org/ Marc Weber wrote: > On Wed, May 21, 2008 at 05:05:21PM -0700, Jeremy Shaw wrote: >> At Thu, 22 May 2008 01:04:24 +0200, >> Marc Weber wrote: >> >>> Some way representing relational data which is typically stored in >>> databases such as Postgresql.. >>> >>> Rewriting something like Postgresql in haskell would take ages.. >>> So I'd be satisfied with having in memory representation only (this >>> would fit the HAppS state system very well .. :) >> Are you familiar with the HAppS IxSet library? > Yes - not with all that sybwith-class stuff though. > There are some issues: > its dynamic : doesn't this waste some CPU cycles? > no multi indexes.. > maybe some space leaks because the data type containing the Maps is > build after each filter maybe leaving unevaluating chunks - Saizan has > told me about it on HAppS.. And you can't extend it to the degree I'd > like to (eg throw a query at it and let the system figure out which > indexes to use) > And last but not least: It does'nt support relations at all yet. > So all the effort adding / checking foreign keys etc has to be done > anyway. > > Thanks Marc > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From kirby81 at gmail.com Thu May 22 02:16:54 2008 From: kirby81 at gmail.com (Salvatore Insalaco) Date: Thu May 22 02:10:13 2008 Subject: [Haskell-cafe] relational data representation in memory using haskell? In-Reply-To: <20080521230424.GA3729@gmx.de> References: <20080521230424.GA3729@gmx.de> Message-ID: <5a376f550805212316k5dbfd172t447a1f115707ac8b@mail.gmail.com> 2008/5/22 Marc Weber : > I'd like to illustrate two different ideas using a small example: > (A) > data CD = CD { title :: String, tracks :: [ Track ] } > data Track = Track { track :: String, cd :: CD } > data PDB = PDB { cds :: Set CD, tracks :: Set Track } > > because it's not using foreign ids but kind of pointers I'll call this > the pointer method This doesn't look like a relational structure at all in Haskell. Let's take the CD and Track relations. In a relational database you have something like: CD (1, 'Querying about you') Track (1, 'Inserting some love', 1) Track (2, 'Updating my feelings', 1) Track (3, 'Deleting my hopes', 1) In an imperative language you can do something similar in memory using objects (you can in haskell to with IORefs and so on, but let's stay on "data"). You get something like: 0x000 CD('Querying about you') 0x004 Track('Inserting some love, 0x004) ... In Haskell when you say: > data Track = Track { track :: String, cd :: CD } You are not storing in Track a reference, a pointer or something similar to a CD, you are storing a *value* (low level you probably have a pointer, but you have not pointer semantics). As you noticed, you cannot "update" the CD title without changing each Track. That's a way to store information, and a good way too, but it's not a relational structure by any extent. If you want to use this structure for your relational data you need two things: 1) Something that will convert from a value-based representation of data to something relational (aka ORM in the OO world... a FRM? VRM?). 2) A relational storage (internal or external). If you want to use "normal" Haskell ADT, are you sure that a relational storage is what you want? Keeping that in memory doesn't give you some advantages of relational databases (e.g. uniform representation), and the impedance between the functional and the relational world is not easy to manage. Maybe I misunderstood what you are trying to accomplish, and you only want to do a generic data structure with fast lookups on the content of the items? Or do you really need relational semantics? Salvatore From marco-oweber at gmx.de Thu May 22 03:37:02 2008 From: marco-oweber at gmx.de (Marc Weber) Date: Thu May 22 03:30:22 2008 Subject: [Haskell-cafe] relational data representation in memory using haskell? In-Reply-To: <5a376f550805212316k5dbfd172t447a1f115707ac8b@mail.gmail.com> References: <20080521230424.GA3729@gmx.de> <5a376f550805212316k5dbfd172t447a1f115707ac8b@mail.gmail.com> Message-ID: <20080522073702.GB29778@gmx.de> On Thu, May 22, 2008 at 08:16:54AM +0200, Salvatore Insalaco wrote: > 2008/5/22 Marc Weber : > > I'd like to illustrate two different ideas using a small example: > > (A) > > data CD = CD { title :: String, tracks :: [ Track ] } > > data Track = Track { track :: String, cd :: CD } > > data PDB = PDB { cds :: Set CD, tracks :: Set Track } > > > > because it's not using foreign ids but kind of pointers I'll call this > > the pointer method > > This doesn't look like a relational structure at all in Haskell. > Let's take the CD and Track relations. In a relational database you > have something like: > CD (1, 'Querying about you') > Track (1, 'Inserting some love', 1) > Track (2, 'Updating my feelings', 1) > Track (3, 'Deleting my hopes', 1) > > In an imperative language you can do something similar in memory using > objects (you can in haskell to with IORefs and so on, but let's stay > on "data"). You get something like: > > 0x000 CD('Querying about you') > 0x004 Track('Inserting some love, 0x004) You are right. But ghc does represent those things as pointers.. :) So it is indeed unless you ask ghc to not use (eg by using strict fields etc), correct? IORefs are not that good because you can't read them within STM. But you are right: Using IORefs was my first idea. > similar to a CD, you are storing a *value* (low level you probably > have a pointer, but you have not pointer semantics). As you noticed, > you cannot "update" the CD title without changing each Track. That's a > way to store information, and a good way too, but it's not a > relational structure by any extent. I agree it's not in general and higly implementation dependant Maybe I'm totally wrong. I imagine ghc having some internal representation of data types which come close to struct CD { Track * tracks; title ** char; } cd; struct Track { cd * CD; title ** char; } track; (does'nt compile but you get the idea. My C knowldge is good enough for reading only). So if you start seeing the whole database as list of connected structs vio pointers adding / deleting/ inserting is quite the same as adding some nodes to a Data.Map. You replace the nodes you have to replace and finally get a poiter pointing to te new database state. As long as you don't loose the original "pointer" you can easily rollpack. Consider let x = Cd ... forkIO $ ( do something with x } -- (1) print x -- (2) How can ghc know when running line (2) that (1) hasen't changed the record? I see two solutions: a) give the forked process a copy (Then my design will collapse) but this is expensive to copy data without knowing you ned to b) use pointers and replace x ony on updating. Thus if (1) changes the title a new struct wil be created poiting to the old list but a new title String. line (2) doesn't have to care at all. I'm guessing that analyzing a) when values have to be copied is complicated - thus b) is implemented ? quicksilver has told me so as well - But I'm not sure that's why I'm asking. > If you want to use "normal" Haskell ADT, are you sure that a > relational storage is what you want? Keeping that in memory doesn't > give you some advantages of relational databases (e.g. uniform > representation), and the impedance between the functional and the > relational world is not easy to manage. > > Maybe I misunderstood what you are trying to accomplish, and you only > want to do a generic data structure with fast lookups on the content > of the items? Exactly.. Of course I only want a generic data structure with fast lookups and content of items.. But I don't want to write the insert delete and update functions for each table again and again.. Does this already exist? Marc Weber From marco-oweber at gmx.de Thu May 22 03:41:29 2008 From: marco-oweber at gmx.de (Marc Weber) Date: Thu May 22 03:34:49 2008 Subject: [Haskell-cafe] relational data representation in memory using haskell? In-Reply-To: <4834C743.5080807@imageworks.com> References: <20080521230424.GA3729@gmx.de> <87abijp5j2.wl%jeremy@n-heptane.com> <20080522004843.GA29778@gmx.de> <4834C743.5080807@imageworks.com> Message-ID: <20080522074129.GC29778@gmx.de> On Wed, May 21, 2008 at 06:07:15PM -0700, Dan Weston wrote: > Consider SQLite [1], which is "a software library that implements a [..] > It has a C API which you can wrap as needed with the FFI, and you wouldn't > need more than a dozen or so functions to start with (it understands SQL > too). So it has kind of API enabling me inserting rows without using SQL? I still have to do some marshalling to / from C and synchronize db layout and haskell data types. Marc Weber From ketil at malde.org Thu May 22 04:56:03 2008 From: ketil at malde.org (Ketil Malde) Date: Thu May 22 04:49:23 2008 Subject: [Haskell-cafe] relational data representation in memory using haskell? In-Reply-To: <5a376f550805212316k5dbfd172t447a1f115707ac8b@mail.gmail.com> (Salvatore Insalaco's message of "Thu\, 22 May 2008 08\:16\:54 +0200") References: <20080521230424.GA3729@gmx.de> <5a376f550805212316k5dbfd172t447a1f115707ac8b@mail.gmail.com> Message-ID: <871w3u3efw.fsf@nmd9999.imr.no> "Salvatore Insalaco" writes: > This doesn't look like a relational structure at all in Haskell. I believe you are abusing terminology here. 'Relation' refers to a table (since it represents a subset of AxBxC.., i.e. a relation), not to references between tables. Mutability and mutability of references is of course important in most relational databases, but I'm not convinced an immutable database wouldn't be interesting and useful in a functional programming language. I've always (well not that I use them often) been annoyed at RDBMS lack of discriminated unions. The TH based approach by HAppS looks cool, but I think simply a slightly more general Data.Map (supporting multiple indices, search by named field and so on) could be a useful thing. -k -- If I haven't seen further, it is by standing in the footprints of giants From kirby81 at gmail.com Thu May 22 05:01:01 2008 From: kirby81 at gmail.com (Salvatore Insalaco) Date: Thu May 22 04:55:00 2008 Subject: [Haskell-cafe] relational data representation in memory using haskell? In-Reply-To: <20080522073702.GB29778@gmx.de> References: <20080521230424.GA3729@gmx.de> <5a376f550805212316k5dbfd172t447a1f115707ac8b@mail.gmail.com> <20080522073702.GB29778@gmx.de> Message-ID: <5a376f550805220201v65f8c967pfe6687aaf9f3d86d@mail.gmail.com> > Consider > > let x = Cd ... > forkIO $ ( do something with x } -- (1) > print x -- (2) > > How can ghc know when running line (2) that (1) hasen't changed the > record? I see two solutions: > a) give the forked process a copy (Then my design will collapse) > but this is expensive to copy data without knowing you ned to > b) use pointers and replace x ony on updating. Thus if (1) changes the > title a new struct wil be created poiting to the old list but a new > title String. line (2) doesn't have to care at all. GHC knows that because in Haskell isn't possible to "update" x. x is not a variable, it's a binding. To put it simply: with IORefs (and STRefs, MVars, ...) you have references to values that you can change (inside their respective monads), much like variables, but data declarations are values, not references to values (even if GHC stores them as pointers you cannot treat them as such), so you cannot update it. So, in your example, you have more or less a relation (CD) where all the "columns" are part of primary key (and so they are not mutable). Salvatore From marco-oweber at gmx.de Thu May 22 05:20:31 2008 From: marco-oweber at gmx.de (Marc Weber) Date: Thu May 22 05:13:51 2008 Subject: [Haskell-cafe] relational data representation in memory using haskell? In-Reply-To: <871w3u3efw.fsf@nmd9999.imr.no> References: <20080521230424.GA3729@gmx.de> <5a376f550805212316k5dbfd172t447a1f115707ac8b@mail.gmail.com> <871w3u3efw.fsf@nmd9999.imr.no> Message-ID: <20080522092031.GA27673@gmx.de> On Thu, May 22, 2008 at 10:56:03AM +0200, Ketil Malde wrote: > "Salvatore Insalaco" writes: > > > This doesn't look like a relational structure at all in Haskell. > > I believe you are abusing terminology here. 'Relation' refers to a Yes. Sorry. I thought the relational in relational databases refers to references between tables. But you a right a relation is a set of rows forming a table. Thanks for clarifying. Thanks Marc From duncan.coutts at worc.ox.ac.uk Thu May 22 05:33:41 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu May 22 05:24:34 2008 Subject: [Haskell-cafe] Ubuntu and ghc In-Reply-To: <5ae4f2ba0805211532l35bef8eas9a10ff6df3e0f843@mail.gmail.com> References: <5ae4f2ba0805211532l35bef8eas9a10ff6df3e0f843@mail.gmail.com> Message-ID: <1211448821.5824.504.camel@localhost> On Wed, 2008-05-21 at 17:32 -0500, Galchin, Vasili wrote: > Hello, > > > https://bugs.launchpad.net/ubuntu/+source/gtk2hs/+bug/229489 .... this > is almost identical to my problem. I am just trying to help others on > this list who are using Ubuntu Linux to avoid my predicament! I had that problem upgrading too. I posted a workaround: http://bugs.launchpad.net/ubuntu/+source/gtk2hs/+bug/229489/comments/9 Duncan From marco-oweber at gmx.de Thu May 22 06:00:44 2008 From: marco-oweber at gmx.de (Marc Weber) Date: Thu May 22 05:54:04 2008 Subject: [Haskell-cafe] relational data representation in memory using haskell? In-Reply-To: <5a376f550805220201v65f8c967pfe6687aaf9f3d86d@mail.gmail.com> References: <20080521230424.GA3729@gmx.de> <5a376f550805212316k5dbfd172t447a1f115707ac8b@mail.gmail.com> <20080522073702.GB29778@gmx.de> <5a376f550805220201v65f8c967pfe6687aaf9f3d86d@mail.gmail.com> Message-ID: <20080522100044.GB27673@gmx.de> Hi Salvatore On Thu, May 22, 2008 at 11:01:01AM +0200, Salvatore Insalaco wrote: > > Consider > > > > let x = Cd ... > > forkIO $ ( do something with x } -- (1) > > print x -- (2) > > > > How can ghc know when running line (2) that (1) hasen't changed the > > record? I see two solutions: > > a) give the forked process a copy (Then my design will collapse) > > but this is expensive to copy data without knowing you ned to > > b) use pointers and replace x ony on updating. Thus if (1) changes the > > title a new struct wil be created poiting to the old list but a new > > title String. line (2) doesn't have to care at all. > > GHC knows that because in Haskell isn't possible to "update" x. x is > not a variable, it's a binding. > To put it simply: with IORefs (and STRefs, MVars, ...) you have > references to values that you can change (inside their respective > monads), much like variables, but data declarations are values, not > references to values (even if GHC stores them as pointers you cannot > treat them as such), so you cannot update it. Sorry - maybe I'm unable to express using the correct terminology.. So I'll just give a small example how I think it could magically work? data CD = CD { title :: String, tracks :: [ Track ] } data Track = Track { track :: String, cd :: CD } data PDB = PDB { cds :: Set CD, tracks :: Set Track } Let's fill the database with 1 track and a cd: 0x3 = pointer to DB rec 0x1: adress of CD 0x5: adress of Track 0x4, 0x9, 0x9: start adress of linked list connected by pointers.. In the final solution should use finger trees or such to speed up deletion / replacing elements 0x3 database: 0x8 cds : tuple1 0x1 : (0x6 "My song") (0x4 [ 0x5, ... ]) ^ pointer to str ^ pointer to track list, 0x5 = pointer to track 0x9 tracks: tuple1 0x5 : ( 0x7 "track 1") 0x1 ^ reference to cd Now I query the track, and "update" it (replacing the title).. It's a little bit tricky, because when updating the track I need to update the cd as well (circular referency). All new pointers are starting from 0x20 So in haskell it would look like this: let updatedCd = 0x22 CD (0x6 "My song") (0x20 ( 0x23 : ...) updatedTrack = 0x23 Track ( 0x21 "updated track title" ) 0x22 in (0x27) DB (0x24 (updatedCd:otherCds)) (0x25 (updatedTrack:otherTracks)) Now my new address to access the database is 0x25. So pretty every adress has been changed but 0x6, ..., otherCds and otherTracks A query running using db 0x3 will not notice any change on its snapshot. Are these actions called rebinding? Of course if you have a lot of relations writing this let in will become tedious and error prone.. That's why I'd like to use template haskell to automatically derive it. Thanks for listening Marc Weber From claus.reinke at talk21.com Thu May 22 06:34:15 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Thu May 22 06:27:38 2008 Subject: [Haskell-cafe] Ubuntu and ghc References: <5ae4f2ba0805211532l35bef8eas9a10ff6df3e0f843@mail.gmail.com> <1211448821.5824.504.camel@localhost> Message-ID: <008001c8bbf7$63753100$d0357ad5@cr3lt> >> https://bugs.launchpad.net/ubuntu/+source/gtk2hs/+bug/229489 .... this >> is almost identical to my problem. I am just trying to help others on >> this list who are using Ubuntu Linux to avoid my predicament! > > I had that problem upgrading too. > > I posted a workaround: > > http://bugs.launchpad.net/ubuntu/+source/gtk2hs/+bug/229489/comments/9 |What's going on: |-------------------------- |Every Haskell library gets registered with the Haskell compiler ghc. |The ghc-pkg program is used to do that. Packages get registered |(ghc-pkg register) when they're installed and unregistered (ghc-pkg |unregister) when they get uninstalled or upgraded. To be unregistered |they have to be registered in the first pace. |So what's gone wrong is that ghc itself has been upgraded before the |other libs (gtk2hs, mtl etc) were unregistered.When ghc gets upgraded |it includes an empty package database. So now when it comes time to |upgrade the other Haskell libs they are of course no longer registered |(because they were registered with the older version of the compiler |and not the new one). The uninstall script then fails because ghc-pkg |unregister fails, since the package is not registered. this sounds as if the uninstall simply needs an option deciding between uninstall-or-fail and achieve-uninstalled-state? but then again, uninstall should know from which compiler version/package database to uninstall, and uninstalling ghc should not disappear things without notifying other (un-)installation tools. i'll abuse this real-life opportunity to point once again at a serious flaw in the "throw-away installations" idea in common use for haskell compilers and libraries: there is no support for upgrading or cross-version consistency! throw-away installation: - if you install a library or a compiler version or tool, it puts itself in a separate place, free from interference with other libraries or compiler versions - usual practice then cleans away/forgets about the source for the installation, so the installation is not repeatable; it also forgets about the other dependencies that were used to build this installation (specific package or compiler versions needed to build this library/compiler/tool) - if you uninstall a library or a compiler version, it just removes itself (and even that isn't all that well supported, beyond unregistration..) there are so many ways this can go wrong that it is surprising that the real-life bugs have taken so long to show up.here are some examples (many of which have been discussed earlier, but have always been tracked as low priority/nice to have..): - if i update my ghc, i want to take all my libraries with me (especially since binary incompatibility means that i can't just reuse the existing installations..) - if i uninstall a version of ghc, i want to be reminded of which libraries are installed only for this ghc version (the libraries i'd lose by uninstalling, as opposed to libraries also installed for later ghc versions), and which installed tools were built using this ghc version (in case upgrading them still requires that old version..) - if i install a new library, i don't want version conflicts because an older, incompatible library version is in use by other packages - if i uninstall a library, i don't want dangling references to it in the package database - i don't want to have to remove anything explicitly, because that would mean bypassing the haskell installation managers - i would want to see a single haskell installation manager for each system, covering compiler versions as well, not to mention collaboration between all cabal/ghc-pkg versions currently installed; so that i can ask about all the package databases/compiler versions/packages; this might also help as a coordination point for upgrades - i would like to be able to determine, for each installed tool, library and compiler, which package and compiler versions were involved in building it, by querying that haskell installation manager - .. it just isn't sufficient not to interfere with existing stuff, it is important to be aware of relationships with existing stuff, and to adjust actions and practices accordingly (to guard against inconsistencies/disappearing dependencies, and to support upgrades/reproducable installations). perhaps the existing tickets in this direction could be given higher priorities, and the various groups and tools concerned with packaging could coordinate on this? claus From kirby81 at gmail.com Thu May 22 06:48:42 2008 From: kirby81 at gmail.com (Salvatore Insalaco) Date: Thu May 22 06:41:59 2008 Subject: [Haskell-cafe] relational data representation in memory using haskell? In-Reply-To: <20080522100044.GB27673@gmx.de> References: <20080521230424.GA3729@gmx.de> <5a376f550805212316k5dbfd172t447a1f115707ac8b@mail.gmail.com> <20080522073702.GB29778@gmx.de> <5a376f550805220201v65f8c967pfe6687aaf9f3d86d@mail.gmail.com> <20080522100044.GB27673@gmx.de> Message-ID: <5a376f550805220348wf8b8b69h928dc55faf5bc7f7@mail.gmail.com> 2008/5/22 Marc Weber : > So in haskell it would look like this: > let updatedCd = 0x22 CD (0x6 "My song") (0x20 ( 0x23 : ...) > updatedTrack = 0x23 Track ( 0x21 "updated track title" ) 0x22 > in (0x27) DB (0x24 (updatedCd:otherCds)) (0x25 (updatedTrack:otherTracks)) Mmmm I don't think that this is a good way to go. Let me do a counter-example: data A = A String data B = B String [A] data C = C String [B] data D = D String [C] Suppose to have some As, Bs, Cs, Ds in your database. Now you want to "update" the String of A. As you cannot "update" stuff in Haskell mantaining the same pointer, you've got a "new A". So you must find all Bs that had this A in their list, and update that. Unfortunately lists are not mutable too, so you are creating a new list; so you need to create new containing Bs too. But then you must change Cs... and so on. A little change like changing the String in A requires updating the whole "DB". Salvatore From marco-oweber at gmx.de Thu May 22 07:25:07 2008 From: marco-oweber at gmx.de (Marc Weber) Date: Thu May 22 07:18:26 2008 Subject: [Haskell-cafe] relational data representation in memory using haskell? In-Reply-To: <5a376f550805220348wf8b8b69h928dc55faf5bc7f7@mail.gmail.com> References: <20080521230424.GA3729@gmx.de> <5a376f550805212316k5dbfd172t447a1f115707ac8b@mail.gmail.com> <20080522073702.GB29778@gmx.de> <5a376f550805220201v65f8c967pfe6687aaf9f3d86d@mail.gmail.com> <20080522100044.GB27673@gmx.de> <5a376f550805220348wf8b8b69h928dc55faf5bc7f7@mail.gmail.com> Message-ID: <20080522112507.GA5351@gmx.de> On Thu, May 22, 2008 at 12:48:42PM +0200, Salvatore Insalaco wrote: > 2008/5/22 Marc Weber : > > So in haskell it would look like this: > > let updatedCd = 0x22 CD (0x6 "My song") (0x20 ( 0x23 : ...) > > updatedTrack = 0x23 Track ( 0x21 "updated track title" ) 0x22 > > in (0x27) DB (0x24 (updatedCd:otherCds)) (0x25 (updatedTrack:otherTracks)) > > Mmmm I don't think that this is a good way to go. > Let me do a counter-example: > > data A = A String > data B = B String [A] > data C = C String [B] > data D = D String [C] > > A little change like changing the String in A requires updating the whole "DB". You're right. Very bad idea unless you only insert once a year and only have queries the whole day. The only way to fix this is by separating relational data from record data. > data A = Map RecordDataA RelationalDataA > data B = Map RecordDataB RelationalDataB So when changing a field in RecordDataA only the relational data B would have to be updated.. but I see that that's not that good either. Fine. Then the only way to go is using uniq ids as keys the way it's already done everywhere Thanks Marc W From ketil at malde.org Thu May 22 08:48:05 2008 From: ketil at malde.org (Ketil Malde) Date: Thu May 22 08:41:23 2008 Subject: [Haskell-cafe] Network.CGI and error handling Message-ID: <87hccq1p4q.fsf@nmd9999.imr.no> Hi, I'm trying to implement a CGI, but I have encountered some problems with handling program errors properly. I think it boils down to this: The first program from the documentation at http://hackage.haskell.org/packages/archive/cgi/3001.1.5.2/doc/html/Network-CGI.html import Network.CGI cgiMain = output "Hello World!" main = runCGI (handleErrors cgiMain) works fine, and ouputs a page with the expected test. Replacing line 2 with: cgiMain = output $ error "Hello World!" returns a blank page, although according to the documentation, 'handleErrors' should produce an error page (500) instead. The error is recorded in the log, where one can read: [Thu May 22 14:35:27 2008] [error] [client 10.1.9.227] test.cgi: Hello World! I've toyed with various approaches, including using catchCGI and replacing 'error' with other run-time failures, but only getting the same result. Any hints? (ghc 6.8.1, cgi-3001.1.5.1, apache 2.0, linux.) -k -- If I haven't seen further, it is by standing in the footprints of giants From simonpj at microsoft.com Thu May 22 08:58:34 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu May 22 08:52:02 2008 Subject: [Haskell-cafe] A chance to share your experience Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE57E3EAA@EA-EXMSG-C334.europe.corp.microsoft.com> Friends I know for a fact that many of you are using Haskell successfully for real applications. Yet none of you have sent me an offer of a presentation at the Commercial Users of Functional Programming workshop, which happens in late Sept. I'm the program co-chair, and I confidently expecting several Haskell offers... but not one so far. I am sad. I am very sad. Make me happy! I'm sure you are very busy making your business work. But think what fun it'd be to share your experience with others, meet other people with similar experiences, recruit bright students to your company... Happily, there is still time. The deadline for offers is 2nd June. All we need by then is a short summary of what you think you might say. You don't have to write a paper (not now, not ever). Your presentation does not have to be highly technical. On the contrary, the emphasis is on the process issues that surround functional programming: convincing management, changes to software development, testing, benefits, costs, successes, concerns. I'm going to the Lake District for a week's holiday next week (it's half term in the UK). Please send me a lovely full mailbox to come back to. The CFP is below, and at http://cufp.galois.com/. best wishes Simon Commercial Users of Functional Programming Workshop (CUFP) 2008 26 September 2008, Victoria, British Columbia ============== CALL FOR PRESENTATIONS ====================== Presentation proposals due 2 June 2008 http://cufp.functionalprogramming.com Functional Programming As a Means, Not an End Sponsored by SIGPLAN Co-located with ICFP 2008 _________________________________________________________________ Functional languages have been under academic development for over 25 years, and remain fertile ground for programming language research. Recently, however, developers in industrial, governmental, and open source projects have begun to use functional programming successfully in practical applications. In these settings, functional programming has often provided dramatic leverage, including whole new ways of thinking about the original problem. The goal of the CUFP workshop is to act as a voice for these users of functional programming. The workshop supports the increasing viability of functional programming in the commercial, governmental, and open-source space by providing a forum for professionals to share their experiences and ideas, whether those ideas are related to business, management, or engineering. The workshop is also designed to enable the formation and reinforcement of relationships that further the commercial use of functional programming. Speaking at CUFP If you use functional programming as a means, rather than as an end, we invite you to offer to give a talk at the workshop. Alternatively, if you know someone who would give a good talk, please nominate them! Talks are typically 30-45 minutes long, but can be shorter. They aim to inform participants about how functional programming played out in real-world applications, focusing especially on the re-usable lessons learned, or insights gained. Your talk does not need to be highly technical; for this audience, reflections on the commercial, management, or software engineering aspects are, if anything, more important. You do not need to submit a paper! If you are interested in offering a talk, or nominating someone to do so, send an e-mail to jim (dot) d (dot) grundy (at) intel (dot) com or simonpj (at) microsoft (dot) com by 2 June 2008 with a short description of what you'd like to talk about or what you think your nominee should give a talk about. Such descriptions should be about one page long. Program Plans CUFP 2008 will last a full day and feature an invited presentation from Michael Hopcroft, the product unit manager for the forthcoming release of Microsoft Visual Studio F#. Additionally, the program will include a mix of presentations and discussion sessions. Topics will range over a wide area, including: * Case studies of successful and unsuccessful uses of functional programming; * Business opportunities and risks from using functional languages; * Enablers for functional language use in a commercial setting; * Barriers to the adoption of functional languages, and * Mitigation strategies for overcoming limitations of functional programming. There will be no published proceedings, as the meeting is intended to be more a discussion forum than a technical interchange. Program Committee * Lennart Augustsson * Matthias Blume * Adam Granicz * Jim Grundy (co-chair) * John Lalonde * Andy Martin * Yaron Minsky * Simon Peyton Jones (co-chair) * Ulf Wiger This will be the fifth CUFP, for more information - including reports from attendees of previous events - see the workshop web site: http://cufp.functionalprogramming.com From isaacdupree at charter.net Thu May 22 09:11:28 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Thu May 22 09:04:55 2008 Subject: [Haskell-cafe] relational data representation in memory using haskell? In-Reply-To: <871w3u3efw.fsf@nmd9999.imr.no> References: <20080521230424.GA3729@gmx.de> <5a376f550805212316k5dbfd172t447a1f115707ac8b@mail.gmail.com> <871w3u3efw.fsf@nmd9999.imr.no> Message-ID: <48357100.2050609@charter.net> to whoever in this thread hasn't realized it: Map String (Map Int Foo) == Map (String,Int) Foo (at least to an approximation) -Isaac From marco-oweber at gmx.de Thu May 22 09:34:36 2008 From: marco-oweber at gmx.de (Marc Weber) Date: Thu May 22 09:28:02 2008 Subject: [Haskell-cafe] relational data representation in memory using haskell? In-Reply-To: <48357100.2050609@charter.net> References: <20080521230424.GA3729@gmx.de> <5a376f550805212316k5dbfd172t447a1f115707ac8b@mail.gmail.com> <871w3u3efw.fsf@nmd9999.imr.no> <48357100.2050609@charter.net> Message-ID: <20080522133436.GA22128@gmx.de> On Thu, May 22, 2008 at 09:11:28AM -0400, Isaac Dupree wrote: > to whoever in this thread hasn't realized it: > Map String (Map Int Foo) == Map (String,Int) Foo > (at least to an approximation) That's note quite right.. if you care only about the Int -> String -> [ Rec ] lookup you are right. But When using Map String (Map Int Rec) you can still use the first index also you'll have to spend some time joining all sets found in the second one.. Marc From olivier.boudry at gmail.com Thu May 22 09:49:54 2008 From: olivier.boudry at gmail.com (Olivier Boudry) Date: Thu May 22 09:43:11 2008 Subject: [Haskell-cafe] Newbie: State monad example questions In-Reply-To: <53396d9e0805211519x71d77df9gb39d7c59203d57ac@mail.gmail.com> References: <53396d9e0805191404va8cb2d7yeb36954b83ac5ca8@mail.gmail.com> <53396d9e0805210542n667d6596uca6b8caf89e30219@mail.gmail.com> <53396d9e0805210810m6f48596jde8e98f7394403c6@mail.gmail.com> <53396d9e0805211519x71d77df9gb39d7c59203d57ac@mail.gmail.com> Message-ID: On Wed, May 21, 2008 at 6:19 PM, Dmitri O.Kondratiev wrote: > -- Then we can use this State object (returned by getAny) in a function > generating random values such as: > > makeRnd :: StdGen -> (Int, StdGen) > makeRnd = runState (do > y <- getAny > return y) > You can simplify this: do y <- m return y is equivalent to `do m` or `m` According to Monad Laws. So you could write the same code as: makeRnd = runState getAny In that case, the use of the State Monad is not really interesting as you just replaced a call to `random g` with a call to `runState getAny g`. The State Monad is interesting if you have more than one action in the first argument of the `runState` function because the state passing will only work in a single `State s a`. Thomas Hartman asked for use cases so I will describe programs I used the State Monad for: 1) You can find a portion of the code here: http://hpaste.org/7809 The purpose of this program was extracting address parts (PO box, street, city, country, postal code, ...) from addresses which are composed of a name, 3 free text lines and a zip code. The state is a list of AddressPart elements. If you look at the extractAddress function, it contains many other function running in the State Monad. Each function can get and put the state. The state will contain both unparsed and already parsed AddressPart elements. The big benefit I got from using the State Monad was that I was able to reorder the functions by just copy/pasting the function name from one place to another. Each of the `State Address ()` function will get the state, try to find an address part in the unparsed AddressPart elements and put a new State with the recognized AddressPartS if any. I think parsing is a common use case for the State Monad where you want to store the unparsed data along with the parse result and don't want to care about passing those elements from one function to another. 2) I also recently used the State Monad Transformer to build a single Data.Map from a set of different files. The State is the Data.Map and the action in the runStateT is a mapM_ over a list of file names. processFile :: String -> StateT (PartsMap B.ByteString) IO () -- get the Map -- add the file info -- put the Map runStateT (mapM_ processFile fileNames) M.Empty -- each processFile call will get access to the result of the previous call and put the updated Map. I don't know if it's a common use case for the State Monad, but I found it useful. I could probably have used foldM to achieve the same goal and don't worry about using the State Monad. Best regards, Olivier. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080522/81824ea7/attachment.htm From stansife at caltech.edu Thu May 22 10:22:19 2008 From: stansife at caltech.edu (Eric Stansifer) Date: Thu May 22 10:15:36 2008 Subject: [Haskell-cafe] Newbie: State monad example questions In-Reply-To: <910ddf450805210111n76f99e7cx43f1f5b84b999217@mail.gmail.com> References: <53396d9e0805191404va8cb2d7yeb36954b83ac5ca8@mail.gmail.com> <910ddf450805210111n76f99e7cx43f1f5b84b999217@mail.gmail.com> Message-ID: <2e58fd390805220722n28888825j8c385d53a8d8a06f@mail.gmail.com> > So, are there any other simple motivating examples that show what > state is really good for? Here's an example from some code that I'm (trying to) write; I am writing a DSL for the Povray Scene Description Language. This part of my program creates a `String' which holds a piece of Povray SDL code. I am using the state to keep track of an infinite list of unique identifiers -- when I use an identifier I would like to avoid reusing the same one later. > type Identifier = String > type Identifiers = [Identifier] > all_identifiers :: Identifiers > all_identifiers = map (\n -> "var" ++ show n) [0, 1..] > next_id :: State Identifiers Identifier > next_id = do > (a:as) <- get > put as > return a I define a function "let_" so that if a user of my code writes something like: > let_ value expr For example, if a user said: > let_ (vector (0, 0, 0)) > (\origin -> > let_ (vector (1, 2, 3)) > (\p -> > union [box origin p, sphere origin (float 1), cylinder origin p (float 0.5)])) it should be analogous to: > union [box (vector (0, 0, 0)) (vector (1, 2, 3)), sphere (vector (0, 0, 0)) (float 1), cylinder (vector (0, 0, 0)) (vector (1, 2, 3)) (float 0.5)] (Cf. http://www.haskell.org/pipermail/haskell-cafe/2008-February/039639.html for details on what I'm trying to do here, but it has nothing to do with my example usage of a state monad.) In my definition of "let_", I extract a fresh, unused identifier which is assigned to the value of "value". > type Code x = State Identifiers String > let_ :: Code x -> (Code x -> Code y) -> Code y > let_ m_value m_expr = do > id <- next_id > value <- m_value > expr <- m_expr (return id) > return ("#declare " ++ id ++ " = " ++ value ++ ";\n" ++ expr) Either of the expressions "m_value" or "m_expr" may require their own unique identifiers, but the State monad takes care of threading my `Identifiers' state so that the same identifier will not be used more than once. Later on, when I made a more sophisticated version of `Identifiers' which kept of track of multiple different namespaces from which identifiers could come, I only had to modify `next_id' without having to worry about whether I would have to make changes in other parts of the program (although I believe further changes would not have been necessary even if I had not used State monads, the modularity of the code is much more obvious when using the State monad instead of explicitly writing out the state that is being passed around). Eric From marco-oweber at gmx.de Thu May 22 10:48:01 2008 From: marco-oweber at gmx.de (Marc Weber) Date: Thu May 22 10:41:23 2008 Subject: [Haskell-cafe] relational data representation in memory using haskell? In-Reply-To: <20080522133436.GA22128@gmx.de> References: <20080521230424.GA3729@gmx.de> <5a376f550805212316k5dbfd172t447a1f115707ac8b@mail.gmail.com> <871w3u3efw.fsf@nmd9999.imr.no> <48357100.2050609@charter.net> <20080522133436.GA22128@gmx.de> Message-ID: <20080522144801.GA7462@gmx.de> On Thu, May 22, 2008 at 03:34:36PM +0200, Marc Weber wrote: > On Thu, May 22, 2008 at 09:11:28AM -0400, Isaac Dupree wrote: > > to whoever in this thread hasn't realized it: > > Map String (Map Int Foo) == Map (String,Int) Foo > > (at least to an approximation) There is another difference if you want to query <,<=,>,>= say String = city and Int = age. Now take Map (Int, String) rec and use this index to filter all tuples having an age >= 80 and beeing "city" Marc From isaacdupree at charter.net Thu May 22 11:10:31 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Thu May 22 11:03:48 2008 Subject: [Haskell-cafe] relational data representation in memory using haskell? In-Reply-To: <20080522144801.GA7462@gmx.de> References: <20080521230424.GA3729@gmx.de> <5a376f550805212316k5dbfd172t447a1f115707ac8b@mail.gmail.com> <871w3u3efw.fsf@nmd9999.imr.no> <48357100.2050609@charter.net> <20080522133436.GA22128@gmx.de> <20080522144801.GA7462@gmx.de> Message-ID: <48358CE7.1000600@charter.net> Marc Weber wrote: > On Thu, May 22, 2008 at 03:34:36PM +0200, Marc Weber wrote: >> On Thu, May 22, 2008 at 09:11:28AM -0400, Isaac Dupree wrote: >>> to whoever in this thread hasn't realized it: >>> Map String (Map Int Foo) == Map (String,Int) Foo >>> (at least to an approximation) > There is another difference if you want to query <,<=,>,>= > say String = city and Int = age. > Now take Map (Int, String) rec and use this index to filter all tuples > having an age >= 80 and beeing "city" there are two problems: Data.Map doesn't have a very good API for that (splitLookup is about the best you can get for ranges) Whether tupled or not, the order of the two indices matters (Int,String) vs. (String,Int) for what you can look up efficiently. It's essentially a binary tree either way (Map x (Map y rec)) or (Map (x,y) rec), sorted in the same order. (tuples sort by lexicographical order) -Isaac From kr.angelov at gmail.com Thu May 22 15:52:11 2008 From: kr.angelov at gmail.com (Krasimir Angelov) Date: Thu May 22 15:45:28 2008 Subject: [Haskell-cafe] Data.Tree.Zipper in the standard libraries Message-ID: Hello Guys, We have Data.Tree in the standard libraries for a long time but for some reason we still don't have standard implementation for Zipper. I wrote recently one implementation for Yi but there are many other versions hanging around. At least I know for some. I propose to add one in the standard libraries i.e. the "containers" package. The version that I use currently is here: http://code.haskell.org/yi/Data/Tree/Zipper.hs If you would like to do code review I will be happy to hear comments. After the API is settled down I will write test cases also. One thing that is worying me is that the current version uses State monad which is in the "mtl" package while the natural place for Data.Tree.Zipper is in "containers". This will create an extra dependency. Is this acceptable? Regards, Krasimir From ketil at malde.org Thu May 22 17:07:31 2008 From: ketil at malde.org (Ketil Malde) Date: Thu May 22 17:00:49 2008 Subject: [Haskell-cafe] Re: Network.CGI and error handling In-Reply-To: <87hccq1p4q.fsf@nmd9999.imr.no> (Ketil Malde's message of "Thu\, 22 May 2008 14\:48\:05 +0200") References: <87hccq1p4q.fsf@nmd9999.imr.no> Message-ID: <87mymiyrn0.fsf@nmd9999.imr.no> Since Bj?rn Bringert suggested (on IRC) the problem could be due to laziness, and that I should force the result string before giving it to "output", I've been playing around a bit. (The program is somewhat more involved than the short test I provided earlier, but available on request). Without strictness, I get a blank page, and an message in the error_log: [Thu May 22 22:00:15 2008] [error] [client 10.1.4.222] snp.cgi: Prelude.last: empty list, referer: http://gadidae/snp.c gi This is okay, but I would still like some output to the user. With strict evaluation of output's argument, I instead get a web page that appears to hang (showing a hourglass cursor and animated toolbar icon). In the log, I find: [Thu May 22 22:22:44 2008] [error] [client 10.1.4.222] Premature end of script headers: snp-strict.cgi, referer: http://gadidae/snp-strict.cgi [Thu May 22 22:26:32 2008] [error] [client 10.1.4.222] Premature end of script headers: snp-strict.cgi, referer: http://gadidae/snp-strict.cgi [Thu May 22 22:27:44 2008] [error] [client 10.1.4.222] (500,"Internal Server Error",["Prelude.last: empty list"]), referer: http://gadidae/snp-strict.cgi [Thu May 22 22:31:32 2008] [error] [client 10.1.4.222] (500,"Internal Server Error",["Prelude.last: empty list"]), referer: http://gadidae/snp-strict.cgi I interpret this as the system putting things on hold for about ten minutes before terminating my script, and for some reason, the intended error document is put in the log instead of being returned to the browser/client. This is just weird. (I do actually get a 500 from the server, but that just talks about "premature end of script headers", and not about the actual bug in my program, so I belive this is just what apache says when terminating a runaway cgi) Network.CGI does look like an established library, certainly the documentation I find is very good and complete, and the interface is concise, logical, and to the point. It seems a shame that it doesn't work. Does anybody else have it working? I'd be very happy to hear about it, even if it just works for you. -k -- If I haven't seen further, it is by standing in the footprints of giants From conal at conal.net Thu May 22 17:13:08 2008 From: conal at conal.net (Conal Elliott) Date: Thu May 22 17:06:24 2008 Subject: [Haskell-cafe] Data.Tree.Zipper in the standard libraries In-Reply-To: References: Message-ID: Hi Krasimir, I had a long exchange with chessguy about this interface, suggesting a significant change in style, simplifying the type. (Incidentally, the change removed the State and hence mtl dependence.) The conversation is on http://tunes.org/~nef/logs/haskell/08.05.17, starting with "12:08:11 w00t!" and really picking up with " chessguy: something smells funny ...". Here's a summary of the conversation, though I encourage you to read the whole thing: * Every definition of tp 'State (TreeLoc a) a', does a getLabel at the end (except getLabel). * Often users of those movement functions discard the result. * Simpler and more orthogonal would be remove the getLabel and return 'State (TreeLoc a) ()' instead. * Now remove that return value altogether, simplifying the type of zipper movements to just 'TreeLoc a -> TreeLoc a'. Then they compose nicely with (.), having id as identity. * Simplify the type of getLabel to just 'TreeLoc a -> a'. Now no more State. Cheers, - Conal On Thu, May 22, 2008 at 12:52 PM, Krasimir Angelov wrote: > Hello Guys, > > We have Data.Tree in the standard libraries for a long time but for > some reason we still don't have standard implementation for Zipper. I > wrote recently one implementation for Yi but there are many other > versions hanging around. At least I know for some. I propose to add > one in the standard libraries i.e. the "containers" package. The > version that I use currently is here: > > http://code.haskell.org/yi/Data/Tree/Zipper.hs > > If you would like to do code review I will be happy to hear comments. > After the API is settled down I will write test cases also. One thing > that is worying me is that the current version uses State monad which > is in the "mtl" package while the natural place for Data.Tree.Zipper > is in "containers". This will create an extra dependency. Is this > acceptable? > > Regards, > Krasimir > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080522/6682c190/attachment.htm From simonpj at microsoft.com Thu May 22 17:51:07 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu May 22 17:44:27 2008 Subject: [Haskell-cafe] Re: MD5 performance optimizations, and GHC -via-C producing segfaulting binary In-Reply-To: <4833350D.2030006@charter.net> References: <5a376f550805200241i3bb57e39sa0cb56e9fb28624b@mail.gmail.com> <48332110.7020404@btinternet.com> <12951033.20080521000100@gmail.com> <20080520201314.GI9426@scytale.galois.com> <4833350D.2030006@charter.net> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE57E415C@EA-EXMSG-C334.europe.corp.microsoft.com> | > I'm confused. GHC of course unboxes strict fields of primitive data types. | > | > {-# OPTIONS -O2 -fvia-C -optc-O2 -funbox-strict-fields #-} | | ... but only when you give -funbox-strict-fields, as there, or UNPACK. | The point is that it never loses sharing to unbox a strict Int field | [1], so it should do that with -O, even without either of the above | overrides. | | [1] I'm not sure if this is true... if it has to rebox the Int, you get | another copy floating around, not the original, right? Correct. If you have data T = MkT {-# UNPACK #-} !Int then given case x of { MkT y -> h y } then GHC must re-box the 'y' before passing it to h. That's why unpacking strict fields isn't an unambiguous win. Perhaps it should be the default, though, which can be switched off, rather than the reverse. Simon From bf3 at telenet.be Thu May 22 17:58:16 2008 From: bf3 at telenet.be (Peter Verswyvelen) Date: Thu May 22 17:51:52 2008 Subject: [Haskell-cafe] What to do when GHC works, RUNGHC fails Message-ID: <4835EC78.6020704@telenet.be> I'm experimenting creating a Cabal script on Windows that installs a module that refers to some DLLs (freetype, png, ...) via C wrappers When configuring, building, and installing using cabal, a test program that uses this installed module runs fine when compiled with GHC --make, but fails miserably when run with RUNGHC (or GHCi) The first thing I noticed is that RUNGHC looks for a DLL called "png.dll" (which it doesn't find and then bails out with an error), while the executable build with GHC uses the correct "libpng3.dll". When I rename the libpng3.dll into png.dll, RUNGHC goes a bit further but then fails with an "unknown symbol". Obviously I did something wrong in my Cabal script, but I have no idea what it is. There seems to be a big difference when it comes to linking between of GHCi and GHC . Any guidelines on what to do in cases like the one above? I really like to use the interpreter because it provides much shorter turnaround times, and things like this stop me from using it. Thanks, Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080522/46c869cf/attachment.htm From dave at zednenem.com Thu May 22 18:03:16 2008 From: dave at zednenem.com (David Menendez) Date: Thu May 22 17:56:33 2008 Subject: [Haskell-cafe] Newbie: State monad example questions In-Reply-To: References: <53396d9e0805191404va8cb2d7yeb36954b83ac5ca8@mail.gmail.com> <53396d9e0805210542n667d6596uca6b8caf89e30219@mail.gmail.com> <53396d9e0805210810m6f48596jde8e98f7394403c6@mail.gmail.com> <53396d9e0805211519x71d77df9gb39d7c59203d57ac@mail.gmail.com> Message-ID: <49a77b7a0805221503i7c3571acm5ce6b0af357adf95@mail.gmail.com> 2008/5/22 Olivier Boudry : > On Wed, May 21, 2008 at 6:19 PM, Dmitri O.Kondratiev > wrote: > >> >> -- Then we can use this State object (returned by getAny) in a function >> generating random values such as: >> >> makeRnd :: StdGen -> (Int, StdGen) >> makeRnd = runState (do >> y <- getAny >> return y) > > You can simplify this: > > do y <- m > return y > > is equivalent to > > `do m` > > or `m` > > According to Monad Laws. > > So you could write the same code as: > makeRnd = runState getAny > > In that case, the use of the State Monad is not really interesting as you > just replaced a call to `random g` with a call to `runState getAny g`. The > State Monad is interesting if you have more than one action in the first > argument of the `runState` function because the state passing will only work > in a single `State s a`. Incidentally, since random has type (Random a, RandomGen g) => g -> (a,g), getAny could have been defined simply as getAny = State random It may be helpful to prove that this definition is equivalent to the one given in the original post. Oh, and here's a super-simple example using the state monad: randR :: (Random a) => (a,a) -> State StdGen a randR range = State (randomR range) twoDice :: State StdGen Int twoDice = do d1 <- randR (1,6) d2 <- randR (1,6) return (d1 + d2) nDice :: Int -> State StdGen Int nDice n | n < 1 = return 0 nDice n = do x <- randR (1,6) y <- rollN (n - 1) return (x + y) Because State StdGen is a monad, you can rewrite nDice without explicit recursion using foldM: nDice n = foldM (\sum m -> liftM (sum+) m) 0 $ take n $ repeat (randR (1,6)) -- Dave Menendez From ketil at malde.org Thu May 22 18:08:18 2008 From: ketil at malde.org (Ketil Malde) Date: Thu May 22 18:01:35 2008 Subject: [Haskell-cafe] Re: Network.CGI and error handling In-Reply-To: <87mymiyrn0.fsf@nmd9999.imr.no> (Ketil Malde's message of "Thu\, 22 May 2008 23\:07\:31 +0200") References: <87hccq1p4q.fsf@nmd9999.imr.no> <87mymiyrn0.fsf@nmd9999.imr.no> Message-ID: <87d4neyotp.fsf@nmd9999.imr.no> Ketil Malde writes: > Since Bj?rn Bringert suggested (on IRC) the problem could be due to > laziness [..] Does anybody else have it working? I found that other person, and he is us. I played around some more, and thought -- just to not leave any stone unturned -- that I should try it on a different web server. So, I moved my CGIs over, and lo and behold, the strict version suddenly works! I therefore would like to apologize for any insinuation I may have perpetrated that could be taken to imply that Network.CGI possesses any feature of less than desirable merit?. As usual, it's some C program that is to blame :-) -k ? I'm tempted to suggest that "output" should be strict in its argument, but I shall refrain. -- If I haven't seen further, it is by standing in the footprints of giants From conal at conal.net Thu May 22 18:33:36 2008 From: conal at conal.net (Conal Elliott) Date: Thu May 22 18:26:52 2008 Subject: [Haskell-cafe] Data.Tree.Zipper in the standard libraries In-Reply-To: References: Message-ID: > > * Every definition of tp I meant "of type", forgetting that my emacs abbrevs don't expand in gmail. On Thu, May 22, 2008 at 2:13 PM, Conal Elliott wrote: > Hi Krasimir, > > I had a long exchange with chessguy about this interface, suggesting a > significant change in style, simplifying the type. (Incidentally, the > change removed the State and hence mtl dependence.) > > The conversation is on http://tunes.org/~nef/logs/haskell/08.05.17, > starting with "12:08:11 w00t!" and really picking up with > " chessguy: something smells funny ...". > > Here's a summary of the conversation, though I encourage you to read the > whole thing: > > * Every definition of tp 'State (TreeLoc a) a', does a getLabel at the end > (except getLabel). > * Often users of those movement functions discard the result. > * Simpler and more orthogonal would be remove the getLabel and return > 'State (TreeLoc a) ()' instead. > * Now remove that return value altogether, simplifying the type of zipper > movements to just 'TreeLoc a -> TreeLoc a'. Then they compose nicely with > (.), having id as identity. > * Simplify the type of getLabel to just 'TreeLoc a -> a'. Now no more > State. > > Cheers, - Conal > > > > On Thu, May 22, 2008 at 12:52 PM, Krasimir Angelov > wrote: > >> Hello Guys, >> >> We have Data.Tree in the standard libraries for a long time but for >> some reason we still don't have standard implementation for Zipper. I >> wrote recently one implementation for Yi but there are many other >> versions hanging around. At least I know for some. I propose to add >> one in the standard libraries i.e. the "containers" package. The >> version that I use currently is here: >> >> http://code.haskell.org/yi/Data/Tree/Zipper.hs >> >> If you would like to do code review I will be happy to hear comments. >> After the API is settled down I will write test cases also. One thing >> that is worying me is that the current version uses State monad which >> is in the "mtl" package while the natural place for Data.Tree.Zipper >> is in "containers". This will create an extra dependency. Is this >> acceptable? >> >> Regards, >> Krasimir >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080522/7ad6524c/attachment.htm From isaacdupree at charter.net Thu May 22 19:14:32 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Thu May 22 19:07:45 2008 Subject: [Haskell-cafe] Re: MD5 performance optimizations, and GHC -via-C producing segfaulting binary In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AE57E415C@EA-EXMSG-C334.europe.corp.microsoft.com> References: <5a376f550805200241i3bb57e39sa0cb56e9fb28624b@mail.gmail.com> <48332110.7020404@btinternet.com> <12951033.20080521000100@gmail.com> <20080520201314.GI9426@scytale.galois.com> <4833350D.2030006@charter.net> <638ABD0A29C8884A91BC5FB5C349B1C32AE57E415C@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <4835FE58.1000901@charter.net> Simon Peyton-Jones wrote: > | [1] I'm not sure if this is true... if it has to rebox the Int, you get > | another copy floating around, not the original, right? > > Correct. If you have > > data T = MkT {-# UNPACK #-} !Int > then given > case x of { MkT y -> h y } > then GHC must re-box the 'y' before passing it to h. That's why unpacking strict fields isn't an unambiguous win. Perhaps it should be the default, though, which can be switched off, rather than the reverse. perhaps there are certain types that the compiler almost always manages to pass around unboxed -- Ints, for example? (Or at least that the extra copies aren't likely to persist for a long time, wasting some memory. Especially not if they're always unboxed in strict fields -- except for strict polymorphic fields, unfortunately.) And other types that aren't usually passed around unboxed? If this is clear, then maybe it's useful to do it by default for those types. Perhaps there should be a {-# NOUNPACK #-} pragma just in case someone wants to make sure a strict field isn't represented unboxed (not even if you give -funbox-strict-fields). -Isaac From dekudekuplex at yahoo.com Fri May 23 01:27:49 2008 From: dekudekuplex at yahoo.com (Benjamin L. Russell) Date: Fri May 23 01:21:04 2008 Subject: [Haskell-cafe] whhaskell on osx 10.5 In-Reply-To: Message-ID: <756653.66529.qm@web30204.mail.mud.yahoo.com> wxHaskell - Building - MacOS X (http://wxhaskell.sourceforge.net/building-macosx.html): > Due to complicated MacOS X restrictions, graphical wxHaskell applications do not work > directly when used from GHCi. Fortunately, Wolfgang Thaller has kindly provided an > ingenious Haskell module that solves this problem. Just import the (compiled) module > EnableGUI in your program and issue the following command to run main from your GHCi > prompt: > > > enableGUI >> main Is there any estimated date on getting graphical wxHaskell applications to work directly when used from GHCi? Benjamin L. Russell --- On Wed, 5/21/08, Kirk Peterson wrote: > From: Kirk Peterson > Subject: Re: [Haskell-cafe] whhaskell on osx 10.5 > To: "Marc Weber" , haskell-cafe@haskell.org > Date: Wednesday, May 21, 2008, 6:50 AM > just running: > $ ./helloworld > > will work fine on windows and linux, under mac os, I ran > into issues > with window focus and click events not firing. Upon > looking further, > I found this page on the wxhaskell site: > http://wxhaskell.sourceforge.net/building-macosx.html > > which explains the need to the macosx-app step in compiling > a > whhaskell app, and why I include it in my example. Hope > this helps. > > cheers, > -kirk > > On Tue, May 20, 2008 at 2:23 PM, Marc Weber > wrote: > > On Tue, May 20, 2008 at 12:38:14PM -0700, Kirk > Peterson wrote: > >> I had a difficult time getting wxhaskell installed > and working on a > >> mac running os x 10.5. I did a quick write up of > the process I got > >> working here: > >> > >> > http://necrobious.blogspot.com/2008/05/wxhaskell-go-go.html > > $ cd ../samples/wx > > $ ghc -package wx -o helloworld HelloWorld.hs > > $ /opt/local/bin/macosx-app -v helloworld > > $ open helloworld.app > > > > I've never used a Mac.. Why do you run macosx-app > ? > > > > Doesn't > > $ ./helloworld > > work? > > > > Marc Weber > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From kr.angelov at gmail.com Fri May 23 03:03:29 2008 From: kr.angelov at gmail.com (Krasimir Angelov) Date: Fri May 23 02:56:46 2008 Subject: [Haskell-cafe] Data.Tree.Zipper in the standard libraries In-Reply-To: References: Message-ID: Aha. I see the point. The current design was influenced from some other implementation that I spot somewhere in the net. I will change it but this reminds me of another problem. Most movement functions raise error if they can't do the movement. This is convenient if you somehow know that the direction in which you go always exists. Alternatively I can use monad with failure. In other words, there are two possibilities: 1. Use error ".." and types like: TreeLoc a -> TreeLoc a 2. Use monad and type like: Monad m => TreeLoc a -> m (TreeLoc a) In the second case some one have to do something like this to check whether the operation is successful: case left loc of Noting -> error "something gone wrong" Just loc -> ... In the first case there is no way to check for success but someone can use precondition: if isFirst loc then do_something (left loc) else i_cannot_go_left In my opinion 1 looks nicer but 2 also have advantages. What do you think? Regards, Krasimir On Fri, May 23, 2008 at 12:33 AM, Conal Elliott wrote: >> * Every definition of tp > > I meant "of type", forgetting that my emacs abbrevs don't expand in gmail. > > On Thu, May 22, 2008 at 2:13 PM, Conal Elliott wrote: >> >> Hi Krasimir, >> >> I had a long exchange with chessguy about this interface, suggesting a >> significant change in style, simplifying the type. (Incidentally, the >> change removed the State and hence mtl dependence.) >> >> The conversation is on http://tunes.org/~nef/logs/haskell/08.05.17, >> starting with "12:08:11 w00t!" and really picking up with >> " chessguy: something smells funny ...". >> >> Here's a summary of the conversation, though I encourage you to read the >> whole thing: >> >> * Every definition of tp 'State (TreeLoc a) a', does a getLabel at the end >> (except getLabel). >> * Often users of those movement functions discard the result. >> * Simpler and more orthogonal would be remove the getLabel and return >> 'State (TreeLoc a) ()' instead. >> * Now remove that return value altogether, simplifying the type of zipper >> movements to just 'TreeLoc a -> TreeLoc a'. Then they compose nicely with >> (.), having id as identity. >> * Simplify the type of getLabel to just 'TreeLoc a -> a'. Now no more >> State. >> >> Cheers, - Conal >> >> >> On Thu, May 22, 2008 at 12:52 PM, Krasimir Angelov >> wrote: >>> >>> Hello Guys, >>> >>> We have Data.Tree in the standard libraries for a long time but for >>> some reason we still don't have standard implementation for Zipper. I >>> wrote recently one implementation for Yi but there are many other >>> versions hanging around. At least I know for some. I propose to add >>> one in the standard libraries i.e. the "containers" package. The >>> version that I use currently is here: >>> >>> http://code.haskell.org/yi/Data/Tree/Zipper.hs >>> >>> If you would like to do code review I will be happy to hear comments. >>> After the API is settled down I will write test cases also. One thing >>> that is worying me is that the current version uses State monad which >>> is in the "mtl" package while the natural place for Data.Tree.Zipper >>> is in "containers". This will create an extra dependency. Is this >>> acceptable? >>> >>> Regards, >>> Krasimir >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe@haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > > From kr.angelov at gmail.com Fri May 23 03:04:39 2008 From: kr.angelov at gmail.com (Krasimir Angelov) Date: Fri May 23 02:57:53 2008 Subject: [Haskell-cafe] Data.Tree.Zipper in the standard libraries In-Reply-To: References: Message-ID: On Fri, May 23, 2008 at 9:03 AM, Krasimir Angelov wrote: > if isFirst loc > then do_something (left loc) > else i_cannot_go_left I meant: if isFirst loc then i_cannot_go_left else do_something (left loc) From ross at soi.city.ac.uk Fri May 23 03:28:06 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Fri May 23 03:21:22 2008 Subject: [Haskell-cafe] Data.Tree.Zipper in the standard libraries In-Reply-To: References: Message-ID: <20080523072806.GA2713@soi.city.ac.uk> On Fri, May 23, 2008 at 09:03:29AM +0200, Krasimir Angelov wrote: > Alternatively I can use monad with failure. In other words, there are > two possibilities: > > 1. Use error ".." and types like: TreeLoc a -> TreeLoc a > 2. Use monad and type like: Monad m => TreeLoc a -> m (TreeLoc a) I'd suggest that TreeLoc a -> Maybe (TreeLoc a) is better than the second version. The problem with using Monad(fail) is that it hides possible runtime errors among testable conditions. With 1. you can at least search the code for occurrences of the dangerous function. With the Monad version you need to consider the type of each use to know whether it is dangerous. From alistair at abayley.org Fri May 23 04:08:09 2008 From: alistair at abayley.org (Alistair Bayley) Date: Fri May 23 04:01:24 2008 Subject: [Haskell-cafe] What to do when GHC works, RUNGHC fails In-Reply-To: <4835EC78.6020704@telenet.be> References: <4835EC78.6020704@telenet.be> Message-ID: <79d7c4980805230108s7af4a167w3d12202d6a9f8b1e@mail.gmail.com> 2008/5/22 Peter Verswyvelen : > The first thing I noticed is that RUNGHC looks for a DLL called "png.dll" > (which it doesn't find and then bails out with an error), while the > executable build with GHC uses the correct "libpng3.dll". When I rename the > libpng3.dll into png.dll, RUNGHC goes a bit further but then fails with an > "unknown symbol". Obviously I did something wrong in my Cabal script, but I > have no idea what it is. > > There seems to be a big difference when it comes to linking between of GHCi > and GHC . Any guidelines on what to do in cases like the one above? We had a similar problem with Takusen and ghci on Windows, where the PostgreSQL client dll is called libpq.dll, rather than pq.dll. We also solved it by copying pq.dll to libpq.dll. The extra-libs option is pq, rather than libpq. That fixed it for us, so I don't know why yours is still failing. Perhaps you can post a link to the src? Alistair From kr.angelov at gmail.com Fri May 23 04:48:01 2008 From: kr.angelov at gmail.com (Krasimir Angelov) Date: Fri May 23 04:41:22 2008 Subject: [Haskell-cafe] Data.Tree.Zipper in the standard libraries In-Reply-To: <20080523072806.GA2713@soi.city.ac.uk> References: <20080523072806.GA2713@soi.city.ac.uk> Message-ID: The monads design is used in Data.Map i.e. lookup :: (Monad m, Ord k) => k -> Map k a -> m a and I think that this will be more consistent. On 5/23/08, Ross Paterson wrote: > On Fri, May 23, 2008 at 09:03:29AM +0200, Krasimir Angelov wrote: > > Alternatively I can use monad with failure. In other words, there are > > two possibilities: > > > > 1. Use error ".." and types like: TreeLoc a -> TreeLoc a > > 2. Use monad and type like: Monad m => TreeLoc a -> m (TreeLoc a) > > I'd suggest that TreeLoc a -> Maybe (TreeLoc a) is better than the > second version. The problem with using Monad(fail) is that it hides > possible runtime errors among testable conditions. With 1. you can > at least search the code for occurrences of the dangerous function. > With the Monad version you need to consider the type of each use to know > whether it is dangerous. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From dominic.steinitz at blueyonder.co.uk Fri May 23 05:36:33 2008 From: dominic.steinitz at blueyonder.co.uk (Dominic Steinitz) Date: Fri May 23 05:29:55 2008 Subject: [Haskell-cafe] London Haskell Get Together Message-ID: For information, not an "official" user group get together but I believe the evening was enjoyed by all participants. Dominic. http://enhyper.blogspot.com/2008/05/haskell-get-together-22nd-may-2008.html From jules at jellybean.co.uk Fri May 23 06:55:10 2008 From: jules at jellybean.co.uk (Jules Bean) Date: Fri May 23 06:48:24 2008 Subject: [Haskell-cafe] Data.Tree.Zipper in the standard libraries In-Reply-To: References: <20080523072806.GA2713@soi.city.ac.uk> Message-ID: <4836A28E.9040702@jellybean.co.uk> Krasimir Angelov wrote: > The monads design is used in Data.Map i.e. > > lookup :: (Monad m, Ord k) => k -> Map k a -> m a which is widely considered a poor design decision and a wart on Data.Map. :-) Seriously, if you don't return a useful error message, then Maybe is as good as it gets, why not use it? (And there really is only one kind of error possible here, in each case) 'fail' only adds information in the case it has a useful error message (in which case I'd encourage MonadError m =>) Jules From Alistair.Bayley at invesco.com Fri May 23 07:05:55 2008 From: Alistair.Bayley at invesco.com (Bayley, Alistair) Date: Fri May 23 06:59:11 2008 Subject: [Haskell-cafe] Data.Tree.Zipper in the standard libraries In-Reply-To: <4836A28E.9040702@jellybean.co.uk> References: <20080523072806.GA2713@soi.city.ac.uk> <4836A28E.9040702@jellybean.co.uk> Message-ID: <125EACD0CAE4D24ABDB4D148C4593DA9049E93B5@GBLONXMB02.corp.amvescap.net> > From: haskell-cafe-bounces@haskell.org > [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Jules Bean > > Krasimir Angelov wrote: > > The monads design is used in Data.Map i.e. > > > > lookup :: (Monad m, Ord k) => k -> Map k a -> m a > > which is widely considered a poor design decision and a wart > on Data.Map. > > Seriously, if you don't return a useful error message, then > Maybe is as good as it gets, why not use it? > > (And there really is only one kind of error possible here, in > each case) > > 'fail' only adds information in the case it has a useful > error message (in which case I'd encourage MonadError m =>) Is there a reason not to recommend Either, if you want to return error information? It is an instance of MonadError. Alistair ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. ***************************************************************** From kr.angelov at gmail.com Fri May 23 07:42:27 2008 From: kr.angelov at gmail.com (Krasimir Angelov) Date: Fri May 23 07:35:46 2008 Subject: [Haskell-cafe] Data.Tree.Zipper in the standard libraries In-Reply-To: <4836A28E.9040702@jellybean.co.uk> References: <20080523072806.GA2713@soi.city.ac.uk> <4836A28E.9040702@jellybean.co.uk> Message-ID: That is annoying. I remember that there were people arguing that Monad should be used instead of Maybe but I don't remember the reasons. Personaly I feel quite happy with Maybe and I am using it in my own code. There should be a consistent approach in the different libraries or at least in a single package like "containers". While googling for Zipper I also found this article: http://citeseer.ist.psu.edu/hinze01web.html Is this better alternative to Zipper? Have someone better experience with it? Regards, Krasimir On 5/23/08, Jules Bean wrote: > Krasimir Angelov wrote: > > The monads design is used in Data.Map i.e. > > > > lookup :: (Monad m, Ord k) => k -> Map k a -> m a > > > > which is widely considered a poor design decision and a wart on Data.Map. > > :-) > > Seriously, if you don't return a useful error message, then Maybe is as good > as it gets, why not use it? > > (And there really is only one kind of error possible here, in each case) > > 'fail' only adds information in the case it has a useful error message (in > which case I'd encourage MonadError m =>) > > Jules > From bf3 at telenet.be Fri May 23 08:00:06 2008 From: bf3 at telenet.be (Peter Verswyvelen) Date: Fri May 23 07:53:26 2008 Subject: [Haskell-cafe] What to do when GHC works, RUNGHC fails In-Reply-To: <79d7c4980805230108s7af4a167w3d12202d6a9f8b1e@mail.gmail.com> References: <4835EC78.6020704@telenet.be> <79d7c4980805230108s7af4a167w3d12202d6a9f8b1e@mail.gmail.com> Message-ID: <086001c8bccc$8a9044c0$9fb0ce40$@be> So it seems the GHCi linker is not using the metadata in the library file correctly? The libpng.dll.a library file clearly contains a reference to libpng3.dll, and I guess since GHC is using the GCC linker, this works fine, but GHCi most likely has its own linker? If this is correct, we should file a bug report? > -----Original Message----- > From: abayley@gmail.com [mailto:abayley@gmail.com] On Behalf Of > Alistair Bayley > Sent: Friday, May 23, 2008 10:08 AM > To: Peter Verswyvelen > Cc: Haskell-Cafe > Subject: Re: [Haskell-cafe] What to do when GHC works, RUNGHC fails > > 2008/5/22 Peter Verswyvelen : > > The first thing I noticed is that RUNGHC looks for a DLL called > "png.dll" > > (which it doesn't find and then bails out with an error), while the > > executable build with GHC uses the correct "libpng3.dll". When I > rename the > > libpng3.dll into png.dll, RUNGHC goes a bit further but then fails > with an > > "unknown symbol". Obviously I did something wrong in my Cabal script, > but I > > have no idea what it is. > > > > There seems to be a big difference when it comes to linking between > of GHCi > > and GHC . Any guidelines on what to do in cases like the one above? > > We had a similar problem with Takusen and ghci on Windows, where the > PostgreSQL client dll is called libpq.dll, rather than pq.dll. We also > solved it by copying pq.dll to libpq.dll. The extra-libs option is pq, > rather than libpq. That fixed it for us, so I don't know why yours is > still failing. Perhaps you can post a link to the src? > > Alistair > > > > -- > No virus found in this incoming message. > Checked by AVG. > Version: 7.5.524 / Virus Database: 269.23.21/1457 - Release Date: > 5/20/2008 4:45 PM From alistair at abayley.org Fri May 23 08:21:38 2008 From: alistair at abayley.org (Alistair Bayley) Date: Fri May 23 08:14:51 2008 Subject: [Haskell-cafe] What to do when GHC works, RUNGHC fails In-Reply-To: <086001c8bccc$8a9044c0$9fb0ce40$@be> References: <4835EC78.6020704@telenet.be> <79d7c4980805230108s7af4a167w3d12202d6a9f8b1e@mail.gmail.com> <086001c8bccc$8a9044c0$9fb0ce40$@be> Message-ID: <79d7c4980805230521n11c2e273v2a29a8abc1ec5ca2@mail.gmail.com> 2008/5/23 Peter Verswyvelen : > So it seems the GHCi linker is not using the metadata in the library file correctly? The libpng.dll.a library file clearly contains a reference to libpng3.dll, and I guess since GHC is using the GCC linker, this works fine, but GHCi most likely has its own linker? > > If this is correct, we should file a bug report? This seems to be the same bug: http://hackage.haskell.org/trac/ghc/ticket/1883 The ghci linker is a custom one (AFAIK) and is "different" from GNU ld. That's a feature, not a bug :-) GNU ld, for example, can find either of libxxx.dll or xxx.dll if you say -lxxx. See this ticket for another difference between ghci and GNU ld (ghci's linker tries to link _all_ symbols in the library archive, rather than just the modules that you're using): http://hackage.haskell.org/trac/ghc/ticket/1477 Alistair From eeoam at ukfsn.org Fri May 23 09:27:52 2008 From: eeoam at ukfsn.org (Eric) Date: Fri May 23 09:21:16 2008 Subject: [Haskell-cafe] Trying to write a very simple HTTP Client Message-ID: <4836C658.3030801@ukfsn.org> Hi all, I've written the following program to connect to a submit an HTTP GET request to a server and print the response: module Main where import Network import System.IO main = withSocketsDo go go = do putStrLn "Connecting..." out <- connectTo "haskell.org" (PortNumber 80) hPutStrLn out "GET /\r" hPutStrLn out "Host: haskell.org\r" hPutStrLn out "\r" cs <- hGetLine out hClose out print cs When I run the program, however, I get the following error: HTTPClient: : hGetLine: end of file Can anyone see what's wrong? E. From dokondr at gmail.com Fri May 23 09:30:05 2008 From: dokondr at gmail.com (Dmitri O.Kondratiev) Date: Fri May 23 09:23:20 2008 Subject: [Haskell-cafe] Newbie: State monad example questions In-Reply-To: References: <53396d9e0805191404va8cb2d7yeb36954b83ac5ca8@mail.gmail.com> <53396d9e0805210542n667d6596uca6b8caf89e30219@mail.gmail.com> <53396d9e0805210810m6f48596jde8e98f7394403c6@mail.gmail.com> Message-ID: <53396d9e0805230630v368248b3hb1c5957835e2a2bc@mail.gmail.com> Do any general-purpose monad 'do' (>>=) and (>>) operator desugaring tools exist? Such that I could first go from 'do' to bind notation and then expand (>>=) definition, as Oliver compactly did. I also tried to expand (>>=) by hand in 'getAny' code, though somewhat differently (see below my pseudo Haskell code) using this definition of (>>=): {-- (>>=) :: State StdGen Int -> (Int -> State StdGen Int) -> State StdGen Int (State so1) >=> fn = State(\g1 -> let(v1, g2) = so1 g1 so2 = fn v1 in (runState so2) g2) --} -- -- First 'getAny' with 'do' notation: -- getAny :: (Random a) => State StdGen a getAny = do g <- get (x,g') <- return $ random g put g' return x -- -- 'getAny' after expanding 'do' into (>>=) : -- getAnyNoSugar :: (Random a) => State StdGen a getAnyNoSugar = (State $ \s -> (s, s)) >>= \g -> (State $ \s -> (random g, s)) >>= \(x,g') -> (State $ \_ -> ((), g')) >> (State $ \s -> (x, s)) -- -- And here is my 'by hand' expansion in pseudo Haskell (may be wrong?): -- {-- o1 = (State $ \s -> (s, s)) o2 = (State $ \s -> (random g, s)) o3 = (State $ \_ -> ((), g')) o4 = (State $ \s -> (x, s)) getAnyNoSugar = o1 >>= f1 f1 = \g -> o2 >>= f2 f2 = \(x,g') -> o3 >>= f3 f3 = \_ -> o4 runState (o1 >>= f1) gen1 ~> State (\g1 -> let v1 = gen1 g2 = gen1 so2 = f1 gen1 in (runState (f1 gen1))) gen1 f1 gen1 ~> (State $ \s -> (random gen1, s)) >>= f2 ~> State (\g1 -> let v1 = random gen1 g2 = gen1 so2 = f2 (random gen1) in (runState (f2 (random gen1)))) gen1 f2 (random gen1) ~> random gen1 = (rv, rg) ~> f2 (rv, rg) ~> State (\g1 -> let x = rv g' = rg (State $ \_ -> ((), rg)) >>= f3 v1 = () g2 = rg so2 = f3 () in (runState (f3 ()) rg)) f3 () ~> o4 ~> (State $ \s -> (rv, s)) runState (o1 >>= f1) gen1 ~> ~> runState State (\g1 -> runState (State (\g1 -> (f2 (random gen1))))) gen1 ~> runState State (\g1 -> runState (State (\g1 -> runState (State (\g1 -> (f3 ()) rg))))) gen1 ~> runState State (\g1 -> runState (State (\g1 -> runState (State (\g1 -> runState (State $ \s -> (rv, s)) rg))))) gen1 -- State (\g1 -> runState (State $ \s -> (rv, s)) rg = State(\g1 -> (rv, rg)) ~> runState State (\g1 -> runState (State (\g1 -> runState (State (\g1 -> (rv, rg)))))) gen1 ~> (rv, rg) --} On Wed, May 21, 2008 at 10:31 PM, Olivier Boudry wrote: > On Wed, May 21, 2008 at 11:10 AM, Dmitri O.Kondratiev > wrote: > >> But how will 'g1' actually get delivered from 'makeRandomValueST g1' to >> invocation of 'getAny' I don't yet understand! >> >> > It may be easier to understand the state passing if you remove the do > notation and replace get, put and return with their definition in the > instance declarations (Monad and MonadState). > > getAny :: (Random a) => State StdGen a > getAny = do g <- get > (x,g') <- return $ random g > put g' > return x > > get = State $ \s -> (s, s) -- copy the state as a return value and pass > state > put s = State $ \_ -> ((), s) -- return unit, ignore the passed state and > replace it with the state given as parameter. > return a = State $ \s -> (a, s) -- return given value and pass state. > > getAnyNoSugar :: (Random a) => State StdGen a > getAnyNoSugar = (State $ \s -> (s, s)) >>= \g -> > (State $ \s -> (random g, s)) >>= \(x,g') -> > (State $ \_ -> ((), g')) >> > (State $ \s -> (x, s)) > > The function is still useable this way and the state transformations should > be a bit more visible. The first element of the tuple is the value that will > be used to call the next function (of type Monad m => a -> m b). The second > element of the tuple is the state and the (>>=) operator will handle passing > it between actions. > > Desugaring the (>>=) and (>>) operators would give you something like this > (I replaced `s` with `y` in the `put` and `return` desugaring and simplified > it): > > State $ \s = let > (g, s') = (\y -> (y,y)) s > ((x,g'), s'') = (\y -> (random g, y)) s' > (_, s''') = (\_ -> ((), g')) s'' > in (x, s''') > > Which is explict state passing between function calls. Extract the State > using `runState`, run it with an initial state and it should give you the > expected result. > > Regards, > > Olivier. > -- Dmitri O. Kondratiev dokondr@gmail.com http://www.geocities.com/dkondr -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080523/844828a6/attachment.htm From johan.tibell at gmail.com Fri May 23 09:58:04 2008 From: johan.tibell at gmail.com (Johan Tibell) Date: Fri May 23 09:51:22 2008 Subject: [Haskell-cafe] Trying to write a very simple HTTP Client In-Reply-To: <4836C658.3030801@ukfsn.org> References: <4836C658.3030801@ukfsn.org> Message-ID: <90889fe70805230658j27ac5092s7e480bc03f64b054@mail.gmail.com> On Fri, May 23, 2008 at 3:27 PM, Eric wrote: > Hi all, > > I've written the following program to connect to a submit an HTTP GET > request to a server and print the response: > > module Main where > > import Network > import System.IO > > main = withSocketsDo go > > go = do putStrLn "Connecting..." > out <- connectTo "haskell.org" (PortNumber 80) > hPutStrLn out "GET /\r" > hPutStrLn out "Host: haskell.org\r" > hPutStrLn out "\r" > cs <- hGetLine out > hClose out > print cs > > When I run the program, however, I get the following error: > > HTTPClient: : hGetLine: end of file > > Can anyone see what's wrong? I think you need to either print cs before you close the socket or make sure that cs is force (~computed) before you close the socket as laziness makes it get evaluated when you call print cs rather than when you call hGetLine. In other words, you try to read from the socket after you've closed it. Cheers, Johan From kolar at fit.vutbr.cz Fri May 23 10:54:39 2008 From: kolar at fit.vutbr.cz (Dusan Kolar) Date: Fri May 23 10:47:54 2008 Subject: [Haskell-cafe] Bug in parallel GHC runtime? Message-ID: <4836DAAF.7090701@fit.vutbr.cz> Hello all, The attached file was compiled by the following command: ghc -O2 --make -threaded ltest1pl.hs -o alall When run in a sequential mode, I get this result: ./alall Starting ... Lst1: 41666666650000 Lst2: 41669166700000 T1: 0m 1.0e-6s 36 End! On the other hand, when run in a threaded mode, I get the following error: ./alall +RTS -N2 Starting ... Lst1: 41666666650000 Lst2: 41669166700000 T1: 0m 0.0s Segmentation fault Is it fault of the GHC runtime, or is it something on my side? My machine: uname -a Linux pc 2.6.24-ARCH #1 SMP PREEMPT Sun Mar 30 10:50:22 CEST 2008 x86_64 Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz GenuineIntel GNU/Linux My ghc: ghc --version The Glorious Glasgow Haskell Compilation System, version 6.8.2 Thanks and regards Dusan -------------- next part -------------- --import Control.Concurrent --import Control.Concurrent.MVar import System.Time import Control.Parallel.Strategies --import Data.List (foldl') import qualified Data.ByteString as B sumAllSums [] = 0 sumAllSums l@(_:xs) = sumlist 0 l + sumAllSums xs where sumlist res [] = res sumlist sr (v:vs) = sumlist (sr+v) vs wlist2wbs [] = B.pack [] wlist2wbs l@(_:_) = B.pack $ encode l where encode :: Integral a => [Int] -> [a] encode [] = [] encode (x:xs) = if x==0 then 0:0:encode xs else fromIntegral (x `mod` 256) : fromIntegral (x `div` 256) : encode xs main = do putStrLn $ "Starting ..." let lst1 = [0..49999] let lst2 = [0..50000] let bs1 = wlist2wbs lst1 let bs2 = wlist2wbs lst2 tm1 <- getClockTime let (v1:v2:_) = parMap rnf sumAllSums [lst1,lst2] tm1' <- getClockTime putStrLn ("Lst1: " ++ show v1) putStrLn ("Lst2: " ++ show v2) let tdiff1 = diffClockTimes tm1' tm1 --let tdiff2 = diffClockTimes tm2' tm2 putStrLn $ "T1: " ++ show (tdMin tdiff1) ++ "m " ++ show (fromIntegral(tdSec tdiff1) + fromIntegral(tdPicosec tdiff1)/1e12) ++ "s" --putStrLn $ "T2: " ++ show (tdMin tdiff2) ++ "m " ++ show (fromIntegral(tdSec tdiff2) + fromIntegral(tdPicosec tdiff2)/1e12) ++ "s" putStrLn $ show $ {-ibs1 +-} B.index bs1 99999 + B.index bs2 49999 {-((bs1 + fromIntegral (B.index bs2 99999)) :: Integer)-} putStrLn $ "End!" {- main = do tm1 <- getClockTime putStrLn $ "Starting ... " mv1 <- newEmptyMVar mv2 <- newEmptyMVar t1 <- forkIO (putMVar mv1 $! sumAllSums [0..49999]) t2 <- forkIO (putMVar mv2 $! sumAllSums [1..50000]) v1 <- takeMVar mv1 v2 <- takeMVar mv2 killThread t1 killThread t2 putStrLn $ "Result: " ++ show (v1+v2) tm2 <- getClockTime let tdiff = diffClockTimes tm2 tm1 putStrLn $ "End! " ++ show (tdMin tdiff) ++ "m " ++ show (fromIntegral(tdSec tdiff) + fromIntegral(tdPicosec tdiff)/1e12) ++ "s" -} From robgreayer at yahoo.com Fri May 23 10:59:53 2008 From: robgreayer at yahoo.com (Robert Greayer) Date: Fri May 23 10:53:06 2008 Subject: [Haskell-cafe] Trying to write a very simple HTTP Client In-Reply-To: <4836C658.3030801@ukfsn.org> Message-ID: <169036.55667.qm@web65714.mail.ac4.yahoo.com> --- Eric wrote: > Hi all, > > I've written the following program to connect to a > submit an HTTP GET > request to a server and print the response: > > module Main where > > import Network > import System.IO > > main = withSocketsDo go > > go = do putStrLn "Connecting..." > out <- connectTo "haskell.org" > (PortNumber 80) > hPutStrLn out "GET /\r" > hPutStrLn out "Host: haskell.org\r" > hPutStrLn out "\r" > cs <- hGetLine out > hClose out > print cs > > When I run the program, however, I get the following > error: > > HTTPClient: : hGetLine: end of file > > Can anyone see what's wrong? > > > E. Try calling 'hFlush out' prior to the call to hGetLine. I believe the output to the socket is buffered, so the receiver isn't seeing your GET request, and eventually closes the connection on its end, leading to the EOF on the hGetLine. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From miguelimo38 at yandex.ru Fri May 23 11:02:39 2008 From: miguelimo38 at yandex.ru (Miguel Mitrofanov) Date: Fri May 23 10:56:05 2008 Subject: [Haskell-cafe] Data.Tree.Zipper in the standard libraries In-Reply-To: <4836A28E.9040702@jellybean.co.uk> References: <20080523072806.GA2713@soi.city.ac.uk> <4836A28E.9040702@jellybean.co.uk> Message-ID: I think that MonadZero m => ... is better than just Maybe. If you can have more general solution for free, why fight it? On 23 May 2008, at 14:55, Jules Bean wrote: > Krasimir Angelov wrote: >> The monads design is used in Data.Map i.e. >> lookup :: (Monad m, Ord k) => k -> Map k a -> m a > > which is widely considered a poor design decision and a wart on > Data.Map. > > :-) > > Seriously, if you don't return a useful error message, then Maybe is > as good as it gets, why not use it? > > (And there really is only one kind of error possible here, in each > case) > > 'fail' only adds information in the case it has a useful error > message (in which case I'd encourage MonadError m =>) > > Jules > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From lemming at henning-thielemann.de Fri May 23 11:09:18 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri May 23 11:01:01 2008 Subject: [Haskell-cafe] Announce: ghc-core, command line pager for reading GHC Core In-Reply-To: <404396ef0805020033q74dfbad4qfb5bf1a425c3fa03@mail.gmail.com> References: <20080502014857.GA1722@scytale.galois.com> <404396ef0805020033q74dfbad4qfb5bf1a425c3fa03@mail.gmail.com> Message-ID: On Fri, 2 May 2008, Neil Mitchell wrote: > Hi Don, > >> Just a quick announcement, I've uploaded to hackage 'ghc-core' , a >> wrapper over ghc for displaying the optimised core and assembly language >> ghc produces from your programs. > > This is cool, but it still lags behind the facilities found in yhc-core. > > http://yhc06.blogspot.com/2006/12/yhccorehtml.html > > I have found that any effort put into improving Core viewing tools > repays itself rather quickly, and that HTML output with hyperlinks is > incredibly handy! I have tried ghc-core now. I find the idea really good to make Core more readable, but although my examples are moderately small the Core already spans several pages. Thus highlighting alone is of limitted help. Indeed, if the output would be HTML as Neil proposed, this would be cool. Then I could quickly find out, what value 'lit_r3gZ' refers to. From jules at jellybean.co.uk Fri May 23 11:09:10 2008 From: jules at jellybean.co.uk (Jules Bean) Date: Fri May 23 11:02:25 2008 Subject: [Haskell-cafe] Data.Tree.Zipper in the standard libraries In-Reply-To: References: <20080523072806.GA2713@soi.city.ac.uk> <4836A28E.9040702@jellybean.co.uk> Message-ID: <4836DE16.3020902@jellybean.co.uk> Miguel Mitrofanov wrote: > I think that MonadZero m => ... is better than just Maybe. If you can > have more general solution for free, why fight it? Because Maybe exists and MonadZero doesn't? Jules From bulat.ziganshin at gmail.com Fri May 23 11:08:14 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Fri May 23 11:04:16 2008 Subject: [Haskell-cafe] Trying to write a very simple HTTP Client In-Reply-To: <90889fe70805230658j27ac5092s7e480bc03f64b054@mail.gmail.com> References: <4836C658.3030801@ukfsn.org> <90889fe70805230658j27ac5092s7e480bc03f64b054@mail.gmail.com> Message-ID: <1179666601.20080523190814@gmail.com> Hello Johan, Friday, May 23, 2008, 5:58:04 PM, you wrote: >> cs <- hGetLine out >> hClose out >> print cs >> > I think you need to either print cs before you close the socket or > make sure that cs is force (~computed) before you close the socket as > laziness makes it get evaluated when you call print cs rather than > when you call hGetLine. In other words, you try to read from the > socket after you've closed it. hGetLine, unlike hGetContents, has a strict semantics. actually, hGetContents is only lazy i/o operation, everything else (hGetChar, hGetBuf, hGetArray) is strict -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From tphyahoo at gmail.com Fri May 23 11:11:21 2008 From: tphyahoo at gmail.com (Thomas Hartman) Date: Fri May 23 11:04:36 2008 Subject: [Haskell-cafe] problems with derive/TH Message-ID: <910ddf450805230811v164ee48bp92544d433f086238@mail.gmail.com> Haskellers/Chris, As part of my quest to better understand STM and eventually build a concurrent haskell server app, I checked out an embryonic haskell mud demo from Chris Smith's repo. It seemed like a great sample app. But I ran into a build issue that seems to have to do with derive/TH. I am assuming this used to work, but something changed, either in TH itself or switching from ghc6.6 to ghc6.8. From the error message (below) I surmise either a) M.Map based values used to automagically work with derive/TH, but no longer do... in which case I need to create this instance manually or b) this should still work, more or less... but I have to import the map instance via an additional module, or something like that. Any advice? Thomas. ***** This is the error I am getting: thartman@thartman-laptop:~/mud>cat _darcs/prefs/defaultrepo http://cdsmith.twu.net/demos/mud thartman@thartman-laptop:~/mud>ghc --version The Glorious Glasgow Haskell Compilation System, version 6.8.2 thartman@thartman-laptop:~/mud>runghc Setup.lhs configure; runghc Setup.lhs build Configuring mud-0.1... Preprocessing executables for mud-0.1... Building mud-0.1... [2 of 5] Compiling World ( World.hs, dist/build/mud/mud-tmp/World.o ) World.hs:42:0: No instances for (Eq (a (M.Map String Player)), Eq (a (M.Map ItemId Item)), Eq (a (M.Map PlayerId Player)), Eq (a (M.Map RoomId Room)), Eq (a RoomId)) arising from the 'deriving' clause of a data type declaration at World.hs:(42,0)-(50,14) Possible fix: add an instance declaration for (Eq (a (M.Map String Player)), Eq (a (M.Map ItemId Item)), Eq (a (M.Map PlayerId Player)), Eq (a (M.Map RoomId Room)), Eq (a RoomId)) When deriving the instance for (Eq (World a)) From lemming at henning-thielemann.de Fri May 23 11:54:36 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri May 23 11:46:25 2008 Subject: [Haskell-cafe] Announce: ghc-core, command line pager for reading GHC Core In-Reply-To: <404396ef0805020033q74dfbad4qfb5bf1a425c3fa03@mail.gmail.com> References: <20080502014857.GA1722@scytale.galois.com> <404396ef0805020033q74dfbad4qfb5bf1a425c3fa03@mail.gmail.com> Message-ID: On Fri, 2 May 2008, Neil Mitchell wrote: > Hi Don, > >> Just a quick announcement, I've uploaded to hackage 'ghc-core' , a >> wrapper over ghc for displaying the optimised core and assembly language >> ghc produces from your programs. > > This is cool, but it still lags behind the facilities found in yhc-core. > > http://yhc06.blogspot.com/2006/12/yhccorehtml.html > > I have found that any effort put into improving Core viewing tools > repays itself rather quickly, and that HTML output with hyperlinks is > incredibly handy! An even more advanced tool could show differences between two Core listings. Say I have a program which runs too slow. But if I change a small detail it runs significantly faster - I want to know, how did my change in the Haskell file modified the Core and why the speedup. Showing differences between Core files will certainly be complicated because the generated identifiers are completely different. I don't know whether the order of declarations is a problem. I have an example here where a program becomes faster by a factor of 10 with a rather small change. First I thought the slow thing must be the higher order function which occurs in the Core and is not inlined, but it is present in the slow and the fast variant of the program. From scook0 at gmail.com Fri May 23 11:54:34 2008 From: scook0 at gmail.com (Stuart Cook) Date: Fri May 23 11:47:48 2008 Subject: [Haskell-cafe] problems with derive/TH In-Reply-To: <910ddf450805230811v164ee48bp92544d433f086238@mail.gmail.com> References: <910ddf450805230811v164ee48bp92544d433f086238@mail.gmail.com> Message-ID: <49b351060805230854r5463a058o8d3e8571326559f8@mail.gmail.com> On Sat, May 24, 2008 at 1:11 AM, Thomas Hartman wrote: > World.hs:42:0: > No instances for (Eq (a (M.Map String Player)), > Eq (a (M.Map ItemId Item)), > Eq (a (M.Map PlayerId Player)), > Eq (a (M.Map RoomId Room)), > Eq (a RoomId)) > arising from the 'deriving' clause of a data type declaration > at World.hs:(42,0)-(50,14) > Possible fix: > add an instance declaration for > (Eq (a (M.Map String Player)), > Eq (a (M.Map ItemId Item)), > Eq (a (M.Map PlayerId Player)), > Eq (a (M.Map RoomId Room)), > Eq (a RoomId)) > When deriving the instance for (Eq (World a)) This error looks suspicious: notice that "a" in a type-constructor position. My guess is that you're accidentally using World's type parameter in a strange way. Perhaps you should double-check that your types and constructor definitions are using parentheses appropriately. Stuart From alfonso.acosta at gmail.com Fri May 23 12:01:28 2008 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Fri May 23 11:54:42 2008 Subject: [Haskell-cafe] problems with derive/TH In-Reply-To: <910ddf450805230811v164ee48bp92544d433f086238@mail.gmail.com> References: <910ddf450805230811v164ee48bp92544d433f086238@mail.gmail.com> Message-ID: <6a7c66fc0805230901q311b0630yaafe0b97a43f3650@mail.gmail.com> On Fri, May 23, 2008 at 5:11 PM, Thomas Hartman wrote: > I am assuming this used to work, but something changed, either in TH > itself or switching from ghc6.6 to ghc6.8. The "deriving" rules of 6.8 are more restrictive in some cases. However, the same result can be obtained in 6.8 byt using stand-alone deriving declarations: http://www.haskell.org/ghc/docs/latest/html/users_guide/deriving.html#stand-alone-deriving I guess this can be the problem. From eeoam at ukfsn.org Fri May 23 12:19:32 2008 From: eeoam at ukfsn.org (Eric) Date: Fri May 23 12:13:17 2008 Subject: [Haskell-cafe] Trying to write a very simple HTTP Client In-Reply-To: <169036.55667.qm@web65714.mail.ac4.yahoo.com> References: <169036.55667.qm@web65714.mail.ac4.yahoo.com> Message-ID: <4836EE94.602@ukfsn.org> Robert Greayer wrote: > --- Eric wrote: > > >> Hi all, >> >> I've written the following program to connect to a >> submit an HTTP GET >> request to a server and print the response: >> >> module Main where >> >> import Network >> import System.IO >> >> main = withSocketsDo go >> >> go = do putStrLn "Connecting..." >> out <- connectTo "haskell.org" >> (PortNumber 80) >> hPutStrLn out "GET /\r" >> hPutStrLn out "Host: haskell.org\r" >> hPutStrLn out "\r" >> cs <- hGetLine out >> hClose out >> print cs >> >> When I run the program, however, I get the following >> error: >> >> HTTPClient: : hGetLine: end of file >> >> Can anyone see what's wrong? >> >> >> E. >> > > Try calling 'hFlush out' prior to the call to > hGetLine. I believe the output to the socket is > buffered, so the receiver isn't seeing your GET > request, and eventually closes the connection on its > end, leading to the EOF on the hGetLine. > > That works! Thank you! Eric M. From lemming at henning-thielemann.de Fri May 23 12:31:24 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri May 23 12:23:07 2008 Subject: [Haskell-cafe] Announce: ghc-core, command line pager for reading GHC Core In-Reply-To: References: <20080502014857.GA1722@scytale.galois.com> <404396ef0805020033q74dfbad4qfb5bf1a425c3fa03@mail.gmail.com> Message-ID: On Fri, 23 May 2008, Henning Thielemann wrote: > An even more advanced tool could show differences between two Core listings. > Say I have a program which runs too slow. But if I change a small detail it > runs significantly faster - I want to know, how did my change in the Haskell > file modified the Core and why the speedup. > Showing differences between Core files will certainly be complicated because > the generated identifiers are completely different. I don't know whether the > order of declarations is a problem. > > I have an example here where a program becomes faster by a factor of 10 with > a rather small change. First I thought the slow thing must be the higher > order function which occurs in the Core and is not inlined, but it is present > in the slow and the fast variant of the program. In this special example, actually simple 'diff' spotted the critical difference, namely a polymorphic function was called. Now I'm in a dilemma: I can either INLINE the function, then it's whole body is copied into main program, which is not necessary here. However this solution would guarantee speed in every case. Or I can SPECIALISE the function, then the function will only be called, but with polymorphism overhead eliminated. This would only work for a restricted range of types. I'd like to have a pragma, that tells GHC to specialise a function for every type it is called with. From igloo at earth.li Fri May 23 12:31:51 2008 From: igloo at earth.li (Ian Lynagh) Date: Fri May 23 12:25:16 2008 Subject: [Haskell-cafe] Announce: ghc-core, command line pager for reading GHC Core In-Reply-To: References: <20080502014857.GA1722@scytale.galois.com> <404396ef0805020033q74dfbad4qfb5bf1a425c3fa03@mail.gmail.com> Message-ID: <20080523163151.GA1279@matrix.chaos.earth.li> On Fri, May 23, 2008 at 05:54:36PM +0200, Henning Thielemann wrote: > > An even more advanced tool could show differences between two Core > listings. That would be great. In the meantime, from GHC 6.10, -ddump-simpl -dsuppress-uniques can be good enough to get by (it means you don't get different random names, so diff more-or-less works). Thanks Ian From dons at galois.com Fri May 23 12:31:53 2008 From: dons at galois.com (Don Stewart) Date: Fri May 23 12:25:46 2008 Subject: [Haskell-cafe] Announce: ghc-core, command line pager for reading GHC Core In-Reply-To: References: <20080502014857.GA1722@scytale.galois.com> <404396ef0805020033q74dfbad4qfb5bf1a425c3fa03@mail.gmail.com> Message-ID: <20080523163153.GA32582@scytale.galois.com> lemming: > > On Fri, 23 May 2008, Henning Thielemann wrote: > > >An even more advanced tool could show differences between two Core > >listings. Say I have a program which runs too slow. But if I change a > >small detail it runs significantly faster - I want to know, how did my > >change in the Haskell file modified the Core and why the speedup. > >Showing differences between Core files will certainly be complicated > >because the generated identifiers are completely different. I don't know > >whether the order of declarations is a problem. > > > >I have an example here where a program becomes faster by a factor of 10 > >with a rather small change. First I thought the slow thing must be the > >higher order function which occurs in the Core and is not inlined, but it > >is present in the slow and the fast variant of the program. > > In this special example, actually simple 'diff' spotted the critical > difference, namely a polymorphic function was called. Now I'm in a > dilemma: I can either INLINE the function, then it's whole body is copied > into main program, which is not necessary here. However this solution > would guarantee speed in every case. Or I can SPECIALISE the function, > then the function will only be called, but with polymorphism overhead > eliminated. This would only work for a restricted range of types. I'd like > to have a pragma, that tells GHC to specialise a function for every type > it is called with. > I usually go with inlining, and get GHC as a whole program optimising compiler. -- Don From bulat.ziganshin at gmail.com Fri May 23 12:56:02 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Fri May 23 12:51:48 2008 Subject: [Haskell-cafe] Announce: ghc-core, command line pager for reading GHC Core In-Reply-To: References: <20080502014857.GA1722@scytale.galois.com> <404396ef0805020033q74dfbad4qfb5bf1a425c3fa03@mail.gmail.com> Message-ID: <1832550999.20080523205602@gmail.com> Hello Henning, Friday, May 23, 2008, 8:31:24 PM, you wrote: > would guarantee speed in every case. Or I can SPECIALISE the function, > then the function will only be called, but with polymorphism overhead > eliminated. This would only work for a restricted range of types. I'd like > to have a pragma, that tells GHC to specialise a function for every type > it is called with. me too. btw, this already present in jhc. inlining doesn't work in any complex case since recursive functions can't be inlined -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From dons at galois.com Fri May 23 13:30:26 2008 From: dons at galois.com (Don Stewart) Date: Fri May 23 13:23:54 2008 Subject: [Haskell-cafe] Announce: ghc-core, command line pager for reading GHC Core In-Reply-To: <20080523163151.GA1279@matrix.chaos.earth.li> References: <20080502014857.GA1722@scytale.galois.com> <404396ef0805020033q74dfbad4qfb5bf1a425c3fa03@mail.gmail.com> <20080523163151.GA1279@matrix.chaos.earth.li> Message-ID: <20080523173026.GA4034@scytale.galois.com> igloo: > On Fri, May 23, 2008 at 05:54:36PM +0200, Henning Thielemann wrote: > > > > An even more advanced tool could show differences between two Core > > listings. > > That would be great. In the meantime, from GHC 6.10, > -ddump-simpl -dsuppress-uniques > can be good enough to get by (it means you don't get different random > names, so diff more-or-less works). > Great! That's easier than doing the renaming on the tool side. -- Don From lrpalmer at gmail.com Fri May 23 13:34:50 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Fri May 23 13:28:03 2008 Subject: [Haskell-cafe] Data.Tree.Zipper in the standard libraries In-Reply-To: <4836A28E.9040702@jellybean.co.uk> References: <20080523072806.GA2713@soi.city.ac.uk> <4836A28E.9040702@jellybean.co.uk> Message-ID: <7ca3f0160805231034w39e8cfe7kbd77e6134fb81aa5@mail.gmail.com> On Fri, May 23, 2008 at 10:55 AM, Jules Bean wrote: > Krasimir Angelov wrote: >> >> The monads design is used in Data.Map i.e. >> >> lookup :: (Monad m, Ord k) => k -> Map k a -> m a > > which is widely considered a poor design decision and a wart on Data.Map. It is? Can you point to somewhere explaining that? I rather liked that idiom. Luke From allbery at ece.cmu.edu Fri May 23 13:36:04 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Fri May 23 13:29:18 2008 Subject: [Haskell-cafe] Data.Tree.Zipper in the standard libraries In-Reply-To: <7ca3f0160805231034w39e8cfe7kbd77e6134fb81aa5@mail.gmail.com> References: <20080523072806.GA2713@soi.city.ac.uk> <4836A28E.9040702@jellybean.co.uk> <7ca3f0160805231034w39e8cfe7kbd77e6134fb81aa5@mail.gmail.com> Message-ID: <45D5B77B-D921-4803-9D11-0320DCAE8111@ece.cmu.edu> On 2008 May 23, at 13:34, Luke Palmer wrote: > On Fri, May 23, 2008 at 10:55 AM, Jules Bean > wrote: >> Krasimir Angelov wrote: >>> >>> The monads design is used in Data.Map i.e. >>> >>> lookup :: (Monad m, Ord k) => k -> Map k a -> m a >> >> which is widely considered a poor design decision and a wart on >> Data.Map. > > It is? Can you point to somewhere explaining that? I rather liked > that idiom. I'd argue that the poor design decision was killing MonadZero, and the type of Data.Map.lookup is a hackaround. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From dons at galois.com Fri May 23 13:45:04 2008 From: dons at galois.com (Don Stewart) Date: Fri May 23 13:38:20 2008 Subject: [Haskell-cafe] Data.Tree.Zipper in the standard libraries In-Reply-To: References: <20080523072806.GA2713@soi.city.ac.uk> Message-ID: <20080523174504.GB4034@scytale.galois.com> Using 'monad' here makes it easier to make a mistake with the code, as it permits new kinds of unexpected failure. This is Haskell, we should use Maybe. And users that want it can lift Maybe a -> m a -- Don (-1) for new uses of fail in place of Nothing. kr.angelov: > The monads design is used in Data.Map i.e. > > lookup :: (Monad m, Ord k) => k -> Map k a -> m a > > and I think that this will be more consistent. > > > On 5/23/08, Ross Paterson wrote: > > On Fri, May 23, 2008 at 09:03:29AM +0200, Krasimir Angelov wrote: > > > Alternatively I can use monad with failure. In other words, there are > > > two possibilities: > > > > > > 1. Use error ".." and types like: TreeLoc a -> TreeLoc a > > > 2. Use monad and type like: Monad m => TreeLoc a -> m (TreeLoc a) > > > > I'd suggest that TreeLoc a -> Maybe (TreeLoc a) is better than the > > second version. The problem with using Monad(fail) is that it hides > > possible runtime errors among testable conditions. With 1. you can > > at least search the code for occurrences of the dangerous function. > > With the Monad version you need to consider the type of each use to know > > whether it is dangerous. > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From anogin at hrl.com Fri May 23 14:04:35 2008 From: anogin at hrl.com (Aleksey Nogin) Date: Fri May 23 13:57:50 2008 Subject: [Haskell-cafe] Re: throwDynIO ? Message-ID: <48370733.4050403@hrl.com> Back in October'06 Carlos Pita sent a message to this list: > Currently I'm trying to grasp haskell exception handling and although > I find it mostly clear I'm a bit confused regarding the lack of a > throwDynIO action "paralelling" throwIO, as there are dynamic variants > for the other throw functions: > > throwDyn - throw > throwDynTo - throwTo > > I understand that the same effect could be conjured up by > > throwIO (DynException (...))) > > magic. But the lack of symmetry still disturbes me. Am I missing something? As far as I can tell, his question was left unanswered. As another Haskell newcomer (crossing over from the OCaml world), I found the absence of throwDynIO weird as well - as far as I understand things, throwing an error in the IO monad seems like a safer thing to do (as I'd know precisely when to expect it to be raised) than throwing it from a pure code and then relying on the "imprecise exceptions" mechanism to get it right. Looking at the ghc-6.8.2/libraries/base/Control/Exception.hs in the GHC source code, I see the following definitions: throw = unsafePerformIO . throwIO throwDyn exception = throw (DynException (toDyn exception)) so I guess I can get define throwDynIO myself by "taking back" the unsafePerformIO: throwDynIO exception = throwIO (DynException (toDyn exception)) but I am still wondering whether the library is simply incomplete here, or whether there is some reason for not defining/using throwDynIO. Thanks in advance for any clarifications! Aleksey From lordgeoffrey at optushome.com.au Fri May 23 14:07:03 2008 From: lordgeoffrey at optushome.com.au (geoffrey) Date: Fri May 23 14:00:18 2008 Subject: [Haskell-cafe] newbie: maintaining relationships Message-ID: <1211566023.5530.5.camel@geoffrey> I am learning haskell and i need some advice about writing functional-style code. Give the following code below, my question is - how do i setup a dependency of User on Common? Obviously what i have there is wrong, because a change in common (i know it's actually immutable) is not reflected in the version captured by User. I understand why my current approach has not a chance a of working, I am using it to, hopefully, illustrate my goal. Thanks for any suggestions > data Common = Common { > cName :: String, > cValue :: Int > } deriving (Show) > data User = User { > uCommon :: Common > } deriving (Show) > makeWorld = (commons, users) > where > commons = [Common "A" 1, Common "B" 2] > users = [User (head commons)] > > main = do > let world = makeWorld > putStrLn (show world) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080524/c04f7d8e/attachment.htm From dons at galois.com Fri May 23 14:33:48 2008 From: dons at galois.com (Don Stewart) Date: Fri May 23 14:27:13 2008 Subject: [Haskell-cafe] Bug in parallel GHC runtime? In-Reply-To: <4836DAAF.7090701@fit.vutbr.cz> References: <4836DAAF.7090701@fit.vutbr.cz> Message-ID: <20080523183348.GE4034@scytale.galois.com> Hi, Thanks for the bug report. This should be filed on the GHC bug tracker, http://hackage.haskell.org/trac/ghc/newticket?type=bug And I've forwarded it to the glasgow-haskell-bugs mailing list. kolar: > Hello all, > > The attached file was compiled by the following command: > > ghc -O2 --make -threaded ltest1pl.hs -o alall > > When run in a sequential mode, I get this result: > ./alall > Starting ... > Lst1: 41666666650000 > Lst2: 41669166700000 > T1: 0m 1.0e-6s > 36 > End! > > > On the other hand, when run in a threaded mode, I get the following error: > ./alall +RTS -N2 > Starting ... > Lst1: 41666666650000 > Lst2: 41669166700000 > T1: 0m 0.0s > Segmentation fault > > Is it fault of the GHC runtime, or is it something on my side? > > > My machine: uname -a > Linux pc 2.6.24-ARCH #1 SMP PREEMPT Sun Mar 30 10:50:22 CEST 2008 x86_64 > Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz GenuineIntel GNU/Linux > > My ghc: ghc --version > The Glorious Glasgow Haskell Compilation System, version 6.8.2 > > > Thanks and regards > Dusan > > --import Control.Concurrent > --import Control.Concurrent.MVar > import System.Time > > import Control.Parallel.Strategies > > --import Data.List (foldl') > import qualified Data.ByteString as B > > > sumAllSums [] = 0 > sumAllSums l@(_:xs) = sumlist 0 l + sumAllSums xs > where sumlist res [] = res > sumlist sr (v:vs) = sumlist (sr+v) vs > > wlist2wbs [] = B.pack [] > wlist2wbs l@(_:_) = B.pack $ encode l > where > encode :: Integral a => [Int] -> [a] > encode [] = [] > encode (x:xs) = > if x==0 then 0:0:encode xs > else fromIntegral (x `mod` 256) : fromIntegral (x `div` 256) : encode xs > > main = do > putStrLn $ "Starting ..." > let lst1 = [0..49999] > let lst2 = [0..50000] > let bs1 = wlist2wbs lst1 > let bs2 = wlist2wbs lst2 > tm1 <- getClockTime > let (v1:v2:_) = parMap rnf sumAllSums [lst1,lst2] > tm1' <- getClockTime > putStrLn ("Lst1: " ++ show v1) > putStrLn ("Lst2: " ++ show v2) > let tdiff1 = diffClockTimes tm1' tm1 > --let tdiff2 = diffClockTimes tm2' tm2 > putStrLn $ "T1: " ++ show (tdMin tdiff1) ++ "m " ++ show (fromIntegral(tdSec tdiff1) + fromIntegral(tdPicosec tdiff1)/1e12) ++ "s" > --putStrLn $ "T2: " ++ show (tdMin tdiff2) ++ "m " ++ show (fromIntegral(tdSec tdiff2) + fromIntegral(tdPicosec tdiff2)/1e12) ++ "s" > putStrLn $ show $ {-ibs1 +-} B.index bs1 99999 + B.index bs2 49999 {-((bs1 + fromIntegral (B.index bs2 99999)) :: Integer)-} > putStrLn $ "End!" > > {- > main = do > tm1 <- getClockTime > putStrLn $ "Starting ... " > mv1 <- newEmptyMVar > mv2 <- newEmptyMVar > t1 <- forkIO (putMVar mv1 $! sumAllSums [0..49999]) > t2 <- forkIO (putMVar mv2 $! sumAllSums [1..50000]) > v1 <- takeMVar mv1 > v2 <- takeMVar mv2 > killThread t1 > killThread t2 > putStrLn $ "Result: " ++ show (v1+v2) > tm2 <- getClockTime > let tdiff = diffClockTimes tm2 tm1 > putStrLn $ "End! " ++ show (tdMin tdiff) ++ "m " ++ show (fromIntegral(tdSec tdiff) + fromIntegral(tdPicosec tdiff)/1e12) ++ "s" > -} > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From lemming at henning-thielemann.de Fri May 23 15:24:30 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri May 23 15:16:15 2008 Subject: [Haskell-cafe] Announce: ghc-core, command line pager for reading GHC Core In-Reply-To: <1832550999.20080523205602@gmail.com> References: <20080502014857.GA1722@scytale.galois.com> <404396ef0805020033q74dfbad4qfb5bf1a425c3fa03@mail.gmail.com> <1832550999.20080523205602@gmail.com> Message-ID: On Fri, 23 May 2008, Bulat Ziganshin wrote: > Hello Henning, > > Friday, May 23, 2008, 8:31:24 PM, you wrote: > >> would guarantee speed in every case. Or I can SPECIALISE the function, >> then the function will only be called, but with polymorphism overhead >> eliminated. This would only work for a restricted range of types. I'd like >> to have a pragma, that tells GHC to specialise a function for every type >> it is called with. > > me too. btw, this already present in jhc. inlining doesn't work in any > complex case since recursive functions can't be inlined GHC inlines recursive functions, too, otherwise it could not turn 'foldl' and friends into plain machine loops. From tphyahoo at gmail.com Fri May 23 15:29:44 2008 From: tphyahoo at gmail.com (Thomas Hartman) Date: Fri May 23 15:22:57 2008 Subject: [Haskell-cafe] problems with derive/TH In-Reply-To: <6a7c66fc0805230901q311b0630yaafe0b97a43f3650@mail.gmail.com> References: <910ddf450805230811v164ee48bp92544d433f086238@mail.gmail.com> <6a7c66fc0805230901q311b0630yaafe0b97a43f3650@mail.gmail.com> Message-ID: <910ddf450805231229s737ca107w473d6be2875f4b9e@mail.gmail.com> adding OPTIONS -XStandaloneDeriving made no difference The following patch fixed the problem. (Well, at least the mud program compiles. I haven't actually tried using it yet.) thartman@thartman-laptop:~/mud>darcs whatsnew { hunk ./World.hs 50 - deriving Eq + -- deriving Eq + +instance Eq (World TVar) where + World a1 a2 a3 a4 a5 a6 a7 a8 == World b1 b2 b3 b4 b5 b6 b7 b8 = + a1 == b1 && a2 == b2 && a3 == b3 && a4 == b4 && a5 == b5 && a6 == b6 && a7 == b7 && a8 == b8 hunk ./World.hs 202 + + hunk ./mud.cabal 9 - network, unix, template-haskell + network, unix, template-haskell, containers, bytestring } thartman@thartman-laptop:~/mud>darcs commit I'm posting a patch here because when I darcs pushed I got darcs: Pushing to http URLs is not supported. You may be able to hack this to work using DARCS_APPLY_HTTP still very new to darcs. is there something else I should have done? Thanks to the cafe, as always! thomas. 2008/5/23 Alfonso Acosta : > On Fri, May 23, 2008 at 5:11 PM, Thomas Hartman wrote: >> I am assuming this used to work, but something changed, either in TH >> itself or switching from ghc6.6 to ghc6.8. > > The "deriving" rules of 6.8 are more restrictive in some cases. > However, the same result can be obtained in 6.8 byt using stand-alone > deriving declarations: > > http://www.haskell.org/ghc/docs/latest/html/users_guide/deriving.html#stand-alone-deriving > > I guess this can be the problem. > From bulat.ziganshin at gmail.com Fri May 23 15:39:21 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Fri May 23 15:35:18 2008 Subject: [Haskell-cafe] problems with derive/TH In-Reply-To: <910ddf450805231229s737ca107w473d6be2875f4b9e@mail.gmail.com> References: <910ddf450805230811v164ee48bp92544d433f086238@mail.gmail.com> <6a7c66fc0805230901q311b0630yaafe0b97a43f3650@mail.gmail.com> <910ddf450805231229s737ca107w473d6be2875f4b9e@mail.gmail.com> Message-ID: <278152360.20080523233921@gmail.com> Hello Thomas, Friday, May 23, 2008, 11:29:44 PM, you wrote: > darcs: Pushing to http URLs is not supported. of course. http is read-only media :) you have to send patches via email (in most cases). read darcs docs -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From duncan.coutts at worc.ox.ac.uk Fri May 23 15:55:57 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri May 23 15:46:46 2008 Subject: [Haskell-cafe] Announce: ghc-core, command line pager for reading GHC Core In-Reply-To: References: <20080502014857.GA1722@scytale.galois.com> <404396ef0805020033q74dfbad4qfb5bf1a425c3fa03@mail.gmail.com> <1832550999.20080523205602@gmail.com> Message-ID: <1211572557.5824.542.camel@localhost> On Fri, 2008-05-23 at 21:24 +0200, Henning Thielemann wrote: > On Fri, 23 May 2008, Bulat Ziganshin wrote: > > > Hello Henning, > > > > Friday, May 23, 2008, 8:31:24 PM, you wrote: > > > >> would guarantee speed in every case. Or I can SPECIALISE the function, > >> then the function will only be called, but with polymorphism overhead > >> eliminated. This would only work for a restricted range of types. I'd like > >> to have a pragma, that tells GHC to specialise a function for every type > >> it is called with. > > > > me too. btw, this already present in jhc. inlining doesn't work in any > > complex case since recursive functions can't be inlined > > GHC inlines recursive functions, too, otherwise it could not turn 'foldl' > and friends into plain machine loops. Actually ghc's definition of foldl is not recursive, though it does of course contain a local recursion: foldl :: (a -> b -> a) -> a -> [b] -> a foldl f z xs = lgo z xs where lgo z [] = z lgo z (x:xs) = lgo (f z x) xs The lgo recursive call is then specialised at the call site and we can get good code. As I understand it, if foldl was written in the standard directly way then ghc would not inline it. So we have to manually apply the static argument transformation. You'll see that foldr is written in the same way. Duncan From jwlato at gmail.com Fri May 23 16:07:21 2008 From: jwlato at gmail.com (John Lato) Date: Fri May 23 16:00:35 2008 Subject: [Haskell-cafe] strange cabal error Message-ID: <9979e72e0805231307h5480078at64781cd5c1ee8c4@mail.gmail.com> Hello, I recently ran into a strange cabal error. When trying to configure a package (leksah 0.1.1) I get the following error: MacBook-Pro:leksah-0.1.1 jwl$ runhaskell Setup.lhs configure Configuring leksah-0.1.1... Setup.lhs: ghc version >=6.2 is required but the version of /usr/local/bin/ghc could not be determined. MacBook-Pro:leksah-0.1.1 jwl$ /usr/local/bin/ghc --version The Glorious Glasgow Haskell Compilation System, version 6.8.2 This is on Mac OS 10.5.2, with GHC 6.8.2 (installed from Manuel C.'s binary package). Thus far several other packages have built and installed just fine (bytestring, binary, parsec, gtk2hs (from source, not darwinports)). Looking through leksah.cabal and Setup.lhs, I didn't see anything unusual (although I'm far from a cabal expert). I only found one relevant result from google, a Nov. 20th message on cabal-devel about another user getting this message on Debian with ghc 6.8.1. He reported getting this message when running install from a directory without write permissions. It doesn't seem to be a permissions problem for me; I do have write permissions for the directory in which I'm running cabal and all subdirectories. Can anyone tell me what's going on, or give me any advice to try? Would a different version of cabal possibly work? Thanks, John Lato From dons at galois.com Fri May 23 16:14:30 2008 From: dons at galois.com (Don Stewart) Date: Fri May 23 16:07:52 2008 Subject: [Haskell-cafe] Announce: ghc-core, command line pager for reading GHC Core In-Reply-To: <1211572557.5824.542.camel@localhost> References: <20080502014857.GA1722@scytale.galois.com> <404396ef0805020033q74dfbad4qfb5bf1a425c3fa03@mail.gmail.com> <1832550999.20080523205602@gmail.com> <1211572557.5824.542.camel@localhost> Message-ID: <20080523201430.GF4034@scytale.galois.com> duncan.coutts: > > On Fri, 2008-05-23 at 21:24 +0200, Henning Thielemann wrote: > > On Fri, 23 May 2008, Bulat Ziganshin wrote: > > > > > Hello Henning, > > > > > > Friday, May 23, 2008, 8:31:24 PM, you wrote: > > > > > >> would guarantee speed in every case. Or I can SPECIALISE the function, > > >> then the function will only be called, but with polymorphism overhead > > >> eliminated. This would only work for a restricted range of types. I'd like > > >> to have a pragma, that tells GHC to specialise a function for every type > > >> it is called with. > > > > > > me too. btw, this already present in jhc. inlining doesn't work in any > > > complex case since recursive functions can't be inlined > > > > GHC inlines recursive functions, too, otherwise it could not turn 'foldl' > > and friends into plain machine loops. > > Actually ghc's definition of foldl is not recursive, though it does of > course contain a local recursion: > > foldl :: (a -> b -> a) -> a -> [b] -> a > foldl f z xs = lgo z xs > where > lgo z [] = z > lgo z (x:xs) = lgo (f z x) xs > > The lgo recursive call is then specialised at the call site and we can > get good code. > > As I understand it, if foldl was written in the standard directly way > then ghc would not inline it. So we have to manually apply the static > argument transformation. You'll see that foldr is written in the same > way. Similar for length et al. These worker/wrapper things inline quite happily: module B where mylength :: [a] -> Int mylength = go 0 where go :: Int -> [a] -> Int go n [] = n go n (_:xs) = go (n+1) xs {-# INLINE mylength #-} module A where import B main = print (mylength (enumFromTo 1 (10::Int))) ------------------------------------------------------------------------ And it is all inlined into A.hs: A.lvl2 = case A.go1 @ Int A.lvl A.lvl1 of w_axy { I# ww_axA -> $wshowSignedInt 0 ww_axA ([] @ Char) } A.go1 :: forall a1_a5n. Int -> [a1_a5n] -> Int A.go1 = \ (@ a1_a7b) (n_a5p :: Int) (ds_d9N :: [a1_a7b]) -> case ds_d9N of wild_B1 { [] -> n_a5p; : ds1_d9O xs_a5s -> A.go1 @ a1_a7b (case n_a5p of wild1_aqC { I# x_aqE -> I# (+# x_aqE 1) }) xs_a5s -- Don From blit32 at gmail.com Fri May 23 16:25:36 2008 From: blit32 at gmail.com (Nabil Alsharif) Date: Fri May 23 16:19:05 2008 Subject: [Haskell-cafe] gtk2hs linking problems Message-ID: <1211574336.6714.11.camel@Fozi> I downloaded the gtk2hs 0.9.12.1 tarball and did the standard configure, make, make install but when I go to compile a test program I get a bunch of errors that look like: compilation IS NOT required [..snip..] (.data+0x38): undefined reference to `gtkzm0zi9zi12zi1_GraphicsziUIziGtkziTypes_zdf548_closure' gui.o: In function `r2JC_srt': (.data+0x60): undefined reference to `gtkzm0zi9zi12zi1_GraphicsziUIziGtkziButtonsziButton_onClicked_closure' gui.o: In function `r2JC_srt': (.data+0x68): undefined reference to `gtkzm0zi9zi12zi1_GraphicsziUIziGtkziTypes_zdf662_closure' gui.o: In function `r2JE_srt': (.data+0x90): undefined reference to `gtkzm0zi9zi12zi1_GraphicsziUIziGtkziButtonsziButton_buttonLabel_closure' gui.o: In function `r2JE_srt': (.data+0x98): undefined reference to `gtkzm0zi9zi12zi1_GraphicsziUIziGtkziTypes_zdf662_closure' gui.o: In function `r2JG_srt': (.data+0xc0): undefined reference to `gtkzm0zi9zi12zi1_GraphicsziUIziGtkziAbstractziContainer_containerChild_closure' gui.o: In function `r2JG_srt': (.data+0xc8): undefined reference to `gtkzm0zi9zi12zi1_GraphicsziUIziGtkziTypes_zdf662_closure' gui.o: In function `r2JG_srt': (.data+0xd0): undefined reference to `gtkzm0zi9zi12zi1_GraphicsziUIziGtkziTypes_zdf548_closure' gui.o: In function `r2JG_closure': (.data+0x108): undefined reference to `glibzm0zi9zi12zi1_SystemziGlibziAttributes_set_closure' gui.o: In function `r2JG_closure': (.data+0x110): undefined reference to `gtkzm0zi9zi12zi1_GraphicsziUIziGtkziGeneralziGenera This was done on a Ubuntu system. It looks like it can't find a reference to a library but it doesn't say which one. If any one has ran into this problem before or knows what wrong help would be appreciated. From lemming at henning-thielemann.de Fri May 23 16:28:31 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri May 23 16:20:14 2008 Subject: [Haskell-cafe] force inlining in GHC (fwd) Message-ID: maybe also of interest in the ghc-core thread ---------- Forwarded message ---------- Date: Fri, 23 May 2008 21:21:03 +0200 (CEST) From: Henning Thielemann To: Simon Peyton-Jones Cc: glasgow-haskell-users@haskell.org Subject: RE: [Haskell-cafe] force inlining in GHC On Wed, 30 Apr 2008, Henning Thielemann wrote: > On Tue, 29 Apr 2008, Simon Peyton-Jones wrote: > > > As luck would have it, I'm working on INLINE pragmas for Roman right at > this moment. > > > > Could you spare a moment to give me a concrete test case, to make sure I > > hit your case too? If you can give me a program that doesn't optimise as > > you expect, I'm much more likely to get it right. I examined some more examples and found out that the behaviours of GHC-6.4.1 and GHC-6.8.2 are quite consistent, that is, accelerations I achieved for GHC-6.8.2 also worked for GHC-6.4.1. Main problem in both GHC-6.4.1 and GHC-6.8.2 remains that sometimes GHC decides to SPECIALISE a function that is tagged with INLINE. I think that SPECIALISE should either copy the INLINE tag to the specialised function (confluent rewriting, right?) or should not SPECIALISE an INLINE function at all. I can now present a simple example, however it needs a (self-contained) package: http://darcs.haskell.org/storablevector/ module Main where import qualified Data.StorableVector.Lazy as SV zipData :: SV.Vector Double zipData = SV.take 500000 $ SV.zipWith (+) (SV.iterate SV.defaultChunkSize ((1-1e-6)*) 0.5) (SV.iterate SV.defaultChunkSize (1e-6 +) 0) main :: IO () main = do SV.writeFile "test-data" zipData ghc-core -o dist/build/fusiontest/fusiontest -O -Wall -fexcess-precision -package storablevector speedtest/SpecialiseTest.hs I get quite at the beginning of the Core: a1 :: Data.StorableVector.Lazy.ChunkSize -> (Double -> Data.Maybe.Maybe (Double, Double)) -> Double -> [Data.StorableVector.Base.Vector Double] This looks much like specialised SV.unfoldr, the expansion of SV.iterate. It seems to be that GHC detects that SV.unfoldr is called twice with the same type and thus specialises it to Double - while forgetting that SV.unfoldr should be inlined anyway. From olivier.boudry at gmail.com Fri May 23 16:34:47 2008 From: olivier.boudry at gmail.com (Olivier Boudry) Date: Fri May 23 16:28:00 2008 Subject: [Haskell-cafe] Newbie: State monad example questions In-Reply-To: <910ddf450805231120h68bc798cl40e6ce9c5d96314c@mail.gmail.com> References: <53396d9e0805191404va8cb2d7yeb36954b83ac5ca8@mail.gmail.com> <53396d9e0805210542n667d6596uca6b8caf89e30219@mail.gmail.com> <53396d9e0805210810m6f48596jde8e98f7394403c6@mail.gmail.com> <53396d9e0805211519x71d77df9gb39d7c59203d57ac@mail.gmail.com> <910ddf450805231120h68bc798cl40e6ce9c5d96314c@mail.gmail.com> Message-ID: On Fri, May 23, 2008 at 2:20 PM, Thomas Hartman wrote: > > The big benefit I got from using the State Monad was that I was able to > reorder the functions > by just copy/pasting the function name from one > place to another. > > I don't understand... why do you need state to do this? Couldn't you > have a function pipeline using dots for composition like > > .... ( > ... > parseAttn . > parsePoBox . > ... > ) address ... > > and have the functions be equally switchable? (well, the first and > last can't quite be copy pasted, but close enough.) > > Introducing state seems like a lot of trouble to me if the only one is > easier reorderability of lines. > Agreed, in fact I started with a function pipeline and then switched to using the State Monad. As the program was written months ago I don't remember exactly why. Maybe I don't like to read backwards. ;-) Funtions running in the state monad can call other functions with the same `State s a` signature (and so on as deep as you want). You never have to care about passing parameters and restarting a new pipeline. But of course you can easily do without the State Monad. I don't think the State Monad allows to do thing that you can't do with basic Haskell. It just makes code more readable (in my opinion at least). Olivier. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080523/0c93fc09/attachment.htm From lemming at henning-thielemann.de Fri May 23 17:10:58 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri May 23 17:02:43 2008 Subject: [Haskell-cafe] Announce: ghc-core, command line pager for reading GHC Core In-Reply-To: <87d4ncvkl0.fsf@nmd9999.imr.no> References: <20080502014857.GA1722@scytale.galois.com> <404396ef0805020033q74dfbad4qfb5bf1a425c3fa03@mail.gmail.com> <87d4ncvkl0.fsf@nmd9999.imr.no> Message-ID: On Fri, 23 May 2008, Ketil Malde wrote: > Henning Thielemann writes: > >>> An even more advanced tool could show differences between two Core >>> listings [..] >> In this special example, actually simple 'diff' spotted the critical >> difference > > I would suggest Emacs's ediff for this, it lets you refine differing > chunks and highlights the actual differences. If you are an Emacs > user, if not, there are probably other nice diff tools out there.. :-) tkdiff, kompare From bertram.felgenhauer at googlemail.com Fri May 23 20:45:16 2008 From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer) Date: Fri May 23 20:38:36 2008 Subject: [Haskell-cafe] gtk2hs linking problems In-Reply-To: <1211574336.6714.11.camel@Fozi> References: <1211574336.6714.11.camel@Fozi> Message-ID: <20080524004516.GA4211@zombie.inf.tu-dresden.de> Nabil Alsharif wrote: > I downloaded the gtk2hs 0.9.12.1 tarball and did the standard configure, > make, make install but when I go to compile a test program I get a bunch > of errors that look like: How did you compile the program? [snip link errors] This usually indicates a missing --make or -package flag (in your case, -package gtk) in the ghc invocation. Try ghc --make Test.hs HTH, Bertram From olivier.boudry at gmail.com Fri May 23 21:37:32 2008 From: olivier.boudry at gmail.com (Olivier Boudry) Date: Fri May 23 21:30:44 2008 Subject: [Haskell-cafe] Newbie: State monad example questions In-Reply-To: <910ddf450805231417p21b2b86duc23dc54d8605dfc5@mail.gmail.com> References: <53396d9e0805191404va8cb2d7yeb36954b83ac5ca8@mail.gmail.com> <53396d9e0805210542n667d6596uca6b8caf89e30219@mail.gmail.com> <53396d9e0805210810m6f48596jde8e98f7394403c6@mail.gmail.com> <53396d9e0805211519x71d77df9gb39d7c59203d57ac@mail.gmail.com> <910ddf450805231120h68bc798cl40e6ce9c5d96314c@mail.gmail.com> <910ddf450805231417p21b2b86duc23dc54d8605dfc5@mail.gmail.com> Message-ID: On Fri, May 23, 2008 at 5:17 PM, Thomas Hartman wrote: > > Maybe I don't like to read backwards. ;-) > > >>> (from Control.arrow) is like flip (.) > > That's something I considered. I like the `|>` operator found in F# (I hope it's not a curse word on this list) which is equivalent to `flip (.)`. It's easy to define in Haskell (|>) :: (a -> b) -> (b -> c) -> a -> c (|>) = flip (.) I even started to use it in my code and then stopped. It may be a stupid concern but as many optimizations performed by GHC are made through rewrite rules and I was worried that those rules may not fire when using this new operator. I never thought of using `>>>` for this, but again I wonder how it will work with rewrite rules. Olivier. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080523/1a20af91/attachment.htm From ajb at spamcop.net Fri May 23 21:41:11 2008 From: ajb at spamcop.net (ajb@spamcop.net) Date: Fri May 23 21:34:23 2008 Subject: [Haskell-cafe] Data.Tree.Zipper in the standard libraries In-Reply-To: <20080523174504.GB4034@scytale.galois.com> References: <20080523072806.GA2713@soi.city.ac.uk> <20080523174504.GB4034@scytale.galois.com> Message-ID: <20080523214111.pa7u73403wo8ksgw-nwo@fcnzpbc.arg@webmail.spamcop.net> G'day all. Quoting Don Stewart : > This is Haskell, we should use Maybe. This is Haskell, more abstract is good. I do agree, though, that Monad is arguably the wrong abstraction. Something like this would arguably be better: class (Functor f) => Fail f where return :: a -> f a fail :: String -> f a (And yes, the String is arguably important; Maybe doesn't give you that.) Cheers, Andrew Bromage From kr.angelov at gmail.com Sat May 24 02:50:18 2008 From: kr.angelov at gmail.com (Krasimir Angelov) Date: Sat May 24 02:43:30 2008 Subject: [Haskell-cafe] Data.Tree.Zipper in the standard libraries In-Reply-To: <8339047720729393098@unknownmsgid> References: <20080523072806.GA2713@soi.city.ac.uk> <20080523174504.GB4034@scytale.galois.com> <8339047720729393098@unknownmsgid> Message-ID: An updated Zipper version is uploaded here: http://www.haskell.org/haskellwiki/User_talk:Kr.angelov It doesn't use State monad anymore and it returns Maybe. This seems to be the common preference, is it? Feel free to vote against. Should we change Data.Map also? There is another proposal for changes in findMin/findMax so it is better to make this two breaking changes together rather than in a later release. It also allows to pass whole new subtree in insert{Left/Right/Down}. On Sat, May 24, 2008 at 3:41 AM, wrote: > G'day all. > > Quoting Don Stewart : > >> This is Haskell, we should use Maybe. > > This is Haskell, more abstract is good. > > I do agree, though, that Monad is arguably the wrong abstraction. Something > like this would arguably be better: > > class (Functor f) => Fail f where > return :: a -> f a > fail :: String -> f a > > (And yes, the String is arguably important; Maybe doesn't give you that.) > > Cheers, > Andrew Bromage > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From bulat.ziganshin at gmail.com Sat May 24 03:39:29 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sat May 24 03:45:17 2008 Subject: [Haskell-cafe] Newbie: State monad example questions In-Reply-To: References: <53396d9e0805191404va8cb2d7yeb36954b83ac5ca8@mail.gmail.com> <53396d9e0805210542n667d6596uca6b8caf89e30219@mail.gmail.com> <53396d9e0805210810m6f48596jde8e98f7394403c6@mail.gmail.com> <53396d9e0805211519x71d77df9gb39d7c59203d57ac@mail.gmail.com> <910ddf450805231120h68bc798cl40e6ce9c5d96314c@mail.gmail.com> <910ddf450805231417p21b2b86duc23dc54d8605dfc5@mail.gmail.com> Message-ID: <1419227352.20080524113929@gmail.com> Hello Olivier, Saturday, May 24, 2008, 5:37:32 AM, you wrote: (|>>) = flip (.) > I even started to use it in my code and then stopped. It may be a > stupid concern but as many optimizations performed by GHC are made > through rewrite rules and I was worried that those rules may not > fire when using this new operator. afaik ghc, |> would be rewritten to flip (.) which would be rewritten to application of first function to second one and so on. rewrite rules doesn't work only on your original code but on intermediate variations too -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From ndmitchell at gmail.com Sat May 24 04:24:57 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Sat May 24 04:18:10 2008 Subject: [Haskell-cafe] Data.Tree.Zipper in the standard libraries In-Reply-To: References: <20080523072806.GA2713@soi.city.ac.uk> <20080523174504.GB4034@scytale.galois.com> <8339047720729393098@unknownmsgid> Message-ID: <404396ef0805240124p2ac50bdfq6f79d3c5f7306efb@mail.gmail.com> Hi, > It doesn't use State monad anymore and it returns Maybe. This seems to > be the common preference, is it? Feel free to vote against. Should we > change Data.Map also? There is another proposal for changes in > findMin/findMax so it is better to make this two breaking changes > together rather than in a later release. The standard libraries proposal thingy is to go via the libraries list, create tickets etc. What reason is there to make this part of the base libraries, rather than a separate package on hackage? I can't see much reason to make Data.Tree part of the base libraries, other than the fact it already is, and it could easily get moved out at a future date. We've seen there is some advantage in leaving the implementation outside the base library, as its already changed several times in the past few days. Thnanks Neil From peteg42 at gmail.com Sat May 24 05:33:08 2008 From: peteg42 at gmail.com (Peter Gammie) Date: Sat May 24 05:26:33 2008 Subject: [Haskell-cafe] library for drawing charts Message-ID: <82B3919B-BE28-4D65-9A3B-957B5EC51D27@gmail.com> Hello, Has anyone got some code for drawing charts? I don't mean graphs of functions, ala http://dockerz.net/twd/HaskellCharts and I don't mean calls to the Google Charts API ala http://community.livejournal.com/evan_tech/241080.html I would like something that can generate PNGs in memory, i.e. not directly to a file. This is close to what I have in mind: http://www.fred.net/brv/chart/ I'd like 2D pie charts, bar charts and something like a google-o-meter. Any pointers? cheers peter From duncan.coutts at worc.ox.ac.uk Sat May 24 05:36:15 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat May 24 05:26:53 2008 Subject: [Haskell-cafe] strange cabal error In-Reply-To: <9979e72e0805231307h5480078at64781cd5c1ee8c4@mail.gmail.com> References: <9979e72e0805231307h5480078at64781cd5c1ee8c4@mail.gmail.com> Message-ID: <1211621775.5824.562.camel@localhost> On Fri, 2008-05-23 at 15:07 -0500, John Lato wrote: > Hello, > > I recently ran into a strange cabal error. When trying to configure a > package (leksah 0.1.1) I get the following error: > > MacBook-Pro:leksah-0.1.1 jwl$ runhaskell Setup.lhs configure > Configuring leksah-0.1.1... > Setup.lhs: ghc version >=6.2 is required but the version of > /usr/local/bin/ghc could not be determined. > > MacBook-Pro:leksah-0.1.1 jwl$ /usr/local/bin/ghc --version > The Glorious Glasgow Haskell Compilation System, version 6.8.2 Run the configure step again with -v3, we should be able to see in the log exactly what string we got back from ghc. Also, to make sure you're using the version of the Cabal library you expect, try: ghc --make Setup.hs -package Cabal-1.2.3.0 ./Setup configure That way we know what we're using, even if you happen to have multiple versions of Cabal installed or if runhaskell happens to point at hugs rather than ghc. Duncan From olivier.boudry at gmail.com Sat May 24 07:39:37 2008 From: olivier.boudry at gmail.com (Olivier Boudry) Date: Sat May 24 07:32:49 2008 Subject: [Haskell-cafe] Newbie: State monad example questions In-Reply-To: <1419227352.20080524113929@gmail.com> References: <53396d9e0805191404va8cb2d7yeb36954b83ac5ca8@mail.gmail.com> <53396d9e0805210810m6f48596jde8e98f7394403c6@mail.gmail.com> <53396d9e0805211519x71d77df9gb39d7c59203d57ac@mail.gmail.com> <910ddf450805231120h68bc798cl40e6ce9c5d96314c@mail.gmail.com> <910ddf450805231417p21b2b86duc23dc54d8605dfc5@mail.gmail.com> <1419227352.20080524113929@gmail.com> Message-ID: On Sat, May 24, 2008 at 3:39 AM, Bulat Ziganshin wrote: > Hello Olivier, > > Saturday, May 24, 2008, 5:37:32 AM, you wrote: > > (|>>) = flip (.) > > > I even started to use it in my code and then stopped. It may be a > > stupid concern but as many optimizations performed by GHC are made > > through rewrite rules and I was worried that those rules may not > > fire when using this new operator. > > afaik ghc, |> would be rewritten to flip (.) which would be rewritten > to application of first function to second one and so on. rewrite > rules doesn't work only on your original code but on intermediate > variations too > > That's really good news. Thanks Bulat, Olivier. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080524/4b956e0f/attachment.htm From olivier.boudry at gmail.com Sat May 24 10:27:15 2008 From: olivier.boudry at gmail.com (Olivier Boudry) Date: Sat May 24 10:20:27 2008 Subject: [Haskell-cafe] library for drawing charts In-Reply-To: <82B3919B-BE28-4D65-9A3B-957B5EC51D27@gmail.com> References: <82B3919B-BE28-4D65-9A3B-957B5EC51D27@gmail.com> Message-ID: On Sat, May 24, 2008 at 5:33 AM, Peter Gammie wrote: > Hello, > > Has anyone got some code for drawing charts? > Look at this: http://byorgey.wordpress.com/2008/04/30/new-haskell-diagrams-library/ I'm not sure it's what you're looking for but it could probably be used as a base for drawing charts. Brent Yorgey announced version 0.1 on the list a few weeks ago. Regards, Olivier. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080524/a6c4e1f9/attachment.htm From jwlato at gmail.com Sat May 24 12:10:35 2008 From: jwlato at gmail.com (John Lato) Date: Sat May 24 12:03:45 2008 Subject: [Haskell-cafe] strange cabal error In-Reply-To: <1211621775.5824.562.camel@localhost> References: <9979e72e0805231307h5480078at64781cd5c1ee8c4@mail.gmail.com> <1211621775.5824.562.camel@localhost> Message-ID: <9979e72e0805240910v55e9ee4bv1802dbb14c706063@mail.gmail.com> On Sat, May 24, 2008 at 4:36 AM, Duncan Coutts wrote: > > Run the configure step again with -v3, we should be able to see in the > log exactly what string we got back from ghc. > > Also, to make sure you're using the version of the Cabal library you > expect, try: > > ghc --make Setup.hs -package Cabal-1.2.3.0 > ./Setup configure > > That way we know what we're using, even if you happen to have multiple > versions of Cabal installed or if runhaskell happens to point at hugs > rather than ghc. > > Duncan > > Duncan, thanks for replying. Trying to use ghc --make Setup.hs failed with a bunch of linker errors, (although ghc-pkg reported that only Cabal-1.2.3.0 was installed), so somehow my Cabal libs must have gotten messed up. Anyway, rebuilding and reinstalling ghc fixed it. I don't know why cabal didn't fail on the other packages, maybe I forgot to clean them before I re-ran configure. I also don't know how the library got messed up; maybe I modified some other package that cabal depends on. Thanks, John From trebla at vex.net Sat May 24 17:59:41 2008 From: trebla at vex.net (Albert Y. C. Lai) Date: Sat May 24 17:52:53 2008 Subject: [Haskell-cafe] newbie: maintaining relationships In-Reply-To: <1211566023.5530.5.camel@geoffrey> References: <1211566023.5530.5.camel@geoffrey> Message-ID: <48388FCD.2040904@vex.net> geoffrey wrote: > Give the following code below, my question is - how do i setup a > dependency of User on Common? Perhaps a first attempt should not have Common store a reference to User, nor User store a reference to Common. Instead, have two Data.Map.Map's: one looks up from Common to User, one from User to Common. This is not the fastest possible, but it is the most programmable possible. For example, introducing mutation is trivial. For example, changing to many-to-many is easy (just re-code to look up from Common to Data.Set.Set User, and from User to Data.Set.Set Common). This is equivalent to the association pattern from OOP: Do not record X-Y relationship inside X or Y; instead create an external association object to store that relationship. The two Data.Map.Map's (and Data.Set.Set's if you use them) are the external association object. This is also equivalent to normalization in database theory. (E.g., think what you would do in entity-relation diagrams.) (Aside: Some people with imperative or OOP or DB training feel that FP is strange, e.g., laziness seem unpredictable to an imperative person, FP program/data structuring feel strange under OOP or DB... But that is only because they are just average in their imperative, OOP, or DB training. For an imperative expert will see how laziness is carried out, in great detail, and therefore totally predictable; and the truest OOP or DB devotee will apply the most appropriate design patterns, as exemplified above, and therefore arrive at the most FP structure as well. This is no coincidence, for all programming paradigms are supposed to converge in the limit.) After you have decided how much mutation and what multiplicity you want, you can then consider eliminating the Data.Map.Map's for speed. From ndmitchell at gmail.com Sat May 24 18:04:27 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Sat May 24 17:57:37 2008 Subject: [Haskell-cafe] newbie: maintaining relationships In-Reply-To: <48388FCD.2040904@vex.net> References: <1211566023.5530.5.camel@geoffrey> <48388FCD.2040904@vex.net> Message-ID: <404396ef0805241504u1579e825tf3a7f73febff6b4@mail.gmail.com> Hi >> Give the following code below, my question is - how do i setup a >> dependency of User on Common? > > Perhaps a first attempt should not have Common store a reference to User, > nor User store a reference to Common. Instead, have two Data.Map.Map's: one > looks up from Common to User, one from User to Common. Sounds like a bidirectional Map to me - fortunately hackage already has one of these: http://hackage.haskell.org/cgi-bin/hackage-scripts/