From mhasan at cs.cornell.edu Sat Mar 1 01:50:55 2008 From: mhasan at cs.cornell.edu (Milos Hasan) Date: Sat Mar 1 01:48:36 2008 Subject: [Haskell-cafe] Generating a random list Message-ID: <47C8FCCF.1050209@cs.cornell.edu> Hi, so let's say I want to generate a list of N random floats. The elegant way of doing it would be to create an infinite lazy list of floats and take the first N, but for N = 1,000,000 or more, this overflows the stack. The reason is apparently that the take function is not tail-recursive, and so it uses O(N) stack space.. What is the right way to do this? Sure, I could write my own tail-recursive generator function. But this seems to be an instance of a more general problem - how to avoid algorithms linear in stack space when dealing with large lists. Thanks a lot! Milos From lrpalmer at gmail.com Sat Mar 1 02:18:57 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Sat Mar 1 02:16:38 2008 Subject: [Haskell-cafe] Generating a random list In-Reply-To: <47C8FCCF.1050209@cs.cornell.edu> References: <47C8FCCF.1050209@cs.cornell.edu> Message-ID: <7ca3f0160802292318j4c978820j824329ce67e013d9@mail.gmail.com> On Sat, Mar 1, 2008 at 6:50 AM, Milos Hasan wrote: > Hi, > > so let's say I want to generate a list of N random floats. The elegant > way of doing it would be to create an infinite lazy list of floats and > take the first N, but for N = 1,000,000 or more, this overflows the > stack. The reason is apparently that the take function is not > tail-recursive, and so it uses O(N) stack space.. Not too likely. take should not be tail recursive, because that is not lazy (you have to compute all n elements to get the first one) and thus uses O(n) space, whereas the take in the Prelude is lazy, so uses O(1) space. The prelude take is the one you want. It's likely that the stack overflow is occurring elsewhere in your program. For example, if you are adding together all the random numbers using foldl or foldr, that will eat up your stack (the right solution in that case is to use the strict foldl'). Perhaps you could post your code, or a minimal example of what you're experiencing. Luke > What is the right way to do this? Sure, I could write my own > tail-recursive generator function. But this seems to be an instance of a > more general problem - how to avoid algorithms linear in stack space > when dealing with large lists. > > Thanks a lot! > Milos > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From bos at serpentine.com Sat Mar 1 02:21:10 2008 From: bos at serpentine.com (Bryan O'Sullivan) Date: Sat Mar 1 02:18:55 2008 Subject: [Haskell-cafe] Generating a random list In-Reply-To: <47C8FCCF.1050209@cs.cornell.edu> References: <47C8FCCF.1050209@cs.cornell.edu> Message-ID: <47C903E6.7090204@serpentine.com> Milos Hasan wrote: > so let's say I want to generate a list of N random floats. The elegant > way of doing it would be to create an infinite lazy list of floats and > take the first N, but for N = 1,000,000 or more, this overflows the > stack. The reason is apparently that the take function is not > tail-recursive, and so it uses O(N) stack space.. You might want to post your code. The reason take isn't tail recursive is that it will be evaluated lazily, so it will not consume O(n) stack space. However, using take is the wrong approach anyway, as the user of the random numbers needs to return the unconsumed portion of the list so that the next user can consume them. This is why code that uses random numbers is usually written in the context of a state monad, such as MonadRandom: http://www.haskell.org/haskellwiki/New_monads/MonadRandom References: <47C8FCCF.1050209@cs.cornell.edu> <7ca3f0160802292318j4c978820j824329ce67e013d9@mail.gmail.com> Message-ID: <47C9116F.8060707@cs.cornell.edu> Hi, thanks for the reply.. >> Hi, >> >> so let's say I want to generate a list of N random floats. The elegant >> way of doing it would be to create an infinite lazy list of floats and >> take the first N, but for N = 1,000,000 or more, this overflows the >> stack. The reason is apparently that the take function is not >> tail-recursive, and so it uses O(N) stack space.. >> > > Not too likely. take should not be tail recursive, because that is > not lazy (you have to compute all n elements to get the first one) and > thus uses O(n) space, whereas the take in the Prelude is lazy, so uses > O(1) space. The prelude take is the one you want. > > It's likely that the stack overflow is occurring elsewhere in your > program. For example, if you are adding together all the random > numbers using foldl or foldr, that will eat up your stack (the right > solution in that case is to use the strict foldl'). Perhaps you could > post your code, or a minimal example of what you're experiencing Summing the list works fine, it uses both O(1) stack space and O(1) heap space (so the laziness of foldl is not the problem here). The problem is that I'm not just trying to sum the list, nor any similar producer-consumer scenario that could be done in O(1) heap space. What I was really trying to do is create a nearest-neighbor search tree with a large number of random points. So I really need the list to physically materialize in memory, and I don't mind it taking O(N) heap space. The problem I was trying to avoid was using O(N) *stack* space in the process of creating the list. Here's a minimal summing example that illustrates the difference. The following works fine, since the elements are generated lazily and summed on the fly, as expected: randFloats :: [Float] randFloats = randoms (mkStdGen 0) main = do let xs = take 1000000 randFloats print $ sum xs But this overflows, because the list is created before being summed, and the take function goes into awfully deep recursion: randFloats :: [Float] randFloats = randoms (mkStdGen 0) main = do xs <- return $ take 1000000 randFloats print $ sum xs Is there a clean way to avoid this problem? Thanks, Milos From mhasan at cs.cornell.edu Sat Mar 1 03:31:51 2008 From: mhasan at cs.cornell.edu (Milos Hasan) Date: Sat Mar 1 03:29:33 2008 Subject: [Haskell-cafe] Generating a random list In-Reply-To: <47C903E6.7090204@serpentine.com> References: <47C8FCCF.1050209@cs.cornell.edu> <47C903E6.7090204@serpentine.com> Message-ID: <47C91477.8080708@cs.cornell.edu> Bryan O'Sullivan wrote: > Milos Hasan wrote: > > >> so let's say I want to generate a list of N random floats. The elegant >> way of doing it would be to create an infinite lazy list of floats and >> take the first N, but for N = 1,000,000 or more, this overflows the >> stack. The reason is apparently that the take function is not >> tail-recursive, and so it uses O(N) stack space.. >> > > You might want to post your code. The reason take isn't tail recursive > is that it will be evaluated lazily, so it will not consume O(n) stack > space. > > Yup, see the code I sent to Luke Palmer. The problem is that I really need the whole list to do further processing on it, instead of just consuming the elements one-by-one as they are produced by the random generator. I'm trying to build a search tree, but for simplicity you might assume that I just need to sort the list (or any other operation that is not a simple fold). > However, using take is the wrong approach anyway, as the user of the > random numbers needs to return the unconsumed portion of the list so > that the next user can consume them. This is why code that uses random > numbers is usually written in the context of a state monad, such as > MonadRandom: http://www.haskell.org/haskellwiki/New_monads/MonadRandom > That sounds interesting, but I'm not sure it's the randomness that's the problem here. I could as well have a completely deterministic function f :: Int -> Float, and I could try to produce the list "map f [1..1000000]", hitting the same issue. Cheers, Milos From mhasan at cs.cornell.edu Sat Mar 1 04:04:05 2008 From: mhasan at cs.cornell.edu (Milos Hasan) Date: Sat Mar 1 04:01:47 2008 Subject: [Haskell-cafe] Generating a random list In-Reply-To: <47C903E6.7090204@serpentine.com> References: <47C8FCCF.1050209@cs.cornell.edu> <47C903E6.7090204@serpentine.com> Message-ID: <47C91C05.90608@cs.cornell.edu> So, I did one more experiment, and the following overflows too: import System.Random import Data.List randFloats :: [Float] randFloats = randoms (mkStdGen 0) main = print $ sum $ sort $ take 1000000 randFloats Could it be that Data.List.sort is the culprit that uses O(n) stack space here? If so, is this avoidable? Thanks a lot, Milos From kalman.noel at bluebottle.com Sat Mar 1 05:52:46 2008 From: kalman.noel at bluebottle.com (Kalman Noel) Date: Sat Mar 1 05:50:06 2008 Subject: [Haskell-cafe] Generating a random list In-Reply-To: <47C9116F.8060707@cs.cornell.edu> References: <47C8FCCF.1050209@cs.cornell.edu> <7ca3f0160802292318j4c978820j824329ce67e013d9@mail.gmail.com> <47C9116F.8060707@cs.cornell.edu> Message-ID: <200803011052.m21AqOxt030491@mi0.bluebottle.com> Milos Hasan wrote: > Here's a minimal summing example that illustrates the difference. The > following works fine, since the elements are generated lazily and summed > on the fly, as expected: > > randFloats :: [Float] > randFloats = randoms (mkStdGen 0) > > main = do > let xs = take 1000000 randFloats > print $ sum xs > > But this overflows, because the list is created before being summed, and > the take function goes into awfully deep recursion: > > randFloats :: [Float] > randFloats = randoms (mkStdGen 0) > > main = do > xs <- return $ take 1000000 randFloats > print $ sum xs > > Is there a clean way to avoid this problem? There is, and it has already been mentioned: It's the behaviour of Prelude.sum that is bugging you. ?sum? will build an expression like this, which is responsible for the stack overflow: ((((...(n1 + n2) + n3) + n4) + ...) + nm) ^ evaluation will start here ^ But this is the first addition to be performed Instead, just use sum', which is defined just like sum, but with a strict left fold instead of a lazy left fold: import Data.List sum' :: (Num a) => [a] -> a sum' = foldl' (+) 0 I don't know exactly why there is a difference between both programs. I suppose that in the first one, the strictness analyzer can optimize sum into sum', but in the second one it cannot. Kalman ---------------------------------------------------------------------- Get a free email address with REAL anti-spam protection. http://www.bluebottle.com/tag/1 From lrpalmer at gmail.com Sat Mar 1 11:15:03 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Sat Mar 1 11:12:43 2008 Subject: [Haskell-cafe] Generating a random list In-Reply-To: <47C9116F.8060707@cs.cornell.edu> References: <47C8FCCF.1050209@cs.cornell.edu> <7ca3f0160802292318j4c978820j824329ce67e013d9@mail.gmail.com> <47C9116F.8060707@cs.cornell.edu> Message-ID: <7ca3f0160803010815u12187549xf712bcaea6b0d02d@mail.gmail.com> On Sat, Mar 1, 2008 at 8:18 AM, Milos Hasan wrote: > Here's a minimal summing example that illustrates the difference. The > following works fine, since the elements are generated lazily and summed > on the fly, as expected: > > randFloats :: [Float] > randFloats = randoms (mkStdGen 0) > > main = do > let xs = take 1000000 randFloats > print $ sum xs > > But this overflows, because the list is created before being summed, and > the take function goes into awfully deep recursion: > > randFloats :: [Float] > randFloats = randoms (mkStdGen 0) > > main = do > xs <- return $ take 1000000 randFloats > print $ sum xs It is definitely the strictness analyzer biting you here. In ghci, the behavior of these two programs is identical (stack overflow). As kalman said, if you replate sum with foldl' (+) 0 in each of these programs, the behavior is still identical (correct). As a side note, one of the monad laws is this: return x >>= f = f x So your two programs are semantically equivalent (there's nothing about IO that forces the evaluation of the list). If you're building some sort of tree out of these values, you're going to want to make sure that whatever fold you do (be it using foldl' or recursion) is strict, so that you don't get a huge thunk that doesn't have any information. Luke From apfelmus at quantentunnel.de Sat Mar 1 11:45:43 2008 From: apfelmus at quantentunnel.de (apfelmus) Date: Sat Mar 1 11:43:29 2008 Subject: [Haskell-cafe] Re: Generating a random list In-Reply-To: <47C91C05.90608@cs.cornell.edu> References: <47C8FCCF.1050209@cs.cornell.edu> <47C903E6.7090204@serpentine.com> <47C91C05.90608@cs.cornell.edu> Message-ID: Milos Hasan wrote: > import System.Random > import Data.List > > randFloats :: [Float] > randFloats = randoms (mkStdGen 0) > > main = print $ sum $ sort $ take 1000000 randFloats > > Could it be that Data.List.sort is the culprit that uses O(n) stack > space here? If so, is this avoidable? sum is not tail-recursive. Sometimes, GHCs strictness analyzer is able to optimize that away. Regards, apfelmus From martine at danga.com Sat Mar 1 13:39:37 2008 From: martine at danga.com (Evan Martin) Date: Sat Mar 1 13:37:19 2008 Subject: [Haskell-cafe] runInteractiveCommand dying uncatchably? Message-ID: <3a6f89fc0803011039s239c1426y770d1a947fc4e991@mail.gmail.com> If I run the following program, it never prints "done". If I uncomment the commented line, it does. import Prelude hiding (catch) import Control.Exception import System.Process import System.IO demo = do putStrLn "starting" (inp,out,err,pid) <- runInteractiveCommand "nonesuchcommand" putStrLn "writing to in on bad command" hPutStr inp "whatever" -- putStr "flushing" hFlush inp `catch` \e -> do print e; return () putStrLn "done" main = demo `catch` \e -> do print e; return () On my machine the output is: $ runhaskell test.hs starting writing to in on bad command $ It appears to exit at the hFlush call. (hClose has the same behavior.) I find this surprising -- I'd expect, even if I'm using an API incorrectly, to get an exception. From trebla at vex.net Sat Mar 1 16:43:38 2008 From: trebla at vex.net (Albert Y. C. Lai) Date: Sat Mar 1 16:41:21 2008 Subject: [Haskell-cafe] Generating a random list In-Reply-To: <47C91C05.90608@cs.cornell.edu> References: <47C8FCCF.1050209@cs.cornell.edu> <47C903E6.7090204@serpentine.com> <47C91C05.90608@cs.cornell.edu> Message-ID: <47C9CE0A.4010600@vex.net> The following is in ghci 6.8.2 with default options (e.g., default heap and stack). "G>" denotes the ghci prompt. At some points ghci will use 500MB of memory. Be sure you have enough physical memory. G> :m + Data.List System.Random G> let f n = take n randoms (mkStdGen 0)) :: [Float] I define f to take a parameter so that thunks are created fresh every time I use it. G> sum (f 1000000) *** Exception: stack overflow This overflow is known, and its solution too: G> foldl' (+) 0 (f 1000000) 499985.38 The more interesting part is when we also sort: G> foldl' (+) 0 (sort (f 1000000)) *** Exception: stack overflow At this point everyone hastens to assign blames according to his/her mental model. But some mental models are more mistaken than others. When a mental model is shown to be mistaken by another example, we have a name for the feeling that ensues: "my brain has exploded". And here is an example that likely causes your brain to explode (it also causes ghci to use 500MB of memory): G> foldl' (+) 0 (sort (reverse (f 1000000))) 499992.0 (Don't worry about the different sum. We all know that re-ordering floating point numbers changes the sum.) Some brains haven't exploded yet. They believe that reverse helps by forcing all 1000000 cons cells before sorting. To burst them, let's reverse twice: G> foldl' (+) 0 (sort (reverse (reverse (f 1000000)))) *** Exception: stack overflow You can also reverse 3 times, 4 times... In general, even number of times overflows, odd number of times works. It is now clear that order before sorting matters. But why should it? I now give some hints and step down. I invite you to contemplate and discuss further. * Suppose f 6 is [a,b,c,d,e,f]. What is the size of thunk f? Compare to the size of thunk a, b, etc. Also note how much is shared among them. If you want, the source code of System.Random is at http://www.haskell.org/ghc/docs/latest/html/libraries/random/src/System-Random.html If that is too complicated, a simpler model is available at http://haskell.org/onlinereport/random.html For our present purpose, the simpler model is accurate enough. * Based on that knowledge, you're in a similar situation as http://www.haskell.org/haskellwiki/Stack_overflow#Scans Thus for example "last (f 1000000)" overflows, while "print (f 1000000)" works just fine (if you have the patience). * Debug.Trace.trace is great for verifying relative order of evaluation. If I construct this list [trace "0" a, trace "1" b, trace "2" c, ...] and pass it to sort, I can see which item is forced in what order when sort compares items. This command does: G> :m + Debug.Trace G> sort (zipWith (trace . show) [0..] (f 6)) What do you see? What do you think? Bump up the number 6 to 10, 20... to verify what you guess. * If you are interested in finding out in detail why sort does that, the source code is at http://www.haskell.org/ghc/docs/latest/html/libraries/base/src/Data-List.html Note the code of "merge": merge cmp xs [] = xs merge cmp [] ys = ys merge cmp (x:xs) (y:ys) = ... Suppose you re-order the first two lines, i.e., make it merge cmp [] ys = ys merge cmp xs [] = xs merge cmp (x:xs) (y:ys) = ... what will happen? * Prove that the sorting algorithm is only responsible for O(n log n) time and O(log n) stack. Thus any extra stack pressure must come from thunks in the list items. From mhasan at cs.cornell.edu Sat Mar 1 16:53:52 2008 From: mhasan at cs.cornell.edu (Milos Hasan) Date: Sat Mar 1 16:51:34 2008 Subject: [Haskell-cafe] Generating a random list In-Reply-To: <7ca3f0160803010815u12187549xf712bcaea6b0d02d@mail.gmail.com> References: <47C8FCCF.1050209@cs.cornell.edu> <7ca3f0160802292318j4c978820j824329ce67e013d9@mail.gmail.com> <47C9116F.8060707@cs.cornell.edu> <7ca3f0160803010815u12187549xf712bcaea6b0d02d@mail.gmail.com> Message-ID: <47C9D070.6010708@cs.cornell.edu> > It is definitely the strictness analyzer biting you here. In ghci, > the behavior of these two programs is identical (stack overflow). As > kalman said, if you replate sum with foldl' (+) 0 in each of these > programs, the behavior is still identical (correct). > > OK, I could replicate that result. Awesome, thanks a lot! > As a side note, one of the monad laws is this: > > return x >>= f = f x > > So your two programs are semantically equivalent (there's nothing > about IO that forces the evaluation of the list). > > OK, thanks, this is an important point. So maybe I should have done this? main = print $ foldl1' (+) $! take 1000000 randFloats My intuition tells me that the $! (and `seq`) just reduces one level (to WHNF?). If so, is there a way to force complete evaluation (so that nothing is reducible anymore)? Thanks, Milos From vigalchin at gmail.com Sat Mar 1 17:25:40 2008 From: vigalchin at gmail.com (Galchin Vasili) Date: Sat Mar 1 17:23:20 2008 Subject: [Haskell-cafe] .cabal problem Message-ID: <5ae4f2ba0803011425ybc4bbeatae9501116a8d1169@mail.gmail.com> Hello, I am trying to install a package on my Linux Ubuntu machine. It chokes build-depends: base, directory because directory dependency is unresolvable. Do I have to specify "extra-libs" so that correct library space is searched? Actually I tried this and it didn't help. ?? Regards, Vasya -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080301/e24e5eaf/attachment.htm From tgdavies at gmail.com Sat Mar 1 18:41:51 2008 From: tgdavies at gmail.com (Tom Davies) Date: Sat Mar 1 18:39:46 2008 Subject: [Haskell-cafe] STAMP benchmark in Haskell? Message-ID: I'm experimenting with STM (in CAL[1] rather than Haskell) and want to run the STAMP[2] benchmarks. Is there a Haskell translation available, or can anyone suggest a better/different benchmark suite for STM? Thanks, Tom [1] http://openquark.org/Open_Quark/Welcome.html [2] http://stamp.stanford.edu/ From gtener at gmail.com Sat Mar 1 19:21:42 2008 From: gtener at gmail.com (=?ISO-8859-2?Q?Krzysztof_Skrz=EAtnicki?=) Date: Sat Mar 1 19:19:22 2008 Subject: [Haskell-cafe] coerce (safe!) Message-ID: <220e47b40803011621u2a87ddc3t5cdb162b3d543b42@mail.gmail.com> Well, it is simply > coerce :: a -> b > coerce _ = undefined so coerce is simply empty function. But still, it is possible to write a function of type (a->b). Well, possibly I didn't write anything particularly new, but please excuse me for I'm still in sort of a shock after I've discovered it. Yet this function reminds me how little I know so I have a question for you. I didn't took any lectures in Category Theory (for I'm still just a student, and I won't for there are none in my institute), but are there any good (e)books you would recommend for a (future) computer scientist? Regards Christopher Skrz?tnicki -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080302/2c68a5b8/attachment.htm From allbery at ece.cmu.edu Sat Mar 1 19:25:35 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sat Mar 1 19:23:16 2008 Subject: [Haskell-cafe] runInteractiveCommand dying uncatchably? In-Reply-To: <3a6f89fc0803011039s239c1426y770d1a947fc4e991@mail.gmail.com> References: <3a6f89fc0803011039s239c1426y770d1a947fc4e991@mail.gmail.com> Message-ID: <9DEB257F-1B39-4082-8AEF-E2CFDB2B6E1D@ece.cmu.edu> On Mar 1, 2008, at 13:39 , Evan Martin wrote: > If I run the following program, it never prints "done". If I > uncomment the commented line, it does. The exception it's getting is a UNIX signal (SIGPIPE), whose default action if not caught is to silently kill the process. Establish a signal handler for sigPIPE, or ignore it (which will silently convert it to an error EPIPE which will raise a normal I/O exception). -- 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 nominolo at googlemail.com Sat Mar 1 19:58:21 2008 From: nominolo at googlemail.com (Thomas Schilling) Date: Sat Mar 1 19:56:05 2008 Subject: [Haskell-cafe] coerce (safe!) In-Reply-To: <220e47b40803011621u2a87ddc3t5cdb162b3d543b42@mail.gmail.com> References: <220e47b40803011621u2a87ddc3t5cdb162b3d543b42@mail.gmail.com> Message-ID: <71E4E973-7F64-4CF3-B06A-9C319E6BD132@googlemail.com> On 2 mar 2008, at 01.21, Krzysztof Skrz?tnicki wrote: > Well, it is simply > > > coerce :: a -> b > > coerce _ = undefined > > so coerce is simply empty function. But still, it is possible to > write a function of type (a->b). > Well, possibly I didn't write anything particularly new, but please > excuse me for I'm still in > sort of a shock after I've discovered it. > > Yet this function reminds me how little I know so I have a question > for you. > I didn't took any lectures in Category Theory (for I'm still just a > student, and I won't for there are none in my institute), > but are there any good (e)books you would recommend for a (future) > computer scientist? For your particular problem you might want to start with this thread (and the linked paper): http://lambda-the-ultimate.org/node/2003 From agl at imperialviolet.org Sat Mar 1 21:02:04 2008 From: agl at imperialviolet.org (Adam Langley) Date: Sat Mar 1 20:59:44 2008 Subject: [Haskell-cafe] .cabal problem In-Reply-To: <5ae4f2ba0803011425ybc4bbeatae9501116a8d1169@mail.gmail.com> References: <5ae4f2ba0803011425ybc4bbeatae9501116a8d1169@mail.gmail.com> Message-ID: <396556a20803011802o5eed8aack8131205c28a17f9@mail.gmail.com> 2008/3/1 Galchin Vasili : > I am trying to install a package on my Linux Ubuntu machine. It chokes > build-depends: base, directory because directory dependency is > unresolvable. Do I have to specify "extra-libs" so that correct library > space is searched? Actually I tried this and it didn't help. ?? So, here's[1] the package "directory", however it ships with GHC, so you very probably already have it installed. Try `ghc-pkg describe directory` to check. Also, run `ghc --version` to see what version of GHC you are running. If it's < 6.8, you may have problems because the directory package didn't exist before then, I believe the same modules were in the base package. In that case, the easy solution is probably to upgrade GHC. [1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/directory-1.0.0.0 AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org From chaddai.fouche at gmail.com Sat Mar 1 21:48:00 2008 From: chaddai.fouche at gmail.com (=?ISO-8859-1?Q?Chadda=EF_Fouch=E9?=) Date: Sat Mar 1 21:45:42 2008 Subject: [Haskell-cafe] Generating a random list In-Reply-To: <47C9D070.6010708@cs.cornell.edu> References: <47C8FCCF.1050209@cs.cornell.edu> <7ca3f0160802292318j4c978820j824329ce67e013d9@mail.gmail.com> <47C9116F.8060707@cs.cornell.edu> <7ca3f0160803010815u12187549xf712bcaea6b0d02d@mail.gmail.com> <47C9D070.6010708@cs.cornell.edu> Message-ID: 2008/3/1, Milos Hasan : > OK, thanks, this is an important point. So maybe I should have done this? > > main = print $ foldl1' (+) $! take 1000000 randFloats > > My intuition tells me that the $! (and `seq`) just reduces one level (to > WHNF?). If so, is there a way to force complete evaluation (so that > nothing is reducible anymore)? In fact with this code you won't have any problem since the foldl1' will consume strictly the elements as soon as take produce them, avoiding any accumulation of thunk by randoms. Now if you were to put a sort in there (supposedly to do something else than a simple sum...), you could have a need for a function that reduce the list and its elements : > forceList [] = () > forceList (x:xs) = x `seq` forceList xs > > main = print $ foldl1' (+) $ (\xs -> forceList xs `seq` sort xs) $ take 1000000 randFloats In Ghci it don't work (probably because the tail call in forceList isn't optimised) but compiled it will work fine. -- Jeda? From mhasan at cs.cornell.edu Sat Mar 1 23:06:51 2008 From: mhasan at cs.cornell.edu (Milos Hasan) Date: Sat Mar 1 23:04:34 2008 Subject: [Haskell-cafe] Re: Generating a random list Message-ID: <47CA27DB.4020208@cs.cornell.edu> OK, you convinced me that sort is not the problem. After all, "last (f 1000000)" overflows too, and last is a very innocent function. I don't know how you found the size (or structure) of the thunks (I'm not aware of a ghci functionality that can tell me that), could you let me know? Anyway, the problem seems to be that the values pulled from the list are not final float values, but instead they're thunks that grow larger and larger as more floats are pulled from the list. That's why last and sort don't work, but print and foldl' do work. Also, an odd number of reverses helps since sort evaluates the elements from the end of the list first. So I forced those values, and it fixed the problem: -- this function returns n random floats (no thunks) f :: Int -> [Float] f n = take n $ randFloats $ mkStdGen 0 where randFloats g = x `seq` x : randFloats g' where (x, g') = random g main = print $ foldl1' (+) $ sort $ f 1000000 This works without overflow, and so does "last (f 1000000)". Would it make sense for System.Random to do this forcing by default, too? Thanks, Milos From vigalchin at gmail.com Sun Mar 2 00:02:43 2008 From: vigalchin at gmail.com (Galchin Vasili) Date: Sun Mar 2 00:00:33 2008 Subject: [Haskell-cafe] .cabal problem In-Reply-To: <396556a20803011802o5eed8aack8131205c28a17f9@mail.gmail.com> References: <5ae4f2ba0803011425ybc4bbeatae9501116a8d1169@mail.gmail.com> <396556a20803011802o5eed8aack8131205c28a17f9@mail.gmail.com> Message-ID: <5ae4f2ba0803012102x54a20400v14b6c8a25cfccc75@mail.gmail.com> exactly .. I have version 6.6.1 ... question is how do I get the Unbuntu package for version 6.8? V. On Sat, Mar 1, 2008 at 8:02 PM, Adam Langley wrote: > 2008/3/1 Galchin Vasili : > > I am trying to install a package on my Linux Ubuntu machine. It > chokes > > build-depends: base, directory because directory dependency is > > unresolvable. Do I have to specify "extra-libs" so that correct library > > space is searched? Actually I tried this and it didn't help. ?? > > So, here's[1] the package "directory", however it ships with GHC, so > you very probably already have it installed. Try `ghc-pkg describe > directory` to check. Also, run `ghc --version` to see what version of > GHC you are running. If it's < 6.8, you may have problems because the > directory package didn't exist before then, I believe the same modules > were in the base package. In that case, the easy solution is probably > to upgrade GHC. > > > [1] > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/directory-1.0.0.0 > > > AGL > > -- > Adam Langley agl@imperialviolet.org http://www.imperialviolet.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080301/e6401862/attachment.htm From aaltman at pdx.edu Sun Mar 2 02:16:53 2008 From: aaltman at pdx.edu (Aaron Altman) Date: Sun Mar 2 02:14:30 2008 Subject: [Haskell-cafe] "Wrong kind" when attempting to build a monad for a circular list of functions In-Reply-To: References: <47C66283.7000509@pdx.edu> Message-ID: <47CA5465.2040300@pdx.edu> A big thanks to you all for the discussion. I have determined that a monad is actually not the best representation of a circular list of functions. I was able to implement it without any special syntax or unusual typing. For the curious: -------------------------------------------------- funcList :: [Int -> Int] funcList = [\_ -> 1, \_ -> 2, \_ -> 3] iterateCircularFL :: [a -> b] -> (a -> b, [a -> b]) iterateCircularFL (x:xs) = (x, concat [xs, [x]]) applyCircularFL :: a -> [a -> b] -> (b, [a -> b]) applyCircularFL arg fList = let (currentFunc, iteratedList) = iterateCircularFL fList in (currentFunc arg, iteratedList) testTraversal i l | i == 0 = putStr "Done." | i > 0 = do { putStr "Execution "; putStr (show i); putStr " returned "; putStr (show val); putStr ".\n"; testTraversal (i - 1) newList } where (val, newList) = applyCircularFL i l main = do testTraversal 5 funcList From roma at ro-che.info Sun Mar 2 03:49:37 2008 From: roma at ro-che.info (Roman Cheplyaka) Date: Sun Mar 2 03:47:22 2008 Subject: [Haskell-cafe] coerce (safe!) In-Reply-To: <220e47b40803011621u2a87ddc3t5cdb162b3d543b42@mail.gmail.com> References: <220e47b40803011621u2a87ddc3t5cdb162b3d543b42@mail.gmail.com> Message-ID: <20080302084937.GA4045@home.ro-che.info> * Krzysztof Skrz?tnicki [2008-03-02 01:21:42+0100] > Well, it is simply > > > coerce :: a -> b > > coerce _ = undefined > > so coerce is simply empty function. But still, it is possible to write a > function of type (a->b). > Well, possibly I didn't write anything particularly new, but please excuse > me for I'm still in > sort of a shock after I've discovered it. Also there's nice possibility of defining Maybe a without ADT. type Maybe a = (a, Bool) just x = (x, True) nothing = (undefined, False) -- Roman I. Cheplyaka :: http://ro-che.info/ ...being in love is totally punk rock... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080302/b1901cd9/attachment.bin From jon.fairbairn at cl.cam.ac.uk Sun Mar 2 04:19:35 2008 From: jon.fairbairn at cl.cam.ac.uk (Jon Fairbairn) Date: Sun Mar 2 04:17:21 2008 Subject: [Haskell-cafe] Re: coerce (safe!) References: <220e47b40803011621u2a87ddc3t5cdb162b3d543b42@mail.gmail.com> Message-ID: "Krzysztof Skrz?tnicki" writes: > Well, it is simply > >> coerce :: a -> b >> coerce _ = undefined > > so coerce is simply empty function. But still, it is possible to write a > function of type (a->b). > Well, possibly I didn't write anything particularly new, but please excuse > me for I'm still in > sort of a shock after I've discovered it. You have to remember that types in Haskell all have undefined as a member (this is an inevitable consequence of allowing arbitrary recursion). So your coerce is returning something that is in the type claimed by the result, so there's nothing shocking about it! -- J?n Fairbairn Jon.Fairbairn@cl.cam.ac.uk From vandijk.roel at gmail.com Sun Mar 2 08:21:29 2008 From: vandijk.roel at gmail.com (Roel van Dijk) Date: Sun Mar 2 08:19:06 2008 Subject: [Haskell-cafe] "Wrong kind" when attempting to build a monad for a circular list of functions In-Reply-To: <47CA5465.2040300@pdx.edu> References: <47C66283.7000509@pdx.edu> <47CA5465.2040300@pdx.edu> Message-ID: Looks good! A few tips: > funcList :: [Int -> Int] > funcList = [\_ -> 1, \_ -> 2, \_ -> 3] funcList = [const 1, const 2, const 3] > > iterateCircularFL :: [a -> b] -> (a -> b, [a -> b]) > iterateCircularFL (x:xs) = (x, concat [xs, [x]]) {- If you use cycle in main then you do not need this function at all. -} > applyCircularFL :: a -> [a -> b] -> (b, [a -> b]) > applyCircularFL arg fList = > let > (currentFunc, iteratedList) = iterateCircularFL fList > in (currentFunc arg, iteratedList) {- If the list of functions is infinite then we do not have to worry about exhausting it, although an empty list will still cause a pattern match failure. -} applyCircularFL :: a -> [a -> b] -> (b, [a -> b]) applyCircularFL arg (f:fs) = (f arg, fs) >testTraversal i l > | i == 0 = putStr "Done." > | i > 0 = do { > putStr "Execution "; > putStr (show i); > putStr " returned "; > putStr (show val); > putStr ".\n"; > testTraversal (i - 1) newList > } > where (val, newList) = applyCircularFL i l {- Transform funcList into an infinite list to simplify things -} main = testTraversal 5 $ cycle funcList I hope these tips are usefull :-) Roel From paul at cogito.org.uk Sun Mar 2 11:53:09 2008 From: paul at cogito.org.uk (Paul Johnson) Date: Sun Mar 2 11:50:57 2008 Subject: [Haskell-cafe] Parody of Darcs patch theory from 1981 Message-ID: <47CADB75.1040707@cogito.org.uk> I was looking through my old copy of "The Devil's DP Dictionary" by Stan Kelly-Bootle, and came across the entry for Stepwise Refinement. I thought "I've seen this before: this is a parody of Darcs patch theory". It included the Null patch, chains of patches, inverse patches, and pseudo-inverse patches. But the book was published in 1981. I've got the pages scanned, but I can't upload them to Wikimedia because they are still in copyright. However I'm quite sure that limited distribution would fall into "fair use" (non-commercial, small part of work, no impact on market, academic relevance). The total file size is about 520kBytes. Assuming people would like to see them, does anyone have any ideas beyond "email to requestors"? Paul. From miguelimo38 at yandex.ru Sun Mar 2 12:09:40 2008 From: miguelimo38 at yandex.ru (Miguel Mitrofanov) Date: Sun Mar 2 12:07:24 2008 Subject: [Haskell-cafe] Parody of Darcs patch theory from 1981 In-Reply-To: <47CADB75.1040707@cogito.org.uk> References: <47CADB75.1040707@cogito.org.uk> Message-ID: <9C02143A-2D54-4130-8063-5B0C62326CD1@yandex.ru> Does it start with "Any sequence of KLUDGES, not necessarily distinct or finite..."? If so, it can be found in "The Computer Contradictionary", by the same author, and probably illegal copy of the last book can be found in the net somewhere. On 2 Mar 2008, at 19:53, Paul Johnson wrote: > I was looking through my old copy of "The Devil's DP Dictionary" by > Stan Kelly-Bootle, and came across the entry for Stepwise > Refinement. I thought "I've seen this before: this is a parody of > Darcs patch theory". It included the Null patch, chains of patches, > inverse patches, and pseudo-inverse patches. But the book was > published in 1981. > > I've got the pages scanned, but I can't upload them to Wikimedia > because they are still in copyright. However I'm quite sure that > limited distribution would fall into "fair use" (non-commercial, > small part of work, no impact on market, academic relevance). The > total file size is about 520kBytes. Assuming people would like to > see them, does anyone have any ideas beyond "email to requestors"? > > Paul. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From apfelmus at quantentunnel.de Sun Mar 2 12:17:09 2008 From: apfelmus at quantentunnel.de (apfelmus) Date: Sun Mar 2 12:15:03 2008 Subject: [Haskell-cafe] Re: Generating a random list In-Reply-To: <47C9CE0A.4010600@vex.net> References: <47C8FCCF.1050209@cs.cornell.edu> <47C903E6.7090204@serpentine.com> <47C91C05.90608@cs.cornell.edu> <47C9CE0A.4010600@vex.net> Message-ID: Albert Y. C. Lai wrote: > Note the code of "merge": > > merge cmp xs [] = xs > merge cmp [] ys = ys > merge cmp (x:xs) (y:ys) = ... > > Suppose you re-order the first two lines, i.e., make it > > merge cmp [] ys = ys > merge cmp xs [] = xs > merge cmp (x:xs) (y:ys) = ... > > what will happen? Oh, so the mergesort in the library doesn't behave as nicely as I'd have expected. I'd consider the first definition a strictness bug; the general etiquette is to force arguments from left to right. Regards, apfelmus From catamorphism at gmail.com Sun Mar 2 12:26:55 2008 From: catamorphism at gmail.com (Tim Chevalier) Date: Sun Mar 2 12:24:39 2008 Subject: [Haskell-cafe] Parody of Darcs patch theory from 1981 In-Reply-To: <47CADB75.1040707@cogito.org.uk> References: <47CADB75.1040707@cogito.org.uk> Message-ID: <4683d9370803020926g1ceac551v3d8c398ad645943@mail.gmail.com> On 3/2/08, Paul Johnson wrote: > I was looking through my old copy of "The Devil's DP Dictionary" by Stan > Kelly-Bootle, and came across the entry for Stepwise Refinement. I > thought "I've seen this before: this is a parody of Darcs patch > theory". It included the Null patch, chains of patches, inverse > patches, and pseudo-inverse patches. But the book was published in 1981. > > I've got the pages scanned, but I can't upload them to Wikimedia because > they are still in copyright. However I'm quite sure that limited > distribution would fall into "fair use" (non-commercial, small part of > work, no impact on market, academic relevance). The total file size is > about 520kBytes. Assuming people would like to see them, does anyone > have any ideas beyond "email to requestors"? I would be entertained, but perhaps this might be more on-topic on the darcs-users mailing list (and interested parties might be more likely to see it there, since not everyone can keep up with haskell-cafe) :-) Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "Imagine if every Thursday your shoes exploded if you tied them the usual way. This happens to us all the time with computers, and nobody thinks of complaining." -- Jeff Raskin From newsham at lava.net Sun Mar 2 14:12:34 2008 From: newsham at lava.net (Tim Newsham) Date: Sun Mar 2 14:10:13 2008 Subject: [Haskell-cafe] A mini haskell (in 244 lines of python) Message-ID: For education and fun I wrote a small untyped non-strict lambda calculus evaluator in python. One of the goals was to keep it fairly small and simple, and to do most of the work in the implemented scripting language itself. For that reason, I added macros to allow things like "let" and "letrec" to be defined as syntactic sugar easily outside of the evaluation engine itself. The result is 244 lines of python, a small prelude that implements tuples, lists and the state monad, and some small example scripts. The prelude and scripts are heavily influenced by Haskell, the main differences being a much simpler syntax, lack of pattern matching and lack of a type system. Data structures aren't supported but are implemented fairly easily using lambda expressions as described in http://www.cs.nott.ac.uk/~nhn/TFP2006/Papers/03-JansenKoopmanPlasmeijer-EfficientInterpretation.pdf This is all available at http://www.thenewsh.com/%7Enewsham/lambda/ as extracted package and .tgz. The README file has documentation including small examples. Accompanying scripts provide more complete examples, such as: [WITHLIST [LET from2 (iter (add 1) 2) [LET primes (nubBy (\x \y (eq (mod y x) 0)) from2) (traceList Val (take 10 primes)) ]]] which calculates the first 10 primes. Exercise to the reader: I bet the evaluator could all be written much more compactly in Haskell. Tim Newsham http://www.thenewsh.com/~newsham/ From paul at cogito.org.uk Sun Mar 2 14:32:40 2008 From: paul at cogito.org.uk (Paul Johnson) Date: Sun Mar 2 14:30:20 2008 Subject: [Haskell-cafe] Parody of Darcs patch theory from 1981 In-Reply-To: <9C02143A-2D54-4130-8063-5B0C62326CD1@yandex.ru> References: <47CADB75.1040707@cogito.org.uk> <9C02143A-2D54-4130-8063-5B0C62326CD1@yandex.ru> Message-ID: <47CB00D8.2000800@cogito.org.uk> Miguel Mitrofanov wrote: > Does it start with "Any sequence of KLUDGES, not necessarily distinct > or finite..."? If so, it can be found in "The Computer > Contradictionary", by the same author, and probably illegal copy of > the last book can be found in the net somewhere. Indeed. In fact I'm not even sure its illegal. Its at http://www.scribd.com/doc/264064/The-Computer-Contradictionary page 202. The typography has been considerably munged (tildes replaced by hyphens mostly), but you can still get a good idea of what its saying. From jmaessen at alum.mit.edu Sun Mar 2 14:36:34 2008 From: jmaessen at alum.mit.edu (Jan-Willem Maessen) Date: Sun Mar 2 14:34:11 2008 Subject: [Haskell-cafe] STAMP benchmark in Haskell? In-Reply-To: References: Message-ID: <45697B5E-F37B-436D-8DC1-06B72AEF6601@alum.mit.edu> On Mar 1, 2008, at 6:41 PM, Tom Davies wrote: > I'm experimenting with STM (in CAL[1] rather than Haskell) > and want to run the STAMP[2] benchmarks. Hmm, I don'tknow of a particularly good STM-in-Haskell benchmark, but I'd say that the STAMP benchmarks are written in a rather imperative, object-oriented style. You wouldn't get very meaningful data about anything if you were to naively translate them to Haskell; you'd instead have to rewrite them completely (at which point head-to-head comparisons are difficult). > Is there a Haskell translation available, or can anyone > suggest a better/different benchmark suite for STM? Good question. Because we tend to eschew mutable state in Haskell, I'd expect the characteristics of such an application to be *very* different. -Jan-Willem Maessen > > > Thanks, > Tom > > [1] http://openquark.org/Open_Quark/Welcome.html > [2] http://stamp.stanford.edu/ > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From lrpalmer at gmail.com Sun Mar 2 16:30:22 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Sun Mar 2 16:27:59 2008 Subject: [Haskell-cafe] coerce (safe!) In-Reply-To: <20080302084937.GA4045@home.ro-che.info> References: <220e47b40803011621u2a87ddc3t5cdb162b3d543b42@mail.gmail.com> <20080302084937.GA4045@home.ro-che.info> Message-ID: <7ca3f0160803021330gb7e7ed3td1f5fe8ff7e76d15@mail.gmail.com> 2008/3/2 Roman Cheplyaka : > * Krzysztof Skrz?tnicki [2008-03-02 01:21:42+0100] > > > Well, it is simply > > > > > coerce :: a -> b > > > coerce _ = undefined > > > > so coerce is simply empty function. But still, it is possible to write a > > function of type (a->b). > > Well, possibly I didn't write anything particularly new, but please excuse > > me for I'm still in > > sort of a shock after I've discovered it. > > Also there's nice possibility of defining Maybe a without ADT. > type Maybe a = (a, Bool) > just x = (x, True) > nothing = (undefined, False) That's a hack. This is my favorite: type Maybe a = forall b. (a -> b) -> b -> b just x = \j n -> j x nothing = \j n -> n Luke From k.kosciuszkiewicz+haskell at gmail.com Sun Mar 2 21:23:19 2008 From: k.kosciuszkiewicz+haskell at gmail.com (Krzysztof =?utf-8?Q?Ko=C5=9Bciuszkiewicz?=) Date: Sun Mar 2 21:21:05 2008 Subject: [Haskell-cafe] Space leak - help needed Message-ID: <20080303022318.GE29085@localdomain> Dear Haskellers, Another story from an (almost) happy Haskell user that finds himself overwhelmed by laziness/space leaks. I'm trying to parse a large file (>600MB) with a single S-expression like structure. With the help of ByteStrings I'm down to 4min processing time in constant space. However, when I try to wrap the parse results in a data structure, the heap blows up - even though I never actually inspect the structure being built! This bugs me, so I come here looking for answers. Parser follows: > module Main where > > import qualified Data.ByteString.Lazy.Char8 as B > import Text.ParserCombinators.Parsec > import Text.ParserCombinators.Parsec.Pos > import System.Environment > import System.Exit > import qualified Data.Map as M > import Lexer > > type XdlParser a = GenParser Token XdlState a > > -- Parser state > type XdlState = Counts > > type Counts = M.Map Count Integer > > data Count = ListCount | SymbolCount > deriving (Eq, Ord, Show) > > emptyXdlState = M.empty > > incCount :: Count -> (Counts -> Counts) > incCount c = M.insertWith' (+) c 1 > > -- handling tokens > myToken :: (Token -> Maybe a) -> XdlParser a > myToken test = token showTok posTok testTok > where > showTok = show > posTok = const (initialPos "") > testTok = test > > -- Syntax of expressions > data Exp = Sym !B.ByteString | List ![Exp] > deriving (Eq, Show) > > expr = list <|> symbol > > rparen = myToken $ \t -> case t of > RParen -> Just () > other -> Nothing > > lparen = myToken $ \t -> case t of > LParen -> Just () > other -> Nothing > > name = myToken $ \t -> case t of > Name n -> Just n > other -> Nothing > > list = do > updateState $ incCount ListCount > lparen > xs <- many1 expr > rparen > return () > -- return $! (List xs) > > symbol = do > updateState $ incCount SymbolCount > name >> return () > -- Sym `fmap` name > > -- Top level parser > top :: XdlParser XdlState > top = do > l <- many1 list > eof > getState > > main = do > args <- getArgs > case args of > [fname] -> do > text <- B.readFile fname > let result = runParser top emptyXdlState fname (tokenize text) > putStrLn $ either show show result > _ -> putStrLn "usage: parse filename" >> exitFailure And the Lexer: > module Lexer (Token(..), tokenize) where > > import qualified Data.ByteString.Lazy.Char8 as B > import Control.Monad > import Data.Char > import Data.List > import System.Environment > import System.Exit > > data Token = LParen > | RParen > | Name B.ByteString > deriving (Ord, Eq, Show) > > type Input = B.ByteString > > -- Processor returns Nothing if it can't process the Input > type Processor = Input -> Maybe ([Token], Input) > > -- Tokenize ends the list when all processors return Nothing > tokenize :: Input -> [Token] > tokenize = concat . unfoldr processAll > where > processors = [doSpaces, doComment, doParens, doName] > processAll :: Processor > processAll bs = if B.null bs > then Nothing > else foldr mminus Nothing $ map ($ bs) processors > mminus a@(Just _) _ = a > mminus Nothing b = b > > doSpaces :: Processor > doSpaces bs = > if B.null sp > then Nothing > else Just ([], nsp) > where > (sp, nsp) = B.span isSpace bs > > doComment :: Processor > doComment bs = > if B.pack "# " `B.isPrefixOf` bs > then Just ([], B.dropWhile (/= '\n') bs) > else Nothing > > doParens :: Processor > doParens bs = case B.head bs of > '(' -> Just ([LParen], B.tail bs) > ')' -> Just ([RParen], B.tail bs) > _ -> Nothing > > doName :: Processor > doName bs = > if B.null nsp > then Nothing > else Just ([Name nsp], sp) > where > (nsp, sp) = B.span (not . isRest) bs > isRest c = isSpace c || c == ')' || c == '(' Regards, -- Krzysztof Ko?ciuszkiewicz Skype: dr.vee, Gadu: 111851, Jabber: kokr@jabberpl.org "Simplicity is the ultimate sophistication" -- Leonardo da Vinci From lrpalmer at gmail.com Sun Mar 2 22:03:12 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Sun Mar 2 22:00:47 2008 Subject: [Haskell-cafe] Space leak - help needed In-Reply-To: <20080303022318.GE29085@localdomain> References: <20080303022318.GE29085@localdomain> Message-ID: <7ca3f0160803021903t1b2d69ecsa208cbdd12fbe1b0@mail.gmail.com> On Mon, Mar 3, 2008 at 2:23 AM, Krzysztof Ko?ciuszkiewicz wrote: > Dear Haskellers, > > Another story from an (almost) happy Haskell user that finds himself > overwhelmed by laziness/space leaks. > > I'm trying to parse a large file (>600MB) with a single S-expression > like structure. With the help of ByteStrings I'm down to 4min processing > time in constant space. However, when I try to wrap the parse results > in a data structure, the heap blows up - even though I never actually > inspect the structure being built! This bugs me, so I come here looking > for answers. Well, I haven't read this through, but superficially, it looks like you're expecting the data structure to be constructed lazily. But... > > -- Syntax of expressions > > data Exp = Sym !B.ByteString | List ![Exp] > > deriving (Eq, Show) It is declared as strict, so it's not going to be constructed lazily... Luke From bertram.felgenhauer at googlemail.com Sun Mar 2 23:20:09 2008 From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer) Date: Sun Mar 2 23:17:52 2008 Subject: [Haskell-cafe] Space leak - help needed In-Reply-To: <20080303022318.GE29085@localdomain> References: <20080303022318.GE29085@localdomain> Message-ID: <20080303042009.GB4363@zombie.inf.tu-dresden.de> Krzysztof Ko?ciuszkiewicz wrote: > Another story from an (almost) happy Haskell user that finds himself > overwhelmed by laziness/space leaks. > > I'm trying to parse a large file (>600MB) with a single S-expression > like structure. With the help of ByteStrings I'm down to 4min processing > time in constant space. However, when I try to wrap the parse results > in a data structure, the heap blows up - even though I never actually > inspect the structure being built! This bugs me, so I come here looking > for answers. Note that Parsec has to parse the whole file before it can decide whether to return a result (Left _) or an error (Right _). ghc would have to be quite smart to eliminate the creation of the expression tree entirely. The polyparse library (http://www.cs.york.ac.uk/fp/polyparse/) offers some lazy parsers, maybe one of those fits your needs. Text.ParserCombinators.Poly.StateLazy is the obvious candidate. HTH, Bertram From bjpop at csse.unimelb.edu.au Mon Mar 3 00:23:52 2008 From: bjpop at csse.unimelb.edu.au (Bernie Pope) Date: Mon Mar 3 00:16:55 2008 Subject: [Haskell-cafe] coerce (safe!) In-Reply-To: <7ca3f0160803021330gb7e7ed3td1f5fe8ff7e76d15@mail.gmail.com> References: <220e47b40803011621u2a87ddc3t5cdb162b3d543b42@mail.gmail.com> <20080302084937.GA4045@home.ro-che.info> <7ca3f0160803021330gb7e7ed3td1f5fe8ff7e76d15@mail.gmail.com> Message-ID: <77A44F60-51A9-4E9B-83DD-F00307066CBB@csse.unimelb.edu.au> On 03/03/2008, at 8:30 AM, Luke Palmer wrote: > 2008/3/2 Roman Cheplyaka : >> * Krzysztof Skrz?tnicki [2008-03-02 01:21:42 >> +0100] >> >>> Well, it is simply >>> >>>> coerce :: a -> b >>>> coerce _ = undefined >>> >>> so coerce is simply empty function. But still, it is possible to >>> write a >>> function of type (a->b). >>> Well, possibly I didn't write anything particularly new, but >>> please excuse >>> me for I'm still in >>> sort of a shock after I've discovered it. >> >> Also there's nice possibility of defining Maybe a without ADT. >> type Maybe a = (a, Bool) >> just x = (x, True) >> nothing = (undefined, False) > > That's a hack. This is my favorite: > > type Maybe a = forall b. (a -> b) -> b -> b > just x = \j n -> j x > nothing = \j n -> n For something slightly different, I've always enjoyed lists (or integer indexed structures) as functions: type List a = Integer -> Maybe a You've got to watch out for non-contiguous lists. It's a good challenge to write head, tail, nil and cons for this type. Then write conversions to/ from normal lists. Bernie. From sulzmann at comp.nus.edu.sg Mon Mar 3 03:41:52 2008 From: sulzmann at comp.nus.edu.sg (Martin Sulzmann) Date: Mon Mar 3 03:39:33 2008 Subject: [Haskell-cafe] STAMP benchmark in Haskell? In-Reply-To: <45697B5E-F37B-436D-8DC1-06B72AEF6601@alum.mit.edu> References: <45697B5E-F37B-436D-8DC1-06B72AEF6601@alum.mit.edu> Message-ID: <18379.47568.399751.427783@suna0.comp.nus.edu.sg> Some Haskell-STM benchmarks can be found here: Dissecting Transactional Executions in Haskell Cristian Perfumo et al http://www.cs.rochester.edu/meetings/TRANSACT07/ Martin -Willem Maessen writes: > > On Mar 1, 2008, at 6:41 PM, Tom Davies wrote: > > > I'm experimenting with STM (in CAL[1] rather than Haskell) > > and want to run the STAMP[2] benchmarks. > > Hmm, I don'tknow of a particularly good STM-in-Haskell benchmark, but > I'd say that the STAMP benchmarks are written in a rather imperative, > object-oriented style. You wouldn't get very meaningful data about > anything if you were to naively translate them to Haskell; you'd > instead have to rewrite them completely (at which point head-to-head > comparisons are difficult). > > > Is there a Haskell translation available, or can anyone > > suggest a better/different benchmark suite for STM? > > Good question. Because we tend to eschew mutable state in Haskell, > I'd expect the characteristics of such an application to be *very* > different. > > -Jan-Willem Maessen > > > > > > > Thanks, > > Tom > > > > [1] http://openquark.org/Open_Quark/Welcome.html > > [2] http://stamp.stanford.edu/ > > > > _______________________________________________ > > 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 icfp.publicity at googlemail.com Mon Mar 3 10:03:10 2008 From: icfp.publicity at googlemail.com (Matthew Fluet (ICFP Publicity Chair)) Date: Mon Mar 3 10:00:47 2008 Subject: [Haskell-cafe] ICFP08 Final CFP Message-ID: <53ff55480803030703p618af6cexe2710c7773648a7c@mail.gmail.com> Final Call for Papers ICFP 2008: International Conference on Functional Programming Victoria, BC, Canada, 22-24 September 2008 http://www.icfpconference.org/icfp2008 Submission deadline: 2 April 2008 ICFP 2008 seeks original papers on the art and science of functional programming. Submissions are invited on all topics from principles to practice, from foundations to features, from abstraction to application. The scope includes all languages that encourage functional programming, including both purely applicative and imperative languages, as well as languages with objects and concurrency. Particular topics of interest include * Applications and Domain-Specific Languages * Foundations * Design * Implementation * Transformation and Analysis * Software-development Techniques * Functional Pearls * Practice and Experience Important Dates (at 09:00 Apia time, UTC-11) ~~~~~~~~~~~~~~~ Submission: 2 April 2008 Author response: 21 May 2008 Notification: 16 June 2008 Final papers due: 7 July 2008 Call for Papers (full text) ~~~~~~~~~~~~~~~ http://www.icfpconference.org/icfp2008/cfp/cfp.html The submission URL will be available from the above page shortly. Program Chair ~~~~~~~~~~~~~ Peter Thiemann Albert-Ludwigs-Universit?t Georges-K?hler-Allee 079 79110 Freiburg, Germany Email: icfp08@informatik.uni-freiburg.de Phone: +49 761 203 8051 Fax: +49 761 203 8052 Mail sent to the address above is filtered for spam. If you send mail and do not receive a prompt response, particularly if the deadline is looming, feel free to telephone and reverse the charges. From jefferson.r.heard at gmail.com Mon Mar 3 11:14:42 2008 From: jefferson.r.heard at gmail.com (Jefferson Heard) Date: Mon Mar 3 11:12:56 2008 Subject: [Haskell-cafe] Failing to make `par` Message-ID: <4165d3a70803030814j4bfe7d1by3b417dd7851ecd1@mail.gmail.com> I've used Control.Parallel and Control.Parallel.Strategies extensively in the past, and I thought I knew what I was doing. I declared the following function: findSupernodes' :: S.Set Name -> Int -> Tree -> Protein.Tree -> S.Set Name findSupernodes' set size (Node i _ _ s il ir) (Protein.Node _ pl pr _ g) | S.size g > size = (Name (fromIntegral i)) `S.insert` set | otherwise = leftNodes `S.union` rightNodes where leftNodes = (findSupernodes' set size il pl) rightNodes = (findSupernodes' set size il pl) findSupernodes' set size (Leaf _ _) (Protein.Gene _ _ _) = set and then simply wrote the following as an initial stab at parallelizing it, because actually calling this function causes the program to execute an absurd number of string comparisons: findSupernodes = findSupernodes' S.empty findSupernodes' :: S.Set Name -> Int -> Tree -> Protein.Tree -> S.Set Name findSupernodes' set size (Node i _ _ s il ir) (Protein.Node _ pl pr _ g) | S.size g > size = (Name (fromIntegral i)) `S.insert` set | otherwise = leftNodes `par` rightNodes `seq` leftNodes `S.union` rightNodes where leftNodes = (findSupernodes' set size il pl) rightNodes = (findSupernodes' set size il pl) findSupernodes' set size (Leaf _ _) (Protein.Gene _ _ _) = set The thing is, these two functions don't return the same thing. The parallel version is returning an empty set, while the sequential version returns what it should return. Any clue what I did wrong? -- Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080303/33193347/attachment.htm From hpacheco at gmail.com Mon Mar 3 12:35:06 2008 From: hpacheco at gmail.com (Hugo Pacheco) Date: Mon Mar 3 12:32:41 2008 Subject: [Haskell-cafe] Issues(Bugs?) with GHC Type Families Message-ID: <7b92c2840803030935t6ed5d2a6ne63d5f8b3d5fe917@mail.gmail.com> Hi all, I have recently tried to replicate some examples from in the articles about type families but found some possible bugs. In [2], the example class C a where type S a (k :: * -> *) :: * instance C [a] where type S [a] k = (a,k a) does not compile under the claim that the type variable k is not in scope. However, if we extract the type family from the class type family S a (k :: * -> *) :: * type instance S [a] k = (a, k a) class C a it compiles correctly. According to [3], the difference is purely syntactic sugar, does that mean that both examples should compile and behave the same or is there some subtlety that justifies the class example not to compile? Another issue is that data kinds (used in both [2] and [3]) do not seem to be supported at all by the compiler, are they already implemented in GHC? Simple examples such as datakind Nat = Zero or datakind Nat = Zero | Succ Nat fail to compile. Perhaps some of these should be submitted to the GHC Bug Tracker. I have tested both GHC 6.8.2 and 6.9.20080218. References: 1. Associated Types with Class. Manuel M. T. Chakravarty, Gabriele Keller, Simon Peyton Jones, and Simon Marlow. In *Proceedings of The 32nd Annual ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages (POPL'05)*, pages 1-13, ACM Press, 2005. 2. Associated Type Synonyms. Manuel M. T. Chakravarty, Gabriele Keller, and Simon Peyton Jones. In *Proceedings of The Tenth ACM SIGPLAN International Conference on Functional Programming *, ACM Press, pages 241-253, 2005. 3. Towards Open Type Functions for Haskell. Tom Schrijvers, Martin Sulzmann, Simon Peyton-Jones, and Manuel M. T. Chakravarty. Unpublished manuscript, 2007. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080303/30db966f/attachment.htm From ryani.spam at gmail.com Mon Mar 3 13:33:23 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Mon Mar 3 13:30:57 2008 Subject: [Haskell-cafe] Issues(Bugs?) with GHC Type Families In-Reply-To: <7b92c2840803030935t6ed5d2a6ne63d5f8b3d5fe917@mail.gmail.com> References: <7b92c2840803030935t6ed5d2a6ne63d5f8b3d5fe917@mail.gmail.com> Message-ID: <2f9b2d30803031033w46e956bdt13ec45d154579db4@mail.gmail.com> 2008/3/3 Hugo Pacheco : > class C a where > type S a (k :: * -> *) :: * > instance C [a] where > type S [a] k = (a,k a) > > does not compile under the claim that the type variable k is not in scope. It's not entirely syntactical sugar; I believe that when a type family is a member of a type-class it makes the assertion that only the class variables are part of the "function". In the class declaration: > class C a where > type S a (k :: * -> *) :: * there are two arguments to the type function S, but the class C only provides one. Contrast with the following > type Pair a k = (a, k a) > class C a where > type S a :: (* -> *) -> * > instance C [a] where > type S [a] = Pair a > datakind Nat = Zero > or > datakind Nat = Zero | Succ Nat datakinds are listed under "future work" in the papers I have read; they aren't implemented yet. -- ryan From dons at galois.com Mon Mar 3 17:22:59 2008 From: dons at galois.com (Don Stewart) Date: Mon Mar 3 17:20:40 2008 Subject: [Haskell-cafe] Re: static constants -- ideas? Message-ID: <20080303222259.GM12508@scytale.galois.com> jason.dusek: > I have an awkward programming problem -- I need to take a > dictionary, parse it, build a bunch of intermediate lists and > then make maps and tries out of the list. A "programming > problem" because it's taken me a fair amount of effort to pull > together the parser and list generator -- and "awkward" > because a 69000 item list, [(String, [(String, String)])], > does not compile under GHC (stack overflow). (It's not likely > to compile under anything else, either!) Here's an example of the approach Bryan outlined, which does seem to work for files as large as gcc can handle: * generate your big Haskell Map * serialise it with Data.Binary, and Codec.Compression.GZip to a file * compile the data into a C const array, and link that into Haskell * decode it on startup, ressurecting the Haskell data. The C source looks like: const uint8_t beowulf[] = { 31, 139, 8, 0, 0, 0, 0, 0, 0, 3, 124, 189, 75, 150, 46, 54, 93, 193, 96, 144, 241, 168, 172, 238, 214, 0, ... http://code.haskell.org/~dons/code/compiled-constants/cbits/constants.c which is the gzip, Data.Binary encoded version of a Map ByteString Int. Then the Haskell code need only access this array as a Ptr Word8, wrap that as a Bytestring, then run Data.Binary over the result to rebuild the Map. As you can see here: http://code.haskell.org/~dons/code/compiled-constants/Constants.hs I've put a couple of examples of how to access C-side serialised Haskell values in a package here: http://code.haskell.org/~dons/code/compiled-constants/ Cheers, Don From jgbailey at gmail.com Mon Mar 3 19:43:57 2008 From: jgbailey at gmail.com (Justin Bailey) Date: Mon Mar 3 19:41:30 2008 Subject: [Haskell-cafe] Annotating GHC assembler output? Message-ID: I'm interested in seeing what kind of assembler my functions turn into. Is there a means of annotating assembler output, similar to the {#- CORE -#} pragma? Is there a trickier way of doing it? Justin From gtener at gmail.com Mon Mar 3 19:45:44 2008 From: gtener at gmail.com (=?ISO-8859-2?Q?Krzysztof_Skrz=EAtnicki?=) Date: Mon Mar 3 19:43:23 2008 Subject: [Haskell-cafe] (flawed?) benchmark : sort Message-ID: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> Hi I was playing with various versions of sorting algorithms. I know it's very easy to create flawed benchmark and I don't claim those are good ones. However, it really seems strange to me, that sort - library function - is actually the worse measured function. I can hardly belive it, and I'd rather say I have made a mistake preparing it. The overall winner seems to be qsort_iv - which is nothing less but old sort replaced by mergesort now. Any clues? Regards Christopher Skrz?tnicki --- cut here --- [Tener@laptener haskell]$ ghc -O2 --make qsort.hs && ./qsort +RTS -sstderr -RTS > /dev/null [1 of 1] Compiling Main ( qsort.hs, qsort.o ) Linking qsort ... ./qsort +RTS -sstderr (1.0,"iv") (1.1896770400256864,"v") (1.3091609772011856,"treeSort") (1.592515715933153,"vii") (1.5953543402198838,"vi") (1.5961286512637272,"iii") (1.8175480563244177,"i") (1.8771604568641642,"ii") (2.453160634439497,"mergeSort") (2.6627090768870216,"sort") 26,094,674,624 bytes allocated in the heap 12,716,656,224 bytes copied during GC (scavenged) 2,021,104,592 bytes copied during GC (not scavenged) 107,225,088 bytes maximum residency (140 sample(s)) 49773 collections in generation 0 ( 21.76s) 140 collections in generation 1 ( 23.61s) 305 Mb total memory in use INIT time 0.00s ( 0.00s elapsed) MUT time 20.39s ( 20.74s elapsed) GC time 45.37s ( 46.22s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 65.76s ( 66.96s elapsed) %GC time 69.0% (69.0% elapsed) Alloc rate 1,279,723,644 bytes per MUT second Productivity 31.0% of total user, 30.5% of total elapsed --- cut here --- {-# OPTIONS_GHC -O2 #-} module Main where import System.CPUTime import System.IO import System.Environment import System.Random import Data.List( partition, sort ) data Tree a = Node (Tree a) a (Tree a) | Leaf qsort_i [] = [] qsort_i (x:xs) = qsort_i (filter (< x) xs) ++ [x] ++ qsort_i (filter (>= x) xs) qsort_ii [] = [] qsort_ii (x:xs) = let (ls,gt) = partition (< x) xs in qsort_ii ls ++ [x] ++ qsort_ii gt qsort_iii xs = qsort_iii' [] xs qsort_iii' acc [] = acc qsort_iii' acc (x:xs) = let (ls,gt) = partition (< x) xs in let acc' = (x:(qsort_iii' acc gt)) in qsort_iii' acc' ls qsort_v [] = [] qsort_v (x:xs) = let (xlt, xgt ) = foldl (\ (lt,gt) el -> case compare x el of GT -> (el:lt, gt) _ -> (lt, el:gt) ) ([],[]) xs in qsort_v xlt ++ [x] ++ qsort_v xgt -- zmodyfikowany i qsort_vi [] = [] qsort_vi (x:xs) = qsort_vi (filter (\y-> compare x y == GT) xs) ++ [x] ++ qsort_vi (filter (\y-> compare x y /= GT) xs) -- zmodyfikowany iii qsort_vii xs = qsort_vii' [] xs qsort_vii' acc [] = acc qsort_vii' acc (x:xs) = let (ls,gt) = partition (\y-> compare x y == GT) xs in let acc' = (x:(qsort_vii' acc gt)) in qsort_vii' acc' ls -- qsort is stable and does not concatenate. qsort_iv xs = qsort_iv' (compare) xs [] qsort_iv' _ [] r = r qsort_iv' _ [x] r = x:r qsort_iv' cmp (x:xs) r = qpart cmp x xs [] [] r -- qpart partitions and sorts the sublists qpart cmp x [] rlt rge r = -- rlt and rge are in reverse order and must be sorted with an -- anti-stable sorting rqsort_iv' cmp rlt (x:rqsort_iv' cmp rge r) qpart cmp x (y:ys) rlt rge r = case cmp x y of GT -> qpart cmp x ys (y:rlt) rge r _ -> qpart cmp x ys rlt (y:rge) r -- rqsort is as qsort but anti-stable, i.e. reverses equal elements rqsort_iv' _ [] r = r rqsort_iv' _ [x] r = x:r rqsort_iv' cmp (x:xs) r = rqpart cmp x xs [] [] r rqpart cmp x [] rle rgt r = qsort_iv' cmp rle (x:qsort_iv' cmp rgt r) rqpart cmp x (y:ys) rle rgt r = case cmp y x of GT -> rqpart cmp x ys rle (y:rgt) r _ -> rqpart cmp x ys (y:rle) rgt r -- code by Orcus -- Zadanie 9 - merge sort mergeSort :: Ord a => [a] -> [a] mergeSort [] = [] mergeSort [x] = [x] mergeSort xs = let(l, r) = splitAt (length xs `quot` 2) xs in mergeSortP (mergeSort l) (mergeSort r) -- funkcja pomocnicza scalaj??ca dwie listy uporz??dkowane w jedn?? mergeSortP :: Ord a => [a] -> [a] -> [a] mergeSortP xs [] = xs mergeSortP [] ys = ys mergeSortP (x:xs) (y:ys) | x <= y = x:(mergeSortP xs (y:ys)) | otherwise = y:(mergeSortP (x:xs) ys) -- Zadanie 10 - tree sort treeSort :: Ord a => [a] -> [a] -- pointless po raz drugi treeSort = (treeSortInorder . treeSortToTree) treeSortToTree :: Ord a => [a] -> Tree a treeSortToTree [] = Leaf treeSortToTree (x:xs) = let (xlt, xgt) = foldl (\ (lt,gt) el -> case compare x el of GT -> (el:lt, gt) _ -> (lt, el:gt) ) ([],[]) xs in Node (treeSortToTree xlt) x (treeSortToTree xgt) treeSortInorder :: Ord a => Tree a -> [a] treeSortInorder Leaf = [] treeSortInorder (Node l x r) = (treeSortInorder l) ++ [x] ++ (treeSortInorder r) -- end code by Orcus -- big_number = 1000000 :: Int main = do gen <- getStdGen let xs' = randomRs (1::Int, big_number) gen xs <- return (take big_number xs') t1 <- getCPUTime print (qsort_i xs) -- i t2 <- getCPUTime print (qsort_ii xs) -- ii t3 <- getCPUTime print (qsort_iii xs) -- iii t4 <- getCPUTime print (qsort_iv xs) -- iv t5 <- getCPUTime print (qsort_v xs) -- v t6 <- getCPUTime print (qsort_vi xs) -- vi t7 <- getCPUTime print (qsort_vii xs) -- vii t8 <- getCPUTime print (sort xs) -- sort t9 <- getCPUTime print (mergeSort xs) -- mergeSort t10 <- getCPUTime print (treeSort xs) -- treeSort t11 <- getCPUTime let getTimes xs = zipWith (-) (tail xs) xs let timers = [t1,t2,t3,t4,t5,t6,t7,t8,t9,t10,t11] let times = getTimes timers let table = zip times ["i","ii","iii","iv", "v", "vi", "vii", "sort","mergeSort","treeSort"] let sorted = sort table let scaled = map (\(x,n) -> (((fromIntegral x / (fromIntegral $ fst (head sorted)))::Double),n)) sorted let toShow = concatMap (\x-> show x ++ "\n") scaled hPutStr stderr toShow main_small = do gen <- getStdGen let xs' = randomRs (1::Int, 100000) gen xs <- return (take big_number xs') t1 <- getCPUTime print (qsort_iv xs) -- iv t2 <- getCPUTime print (sort xs) -- sort t3 <- getCPUTime print (mergeSort xs) -- mergeSort t4 <- getCPUTime print (treeSort xs) -- treeSort t5 <- getCPUTime let getTimes xs = zipWith (-) (tail xs) xs let timers = [t1,t2,t3,t4,t5] let times = getTimes timers let table = zip times ["iv", "sort","mergeSort","treeSort"] let sorted = sort table let scaled = map (\(x,n) -> (((fromIntegral x / (fromIntegral $ fst (head sorted)))::Double),n)) sorted let toShow = concatMap (\x-> show x ++ "\n") scaled hPutStr stderr toShow hPrint stderr times --- cut here --- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080304/3d912e5d/attachment.htm From Ben.Lippmeier at anu.edu.au Mon Mar 3 20:41:13 2008 From: Ben.Lippmeier at anu.edu.au (Ben Lippmeier) Date: Mon Mar 3 20:38:52 2008 Subject: [Haskell-cafe] Annotating GHC assembler output? In-Reply-To: References: Message-ID: <47CCA8B9.5080506@anu.edu.au> Hi Justin. try: ghc -c -ddump-to-file -ddump-asm You should get a .dump.asm file in the same place as which still has symbols named after the source functions. Keep in mind though that the continuation passing style (CPS) conversion done in the back end of GHC causes the code not to look like something you might get out of, say GCC. Ben. Justin Bailey wrote: > I'm interested in seeing what kind of assembler my functions turn > into. Is there a means of annotating assembler output, similar to the > {#- CORE -#} pragma? Is there a trickier way of doing it? > > Justin > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From Ben.Lippmeier at anu.edu.au Mon Mar 3 20:50:28 2008 From: Ben.Lippmeier at anu.edu.au (Ben Lippmeier) Date: Mon Mar 3 20:48:03 2008 Subject: [Haskell-cafe] Annotating GHC assembler output? In-Reply-To: References: Message-ID: <47CCAAE4.1080702@anu.edu.au> And to answer your actual question.. No - notes in the core language get stripped out during conversion to STG. Ben. Justin Bailey wrote: > I'm interested in seeing what kind of assembler my functions turn > into. Is there a means of annotating assembler output, similar to the > {#- CORE -#} pragma? Is there a trickier way of doing it? > > Justin > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From chak at cse.unsw.edu.au Mon Mar 3 21:36:07 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Mon Mar 3 21:33:50 2008 Subject: [Haskell-cafe] Issues(Bugs?) with GHC Type Families In-Reply-To: <7b92c2840803030935t6ed5d2a6ne63d5f8b3d5fe917@mail.gmail.com> References: <7b92c2840803030935t6ed5d2a6ne63d5f8b3d5fe917@mail.gmail.com> Message-ID: Hugo Pacheco: > I have recently tried to replicate some examples from in the > articles about type families but found some possible bugs. > > In [2], the example > > class C a where > type S a (k :: * -> *) :: * > instance C [a] where > type S [a] k = (a,k a) > > does not compile under the claim that the type variable k is not in > scope. > > However, if we extract the type family from the class > > type family S a (k :: * -> *) :: * > type instance S [a] k = (a, k a) > class C a > > it compiles correctly. > According to [3], the difference is purely syntactic sugar, does > that mean that both examples should compile and behave the same or > is there some subtlety that justifies the class example not to > compile? I am sorry for the confusion this causes, but we wrote the paper before the implementation in GHC was finalised. Hence, the implementation deviates from the paper in some aspects. Generally, please use http://haskell.org/haskellwiki/GHC/Type_families (which will be integrated into GHC's Users Manual for 6.10) as the definite guide to the implementation. Here a brief rational for this change in design. We originally intended to distinguish between type parameters that do use type indexing (the a in (S a k)) and those that do not (the k in (S a k)). However, we found later that this leads to implementation problems. The new rule is that any explicitly named parmeters, eg, s and k in type family S a (k :: * -> *) :: * are indexed. If you don't want to use the second parameter as an index, write type S a :: (* -> *) -> * This is also simpler to explain, as simply *all* explicitly named parameters in a type family declaration are indicies. > Another issue is that data kinds (used in both [2] and [3]) do not > seem to be supported at all by the compiler, are they already > implemented in GHC? > > Simple examples such as > > datakind Nat = Zero > or > datakind Nat = Zero | Succ Nat > > fail to compile. No, datakinds aren't supported yet. We still intend to add them, but our first priority is to thoroughly debug the existing functionality and especially to make sure the interaction with GADTs works well. Thanks for the feedback. Manuel From baseballfurlife at gmail.com Mon Mar 3 21:55:03 2008 From: baseballfurlife at gmail.com (adekoba) Date: Mon Mar 3 21:57:35 2008 Subject: [Haskell-cafe] ID3 tagging Message-ID: I was wondering if there are any haskell packages for tagging ID3 frames in mp3 files. Or perhaps if there were any plans for developing them... From dons at galois.com Mon Mar 3 23:07:21 2008 From: dons at galois.com (Don Stewart) Date: Mon Mar 3 23:04:56 2008 Subject: [Haskell-cafe] ID3 tagging In-Reply-To: References: Message-ID: <20080304040721.GA23086@scytale.galois.com> baseballfurlife: > I was wondering if there are any haskell packages for tagging ID3 frames in mp3 > files. Or perhaps if there were any plans for developing them... hpodder includes the ability to write id3 tags, iirc, http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hpodder if you can't find a specific library for it, an id3 binding would make a great introductory haskell programming exercise. -- Don From vigalchin at gmail.com Mon Mar 3 23:56:55 2008 From: vigalchin at gmail.com (Galchin Vasili) Date: Mon Mar 3 23:54:27 2008 Subject: [Haskell-cafe] automagically? Message-ID: <5ae4f2ba0803032056l18979319t384c527a337899b3@mail.gmail.com> Hello, Say i am building package X that depends on A, H, D. How can I automagically check to A, H, D need to "darcs get" down and built/install before X? If this feature is not available it should be, i.e. an integration of darcs and cabal. Regards, Vasya -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080303/757f96cf/attachment.htm From dons at galois.com Mon Mar 3 23:59:21 2008 From: dons at galois.com (Don Stewart) Date: Mon Mar 3 23:56:57 2008 Subject: [Haskell-cafe] automagically? In-Reply-To: <5ae4f2ba0803032056l18979319t384c527a337899b3@mail.gmail.com> References: <5ae4f2ba0803032056l18979319t384c527a337899b3@mail.gmail.com> Message-ID: <20080304045921.GB23086@scytale.galois.com> vigalchin: > Hello, > > Say i am building package X that depends on A, H, D. How can I > automagically check to A, H, D need to "darcs get" down and built/install > before X? If this feature is not available it should be, i.e. an > integration of darcs and cabal. > There are a couple of tools to do this ("searchpath" distributed with HAppS is one such tool). For enterprise Haskell, better to rely on hackage.haskell.org, stable releases of code, and using the "cabal-install" tool to gather and install dependencies. -- Don From alangcarter at gmail.com Tue Mar 4 01:29:24 2008 From: alangcarter at gmail.com (Alan Carter) Date: Tue Mar 4 01:26:57 2008 Subject: [Haskell-cafe] Doubting Haskell In-Reply-To: <2608b8a80802210523v55dd8588n7b10511a1e25d74a@mail.gmail.com> References: <56a54d4d0802161405l774ff97djada856fbccdb8b08@mail.gmail.com> <89ca3d1f0802190648s230c67cet40a9612397dd482f@mail.gmail.com> <56a54d4d0802191727h4a2a64a3xcd532ccf86e5a9a@mail.gmail.com> <89ca3d1f0802200158g5f1b884eua5b4ea5634471d9b@mail.gmail.com> <2608b8a80802210523v55dd8588n7b10511a1e25d74a@mail.gmail.com> Message-ID: <56a54d4d0803032229t6b2456c2ka920d99cd8ef377d@mail.gmail.com> Many thanks for the explanations when I was first experimenting with Haskell. I managed to finish translating a C++ wxWidgets program into Haskell wxHaskell, and am certainly impressed. I've written up some reflections on my newbie experience together with both versions, which might be helpful to people interested in popularizing Haskell, at: http://the-programmers-stone.com/2008/03/04/a-first-haskell-experience/ Regards, Alan -- ... the PA system was moaning unctuously, like a lady hippopotamus reading A. E. Housman ..." -- James Blish, "They Shall Have Stars" From magnus at therning.org Tue Mar 4 03:10:04 2008 From: magnus at therning.org (Magnus Therning) Date: Tue Mar 4 03:07:40 2008 Subject: [Haskell-cafe] CABAL: conditional executable? Message-ID: <47CD03DC.3000402@therning.org> I'm putting together a package consisting of 2 executables. Only one of them is pure Haskell and thus buildable on all platforms, the other relies on Windows API calls and can only be built on that platform. I found the ?if os(...)? conditional in the CABAL docs but I'm having problems getting it to do what I want. if os(mingw32) executable foo ... Results in the error ?Section expected?. Swapping the two lines like this executable foo if os(mingw32) ... results in ?Setup.hs: Error: No 'Main-Is' field found for executable foo?. Is there a way to get CABAL to do what I want or should I raise a feature request on the CABAL trac? /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus?therning?org Jabber: magnus?therning?gmail?com http://therning.org/magnus What if I don't want to obey the laws? Do they throw me in jail with the other bad monads? -- Daveman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080304/6486e72f/signature.bin From nominolo at googlemail.com Tue Mar 4 03:54:55 2008 From: nominolo at googlemail.com (Thomas Schilling) Date: Tue Mar 4 03:52:33 2008 Subject: [Haskell-cafe] CABAL: conditional executable? In-Reply-To: <47CD03DC.3000402@therning.org> References: <47CD03DC.3000402@therning.org> Message-ID: <6D5A5CD1-080A-4874-87DE-6CA4D64B9230@googlemail.com> executable foo main-is: bla if !os(windows): buildable: false Unfortunately this gives rather unhelpful error messages when used with flags, but it works well enough for now. / Thomas On 4 mar 2008, at 09.10, Magnus Therning wrote: > I'm putting together a package consisting of 2 executables. Only > one of > them is pure Haskell and thus buildable on all platforms, the other > relies on Windows API calls and can only be built on that platform. I > found the ?if os(...)? conditional in the CABAL docs but I'm > having > problems getting it to do what I want. > > if os(mingw32) > executable foo > ... > > Results in the error ?Section expected?. Swapping the two lines > like this > > executable foo > if os(mingw32) > ... > > results in ?Setup.hs: Error: No 'Main-Is' field found for > executable foo?. > > Is there a way to get CABAL to do what I want or should I raise a > feature request on the CABAL trac? > > /M > > -- > Magnus Therning (OpenPGP: 0xAB4DFBA4) > magnus?therning?org Jabber: magnus?therning? > gmail?com > http://therning.org/magnus > > What if I don't want to obey the laws? Do they throw me in jail with > the other bad monads? > -- Daveman > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From lemming at henning-thielemann.de Tue Mar 4 04:18:12 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue Mar 4 04:14:36 2008 Subject: [Haskell-cafe] CABAL: conditional executable? In-Reply-To: <47CD03DC.3000402@therning.org> References: <47CD03DC.3000402@therning.org> Message-ID: On Tue, 4 Mar 2008, Magnus Therning wrote: > I'm putting together a package consisting of 2 executables. Only one of > them is pure Haskell and thus buildable on all platforms, the other > relies on Windows API calls and can only be built on that platform. I > found the ???if os(...)??? conditional in the CABAL docs but I'm having > problems getting it to do what I want. > > if os(mingw32) > executable foo > ... > > Results in the error ???Section expected???. Swapping the two lines like this > > executable foo > if os(mingw32) > ... > > results in ???Setup.hs: Error: No 'Main-Is' field found for executable foo???. It sounds like another instance of the case that parts of a package cannot be build under some circumstances. Keep in mind that other packages might rely on the installed second executable if they find that the package is installed. Thus, I guess it's better to extract the second executable to a different package for Window's only stuff. From magnus at therning.org Tue Mar 4 04:58:36 2008 From: magnus at therning.org (Magnus Therning) Date: Tue Mar 4 04:56:09 2008 Subject: [Haskell-cafe] CABAL: conditional executable? In-Reply-To: References: <47CD03DC.3000402@therning.org> Message-ID: On 3/4/08, Henning Thielemann wrote: > > > On Tue, 4 Mar 2008, Magnus Therning wrote: > > > I'm putting together a package consisting of 2 executables. Only one of > > them is pure Haskell and thus buildable on all platforms, the other > > relies on Windows API calls and can only be built on that platform. I > > > found the ? if os(...)? conditional in the CABAL docs but I'm having > > > problems getting it to do what I want. > > > > if os(mingw32) > > executable foo > > ... > > > > > Results in the error ? Section expected? . Swapping the two lines > like this > > > > > executable foo > > if os(mingw32) > > ... > > > > > results in ? Setup.hs: Error: No 'Main-Is' field found for executable > foo? . > > It sounds like another instance of the case that parts of a package cannot > be build under some circumstances. Keep in mind that other packages might > rely on the installed second executable if they find that the package is > installed. Thus, I guess it's better to extract the second executable to a > different package for Window's only stuff. Good point. Does CABAL 1.2 have support for multiple .cabal files in the same directory? If not then I'm not too happy with this solution. /M -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080304/e5112d0b/attachment.htm From nominolo at googlemail.com Tue Mar 4 05:03:05 2008 From: nominolo at googlemail.com (Thomas Schilling) Date: Tue Mar 4 05:00:49 2008 Subject: [Haskell-cafe] CABAL: conditional executable? In-Reply-To: References: <47CD03DC.3000402@therning.org> Message-ID: On 4 mar 2008, at 10.58, Magnus Therning wrote: > > > Good point. Does CABAL 1.2 have support for multiple .cabal files > in the same directory? If not then I'm not too happy with this > solution. No. Eventually, Cabal will support something like this, but it's unlikely that Cabal 1.4 will. From magnus at therning.org Tue Mar 4 05:37:09 2008 From: magnus at therning.org (Magnus Therning) Date: Tue Mar 4 05:34:41 2008 Subject: [Haskell-cafe] CABAL: conditional executable? In-Reply-To: <6D5A5CD1-080A-4874-87DE-6CA4D64B9230@googlemail.com> References: <47CD03DC.3000402@therning.org> <6D5A5CD1-080A-4874-87DE-6CA4D64B9230@googlemail.com> Message-ID: On 3/4/08, Thomas Schilling wrote: > > executable foo > main-is: bla > if !os(windows): > buildable: false > > Unfortunately this gives rather unhelpful error messages when used > with flags, but it works well enough for now. > > / Thomas Hmmm, I don't seem to get this to work the way I want it. I get a "Parse of field 'buildable' failed:" which means configure failed and then I can't proceed to build the second executable, bar, in the same package. /M -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080304/427a7f3c/attachment.htm From paul at cogito.org.uk Tue Mar 4 05:48:34 2008 From: paul at cogito.org.uk (Paul Johnson) Date: Tue Mar 4 05:46:08 2008 Subject: [Haskell-cafe] Doubting Haskell In-Reply-To: <56a54d4d0803032229t6b2456c2ka920d99cd8ef377d@mail.gmail.com> References: <56a54d4d0802161405l774ff97djada856fbccdb8b08@mail.gmail.com> <89ca3d1f0802190648s230c67cet40a9612397dd482f@mail.gmail.com> <56a54d4d0802191727h4a2a64a3xcd532ccf86e5a9a@mail.gmail.com> <89ca3d1f0802200158g5f1b884eua5b4ea5634471d9b@mail.gmail.com> <2608b8a80802210523v55dd8588n7b10511a1e25d74a@mail.gmail.com> <56a54d4d0803032229t6b2456c2ka920d99cd8ef377d@mail.gmail.com> Message-ID: <47CD2902.2070608@cogito.org.uk> Alan Carter wrote: > I've written up some reflections on my newbie experience together with > both versions, which might be helpful to people interested in > popularizing Haskell, at: > > http://the-programmers-stone.com/2008/03/04/a-first-haskell-experience/ > Thank you for writing this. On the lack of simple examples showing, for example, file IO: I seem to recall a Perl book (maybe it was Edition 1 of the Camel Book) which had lots of very short programs each illustrating one typical job. Also the Wiki does have some pages of "worked example" programs. But I agree, we could do better. I'm surprised you found the significant whitespace difficult. Yes, the formal rules are a bit arcane, but I just read them as "does the Right Thing", and it generally works for me. I didn't know about the significance of comments, but then I've never written an outdented comment. I had a look through your code, and although I admit I haven't done the work, I'm sure that there would be ways of factoring out all the commonality and thereby reducing the length. Finally, thanks for that little story about the BBC B. I had one of those, and I always wondered about that heatsink, and the stonking big resistor next to it. They looked out of scale with the rest of the board. Paul. From nominolo at googlemail.com Tue Mar 4 06:08:49 2008 From: nominolo at googlemail.com (Thomas Schilling) Date: Tue Mar 4 06:06:37 2008 Subject: [Haskell-cafe] CABAL: conditional executable? In-Reply-To: References: <47CD03DC.3000402@therning.org> <6D5A5CD1-080A-4874-87DE-6CA4D64B9230@googlemail.com> Message-ID: <889D9BE0-29FC-4F34-A574-7BDD32AF8F11@googlemail.com> On 4 mar 2008, at 11.37, Magnus Therning wrote: > On 3/4/08, Thomas Schilling wrote: > executable foo > main-is: bla > if !os(windows): > buildable: false > > Unfortunately this gives rather unhelpful error messages when used > with flags, but it works well enough for now. > > / Thomas > > Hmmm, I don't seem to get this to work the way I want it. I get a > "Parse of field 'buildable' failed:" which means configure failed > and then I can't proceed to build the second executable, bar, in > the same package. Oh, right. That's a bug in Cabal 1.2 (fixed in HEAD). Use: buildable: False HTH From ketil at malde.org Tue Mar 4 06:16:45 2008 From: ketil at malde.org (Ketil Malde) Date: Tue Mar 4 06:14:12 2008 Subject: [Haskell-cafe] Doubting Haskell In-Reply-To: <47CD2902.2070608@cogito.org.uk> (Paul Johnson's message of "Tue\, 04 Mar 2008 10\:48\:34 +0000") References: <56a54d4d0802161405l774ff97djada856fbccdb8b08@mail.gmail.com> <89ca3d1f0802190648s230c67cet40a9612397dd482f@mail.gmail.com> <56a54d4d0802191727h4a2a64a3xcd532ccf86e5a9a@mail.gmail.com> <89ca3d1f0802200158g5f1b884eua5b4ea5634471d9b@mail.gmail.com> <2608b8a80802210523v55dd8588n7b10511a1e25d74a@mail.gmail.com> <56a54d4d0803032229t6b2456c2ka920d99cd8ef377d@mail.gmail.com> <47CD2902.2070608@cogito.org.uk> Message-ID: <87zlte7n8i.fsf@nmd9999.imr.no> Paul Johnson writes: > I'm surprised you found the significant whitespace difficult. I wonder if this has something to do with the editor one uses? I use Emacs, and just keep hitting TAB, cycling through possible alignments, until things align sensibly. I haven't really tried, but I can imagine lining things up manually would be more painful, especially if mixing tabs and spaces. -k -- If I haven't seen further, it is by standing in the footprints of giants From lrpalmer at gmail.com Tue Mar 4 06:44:56 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Tue Mar 4 06:42:26 2008 Subject: [Haskell-cafe] Doubting Haskell In-Reply-To: <87zlte7n8i.fsf@nmd9999.imr.no> References: <56a54d4d0802161405l774ff97djada856fbccdb8b08@mail.gmail.com> <89ca3d1f0802190648s230c67cet40a9612397dd482f@mail.gmail.com> <56a54d4d0802191727h4a2a64a3xcd532ccf86e5a9a@mail.gmail.com> <89ca3d1f0802200158g5f1b884eua5b4ea5634471d9b@mail.gmail.com> <2608b8a80802210523v55dd8588n7b10511a1e25d74a@mail.gmail.com> <56a54d4d0803032229t6b2456c2ka920d99cd8ef377d@mail.gmail.com> <47CD2902.2070608@cogito.org.uk> <87zlte7n8i.fsf@nmd9999.imr.no> Message-ID: <7ca3f0160803040344r5f9efad5o38ed9204dba30e8a@mail.gmail.com> On Tue, Mar 4, 2008 at 4:16 AM, Ketil Malde wrote: > Paul Johnson writes: > > > I'm surprised you found the significant whitespace difficult. > > I wonder if this has something to do with the editor one uses? I use > Emacs, and just keep hitting TAB, cycling through possible alignments, > until things align sensibly. I haven't really tried, but I can > imagine lining things up manually would be more painful, especially > if mixing tabs and spaces. Especially if mixing tabs and spaces indeed. Haskell does the Python thing of assuming that a tab is 8 spaces, which IMO is a mistake. The sensible thing to do if you have a whitespace-sensitive language that accepts both spaces in tabs is to make them incomparable to each other; i.e. main = do putStrLn $ "Hello" ++ "World" -- compiles fine main = do putStrLn $ "Hello" ++ "World" -- error, can't tell how indented '++ "World"' is... Luke From lemming at henning-thielemann.de Tue Mar 4 09:04:01 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue Mar 4 09:00:24 2008 Subject: [Haskell-cafe] Markup bug in HaskellWiki Message-ID: In the Wiki article http://haskell.org/haskellwiki/Comparison_chain there is the piece unzip">unzip which is improperly formatted. From dougal at dougalstanton.net Tue Mar 4 10:10:19 2008 From: dougal at dougalstanton.net (Dougal Stanton) Date: Tue Mar 4 10:07:54 2008 Subject: [Haskell-cafe] Markup bug in HaskellWiki In-Reply-To: References: Message-ID: <2d3641330803040710u4b2a2951wbfc84c5f05b0330a@mail.gmail.com> On 04/03/2008, Henning Thielemann wrote: > > In the Wiki article > > http://haskell.org/haskellwiki/Comparison_chain > > there is the piece > > unzip">unzip > > which is improperly formatted. I guess the wiki uses GeSHi, and it's because of a bug in the keyword list. I reported it to the maintainer a few weeks ago (when I wrote this [1]) but I haven't heard any word back. It's dead easy to fix if someone has access to the PHP source. There's a file called, IIRC, haskell.php with a large list of keywords. Two of them, 'unzip' and 'unzip3' appear twice. Delete one of each and it all works fine again. [1] -- Dougal Stanton dougal@dougalstanton.net // http://www.dougalstanton.net From p.f.moore at gmail.com Tue Mar 4 10:18:46 2008 From: p.f.moore at gmail.com (Paul Moore) Date: Tue Mar 4 10:16:17 2008 Subject: [Haskell-cafe] Doubting Haskell In-Reply-To: <56a54d4d0803032229t6b2456c2ka920d99cd8ef377d@mail.gmail.com> References: <56a54d4d0802161405l774ff97djada856fbccdb8b08@mail.gmail.com> <89ca3d1f0802190648s230c67cet40a9612397dd482f@mail.gmail.com> <56a54d4d0802191727h4a2a64a3xcd532ccf86e5a9a@mail.gmail.com> <89ca3d1f0802200158g5f1b884eua5b4ea5634471d9b@mail.gmail.com> <2608b8a80802210523v55dd8588n7b10511a1e25d74a@mail.gmail.com> <56a54d4d0803032229t6b2456c2ka920d99cd8ef377d@mail.gmail.com> Message-ID: <79990c6b0803040718q507f84a2gd8692bb4038be73a@mail.gmail.com> On 04/03/2008, Alan Carter wrote: > http://the-programmers-stone.com/2008/03/04/a-first-haskell-experience/ That was an interesting read. Thanks for posting it. I also liked the tale of the BBC ULA - it reminded me of a demo I saw once at an Acorn show, where they had a RISC PC on show, with a (IBM) PC card in it. They were demonstrating how hot the PC chip runs compared to the ARM RISC chip by using it to make toast. I dread to think what you could do with one of today's monsters :-) Paul. From bjorn at bringert.net Tue Mar 4 10:31:41 2008 From: bjorn at bringert.net (Bjorn Bringert) Date: Tue Mar 4 10:29:18 2008 Subject: [Haskell-cafe] Connection helpers: for people interested in network code In-Reply-To: <396556a20802291150y683a8ca5q1065e87a48b6e518@mail.gmail.com> References: <396556a20802291150y683a8ca5q1065e87a48b6e518@mail.gmail.com> Message-ID: On Fri, Feb 29, 2008 at 8:50 PM, Adam Langley wrote: > I generally find that I'm wrapping sockets in the same functions a lot > and now I'm looking writings code which works with both Sockets and > SSL connections. So I wrote a module, presumptuously called > Network.Connection, although I'm not actually going to try and take > that name (even in Hackage) unless I get a general agreement that this > is a good thing. > > So, any comments on the interface, similar things that I should look at etc? > > http://www.imperialviolet.org/binary/network-connection/Network-Connection.html > > I made the BaseConnection an ADT, rather than a class because I wanted > to avoid hitting the monomorphism restriction in code. That might have > been a mistake, I'm not sure yet. > > If it doesn't excite anyone enough to reply, I'll change the name and > put it in Hackage, mostly as is. Then I'll tie HsOpenSSL into it so > that SSL connections work transparently. Hi Adam, you may want to have a look at the socket abstraction used in the HTTP package: http://hackage.haskell.org/packages/archive/HTTP/3001.0.4/doc/html/Network-Stream.html It would be great to get HTTPS support going! /Bjorn From vikrant.patil at gmail.com Tue Mar 4 10:45:47 2008 From: vikrant.patil at gmail.com (Vikrant) Date: Tue Mar 4 10:43:19 2008 Subject: [Haskell-cafe] problem in using wash Message-ID: Hi, I was trying to use wash to learn it. I am using ubuntu and I have ghc6.6.1 installed on my system. I have also installed the package libghc6-wash-dev but in my code when i write "import WASH.CGI" it gives me following error firstCGI.hs:5:7: Could not find module `WASH.CGI': locations searched: WASH/CGI.hs WASH/CGI.lhs Failed, modules loaded: none. can somebody help me in this? Regards, Vikrant -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080304/dc5afef4/attachment.htm From agl at imperialviolet.org Tue Mar 4 11:15:24 2008 From: agl at imperialviolet.org (Adam Langley) Date: Tue Mar 4 11:12:56 2008 Subject: [Haskell-cafe] Connection helpers: for people interested in network code In-Reply-To: References: <396556a20802291150y683a8ca5q1065e87a48b6e518@mail.gmail.com> Message-ID: <396556a20803040815i13c70459gdcaf4b1469403f13@mail.gmail.com> On Tue, Mar 4, 2008 at 7:31 AM, Bjorn Bringert wrote: > you may want to have a look at the socket abstraction used in the HTTP package: > > http://hackage.haskell.org/packages/archive/HTTP/3001.0.4/doc/html/Network-Stream.html > > It would be great to get HTTPS support going! I should have mentioned that I had seen this in the original email. I think the major problem with this interface was that it was written in the time before ByteStrings. Now that we have ByteStrings I think that it makes a lot of sense for networking to use them. However, it shouldn't be too hard to wrap HsOpenSSL in this interface. I might try this this week. Then HTTPS should Just Work (maybe ;) AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org From g9ks157k at acme.softbase.org Tue Mar 4 11:15:37 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Tue Mar 4 11:14:14 2008 Subject: [Haskell-cafe] Markup bug in HaskellWiki In-Reply-To: <2d3641330803040710u4b2a2951wbfc84c5f05b0330a@mail.gmail.com> References: <2d3641330803040710u4b2a2951wbfc84c5f05b0330a@mail.gmail.com> Message-ID: <200803041715.37919.g9ks157k@acme.softbase.org> Am Dienstag, 4. M?rz 2008 16:10 schrieb Dougal Stanton: > [?] > There's a file called, IIRC, haskell.php with a large list of > keywords. Two of them, 'unzip' and 'unzip3' appear twice. Delete one > of each and it all works fine again. Why do they appear at all? They are not keywords. Best wishes, Wolfgang From cgibbard at gmail.com Tue Mar 4 11:21:15 2008 From: cgibbard at gmail.com (Cale Gibbard) Date: Tue Mar 4 11:18:47 2008 Subject: [Haskell-cafe] Doubting Haskell In-Reply-To: <7ca3f0160803040344r5f9efad5o38ed9204dba30e8a@mail.gmail.com> References: <56a54d4d0802161405l774ff97djada856fbccdb8b08@mail.gmail.com> <89ca3d1f0802190648s230c67cet40a9612397dd482f@mail.gmail.com> <56a54d4d0802191727h4a2a64a3xcd532ccf86e5a9a@mail.gmail.com> <89ca3d1f0802200158g5f1b884eua5b4ea5634471d9b@mail.gmail.com> <2608b8a80802210523v55dd8588n7b10511a1e25d74a@mail.gmail.com> <56a54d4d0803032229t6b2456c2ka920d99cd8ef377d@mail.gmail.com> <47CD2902.2070608@cogito.org.uk> <87zlte7n8i.fsf@nmd9999.imr.no> <7ca3f0160803040344r5f9efad5o38ed9204dba30e8a@mail.gmail.com> Message-ID: <89ca3d1f0803040821v2a679207vbbc6e748bcffcc79@mail.gmail.com> On 04/03/2008, Luke Palmer wrote: > On Tue, Mar 4, 2008 at 4:16 AM, Ketil Malde wrote: > > Paul Johnson writes: > > > > > I'm surprised you found the significant whitespace difficult. > > > > I wonder if this has something to do with the editor one uses? I use > > Emacs, and just keep hitting TAB, cycling through possible alignments, > > until things align sensibly. I haven't really tried, but I can > > imagine lining things up manually would be more painful, especially > > if mixing tabs and spaces. > > > Especially if mixing tabs and spaces indeed. Haskell does the Python > thing of assuming that a tab is 8 spaces, which IMO is a mistake. The > sensible thing to do if you have a whitespace-sensitive language that > accepts both spaces in tabs is to make them incomparable to each > other; i.e. I honestly think that tab characters occurring anywhere but in a comment should be considered a lexical error and rejected by the compiler outright. More problems are caused by trying to continue with only tabs, or some mixture of tabs and spaces than just getting one's editor to expand tabs automatically. - Cale From jgbailey at gmail.com Tue Mar 4 11:28:20 2008 From: jgbailey at gmail.com (Justin Bailey) Date: Tue Mar 4 11:25:53 2008 Subject: [Haskell-cafe] Annotating GHC assembler output? In-Reply-To: <47CCA8B9.5080506@anu.edu.au> References: <47CCA8B9.5080506@anu.edu.au> Message-ID: On Mon, Mar 3, 2008 at 5:41 PM, Ben Lippmeier wrote: > Hi Justin. > > try: ghc -c -ddump-to-file -ddump-asm > Thanks, that does it. I also tried the -keep-s-files (possibly new to 6.8) and found it produces the same output. Justin From lemming at henning-thielemann.de Tue Mar 4 11:28:39 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue Mar 4 11:26:17 2008 Subject: [Haskell-cafe] Markup bug in HaskellWiki In-Reply-To: <200803041715.37919.g9ks157k@acme.softbase.org> References: <2d3641330803040710u4b2a2951wbfc84c5f05b0330a@mail.gmail.com> <200803041715.37919.g9ks157k@acme.softbase.org> Message-ID: On Tue, 4 Mar 2008, Wolfgang Jeltsch wrote: > Am Dienstag, 4. M?rz 2008 16:10 schrieb Dougal Stanton: > > [?] > > > There's a file called, IIRC, haskell.php with a large list of > > keywords. Two of them, 'unzip' and 'unzip3' appear twice. Delete one > > of each and it all works fine again. > > Why do they appear at all? They are not keywords. They link to the online Haddock documentation of Prelude. From dougal at dougalstanton.net Tue Mar 4 12:03:59 2008 From: dougal at dougalstanton.net (Dougal Stanton) Date: Tue Mar 4 12:01:33 2008 Subject: [Haskell-cafe] Markup bug in HaskellWiki In-Reply-To: <200803041715.37919.g9ks157k@acme.softbase.org> References: <2d3641330803040710u4b2a2951wbfc84c5f05b0330a@mail.gmail.com> <200803041715.37919.g9ks157k@acme.softbase.org> Message-ID: <2d3641330803040903w424270bck84072070b4e449bd@mail.gmail.com> On 04/03/2008, Wolfgang Jeltsch wrote: > Am Dienstag, 4. M?rz 2008 16:10 schrieb Dougal Stanton: > > [?] > > > > There's a file called, IIRC, haskell.php with a large list of > > keywords. Two of them, 'unzip' and 'unzip3' appear twice. Delete one > > of each and it all works fine again. > > > Why do they appear at all? They are not keywords. Well, keywords is a bit of a misnomer. Geshi isn't very smart, it just recognises the standard prelude and adds in links to the online API. D -- Dougal Stanton dougal@dougalstanton.net // http://www.dougalstanton.net From devriese at cs.tcd.ie Tue Mar 4 12:16:40 2008 From: devriese at cs.tcd.ie (Edsko de Vries) Date: Tue Mar 4 12:14:11 2008 Subject: [Haskell-cafe] Functional programmer's intuition for adjunctions? Message-ID: <20080304171640.GC32511@netsoc.tcd.ie> Hi, Is there an intuition that can be used to explain adjunctions to functional programmers, even if the match isn't necessary 100% perfect (like natural transformations and polymorphic functions?). Thanks, Edsko From chaddai.fouche at gmail.com Tue Mar 4 12:47:27 2008 From: chaddai.fouche at gmail.com (=?ISO-8859-1?Q?Chadda=EF_Fouch=E9?=) Date: Tue Mar 4 12:45:02 2008 Subject: [Haskell-cafe] (flawed?) benchmark : sort In-Reply-To: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> Message-ID: 2008/3/4, Krzysztof Skrz?tnicki : > Hi > > I was playing with various versions of sorting algorithms. I know it's very > easy to create flawed benchmark and I don't claim those are good ones. > However, it really seems strange to me, that sort - library function - is > actually the worse measured function. I can hardly belive it, and I'd rather > say I have made a mistake preparing it. > > The overall winner seems to be qsort_iv - which is nothing less but old sort > replaced by mergesort now. > > Any clues? Part of what you may be missing : -- cut here -- module Main where import Control.Parallel.Strategies import Control.Arrow import System.CPUTime import System.IO import System.Environment import System.Random import Data.List( partition, sort ) data Tree a = Node (Tree a) a (Tree a) | Leaf qsort_i [] = [] qsort_i (x:xs) = qsort_i (filter (< x) xs) ++ [x] ++ qsort_i (filter (>= x) xs) qsort_ii [] = [] qsort_ii (x:xs) = let (ls,gt) = partition (< x) xs in qsort_ii ls ++ [x] ++ qsort_ii gt qsort_iii xs = qsort_iii' [] xs qsort_iii' acc [] = acc qsort_iii' acc (x:xs) = let (ls,gt) = partition (< x) xs in let acc' = (x:(qsort_iii' acc gt)) in qsort_iii' acc' ls qsort_v [] = [] qsort_v (x:xs) = let (xlt, xgt ) = foldl (\ (lt,gt) el -> case compare x el of GT -> (el:lt, gt) _ -> (lt, el:gt) ) ([],[]) xs in qsort_v xlt ++ [x] ++ qsort_v xgt -- zmodyfikowany i qsort_vi [] = [] qsort_vi (x:xs) = qsort_vi (filter (\y-> compare x y == GT) xs) ++ [x] ++ qsort_vi (filter (\y-> compare x y /= GT) xs) -- zmodyfikowany iii qsort_vii xs = qsort_vii' [] xs qsort_vii' acc [] = acc qsort_vii' acc (x:xs) = let (ls,gt) = partition (\y-> compare x y == GT) xs in let acc' = (x:(qsort_vii' acc gt)) in qsort_vii' acc' ls -- qsort is stable and does not concatenate. qsort_iv xs = qsort_iv' (compare) xs [] qsort_iv' _ [] r = r qsort_iv' _ [x] r = x:r qsort_iv' cmp (x:xs) r = qpart cmp x xs [] [] r -- qpart partitions and sorts the sublists qpart cmp x [] rlt rge r = -- rlt and rge are in reverse order and must be sorted with an -- anti-stable sorting rqsort_iv' cmp rlt (x:rqsort_iv' cmp rge r) qpart cmp x (y:ys) rlt rge r = case cmp x y of GT -> qpart cmp x ys (y:rlt) rge r _ -> qpart cmp x ys rlt (y:rge) r -- rqsort is as qsort but anti-stable, i.e. reverses equal elements rqsort_iv' _ [] r = r rqsort_iv' _ [x] r = x:r rqsort_iv' cmp (x:xs) r = rqpart cmp x xs [] [] r rqpart cmp x [] rle rgt r = qsort_iv' cmp rle (x:qsort_iv' cmp rgt r) rqpart cmp x (y:ys) rle rgt r = case cmp y x of GT -> rqpart cmp x ys rle (y:rgt) r _ -> rqpart cmp x ys (y:rle) rgt r -- code by Orcus -- Zadanie 9 - merge sort mergeSort :: Ord a => [a] -> [a] mergeSort [] = [] mergeSort [x] = [x] mergeSort xs = let(l, r) = splitAt (length xs `quot` 2) xs in mergeSortP (mergeSort l) (mergeSort r) -- funkcja pomocnicza scalaj??ca dwie listy uporz??dkowane w jedn?? mergeSortP :: Ord a => [a] -> [a] -> [a] mergeSortP xs [] = xs mergeSortP [] ys = ys mergeSortP (x:xs) (y:ys) | x <= y = x:(mergeSortP xs (y:ys)) | otherwise = y:(mergeSortP (x:xs) ys) -- Zadanie 10 - tree sort treeSort :: Ord a => [a] -> [a] -- pointless po raz drugi treeSort = (treeSortInorder . treeSortToTree) treeSortToTree :: Ord a => [a] -> Tree a treeSortToTree [] = Leaf treeSortToTree (x:xs) = let (xlt, xgt) = foldl (\ (lt,gt) el -> case compare x el of GT -> (el:lt, gt) _ -> (lt, el:gt) ) ([],[]) xs in Node (treeSortToTree xlt) x (treeSortToTree xgt) treeSortInorder :: Ord a => Tree a -> [a] treeSortInorder Leaf = [] treeSortInorder (Node l x r) = (treeSortInorder l) ++ [x] ++ (treeSortInorder r) -- end code by Orcus -- begin benchmark making code makeBenchs benchs xs = do let (funcNames, funcs) = unzip benchs tBegin <- getCPUTime timers <- mapM (\f-> print (f xs) >> getCPUTime) funcs let times = zipWith (-) timers (tBegin:timers) sortedResults = sort $ zip times funcNames minT = fromIntegral $ fst $ head sortedResults scaled = map (((/minT) . fromIntegral) *** id) sortedResults hPutStr stderr $ unlines $ map show scaled onRandom eltCnt = do gen <- getStdGen let xs = take eltCnt (randomRs (1::Int, bigNum) gen) `using` rnf xs `seq` return xs onSorted eltCnt = do gen <- getStdGen let xs = take eltCnt (randomRs (1::Int, bigNum) gen) `using` rnf sxs = sort xs `using` rnf xs `seq` sxs `seq` return sxs bigNum = 1000000 :: Int -- end of benchmark making code main = makeBenchs [("i",qsort_i), ("ii",qsort_ii), ("iii",qsort_iii), ("iv",qsort_iv), ("v",qsort_v), ("vi",qsort_vi), ("vii",qsort_vii), ("sort",sort), ("mergeSort",mergeSort), ("treeSort",treeSort)] =<< onSorted . read . head =<< getArgs -- cut here -- It could probably be improved (with classics solution (better selection of the pivot...)), but the mergesort is only 3 times slower in worse case, and much more regular, if someone needs a faster sort in a specific case, it isn't hard to code. -- Jeda? From ndmitchell at gmail.com Tue Mar 4 12:54:21 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Tue Mar 4 12:51:51 2008 Subject: [Haskell-cafe] (flawed?) benchmark : sort In-Reply-To: References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> Message-ID: <404396ef0803040954uac20b35ua55aa7510ac07e21@mail.gmail.com> Hi > -- Zadanie 9 - merge sort > mergeSort :: Ord a => [a] -> [a] > mergeSort [] = [] > mergeSort [x] = [x] > mergeSort xs = let(l, r) = splitAt (length xs `quot` 2) xs > in mergeSortP (mergeSort l) (mergeSort r) splitAt is not a particularly good way to split a list, since you recurse over the list twice. Try instead: split (x:xs) = (x:b,a) where (a,b) = split xs split [] = ([], []) Perhaps adding some strictness annotations and turning the where into a case. Also remember that a standard benchmark for sorting is an ordered/reverse ordered list, as that causes quicksort to go to O(n^2) given a bad pivot choice. If the sort in the standard libraries can be improved on, it should be replaced. Thanks Neil From derek.a.elkins at gmail.com Tue Mar 4 12:58:38 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Tue Mar 4 12:56:20 2008 Subject: [Haskell-cafe] Functional programmer's intuition for adjunctions? In-Reply-To: <20080304171640.GC32511@netsoc.tcd.ie> References: <20080304171640.GC32511@netsoc.tcd.ie> Message-ID: <1204653519.5706.13.camel@derek-laptop> On Tue, 2008-03-04 at 17:16 +0000, Edsko de Vries wrote: > Hi, > > Is there an intuition that can be used to explain adjunctions to > functional programmers, even if the match isn't necessary 100% perfect > (like natural transformations and polymorphic functions?). Well when you pretend Hask is Set, many things can be discussed fairly directly. F is left adjoint to U, F -| U, if Hom(FA,B) is naturally isomorphic to Hom(A,UB), natural in A and B. A natural transformation over Set is just a polymorphic function. So we have an adjunction if we have two functions: phi :: (F a -> b) -> (a -> U b) and phiInv :: (a -> U b) -> (F a -> b) such that phi . phiInv = id and phiInv . phi = id and F and U are instances of Functor. The unit and counit respectively is then just phi id and phiInv id. You can work several examples using this framework, though it gets difficult when it is difficult to model other categories. Also discussing and proving some properties of adjunctions (namely continuity properties) would help. Of course, this is a concrete example using basic ideas of programming and not some "intuitive analogy". I feel comfortable working with adjunctions, but I don't have some general analogy that I use. From devriese at cs.tcd.ie Tue Mar 4 13:30:05 2008 From: devriese at cs.tcd.ie (Edsko de Vries) Date: Tue Mar 4 13:28:07 2008 Subject: [Haskell-cafe] Functional programmer's intuition for adjunctions? In-Reply-To: <1204653519.5706.13.camel@derek-laptop> References: <20080304171640.GC32511@netsoc.tcd.ie> <1204653519.5706.13.camel@derek-laptop> Message-ID: <20080304183005.GA29033@netsoc.tcd.ie> On Tue, Mar 04, 2008 at 11:58:38AM -0600, Derek Elkins wrote: > On Tue, 2008-03-04 at 17:16 +0000, Edsko de Vries wrote: > > Hi, > > > > Is there an intuition that can be used to explain adjunctions to > > functional programmers, even if the match isn't necessary 100% perfect > > (like natural transformations and polymorphic functions?). > > Well when you pretend Hask is Set, many things can be discussed fairly > directly. > > F is left adjoint to U, F -| U, if Hom(FA,B) is naturally isomorphic to > Hom(A,UB), natural in A and B. A natural transformation over Set is > just a polymorphic function. So we have an adjunction if we have two > functions: > > phi :: (F a -> b) -> (a -> U b) > and > phiInv :: (a -> U b) -> (F a -> b) > > such that phi . phiInv = id and phiInv . phi = id and F and U are > instances of Functor. > > The unit and counit respectively is then just phi id and phiInv id. Sure, but that doesn't really explain what an adjunction *is*. For me, it helps to think of a natural transformation as a polymorphic function: it gives me an intuition about what a natural transformation is. Specializing the definition of an adjunction for Hask (or Set) helps understanding the *definitions*, but not the *intention*, if that makes any sense.. Edsko From miguelimo38 at yandex.ru Tue Mar 4 13:45:59 2008 From: miguelimo38 at yandex.ru (Miguel Mitrofanov) Date: Tue Mar 4 13:43:42 2008 Subject: [Haskell-cafe] Functional programmer's intuition for adjunctions? In-Reply-To: <20080304183005.GA29033@netsoc.tcd.ie> References: <20080304171640.GC32511@netsoc.tcd.ie> <1204653519.5706.13.camel@derek-laptop> <20080304183005.GA29033@netsoc.tcd.ie> Message-ID: <4014B004-2644-43A9-95D0-14508A3454B0@yandex.ru> Well, we have at least one very useful example of adjunction. It's called "curry". See, if X is some arbitrary type, you can define type F = (,X) instance Functor F where fmap f (a,x) = (fa,x) type G = (->) X instance Functor G where fmap f h = \x -> f (h x) Now, we have the adjunction: phi :: ((a,X) -> b) -> (a -> (X -> b)) phi = curry phiInv :: (a -> (X -> b)) -> ((a,X) -> b) phiInv = uncurry On 4 Mar 2008, at 21:30, Edsko de Vries wrote: > On Tue, Mar 04, 2008 at 11:58:38AM -0600, Derek Elkins wrote: >> On Tue, 2008-03-04 at 17:16 +0000, Edsko de Vries wrote: >>> Hi, >>> >>> Is there an intuition that can be used to explain adjunctions to >>> functional programmers, even if the match isn't necessary 100% >>> perfect >>> (like natural transformations and polymorphic functions?). >> >> Well when you pretend Hask is Set, many things can be discussed >> fairly >> directly. >> >> F is left adjoint to U, F -| U, if Hom(FA,B) is naturally >> isomorphic to >> Hom(A,UB), natural in A and B. A natural transformation over Set is >> just a polymorphic function. So we have an adjunction if we have two >> functions: >> >> phi :: (F a -> b) -> (a -> U b) >> and >> phiInv :: (a -> U b) -> (F a -> b) >> >> such that phi . phiInv = id and phiInv . phi = id and F and U are >> instances of Functor. >> >> The unit and counit respectively is then just phi id and phiInv id. > > Sure, but that doesn't really explain what an adjunction *is*. For me, > it helps to think of a natural transformation as a polymorphic > function: > it gives me an intuition about what a natural transformation is. > Specializing the definition of an adjunction for Hask (or Set) helps > understanding the *definitions*, but not the *intention*, if that > makes > any sense.. > > Edsko > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From qdunkan at gmail.com Tue Mar 4 13:52:52 2008 From: qdunkan at gmail.com (Evan Laforge) Date: Tue Mar 4 13:50:23 2008 Subject: [Haskell-cafe] Doubting Haskell In-Reply-To: <7ca3f0160803040344r5f9efad5o38ed9204dba30e8a@mail.gmail.com> References: <56a54d4d0802161405l774ff97djada856fbccdb8b08@mail.gmail.com> <89ca3d1f0802190648s230c67cet40a9612397dd482f@mail.gmail.com> <56a54d4d0802191727h4a2a64a3xcd532ccf86e5a9a@mail.gmail.com> <89ca3d1f0802200158g5f1b884eua5b4ea5634471d9b@mail.gmail.com> <2608b8a80802210523v55dd8588n7b10511a1e25d74a@mail.gmail.com> <56a54d4d0803032229t6b2456c2ka920d99cd8ef377d@mail.gmail.com> <47CD2902.2070608@cogito.org.uk> <87zlte7n8i.fsf@nmd9999.imr.no> <7ca3f0160803040344r5f9efad5o38ed9204dba30e8a@mail.gmail.com> Message-ID: <2518b95d0803041052g882a9edxd1898c6487722323@mail.gmail.com> > Especially if mixing tabs and spaces indeed. Haskell does the Python > thing of assuming that a tab is 8 spaces, which IMO is a mistake. The FWIW, most people in python land think the same thing, and the -t flag makes mixed tabs and spaces a warning or error. At the least, -Wall could report mixed usage. At the most, make it an error. From dominic.steinitz at blueyonder.co.uk Tue Mar 4 14:01:16 2008 From: dominic.steinitz at blueyonder.co.uk (Dominic Steinitz) Date: Tue Mar 4 13:59:00 2008 Subject: [Haskell-cafe] Re: Functional programmer's intuition for adjunctions? References: <20080304171640.GC32511@netsoc.tcd.ie> <1204653519.5706.13.camel@derek-laptop> <20080304183005.GA29033@netsoc.tcd.ie> <4014B004-2644-43A9-95D0-14508A3454B0@yandex.ru> Message-ID: > Well, we have at least one very useful example of adjunction. It's > called "curry". See, if X is some arbitrary type, you can define > This adjunction is the one that makes a category cartesian closed. Dominic. From mlandman at face2interface.com Tue Mar 4 14:06:59 2008 From: mlandman at face2interface.com (Marty Landman) Date: Tue Mar 4 14:04:54 2008 Subject: [Haskell-cafe] Haskell & Perl architecture question Message-ID: <20080304190452.A0499324333@www.haskell.org> I'm looking at a production system running Perl & Haskell in an Apache environment and trying to get a handle on the system architecture. Are there online resources anyone could recommend I start with? Thanks in advance, Marty -- Marty Landman, Face 2 Interface Inc. 845-679-9387 Drupal Development Blog: http://drupal.face2interface.com/ Free Database Search App: http://face2interface.com/Products/FormATable.shtml From dpiponi at gmail.com Tue Mar 4 16:24:34 2008 From: dpiponi at gmail.com (Dan Piponi) Date: Tue Mar 4 16:22:04 2008 Subject: [Haskell-cafe] Functional programmer's intuition for adjunctions? In-Reply-To: <20080304171640.GC32511@netsoc.tcd.ie> References: <20080304171640.GC32511@netsoc.tcd.ie> Message-ID: <625b74080803041324t42d392f8uff4f09c4da9e1df5@mail.gmail.com> Edsko asked: > Is there an intuition that can be used to explain adjunctions to > functional programmers, even if the match isn't necessary 100% perfect > (like natural transformations and polymorphic functions?). I think there's a catch because many interesting examples of adjunctions involve multiple distinct categories. So there's a sense in which you have to go outside of programming to explain what they are, apart from a few simple examples like currying. But if you're familiar with the category of monoids and monoid homomorphisms, then we can generate another example: One intuition is the notion of trying to approximate an object in one category using objects in another. For example, consider the category of monoids. How best can we approximate an arbitrary type in a monoid? Suppose our type, T, has elements a,b and c. We could try to represent this as a monoid. But monoids should have products and an identity. So if the monoid contains a,b and c it should also contain 1, ab, bc, abcba and so on. And what should ab equal? Might it be the same as bc? The simplest strategy is to assume that all of these products are distinct and approximate the type T with the monoid containing 1, a, b and c and assuming no element equals any other unless the monoid laws say so (ie. 1a=a1=a). This is called the *f*ree monoid generated by T, and we can write it F(T). Now go the other way: given a monoid, S, how can we map it back to a type? There's an obvious idea, just make a type whose elements are the *u*nderlying elements of the monoid, discarding the multiplication rule. Call this U(S). (We're treating Hask like Set here.) So what's U(F(T))? T gets mapped to the free monoid generated by T, and mapped back to the elements of this monoid. In other words, the elements of U(F(T)) are (possibly non-empty) strings of elements of T. So UF is the list type constructor. Any homomorphism, f, between monoids is completely determined once you know where a set of generators of the monoid map under the homomorphism, and vice versa. All of the other elements can be deduced using f(1) = 1 and f(xy)=f(x)f(y). So if F(a) is the free monoid generated by a, then a homomorphism F(a)->b is completely determined by a function a->U(b), and vice versa. We have an isomorphism (F(a)->b) <-> (a->U(b)) and (F,U) forms an adjunction, according to Derek's definition. So intuitively, what's going on is that Haskell lists emerge as a result of an attempt to approximate types with monoids and adjunctions formalise what we mean by 'approximation'. When we go from a type, to a monoid, and back again, we don't end up where we started, but at a new type. Other adjunctions can be seen in this way. But because different examples use different categories, it's hard to picture a uniform way of viewing adjunctions that spans them all. It's also no coincidence now that lists form a monad... -- Dan From hjgtuyl at chello.nl Tue Mar 4 17:01:43 2008 From: hjgtuyl at chello.nl (hjgtuyl@chello.nl) Date: Tue Mar 4 16:59:13 2008 Subject: [Haskell-cafe] Doubting Haskell In-Reply-To: <56a54d4d0803032229t6b2456c2ka920d99cd8ef377d@mail.gmail.com> References: <56a54d4d0802161405l774ff97djada856fbccdb8b08@mail.gmail.com> <89ca3d1f0802190648s230c67cet40a9612397dd482f@mail.gmail.com> <56a54d4d0802191727h4a2a64a3xcd532ccf86e5a9a@mail.gmail.com> <89ca3d1f0802200158g5f1b884eua5b4ea5634471d9b@mail.gmail.com> <2608b8a80802210523v55dd8588n7b10511a1e25d74a@mail.gmail.com> <56a54d4d0803032229t6b2456c2ka920d99cd8ef377d@mail.gmail.com> Message-ID: About the line length needed for Haskell programs, there was a discussion about this some time ago, that could be regarded as a tutorial for reducing indentation: http://haskell.org/pipermail/haskell-cafe/2007-July/028787.html As for the idle core you mention: I keep one core fully occupied with a program that searches for a cure against cancer, see: http://www.computeagainstcancer.org/ The example you gave for the use of "map" can be simplified: map func (take (10 [0..])) -- should actually be: map func (take 10 [0..]) -> map func [0..9] Regards, Henk-Jan van Tuyl -- http://functor.bamikanarie.com http://Van.Tuyl.eu/ -- On Tue, 04 Mar 2008 07:29:24 +0100, Alan Carter wrote: > Many thanks for the explanations when I was first experimenting with > Haskell. I managed to finish translating a C++ wxWidgets program into > Haskell wxHaskell, and am certainly impressed. > > I've written up some reflections on my newbie experience together with > both versions, which might be helpful to people interested in > popularizing Haskell, at: > > http://the-programmers-stone.com/2008/03/04/a-first-haskell-experience/ > > Regards, > > Alan > -- -- Met vriendelijke groet, Henk-Jan van Tuyl -- http://functor.bamikanarie.com http://Van.Tuyl.eu/ -- From s.clover at gmail.com Tue Mar 4 17:20:43 2008 From: s.clover at gmail.com (Sterling Clover) Date: Tue Mar 4 17:18:14 2008 Subject: [Haskell-cafe] Haskell & Perl architecture question In-Reply-To: <20080304190452.A0499324333@www.haskell.org> References: <20080304190452.A0499324333@www.haskell.org> Message-ID: Not quite sure what you're looking for? Do you mean that you're looking at the possibility of setting such a system up, or that you're looking at a system that is already set up and trying to grok how it works? If the latter, you might want to get a sense of how ghc manages its packages and dependencies at http://www.haskell.org/ghc/docs/latest/html/users_guide/packages.html, which also includes links to the information on the cabal infrastructure. If that's not your question, then that material might either be too basic for you or too offbase. The GHC manual is generally very well documented in terms of describing package infrastructure, the linking process and the runtime environment, etc. If, rather, you're looking at issues more directly related to Haskell/web stuff, you might want to specify what exactly you're looking to do, as there are a number of solutions in use rather than a single, e.g., mod_haskell. If it's an established system, then either it will be using a haskell webserver (WASH, HAppS, etc) or it will be written using the CGI/FastCGI libraries. If you're looking to set up a system, then of course it depends what you want to do with it... for lightweight solutions, a combination of FastCGI and HDBC seems to be pretty popular at the moment. In all these cases, note that generally you'll be working with Haskell binaries, rather than scripts, and that such binaries should either be built on the system in question directly, or on one with the same architecture. Hope that helps, Sterl. On Tue, Mar 4, 2008 at 2:06 PM, Marty Landman wrote: > I'm looking at a production system running Perl & Haskell in an > Apache environment and trying to get a handle on the system > architecture. Are there online resources anyone could recommend I start > with? > > Thanks in advance, > Marty > > > -- > Marty Landman, Face 2 Interface Inc. 845-679-9387 > Drupal Development Blog: http://drupal.face2interface.com/ > Free Database Search App: > http://face2interface.com/Products/FormATable.shtml > > _______________________________________________ > 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/20080304/48779b6b/attachment.htm From chaddai.fouche at gmail.com Tue Mar 4 17:30:00 2008 From: chaddai.fouche at gmail.com (=?ISO-8859-1?Q?Chadda=EF_Fouch=E9?=) Date: Tue Mar 4 17:27:30 2008 Subject: [Haskell-cafe] Doubting Haskell In-Reply-To: <56a54d4d0803032229t6b2456c2ka920d99cd8ef377d@mail.gmail.com> References: <56a54d4d0802161405l774ff97djada856fbccdb8b08@mail.gmail.com> <89ca3d1f0802190648s230c67cet40a9612397dd482f@mail.gmail.com> <56a54d4d0802191727h4a2a64a3xcd532ccf86e5a9a@mail.gmail.com> <89ca3d1f0802200158g5f1b884eua5b4ea5634471d9b@mail.gmail.com> <2608b8a80802210523v55dd8588n7b10511a1e25d74a@mail.gmail.com> <56a54d4d0803032229t6b2456c2ka920d99cd8ef377d@mail.gmail.com> Message-ID: 2008/3/4, Alan Carter : > I've written up some reflections on my newbie experience together with > both versions, which might be helpful to people interested in > popularizing Haskell, at: > > http://the-programmers-stone.com/2008/03/04/a-first-haskell-experience/ This is truly interesting, any learning experience is enlightening, we truly do need to lower this barrier of admittance of which you speak. On another subject, there are still point in your code that could be clearer or done with less cruft : maxOfHistogram stats = snd (foldl (\(cA, vA) (cB, vB) -> if (vA > vB) then (cA, vA) else (cB, vB)) (0, 0) stats) can become : maxofHistogram stats = foldl' max 0 (map snd stats) ("foldl' max 0" could be replaced by "maximum" but there wouldn't be a default 0 anymore) more importantly, you can replace this kind of code : vA <- varCreate [] vB <- varCreate [] -- ... vL <- varCreate [] vM <- varCreate [] vN <- varCreate [] vO <- varCreate [] by : [vA, vB, vC, vD, vE, vF, vG, vH, vI, vJ, vK, vL, vM, vN, vO] <- replicateM 15 (varCreate []) (true also for the "dA <- textEntry statusFrame [text := "0", alignment := AlignRight]" sequence) I'm not sure that functions like getdTotal couldn't be improved, I wonder if a small Map for the elements of d wouldn't make the code much better and offer other opportunities for abstractions. As it is, enumeration like : [[label "Total Entries", widget (getdTotal d)] ,[label "Valid Entries", widget (getdValid d)] -- ... ,[label "MDMA", widget (getdMdma d)] ,[label "Caffeine", widget (getdCaffeine d)]] could be slightly reduced by : let bindLabelAndWidget (lbl,getter) = [label lbl, widget (getter d)] in map bindLabelAndWidget [("Total Entries", getdTotal), ("Valid Entries", getdValid) ,(...)] And little thing like : mapM_ (\f -> do repaint f) knownFrames becoming : mapM_ repaint knownFrames I also do concur that a flag or a warning to signal mixed tabulations and space would be a _very_ good idea ! -- Jeda? From dons at galois.com Tue Mar 4 17:35:05 2008 From: dons at galois.com (Don Stewart) Date: Tue Mar 4 17:32:42 2008 Subject: [Haskell-cafe] Doubting Haskell In-Reply-To: References: <56a54d4d0802161405l774ff97djada856fbccdb8b08@mail.gmail.com> <89ca3d1f0802190648s230c67cet40a9612397dd482f@mail.gmail.com> <56a54d4d0802191727h4a2a64a3xcd532ccf86e5a9a@mail.gmail.com> <89ca3d1f0802200158g5f1b884eua5b4ea5634471d9b@mail.gmail.com> <2608b8a80802210523v55dd8588n7b10511a1e25d74a@mail.gmail.com> <56a54d4d0803032229t6b2456c2ka920d99cd8ef377d@mail.gmail.com> Message-ID: <20080304223505.GG25900@scytale.galois.com> chaddai.fouche: > 2008/3/4, Alan Carter : > > I've written up some reflections on my newbie experience together with > > both versions, which might be helpful to people interested in > > popularizing Haskell, at: > > > > http://the-programmers-stone.com/2008/03/04/a-first-haskell-experience/ > > > I also do concur that a flag or a warning to signal mixed tabulations > and space would be a _very_ good idea ! > Such a flag already exists: -fwarn-tabs As in: $ ghc -fwarn-tabs A.hs -no-recomp A.hs:3:0: Tab character -- Don From gtener at gmail.com Tue Mar 4 17:37:45 2008 From: gtener at gmail.com (=?ISO-8859-2?Q?Krzysztof_Skrz=EAtnicki?=) Date: Tue Mar 4 17:35:15 2008 Subject: [Haskell-cafe] (flawed?) benchmark : sort In-Reply-To: References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> Message-ID: <220e47b40803041437o28af877j925df27bc7f8093a@mail.gmail.com> Thanks for improved code. My point was to measure which programming patterns are faster than the others so I can learn which ones I should use. However, the thing that is really bad is the fact, that even oneliner qsort_i is faster than library sort. Which is very different from what I've expected. My intuition is only best and fastest code goes to library, to the point that people can learn from it. It seems I was mislead. > It could probably be improved (with classics solution (better > selection of the pivot...)), but the mergesort is only 3 times slower > in worse case, and much more regular, if someone needs a faster sort > in a specific case, it isn't hard to code. > > -- > Jeda? > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080304/de3bdc0e/attachment.htm From ndmitchell at gmail.com Tue Mar 4 17:40:35 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Tue Mar 4 17:38:05 2008 Subject: [Haskell-cafe] (flawed?) benchmark : sort In-Reply-To: <220e47b40803041437o28af877j925df27bc7f8093a@mail.gmail.com> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <220e47b40803041437o28af877j925df27bc7f8093a@mail.gmail.com> Message-ID: <404396ef0803041440t2f344ebq3aec4e0b2ec2e39c@mail.gmail.com> Hi > My intuition is only best and fastest code goes to library, to the point > that people can learn from it. It seems I was mislead. The compilers change over time - meaning that the fastest code may change over time. There is also the chance that the original code was not the best - for example the words function in the standard library performs two additional isSpace tests per word. The original code specifies an interface, its thanks to people trying to beat the performance that things improve. Thanks Neil From chaddai.fouche at gmail.com Tue Mar 4 18:04:15 2008 From: chaddai.fouche at gmail.com (=?ISO-8859-1?Q?Chadda=EF_Fouch=E9?=) Date: Tue Mar 4 18:01:45 2008 Subject: [Haskell-cafe] (flawed?) benchmark : sort In-Reply-To: <220e47b40803041437o28af877j925df27bc7f8093a@mail.gmail.com> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <220e47b40803041437o28af877j925df27bc7f8093a@mail.gmail.com> Message-ID: 2008/3/4, Krzysztof Skrz?tnicki : > Thanks for improved code. My point was to measure which programming patterns > are faster than the others so I can learn which ones I should use. However, > the thing that is really bad is the fact, that even oneliner qsort_i is > faster than library sort. Which is very different from what I've expected. > My intuition is only best and fastest code goes to library, to the point > that people can learn from it. It seems I was mislead. I think you did not correctly got the point of my and Neil Mitchell's message : you benchmarked those function on a completely random sequences so qsort was at his best, but in the real world, most sequences would have bias, and it is not infrequent at all to sort a partially sorted (or reverse sorted) list... In this case the performance of all your qsort are abysmal... Which is the reason the old sort was replaced by the actual mergesort in the library. Try my code (with 10000 elements for example), you'll see that sort is the best on a sorted list, and that qsort is at least 60 times slower (on 10000, in fact it is degenerating in O(n^2)). In the real world, the library maintainers decided it was ok to pay a slight overhead in the case where the list to sort is really randomly distributed since mergesort won so hugely over qsort in the pretty frequent case (in programs) of lists which present regularities. There is no sort which is ideal in all situations, but we can try to get a sort that works well in all situations, and don't trash in situations not so infrequent. (On the other hand, don't expect libraries functions to always be the best to use in your particular situation, they tend to be all-purpose as we just saw and the maintainers prefer simple generic implementations rather than complicated ones who could be slightly (or even significantly) faster in some case) -- Jeda? From wferi at niif.hu Tue Mar 4 18:08:55 2008 From: wferi at niif.hu (Ferenc Wagner) Date: Tue Mar 4 18:06:26 2008 Subject: [Haskell-cafe] Re: problem in using wash In-Reply-To: (vikrant.patil@gmail.com's message of "Tue, 4 Mar 2008 21:15:47 +0530") References: Message-ID: <87od9uaxyw.fsf@szonett.ki.iif.hu> Vikrant writes: > I was trying to use wash to learn it. I am using ubuntu and I have ghc6.6.1 > installed on my system. > I have also installed the package libghc6-wash-dev > > but in my code when i write > > "import WASH.CGI" > > it gives me following error > > firstCGI.hs:5:7: > Could not find module `WASH.CGI': > locations searched: > WASH/CGI.hs > WASH/CGI.lhs > Failed, modules loaded: none. > > > > can somebody help me in this? Check with 'ghc-pkg list' if the package is present, then use 'ghc-pkg describe WashNGo' to get the exported module names. Also don't forget to use --make when compiling (or explicit package name). -- Regards, Feri. From gtener at gmail.com Tue Mar 4 18:27:11 2008 From: gtener at gmail.com (=?ISO-8859-2?Q?Krzysztof_Skrz=EAtnicki?=) Date: Tue Mar 4 18:24:43 2008 Subject: [Haskell-cafe] (flawed?) benchmark : sort In-Reply-To: References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <220e47b40803041437o28af877j925df27bc7f8093a@mail.gmail.com> Message-ID: <220e47b40803041527r59f00801ob160de5688ac4854@mail.gmail.com> I get it now, thanks. Also, I guess it is possible to find a better algorithm for standard library sort. Christopher Skrz?tnicki On Wed, Mar 5, 2008 at 12:04 AM, Chadda? Fouch? wrote: > 2008/3/4, Krzysztof Skrz?tnicki : > > Thanks for improved code. My point was to measure which programming > patterns > > are faster than the others so I can learn which ones I should use. > However, > > the thing that is really bad is the fact, that even oneliner qsort_i is > > faster than library sort. Which is very different from what I've > expected. > > My intuition is only best and fastest code goes to library, to the point > > that people can learn from it. It seems I was mislead. > > I think you did not correctly got the point of my and Neil Mitchell's > message : you benchmarked those function on a completely random > sequences so qsort was at his best, but in the real world, most > sequences would have bias, and it is not infrequent at all to sort a > partially sorted (or reverse sorted) list... In this case the > performance of all your qsort are abysmal... Which is the reason the > old sort was replaced by the actual mergesort in the library. Try my > code (with 10000 elements for example), you'll see that sort is the > best on a sorted list, and that qsort is at least 60 times slower (on > 10000, in fact it is degenerating in O(n^2)). > > In the real world, the library maintainers decided it was ok to pay a > slight overhead in the case where the list to sort is really randomly > distributed since mergesort won so hugely over qsort in the pretty > frequent case (in programs) of lists which present regularities. > > There is no sort which is ideal in all situations, but we can try to > get a sort that works well in all situations, and don't trash in > situations not so infrequent. > > (On the other hand, don't expect libraries functions to always be the > best to use in your particular situation, they tend to be all-purpose > as we just saw and the maintainers prefer simple generic > implementations rather than complicated ones who could be slightly (or > even significantly) faster in some case) > > -- > Jeda? > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080305/330a8e1b/attachment.htm From derek.a.elkins at gmail.com Tue Mar 4 19:33:51 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Tue Mar 4 19:31:32 2008 Subject: [Haskell-cafe] Re: Functional programmer's intuition for adjunctions? In-Reply-To: References: <20080304171640.GC32511@netsoc.tcd.ie> <1204653519.5706.13.camel@derek-laptop> <20080304183005.GA29033@netsoc.tcd.ie> <4014B004-2644-43A9-95D0-14508A3454B0@yandex.ru> Message-ID: <1204677231.5706.15.camel@derek-laptop> On Tue, 2008-03-04 at 19:01 +0000, Dominic Steinitz wrote: > > Well, we have at least one very useful example of adjunction. It's > > called "curry". See, if X is some arbitrary type, you can define > > > > This adjunction is the one that makes a category cartesian closed. and the monad for it gives rise to the state monad. And the other adjunction relating to exponentials and symmetry gives rise to the continuation monad. From tphyahoo at gmail.com Tue Mar 4 20:07:46 2008 From: tphyahoo at gmail.com (Thomas Hartman) Date: Tue Mar 4 20:05:16 2008 Subject: [Haskell-cafe] Re: [Yhc] Yhc Web Service quietly opened for public testing In-Reply-To: References: Message-ID: <910ddf450803041707w2ba234c3ye3d0e90718d210dd@mail.gmail.com> That is seriously cool. Congratulations Dmitry! thomas. 2008/3/4, Dimitry Golubovsky : > Hi, > > I finally got the Yhc Web Service (web-based front end to the > compiler) running in public testing mode. There hasn't been any > documentation written, and Haddock stuff not brought in order, but if > anyone wants to just get a taste of it, please open this hpaste entry: > > http://hpaste.org/6094 > > and follow the instructions. > > In 10 steps, you'll get Haskell to work in your web browser* ;) No > need to install anything. > > Feel free to edit the source code, and even deliberately make errors > to see how error log looks. At the moment, I do not run automatic > cleanup of failed compilations. > > This is one of my old tests, not showing any GUI interaction. However, > both documents browser and new entry form were written in Haskell > which gives some idea about what can be done. Sources of these forms > are in the Yhc repo. > > Thanks. > > ----------- > * Likely, your results will be better with Firefox than with MSIE. But > MSIE should work as well. > > > -- > Dimitry Golubovsky > > Anywhere on the Web > _______________________________________________ > Yhc mailing list > Yhc@haskell.org > http://www.haskell.org/mailman/listinfo/yhc > From miguelimo38 at yandex.ru Tue Mar 4 20:13:23 2008 From: miguelimo38 at yandex.ru (Miguel Mitrofanov) Date: Tue Mar 4 20:11:09 2008 Subject: [Haskell-cafe] Re: Functional programmer's intuition for adjunctions? In-Reply-To: <1204677231.5706.15.camel@derek-laptop> References: <20080304171640.GC32511@netsoc.tcd.ie> <1204653519.5706.13.camel@derek-laptop> <20080304183005.GA29033@netsoc.tcd.ie> <4014B004-2644-43A9-95D0-14508A3454B0@yandex.ru> <1204677231.5706.15.camel@derek-laptop> Message-ID: Well, I think it's really cool to be sitting in cafe exchanging some ?ute facts from category theory we happen to know. Girls would definitely like it. On 5 Mar 2008, at 03:33, Derek Elkins wrote: > On Tue, 2008-03-04 at 19:01 +0000, Dominic Steinitz wrote: >>> Well, we have at least one very useful example of adjunction. It's >>> called "curry". See, if X is some arbitrary type, you can define >>> >> >> This adjunction is the one that makes a category cartesian closed. > > and the monad for it gives rise to the state monad. > > And the other adjunction relating to exponentials and symmetry gives > rise to the continuation monad. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From derek.a.elkins at gmail.com Tue Mar 4 20:24:04 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Tue Mar 4 20:21:47 2008 Subject: [Haskell-cafe] Functional programmer's intuition for adjunctions? In-Reply-To: <20080304183005.GA29033@netsoc.tcd.ie> References: <20080304171640.GC32511@netsoc.tcd.ie> <1204653519.5706.13.camel@derek-laptop> <20080304183005.GA29033@netsoc.tcd.ie> Message-ID: <1204680244.5706.27.camel@derek-laptop> On Tue, 2008-03-04 at 18:30 +0000, Edsko de Vries wrote: > On Tue, Mar 04, 2008 at 11:58:38AM -0600, Derek Elkins wrote: > > On Tue, 2008-03-04 at 17:16 +0000, Edsko de Vries wrote: > > > Hi, > > > > > > Is there an intuition that can be used to explain adjunctions to > > > functional programmers, even if the match isn't necessary 100% perfect > > > (like natural transformations and polymorphic functions?). > > > > Well when you pretend Hask is Set, many things can be discussed fairly > > directly. > > > > F is left adjoint to U, F -| U, if Hom(FA,B) is naturally isomorphic to > > Hom(A,UB), natural in A and B. A natural transformation over Set is > > just a polymorphic function. So we have an adjunction if we have two > > functions: > > > > phi :: (F a -> b) -> (a -> U b) > > and > > phiInv :: (a -> U b) -> (F a -> b) > > > > such that phi . phiInv = id and phiInv . phi = id and F and U are > > instances of Functor. > > > > The unit and counit respectively is then just phi id and phiInv id. > > Sure, but that doesn't really explain what an adjunction *is*. For me, > it helps to think of a natural transformation as a polymorphic function: > it gives me an intuition about what a natural transformation is. > Specializing the definition of an adjunction for Hask (or Set) helps > understanding the *definitions*, but not the *intention*, if that makes > any sense.. I explicitly mentioned this at the end of my first email: """ Of course, this is a concrete example using basic ideas of programming and not some "intuitive analogy". I feel comfortable working with adjunctions, but I don't have some general analogy that I use. """ I'm suggesting that trying to find such an analogy may be more trouble than it is worth. The best analogy I've heard is to relate the problem of finding an adjunction to optimization problems. Personally, I find representability to be simpler, more useful, and easier to get an intuition about. Adjunction is then a particular case of parameterized representability. From joseph.bruce at pnl.gov Tue Mar 4 23:44:48 2008 From: joseph.bruce at pnl.gov (Bruce, Joseph R (Joe)) Date: Tue Mar 4 23:42:19 2008 Subject: [Haskell-cafe] Re: Exporting Haskell Libraries to C Programmers Message-ID: Don Stewart galois.com> writes: > > joseph.bruce: > > Hi, > > > > I have a Haskell library that I want to make available via FFI to C > > programmers on my project team. I read this thread > > (http://thread.gmane.org/gmane.comp.lang.haskell.cafe/21447) which had > > some interesting ideas, but they seemed unresolved. Or maybe it answers > > my question but I don't understand it. > > > > Is there a way I can package (ghc-)compiled Haskell code into a > > statically-linked library and not force the C programmers to include > > headers and libraries that they have no knowledge of and undefine a > > seemingly endless list of preprocessor symbols (run ghc with the verbose > > flag and look at the calls to gcc)? Can this process be automated? > > Yes, check the FFI documentation for the main story. > > In short, build the Haskell code with cabal, with your foreign export > Haskell functions in the cbits. That bundle can then be linked against > C code. > > You do need to link your app against libHSrts.a and libHSbase.a (and > other libs you use), but assuming you foreign export, the code > to call will look just like normal C stuff. > Thanks Don. I finally got back to this. I hadn't looked at CABAL before. It's a very useful tool and met all my library-forming needs. That's only half my problem though. I'm trying to make the use of this Haskell code as transparent as possible to the C programmers on the team. Telling them about the Haskell base libraries dependency or distributing those libraries with my code is not too bad, but the list of -u flags that the linker needs is brutal. Is there a way to avoid it, or embed it in the package? Ex (using ghc-6.8.2 -v): ... gcc -v -o primes Primes.o ./Primes_stub.o hs_primes_wrapper.o cprimes.c -Bc:\ghc\ghc-6.8.2\gcc-lib/ -DDONT_WANT_WIN32_DLL_SUPPORT -Lc:/ghc/ghc-6.8.2/lib\base-3.0.1.0 -Lc:/ghc/ghc-6.8.2 -Lc:/ghc/ghc-6.8.2/gcc-lib -lHSbase-3.0.1.0 -lwsock32 -lmsvcrt -lkernel32 -luser32 -lshell32 -lHSrts -lm -lgmp -lwsock32 -u _base_GHCziBase_Izh_static_info -u _base_GHCziBase_Czh_static_info -u _base_GHCziFloat_Fzh_static_info -u _base_GHCziFloat_Dzh_static_info -u _base_GHCziPtr_Ptr_static_info -u _base_GHCziWord_Wzh_static_info -u _base_GHCziInt_I8zh_static_info -u _base_GHCziInt_I16zh_static_info -u _base_GHCziInt_I32zh_static_info -u _base_GHCziInt_I64zh_static_info -u _base_GHCziWord_W8zh_static_info -u _base_GHCziWord_W16zh_static_info -u _base_GHCziWord_W32zh_static_info -u _base_GHCziWord_W64zh_static_info -u _base_GHCziStable_StablePtr_static_info -u _base_GHCziBase_Izh_con_info -u _base_GHCziBase_Czh_con_info -u _base_GHCziFloat_Fzh_con_info -u _base_GHCziFloat_Dzh_con_info -u _base_GHCziPtr_Ptr_con_info -u _base_GHCziPtr_FunPtr_con_info -u _base_GHCziStable_StablePtr_con_info -u _base_GHCziBase_False_closure -u _base_GHCziBase_True_closure -u _base_GHCziPack_unpackCString_closure -u _base_GHCziIOBase_stackOverflow_closure -u _base_GHCziIOBase_heapOverflow_closure -u _base_GHCziIOBase_NonTermination_closure -u _base_GHCziIOBase_BlockedOnDeadMVar_closure -u _base_GHCziIOBase_BlockedIndefinitely_closure -u _base_GHCziIOBase_Deadlock_closure -u _base_GHCziIOBase_NestedAtomically_closure -u _base_GHCziWeak_runFinalizzerBatch_closure -u _base_GHCziConc_ensureIOManagerIsRunning_closure ... This particular example is a build on a windows system and makes use of the .o's directly and not the .a I create, but those are of no consequence as this is ultimately a linking issue, not a compilation issue. I don't know what these -u's are for, but I know that if I take them out, the linker fails. They do change from one system to another (this list fails with the linker on RHEL 5). But right now my solution for the C programmers is a make file with $haskell_undefine_flags = , and I'd prefer something more elegant and less system dependent. I am willing to accept that there is no good way around it, but perhaps someone has dealt with this issue before. Any help? Thanks. Joe From vikrant.patil at gmail.com Tue Mar 4 23:59:51 2008 From: vikrant.patil at gmail.com (Vikrant) Date: Tue Mar 4 23:57:20 2008 Subject: [Haskell-cafe] Re: problem in using wash In-Reply-To: <87od9uaxyw.fsf@szonett.ki.iif.hu> References: <87od9uaxyw.fsf@szonett.ki.iif.hu> Message-ID: Thanks for the information. Now I could find mistake in what I was importing. 'ghc-pkg describe WashNGo' told me correct exported module names. On 05/03/2008, Ferenc Wagner wrote: > > Vikrant writes: > > > I was trying to use wash to learn it. I am using ubuntu and I have > ghc6.6.1 > > installed on my system. > > I have also installed the package libghc6-wash-dev > > > > but in my code when i write > > > > "import WASH.CGI" > > > > it gives me following error > > > > firstCGI.hs:5:7: > > Could not find module `WASH.CGI': > > locations searched: > > WASH/CGI.hs > > WASH/CGI.lhs > > Failed, modules loaded: none. > > > > > > > > can somebody help me in this? > > > Check with 'ghc-pkg list' if the package is present, then use > 'ghc-pkg describe WashNGo' to get the exported module names. Also > don't forget to use --make when compiling (or explicit package name). > > -- > Regards, > Feri. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080305/c32367c5/attachment.htm From lemming at henning-thielemann.de Wed Mar 5 01:53:19 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed Mar 5 01:49:38 2008 Subject: [Haskell-cafe] Orphan instances Message-ID: Consider the following modules module A class A t module T import A data T a module B import A import T class A t => B t instance B t => A (T t) GHC emits warning about orphan instance A (T t), since neither A nor T are defined in B. However I can't move the instance to A or T since it depends on B. Would it be fine to lift the restriction, such that it is accepted to declare the instance in a module where the type or the class or a superclass (this is new) is defined? In my example class B provides conversion toInteger (that is Integral), class A provides conversion toRational (that is Real) and T is Ratio. From alistair at abayley.org Wed Mar 5 04:24:09 2008 From: alistair at abayley.org (Alistair Bayley) Date: Wed Mar 5 04:21:42 2008 Subject: [Haskell-cafe] ANN: Takusen 0.8 Message-ID: <79d7c4980803050124h1fca8cc1gef8ddd75f234685d@mail.gmail.com> Oleg and I are pleased to announce the release of Takusen 0.8. (Don Stewart did an interim 0.7 release for us a few weeks ago, and added us to Hackage. This release is a tidy-up of some loose ends, and some bug fixes. Hence, I've summarise the changes since the 0.6 release.) Changes since 0.6: - ODBC support. This still has a few gaps (and probably bugs and rough edges) but should be fairly usable. - support for reusable/persistent sessions, so you can hang onto the connection object between invocations of withSession (this was in release 0.6 but omitted from the release notes). - improvements to the Cabal Setup scripts, which should give better experiences for ghc-6.4, ghc-6.6, and ghc-6.8. The (eventual) 1.4 release of Cabal should be able to build our haddock docs, too. - improved UTF8 decoder (marshals directly from buffer). The release bundle: http://hackage.haskell.org/packages/archive/Takusen/0.8/Takusen-0.8.tar.gz The latest code: darcs get http://darcs.haskell.org/takusen Docs: http://darcs.haskell.org/takusen/doc/html/index.html A comprehensive description of API usage can be found in the documentation for module Database.Enumerator (look for the Usage section): http://darcs.haskell.org/takusen/doc/html/Database-Enumerator.html Future plans: - FreeTDS backend (Sybase and MS Sql Server) - support for Blobs and Clobs For those of you unfamiliar with Takusen, here is our HCAR blurb: Takusen is a library for accessing DBMS's. Like HSQL, we support arbitrary SQL statements (currently strings, extensible to anything that can be converted to a string). Takusen's `unique-selling-point' is safety and efficiency. We statically ensure all acquired database resources - such as cursors, connection and statement handles - are released, exactly once, at predictable times. Takusen can avoid loading the whole result set in memory, and so can handle queries returning millions of rows in constant space. Takusen also supports automatic marshalling and unmarshalling of results and query parameters. These benefits come from the design of query result processing around a left-fold enumerator. Currently we fully support ODBC, Oracle, Sqlite, and PostgreSQL. From alistair at abayley.org Wed Mar 5 04:29:31 2008 From: alistair at abayley.org (Alistair Bayley) Date: Wed Mar 5 04:26:59 2008 Subject: [Haskell-cafe] Re: ANN: Takusen 0.8 In-Reply-To: <79d7c4980803050124h1fca8cc1gef8ddd75f234685d@mail.gmail.com> References: <79d7c4980803050124h1fca8cc1gef8ddd75f234685d@mail.gmail.com> Message-ID: <79d7c4980803050129y586a20b9n384b66731605a0b7@mail.gmail.com> > Changes since 0.6: > > - ODBC support. This still has a few gaps (and probably bugs and rough edges) > but should be fairly usable. Doh! I had also meant to make a request: the ODBC code (and Setup.hs configuration) is only tested under Windows (XP). We'd love for people to test on *nix platforms and fill in the missing bits in the Setup script. Alistair From claudiusmaximus at goto10.org Wed Mar 5 05:01:33 2008 From: claudiusmaximus at goto10.org (Claude Heiland-Allen) Date: Wed Mar 5 04:56:27 2008 Subject: [Haskell-cafe] Re: Exporting Haskell Libraries to C Programmers In-Reply-To: References: Message-ID: <47CE6F7D.9010107@goto10.org> Bruce, Joseph R (Joe) wrote: [snip] > I hadn't looked at CABAL before. It's a very useful tool and met all my library-forming needs. > That's only half my problem though. I'm trying to make the use of this Haskell code as transparent as possible to the C programmers on the team. Telling them about the Haskell base libraries dependency or distributing those libraries with my code is not too bad, but the list of -u flags that the linker needs is brutal. Is there a way to avoid it, or embed it in the package? > > Ex (using ghc-6.8.2 -v): > ... > gcc -v -o primes Primes.o ./Primes_stub.o hs_primes_wrapper.o cprimes.c [snip] Maybe try compiling cprimes.c to cprimes.o with gcc, then link with GHC? Something like: gcc -o cprimes.o -c cprimes.c ghc -no-hs-main --make -c *.hs ghc -no-hs-main -package foo -o moo *.o I know this isn't ideal, but it's similar to what I used to build a .so from Haskell code that can be loaded by a C app ignorant of Haskell. Claude -- http://claudiusmaximus.goto10.org From simonpj at microsoft.com Wed Mar 5 06:26:02 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed Mar 5 06:23:31 2008 Subject: [Haskell-cafe] Orphan instances In-Reply-To: References: Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C322007B2D74@EA-EXMSG-C334.europe.corp.microsoft.com> | GHC emits warning about orphan instance A (T t), since neither A nor T are | defined in B. However I can't move the instance to A or T since it depends | on B. Would it be fine to lift the restriction, such that it is accepted | to declare the instance in a module where the type or the class or a | superclass (this is new) is defined? The issue is this. Suppose GHC is compiling a module X, somewhere far away from the modules A,T,B which you define. While compiling X, GHC needs to solve the class constraint A (T Int) Well, in order to make sense of the constraint, GHC will have read the interfaces for module A and T, so that it knows that A is indeed a class, and T is indeed a type constructor. But so far nothing says that it needs to read the interface for B. But suppose that B indeed appears in the transitive closure of X's imports. Then the programmer expects GHC to find the instance in B. To ensure that it does, GHC reads the interface of every orphan module in the transitive closure of X's imports. (An orphan module is one like B that defines an instance whose head does not mention something defined locally.) The warning is just so that you know this is going to happen. It's something to avoid when unnecessary, but not a bug. I think you can see from this explanation that simply declaring that B isn't an orphan module after all isn't going to help! Simon | -----Original Message----- | From: haskell-cafe-bounces@haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Henning Thielemann | Sent: 05 March 2008 06:53 | To: Haskell Cafe | Subject: [Haskell-cafe] Orphan instances | | | Consider the following modules | | | module A | | class A t | | | module T | | import A | | data T a | | | module B | | import A | import T | | class A t => B t | | instance B t => A (T t) | | | | GHC emits warning about orphan instance A (T t), since neither A nor T are | defined in B. However I can't move the instance to A or T since it depends | on B. Would it be fine to lift the restriction, such that it is accepted | to declare the instance in a module where the type or the class or a | superclass (this is new) is defined? | | | In my example class B provides conversion toInteger (that is Integral), | class A provides conversion toRational (that is Real) and T is Ratio. | _______________________________________________ | Haskell-Cafe mailing list | Haskell-Cafe@haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe From ketil at malde.org Wed Mar 5 07:48:36 2008 From: ketil at malde.org (Ketil Malde) Date: Wed Mar 5 07:46:01 2008 Subject: [Haskell-cafe] Job opening: Use Haskell to save the environment! Message-ID: <878x0x49qz.fsf@nmd9999.imr.no> Well - maybe?. I'm not sure how relevant this is for this list, but I thought I should mention that there is an open position for a 3-year Ph.D. scolarship at IMR where I work. The work is in bioinformatics, and as I'm a happy Haskell user, I'd be happy to see qualified applicants who know Haskell as well. If you are interested, and posess a Master's degree (or equivalent education), a rough translation of the announcement is attached - the official one (in Norwegian) can be found at: http://www.imr.no/aktuelt/ledige_stillinger/stipendiat_bioinformatikk, Please contact me with any questions! -k -------------- next part -------------- There is an open research fellow position (Ph.D. scholarship) at the Institute of Marine Research in Bergen, Norway. The position is for three years, and it is part of the project "Salmon louse genome sequencing and functional studies on host parasite interactions", financed by the Norwegian Research Council's program for functional genomics, FUGE. The sea louse is an important ecological and economic problem for the fish farming industry, and the goal of the project is to investigate parasite-host interactions, ultimately leading to a vaccine against the sea louse. The research fellow will contribute to annotation and other analysis of sequence data, establishing improved models for errors, and development of new methods and software tools for computational analysis. New sequencing technologies are likely to be central. We are looking for a motivated candidate with a relevant master's degree or equivalent education, and a solid background in one of the following topics: * algorithm development and analysis * statistics * bioinformatics * molecular biology Place of work will be Bergen, the salary follows national regulations and starts out at NOK 325000 (i.e., approximately ?40000)/year. Contact Ketil Malde (ketil.malde@imr.no, +47 55238647) for further details. -------------- next part -------------- ?) The target of the project is the sea louse, which is a large ecological and economical problem. -- If I haven't seen further, it is by standing in the footprints of giants From carette at mcmaster.ca Wed Mar 5 11:28:48 2008 From: carette at mcmaster.ca (Jacques Carette) Date: Wed Mar 5 11:29:16 2008 Subject: [Haskell-cafe] 2nd CFP: PLMMS 2008 Message-ID: <47CECA40.6040007@mcmaster.ca> SECOND CALL FOR PAPERS * UPDATE: Post-workshop proceedings in Journal of Automated Reasoning * UPDATE: Invited talk by Conor McBride Second Workshop on Programming Languages for Mechanized Mathematics (PLMMS 2008) http://events.cs.bham.ac.uk/cicm08/workshops/plmms/ As part of CICM / Calculemus 2008 Birmingham, UK, 28-29 July 2008 This workshop is focused on the intersection of programming languages (PL) and mechanized mathematics systems (MMS). The latter category subsumes present-day computer algebra systems (CAS), interactive proof assistants (PA), and automated theorem provers (ATP), all heading towards fully integrated mechanized mathematical assistants that are expected to emerge eventually (cf. the objective of Calculemus). The two subjects of PL and MMS meet in the following topics, which are of particular interest to this workshop: * Dedicated input languages for MMS: covers all aspects of languages intended for the user to deploy or extend the system, both algorithmic and declarative ones. Typical examples are tactic definition languages such as Ltac in Coq, mathematical proof languages as in Mizar or Isar, or specialized programming languages built into CA systems. Of particular interest are the semantics of those languages, especially when current ones are untyped. * Mathematical modeling languages used for programming: covers the relation of logical descriptions vs. algorithmic content. For instance the logic of ACL2 extends a version of Lisp, that of Coq is close to Haskell, and some portions of HOL are similar to ML and Haskell, while Maple tries to do both simultaneously. Such mathematical languages offer rich specification capabilities, which are rarely available in regular programming languages. How can programming benefit from mathematical concepts, without limiting mathematics to the computational worldview? * Programming languages with mathematical specifications: covers advanced "mathematical" concepts in programming languages that improve the expressive power of functional specifications, type systems, module systems etc. Programming languages with dependent types are of particular interest here, as is intentionality vs extensionality. * Language elements for program verification: covers specific means built into a language to facilitate correctness proofs using MMS. For example, logical annotations within programs may be turned into verification conditions to be solved in a proof assistant eventually. How need MMS and PL to be improved to make this work conveniently and in a mathematically appealing way? These issues have a very colorful history. Many PL innovations first appeared in either CA or proof systems first, before migrating into more mainstream programming languages. Some examples include type inference, dependent types, generics, term-rewriting, first-class types, first-class expressions, first-class modules, code extraction etc. However, such innovations were never aggressively pursued by builders of MMS, but often reconstructed by programming language researchers. This workshop is an opportunity to present the latest innovations in MMS design that may be relevant to future programming languages, or conversely novel PL principles that improve upon implementation and deployment of MMS. We also want to critically examine what has worked, and what has not. Why are all the languages of mainstream CA systems untyped? Why are the (strongly typed) proof assistants so much harder to use than a typical CAS? What forms of polymorphism exist in mathematics? What forms of dependent types may be used in mathematical modeling? How can MMS regain the upper hand on issues of "genericity" and "modularity"? What are the biggest barriers to using a more mainstream language as a host language for a CAS or PA/ATP? Invited Talk ------------ Conor McBride (Alta Systems, Northern Ireland) will give an invited talk. Submission ---------- Submission works through EasyChair http://www.easychair.org/conferences/?conf=plmms2008 Two kinds of papers will be considered: * Full research papers may be up to 12 pages long. Authors of accepted papers are expected to present their work on the workshop in a regular talk. * Position papers may be up to 4 pages long. The workshop presentation of accepted position papers consists of two parts: a stimulating statement of certain issues or challenges by the author, followed by a discussion in the plenum. Papers should use the usual ENTCS style http://www.entcs.org/prelim.html (11 point version), and will be reviewed by the program committee. Informal workshop proceedings will be circulated as a technical report. Moreover there will be post-workshop proceedings of improved research papers, or position papers that have been completed into full papers, to appear in a special issue of the Journal of Automated Reasoning. There will be a separate submission and review phase for this, where papers from both PLMMS 2007 and 2008 will be considered. Programme Committee ------------------- Jacques Carette (Co-Chair) (McMaster University, Canada) John Harrison (Intel Corporation, USA) Hugo Herbelin (INRIA, Ecole polytechnique, France) James McKinna (Radboud University Nijmegen, Netherlands) Ulf Norell (Chalmers University, Sweden) Bill Page Christophe Raffalli (Universite de Savoie, France) Josef Urban (Charles University, Czech Republic) Stephen Watt (ORCCA, University of Western Ontario, Canada) Makarius Wenzel (Co-Chair) (Technische Universitaet Muenchen, Germany) Freek Wiedijk (Radboud University Nijmegen, Netherlands) Important Dates --------------- * Submission deadline - 5 May 2008 * Notification of acceptance - 6 June 2008 * Final version - 7 July 2008 (approximately) * Workshop - 28-29 July 2008 From jgbailey at gmail.com Wed Mar 5 12:26:43 2008 From: jgbailey at gmail.com (Justin Bailey) Date: Wed Mar 5 12:24:11 2008 Subject: [Haskell-cafe] Re: [Yhc] Yhc Web Service quietly opened for public testing In-Reply-To: <910ddf450803041707w2ba234c3ye3d0e90718d210dd@mail.gmail.com> References: <910ddf450803041707w2ba234c3ye3d0e90718d210dd@mail.gmail.com> Message-ID: > 2008/3/4, Dimitry Golubovsky : > > Hi, > > > > I finally got the Yhc Web Service (web-based front end to the > > compiler) running in public testing mode. There hasn't been any > > documentation written, and Haddock stuff not brought in order, but if > > anyone wants to just get a taste of it, please open this hpaste entry: > > > > http://hpaste.org/6094 Does this take a Haskell program and compile it to JavaScript? That's pretty amazing. Justin From golubovsky at gmail.com Wed Mar 5 12:36:02 2008 From: golubovsky at gmail.com (Dimitry Golubovsky) Date: Wed Mar 5 12:33:29 2008 Subject: [Haskell-cafe] Re: [Yhc] Yhc Web Service quietly opened for public testing In-Reply-To: References: <910ddf450803041707w2ba234c3ye3d0e90718d210dd@mail.gmail.com> Message-ID: Justin, On 3/5/08, Justin Bailey wrote: > Does this take a Haskell program and compile it to JavaScript? That's > pretty amazing. Yes, exactly. The two user interface programs, MainGUI and NewEntry were written in Haskell and compiled into Javascript by the same tools. With minimal changes they are pasteable/compilable by this service as well. See http://haskell.org/pipermail/yhc/2008-March/001194.html - anybody wants to try? I suggested this relatively simple program as a test example just to make sure results would be similar for everybody. More complex issues may arise e. g. with CSS interpreted differently by FF vs MSIE; this needs to work on in the future. Thanks for your interest. -- Dimitry Golubovsky Anywhere on the Web From jgardner at jonathangardner.net Wed Mar 5 13:09:47 2008 From: jgardner at jonathangardner.net (Jonathan Gardner) Date: Wed Mar 5 13:07:14 2008 Subject: [Haskell-cafe] Starting Haskell with a web application Message-ID: <6cc20cea0803051009y7fedd8a2i304f63ac867c3c23@mail.gmail.com> I am sure I am missing something obvious, but since the cafe is the place to ask stupid questions... I am getting more and more excited about Haskell as I learn more and more about it. Professionally, and as a hobby, I love working on web applications. Where do I get started in writing a web app with Haskell? I am looking more for a framework like Pylons and less like Apache, if that helps. I am sure someone has already done the homework on this, so a link will be fine. -- Jonathan Gardner jgardner@jonathangardner.net From bos at serpentine.com Wed Mar 5 13:52:07 2008 From: bos at serpentine.com (Bryan O'Sullivan) Date: Wed Mar 5 13:49:34 2008 Subject: [Haskell-cafe] Starting Haskell with a web application In-Reply-To: <6cc20cea0803051009y7fedd8a2i304f63ac867c3c23@mail.gmail.com> References: <6cc20cea0803051009y7fedd8a2i304f63ac867c3c23@mail.gmail.com> Message-ID: <47CEEBD7.30005@serpentine.com> Jonathan Gardner wrote: > Where do I get started in writing a web app with Haskell? I am looking > more for a framework like Pylons and less like Apache, if that helps. The closest we currently have to a web framework is Happs (http://happs.org/), but it uses the kitchen sink of advanced and unusual language extensions, which I think might be why it hasn't got all that much momentum. 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. References: <6cc20cea0803051009y7fedd8a2i304f63ac867c3c23@mail.gmail.com> <47CEEBD7.30005@serpentine.com> Message-ID: <20080305190018.GE16789@scytale.galois.com> bos: > Jonathan Gardner wrote: > > > Where do I get started in writing a web app with Haskell? I am looking > > more for a framework like Pylons and less like Apache, if that helps. > > The closest we currently have to a web framework is Happs > (http://happs.org/), but it uses the kitchen sink of advanced and > unusual language extensions, which I think might be why it hasn't got > all that much momentum. > > 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. Perhaps it is time for a haskell web apps wiki page, if there isn't one, outlining the approaches, with a structure like: * HAppS * CGI - FastCGI * Database solutions - HDBC - Takusen * Templating - HStringTemplate * JSON rpc etc. From bos at serpentine.com Wed Mar 5 14:07:11 2008 From: bos at serpentine.com (Bryan O'Sullivan) Date: Wed Mar 5 14:04:39 2008 Subject: [Haskell-cafe] Starting Haskell with a web application In-Reply-To: <20080305190018.GE16789@scytale.galois.com> References: <6cc20cea0803051009y7fedd8a2i304f63ac867c3c23@mail.gmail.com> <47CEEBD7.30005@serpentine.com> <20080305190018.GE16789@scytale.galois.com> Message-ID: <47CEEF5F.8010807@serpentine.com> Don Stewart wrote: > Perhaps it is time for a haskell web apps wiki page, if there isn't one, > outlining the approaches, Indeed. In addition to the code you mention, people like Adam Langley and Johan Tibbell are taking on corners of the web app problem space in a more modern context. It's going to be an interesting year or two; I only wish we could accelerate the arrival of this particular portion of the future. We have a hole in "Real World Haskell" for writing about web development that we can't satisfactorily fill with what's currently available. References: <6cc20cea0803051009y7fedd8a2i304f63ac867c3c23@mail.gmail.com> <47CEEBD7.30005@serpentine.com> <20080305190018.GE16789@scytale.galois.com> <47CEEF5F.8010807@serpentine.com> Message-ID: <396556a20803051125o34ca2197w60773871f7059523@mail.gmail.com> On Wed, Mar 5, 2008 at 11:07 AM, Bryan O'Sullivan wrote: > Indeed. In addition to the code you mention, people like Adam Langley > and Johan Tibbell are taking on corners of the web app problem space in > a more modern context. I should probably speak up then ;) I'm (slowly) writing Network.MiniHTTP. What it does have is a modern, ByteString based HTTP parser and serialiser (in decent shape), SSL support (only in darcs at the moment) and my test case, that I'm working towards, is an OpenID consumer. Once I have that working, I'll do a second release. It's not that far off, it's just a question of time. AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org From bjorn at bringert.net Wed Mar 5 16:05:42 2008 From: bjorn at bringert.net (Bjorn Bringert) Date: Wed Mar 5 16:03:13 2008 Subject: [Haskell-cafe] Connection helpers: for people interested in network code In-Reply-To: <396556a20803040815i13c70459gdcaf4b1469403f13@mail.gmail.com> References: <396556a20802291150y683a8ca5q1065e87a48b6e518@mail.gmail.com> <396556a20803040815i13c70459gdcaf4b1469403f13@mail.gmail.com> Message-ID: On Tue, Mar 4, 2008 at 5:15 PM, Adam Langley wrote: > On Tue, Mar 4, 2008 at 7:31 AM, Bjorn Bringert wrote: > > you may want to have a look at the socket abstraction used in the HTTP package: > > > > http://hackage.haskell.org/packages/archive/HTTP/3001.0.4/doc/html/Network-Stream.html > > > > It would be great to get HTTPS support going! > > I should have mentioned that I had seen this in the original email. I > think the major problem with this interface was that it was written in > the time before ByteStrings. Now that we have ByteStrings I think that > it makes a lot of sense for networking to use them. > > However, it shouldn't be too hard to wrap HsOpenSSL in this interface. > I might try this this week. Then HTTPS should Just Work (maybe ;) There is some (dormant?) work on bringing HTTP into the age of the ByteString. Thomas Schilling (nominolo) might be able to tell you more about it. /B From sebastian.sylvan at gmail.com Wed Mar 5 16:08:09 2008 From: sebastian.sylvan at gmail.com (Sebastian Sylvan) Date: Wed Mar 5 16:05:37 2008 Subject: [Haskell-cafe] Starting Haskell with a web application In-Reply-To: <47CEEBD7.30005@serpentine.com> References: <6cc20cea0803051009y7fedd8a2i304f63ac867c3c23@mail.gmail.com> <47CEEBD7.30005@serpentine.com> Message-ID: <3d96ac180803051308i630122ffn7ede41aa7ef5d8fc@mail.gmail.com> On Wed, Mar 5, 2008 at 6:52 PM, Bryan O'Sullivan wrote: > Jonathan Gardner wrote: > > > Where do I get started in writing a web app with Haskell? I am looking > > more for a framework like Pylons and less like Apache, if that helps. > > The closest we currently have to a web framework is Happs > (http://happs.org/), but it uses the kitchen sink of advanced and > unusual language extensions, which I think might be why it hasn't got > all that much momentum. > > 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. > My web host has GHC 6.6 and it builds fine. I like WASH quite a lot, though it may be a bit heavy-weight for certain applications in the way it does sessions (though it works really well e.g. when users click the back button etc.). Maybe zipping up the session state or something would help there (or maybe it already does this?) - on my simple toy site it takes up around 30% of the total size, which is a bit hefty. Oh yeah, I use the preprocessor thing to get the nice syntax, but it's a bit messy when things go wrong since it passes through a preprocessor before being compiled. -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080305/459a45c2/attachment.htm From nominolo at googlemail.com Wed Mar 5 17:37:54 2008 From: nominolo at googlemail.com (Thomas Schilling) Date: Wed Mar 5 17:35:41 2008 Subject: [Haskell-cafe] Connection helpers: for people interested in network code In-Reply-To: References: <396556a20802291150y683a8ca5q1065e87a48b6e518@mail.gmail.com> <396556a20803040815i13c70459gdcaf4b1469403f13@mail.gmail.com> Message-ID: <5813A9C9-690E-4DA0-A11B-58AC105955C4@googlemail.com> On 5 mar 2008, at 22.05, Bjorn Bringert wrote: > > There is some (dormant?) work on bringing HTTP into the age of the > ByteString. Thomas Schilling (nominolo) might be able to tell you more > about it. > Well, I can say with certainty that I won't have the time nor energy to bring this into a usable state anytime soon (speak: not this year). I think it's unlikely that Jonas will, either. Our work was a quick hack, meant mainly as a proof of concept. Doing it well would require work and more knowledge of the HTTP protocol than I have, ATM. I agree that it would be valuable to the community, but it's not gonna be me. I wonder, though, what happened to the curl bindings for Haskell? This was a Summer of Code project last year. Also Johan Tibell expressed some interest in getting bytestrings for HTTP. / Thomas From dons at galois.com Wed Mar 5 18:04:59 2008 From: dons at galois.com (Don Stewart) Date: Wed Mar 5 18:02:43 2008 Subject: [Haskell-cafe] Connection helpers: for people interested in network code In-Reply-To: <5813A9C9-690E-4DA0-A11B-58AC105955C4@googlemail.com> References: <396556a20802291150y683a8ca5q1065e87a48b6e518@mail.gmail.com> <396556a20803040815i13c70459gdcaf4b1469403f13@mail.gmail.com> <5813A9C9-690E-4DA0-A11B-58AC105955C4@googlemail.com> Message-ID: <20080305230459.GA2942@scytale.galois.com> nominolo: > > On 5 mar 2008, at 22.05, Bjorn Bringert wrote: > > > >There is some (dormant?) work on bringing HTTP into the age of the > >ByteString. Thomas Schilling (nominolo) might be able to tell you more > >about it. > > > > Well, I can say with certainty that I won't have the time nor energy > to bring this into a usable state anytime soon (speak: not this > year). I think it's unlikely that Jonas will, either. Our work was > a quick hack, meant mainly as a proof of concept. Doing it well > would require work and more knowledge of the HTTP protocol than I > have, ATM. I agree that it would be valuable to the community, but > it's not gonna be me. > > I wonder, though, what happened to the curl bindings for Haskell? > This was a Summer of Code project last year. Also Johan Tibell > expressed some interest in getting bytestrings for HTTP. $ git clone http://code.haskell.org/curl.git :) But really, we want an no-errors bytestring-efficient http of our own. From lennart at augustsson.net Wed Mar 5 18:48:03 2008 From: lennart at augustsson.net (Lennart Augustsson) Date: Wed Mar 5 18:45:34 2008 Subject: [Haskell-cafe] Doubting Haskell In-Reply-To: <56a54d4d0803032229t6b2456c2ka920d99cd8ef377d@mail.gmail.com> References: <56a54d4d0802161405l774ff97djada856fbccdb8b08@mail.gmail.com> <89ca3d1f0802190648s230c67cet40a9612397dd482f@mail.gmail.com> <56a54d4d0802191727h4a2a64a3xcd532ccf86e5a9a@mail.gmail.com> <89ca3d1f0802200158g5f1b884eua5b4ea5634471d9b@mail.gmail.com> <2608b8a80802210523v55dd8588n7b10511a1e25d74a@mail.gmail.com> <56a54d4d0803032229t6b2456c2ka920d99cd8ef377d@mail.gmail.com> Message-ID: Thanks for an interesting write-up. And not bad for a first Haskell program. :) There's still a number of things you could do to limit the boiler plate code, though. On Tue, Mar 4, 2008 at 6:29 AM, Alan Carter wrote: > Many thanks for the explanations when I was first experimenting with > Haskell. I managed to finish translating a C++ wxWidgets program into > Haskell wxHaskell, and am certainly impressed. > > I've written up some reflections on my newbie experience together with > both versions, which might be helpful to people interested in > popularizing Haskell, at: > > http://the-programmers-stone.com/2008/03/04/a-first-haskell-experience/ > > Regards, > > Alan > > -- > ... the PA system was moaning unctuously, like a lady hippopotamus > reading A. E. Housman ..." > -- James Blish, "They Shall Have Stars" > _______________________________________________ > 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/20080305/32359814/attachment.htm From hpacheco at gmail.com Wed Mar 5 20:27:47 2008 From: hpacheco at gmail.com (Hugo Pacheco) Date: Wed Mar 5 20:25:14 2008 Subject: [Haskell-cafe] Issues(Bugs?) with GHC Type Families In-Reply-To: References: <7b92c2840803030935t6ed5d2a6ne63d5f8b3d5fe917@mail.gmail.com> Message-ID: <7b92c2840803051727l6a31fd78j63c756ee9a1973ca@mail.gmail.com> Just something I have been wondering. I would like to implement somehting like: type family F a :: * -> * ... class C a b where ... instance (F a ~ F b) => C a b where ... But apparently type equality coercions can not be used as a single context. If I enable -fallow-undecidable-instances, whenever the equality does not hold, the instance returns a compile error, what does make sense. Is there any way I could overcome this? Thanks, hugo -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080306/48876081/attachment.htm From ajb at spamcop.net Wed Mar 5 20:36:19 2008 From: ajb at spamcop.net (ajb@spamcop.net) Date: Wed Mar 5 20:33:46 2008 Subject: [Haskell-cafe] Functional programmer's intuition for adjunctions? In-Reply-To: <1204680244.5706.27.camel@derek-laptop> References: <20080304171640.GC32511@netsoc.tcd.ie> <1204653519.5706.13.camel@derek-laptop> <20080304183005.GA29033@netsoc.tcd.ie> <1204680244.5706.27.camel@derek-laptop> Message-ID: <20080305203619.wi1d6xf34gcks0ss@webmail.spamcop.net> G'day all. Quoting Derek Elkins : > Of course, this is a concrete example using basic ideas of programming > and not some "intuitive analogy". I feel comfortable working with > adjunctions, but I don't have some general analogy that I use. I think this is important. The concept of an adjunction isn't like that of a natural transformation. In Haskell, natural transformations are functions that respect the structure of functors. Since you can't avoid respecting the structure of functors (the language won't let you do otherwise), you get natural transformations for free. (Free as in theorems, not free as in beer.) Adjunctions, on the other hand, you have to make yourself. As such, they're more like monads. I use at least three distinct pictures when I'm working with monads: - Overloaded semicolon. - Functorial container (e.g. lists). - Term substitution system. ...but even that doesn't fully cover all the possibilities that monads give you. Monads are what they are, and you use them when it seems to make sense to implement the Monad interface for them. It's sometimes only obvious that an interface is conformed to after the event. For example, consider Data.Supply: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/value-supply-0.1 It's clear in retrospect that Supply is a comonad, but probably neither the paper authors nor the package author, smart as they are, noticed this at the time of writing, because you need experience with comonads to identify them. I think it's the same with adjunctions. Having said that, I think it makes sense to come up with some example pictures, much like the example pictures of monads that people use. Looking at those examples again: phi :: (F a -> b) -> (a -> U b) phiInv :: (a -> U b) -> (F a -> b) One thing that springs to mind is that an adjunction could connect monads and their associated comonads. Is that a good picture? Cheers, Andrew Bromage From ok at cs.otago.ac.nz Wed Mar 5 21:28:28 2008 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Wed Mar 5 21:25:57 2008 Subject: [Haskell-cafe] Doubting Haskell In-Reply-To: References: <56a54d4d0802161405l774ff97djada856fbccdb8b08@mail.gmail.com> <89ca3d1f0802190648s230c67cet40a9612397dd482f@mail.gmail.com> <56a54d4d0802191727h4a2a64a3xcd532ccf86e5a9a@mail.gmail.com> <89ca3d1f0802200158g5f1b884eua5b4ea5634471d9b@mail.gmail.com> <2608b8a80802210523v55dd8588n7b10511a1e25d74a@mail.gmail.com> <56a54d4d0803032229t6b2456c2ka920d99cd8ef377d@mail.gmail.com> Message-ID: Concerning the Haskell program that does some statistics and displays some graphs, I must say that if that were the task I had to solve I would not use either C++ or Haskell, but R, the open source S lookalike. The best way to be productive as a programmer is to not write code if you can steal it. R looks like an imperative language, but it is "value-oriented" in the same way that SETL is, so is by some criteria a functional language of sorts. From golubovsky at gmail.com Thu Mar 6 00:05:43 2008 From: golubovsky at gmail.com (Dimitry Golubovsky) Date: Thu Mar 6 00:03:11 2008 Subject: [Haskell-cafe] Haddock Documentation for Yhc Web Service available online Message-ID: Hi, I have regenerated Haddock documentation for Haskell modules included into the Yhc Web Service. http://www.golubovsky.org:5984/_utils/yhcws/index.html Thanks. -- Dimitry Golubovsky Anywhere on the Web From a.biurvOir4 at asuhan.com Thu Mar 6 00:22:44 2008 From: a.biurvOir4 at asuhan.com (Kim-Ee Yeoh) Date: Thu Mar 6 00:30:45 2008 Subject: [Haskell-cafe] Functional programmer's intuition for adjunctions? In-Reply-To: <20080305203619.wi1d6xf34gcks0ss@webmail.spamcop.net> References: <20080304171640.GC32511@netsoc.tcd.ie> <1204653519.5706.13.camel@derek-laptop> <20080304183005.GA29033@netsoc.tcd.ie> <1204680244.5706.27.camel@derek-laptop> <20080305203619.wi1d6xf34gcks0ss@webmail.spamcop.net> Message-ID: <15866753.post@talk.nabble.com> ajb-2 wrote: > > In Haskell, natural transformations are > functions that respect the structure of functors. Since you can't > avoid respecting the structure of functors (the language won't let you > do otherwise), you get natural transformations for free. (Free as > in theorems, not free as in beer.) > It's worth noting that polymorphism is one of those unavoidable, albeit hidden, functors. Polymorphizing a function "forall a" can be thought of as lifting it via the ((->) T_a) functor, where T_a is the type variable of "a". E.g. reverse really has the signature T_a -> [a] -> [a]. But ((->) T_a) is left adjoint to ((,) T_a), which just happens to be the analogous type-explicit way of representing existentials. Adjunctions are a useful tool to describe and analyze such dualities precisely. ajb-2 wrote: > > Adjunctions, on the other hand, you have to make yourself. As such, > they're more like monads. > Constructing adjunctions, comprising as they do of a pair of functors, does seem double the work of a single monad. Duality OTOH is a powerful guiding principle and may well be easier than working with the monad laws directly. And besides, you get a comonad for free. ajb-2 wrote: > > One thing that springs to mind is that an adjunction could connect > monads and their associated comonads. Is that a good picture? > Definitely. -- View this message in context: http://www.nabble.com/Functional-programmer%27s-intuition-for-adjunctions--tp15832225p15866753.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. From johan.tibell at gmail.com Thu Mar 6 04:16:40 2008 From: johan.tibell at gmail.com (Johan Tibell) Date: Thu Mar 6 04:14:08 2008 Subject: [Haskell-cafe] Starting Haskell with a web application In-Reply-To: <396556a20803051125o34ca2197w60773871f7059523@mail.gmail.com> References: <6cc20cea0803051009y7fedd8a2i304f63ac867c3c23@mail.gmail.com> <47CEEBD7.30005@serpentine.com> <20080305190018.GE16789@scytale.galois.com> <47CEEF5F.8010807@serpentine.com> <396556a20803051125o34ca2197w60773871f7059523@mail.gmail.com> Message-ID: <90889fe70803060116u1d875adbl94f02d77e8039c91@mail.gmail.com> On Wed, Mar 5, 2008 at 8:25 PM, Adam Langley wrote: > On Wed, Mar 5, 2008 at 11:07 AM, Bryan O'Sullivan wrote: > > Indeed. In addition to the code you mention, people like Adam Langley > > and Johan Tibbell are taking on corners of the web app problem space in > > a more modern context. > > I should probably speak up then ;) Me too! ;) I'm writing a web application server which I'm trying to make as simple to manage as Mongrel [1], a popular Ruby web server used to host web application written in e.g. Ruby on Rails. It uses Oleg style enumerators and ByteString internally to safely an efficiently manage resources. The web application interface is that of Python's WSGI [2] but adapted to a Haskell style. I've been busy lately but starting this weekend I will have much more time to work on it and can hopefully make a first release. 1. http://mongrel.rubyforge.org/ - I believe the original author left the project so the projects original website is gone. 2. http://www.python.org/dev/peps/pep-0333/ -- Johan From Alistair_Bayley at invescoperpetual.co.uk Thu Mar 6 06:08:53 2008 From: Alistair_Bayley at invescoperpetual.co.uk (Bayley, Alistair) Date: Thu Mar 6 06:06:19 2008 Subject: [Haskell-cafe] Starting Haskell with a web application In-Reply-To: <90889fe70803060116u1d875adbl94f02d77e8039c91@mail.gmail.com> References: <6cc20cea0803051009y7fedd8a2i304f63ac867c3c23@mail.gmail.com><47CEEBD7.30005@serpentine.com><20080305190018.GE16789@scytale.galois.com><47CEEF5F.8010807@serpentine.com><396556a20803051125o34ca2197w60773871f7059523@mail.gmail.com> <90889fe70803060116u1d875adbl94f02d77e8039c91@mail.gmail.com> Message-ID: <125EACD0CAE4D24ABDB4D148C4593DA9049E92F6@GBLONXMB02.corp.amvescap.net> > From: haskell-cafe-bounces@haskell.org > [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Johan Tibell > > I'm writing a web application server which I'm trying to make as > simple to manage as Mongrel [1], a popular Ruby web server used to > host web application written in e.g. Ruby on Rails. It uses Oleg style > enumerators and ByteString internally to safely an efficiently manage > resources. The web application interface is that of Python's WSGI [2] > but adapted to a Haskell style. I've been busy lately but starting > this weekend I will have much more time to work on it and can > hopefully make a first release. > > 1. http://mongrel.rubyforge.org/ - I believe the original author left > the project so the projects original website is gone. > 2. http://www.python.org/dev/peps/pep-0333/ Do you (both) have repos that I could download from? I quite interested in both projects, esp. the WSGI clone. 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 ketil at malde.org Thu Mar 6 06:31:10 2008 From: ketil at malde.org (Ketil Malde) Date: Thu Mar 6 06:28:32 2008 Subject: [Haskell-cafe] SimpleArgs Message-ID: <87ejaoxf5t.fsf@nmd9999.imr.no> Hi, Often when I write small scripts, I find I just want a couple of command line arguments but don't want to go the whole GetOpt route. SimpleArgs is an attempt to make the raw getArgs somewhat less raw, and quick and dirty scripts a bit less dirty without sacrificing the quickness. Since I find this quite useful, I thought I'd advertise the code here, ask what people think, and invite suggestions for improvement. It's at: http://malde.org/~ketil/simpleargs -k -- If I haven't seen further, it is by standing in the footprints of giants From lemming at henning-thielemann.de Thu Mar 6 06:37:33 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu Mar 6 06:34:58 2008 Subject: [Haskell-cafe] SimpleArgs In-Reply-To: <87ejaoxf5t.fsf@nmd9999.imr.no> References: <87ejaoxf5t.fsf@nmd9999.imr.no> Message-ID: On Thu, 6 Mar 2008, Ketil Malde wrote: > Often when I write small scripts, I find I just want a couple of > command line arguments but don't want to go the whole GetOpt route. > SimpleArgs is an attempt to make the raw getArgs somewhat less raw, > and quick and dirty scripts a bit less dirty without sacrificing the > quickness. I also thought command line parsing is cumbersome until I found: http://www.haskell.org/haskellwiki/High-level_option_handling_with_GetOpt From johan.tibell at gmail.com Thu Mar 6 06:40:13 2008 From: johan.tibell at gmail.com (Johan Tibell) Date: Thu Mar 6 06:37:41 2008 Subject: [Haskell-cafe] Starting Haskell with a web application In-Reply-To: <125EACD0CAE4D24ABDB4D148C4593DA9049E92F6@GBLONXMB02.corp.amvescap.net> References: <6cc20cea0803051009y7fedd8a2i304f63ac867c3c23@mail.gmail.com> <47CEEBD7.30005@serpentine.com> <20080305190018.GE16789@scytale.galois.com> <47CEEF5F.8010807@serpentine.com> <396556a20803051125o34ca2197w60773871f7059523@mail.gmail.com> <90889fe70803060116u1d875adbl94f02d77e8039c91@mail.gmail.com> <125EACD0CAE4D24ABDB4D148C4593DA9049E92F6@GBLONXMB02.corp.amvescap.net> Message-ID: <90889fe70803060340m1cfb8c42s7ce540d35fedfb63@mail.gmail.com> > Do you (both) have repos that I could download from? I quite interested > in both projects, esp. the WSGI clone. Yes and no. The code [1] is in my darcs repository but is in an unusable state until I've fixed my incremental parser (in Hyena/Parser.hs) which I plan to do next week. I would like the first release to be nice and polished so I'm trying to not release anything prematurely. 1. http://darcs.johantibell.com/hyena/ From zao at acc.umu.se Thu Mar 6 08:02:45 2008 From: zao at acc.umu.se (Lars Viklund) Date: Thu Mar 6 08:00:20 2008 Subject: [Haskell-cafe] Starting Haskell with a web application In-Reply-To: <47CEEBD7.30005@serpentine.com> References: <6cc20cea0803051009y7fedd8a2i304f63ac867c3c23@mail.gmail.com> <47CEEBD7.30005@serpentine.com> Message-ID: <20080306130245.GB22702@shaka.acc.umu.se> 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 From Malcolm.Wallace at cs.york.ac.uk Thu Mar 6 09:11:57 2008 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Thu Mar 6 09:16:23 2008 Subject: [Haskell-cafe] Google summer of code Message-ID: <20080306141157.2cce4354.Malcolm.Wallace@cs.york.ac.uk> Reply-To: haskell-cafe@haskell.org Google Summer of Code As many of you will already know, Google is running its "Summer of Code" project again this year, and haskell.org is once again going to apply to be a mentoring organisation. Are you a student who would like to earn money for hacking in Haskell? Or are you a non-student who has a cool idea for a coding project but no time to do it yourself? Well, our wiki to gather ideas is now up-and-running again: http://hackage.haskell.org/trac/summer-of-code Add yourself to the list of interested people! Especially potential mentors. There are some ideas still there from last year, in the trac tickets. However, due to the amount of spam accumulating there, I suggest that this year, we use the haskell-cafe email list as a place to put out project ideas, solicit feedback on them, and look for interested people. Prefix any message subject line with with [GSoC] to help others find them. Google will start accepting student applications on 24th March, but now is the time to start gathering thoughts and matching up interesting ideas with interested people. The official timeline is as follows: March 12: Mentoring organization application deadline March 17: List of accepted mentoring organizations published March 24: Student application period opens March 31: Student application deadline Interim Period: we review and rank student proposals April 14: List of accepted student applications published Interim Period: Students learn more about their project communities May 26: Students begin coding; Google begins issuing initial payments July 14: Google begins issuing mid-term payments August 11: Suggested end of coding August 18: Definite end of coding Sept 1: Final evaluation deadline; Google begins issuing final payments Sept 3: Students upload code to Google (required) Regards, Malcolm From ndmitchell at gmail.com Thu Mar 6 09:47:09 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Thu Mar 6 09:44:33 2008 Subject: [Haskell-cafe] Re: [Haskell] Google summer of code In-Reply-To: <20080306141157.2cce4354.Malcolm.Wallace@cs.york.ac.uk> References: <20080306141157.2cce4354.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <404396ef0803060647o55e2561bkc1c55b8c77c5ce5@mail.gmail.com> Hi > There are some ideas still there from last year, in the trac tickets. > However, due to the amount of spam accumulating there, I suggest that > this year, we use the haskell-cafe email list as a place to put out > project ideas, solicit feedback on them, and look for interested people. > Prefix any message subject line with with [GSoC] to help others find > them. I like the idea of a bug tracker for these projects, but trac is obviously not sufficient. Why not use the best bug tracker there is, namely the Google Code Bug Tracker. I worry that emails will end up getting lost in the crowd, or that the replies from the list may not reflect the view of the potential mentors accurately. Thanks Neil From magnus at therning.org Thu Mar 6 10:46:44 2008 From: magnus at therning.org (Magnus Therning) Date: Thu Mar 6 10:44:08 2008 Subject: [Haskell-cafe] CABAL: conditional executable? In-Reply-To: <889D9BE0-29FC-4F34-A574-7BDD32AF8F11@googlemail.com> References: <47CD03DC.3000402@therning.org> <6D5A5CD1-080A-4874-87DE-6CA4D64B9230@googlemail.com> <889D9BE0-29FC-4F34-A574-7BDD32AF8F11@googlemail.com> Message-ID: On 3/4/08, Thomas Schilling wrote: > > > On 4 mar 2008, at 11.37, Magnus Therning wrote: > > > On 3/4/08, Thomas Schilling wrote: > > executable foo > > main-is: bla > > if !os(windows): > > buildable: false > > > > Unfortunately this gives rather unhelpful error messages when used > > with flags, but it works well enough for now. > > > > / Thomas > > > > Hmmm, I don't seem to get this to work the way I want it. I get a > > "Parse of field 'buildable' failed:" which means configure failed > > and then I can't proceed to build the second executable, bar, in > > the same package. > > > Oh, right. That's a bug in Cabal 1.2 (fixed in HEAD). Use: > > buildable: False OK, that solved that problem, now onto the next. Rather surprisingly to me, buildability has an impact on what's included in the source tar-ball created with "sdist". What's the reason for that behaviour? /M -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080306/b83e9687/attachment.htm From ndmitchell at gmail.com Thu Mar 6 10:47:46 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Thu Mar 6 10:45:19 2008 Subject: [Haskell-cafe] [GSoC] Project proposal: Hoogle 4 Message-ID: <404396ef0803060747i6d3dc5f7o6edc8013be9cd7ba@mail.gmail.com> Hi I would like to be a Summer of Code student, doing the project "Hoogle 4" (http://haskell.org/hoogle/) PROJECT GOALS: There are two main themes: 1) Make Hoogle more useful to the community, along the same path as it is currently used. 2) Make Hoogle suitable to use as the standard interface to Hackage. This requires adding the following features to Hoogle, to form a Hoogle 4 release: * Faster searching (1000x faster at least, perhaps more like 1000000x for text searching) * Generalised text searching (i.e. searching .cabal fields) * Removal of all bugs :-) * Support for higher-kinded type classes (i.e. Monads) * Support for some Haskell type extensions (i.e. Multi-Parameter type classes) * Support for multiple packages * Generalised interface to all of Cabal Progress on Hoogle 4 has already started, but has currently stalled due to lack of time. I am writing up my PhD currently, and will be available to start at the beginning of the Summer to work on Hoogle. Duncan Coutts has agreed to mentor this project. The position of backup mentor is still available. I do not expect to need a great deal of supervision :-) Please respond with any suggestions, requests for further information or just general comments. Thanks Neil From magnus at therning.org Thu Mar 6 11:01:32 2008 From: magnus at therning.org (Magnus Therning) Date: Thu Mar 6 10:58:56 2008 Subject: [Haskell-cafe] CABAL: conditional executable? In-Reply-To: References: <47CD03DC.3000402@therning.org> <6D5A5CD1-080A-4874-87DE-6CA4D64B9230@googlemail.com> <889D9BE0-29FC-4F34-A574-7BDD32AF8F11@googlemail.com> Message-ID: On 3/6/08, Magnus Therning wrote: > > On 3/4/08, Thomas Schilling wrote: > > > > > On 4 mar 2008, at 11.37, Magnus Therning wrote: > > > > > On 3/4/08, Thomas Schilling wrote: > > > executable foo > > > main-is: bla > > > if !os(windows): > > > buildable: false > > > > > > Unfortunately this gives rather unhelpful error messages when used > > > with flags, but it works well enough for now. > > > > > > / Thomas > > > > > > Hmmm, I don't seem to get this to work the way I want it. I get a > > > "Parse of field 'buildable' failed:" which means configure failed > > > and then I can't proceed to build the second executable, bar, in > > > the same package. > > > > > > Oh, right. That's a bug in Cabal 1.2 (fixed in HEAD). Use: > > > > buildable: False > > > OK, that solved that problem, now onto the next. Rather surprisingly to > me, buildability has an impact on what's included in the source tar-ball > created with "sdist". What's the reason for that behaviour? > It seems the source isn't even included on the platform where the executable *is* buildable. I'll see if I can put together a small example and raise a bug. /M -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080306/c3f6659b/attachment.htm From magnus at therning.org Thu Mar 6 11:29:21 2008 From: magnus at therning.org (Magnus Therning) Date: Thu Mar 6 11:26:46 2008 Subject: [Haskell-cafe] CABAL: conditional executable? In-Reply-To: References: <47CD03DC.3000402@therning.org> <6D5A5CD1-080A-4874-87DE-6CA4D64B9230@googlemail.com> <889D9BE0-29FC-4F34-A574-7BDD32AF8F11@googlemail.com> Message-ID: On 3/6/08, Magnus Therning wrote: > > On 3/6/08, Magnus Therning wrote: > > > > On 3/4/08, Thomas Schilling wrote: > > > > > > > > On 4 mar 2008, at 11.37, Magnus Therning wrote: > > > > > > > On 3/4/08, Thomas Schilling wrote: > > > > executable foo > > > > main-is: bla > > > > if !os(windows): > > > > buildable: false > > > > > > > > Unfortunately this gives rather unhelpful error messages when used > > > > with flags, but it works well enough for now. > > > > > > > > / Thomas > > > > > > > > Hmmm, I don't seem to get this to work the way I want it. I get a > > > > "Parse of field 'buildable' failed:" which means configure failed > > > > and then I can't proceed to build the second executable, bar, in > > > > the same package. > > > > > > > > > Oh, right. That's a bug in Cabal 1.2 (fixed in HEAD). Use: > > > > > > buildable: False > > > > > > OK, that solved that problem, now onto the next. Rather surprisingly to > > me, buildability has an impact on what's included in the source tar-ball > > created with "sdist". What's the reason for that behaviour? > > > > It seems the source isn't even included on the platform where the > executable *is* buildable. I'll see if I can put together a small example > and raise a bug. > Done, http://hackage.haskell.org/trac/hackage/ticket/257 /M -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080306/1bb63d03/attachment.htm From clawsie at fastmail.fm Thu Mar 6 11:57:44 2008 From: clawsie at fastmail.fm (brad clawsie) Date: Thu Mar 6 11:55:15 2008 Subject: [Haskell-cafe] Connection helpers: for people interested in network code Message-ID: <86wsofzt6f.fsf@jobbicycle.corp.yahoo.com> > I wonder, though, what happened to the curl bindings for Haskell? i offered some time ago to look at building a cabal package and documentation for this. i would offer up excuses as to why this hasn't appeared yet, but between kids, work and ski season i just haven't allocated the time yet. sorry to all. i still hope to look into this, but fair to say i dropped the ball. From stefan at cs.uu.nl Thu Mar 6 12:18:44 2008 From: stefan at cs.uu.nl (Stefan Holdermans) Date: Thu Mar 6 12:16:08 2008 Subject: [Haskell-cafe] Small displeasure with associated type synonyms Message-ID: Dear all, I was doing a little experimentation with associated type synonyms and ran into a small but unforeseen annoyance. The following, contrived, example snippets illustrate my pain: First, let us declare some of the simplest classes exhibiting associated type synonyms that I can think of, class C a where type T a val :: T a together with a trivial instance for nullary products: instance C () where type T () = () val = () But then, let us try an instance for binary products: instance (C a, C b) => C (a, b) where type T (a, b) = (T a, T b) val = (val, val) I really thought this would work out nicely, but GHC (version 6.8.2) gracefully gives me Couldn't match expected type `T a2' against inferred type `T a' Expected type: T (a2, b) Inferred type: (T a, T a1) In the expression: (val, val) In the definition of `val': val = (val, val) Couldn't match expected type `T b' against inferred type `T a1' Expected type: T (a2, b) Inferred type: (T a, T a1) In the expression: (val, val) In the definition of `val': val = (val, val) while I think I deserve better than that. Can someone (Tom?) please explain (a) why the required unifications fail, (b) whether or not it is reasonable to expect the unifications to succeed, and (c) how I can overcome problems like these? Surely, I can have val take a dummy argument, but I am hoping for something a bit more elegant here. I tried lexically scoped type variables, but to no avail: instance forall a b. (C a, C b) => C (a, b) where type T (a, b) = (T a, T b) val = (val :: T a, val :: T b) gives me Couldn't match expected type `T a2' against inferred type `T a' In the expression: val :: T a In the expression: (val :: T a, val :: T b) In the definition of `val': val = (val :: T a, val :: T b) etc. Cheers, Stefan From agl at imperialviolet.org Thu Mar 6 12:19:14 2008 From: agl at imperialviolet.org (Adam Langley) Date: Thu Mar 6 12:16:40 2008 Subject: [Haskell-cafe] Starting Haskell with a web application In-Reply-To: <125EACD0CAE4D24ABDB4D148C4593DA9049E92F6@GBLONXMB02.corp.amvescap.net> References: <6cc20cea0803051009y7fedd8a2i304f63ac867c3c23@mail.gmail.com> <47CEEBD7.30005@serpentine.com> <20080305190018.GE16789@scytale.galois.com> <47CEEF5F.8010807@serpentine.com> <396556a20803051125o34ca2197w60773871f7059523@mail.gmail.com> <90889fe70803060116u1d875adbl94f02d77e8039c91@mail.gmail.com> <125EACD0CAE4D24ABDB4D148C4593DA9049E92F6@GBLONXMB02.corp.amvescap.net> Message-ID: <396556a20803060919w40dbd0c1nc38bb2201d5469e0@mail.gmail.com> On Thu, Mar 6, 2008 at 3:08 AM, Bayley, Alistair wrote: > Do you (both) have repos that I could download from? I quite interested > in both projects, esp. the WSGI clone. There was a Hackage release of network-minihttp[1], which I think would serve files from the filesystem quite happily. The darcs repo is just a mess at the moment. (darcs.imperialviolet.org/network-minihttp) [1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/network-minihttp-0.1 AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org From jgm at berkeley.edu Thu Mar 6 12:31:52 2008 From: jgm at berkeley.edu (John MacFarlane) Date: Thu Mar 6 12:27:41 2008 Subject: [Haskell-cafe] Re: ANN: Parsec 3.0.0 In-Reply-To: <1204786736.5936.18.camel@derek-laptop> References: <1204786736.5936.18.camel@derek-laptop> Message-ID: <20080306173151.GA20692@berkeley.edu> > * A "compatibility" Text.ParserCombinators.Parsec tree for the old > Parsec. It's not perfect, but it should work with most Parsec 2 > code. A data point: I recompiled pandoc with the new Text.ParserCombinators.Parsec compatibility module, and performance is much worse than with parsec 2.1 (approximately twice as slow on my standard benchmark). That aside, this is a very welcome release! John From hpacheco at gmail.com Thu Mar 6 13:08:00 2008 From: hpacheco at gmail.com (Hugo Pacheco) Date: Thu Mar 6 13:05:24 2008 Subject: [Haskell-cafe] Small displeasure with associated type synonyms In-Reply-To: References: Message-ID: <7b92c2840803061008m33e4743fh195bc483805e7ddb@mail.gmail.com> I don't know if this is exactly what you were expecting as a dummy argument, but I solve this kind of issues like this: _L = undefined class C a where type TT a val :: a -> TT a instance C () where type TT () = () val _ = () instance (C a, C b) => C (a, b) where type TT (a,b) = (TT a, TT b) val _ = (val (_L :: a),val (_L :: b)) Why normal unification (val :: TT a) does not work I can't say why, but this kind of behavior is not solely for type families. Cheers, hugo -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080306/ffd6559a/attachment.htm From bjorn at bringert.net Thu Mar 6 13:34:50 2008 From: bjorn at bringert.net (Bjorn Bringert) Date: Thu Mar 6 13:32:15 2008 Subject: [Haskell-cafe] Starting Haskell with a web application In-Reply-To: <20080305190018.GE16789@scytale.galois.com> References: <6cc20cea0803051009y7fedd8a2i304f63ac867c3c23@mail.gmail.com> <47CEEBD7.30005@serpentine.com> <20080305190018.GE16789@scytale.galois.com> Message-ID: On Wed, Mar 5, 2008 at 8:00 PM, Don Stewart wrote: > bos: > > > Jonathan Gardner wrote: > > > > > Where do I get started in writing a web app with Haskell? I am looking > > > more for a framework like Pylons and less like Apache, if that helps. > > > > The closest we currently have to a web framework is Happs > > (http://happs.org/), but it uses the kitchen sink of advanced and > > unusual language extensions, which I think might be why it hasn't got > > all that much momentum. > > > > 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. > > Perhaps it is time for a haskell web apps wiki page, if there isn't one, > outlining the approaches, with a structure like: > > * HAppS > * CGI > - FastCGI > > * Database solutions > - HDBC > - Takusen > > * Templating > - HStringTemplate > > * JSON rpc > > etc. There's this: http://www.haskell.org/haskellwiki/Practical_web_programming_in_Haskell It doesn't mention many of the above, but they would be nice additions. The page should probably be split into several though. /Bjorn From Tom.Schrijvers at cs.kuleuven.be Thu Mar 6 14:14:55 2008 From: Tom.Schrijvers at cs.kuleuven.be (Tom Schrijvers) Date: Thu Mar 6 14:13:39 2008 Subject: [Haskell-cafe] Re: Small displeasure with associated type synonyms In-Reply-To: References: Message-ID: Stefan, > I tried lexically scoped type variables, but to no avail: > > instance forall a b. (C a, C b) => C (a, b) where > type T (a, b) = (T a, T b) > val = (val :: T a, val :: T b) The problem is ambiguity. The type checker can't determine which val function to use, i.e. which dictionary to pass to val. Assume: instance C Int where type T Int = Int val = 0 instance C Bool where type T Bool = Int val = 1 Now, if you want some val :: Int, which one do you get? The one of C Int of C Bool? Depending on the choice you may get a different result. We can't have that in a deterministic functional language. Hence the error. Adding a type signature doesn't change the matter. Providing an additional argument, as you propose, resolves the ambiguity. I hope this helps. Cheers, Tom -- Tom Schrijvers Department of Computer Science K.U. Leuven Celestijnenlaan 200A B-3001 Heverlee Belgium tel: +32 16 327544 e-mail: tom.schrijvers@cs.kuleuven.be url: http://www.cs.kuleuven.be/~toms/ From jgbailey at gmail.com Thu Mar 6 14:37:04 2008 From: jgbailey at gmail.com (Justin Bailey) Date: Thu Mar 6 14:34:26 2008 Subject: [Haskell-cafe] If Version Control Systems were Airlines Message-ID: Way off topic, but this is the cafe. The below is well worth reading. http://changelog.complete.org/posts/698-If-Version-Control-Systems-were-Airlines.html For the click-impaired, here's Darcs Airlines: "Darcs Airlines: Unlike every other airline, this one uses physicists instead of engineers to design its airplanes. One brilliant Darcs physicist has finally come up with The Theory of Everything, and as such, Darcs knows where you want to go before even you do. Darcs airlines prides itself on customer service, and asks your preference for even the tiniest details about your trip. Each seat pocket features a copy of the Theory of Everything for your reading enjoyment, but nobody actually understands it. Occasionally, you will find that Darcs pilots get into angry conflicts with the control tower in mid-flight. This results in the control tower revoking your permission to land. Legend has it that one Darcs pilot of a plane with exceptionally large fuel tanks actually resolved his conflict with the tower and landed two weeks after taking off. Experienced Darcs users board with several parachutes: one for themselves, and a few more for the newbies. The Darcs physicists claim that the Theory of Everything predicted the pilots would act this way, and that all pilots eventually act this way throughout the entire universe. They toil day and night finding a way to adjust the gravitational constant of the universe, thereby reducing the anger factor of the pilots. Main competitor: OS/2 airlines." Justin From haskell at list.mightyreason.com Thu Mar 6 14:51:11 2008 From: haskell at list.mightyreason.com (ChrisK) Date: Thu Mar 6 14:48:49 2008 Subject: [Haskell-cafe] Re: Small displeasure with associated type synonyms In-Reply-To: References: Message-ID: <47D04B2F.5090609@list.mightyreason.com> Tom Schrijvers wrote: > Stefan, > >> I tried lexically scoped type variables, but to no avail: >> >> instance forall a b. (C a, C b) => C (a, b) where >> type T (a, b) = (T a, T b) >> val = (val :: T a, val :: T b) > > The problem is ambiguity. The type checker can't determine which val > function to use, i.e. which dictionary to pass to val. Assume: > > instance C Int where > type T Int = Int > val = 0 > > instance C Bool where > type T Bool = Int > val = 1 > > Now, if you want some val :: Int, which one do you get? The one of C Int > of C Bool? Depending on the choice you may get a different result. We > can't have that in a deterministic functional language. Hence the error. > Adding a type signature doesn't change the matter. I don't see how your example explains this particular error. I agree Int cannot be generalized to (T Int) or (T Bool). I see Stefan's local type signature is not (val :: a) like your (val ::Int) but (val :: T a) which is a whole different beast. And (T a) is the type that ghc should assign here. The C (a,b) instance wants val :: T (a,b), The T (a,b) is declared as "(T a, T b)". The annotated val returns "(T a, T b)". One never needs the sort of Int to (T Int) generalization. So what is a better explanation or example to clarify why GHC cannot accept the original code? -- Chris From Tom.Schrijvers at cs.kuleuven.be Thu Mar 6 15:41:00 2008 From: Tom.Schrijvers at cs.kuleuven.be (Tom Schrijvers) Date: Thu Mar 6 15:39:35 2008 Subject: [Haskell-cafe] Re: Small displeasure with associated type synonyms In-Reply-To: <47D04B2F.5090609@list.mightyreason.com> References: <47D04B2F.5090609@list.mightyreason.com> Message-ID: > I don't see how your example explains this particular error. > I agree Int cannot be generalized to (T Int) or (T Bool). Generalized is not the right word here. In my example T Int, T Bool and Int are all equivalent. > I see Stefan's local type signature is not (val :: a) like your (val ::Int) > but (val :: T a) which is a whole different beast. Not all that different. As in my example the types T Int, T Bool and Int are equivalent, whether one writes val :: Int, val :: T Int or val :: T Bool. My point is that writing val :: T Int or val :: T Bool does not help determining whether one should pick the val implementation of instance C Int or C Bool. > And (T a) is the type that ghc should assign here. As my example tries to point out, there is not one single syntactic form to denote a type. Consider the val of in the first component. Because of val's signature in the type class the type checker infers that the val expression has a type equivalent to T a2 for some a2. The type checker also expects a type equivalent to T a, either because of the type annotation or because of the left hand side. So the type checker must solve the equation T a ~ T a2 for some as yet to determine type a2 (a unification variable). This is precisely where the ambiguity comes in. The type constructor T is not injective. That means that the equation may hold for more than one value of a2 (e.g. for T Int ~ T a2, a2 could be Int or Bool). Hence, the type checker complains: Couldn't match expected type `T a2' against inferred type `T a'. Maybe you don't care what type is chosen, if multiple ones are possible. My example tried to show that this can effect the values computed by your program. So it does matter. For this particular example, it seems that the type checker does not have have more than alternative for a2 in scope. However, it is not aware of that fact. It uniformly applies the same general strategy for solving equations in all contexts. This is a trade-off in type system complexity vs. expressivity. There is an opportunity for exploring another point in the design space here. Tom -- Tom Schrijvers Department of Computer Science K.U. Leuven Celestijnenlaan 200A B-3001 Heverlee Belgium tel: +32 16 327544 e-mail: tom.schrijvers@cs.kuleuven.be url: http://www.cs.kuleuven.be/~toms/ From haskell at list.mightyreason.com Thu Mar 6 15:57:21 2008 From: haskell at list.mightyreason.com (ChrisK) Date: Thu Mar 6 15:54:57 2008 Subject: [Haskell-cafe] Re: Small displeasure with associated type synonyms In-Reply-To: References: <47D04B2F.5090609@list.mightyreason.com> Message-ID: <47D05AB1.20706@list.mightyreason.com> Okay, I get the difference. The "T a" annotation in "val :: T a)"and "val :: T a" does not help choose the "C a" dictionary. But the "val :: a-> T a" and "val (undefined :: a)" allows "a" to successfully choose the "C a" dictionary. val :: T a fixes "T a" but does not imply "C a". (undefined :: a) fixes "a" and does imply "C a". I now see how the functional dependency works here (which I should have tried to do in the first place -- I should have thought more and relied on the mailing list less). "class C a b | a -> b" is here "class C a where type T a = b". So only knowing "T a" or "b" does not allow "a" to be determined. -- Chris Tom Schrijvers wrote: >> I don't see how your example explains this particular error. >> I agree Int cannot be generalized to (T Int) or (T Bool). > > Generalized is not the right word here. In my example T Int, T Bool and > Int are all equivalent. > >> I see Stefan's local type signature is not (val :: a) like your (val >> ::Int) but (val :: T a) which is a whole different beast. > > Not all that different. As in my example the types T Int, T Bool and Int > are equivalent, whether one writes val :: Int, val :: T Int or val :: T > Bool. My point is that writing val :: T Int or val :: T Bool does not > help determining whether one should pick the val implementation of > instance C Int or C Bool. > >> And (T a) is the type that ghc should assign here. > > As my example tries to point out, there is not one single syntactic form > to denote a type. > > Consider the val of in the first component. Because of val's signature > in the type class the type checker infers that the val expression has a > type equivalent to T a2 for some a2. The type checker also expects a > type equivalent to T a, either because of the type annotation or because > of the left hand side. So the type checker must solve the equation T a ~ > T a2 for some as yet to determine type a2 (a unification variable). This > is precisely where the ambiguity comes in. The type constructor T is not > injective. That means that the equation may hold for more than one value > of a2 (e.g. for T Int ~ T a2, a2 could be Int or Bool). Hence, the type > checker complains: > > Couldn't match expected type `T a2' against inferred type `T a'. > > Maybe you don't care what type is chosen, if multiple ones are possible. > My example tried to show that this can effect the values computed by > your program. So it does matter. > > For this particular example, it seems that the type checker does not > have have more than alternative for a2 in scope. However, it is not > aware of that fact. It uniformly applies the same general strategy for > solving equations in all contexts. This is a trade-off in type system > complexity vs. expressivity. > > There is an opportunity for exploring another point in the design space > here. > > Tom > > -- > Tom Schrijvers > > Department of Computer Science > K.U. Leuven > Celestijnenlaan 200A > B-3001 Heverlee > Belgium > > tel: +32 16 327544 > e-mail: tom.schrijvers@cs.kuleuven.be > url: http://www.cs.kuleuven.be/~toms/ From stefan at cs.uu.nl Thu Mar 6 17:20:04 2008 From: stefan at cs.uu.nl (Stefan Holdermans) Date: Thu Mar 6 17:17:30 2008 Subject: [Haskell-cafe] Re: Small displeasure with associated type synonyms In-Reply-To: References: Message-ID: <8C8EBE19-330D-4DC5-ACC9-76442242CAB6@cs.uu.nl> Tom, Thanks for your quick answer. > The problem is ambiguity. The type checker can't determine which val > function to use, i.e. which dictionary to pass to val. I see. Still, maybe a type-error message in terms of good old "unresolved top-level overloading" would be a bit more useful here... ;-) Cheers, Stefan From clawsie at fastmail.fm Thu Mar 6 18:09:11 2008 From: clawsie at fastmail.fm (brad clawsie) Date: Thu Mar 6 18:06:41 2008 Subject: [Haskell-cafe] Connection helpers: for people interested in network code In-Reply-To: (Gwern Branwen's message of "Thu\, 6 Mar 2008 18\:03\:10 -0500") References: <86wsofzt6f.fsf@jobbicycle.corp.yahoo.com> Message-ID: <86od9rxxew.fsf@jobbicycle.corp.yahoo.com> "Gwern Branwen" writes: >> i offered some time ago to look at building a cabal package and >> documentation for this. i would offer up excuses as to why this hasn't >> appeared yet, but between kids, work and ski season i just haven't >> allocated the time yet. sorry to all. i still hope to look into this, >> but fair to say i dropped the ball. > > Dunno. I just downloaded the git repo, and I'm not sure what's > stopping anyone from uploading it to Hackage. It builds cleanly and > with essentially no warning on 6.8.2, the Haddock docs build, and so > on. The Cabal file itself is quite good; out of boredom, I tweaked it > a little: awesome! that means someone has indeed recognized my lameness and subbed in to do what i didn't. thanks to whoever you are! sorry again for promising and not delivering [gwern, hope you don't mind if i redirect your personally reply to the list for context preservation] From chak at cse.unsw.edu.au Thu Mar 6 19:55:16 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Thu Mar 6 19:52:41 2008 Subject: [Haskell-cafe] Issues(Bugs?) with GHC Type Families In-Reply-To: <7b92c2840803051727l6a31fd78j63c756ee9a1973ca@mail.gmail.com> References: <7b92c2840803030935t6ed5d2a6ne63d5f8b3d5fe917@mail.gmail.com> <7b92c2840803051727l6a31fd78j63c756ee9a1973ca@mail.gmail.com> Message-ID: <13737842-6754-4401-8F78-9A215F7BC0FB@cse.unsw.edu.au> Hugo Pacheco: > Just something I have been wondering. > > I would like to implement somehting like: > > type family F a :: * -> * > ... > class C a b where ... > instance (F a ~ F b) => C a b where ... > > But apparently type equality coercions can not be used as a single > context. If I enable -fallow-undecidable-instances, whenever the > equality does not hold, the instance returns a compile error, what > does make sense. > > Is there any way I could overcome this? I think I don't understand your question fully. This class instance requires both -XFlexibleInstances and -fallow-undecidable-instances to compile. If the equality does not hold, you should get a type error because your program is not type correct. So, what is it that you would like different? Manuel From chak at cse.unsw.edu.au Thu Mar 6 20:19:27 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Thu Mar 6 20:17:06 2008 Subject: [Haskell-cafe] Re: Small displeasure with associated type synonyms In-Reply-To: <8C8EBE19-330D-4DC5-ACC9-76442242CAB6@cs.uu.nl> References: <8C8EBE19-330D-4DC5-ACC9-76442242CAB6@cs.uu.nl> Message-ID: <10916720-EAF8-407A-BAF1-B58823121359@cse.unsw.edu.au> Stefan Holdermans: >> The problem is ambiguity. The type checker can't determine which >> val function to use, i.e. which dictionary to pass to val. > > I see. Still, maybe a type-error message in terms of good old > "unresolved top-level overloading" would be a bit more useful > here... ;-) I agree the error message is appalling. Could you put this as a bug in the bug tracker? Thanks, Manuel From hpacheco at gmail.com Thu Mar 6 20:37:01 2008 From: hpacheco at gmail.com (Hugo Pacheco) Date: Thu Mar 6 20:34:27 2008 Subject: [Haskell-cafe] Issues(Bugs?) with GHC Type Families In-Reply-To: <13737842-6754-4401-8F78-9A215F7BC0FB@cse.unsw.edu.au> References: <7b92c2840803030935t6ed5d2a6ne63d5f8b3d5fe917@mail.gmail.com> <7b92c2840803051727l6a31fd78j63c756ee9a1973ca@mail.gmail.com> <13737842-6754-4401-8F78-9A215F7BC0FB@cse.unsw.edu.au> Message-ID: <7b92c2840803061737g7fd31713tc8ba20be86de9edf@mail.gmail.com> > > > > >If the equality does not hold, you should get a type error because > >your program is not type correct. So, what is it that you would like > >different? > > I would simply like the compiler not to use that instance if the equality > constraint does not hold, like some another instance dependency constraint, > but I assume that is not possible. hugo -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080307/53cfdb1a/attachment.htm From ivan.miljenovic at gmail.com Thu Mar 6 20:45:12 2008 From: ivan.miljenovic at gmail.com (Ivan Miljenovic) Date: Thu Mar 6 20:42:34 2008 Subject: [Haskell-cafe] Analysing Haskell with Graph Theory Message-ID: Back in December, I posted that I was thinking about doing a project for my honours year on using graph theory for analysis on Haskell source code, amongst others: http://thread.gmane.org/gmane.comp.lang.haskell.cafe/32912 Well, I've officially started this project, and my supervisor and I have come up with the following functions that would probably be relevant to analysing _any_ piece of source code (the actual code will be tentatively stored as a directed graph with the nodes being functions and the edges being function calls, i.e. if f calls g, there is a directed edge from f to g): * root finding -> find nodes with no incoming edges (in a program, you'd ideally want only main to be such a node) * cycle detection -> find a possibly recursive cycle in your code: if the cycle is too big, then you may wish to consider refactoring * depth analysis -> find leaves that have a depth from the root node that is extremely large compared to the others (if a function is 50 calls down from main compared to an average of 15, you may wish to refactor) * chain detection -> find connected functions that have only one incoming and one outgoing edge, e.g. : f -> g -> h : if g isn't used anywhere else, you may wish to combine it inside either f or g * node popularity -> get a count of how many functions use a particular function and how many other functions it calls (related to chain detection above) * clique detection -> probably not as relevant to source code, but if you have a large number of functions that are all pairwise co-recursive than you may wish to refactor Can anyone think of any other kind of functions that would be useful in this kind of source code analysis? Also, I'm going to be using haskell-src for for the parsing of the Haskell code so that I don't waste my time writing a parser, when my project is technically on the graph-theory side of things. I know that it focuses mainly on H98 with only a few extensions... is this likely to be a problem if I want to try running my eventual program on say ghc or xmonad as test examples? -- Ivan Lazar Miljenovic From hpacheco at gmail.com Thu Mar 6 21:30:41 2008 From: hpacheco at gmail.com (Hugo Pacheco) Date: Thu Mar 6 21:28:04 2008 Subject: [Haskell-cafe] Issues(Bugs?) with GHC Type Families In-Reply-To: <7b92c2840803061737g7fd31713tc8ba20be86de9edf@mail.gmail.com> References: <7b92c2840803030935t6ed5d2a6ne63d5f8b3d5fe917@mail.gmail.com> <7b92c2840803051727l6a31fd78j63c756ee9a1973ca@mail.gmail.com> <13737842-6754-4401-8F78-9A215F7BC0FB@cse.unsw.edu.au> <7b92c2840803061737g7fd31713tc8ba20be86de9edf@mail.gmail.com> Message-ID: <7b92c2840803061830rf507765yb054b7aedd2fdffd@mail.gmail.com> What I said is not true since overlapping instances are not that much decidable. Btw, in previous versions of GHC this worked well, but now I suppose order does not suffices to define instances overlapping How could I compile such an example, assuming that I want to use the instance C String for Strings only and the more general instance for the rest? class C a where c :: a instance C Char where c = 'a' instance C a => C [a] where c = [c :: a,c :: a] instance C String where c = "a" cc = c :: String Sorry for the newbie question. hugo -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080307/64dc4dfa/attachment.htm From j.vimal at gmail.com Thu Mar 6 21:35:32 2008 From: j.vimal at gmail.com (Vimal) Date: Thu Mar 6 21:32:58 2008 Subject: [Haskell-cafe] Analysing Haskell with Graph Theory In-Reply-To: References: Message-ID: > be tentatively stored as a directed graph with the nodes being > functions and the edges being function calls, i.e. if f calls g, there > is a directed edge from f to g): > Will the graph be completely computed before the analysis begins? Or will you try to build the graph lazily as and when you require more information? And > * root finding -> find nodes with no incoming edges (in a program, > you'd ideally want only main to be such a node) > > * cycle detection -> find a possibly recursive cycle in your code: if > the cycle is too big, then you may wish to consider refactoring > > * depth analysis -> find leaves that have a depth from the root node > that is extremely large compared to the others (if a function is 50 > calls down from main compared to an average of 15, you may wish to > refactor) > > * chain detection -> find connected functions that have only one > incoming and one outgoing edge, e.g. : f -> g -> h : if g isn't used > anywhere else, you may wish to combine it inside either f or g > > * node popularity -> get a count of how many functions use a > particular function and how many other functions it calls (related to > chain detection above) > > * clique detection -> probably not as relevant to source code, but if > you have a large number of functions that are all pairwise > co-recursive than you may wish to refactor > > Can anyone think of any other kind of functions that would be useful > in this kind of source code analysis? > Are you looking for Haskell functions that can be used to solve the above problems? I guess once you come up with the algorithms, translating it into Haskell shouldnt be much of a problem. -- Vimal From ryani.spam at gmail.com Thu Mar 6 21:52:26 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Thu Mar 6 21:49:50 2008 Subject: [Haskell-cafe] Issues(Bugs?) with GHC Type Families In-Reply-To: <7b92c2840803061830rf507765yb054b7aedd2fdffd@mail.gmail.com> References: <7b92c2840803030935t6ed5d2a6ne63d5f8b3d5fe917@mail.gmail.com> <7b92c2840803051727l6a31fd78j63c756ee9a1973ca@mail.gmail.com> <13737842-6754-4401-8F78-9A215F7BC0FB@cse.unsw.edu.au> <7b92c2840803061737g7fd31713tc8ba20be86de9edf@mail.gmail.com> <7b92c2840803061830rf507765yb054b7aedd2fdffd@mail.gmail.com> Message-ID: <2f9b2d30803061852w2978d312y97c9a445584f589f@mail.gmail.com> 2008/3/6 Hugo Pacheco : > How could I compile such an example, assuming that I want to use the > instance C String for Strings only and the more general instance for the > rest? > class C a where > c :: a > instance C Char where > c = 'a' > instance C a => C [a] where > c = [c :: a,c :: a] > instance C String where > c = "a" > cc = c :: String This is actually a general issue with the way typeclasses are defined in Haskell; the accepted solution is what the "Show" typeclass does: > class C a where > c :: a > cList :: [a] > cList = [c,c] > instance C Char where > c = 'a' > cList = "a" -- replaces instance for String above > instance C a => C [a] where > c = cList > cc = c :: String I don't really like this solution; it feels like a hack and it relies on knowing when you define the typeclass what sort of overlap you expect. I wish there was some form of instance declaration that let you do case analysis; something similar to the following: instances C [a] where instance C String where c = "a" instance C a => C [a] where c = [c,c] instance Num a => C [a] where c = [0] When trying to find a constraint for C [a] for some type a, the instances would be checked in order: 1) If a was Char, the first instance would be selected. 2) Otherwise, if there was an instance for C a, the second instance would be selected. 3) Otherwise, if there was an instance for Num a, the third instance would be selected. 4) Otherwise a type error would occur. Then overlapping instances wouldn't be required nearly as often; the relevant instances would all have to be defined in one place, but that's often the case anyways. In exchange for giving up some of the openness of typeclasses, you would get the benefit of being able to have better control over instance definitions. You could also use this to create "closed" typeclasses using "instances C a where ..."; the compiler would then know that all possible instances were defined at that location; any other definition would clearly overlap and so the compiler could rule out their existence immediately. There might be some benefit in this case in terms of removing ambiguities that currently arise due to open typeclasses. -- ryan From golubovsky at gmail.com Thu Mar 6 22:05:01 2008 From: golubovsky at gmail.com (Dimitry Golubovsky) Date: Thu Mar 6 22:02:25 2008 Subject: [Haskell-cafe] "Hello World" in Haskell for web browser Message-ID: Hi, I have noticed that some people tried to compile a traditional Haskell program using IO monad to show "Hello World" using Yhc Web Service. Thanks for your interest, and here are some clues. The programming paradigm chosen for Haskell Web programming is not based on monads. It is based on CPS-style calls to DOM functions by Haskell code compiled to Javascript. Further on, additional layers may stack up (such as Haskell Web Toolkit) to provide more convenient APIs, but DOM is the basis. So here is an example of "Hello World" program written this way: -- begin pasteable code -- module HelloWorldDOM where import CPS import UnsafeJS import CDOM.Level2.DomUtils import DOM.Level2.Dom import DOM.Level2.Html2 import DOM.Level2.HTMLElement import DOM.Level2.HTMLDivElement main = getHTMLDocument $ \doc -> documentBody doc $ \body -> mkText doc "Hello World" $ \txt -> mkDiv doc $ \dv -> addChild txt dv $ \_ -> addChild dv body $ id -- end pasteable code -- The meaning of this: * get reference to the HTML document node first (it is the parent of everything), * extract the tag node, create at text element with "Hello World", * create a
tag node, * insert the text node into div, * insert div into body Or, same in HTML:
Hello World
but filled in dynamically. Using Haskell Web Toolkit API, the same may be expressed in more compact fashion: -- begin pasteable code -- module HelloWorldHsWTK where import DOM.Level2.HTMLDivElement import Graphics.UI.HsWTK main = docBodyC (mkDiv |<< textP "Hello World") -- end pasteable code -- Here, docBodyC is roughly equivalent of the first two DOM calls, mkDiv is same as above, |<< means "insert into container", and textP is a wrapper around mkText. Earlier, I posted the link to Haddock-generated documentation which also includes the Haskell DOM API. Here it is again: http://www.golubovsky.org:5984/_utils/yhcws/index.html Hopefully this example along with the documentation provided helps shed some light on Haskell Web programming techniques. Feel free to ask questions. Thanks. -- Dimitry Golubovsky Anywhere on the Web From duncan.coutts at worc.ox.ac.uk Thu Mar 6 22:08:59 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Mar 6 22:06:22 2008 Subject: [Haskell-cafe] CABAL: conditional executable? In-Reply-To: References: <47CD03DC.3000402@therning.org> <6D5A5CD1-080A-4874-87DE-6CA4D64B9230@googlemail.com> <889D9BE0-29FC-4F34-A574-7BDD32AF8F11@googlemail.com> Message-ID: <1204859339.11558.379.camel@localhost> On Thu, 2008-03-06 at 16:29 +0000, Magnus Therning wrote: > On 3/6/08, Magnus Therning wrote: > On 3/6/08, Magnus Therning wrote: > On 3/4/08, Thomas Schilling > wrote: > Oh, right. That's a bug in Cabal 1.2 (fixed > in HEAD). Use: > > buildable: False > > OK, that solved that problem, now onto the next. > Rather surprisingly to me, buildability has an impact > on what's included in the source tar-ball created with > "sdist". What's the reason for that behaviour? > > It seems the source isn't even included on the platform where > the executable *is* buildable. I'll see if I can put together > a small example and raise a bug. > > Done, http://hackage.haskell.org/trac/hackage/ticket/257 Fixed, thanks. Duncan From lrpalmer at gmail.com Thu Mar 6 22:16:46 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Thu Mar 6 22:14:13 2008 Subject: [Haskell-cafe] Issues(Bugs?) with GHC Type Families In-Reply-To: <2f9b2d30803061852w2978d312y97c9a445584f589f@mail.gmail.com> References: <7b92c2840803030935t6ed5d2a6ne63d5f8b3d5fe917@mail.gmail.com> <7b92c2840803051727l6a31fd78j63c756ee9a1973ca@mail.gmail.com> <13737842-6754-4401-8F78-9A215F7BC0FB@cse.unsw.edu.au> <7b92c2840803061737g7fd31713tc8ba20be86de9edf@mail.gmail.com> <7b92c2840803061830rf507765yb054b7aedd2fdffd@mail.gmail.com> <2f9b2d30803061852w2978d312y97c9a445584f589f@mail.gmail.com> Message-ID: <7ca3f0160803061916t53919820g2d7c4a8834b58378@mail.gmail.com> On Thu, Mar 6, 2008 at 7:52 PM, Ryan Ingram wrote: > I wish there was some form of instance declaration that let you do > case analysis; something similar to the following: > > instances C [a] where > > instance C String where > c = "a" > > instance C a => C [a] where > c = [c,c] > instance Num a => C [a] where > c = [0] > > When trying to find a constraint for C [a] for some type a, the > instances would be checked in order: > 1) If a was Char, the first instance would be selected. > 2) Otherwise, if there was an instance for C a, the second instance > would be selected. > 3) Otherwise, if there was an instance for Num a, the third instance > would be selected. > 4) Otherwise a type error would occur. I agree that this would be nice. But I think that the situation is stickier than it looks on the surface. Consider this: instances GShow [a] where instance [Char] where gShow = id instance [a] where gShow x = "list(" ++ length x ++ ")" gShow' :: [a] -> String gShow' = gShow For any implementation which keeps implementations polymorphic (i.e. no required inlining like C++), despite what the program *says*, gShow' would not be equal to gShow. When gShow' calls gShow, it needs a GShow dictionary; so it does constraint solving and finds a dictionary for [a]. a is not Char, so it uses the [a] dictionary, not the [Char] dictionary. Therefore: gShow "hello" = "hello" gShow' "hello" = "list(5)" That's just the first issue, and that alone is enough to make me not want this. When we get to more complex examples like the one you gave above involving constraints, in order to solve for the constraints needed for an instance of C [a] you need a *disjunction* constraint, which vastly increases the likelihood of an undecidable solution. Luke From dave at zednenem.com Thu Mar 6 22:26:30 2008 From: dave at zednenem.com (David Menendez) Date: Thu Mar 6 22:23:53 2008 Subject: [Haskell-cafe] Re: Small displeasure with associated type synonyms In-Reply-To: <47D05AB1.20706@list.mightyreason.com> References: <47D04B2F.5090609@list.mightyreason.com> <47D05AB1.20706@list.mightyreason.com> Message-ID: <49a77b7a0803061926r72e572d6tdf29e384c4fad4c4@mail.gmail.com> On Thu, Mar 6, 2008 at 3:57 PM, ChrisK wrote: > Okay, I get the difference. > > The "T a" annotation in "val :: T a)"and "val :: T a" does not help choose the > "C a" dictionary. > But the "val :: a-> T a" and "val (undefined :: a)" allows "a" to successfully > choose the "C a" dictionary. > > val :: T a fixes "T a" but does not imply "C a". > (undefined :: a) fixes "a" and does imply "C a". > I now see how the functional dependency works here (which I should have tried to > do in the first place -- I should have thought more and relied on the mailing > list less). > > "class C a b | a -> b" is here "class C a where type T a = b". > So only knowing "T a" or "b" does not allow "a" to be determined. Am I correct in thinking this would have worked if it were an associated type instead of an associated type synonym? ie, class C a where data T a val :: T a -- Dave Menendez From dave at zednenem.com Thu Mar 6 22:53:56 2008 From: dave at zednenem.com (David Menendez) Date: Thu Mar 6 22:51:19 2008 Subject: [Haskell-cafe] Issues(Bugs?) with GHC Type Families In-Reply-To: <2f9b2d30803061852w2978d312y97c9a445584f589f@mail.gmail.com> References: <7b92c2840803030935t6ed5d2a6ne63d5f8b3d5fe917@mail.gmail.com> <7b92c2840803051727l6a31fd78j63c756ee9a1973ca@mail.gmail.com> <13737842-6754-4401-8F78-9A215F7BC0FB@cse.unsw.edu.au> <7b92c2840803061737g7fd31713tc8ba20be86de9edf@mail.gmail.com> <7b92c2840803061830rf507765yb054b7aedd2fdffd@mail.gmail.com> <2f9b2d30803061852w2978d312y97c9a445584f589f@mail.gmail.com> Message-ID: <49a77b7a0803061953t48858572ne9528fb68cb48f38@mail.gmail.com> On Thu, Mar 6, 2008 at 9:52 PM, Ryan Ingram wrote: > This is actually a general issue with the way typeclasses are defined > in Haskell; the accepted solution is what the "Show" typeclass does: > > > > class C a where > > c :: a > > cList :: [a] > > cList = [c,c] > > > > instance C Char where > > c = 'a' > > cList = "a" -- replaces instance for String above > > > instance C a => C [a] where > > c = cList > > cc = c :: String > > I don't really like this solution; it feels like a hack and it relies > on knowing when you define the typeclass what sort of overlap you > expect. The pattern above can be thought of as a specialized version of this: class C a where c :: a class ListOfC a where listOfC :: [a] instance (ListOfC a) => C [a] where c = listOfC This works for an arbitrary number of type constructors (good!), but requires a ListOfC instance for everything you might want to put into a list (cumbersome!). You can make things slightly less verbose by putting a sensible default in ListOfC, class (C a) => ListOfC a where listOfC :: [a] listOfC = default_c -- Dave Menendez From ivan.miljenovic at gmail.com Fri Mar 7 00:02:32 2008 From: ivan.miljenovic at gmail.com (Ivan Miljenovic) Date: Thu Mar 6 23:59:55 2008 Subject: [Haskell-cafe] Analysing Haskell with Graph Theory In-Reply-To: References: Message-ID: On 07/03/2008, Vimal wrote: > > Will the graph be completely computed before the analysis begins? Or > will you try to build the graph lazily as and when you require more > information? Probably beforehand. > > Are you looking for Haskell functions that can be used to solve the > above problems? I guess once you come up with the algorithms, > translating it into Haskell shouldnt be much of a problem. No, I'm just asking people what else they think I should be looking for. -- Ivan Lazar Miljenovic From jstrait at moonloop.net Fri Mar 7 00:18:55 2008 From: jstrait at moonloop.net (Jon Strait) Date: Fri Mar 7 00:23:05 2008 Subject: [Haskell-cafe] Build dependency problem with bytestring. Message-ID: <47D0D03F.8000705@moonloop.net> Hi all, I'm upgrading HAppS from my 0.9.2 to the current 0.9.2.1 in Hackage. Some HAppS components have built and installed (IxSet and Util). Halfway through the HAppS-State build, the GHC runtime linker gives a fatal error on finding a duplicate definition for symbol fps_minimum while loading bytestring 0.9.0.4 after having already loaded bytestring 0.9.0.1. From trial and error, I'm guessing that HAppS-State needs 0.9.0.1 but one of its build dependencies was built with 0.9.0.4. Using GHC 6.8.2 Linux here. Any suggestions on how best to currently approach this situation? Thanks, Jon From dons at galois.com Fri Mar 7 00:27:30 2008 From: dons at galois.com (Don Stewart) Date: Fri Mar 7 00:24:53 2008 Subject: [Haskell-cafe] Build dependency problem with bytestring. In-Reply-To: <47D0D03F.8000705@moonloop.net> References: <47D0D03F.8000705@moonloop.net> Message-ID: <20080307052730.GD14958@scytale.galois.com> jstrait: > Hi all, > > I'm upgrading HAppS from my 0.9.2 to the current 0.9.2.1 in Hackage. > Some HAppS components have built and installed (IxSet and Util). > Halfway through the HAppS-State build, the GHC runtime linker gives a > fatal error on finding a duplicate definition for symbol fps_minimum > while loading bytestring 0.9.0.4 after having already loaded bytestring > 0.9.0.1. From trial and error, I'm guessing that HAppS-State needs > 0.9.0.1 but one of its build dependencies was built with 0.9.0.4. > Using GHC 6.8.2 Linux here. > > Any suggestions on how best to currently approach this situation? > . you need to uninstall your happs build, uninstall bytestring 0.9.0.1, and start over, so all packages link against 0.9.0.4 only. Cheers, Don From Tom.Schrijvers at cs.kuleuven.be Fri Mar 7 02:07:57 2008 From: Tom.Schrijvers at cs.kuleuven.be (Tom Schrijvers) Date: Fri Mar 7 02:06:33 2008 Subject: [Haskell-cafe] Re: Small displeasure with associated type synonyms In-Reply-To: <49a77b7a0803061926r72e572d6tdf29e384c4fad4c4@mail.gmail.com> References: <47D04B2F.5090609@list.mightyreason.com> <47D05AB1.20706@list.mightyreason.com> <49a77b7a0803061926r72e572d6tdf29e384c4fad4c4@mail.gmail.com> Message-ID: > Am I correct in thinking this would have worked if it were an > associated type instead of an associated type synonym? > > ie, > > class C a where > data T a > val :: T a Yes, you are. Associate data type constructors (as well as ordinary algebraic data constructors) are injective. So we have: forall a b . T a = T b <=> a = b Cheers, Tom -- Tom Schrijvers Department of Computer Science K.U. Leuven Celestijnenlaan 200A B-3001 Heverlee Belgium tel: +32 16 327544 e-mail: tom.schrijvers@cs.kuleuven.be url: http://www.cs.kuleuven.be/~toms/ From ryani.spam at gmail.com Fri Mar 7 02:10:48 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Fri Mar 7 02:08:09 2008 Subject: [Haskell-cafe] Issues(Bugs?) with GHC Type Families In-Reply-To: <7ca3f0160803061916t53919820g2d7c4a8834b58378@mail.gmail.com> References: <7b92c2840803030935t6ed5d2a6ne63d5f8b3d5fe917@mail.gmail.com> <7b92c2840803051727l6a31fd78j63c756ee9a1973ca@mail.gmail.com> <13737842-6754-4401-8F78-9A215F7BC0FB@cse.unsw.edu.au> <7b92c2840803061737g7fd31713tc8ba20be86de9edf@mail.gmail.com> <7b92c2840803061830rf507765yb054b7aedd2fdffd@mail.gmail.com> <2f9b2d30803061852w2978d312y97c9a445584f589f@mail.gmail.com> <7ca3f0160803061916t53919820g2d7c4a8834b58378@mail.gmail.com> Message-ID: <2f9b2d30803062310lb57c7fdic632fd518dc77a27@mail.gmail.com> On Thu, Mar 6, 2008 at 7:16 PM, Luke Palmer wrote: > I agree that this would be nice. But I think that the situation is > stickier than it looks on the surface. Consider this: > > instances GShow [a] where > instance [Char] where gShow = id > instance [a] where gShow x = "list(" ++ length x ++ ")" > > gShow' :: [a] -> String > gShow' = gShow I'm not so sure. It's not that hard to imagine a compiler where the core-language expansion of this code looks like this: data GShowDict a = GShowDict { gShow :: a -> String } id :: (a :: *) -> a -> a id A a = a length :: (a :: *) -> [a] -> Int -- definition elided gShow' :: (a :: *) -> [a] -> String gShow' A = gShow (mkDict_GShow_List A) mkDict_GShow_List :: (a :: *) -> GShowDict [a] mkDict_GShow_List A = typecase A of Char -> GShowDict (id [A]) _ -> GShowDict (\xs -> length A xs) Now, it's true that this means that you can no longer do full type erasure, but I'm not convinced of the importance of that anyways; if you look at mainstream languages you generally only get type erasure for a restricted subset of the types and that's good enough for performance: 1) In Java, you only get type erasure for primitive types; everything else needs its type tag so it can be safely downcasted from Object. 2) In C++ only primitive types and structs/classes with no virtual functions get type erasure; if a class has virtual functions its virtual function table is implicitly a "type tag". I don't think the cost is that great; the compiler can easily flag polymorphic functions that require type information for some or all arguments and in many cases the type evidence can be passed "just-in-time" when calling from a non-polymorphic function into a polymorphic function. > When we get to more complex examples like the one you gave > above involving constraints, in order to solve for the constraints > needed for an instance of C [a] you need a *disjunction* constraint, > which vastly increases the likelihood of an undecidable solution. This is definitely an issue. I don't have a full understanding of the methods used for typechecking/inference of typeclasses; I'm just a programmer who wants MORE POWER :) -- ryan From jstrait at moonloop.net Fri Mar 7 03:59:54 2008 From: jstrait at moonloop.net (Jon Strait) Date: Fri Mar 7 04:04:04 2008 Subject: [Haskell-cafe] Build dependency problem with bytestring. In-Reply-To: <20080307052730.GD14958@scytale.galois.com> References: <47D0D03F.8000705@moonloop.net> <20080307052730.GD14958@scytale.galois.com> Message-ID: <47D1040A.60900@moonloop.net> Don Stewart wrote: > jstrait: > >> Hi all, >> >> I'm upgrading HAppS from my 0.9.2 to the current 0.9.2.1 in Hackage. >> Some HAppS components have built and installed (IxSet and Util). >> Halfway through the HAppS-State build, the GHC runtime linker gives a >> fatal error on finding a duplicate definition for symbol fps_minimum >> while loading bytestring 0.9.0.4 after having already loaded bytestring >> 0.9.0.1. From trial and error, I'm guessing that HAppS-State needs >> 0.9.0.1 but one of its build dependencies was built with 0.9.0.4. >> Using GHC 6.8.2 Linux here. >> >> Any suggestions on how best to currently approach this situation? >> . >> > > you need to uninstall your happs build, uninstall bytestring 0.9.0.1, > and start over, so all packages link against 0.9.0.4 only. > > Cheers, > Don > Thanks for the response, Don. I ended up unregistering and rebuilding many more packages against bytestring 0.9.0.4 that had previously been built against 0.9.0.1. However, GHC itself had been built with bytestring 0.9.0.1, and was showing up as broken in the package listing. So, when I was done fighting the missing dependency errors, I just reinstalled bytestring 0.9.0.1 and let the rest be, for now. Another issue I had, and I don't think this is the intended behavior of Cabal, is that when using 'cabal install --global' as root, lib files from the package would be placed under the root's own .cabal/lib/ directory. So, as a different user, I would be unable to access those lib files if they were needed for my own local build. I had to add the option '--libdir=/usr/lib/ghc-6.8.2/lib' on install, something I thought should have been implicit when using the --global option. Jon From ivan.miljenovic at gmail.com Fri Mar 7 06:14:09 2008 From: ivan.miljenovic at gmail.com (Ivan Miljenovic) Date: Fri Mar 7 06:11:30 2008 Subject: [Haskell-cafe] Analysing Haskell with Graph Theory In-Reply-To: <47D10094.1010900@fit.vutbr.cz> References: <47D10094.1010900@fit.vutbr.cz> Message-ID: (CC'd to the list) On 07/03/2008, Dusan Kolar wrote: > I'm just wondering what algorithms you use for analysis. For instance, > clique is an NP complete problem. Do you use some approximation? If yes, > which? I'm particularly interested in the algorithm. I haven't gotten that far yet ;-) As it stands, my supervisor have discussed this slightly and I'll probably start off with a more-or-less brute-force approach. This should be OK as the graph will probably be reasonably sparse and (hopefully) not too big! -- Ivan Lazar Miljenovic From hthiel.char at zonnet.nl Fri Mar 7 06:31:12 2008 From: hthiel.char at zonnet.nl (Hans van Thiel) Date: Fri Mar 7 06:29:02 2008 Subject: [Haskell-cafe] ANN: Emping 0.4 Message-ID: <1204889473.9716.25.camel@localhost.localdomain> Hello All, Emping 0.4, a utility which can derive heuristic rules from facts in Open Office Calc spreadsheet .csv format, has been released on HackageDB. Version 0.4 supports blank fields, treated as 'none of the others', which allows for split attribute values. For example, "Owns Car" could have values "Yes" or 'No", and then "Yes" could be split into "Make", "Price Range" and so on, while the fields for "No" could be blank for these attributes. Data still have to be in the spreadsheet format of rows and columns (and in OO Calc .csv). Version 0.4 has a Gtk2Hs based GUI and the code has been changed in several places. Compiled with GHC 6.8 it appears to be noticeably faster than version 0.3. The package comes with a user guide, a white paper, and two data files from the UCI Machine Learning Repository. To get an impression see: http://j-van-thiel.speedlinq.nl/emp/empug.html The compiled binary for Linux, with documentation, can also be downloaded directly from my web site. Thank you, Hans van Thiel From duncan.coutts at worc.ox.ac.uk Fri Mar 7 06:38:06 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Mar 7 06:41:20 2008 Subject: [Haskell-cafe] Build dependency problem with bytestring. In-Reply-To: <47D1040A.60900@moonloop.net> References: <47D0D03F.8000705@moonloop.net> <20080307052730.GD14958@scytale.galois.com> <47D1040A.60900@moonloop.net> Message-ID: <1204889887.11558.388.camel@localhost> On Fri, 2008-03-07 at 00:59 -0800, Jon Strait wrote: > Don Stewart wrote: > > jstrait: > > > >> Hi all, > >> > >> I'm upgrading HAppS from my 0.9.2 to the current 0.9.2.1 in Hackage. > >> Some HAppS components have built and installed (IxSet and Util). > >> Halfway through the HAppS-State build, the GHC runtime linker gives a > >> fatal error on finding a duplicate definition for symbol fps_minimum > >> while loading bytestring 0.9.0.4 after having already loaded bytestring > >> 0.9.0.1. From trial and error, I'm guessing that HAppS-State needs > >> 0.9.0.1 but one of its build dependencies was built with 0.9.0.4. > >> Using GHC 6.8.2 Linux here. > >> > >> Any suggestions on how best to currently approach this situation? > >> . > >> > > > > you need to uninstall your happs build, uninstall bytestring 0.9.0.1, > > and start over, so all packages link against 0.9.0.4 only. > > > > Cheers, > > Don > > > Thanks for the response, Don. I ended up unregistering and rebuilding > many more packages against bytestring 0.9.0.4 that had previously been > built against 0.9.0.1. However, GHC itself had been built with > bytestring 0.9.0.1, and was showing up as broken in the package > listing. So, when I was done fighting the missing dependency errors, I > just reinstalled bytestring 0.9.0.1 and let the rest be, for now. The current development version of cabal detects theses problems of inconsistent versions of dependencies and warns about them and provides detail on what packages have conflicting dependencies. The next step is rather harder which is to get cabal-install to make installation plans that avoid the problem in the first place, possibly by rebuilding existing packages against different versions of their dependencies. > Another issue I had, and I don't think this is the intended behavior of > Cabal, is that when using 'cabal install --global' as root, lib files > from the package would be placed under the root's own .cabal/lib/ > directory. So, as a different user, I would be unable to access those > lib files if they were needed for my own local build. I had to add the > option > '--libdir=/usr/lib/ghc-6.8.2/lib' on install, something I thought > should have been implicit when using the --global option. Sorry about that. You'll be glad to know however that we fixed it the other day. Upgrade to the latest darcs version of the Cabal lib and cabal-install. If you find the problem isn't fixed or you run into other issues please do report them! :-) http://hackage.haskell.org/trac/hackage/ Duncan From ketil at malde.org Fri Mar 7 07:00:01 2008 From: ketil at malde.org (Ketil Malde) Date: Fri Mar 7 06:57:17 2008 Subject: [Haskell-cafe] Analysing Haskell with Graph Theory In-Reply-To: (Ivan Miljenovic's message of "Fri\, 7 Mar 2008 11\:45\:12 +1000") References: Message-ID: <87ve3yd9ry.fsf@nmd9999.imr.no> "Ivan Miljenovic" writes: > Can anyone think of any other kind of functions that would be useful > in this kind of source code analysis? Sometimes, it's not obvious where to draw boundaries between modules, perhaps finding a "smallest cut" (if that is the correct term) could help to minimize the interfaces? I.e. find tightly connected components that have relatively few inbound links. Sounds like an interesting project, good luck! -k -- If I haven't seen further, it is by standing in the footprints of giants From arnarbi at gmail.com Fri Mar 7 07:12:56 2008 From: arnarbi at gmail.com (Arnar Birgisson) Date: Fri Mar 7 07:10:18 2008 Subject: [Haskell-cafe] Analysing Haskell with Graph Theory In-Reply-To: References: Message-ID: <28012bc60803070412i653838cay98e417cfddb0d455@mail.gmail.com> On Fri, Mar 7, 2008 at 1:45 AM, Ivan Miljenovic wrote: > Can anyone think of any other kind of functions that would be useful > in this kind of source code analysis? Will you be considering parallel programs? Also, perhaps some information flow analysis would be interesting. Arnar From ivan.miljenovic at gmail.com Fri Mar 7 07:42:50 2008 From: ivan.miljenovic at gmail.com (Ivan Miljenovic) Date: Fri Mar 7 07:40:13 2008 Subject: [Haskell-cafe] Analysing Haskell with Graph Theory In-Reply-To: <28012bc60803070412i653838cay98e417cfddb0d455@mail.gmail.com> References: <28012bc60803070412i653838cay98e417cfddb0d455@mail.gmail.com> Message-ID: On 07/03/2008, Arnar Birgisson wrote: > Will you be considering parallel programs? Also, perhaps some > information flow analysis would be interesting. What do you mean by parallel programs? The parallelism hints used by ghc? In that case, I'll be supporting whatever the parser I can find supports :p -- Ivan Lazar Miljenovic From ivan.miljenovic at gmail.com Fri Mar 7 07:44:50 2008 From: ivan.miljenovic at gmail.com (Ivan Miljenovic) Date: Fri Mar 7 07:42:12 2008 Subject: [Haskell-cafe] Analysing Haskell with Graph Theory In-Reply-To: <87ve3yd9ry.fsf@nmd9999.imr.no> References: <87ve3yd9ry.fsf@nmd9999.imr.no> Message-ID: On 07/03/2008, Ketil Malde wrote: > > Sometimes, it's not obvious where to draw boundaries between modules, > perhaps finding a "smallest cut" (if that is the correct term) could > help to minimize the interfaces? I.e. find tightly connected > components that have relatively few inbound links. As in the seeing if a module can be split into sub-modules (i.e. disjoint or nearly disjoint sub-graphs inside the module graph)? I was thinking about something like that a few days ago but had forgotten about it when discussing it with my supervisor. (It doesn't help that he's mainly a C-programmer, and doesn't really understand what I mean when I talk about modules). -- Ivan Lazar Miljenovic From arnarbi at gmail.com Fri Mar 7 08:17:38 2008 From: arnarbi at gmail.com (Arnar Birgisson) Date: Fri Mar 7 08:15:02 2008 Subject: [Haskell-cafe] Analysing Haskell with Graph Theory In-Reply-To: References: <28012bc60803070412i653838cay98e417cfddb0d455@mail.gmail.com> Message-ID: <28012bc60803070517h3d58e6baif57043ce8bfd2a08@mail.gmail.com> On Fri, Mar 7, 2008 at 12:42 PM, Ivan Miljenovic wrote: > On 07/03/2008, Arnar Birgisson wrote: > > Will you be considering parallel programs? Also, perhaps some > > information flow analysis would be interesting. > > What do you mean by parallel programs? The parallelism hints used by > ghc? In that case, I'll be supporting whatever the parser I can find > supports :p I mean parallel programs in general. For example, you mention that preferably one would want "main" to be the only function that has no incoming edges. With parallel programs that may not be the case. This ties into also considering reactive programs (i.e. programs which main function is of the form "while (1) { ... }"). I'm not quite sure if it fits the project you describe, but looking for certain properties like possible deadlocks or livelocks in such programs is something of interest. There is also a security angle to this. Consider two agents, one representing an ATM and one representing the branch office of a bank. Analysing the possible possible information paths between the two can help you define a clear interface between the two (assuming one doesn't exist already). Having such an interface rigorously defined helps with maintaining security properties. Also related to considering parallel programs are coroutines. Analysing the "call graph" of systems of coroutines might be interesting as well. I'm just thinking outloud though, some of these might not be interesting at all :) cheers, Arnar From droundy at darcs.net Fri Mar 7 08:37:50 2008 From: droundy at darcs.net (David Roundy) Date: Fri Mar 7 08:35:12 2008 Subject: [Haskell-cafe] Re: Small displeasure with associated type synonyms In-Reply-To: References: <47D04B2F.5090609@list.mightyreason.com> <47D05AB1.20706@list.mightyreason.com> <49a77b7a0803061926r72e572d6tdf29e384c4fad4c4@mail.gmail.com> Message-ID: <20080307133748.GD28119@darcs.net> On Fri, Mar 07, 2008 at 08:07:57AM +0100, Tom Schrijvers wrote: > >Am I correct in thinking this would have worked if it were an > >associated type instead of an associated type synonym? > > > >ie, > > > >class C a where > > data T a > > val :: T a > > Yes, you are. Associate data type constructors (as well as ordinary > algebraic data constructors) are injective. So we have: Yay, that's what I though! (but was hesitant to suggest anything, since I've never actually used associated anything...) It's nice to hear that I do understand some of this stuff. :) -- David Roundy Department of Physics Oregon State University From sebell at gmail.com Fri Mar 7 11:10:45 2008 From: sebell at gmail.com (Scott Bell) Date: Fri Mar 7 11:08:05 2008 Subject: [Haskell-cafe] Network.Socket Woes Message-ID: <215432060803070810o7dab14bfi244962b7876ce685@mail.gmail.com> Hi all, I'm trying to do some standard socket stuff using the Network.Socket library. This example is a UDP server: import Network.Socket proto_udp :: ProtocolNumber proto_udp = 17 port = 10162 main = do s <- socket AF_INET Datagram 17 bindSocket s (SockAddrInet (PortNum port) iNADDR_ANY) putStrLn $ "Listening on port " ++ (show port) ++ "... " (msg, n, addr) <- recvFrom s 1024 putStrLn $ "Received " ++ (show n) ++ " bytes from " ++ (show addr) ++ ": " putStrLn (show msg) Using the equivalent C program (socket, bind, recvfrom) I'm able to successfully receive a 64 byte message from my test program. The Haskell version, however, does not return from recvFrom. I've also tried wrapping this in a withSocketsDo, with no effect. How can I proceed to debug/troubleshoot this program? Thanks, - Scott Bell From agl at imperialviolet.org Fri Mar 7 12:48:48 2008 From: agl at imperialviolet.org (Adam Langley) Date: Fri Mar 7 12:46:10 2008 Subject: [Haskell-cafe] Network.Socket Woes In-Reply-To: <215432060803070810o7dab14bfi244962b7876ce685@mail.gmail.com> References: <215432060803070810o7dab14bfi244962b7876ce685@mail.gmail.com> Message-ID: <396556a20803070948t7b21f17cp93408a6dcbde19e3@mail.gmail.com> On Fri, Mar 7, 2008 at 8:10 AM, Scott Bell wrote: > my test program. The Haskell version, however, does not > return from recvFrom. I've also tried wrapping this in a > withSocketsDo, with no effect. So this is a long standing, ah, issue with the Network modules. Try sending a UDP packet to port 45607 and you'll find that the Haskell code gets it. hex(45607) = 0xb227 0x27b2 = 10162 In short, PortNum doesn't do the endian conversion for you. And I don't know a good way to figure out the endianness of the underlying system from Haskell I'm afraid. I usually end up FFIing out to htons or just assuming that the system is little-endian. We should really fix this unless there's some trick that I've been missing all this time. AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org From sebell at gmail.com Fri Mar 7 12:56:32 2008 From: sebell at gmail.com (Scott Bell) Date: Fri Mar 7 12:53:53 2008 Subject: [Haskell-cafe] Network.Socket Woes In-Reply-To: <396556a20803070948t7b21f17cp93408a6dcbde19e3@mail.gmail.com> References: <215432060803070810o7dab14bfi244962b7876ce685@mail.gmail.com> <396556a20803070948t7b21f17cp93408a6dcbde19e3@mail.gmail.com> Message-ID: <215432060803070956g581ff593kb23fa79adbe695b3@mail.gmail.com> Adam, This does the trick, thanks! I certainly would not have been able to track down such an insidious `issue' without much agony and despair. - Scott On Fri, Mar 7, 2008 at 10:48 AM, Adam Langley wrote: > On Fri, Mar 7, 2008 at 8:10 AM, Scott Bell wrote: > > my test program. The Haskell version, however, does not > > return from recvFrom. I've also tried wrapping this in a > > withSocketsDo, with no effect. > > So this is a long standing, ah, issue with the Network modules. > > Try sending a UDP packet to port 45607 and you'll find that the > Haskell code gets it. > > hex(45607) = 0xb227 > 0x27b2 = 10162 > > In short, PortNum doesn't do the endian conversion for you. And I > don't know a good way to figure out the endianness of the underlying > system from Haskell I'm afraid. I usually end up FFIing out to htons > or just assuming that the system is little-endian. > > We should really fix this unless there's some trick that I've been > missing all this time. > > > AGL > > -- > Adam Langley agl@imperialviolet.org http://www.imperialviolet.org > From dave at zednenem.com Fri Mar 7 13:22:13 2008 From: dave at zednenem.com (David Menendez) Date: Fri Mar 7 13:19:34 2008 Subject: [Haskell-cafe] Issues(Bugs?) with GHC Type Families In-Reply-To: <2f9b2d30803062310lb57c7fdic632fd518dc77a27@mail.gmail.com> References: <7b92c2840803030935t6ed5d2a6ne63d5f8b3d5fe917@mail.gmail.com> <7b92c2840803051727l6a31fd78j63c756ee9a1973ca@mail.gmail.com> <13737842-6754-4401-8F78-9A215F7BC0FB@cse.unsw.edu.au> <7b92c2840803061737g7fd31713tc8ba20be86de9edf@mail.gmail.com> <7b92c2840803061830rf507765yb054b7aedd2fdffd@mail.gmail.com> <2f9b2d30803061852w2978d312y97c9a445584f589f@mail.gmail.com> <7ca3f0160803061916t53919820g2d7c4a8834b58378@mail.gmail.com> <2f9b2d30803062310lb57c7fdic632fd518dc77a27@mail.gmail.com> Message-ID: <49a77b7a0803071022l5526223dhf9e502c5f4180931@mail.gmail.com> On Fri, Mar 7, 2008 at 2:10 AM, Ryan Ingram wrote: > I don't think the cost is that great; the compiler can easily flag > polymorphic functions that require type information for some or all > arguments and in many cases the type evidence can be passed > "just-in-time" when calling from a non-polymorphic function into a > polymorphic function. As I understand it, the cost in performance isn't too bad. For example, JHC uses type-passing to implement type classes. One problem is that a language with pervasive typecase has weaker guarantees. For example, in present-day Haskell we can tell that length :: [a] -> Int works the same for every type 'a' just by looking at the type signature. That's not the case if we can call typecase in arbitrary functions. We can avoid that problem by requiring a type representation parameter, or otherwise indicating the use of typecase in the signature. Modern Haskell provides this with the Typeable class. (Which, in JHC, is essentially empty.) Thus, another solution for writing the show instance for lists is: class (Typeable a) => Show [a] where show s = case cast s of Just str -> "\"" ++ str ++"\"" Nothing -> showList s where showList ... To summarize: we can make more claims about a function with type "forall a. F a -> G a" than one with type "forall a. (Typeable a) => F a -> G a", even though every type can (as far as I know) be made an instance of Typeable. -- Dave Menendez From donnie at darthik.com Fri Mar 7 13:25:59 2008 From: donnie at darthik.com (donnie Jones) Date: Fri Mar 7 13:23:21 2008 Subject: [Haskell-cafe] Network.Socket Woes In-Reply-To: <396556a20803070948t7b21f17cp93408a6dcbde19e3@mail.gmail.com> References: <215432060803070810o7dab14bfi244962b7876ce685@mail.gmail.com> <396556a20803070948t7b21f17cp93408a6dcbde19e3@mail.gmail.com> Message-ID: Hello Adam, Maybe you could use the binary package [1] to always encode the portNumber, etc. in network byte order? Such as available put/get functions: putWord16be :: Word16 -> Put Hope this helps... __ Donnie 1. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/binary-0.4.1 On 3/7/08, Adam Langley wrote: > > On Fri, Mar 7, 2008 at 8:10 AM, Scott Bell wrote: > > my test program. The Haskell version, however, does not > > return from recvFrom. I've also tried wrapping this in a > > withSocketsDo, with no effect. > > > So this is a long standing, ah, issue with the Network modules. > > Try sending a UDP packet to port 45607 and you'll find that the > Haskell code gets it. > > hex(45607) = 0xb227 > 0x27b2 = 10162 > > In short, PortNum doesn't do the endian conversion for you. And I > don't know a good way to figure out the endianness of the underlying > system from Haskell I'm afraid. I usually end up FFIing out to htons > or just assuming that the system is little-endian. > > We should really fix this unless there's some trick that I've been > missing all this time. > > > AGL > > > -- > Adam Langley agl@imperialviolet.org http://www.imperialviolet.org > > _______________________________________________ > 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/20080307/3fbc3949/attachment.htm From josh at joshisanerd.com Fri Mar 7 13:39:40 2008 From: josh at joshisanerd.com (Josh Myer) Date: Fri Mar 7 13:37:00 2008 Subject: [Haskell-cafe] Network.Socket Woes In-Reply-To: <215432060803070956g581ff593kb23fa79adbe695b3@mail.gmail.com> References: <215432060803070810o7dab14bfi244962b7876ce685@mail.gmail.com> <396556a20803070948t7b21f17cp93408a6dcbde19e3@mail.gmail.com> <215432060803070956g581ff593kb23fa79adbe695b3@mail.gmail.com> Message-ID: <20080307183940.GC3075@wilmington.dreamhost.com> On Fri, Mar 07, 2008 at 10:56:32AM -0700, Scott Bell wrote: > Adam, > > This does the trick, thanks! I certainly would not have been > able to track down such an insidious `issue' without much > agony and despair. (haskell-cafe, my apologies for a message that's only tangentially on-topic. The content might be helpful, especially if you're writing socket apps.) Assuming you're on Linux, there are a few handy tools for this job: * 'netstat -nlp' (show listeners, with process name, numeric) * lsof -p $pid (list open file descriptors for PID) * strace -p $pid (trace system calls in running process) * strace /path/to/executable (trace system calls to stderr) * ls -l /proc/$pid/fd (peek at kernel's view of PID's fd table) There's also dtrace on Solaris and OS X, but I don't use those OSes, so I'm not too familiar with it. In Windows, there seems to be an embarassment of riches when it comes to profiling tools. Hope this helps, -- /jbm, but you can call me Josh. Really, you can! From beschmi at gmail.com Fri Mar 7 14:04:10 2008 From: beschmi at gmail.com (Benedikt Schmidt) Date: Fri Mar 7 14:00:45 2008 Subject: [Haskell-cafe] Re: Network.Socket Woes References: <215432060803070810o7dab14bfi244962b7876ce685@mail.gmail.com> <396556a20803070948t7b21f17cp93408a6dcbde19e3@mail.gmail.com> Message-ID: <87pru6z785.fsf@twofish.i-did-not-set--mail-host-address--so-tickle-me> "Adam Langley" writes: > On Fri, Mar 7, 2008 at 8:10 AM, Scott Bell wrote: >> my test program. The Haskell version, however, does not >> return from recvFrom. I've also tried wrapping this in a >> withSocketsDo, with no effect. > > So this is a long standing, ah, issue with the Network modules. > > Try sending a UDP packet to port 45607 and you'll find that the > Haskell code gets it. > > hex(45607) = 0xb227 > 0x27b2 = 10162 > > In short, PortNum doesn't do the endian conversion for you. And I > don't know a good way to figure out the endianness of the underlying > system from Haskell I'm afraid. I usually end up FFIing out to htons > or just assuming that the system is little-endian. The PortNumber type is an instance of Num, so it works if you do not use the PortNum constructor. Prelude Network.Socket> case 10162 :: PortNumber of PortNum p -> p 45607 Benedikt From agl at imperialviolet.org Fri Mar 7 14:46:32 2008 From: agl at imperialviolet.org (Adam Langley) Date: Fri Mar 7 14:43:53 2008 Subject: [Haskell-cafe] Re: Network.Socket Woes In-Reply-To: <87pru6z785.fsf@twofish.i-did-not-set--mail-host-address--so-tickle-me> References: <215432060803070810o7dab14bfi244962b7876ce685@mail.gmail.com> <396556a20803070948t7b21f17cp93408a6dcbde19e3@mail.gmail.com> <87pru6z785.fsf@twofish.i-did-not-set--mail-host-address--so-tickle-me> Message-ID: <396556a20803071146j4c340060rb996d078e3e67635@mail.gmail.com> On Fri, Mar 7, 2008 at 11:04 AM, Benedikt Schmidt wrote: > The PortNumber type is an instance of Num, so it works if you do not > use the PortNum constructor. > > Prelude Network.Socket> case 10162 :: PortNumber of PortNum p -> p > 45607 And there was the trick that I've been missing all this time ;) I'll probably submit a documentation patch for this since I'm a Bear of Little Brain and this wasn't obvious to me. -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org From donnie at darthik.com Fri Mar 7 14:48:30 2008 From: donnie at darthik.com (donnie Jones) Date: Fri Mar 7 14:45:52 2008 Subject: [Haskell-cafe] Network.Socket Woes In-Reply-To: <396556a20803070948t7b21f17cp93408a6dcbde19e3@mail.gmail.com> References: <215432060803070810o7dab14bfi244962b7876ce685@mail.gmail.com> <396556a20803070948t7b21f17cp93408a6dcbde19e3@mail.gmail.com> Message-ID: Hello Adam, After taking a closer look, the network module does do the ntohs() FFI call: http://haskell.org/ghc/docs/latest/html/libraries/network/src/Network-Socket.html#PortNumber Thus, I think the issue is probably that Scott's UDP Client does not do the htons() for the port number, or if the UDP Client is in Haskell, then it is not using the Portnumber constructor. __ Donnie On 3/7/08, Adam Langley wrote: > > On Fri, Mar 7, 2008 at 8:10 AM, Scott Bell wrote: > > my test program. The Haskell version, however, does not > > return from recvFrom. I've also tried wrapping this in a > > withSocketsDo, with no effect. > > > So this is a long standing, ah, issue with the Network modules. > > Try sending a UDP packet to port 45607 and you'll find that the > Haskell code gets it. > > hex(45607) = 0xb227 > 0x27b2 = 10162 > > In short, PortNum doesn't do the endian conversion for you. And I > don't know a good way to figure out the endianness of the underlying > system from Haskell I'm afraid. I usually end up FFIing out to htons > or just assuming that the system is little-endian. > > We should really fix this unless there's some trick that I've been > missing all this time. > > > AGL > > > -- > Adam Langley agl@imperialviolet.org http://www.imperialviolet.org > > _______________________________________________ > 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/20080307/6a536c7f/attachment.htm From jefferson.r.heard at gmail.com Fri Mar 7 14:58:05 2008 From: jefferson.r.heard at gmail.com (Jefferson Heard) Date: Fri Mar 7 14:55:25 2008 Subject: [Haskell-cafe] Thanks for the help: image of draft visualization Message-ID: <4165d3a70803071158n6b1a8a73idf36caf937276b61@mail.gmail.com> Thanks for everyone's help on the list re my Haskell woes with the latest visualization effort. I've been making my code more generic for the last week, and I plan on releasing a visualization framework back to the community at some point. Gotta get approval from my boss before releasing code back to the wild, but here's an image of the draft of the visualization I've been working on: http://vizdata.renci.org/projects/jeff/ProteinViz/ProteinViz.png Basically, what you're seeing is 18,500 genes arranged in a full heirarchical clustering (the clustering technique uses a metric I'm unfamiliar with, and I got the dataset pre-packaged from the guy who's using it). The final visualization is fully interactive and runs fine under Linux, dies a miserable death under windows (runs out of RAM, and I can't figure out why, nor do I particularly care), and primarily runs on our 14 foot by 9 foot (4.5x3 metres for those of us in metric) linux display wall. The full program is about 800 linux of Haskell code using nothing but the standard library under GHC 6.8. Again, thanks for all your help! -- Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080307/befeb83f/attachment.htm From donn at avvanta.com Fri Mar 7 15:16:57 2008 From: donn at avvanta.com (Donn Cave) Date: Fri Mar 7 15:14:19 2008 Subject: [Haskell-cafe] Re: Network.Socket Woes In-Reply-To: <396556a20803071146j4c340060rb996d078e3e67635@mail.gmail.com> References: <215432060803070810o7dab14bfi244962b7876ce685@mail.gmail.com> <396556a20803070948t7b21f17cp93408a6dcbde19e3@mail.gmail.com> <87pru6z785.fsf@twofish.i-did-not-set--mail-host-address--so-tickle-me> <396556a20803071146j4c340060rb996d078e3e67635@mail.gmail.com> Message-ID: <4D4BFE9B-FA8A-45AC-8438-B5B3129C041A@avvanta.com> On Mar 7, 2008, at 11:46 AM, Adam Langley wrote: > And there was the trick that I've been missing all this time ;) I'll > probably submit a documentation patch for this since I'm a Bear of > Little Brain and this wasn't obvious to me. That would be great - I have been doing the same thing, and was just a minute short of sending in the FORTRAN Programmer's solution. It would have really made your eyes burn. Donn Cave, donn@avvanta.com From felipe.lessa at gmail.com Fri Mar 7 15:23:28 2008 From: felipe.lessa at gmail.com (Felipe Lessa) Date: Fri Mar 7 15:20:48 2008 Subject: [Haskell-cafe] Re: Network.Socket Woes In-Reply-To: <87pru6z785.fsf@twofish.i-did-not-set--mail-host-address--so-tickle-me> References: <215432060803070810o7dab14bfi244962b7876ce685@mail.gmail.com> <396556a20803070948t7b21f17cp93408a6dcbde19e3@mail.gmail.com> <87pru6z785.fsf@twofish.i-did-not-set--mail-host-address--so-tickle-me> Message-ID: On Fri, Mar 7, 2008 at 4:04 PM, Benedikt Schmidt wrote: > The PortNumber type is an instance of Num, so it works if you do not > use the PortNum constructor. > > Prelude Network.Socket> case 10162 :: PortNumber of PortNum p -> p > 45607 Considering that PortNumber implements toEnum/fromEnum, why is PortNum exported anyway? -- Felipe. From dons at galois.com Fri Mar 7 17:30:07 2008 From: dons at galois.com (Don Stewart) Date: Fri Mar 7 17:27:33 2008 Subject: [Haskell-cafe] Thanks for the help: image of draft visualization In-Reply-To: <4165d3a70803071158n6b1a8a73idf36caf937276b61@mail.gmail.com> References: <4165d3a70803071158n6b1a8a73idf36caf937276b61@mail.gmail.com> Message-ID: <20080307223007.GA24288@scytale.galois.com> jefferson.r.heard: > Thanks for everyone's help on the list re my Haskell woes with the latest > visualization effort. I've been making my code more generic for the last > week, and I plan on releasing a visualization framework back to the > community at some point. Gotta get approval from my boss before releasing > code back to the wild, but here's an image of the draft of the > visualization I've been working on: > > [1]http://vizdata.renci.org/projects/jeff/ProteinViz/ProteinViz.png > > Basically, what you're seeing is 18,500 genes arranged in a full > heirarchical clustering (the clustering technique uses a metric I'm > unfamiliar with, and I got the dataset pre-packaged from the guy who's > using it). The final visualization is fully interactive and runs fine > under Linux, dies a miserable death under windows (runs out of RAM, and I > can't figure out why, nor do I particularly care), and primarily runs on > our 14 foot by 9 foot (4.5x3 metres for those of us in metric) linux > display wall. The full program is about 800 linux of Haskell code using > nothing but the standard library under GHC 6.8. > > Again, thanks for all your help! > Truly awesome. Well done! Can't wait to see a writeup on your approach, and lessons learnt. -- Don From gwern0 at gmail.com Fri Mar 7 18:08:24 2008 From: gwern0 at gmail.com (gwern0@gmail.com) Date: Fri Mar 7 18:06:15 2008 Subject: [Haskell-cafe] Re: Data.HashTable In-Reply-To: <47D06599.8080806@imn.htwk-leipzig.de> References: <47CFFF7C.2040901@imn.htwk-leipzig.de> <89ca3d1f0803061216p3f429d15p6e91dc2f00be157a@mail.gmail.com> <47D06599.8080806@imn.htwk-leipzig.de> Message-ID: <20080307230824.GA189982@localhost> On 2008.03.06 22:43:53 +0100, Johannes Waldmann scribbled 1.4K characters: > > In practice, Data.Map outperforms it in essentially all cases > > (Data.HashTable stops working beyond a certain size and so any > > asymptotic benefits, if they exist at all, don't have time to kick > > in). > > What! > > I learned at school, and I teach my students, > * balanced binary tree: costs are log(size) > * hashtable: cost are essentially constant > therefore, hashtable should be preferred in almost all cases > (if you know a reasonable hash function > and except where you need persistency, of course) > > the difference should be visible even for moderate sizes > (e.g. 1000). With a reasonable implementation I expect > log(1000) = 10 comparisons (and dereferencings) for the tree; > while the hashtable should have the computation of the hash value > (ideally, in registers), one memory access, and one comparison. > > ... but indeed some experiments with Data.Map and Data.Hashtable > support the point you made. That's either good for Data.Map > or bad for Data.Hashtable. > > PS: I did not manage to compile HsJudy-1.0 with ghc-6.8.2 > (some hsc file missing - perhaps that should be auto-generated? how?) > > Best regards, Johannes. Oh... I'm terribly sorry about that. It was I who uploaded HsJudy. The problem was, it's maintained by the Pugs project for some reason. The directory structure looks like: pugs/ thirdparty/ HsJudy/ hsregex/ HsSyck/ installed/ judy/ Judy-1.0.3/ Here Judy-1.0.3/ contains the actual C library Judy itself. So what the Cabalized package residing in HsJudy/ was doing was literally linking against stuff like '../judy/Judy-1.0.3/src/JudyL/*.o'. At the time I was packaging, Cabal didn't yet warn about problems like ../, so it would build and install just fine when I ran it with no problems; but I forgot that obviously all the ../ stuff would totally break in an sdist tarball. I think I've fixed it: . -- gwern Air eavesdropping pipe-bomb TSCM Centro ^X JIC TWA USACIL Protection -------------- 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/20080307/248c8f7a/attachment.bin From jgbailey at gmail.com Fri Mar 7 19:36:46 2008 From: jgbailey at gmail.com (Justin Bailey) Date: Fri Mar 7 19:34:06 2008 Subject: [Haskell-cafe] [pdxfunc] pdxfunc meeting: Monday, March 10, 7pm, CubeSpace In-Reply-To: <47D196E5.1080701@pragmaticraft.com> References: <47D196E5.1080701@pragmaticraft.com> Message-ID: The Portland Functional Programming group is meeting again this Monday, March 10, at 7 p.m. Join us! ---------- Forwarded message ---------- From: Igal Koshevoy Date: Fri, Mar 7, 2008 at 11:26 AM Subject: [pdxfunc] pdxfunc meeting: Monday, March 10, 7pm, CubeSpace To: Igal Koshevoy Join us at the next meeting of pdxfunc, the Portland Functional Programming Study Group. We'll have presentations, demos and discussions. We welcome programmers interested in all functional languages and our meetings have content for coders of all skill levels. If interested, please also subscribe to our mailing list at http://groups.google.com/group/pdxfunc PRESENTATION * Dr. Bart Massey: Audio Processing With Haskell - Abstract: Dr. Massey will discuss and demonstrate a Haskell implementation of a WAVE file I/O library and compressor-limiter application that he's been working on. He'll also talk about why he chose Haskell to do this. - Speaker: Dr. Bart Massey teaches Computer Science at Portland State University, focusing on open source software engineering and artificial intelligence. He's the current Secretary of the X.org Board of Directors, co-author of the Nickle open source programming language, and spent many years as the faculty advisor the Portland State Aerospace Society that builds open source sounding rockets. REMAINDER We'll spend the rest of the meeting doing open discussion, talking about projects, technical challenges, recent developments, etc. It's a good group with a lot of varied experience, so there won't be any shortage of interesting discussion. NEWS Don Stewart, who gave the group's first presentation, recently announced that the Haskell-based xmonad tiling window manager he helps write is now one year old (http://www.haskell.org/pipermail/xmonad/2008-March/005021.html) and the "Real World Haskell" book that he, Bryan O'Sullivan and John Goerzen are writing has released some new draft chapters for previewing (http://book.realworldhaskell.org/). Congratulations, Don! Anyway, see you at the meeting! --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pdxfunc" group. To post to this group, send email to pdxfunc@googlegroups.com To unsubscribe from this group, send email to pdxfunc-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/pdxfunc?hl=en -~----------~----~----~----~------~----~------~--~--- From xj2106 at columbia.edu Sat Mar 8 00:29:23 2008 From: xj2106 at columbia.edu (Xiao-Yong Jin) Date: Sat Mar 8 00:27:15 2008 Subject: [Haskell-cafe] Exception handling when using STUArray Message-ID: <87wsod6ax8.fsf@columbia.edu> Dear list, I'm using STUArray in some of my time critical number crunching code. I would like to know some way to catch the exceptions raised in the ST monad, ie. ArrayException. Looking through the Control.Exception module, I understand that those functions can only be used within IO monad. So my question is, what the best way to do exception handling in STUArray is. Plus, it would be helpful if I can also raise an exception in ST monad, but how? Thanks, Xiao-Yong -- c/* __o/* <\ * (__ */\ < From johan.tibell at gmail.com Sat Mar 8 03:56:36 2008 From: johan.tibell at gmail.com (Johan Tibell) Date: Sat Mar 8 03:53:53 2008 Subject: [Haskell-cafe] Difficulties implementing an incremental parser using Oleg-style left fold enumerator Message-ID: <90889fe70803080056u143f1cdka322fabbfb5e4a9d@mail.gmail.com> Dear haskell-cafe, I'm trying to write a parser combinator library with the following contraints: * Parses LL(1) grammars. * Is incremental i.e. it uses an Oleg style left fold enumerator to receive its input. * Is applicative but not monadic. The problem -- maybe there are others too -- is that when a parser such as many (byte 65) is run it will always return a 'Partial' result waiting for more input even though the enumerator is exhausted. In other words, there's no way to detect end of input. My current implementation of the parser type is newtype Parser r a = Parser { unParser :: S -> (a -> S -> Result r) -> (S -> Result r) -> Result r } where the first parameter is the parse state, the second a success continuation, and the third a failure continuation. The only tricky part (except for the above mentioned problem) is to implement the choice operator. I implement mine as instance Applicative (Parser r) where pure a = ... p <*> p' = Parser $ \s succ fail -> flip (unParser p s) fail $ \f s' -> unParser p' s' (succ . f) fail which I think is correct. Here follows my code. I hope someone has some idea how I could handle the end of input problem correctly. Thanks. -- Johan {-# LANGUAGE DeriveDataTypeable, Rank2Types #-} ----------------------------------------------------------------------------- -- | -- Module : Parsing.IParse -- Copyright : (c) Johan Tibell 2008 -- License : BSD3-style (see LICENSE) -- -- Maintainer : johan.tibell@gmail.com -- Stability : experimental -- Portability : portable -- -- An incremental LL(1) parser combinator library. -- ----------------------------------------------------------------------------- module Parsing.IParse ( -- * The 'Parser' type Parser, Enumerator, parse, -- * Primitive parsers satisfy, byte, module Control.Applicative ) where import Control.Applicative (Alternative(..), Applicative(..)) import Control.Monad (Functor(..)) import qualified Data.ByteString as S import Data.Int (Int64) import Data.Typeable (Typeable, showsTypeRep, typeOf) import Data.Word (Word8) import Prelude hiding (fail, succ) -- --------------------------------------------------------------------- -- The Parser type -- | The parse state. data S = S {-# UNPACK #-} !S.ByteString {-# UNPACK #-} !Int64 deriving Show -- | A parse either succeeds, fails or returns a suspension with which -- the parsing can be resumed. data Result a = Finished a S | Failed Int64 | Partial (S.ByteString -> Result a) deriving Typeable -- | For debug output. instance (Show a, Typeable a) => Show (Result a) where showsPrec d (Finished a s) = showParen (d > 10) showStr where showStr = showString "Finished " . showsPrec 11 a . showString " " . showsPrec 11 s showsPrec d (Failed pos) = showParen (d > 10) showStr where showStr = showString "Failed " . showsPrec 11 pos showsPrec d (Partial k) = showParen (d > 10) showStr where showStr = showString "Partial " . showsTypeRep (typeOf k) -- | A parser takes a parse state, a success continuation and a -- failure continuation and returns a 'Result'. newtype Parser r a = Parser { unParser :: S -> (a -> S -> Result r) -> (S -> Result r) -> Result r } -- --------------------------------------------------------------------- -- Instances instance Functor (Parser r) where fmap f p = Parser $ \s succ fail -> unParser p s (succ . f) fail instance Applicative (Parser r) where pure a = Parser $ \s succ _ -> succ a s p <*> p' = Parser $ \s succ fail -> flip (unParser p s) fail $ \f s' -> unParser p' s' (succ . f) fail instance Alternative (Parser r) where empty = Parser $ \s _ fail -> fail s p <|> p' = Parser $ \s@(S _ pos) succ fail -> unParser p s succ $ \s'@(S _ pos') -> if pos == pos' then unParser p' s' succ fail else fail s' -- --------------------------------------------------------------------- -- Running a parser -- | The initial, empty parse state. initState :: S initState = S S.empty 0 -- | This is the final continuation that turns a successful parse into -- a 'Result'. finishedCont :: a -> S -> Result a finishedCont v s = Finished v s -- | This is the final continuation that turns an unsuccessful parse -- into a 'Result'. failedCont :: S -> Result a failedCont (S _ pos) = Failed pos -- | A enumerator is a partially applied left fold over some -- 'S.ByteString' input. The caller supplies an initial seed and an -- iteratee function. The iteratee function returns @Left seed@ if it -- want to terminate the iteration early, otherwise @Right seed@. type Enumerator m s = (s -> S.ByteString -> Either s s) -> s -> m s -- | @parse p enumerator@ runs the parser @p@, pulling in new data -- using @enumerator@ when necessary, and return @Left pos@ on failure -- and @Right val remaining@ on success. parse :: Monad m => Parser r r -> (forall s. Enumerator m s) -> m (Either Int64 (r, S.ByteString)) parse p enumerator = -- First test if the parser can succeed without consuming any -- input. let seed = (unParser p) initState finishedCont failedCont in case seed of Failed pos -> return $ Left pos Finished x (S s _) -> return $ Right (x, s) _ -> -- Otherwise, use the enumerator to feed the parser some -- input. do (result, pos) <- enumerator iter (seed, 0) return $ case result of Failed pos' -> Left pos' Finished x (S s _) -> Right (x, s) Partial _ -> Left pos where iter (Partial k, pos) chunk = let pos' = pos + fromIntegral (S.length chunk) in case k chunk of partial@(Partial _) -> Right (partial, pos') result -> Left (result, pos') iter _ _ = error "Should be partial." -- --------------------------------------------------------------------- -- Primitive parsers -- | The parser @satisfy p@ succeeds for any character for which the -- supplied function @p@ returns 'True'. Returns the character that -- is actually parsed. satisfy :: (Word8 -> Bool) -> Parser r Word8 satisfy p = Parser $ \st@(S s pos) succ fail -> case S.uncons s of Just (b, bs) -> if p b then succ b (S bs (pos + 1)) else fail st Nothing -> Partial $ \s' -> unParser (satisfy p) (S s' pos) succ fail -- | @byte b@ parses a single byte @b@. Returns the parsed byte -- (i.e. @b@). byte :: Word8 -> Parser r Word8 byte b = satisfy (== b) From johan.tibell at gmail.com Sat Mar 8 03:59:44 2008 From: johan.tibell at gmail.com (Johan Tibell) Date: Sat Mar 8 03:57:03 2008 Subject: [Haskell-cafe] Re: Difficulties implementing an incremental parser using Oleg-style left fold enumerator In-Reply-To: <90889fe70803080056u143f1cdka322fabbfb5e4a9d@mail.gmail.com> References: <90889fe70803080056u143f1cdka322fabbfb5e4a9d@mail.gmail.com> Message-ID: <90889fe70803080059h961c44eu47bcac82a252dc20@mail.gmail.com> On Sat, Mar 8, 2008 at 9:56 AM, Johan Tibell wrote: > My current implementation of the parser type is > > newtype Parser r a = Parser > { unParser :: S -> (a -> S -> Result r) -> (S -> Result r) -> Result r } > > where the first parameter is the parse state, the second a success > continuation, and the third a failure continuation. The only tricky > part (except for the above mentioned problem) is to implement the > choice operator. I implement mine as > > instance Applicative (Parser r) where > pure a = ... > p <*> p' = Parser $ \s succ fail -> > flip (unParser p s) fail $ \f s' -> > unParser p' s' (succ . f) fail Copied the wrong code, here's the implementation of <|> instance Alternative (Parser r) where empty = ... p <|> p' = Parser $ \s@(S _ pos) succ fail -> unParser p s succ $ \s'@(S _ pos') -> if pos == pos' then unParser p' s' succ fail else fail s' -- Johan From dbueno at gmail.com Sat Mar 8 09:31:15 2008 From: dbueno at gmail.com (Denis Bueno) Date: Sat Mar 8 09:28:34 2008 Subject: [Haskell-cafe] Exception handling when using STUArray In-Reply-To: <87wsod6ax8.fsf@columbia.edu> References: <87wsod6ax8.fsf@columbia.edu> Message-ID: <6dbd4d000803080631s5d16e43cr7f7b2623c932b175@mail.gmail.com> On Sat, Mar 8, 2008 at 12:29 AM, Xiao-Yong Jin wrote: > I'm using STUArray in some of my time critical number > crunching code. I would like to know some way to catch the > exceptions raised in the ST monad, ie. ArrayException. I am also using STUArray from some time-critical code; however, I don't deal with ArrayException, or any exceptions for that matter. What besides an out-of-bounds read or write might throw an ArrayException? If it is out-of-bounds reading or writing, surely that indicates a bug in your program that you'd rather fix than catch the exception, no? Also, if you're using GHC, note that the ArrayException documentation says: "(NOTE: GHC currently does not throw ArrayExceptions)." > Looking through the Control.Exception module, I understand > that those functions can only be used within IO monad. So This isn't quite true, if I understand what you mean. The function throw can be used from any code (http://haskell.org/ghc/docs/latest/html/libraries/base/Control-Exception.html). But you must catch exceptions in the IO monad. > my question is, what the best way to do exception handling > in STUArray is. Plus, it would be helpful if I can also > raise an exception in ST monad, but how? I think what I noted in the last paragraph solves this problem. -- Denis From xj2106 at columbia.edu Sat Mar 8 09:54:44 2008 From: xj2106 at columbia.edu (Xiao-Yong Jin) Date: Sat Mar 8 09:52:40 2008 Subject: [Haskell-cafe] Exception handling when using STUArray In-Reply-To: <6dbd4d000803080631s5d16e43cr7f7b2623c932b175@mail.gmail.com> (Denis Bueno's message of "Sat, 8 Mar 2008 09:31:15 -0500") References: <87wsod6ax8.fsf@columbia.edu> <6dbd4d000803080631s5d16e43cr7f7b2623c932b175@mail.gmail.com> Message-ID: <87skz15kqz.fsf@columbia.edu> "Denis Bueno" writes: > On Sat, Mar 8, 2008 at 12:29 AM, Xiao-Yong Jin wrote: >> I'm using STUArray in some of my time critical number >> crunching code. I would like to know some way to catch the >> exceptions raised in the ST monad, ie. ArrayException. > > I am also using STUArray from some time-critical code; however, I > don't deal with ArrayException, or any exceptions for that matter. > What besides an out-of-bounds read or write might throw an > ArrayException? If it is out-of-bounds reading or writing, surely > that indicates a bug in your program that you'd rather fix than catch > the exception, no? In my case, because I choose a index of the array according to certain value in the array, if there is NaN or Infinity in the array, the code breaks. So I guess, to fix the code, I would probably use isNaN/isInfinite and throw an exception when that happens. > Also, if you're using GHC, note that the ArrayException documentation says: > > "(NOTE: GHC currently does not throw ArrayExceptions)." > >> Looking through the Control.Exception module, I understand >> that those functions can only be used within IO monad. So > > This isn't quite true, if I understand what you mean. The function > throw can be used from any code > (http://haskell.org/ghc/docs/latest/html/libraries/base/Control-Exception.html). > But you must catch exceptions in the IO monad. Thanks for the clarification. I didn't read the documentation carefully. I'll experiment on `throw', right now. Xiao-Yong -- c/* __o/* <\ * (__ */\ < From dbueno at gmail.com Sat Mar 8 10:47:20 2008 From: dbueno at gmail.com (Denis Bueno) Date: Sat Mar 8 10:44:38 2008 Subject: [Haskell-cafe] Exception handling when using STUArray In-Reply-To: <87skz15kqz.fsf@columbia.edu> References: <87wsod6ax8.fsf@columbia.edu> <6dbd4d000803080631s5d16e43cr7f7b2623c932b175@mail.gmail.com> <87skz15kqz.fsf@columbia.edu> Message-ID: <6dbd4d000803080747i41283ee7wa2c25a7214a703b@mail.gmail.com> On Sat, Mar 8, 2008 at 9:54 AM, Xiao-Yong Jin wrote: > > ArrayException? If it is out-of-bounds reading or writing, surely > > that indicates a bug in your program that you'd rather fix than catch > > the exception, no? > > In my case, because I choose a index of the array according > to certain value in the array, if there is NaN or Infinity > in the array, the code breaks. So I guess, to fix the code, > I would probably use isNaN/isInfinite and throw an exception > when that happens. I see. In that case, you should check out the ErrorT monad transformer (http://haskell.org/ghc/docs/latest/html/libraries/mtl/Control-Monad-Error.html#t%3AErrorT); it lets you throw an error conveniently using Either. It may or may not fit your needs, but at least it's worth knowing about. And in case you don't understand monad transformers: if you understand the State monad, the following post is a fairly nice, minimal explanation of monad transformers: http://sigfpe.blogspot.com/2006/05/grok-haskell-monad-transformers.html -- Denis From xj2106 at columbia.edu Sat Mar 8 14:19:01 2008 From: xj2106 at columbia.edu (Xiao-Yong Jin) Date: Sat Mar 8 14:16:55 2008 Subject: [Haskell-cafe] Exception handling when using STUArray In-Reply-To: <6dbd4d000803080747i41283ee7wa2c25a7214a703b@mail.gmail.com> (Denis Bueno's message of "Sat, 8 Mar 2008 10:47:20 -0500") References: <87wsod6ax8.fsf@columbia.edu> <6dbd4d000803080631s5d16e43cr7f7b2623c932b175@mail.gmail.com> <87skz15kqz.fsf@columbia.edu> <6dbd4d000803080747i41283ee7wa2c25a7214a703b@mail.gmail.com> Message-ID: <87d4q581ne.fsf@columbia.edu> "Denis Bueno" writes: > On Sat, Mar 8, 2008 at 9:54 AM, Xiao-Yong Jin wrote: >> > ArrayException? If it is out-of-bounds reading or writing, surely >> > that indicates a bug in your program that you'd rather fix than catch >> > the exception, no? >> >> In my case, because I choose a index of the array according >> to certain value in the array, if there is NaN or Infinity >> in the array, the code breaks. So I guess, to fix the code, >> I would probably use isNaN/isInfinite and throw an exception >> when that happens. > > I see. In that case, you should check out the ErrorT monad transformer > (http://haskell.org/ghc/docs/latest/html/libraries/mtl/Control-Monad-Error.html#t%3AErrorT); > it lets you throw an error conveniently using Either. It may or may > not fit your needs, but at least it's worth knowing about. > > And in case you don't understand monad transformers: if you understand > the State monad, the following post is a fairly nice, minimal > explanation of monad transformers: > http://sigfpe.blogspot.com/2006/05/grok-haskell-monad-transformers.html Thanks. I do need to learn some monad transformers. And this post is indeed very helpful. Xiao-Yong -- c/* __o/* <\ * (__ */\ < From lemming at henning-thielemann.de Sat Mar 8 15:33:39 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sat Mar 8 15:29:46 2008 Subject: [Haskell-cafe] Exception handling when using STUArray In-Reply-To: <6dbd4d000803080631s5d16e43cr7f7b2623c932b175@mail.gmail.com> References: <87wsod6ax8.fsf@columbia.edu> <6dbd4d000803080631s5d16e43cr7f7b2623c932b175@mail.gmail.com> Message-ID: On Sat, 8 Mar 2008, Denis Bueno wrote: > On Sat, Mar 8, 2008 at 12:29 AM, Xiao-Yong Jin wrote: >> I'm using STUArray in some of my time critical number >> crunching code. I would like to know some way to catch the >> exceptions raised in the ST monad, ie. ArrayException. > > I am also using STUArray from some time-critical code; however, I > don't deal with ArrayException, or any exceptions for that matter. > What besides an out-of-bounds read or write might throw an > ArrayException? If it is out-of-bounds reading or writing, surely > that indicates a bug in your program that you'd rather fix than catch > the exception, no? Another instance of mixing up exceptions and errors in the Haskell libraries. http://www.haskell.org/haskellwiki/Error http://www.haskell.org/haskellwiki/Exception > Also, if you're using GHC, note that the ArrayException documentation says: > > "(NOTE: GHC currently does not throw ArrayExceptions)." > >> Looking through the Control.Exception module, I understand >> that those functions can only be used within IO monad. So > > This isn't quite true, if I understand what you mean. The function > throw can be used from any code > (http://haskell.org/ghc/docs/latest/html/libraries/base/Control-Exception.html). > But you must catch exceptions in the IO monad. > >> my question is, what the best way to do exception handling >> in STUArray is. Plus, it would be helpful if I can also >> raise an exception in ST monad, but how? > > I think what I noted in the last paragraph solves this problem. From agl at imperialviolet.org Sat Mar 8 16:11:30 2008 From: agl at imperialviolet.org (Adam Langley) Date: Sat Mar 8 16:08:48 2008 Subject: [Haskell-cafe] Re: Difficulties implementing an incremental parser using Oleg-style left fold enumerator In-Reply-To: <90889fe70803080056u143f1cdka322fabbfb5e4a9d@mail.gmail.com> References: <90889fe70803080056u143f1cdka322fabbfb5e4a9d@mail.gmail.com> Message-ID: <396556a20803081311g4a564870xacb07fd49f835d1e@mail.gmail.com> On Sat, Mar 8, 2008 at 12:56 AM, Johan Tibell wrote: > The problem -- maybe there are others too -- is that when a parser such as > > many (byte 65) > > is run it will always return a 'Partial' result waiting for more input > even though the enumerator is exhausted. In other words, there's no > way to detect end of input. It appears that you need some way to distinguish the end of input from, "that's all I have for now". You could use an empty Bytestring in S if you were careful that you maintained that, in normal processing, such a state doesn't arise. Otherwise, have a Maybe in your state and set it to Nothing when the input is exhausted. Then have combinators, like many, handle the EOF case sensibly. AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org From johan.tibell at gmail.com Sat Mar 8 17:53:27 2008 From: johan.tibell at gmail.com (Johan Tibell) Date: Sat Mar 8 17:50:44 2008 Subject: [Haskell-cafe] Re: Difficulties implementing an incremental parser using Oleg-style left fold enumerator In-Reply-To: <396556a20803081311g4a564870xacb07fd49f835d1e@mail.gmail.com> References: <90889fe70803080056u143f1cdka322fabbfb5e4a9d@mail.gmail.com> <396556a20803081311g4a564870xacb07fd49f835d1e@mail.gmail.com> Message-ID: <90889fe70803081453l16f8f936j446f5a5b48105475@mail.gmail.com> On Sat, Mar 8, 2008 at 10:11 PM, Adam Langley wrote: > On Sat, Mar 8, 2008 at 12:56 AM, Johan Tibell wrote: > > The problem -- maybe there are others too -- is that when a parser such as > > > > many (byte 65) > > > > is run it will always return a 'Partial' result waiting for more input > > even though the enumerator is exhausted. In other words, there's no > > way to detect end of input. > > It appears that you need some way to distinguish the end of input > from, "that's all I have for now". You could use an empty Bytestring > in S if you were careful that you maintained that, in normal > processing, such a state doesn't arise. Otherwise, have a Maybe in > your state and set it to Nothing when the input is exhausted. Then > have combinators, like many, handle the EOF case sensibly. I changed the type of Partial to Maybe ByteString -> Result a so that the client can specify EOF. -- Johan From tphyahoo at gmail.com Sat Mar 8 22:06:56 2008 From: tphyahoo at gmail.com (Thomas Hartman) Date: Sat Mar 8 22:04:13 2008 Subject: [Haskell-cafe] deriving instances of Enum for tuples of bounded, enumerable types (useful for generating QuickCheck.Arbitrary instances for collection of collection types) Message-ID: <910ddf450803081906p534968f1l880b05cd67251312@mail.gmail.com> I have some code for creating instances of Enum for a tuple of bounded enumerable types. The main win with this was that it makes it easier for me to generate Test.QuickCheck.Arbitrary instances for types that are based on collections of enumerable collections -- like you might get when modeling poker for instance. In fact, I was trying to answer the question about using QuickCheck with poker, that Vincent Foley asked a few days ago at http://groups.google.com/group/fa.haskell/browse_thread/thread/8298c4d838c95505/4e31cc8b859bad24#4e31cc8b859bad24 when I came up with this. (And I am posting a reply to Vincent right after I finish writing this message.) Basically I noticed that coming up with the Arbitrary instances seemed to be tricker than I would have expected. However, it was pretty straightforward to write an instance of arbitrary for instance (Enum a, Bounded a) => Arbitrary a where arbitrary = do n <- choose (fromEnum (minBound :: a), fromEnum (maxBound :: a) ) return $ toEnum n So all I needed to do was get my type into instances of Enum and Bounded, and I got my Arbitrary instance for free. Most of the work was just writing the instances for various tuples of Bounded Enumerable types. Maybe I've been spoiled by how easy many types are gotten using the magic of the deriving clause, but this seemed like a lot of work to me. I was wondering if there was an easier way? Or if not, if it would make sense for something like this to be added to the prelude? Or is there some sizeable collection of nice Arbitrary instances for QuickCheck somewheres that I can leverage off of, that hasn't made it into the standard libraries? A minor issue: I had a question if I could make the type signatures for Enum instances less verbose by doing something like type BoundedEnum = (Bounded a, Enum a) => a... I tried, and commented out my attempt as it wouldn't type check. Guidance appreciated. Thanks, Thomas. Code follows: {-# OPTIONS -fglasgow-exts -fallow-undecidable-instances #-} module EnumInstances where -- instances of Enum for tuples of types that are both Bounded and Enum -- typechecks, and does the right thing, though this signature seems messy, specially when I -- want to do this kind of thing for longer tuples instance (Enum a, Enum b,Bounded a, Bounded b) => Enum (a,b) where fromEnum (primero,segundo) = ( divFactor * (fromEnum primero) ) + (fromEnum segundo) where divFactor = fromEnum (maxBound :: b) + 1 toEnum i | (i > (fromEnum (maxBound :: (a,b)))) || (i < (fromEnum (minBound :: (a,b)))) = error "Enum (a,b) bounds error" | otherwise = (a,b) where a = toEnum baseline b = toEnum $ i - (baseline * divFactor ) baseline = i `div` divFactor divFactor = (fromEnum (maxBound :: b)) + 1 -- I tried to use a type synonym to write a cleaner type syg but... type BoundedEnumerable = (Enum a, Bounded a) => a -- does not typecheck. oh well, the verbose signatures aren't all that bad. {- instance Enum (BoundedEnumerable,BoundedEnumerable) where fromEnum (primero,segundo) = ( divFactor * (fromEnum primero) ) + (fromEnum segundo) where divFactor = fromEnum (maxBound :: b) + 1 toEnum i | (i > (fromEnum (maxBound :: (a,b)))) || (i < (fromEnum (minBound :: (a,b)))) = error "Enum (a,b) bounds error" | otherwise = (a,b) where a = toEnum baseline b = toEnum $ i - (baseline * divFactor ) baseline = i `div` divFactor divFactor = (fromEnum (maxBound :: b)) + 1 -} instance (Enum t, Enum t1, Enum t2, Bounded t, Bounded t1, Bounded t2) => Enum (t,t1,t2) where fromEnum (a,b,c) = fromEnum ((a,b),c) toEnum i = (a,b,c) where ((a,b),c) = toEnum i instance (Enum t, Enum t1, Enum t2, Enum t3, Bounded t, Bounded t1, Bounded t2, Bounded t3) => Enum (t,t1,t2,t3) where fromEnum (a,b,c,d) = fromEnum ((a,b,c),d) toEnum i = (a,b,c,d) where ((a,b,c),d) = toEnum i instance (Enum t, Enum t1, Enum t2, Enum t3, Enum t4, Bounded t, Bounded t1, Bounded t2, Bounded t3, Bounded t4) => Enum (t,t1,t2,t3,t4) where fromEnum (a,b,c,d,e) = fromEnum ((a,b,c,d),e) toEnum i = (a,b,c,d,e) where ((a,b,c,d),e) = toEnum i From tphyahoo at gmail.com Sat Mar 8 22:21:21 2008 From: tphyahoo at gmail.com (Thomas Hartman) Date: Sat Mar 8 22:18:38 2008 Subject: [Haskell-cafe] reply to vincent foley's question about poker Message-ID: <910ddf450803081921w1e0f6647h9c36d672c145e759@mail.gmail.com> Weirdly, I came across a question Vincent Foley asked in FA Haskell when I read it in the googlegroups interface, http://groups.google.com/group/fa.haskell/browse_thread/thread/8298c4d838c95505/bef67f52f0f28bc5#bef67f52f0f28bc5 but I don't seem to have his question in my inbox where I get haskell cafe. Maybe it got filtered somehow? I notice nobody else from Haskell Cafe seems to have answered, and this is usually a pretty helpful place so I am thinking maybe it really did get filtered. Oh well, I will answer it anyway now.. The question had to do with writing Arbitrary instances for datatypes useful for playing poker, and using quickCheck with them. I like my solution because I get Arbitrary instances for basically every datatype that's involved, from a single definition that gives you Arbitrary for any type a that is both Enum and Bounded. instance (Enum a, Bounded a) => Arbitrary a where arbitrary = do n <- choose (fromEnum (minBound :: a), fromEnum (maxBound :: a) ) return $ toEnum n Here's the code. (Note: For the code to compile you need the EnumInstances .hs module. I posted this a few minutes ago on haskell cafe.) {-# OPTIONS -fglasgow-exts -fallow-undecidable-instances #-} module Cards where import Test.QuickCheck import Control.Arrow import Debug.Trace import EnumInstances -- Types data Suit = Clubs | Diamond | Heart | Spade deriving (Show, Eq, Bounded, Enum, Ord) data Rank = Ace | Two | Three | Four | Five | Six | Seven | Eight | Nine | Ten | Jack | Queen | King deriving (Show, Eq, Bounded, Enum,Ord) --instance Arbitrary Rank where -- arbitrary = return $ choose data Card = Card (Rank, Suit) deriving (Eq,Show,Bounded, Ord) instance Enum Card where fromEnum (Card (r,s)) = fromEnum (r,s) toEnum i = Card (toEnum i) -- to check a new instance with quickCheck -- quickCheck (pEnum :: SomeType -> Bool) pEnum x = x == (toEnum . fromEnum) x -- type Hand = [Card] -- a hand is five cards data Hand = Hand Card Card Card Card Card deriving (Eq,Show, Bounded) instance Enum Hand where fromEnum (Hand a b c d e) = fromEnum (a,b,c,d,e) toEnum i = Hand a b c d e where (a,b,c,d,e) = toEnum i instance (Enum a, Bounded a) => Arbitrary a where arbitrary = do n <- choose (fromEnum (minBound :: a), fromEnum (maxBound :: a) ) return $ toEnum n -- not a very useful property, and certainly fails -- but it proves we have a working Arbitrary instance for Hand. pHandIsAlwaysAceOfClubs h = h == (Hand c c c c c) where c = Card (Ace, Clubs) t1 = do quickCheck (pEnum :: Rank -> Bool) quickCheck (pEnum :: Suit -> Bool) quickCheck (pEnum :: Card -> Bool) quickCheck (pEnum :: Hand -> Bool) quickCheck pHandIsAlwaysAceOfClubs -- of course this fails traceIt x = trace (show x) x From allbery at ece.cmu.edu Sat Mar 8 22:23:02 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sat Mar 8 22:20:18 2008 Subject: [Haskell-cafe] deriving instances of Enum for tuples of bounded, enumerable types (useful for generating QuickCheck.Arbitrary instances for collection of collection types) In-Reply-To: <910ddf450803081906p534968f1l880b05cd67251312@mail.gmail.com> References: <910ddf450803081906p534968f1l880b05cd67251312@mail.gmail.com> Message-ID: On Mar 8, 2008, at 22:06 , Thomas Hartman wrote: > A minor issue: I had a question if I could make the type signatures > for Enum instances less verbose by doing something like type > BoundedEnum = (Bounded a, Enum a) => a... I tried, and commented out > my attempt as it wouldn't type check. Guidance appreciated. Nope. Uses of "type" declarations are self-contained; if you do type BoundedEnum = (Bounded a, Enum a) => a myFunc :: BoundedEnum -> BoundedEnum -> BoundedEnum each instance of BoundedEnum in the declaration of BoundedEnum refers to a distinct a. More technically, the declaration expands to: myFunc :: (forall a. (Bounded a, Enum a) => a) -> (forall a. (Bounded a, Enum a) => a) -> (forall a. (Bounded a, Enum a) => a) which is a rather useless declaration (I think the only inhabitant of that type is _|_). And yes, this is annoying. I think you might be able to do this as a typeclass instead, at the expense of having to insert an instance declaration for each type. (You will have to use an extension if you want to declare instances for types such as Int. I think.) class (Bounded a, Enum a) => BoundedEnum a where -- empty instance BoundedEnum MyType a where instance BoundedEnum Int where -- requires FlexibleInstances? -- 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 Sat Mar 8 23:15:06 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Sat Mar 8 23:12:26 2008 Subject: [Haskell-cafe] reply to vincent foley's question about poker In-Reply-To: <910ddf450803081921w1e0f6647h9c36d672c145e759@mail.gmail.com> References: <910ddf450803081921w1e0f6647h9c36d672c145e759@mail.gmail.com> Message-ID: <7ca3f0160803082015l5d7d5718t7c85781c509218ec@mail.gmail.com> On Sun, Mar 9, 2008 at 3:21 AM, Thomas Hartman wrote: > instance (Enum a, Bounded a) => Arbitrary a where > arbitrary = do n <- choose (fromEnum (minBound :: a), fromEnum > (maxBound :: a) ) > return $ toEnum n I really think it's a bad idea to allow undecidable instances. While it may seem to work for small problems, when you start using undecidable instances in larger pieces of software, you will get elusive typecheker errors (stack overflows / infinite loops) which magically appear and disappear with small changes to the code. You probably already know this, but the evil of undecidable instances makes itself pretty apparent once you understand how the typeclass algorithm works. Here's how it goes, anthropomorphically: * I see a call to arbitrary; I will call its return value "a". The call to arbitrary comes with the constraint "Arbitrary a". ... in the future, when generalizing the type ... * I see that "a" has be unified to "[b]" (for some b). I need an instance for "Arbitrary [b]". Ah, here's one (seeing the instance above). Now I have "Arbitrary [b]", and I thus have to add the constraints "Enum [b]" and "Bounded [b]" ... continue solving... The thing to note is that we did not *check* that we had "Enum [b]" and "Bounded [b]" before using the instance "Arbitrary [b]"; rather it worked the other way round: We found an instance "Arbitrary [b]" and that induced some new constraints for us. That means that if you have, say, these two instances: instance (Arbitrary a) => Aribtrary [a] instance (Enum a, Bounded a) => Aribtrary a If you have a list type that you need to be an instance of Aribtrary, if you're unlucky it will pick the second one and you'll end up with Enum [a] and Bounded [a], which won't be satisfiable. There is no backtracking, you just get a type error where there (according to you) should not be one. I believe GHC has some rules to minimize the occurences of such "unluckiness", but they're just heuristic and don't provide any guarantee (and thus only propagate the illusion that instances like this are actually okay). This is an example where undecidable instances will lead to indeterminate behavior, but there are other trickier cases where you get an infinite loop, which is fixable only by knowing how the algorithm works and placing a type annotation in the most obscure corner of some function. Okay, now that that rant is done, what is the safe way to accomplish what you want? Wrap it in a newtype: newtype EnumArbitrary a = EnumArbitrary { fromEnumArbitrary :: a } instance (Enum a, Bounded a) => Arbitrary (EnumArbitrary a) where ... This is a perfectly fine, well behaved H98 instance. You mark when you want to use this instance by appearances of the constructor EnumArbitrary, so you don't run into cases like the above. However, many times for usability purposes I run into situations where I want a generic instance like the one you used. Props to anyone who can come up with a typeclass system which allows such things and has decidable and predictable inference. Luke From lrpalmer at gmail.com Sat Mar 8 23:32:58 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Sat Mar 8 23:30:15 2008 Subject: [Haskell-cafe] deriving instances of Enum for tuples of bounded, enumerable types (useful for generating QuickCheck.Arbitrary instances for collection of collection types) In-Reply-To: References: <910ddf450803081906p534968f1l880b05cd67251312@mail.gmail.com> Message-ID: <7ca3f0160803082032v2adebaf2w6a12f2e207578a4e@mail.gmail.com> On Sun, Mar 9, 2008 at 3:23 AM, Brandon S. Allbery KF8NH wrote: > myFunc :: (forall a. (Bounded a, Enum a) => a) -> > (forall a. (Bounded a, Enum a) => a) -> > (forall a. (Bounded a, Enum a) => a) > > which is a rather useless declaration (I think the only inhabitant of > that type is _|_). Just to nitpick: this function type is quite specific, and there are many non _|_ implementations. myFunc a b = a myFunc a b = b myFunc a b = toEnum (f a b) where f :: Int -> Int -> Int ... Luke From vigalchin at gmail.com Sun Mar 9 00:37:29 2008 From: vigalchin at gmail.com (Galchin Vasili) Date: Sun Mar 9 00:34:46 2008 Subject: [Haskell-cafe] c_open and c_close signatures in the unix package Message-ID: <5ae4f2ba0803082137j242f1663o2d1ca7dcf032c577@mail.gmail.com> Hello, I need to find the c_open and c_close signatures that are referenced in unix/System/Posix/IO.hsc. Thanks, Vasya -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080308/3af1b544/attachment-0001.htm From vigalchin at gmail.com Sun Mar 9 00:39:27 2008 From: vigalchin at gmail.com (Galchin Vasili) Date: Sun Mar 9 00:36:43 2008 Subject: [Haskell-cafe] STM example code Message-ID: <5ae4f2ba0803082139mff44e30haf09ad07713852ba@mail.gmail.com> Hello, I am playing around with the STM API. I would like to see examples of STM other than the Santa.hs as I am having problems with STM vs IO. Thanks, Vasili -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080308/21c194dd/attachment.htm From allbery at ece.cmu.edu Sun Mar 9 00:51:53 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sun Mar 9 00:49:09 2008 Subject: [Haskell-cafe] c_open and c_close signatures in the unix package In-Reply-To: <5ae4f2ba0803082137j242f1663o2d1ca7dcf032c577@mail.gmail.com> References: <5ae4f2ba0803082137j242f1663o2d1ca7dcf032c577@mail.gmail.com> Message-ID: <464BD50A-8F39-4E00-A7AD-04259AC0720E@ece.cmu.edu> On Mar 9, 2008, at 0:37 , Galchin Vasili wrote: > I need to find the c_open and c_close signatures that are > referenced in unix/System/Posix/IO.hsc. base/System/Posix/Internals.hs, according to a quick find|grep. -- 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 donn at avvanta.com Sun Mar 9 01:43:20 2008 From: donn at avvanta.com (Donn Cave) Date: Sun Mar 9 01:40:39 2008 Subject: [Haskell-cafe] Exception handling when using STUArray In-Reply-To: References: <87wsod6ax8.fsf@columbia.edu> <6dbd4d000803080631s5d16e43cr7f7b2623c932b175@mail.gmail.com> Message-ID: On Mar 8, 2008, at 12:33 PM, Henning Thielemann wrote: > On Sat, 8 Mar 2008, Denis Bueno wrote: ... >> I am also using STUArray from some time-critical code; however, I >> don't deal with ArrayException, or any exceptions for that matter. >> What besides an out-of-bounds read or write might throw an >> ArrayException? If it is out-of-bounds reading or writing, surely >> that indicates a bug in your program that you'd rather fix than catch >> the exception, no? > > Another instance of mixing up exceptions and errors in the Haskell > libraries. > http://www.haskell.org/haskellwiki/Error > http://www.haskell.org/haskellwiki/Exception This seems to me one of the disappointments of Haskell - not just a detail that was handled in an awkward way, but a fundamental flaw. I'm not talking about ArrayException, whatever that is, but the notion that errors encountered in functional code mustn't be handled as exceptions. If your input file is not where you expected it and openFile fails, or it was incompletely written out and your input processing fails in a 'head' or pattern match, the difference is not very important to me. I want to be able to call your code and manage the risk that it's going to kill my server. You may feel that it's your job to write more robust functional code that can't run into these errors, but C programmers can be found who insist that it's the programmer's job to manage heap memory and it isn't all that hard. A programming language that fails to make it easier to write more robust code, is not moving us forward. I rejoice that Haskell isn't as miserable as C, but with respect to exceptions and errors, it's behind for example Python. Languages that can, use exceptions like IndexError. Evidently, Haskell fundamentally can't. That's too bad. Donn Cave, donn@avvanta.com From dons at galois.com Sun Mar 9 01:54:24 2008 From: dons at galois.com (Don Stewart) Date: Sun Mar 9 01:51:41 2008 Subject: [Haskell-cafe] Exception handling when using STUArray In-Reply-To: References: <87wsod6ax8.fsf@columbia.edu> <6dbd4d000803080631s5d16e43cr7f7b2623c932b175@mail.gmail.com> Message-ID: <20080309065424.GA23232@scytale.galois.com> donn: > > On Mar 8, 2008, at 12:33 PM, Henning Thielemann wrote: > > >On Sat, 8 Mar 2008, Denis Bueno wrote: > ... > >>I am also using STUArray from some time-critical code; however, I > >>don't deal with ArrayException, or any exceptions for that matter. > >>What besides an out-of-bounds read or write might throw an > >>ArrayException? If it is out-of-bounds reading or writing, surely > >>that indicates a bug in your program that you'd rather fix than catch > >>the exception, no? > > > >Another instance of mixing up exceptions and errors in the Haskell > >libraries. > > http://www.haskell.org/haskellwiki/Error > > http://www.haskell.org/haskellwiki/Exception > > This seems to me one of the disappointments of Haskell - not just a > detail that was handled in an awkward way, but a fundamental flaw. > I'm not talking about ArrayException, whatever that is, but the notion > that errors encountered in functional code mustn't be handled as > exceptions. > > If your input file is not where you expected it and openFile fails, > or it was > incompletely written out and your input processing fails in a 'head' or > pattern match, the difference is not very important to me. I want to be > able to call your code and manage the risk that it's going to kill my > server. > You may feel that it's your job to write more robust functional code > that > can't run into these errors, but C programmers can be found who insist > that it's the programmer's job to manage heap memory and it isn't all > that hard. A programming language that fails to make it easier to write > more robust code, is not moving us forward. I rejoice that Haskell > isn't > as miserable as C, but with respect to exceptions and errors, it's > behind > for example Python. Languages that can, use exceptions like IndexError. > Evidently, Haskell fundamentally can't. That's too bad. I don't understand this complaint -- you can handle all these with Control.Exception. xmonad catches all these things for example, in user code, to prevent poorly written modules throwing a pattern match exception, or calling 'error' and making the window manager unstable. Handling exceptions generated from pure code is just another part of making systems more robust -- and of course you can do it in Haskell. -- Don From allbery at ece.cmu.edu Sun Mar 9 03:09:49 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sun Mar 9 03:07:05 2008 Subject: [Haskell-cafe] Exception handling when using STUArray In-Reply-To: <20080309065424.GA23232@scytale.galois.com> References: <87wsod6ax8.fsf@columbia.edu> <6dbd4d000803080631s5d16e43cr7f7b2623c932b175@mail.gmail.com> <20080309065424.GA23232@scytale.galois.com> Message-ID: On Mar 9, 2008, at 1:54 , Don Stewart wrote: > donn: >> >> This seems to me one of the disappointments of Haskell - not just a >> detail that was handled in an awkward way, but a fundamental flaw. >> I'm not talking about ArrayException, whatever that is, but the >> notion >> that errors encountered in functional code mustn't be handled as >> exceptions. >> > I don't understand this complaint -- you can handle all these with > Control.Exception. > > xmonad catches all these things for example, in user code, to prevent > poorly written modules throwing a pattern match exception, or calling > 'error' and making the window manager unstable. > > Handling exceptions generated from pure code is just another part of > making systems more robust -- and of course you can do it in Haskell. I'm unsure what the complaint here is as well. That exceptions must be handled in IO: an exception is, by definition, an unexpected condition. These simply can not exist in the deterministic paradigm of pure code, therefore you must be in IO (home of all things nondeterministic) to catch them. That it is preferred to handle known cases without using exceptions: staying completely pure is cleaner, and gives you more control over what goes on. And enables swapping in different mechanisms to react to failure; note how using the Monad instances of Maybe, Either, or [] allows you to decide how to handle failure (and [] allows you to support multiple possible results as well, while Maybe and Either will stop processing at the first. Basically, the Haskell way is to make as much as possible pure and minimize the intrusion of IO. Exceptions necessarily complicate this, so are when possible avoided in favor of pure alternatives, which are considered better style --- but they are available in IO if needed. -- 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 s.clover at gmail.com Sun Mar 9 03:57:19 2008 From: s.clover at gmail.com (Sterling Clover) Date: Sun Mar 9 03:54:56 2008 Subject: [Haskell-cafe] Exception handling when using STUArray In-Reply-To: References: <87wsod6ax8.fsf@columbia.edu> <6dbd4d000803080631s5d16e43cr7f7b2623c932b175@mail.gmail.com> <20080309065424.GA23232@scytale.galois.com> Message-ID: <61E964B8-A42A-4151-A995-7494E1AD4EF7@gmail.com> On the other hand, there are lots of issues that can be worked on here, foax! While tools like the one is ndm is working on seem to offer a way forward, at the moment, there's no standard way that I know of besides "inspection" to determine if code might throw an exception, and this is particularly the case with the dreaded lazy IO of prelude functions. And as per a recent discussion on libraries, it's still a royal pain to catch IO exceptions in monads with an IO base. And then, of course, there's the issue of exceptions in ST or STM which have similar issues. All this could be solved if we standardized on some version of gcatch over MonadBase or a variant. The machinery just hasn't been fully written yet, although Control.Monad.Error is, sort of, a start. And of course, using head or any other partial functions in production code without a great deal of care is a really *bad idea*, but the prelude sort of locks us into having them at least. Tutorials and examples might be better served emphasizing why these things are dangerous, and common idioms for avoiding them... Regards, sclv On Mar 9, 2008, at 3:09 AM, Brandon S. Allbery KF8NH wrote: > > On Mar 9, 2008, at 1:54 , Don Stewart wrote: > >> donn: >>> >>> This seems to me one of the disappointments of Haskell - not just a >>> detail that was handled in an awkward way, but a fundamental flaw. >>> I'm not talking about ArrayException, whatever that is, but the >>> notion >>> that errors encountered in functional code mustn't be handled as >>> exceptions. >>> >> I don't understand this complaint -- you can handle all these with >> Control.Exception. >> >> xmonad catches all these things for example, in user code, to prevent >> poorly written modules throwing a pattern match exception, or calling >> 'error' and making the window manager unstable. >> >> Handling exceptions generated from pure code is just another part of >> making systems more robust -- and of course you can do it in Haskell. > > I'm unsure what the complaint here is as well. > > That exceptions must be handled in IO: an exception is, by > definition, an unexpected condition. These simply can not exist in > the deterministic paradigm of pure code, therefore you must be in > IO (home of all things nondeterministic) to catch them. > > That it is preferred to handle known cases without using > exceptions: staying completely pure is cleaner, and gives you more > control over what goes on. And enables swapping in different > mechanisms to react to failure; note how using the Monad instances > of Maybe, Either, or [] allows you to decide how to handle failure > (and [] allows you to support multiple possible results as well, > while Maybe and Either will stop processing at the first. > > Basically, the Haskell way is to make as much as possible pure and > minimize the intrusion of IO. Exceptions necessarily complicate > this, so are when possible avoided in favor of pure alternatives, > which are considered better style --- but they are available in IO > if needed. > > -- > 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 From aslatter at gmail.com Sun Mar 9 04:03:08 2008 From: aslatter at gmail.com (Antoine Latter) Date: Sun Mar 9 04:00:24 2008 Subject: [Haskell-cafe] deriving instances of Enum for tuples of bounded, enumerable types (useful for generating QuickCheck.Arbitrary instances for collection of collection types) In-Reply-To: References: <910ddf450803081906p534968f1l880b05cd67251312@mail.gmail.com> Message-ID: <694519c50803090003v5f795b7btc780c5bcea231637@mail.gmail.com> On Sat, Mar 8, 2008 at 9:23 PM, Brandon S. Allbery KF8NH > I think you might be able to do this as a typeclass instead, at the > expense of having to insert an instance declaration for each type. > (You will have to use an extension if you want to declare instances > for types such as Int. I think.) > > class (Bounded a, Enum a) => BoundedEnum a where -- empty > > instance BoundedEnum MyType a where > instance BoundedEnum Int where -- requires FlexibleInstances? I've had good luck with things like: class (Bounded a, Enum a) => BoundedEnum a instance (Bounded a, Enum a) => BoundedEnum a which picks up everything that can inhabit the new class. -Antoine From donn at avvanta.com Sun Mar 9 13:12:29 2008 From: donn at avvanta.com (Donn Cave) Date: Sun Mar 9 13:09:45 2008 Subject: [Haskell-cafe] Exception handling when using STUArray In-Reply-To: <20080309065424.GA23232@scytale.galois.com> References: <87wsod6ax8.fsf@columbia.edu> <6dbd4d000803080631s5d16e43cr7f7b2623c932b175@mail.gmail.com> <20080309065424.GA23232@scytale.galois.com> Message-ID: <92412FAB-BD4B-4D2C-A804-328A4C265FC4@avvanta.com> On Mar 8, 2008, at 10:54 PM, Don Stewart wrote: [... replying to my poorly informed rant about exceptions ... ] > > I don't understand this complaint -- you can handle all these with > Control.Exception. > > xmonad catches all these things for example, in user code, to prevent > poorly written modules throwing a pattern match exception, or calling > 'error' and making the window manager unstable. > > Handling exceptions generated from pure code is just another part of > making systems more robust -- and of course you can do it in Haskell. OK, I tried this out and found that it does work, and I thought to myself, `no more posting rants to haskell-cafe after late nights out with too much wine!' But then I changed my test error from a pattern match, to a `head', and that gets past my exception handler: module Main (main) where import System (getArgs) ax = getArgs >>= print . head px = catch ax (\ e -> putStrLn ("caught this one: " ++ show e)) main = px Is there a way to catch it, that I'm missing? What is the essential difference between these errors? If we only have to bring IO out to the locations where we want to handle errors, then that's not so bad as I thought. Incidentally, I also reviewed again the two Wiki pages previously recommended in this thread, for Error and Exception, and I really don't follow them. I know the author is well versed in Haskell and I'm sure he's trying to convey some valuable notion about the difference between errors and exceptions, but it doesn't come across and I don't think it's just me. Donn Cave, donn@avvanta.com From dons at galois.com Sun Mar 9 14:49:36 2008 From: dons at galois.com (Don Stewart) Date: Sun Mar 9 14:46:53 2008 Subject: [Haskell-cafe] Exception handling when using STUArray In-Reply-To: <92412FAB-BD4B-4D2C-A804-328A4C265FC4@avvanta.com> References: <87wsod6ax8.fsf@columbia.edu> <6dbd4d000803080631s5d16e43cr7f7b2623c932b175@mail.gmail.com> <20080309065424.GA23232@scytale.galois.com> <92412FAB-BD4B-4D2C-A804-328A4C265FC4@avvanta.com> Message-ID: <20080309184936.GA26907@scytale.galois.com> donn: > > On Mar 8, 2008, at 10:54 PM, Don Stewart wrote: > > [... replying to my poorly informed rant about exceptions ... ] > > > > >I don't understand this complaint -- you can handle all these with > >Control.Exception. > > > >xmonad catches all these things for example, in user code, to prevent > >poorly written modules throwing a pattern match exception, or calling > >'error' and making the window manager unstable. > > > >Handling exceptions generated from pure code is just another part of > >making systems more robust -- and of course you can do it in Haskell. > > OK, I tried this out and found that it does work, and I thought to > myself, > `no more posting rants to haskell-cafe after late nights out with too > much > wine!' But then I changed my test error from a pattern match, to a > `head', > and that gets past my exception handler: > > module Main (main) where > import System (getArgs) > > ax = getArgs >>= print . head > > px = catch ax (\ e -> putStrLn ("caught this one: " ++ show e)) > > main = px > > Is there a way to catch it, that I'm missing? What is the essential > difference between these errors? That's the difference between Prelude.catch and Control.Exception.catch. You almost always want Control.Exception.catch. Prelude.catch: $ runhaskell A.hs "A.hs: Prelude.head: empty list Control.Exception.catch $ runhaskell A.hs "caught this one: Prelude.head: empty list As the docs for Control.Exception say: -- Note that 'catch' catches all types of exceptions, and is generally -- used for \"cleaning up\" before passing on the exception using -- 'throwIO'. -- Also note that the "Prelude" also exports a function called -- 'Prelude.catch' with a similar type to 'Control.Exception.catch', -- except that the "Prelude" version only catches the IO and user -- families of exceptions (as required by Haskell 98). -- -- We recommend either hiding the "Prelude" version of 'Prelude.catch' -- when importing "Control.Exception" There's a number of other useful exception handlers: handle finally bracket All useful, all have their place. -- Don From mail at philip.in-aachen.net Sun Mar 9 15:27:58 2008 From: mail at philip.in-aachen.net (=?ISO-8859-15?Q?Philip_M=FCller?=) Date: Sun Mar 9 15:24:59 2008 Subject: [Haskell-cafe] simple Haskell question - List comprehensions Message-ID: <47D43A3E.2080805@philip.in-aachen.net> Hi, I'm just working through Hutton's "Programming in Haskell" and I found an exercise which I can't solve, although it looks simple. Maybe someone here could give me a hint? Exercise: Show how the single comprehension [(x,y) | x <- [1,2,3], y <- [4,5,6]] with two generators can be re-expressed using two comprehensions with single generators. Hint: make use of the library function _concat_. Thank you very much, Philip From miguelimo38 at yandex.ru Sun Mar 9 15:52:30 2008 From: miguelimo38 at yandex.ru (Miguel Mitrofanov) Date: Sun Mar 9 15:49:58 2008 Subject: [Haskell-cafe] simple Haskell question - List comprehensions In-Reply-To: <47D43A3E.2080805@philip.in-aachen.net> References: <47D43A3E.2080805@philip.in-aachen.net> Message-ID: <8D82ACE4-367E-4FE5-A1C6-31A20424FD18@yandex.ru> > Exercise: > Show how the single comprehension [(x,y) | x <- [1,2,3], y <- > [4,5,6]] with two generators can be re-expressed using two > comprehensions with single generators. > Hint: make use of the library function _concat_. Another hint: it can be rewritten as concatMap (\x -> concatMap (\y -> [(x,y)]) [4,5,6]) [1,2,3] From sebastian.sylvan at gmail.com Sun Mar 9 16:00:54 2008 From: sebastian.sylvan at gmail.com (Sebastian Sylvan) Date: Sun Mar 9 15:58:08 2008 Subject: [Haskell-cafe] simple Haskell question - List comprehensions In-Reply-To: <47D43A3E.2080805@philip.in-aachen.net> References: <47D43A3E.2080805@philip.in-aachen.net> Message-ID: <3d96ac180803091300k67e14863k47ec5278211d6f6e@mail.gmail.com> On Sun, Mar 9, 2008 at 7:27 PM, Philip M?ller wrote: > Hi, > > I'm just working through Hutton's "Programming in Haskell" and I found > an exercise which I can't solve, although it looks simple. Maybe someone > here could give me a hint? > > Exercise: > Show how the single comprehension [(x,y) | x <- [1,2,3], y <- [4,5,6]] > with two generators can be re-expressed using two comprehensions with > single generators. > Hint: make use of the library function _concat_. Another hint, list comprehensions are just values of type [ a ] (a would be Integer in this case). So in other words, in any place where you want a list, you can stick a list comprehension. In this case you want to take each x in xs, and then for each x you want to grab each y in ys, and return (x,y). Right, so we know how to do that first bit, the "for each x in xs" bit, right? Just do [ ... | x <- xs ]. And now what do we want to do for each element of x? Well we want to do "for each y in ys", right? So that's just another list comprehension [ ... | y <- ys ]. Stick the two together and you get [ [ ... | y <- ys] | x <- xs ]. So what do we want to do to x and y? Well we want to pair them: [ [ (x,y) | y <- ys] | x <- xs ]. Now, this gives us a list of lists (because each element of x will yield a list of x,y pairs, where x is constant and y is each element in ys). To flatten this into a single list, you can use concat: concat [[ (x,y) | y <- ys] | x <- xs ] -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080309/b9382248/attachment.htm From lemming at henning-thielemann.de Sun Mar 9 16:07:58 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun Mar 9 16:05:13 2008 Subject: [Haskell-cafe] Exception handling when using STUArray In-Reply-To: References: <87wsod6ax8.fsf@columbia.edu> <6dbd4d000803080631s5d16e43cr7f7b2623c932b175@mail.gmail.com> Message-ID: On Sat, 8 Mar 2008, Donn Cave wrote: > On Mar 8, 2008, at 12:33 PM, Henning Thielemann wrote: > > > On Sat, 8 Mar 2008, Denis Bueno wrote: > ... > >> I am also using STUArray from some time-critical code; however, I > >> don't deal with ArrayException, or any exceptions for that matter. > >> What besides an out-of-bounds read or write might throw an > >> ArrayException? If it is out-of-bounds reading or writing, surely > >> that indicates a bug in your program that you'd rather fix than catch > >> the exception, no? > > > > Another instance of mixing up exceptions and errors in the Haskell > > libraries. > > http://www.haskell.org/haskellwiki/Error > > http://www.haskell.org/haskellwiki/Exception > > This seems to me one of the disappointments of Haskell - not just a > detail that was handled in an awkward way, but a fundamental flaw. > I'm not talking about ArrayException, whatever that is, but the notion > that errors encountered in functional code mustn't be handled as > exceptions. Errors are programming errors and must be fixed as Denis explained. Thus there is no need for a complex system of handling these situations at run-time. The program error might be unexpected but it isn't the fault of the user or of the context the program runs in but of the fault of the programmer. The program may report "bug detected, send an e-mail to the author" but eventually it should quit (at least the buggy thread) before worse things happen. This is possible in Haskell but should not be mixed up with handling of exceptions like "non-existing file". > I rejoice that Haskell isn't as miserable as C, but with respect to > exceptions and errors, it's behind for example Python. Languages that > can, use exceptions like IndexError. How precisely would you handle IndexError if it would be an exception and not just an error? From dons at galois.com Sun Mar 9 17:33:26 2008 From: dons at galois.com (Don Stewart) Date: Sun Mar 9 17:30:44 2008 Subject: [Haskell-cafe] Haskell Weekly News: March 09, 2008 Message-ID: <20080309213326.GC27150@scytale.galois.com> --------------------------------------------------------------------------- Haskell Weekly News http://sequence.complete.org/hwn/20080309 Issue 71 - March 09, 2008 --------------------------------------------------------------------------- Welcome to issue 71 of HWN, a newsletter covering developments in the [1]Haskell community. Another busy week on the Haskell library front, with around 100 new and updated libraries and tools on Hackage. 1. http://haskell.org/ Announcements Google Summer of Code. Malcolm Wallace [2]announced Google is running its 'Summer of Code' project again this year, and Haskell.org is once again going to apply to be a mentoring organisation. If you're interested in earning money to hack on Haskell, and helping out the community, [3]take a look at the wiki. 2. http://article.gmane.org/gmane.comp.lang.haskell.cafe/37273 3. http://hackage.haskell.org/trac/summer-of-code Haskell in the browser. Dimitry Golubovsky [4]announced that the YHC JavaScript backend is now in alpha testing, and is open to experimentation for those wanting to write Haskell directly for the browser 4. http://article.gmane.org/gmane.comp.lang.haskell.cafe/37299 Hackage New and updated libraries in [5]the Hackage library database. 5. http://hackage.haskell.org/ * typalyze 0.1.1. Uploaded by Matthew Danish. [6]typalyze: Analyzes Haskell source files for easy reference. * lax 0.0.0.1. Uploaded by Wolfgang Jeltsch. [7]lax: Lax arrows. * truelevel 0.1.1. Uploaded by Barton Massey. [8]truelevel: Audio file compressor-limiter. * WAVE 0.1. Uploaded by Barton Massey. [9]WAVE: WAVE audio file IO library. * parseargs 0.1. Uploaded by Barton Massey. [10]parseargs: Command-line argument parsing library for Haskell programs. * conjure 0.1. Uploaded by Gwern Branwen. [11]conjure: A BitTorrent client. * Diff 0.1.1. Uploaded by Sterling Clover. [12]Diff: O(ND) diff algorithm in haskell.. * simseq 0.0. Uploaded by Gwern Branwen. [13]simseq: Simulate sequencing with different models for priming and errors. * rbr 0.8.3. Uploaded by Gwern Branwen. [14]rbr: Mask nucleotide (EST) sequences in Fasta format. * xml2x 0.2. Uploaded by Gwern Branwen. [15]xml2x: Convert BLAST output in XML format to CSV or HTML. 6. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/typalyze-0.1.1 7. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/lax-0.0.0.1 8. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/truelevel-0.1.1 9. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/WAVE-0.1 10. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/parseargs-0.1 11. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/conjure-0.1 12. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Diff-0.1.1 13. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/simseq-0.0 14. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/rbr-0.8.3 15. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/xml2x-0.2 * estreps 0.1. Uploaded by Gwern Branwen. [16]estreps: Repeats from ESTs. * clustertools 0.1. Uploaded by Gwern Branwen. [17]clustertools: Tools for manipulating sequence clusters. * xsact 1.6. Uploaded by Gwern Branwen. [18]xsact: Cluster EST sequences. * HsJudy 0.2. Uploaded by Gwern Branwen. [19]HsJudy: Judy bindings, and some nice APIs. * prof2dot 0.3.1. Uploaded by Gregory Wright. [20]prof2dot: Convert GHC profiles into GraphViz's dot format. * strict 0.3.2. Uploaded by Roman Leshchinskiy. [21]strict: Strict data types and String IO.. * Emping 0.4. Uploaded by Hans VanThiel. [22]Emping: derives heuristic rules from nominal data. * GuiHaskell 0.1.1. Uploaded by Neil Mitchell. [23]GuiHaskell: A graphical REPL and development environment for Haskell. * simpleargs 0.1. Uploaded by Ketil Malde. [24]simpleargs: Provides a more flexible getArgs function with better error reporting.. * parsec 3.0.0. Uploaded by Derek Elkins. [25]parsec: Monadic parser combinators. 16. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/estreps-0.1 17. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/clustertools-0.1 18. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/xsact-1.6 19. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HsJudy-0.2 20. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/prof2dot-0.3.1 21. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/strict-0.3.2 22. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Emping-0.4 23. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/GuiHaskell-0.1.1 24. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/simpleargs-0.1 25. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/parsec-3.0.0 * hetris 0.2. Uploaded by Gwern Branwen. [26]hetris: Text Tetris. * hscurses 1.3. Uploaded by Gwern Branwen. [27]hscurses: NCurses bindings for Haskell. * photoname 2.0. Uploaded by Dino Morelli. [28]photoname: Rename JPEG photo files based on shoot date. * mage 1.1.0. Uploaded by Gwern Branwen. [29]mage: Rogue-like. * infix 0.1.1. Uploaded by Gwern Branwen. [30]infix: Infix expression re-parsing (for HsParser library). * bio 0.3.3. Uploaded by Gwern Branwen. [31]bio: A bioinformatics library. * dephd 0.0. Uploaded by Gwern Branwen. [32]dephd: Analyze 'phred' output (.phd files). * hybrid 2.0. Uploaded by Gwern Branwen. [33]hybrid: A implementation of a type-checker for Lambda-H. * propgrid 0.1. Uploaded by Gwern Branwen. [34]propgrid: GUI propertygrid. * gravatar 0.3. Uploaded by Donald Stewart. [35]gravatar: Find the url of the gravatar associated with an email address.. 26. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hetris-0.2 27. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hscurses-1.3 28. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/photoname-2.0 29. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/mage-1.1.0 30. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/infix-0.1.1 31. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/bio-0.3.3 32. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/dephd-0.0 33. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hybrid-2.0 34. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/propgrid-0.1 35. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/gravatar-0.3 * himerge 0.17.9. Uploaded by Luis Araujo. [36]himerge: Haskell Graphical User Interface for Emerge. * Takusen 0.8. Uploaded by Alistair Bayley. [37]Takusen: Database library with left-fold interface, for PostgreSQL, Oracle, SQLite, ODBC.. * irc 0.4.1. Uploaded by Trevor Elliott. [38]irc: A small library for parsing IRC messages.. * hexpat 0.2. Uploaded by Evan Martin. [39]hexpat: wrapper for expat, the fast XML parser. * microbench 0.1. Uploaded by Evan Martin. [40]microbench: Microbenchmark Haskell code. * hxt 7.5. Uploaded by Uwe Schmidt. [41]hxt: A collection of tools for processing XML with Haskell.. * hmatrix 0.2.1.0. Uploaded by Alberto Ruiz. [42]hmatrix: Linear algebra and numerical computations. * binary-strict 0.3.1. Uploaded by Adam Langley. [43]binary-strict: Binary deserialisation using strict ByteStrings. * category-extras 0.1. Uploaded by Dan Doel. [44]category-extras: Various modules and constructs inspired by category theory.. * pcap 0.4.3. Uploaded by Bryan OSullivan. [45]pcap: A system-independent interface for user-level packet capture. 36. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/himerge-0.17.9 37. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Takusen-0.8 38. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/irc-0.4.1 39. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hexpat-0.2 40. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/microbench-0.1 41. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hxt-7.5 42. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hmatrix-0.2.1.0 43. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/binary-strict-0.3.1 44. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/category-extras-0.1 45. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/pcap-0.4.3 * curl 1.3.1. Uploaded by Eric Mertens. [46]curl: Haskell binding to libcurl. * fastcgi 3001.0.2. Uploaded by Bjorn Bringert. [47]fastcgi: A Haskell library for writing FastCGI programs. * hslogger 1.0.5. Uploaded by John Goerzen. [48]hslogger: Versatile logging framework. * HAppS-Server 0.9.2.1. Uploaded by David Himmelstrup. [49]HAppS-Server: Web related tools and services.. * HAppS-IxSet 0.9.2.1. Uploaded by David Himmelstrup. [50]HAppS-IxSet: Added by DavidHimmelstrup, Fri Feb 29 07:27:13 PST 2008.. * HAppS-State 0.9.2.1. Uploaded by David Himmelstrup. [51]HAppS-State: Event-based distributed state.. * HAppS-Data 0.9.2.1. Uploaded by David Himmelstrup. [52]HAppS-Data: HAppS data manipulation libraries. * HAppS-Util 0.9.2.1. Uploaded by David Himmelstrup. [53]HAppS-Util: Web framework. * sessions 2008.2.28. Uploaded by Matthew Sackman. [54]sessions: Session Types for Haskell. * utf8-string 0.3. Uploaded by Eric Mertens. [55]utf8-string: Support for reading and writing UTF8 Strings. 46. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/curl-1.3.1 47. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/fastcgi-3001.0.2 48. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hslogger-1.0.5 49. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HAppS-Server-0.9.2.1 50. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HAppS-IxSet-0.9.2.1 51. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HAppS-State-0.9.2.1 52. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HAppS-Data-0.9.2.1 53. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HAppS-Util-0.9.2.1 54. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/sessions-2008.2.28 55. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/utf8-string-0.3 * EdisonCore 1.2.1.2. Uploaded by Robert Dockins. [56]EdisonCore: A library of efficent, purely-functional data structures (Core Implementations). * parameterized-data 0.1. Uploaded by Alfonso Acosta. [57]parameterized-data: Parameterized data library implementing lightweight dependent types. * unix 2.3.0.0. Uploaded by Ross Paterson. [58]unix: POSIX functionality. * hoogle 3.1. Uploaded by Neil Mitchell. [59]hoogle: Haskell API Search. * ftshell 0.2. Uploaded by Janis Voigtlaender. [60]ftshell: Shell interface to the FreeTheorems library.. * free-theorems 0.2. Uploaded by Janis Voigtlaender. [61]free-theorems: Automatic generation of free theorems.. * special-functors 1.0. Uploaded by Henning Thielemann. [62]special-functors: Control.Applicative, Data.Foldable, Data.Traversable (compatibility package). * type-level 0.1. Uploaded by Alfonso Acosta. [63]type-level: Type-level programming library. * nymphaea 0.2. Uploaded by Gwern Branwen. [64]nymphaea: An interactive GUI for manipulating L-systems. * hsc3 0.2. Uploaded by Rohan Drape. [65]hsc3: Haskell SuperCollider. 56. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/EdisonCore-1.2.1.2 57. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/parameterized-data-0.1 58. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/unix-2.3.0.0 59. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hoogle-3.1 60. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/ftshell-0.2 61. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/free-theorems-0.2 62. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/special-functors-1.0 63. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/type-level-0.1 64. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/nymphaea-0.2 65. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hsc3-0.2 * hosc 0.2. Uploaded by Rohan Drape. [66]hosc: Haskell Open Sound Control. * hslackbuilder 0.0.1. Uploaded by Andrea Rossato. [67]hslackbuilder: HSlackBuilder automatically generates slackBuild scripts from a cabal package. * hsparklines 0.1.0. Uploaded by Hitesh Jasani. [68]hsparklines: Sparklines for Haskell. * sat-micro-hs 0.1.1. Uploaded by Denis Bueno. [69]sat-micro-hs: A minimal SAT solver. * interlude 0.1.1. Uploaded by Gwern Branwen. [70]interlude: Replaces some Prelude functions for enhanced error reporting. * parse-dimacs 1.0.1. Uploaded by Denis Bueno. [71]parse-dimacs: DIMACS CNF parser library. * bitset 0.5. Uploaded by Denis Bueno. [72]bitset: A functional data structure for efficient membership testing.. * special-functors 1.0. Uploaded by Henning Thielemann. [73]special-functors: Control.Applicative, Data.Foldable, Data.Traversable (compatibility package). * condorcet 0.0.1. Uploaded by Gwern Branwen. [74]condorcet: Library for Condorcet voting. * heap 0.2.3. Uploaded by Stephan Friedrichs. [75]heap: Heaps in Haskell. 66. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hosc-0.2 67. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hslackbuilder-0.0.1 68. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hsparklines-0.1.0 69. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/sat-micro-hs-0.1.1 70. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/interlude-0.1.1 71. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/parse-dimacs-1.0.1 72. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/bitset-0.5 73. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/special-functors-1.0 74. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/condorcet-0.0.1 75. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/heap-0.2.3 * hspr-sh 0.3. Uploaded by Gwern Branwen. [76]hspr-sh: Session handler for HSP. * hsp 0.2. Uploaded by Gwern Branwen. [77]hsp: Haskell Server Pages is a library for writing dynamic server-side web pages.. * trhsx 0.2.1. Uploaded by Gwern Branwen. [78]trhsx: trhsx is the preprocessor for Harp and HSP. * haskell-src-exts 0.2.1. Uploaded by Gwern Branwen. [79]haskell-src-exts: Manipulating Haskell source: abstract syntax, lexer, parser, and pretty-printer. * harp 0.2.1. Uploaded by Gwern Branwen. [80]harp: HaRP allows pattern-matching with regular expressions. * HTF 0.1. Uploaded by Gwern Branwen. [81]HTF: The Haskell Test Framework. * hsdip 0.1. Uploaded by Gwern Branwen. [82]hsdip: hsdip - a Diplomacy parser/renderer. * mpdmate 0.1. Uploaded by Gwern Branwen. [83]mpdmate: MPD/PowerMate executable. * powermate 0.1. Uploaded by Gwern Branwen. [84]powermate: PowerMate bindings. * syb-with-class 0.4. Uploaded by David Himmelstrup. [85]syb-with-class: Scrap Your Boilerplate With Class. 76. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hspr-sh-0.3 77. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hsp-0.2 78. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/trhsx-0.2.1 79. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/haskell-src-exts-0.2.1 80. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/harp-0.2.1 81. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HTF-0.1 82. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hsdip-0.1 83. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/mpdmate-0.1 84. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/powermate-0.1 85. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/syb-with-class-0.4 * whim 0.1. Uploaded by Gwern Branwen. [86]whim: A Haskell window manager. * memcached 0.1. Uploaded by Gwern Branwen. [87]memcached: haskell bindings for memcached. * HaLeX 1.1. Uploaded by Gwern Branwen. [88]HaLeX: HaLeX enables modelling, manipulation and animation of regular languages. 86. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/whim-0.1 87. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/memcached-0.1 88. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HaLeX-1.1 Jobs Haskell for real-time control software. Tom Hawkins [89]announced an opening for a Haskell job in real-time control software for vehicle and machinery applications 89. http://article.gmane.org/gmane.comp.lang.haskell.cafe/37093 Haskell for bioinformatics. Ketil Malde [90]announced an open position for a 3-year Ph.D. scolarship at IMR working on bioinformatics projects in Haskell 90. http://news.gmane.org/gmane.comp.lang.haskell.cafe/cutoff=37362 Blog noise [91]Haskell news from the [92]blogosphere. * [93]Barracuda P2P Chat * [94]A Lambda Calculus Reducer * [95]A Fashion Magazine in Haskell * [96]Introduction to building stateful web apps in HAppS * [97]Intro to HAppS-State * [98]Project Euler in Haskell * [99]In praise of mandatory indentation for novice programmers * [100]More Monads on the Cheap: Inlined fromMaybe * [101]A First Haskell Experience * [102]Haskell and code coverage * [103]Why I don't use Haskell for Functional Programming (monads, lifting) 91. http://planet.haskell.org/ 92. http://haskell.org/haskellwiki/Blog_articles 93. http://haskell.org/gtk2hs/archives/2008/02/24/barracuda-p2p-chat/ 94. http://www.defmacro.org/ramblings/lambda-reducer.html 95. http://www.alpheccar.org/en/posts/show/91 96. http://softwaresimply.blogspot.com/2008/02/intro-to-happs-part-1.html 97. http://softwaresimply.blogspot.com/2008/02/intro-to-happs-state.html 98. http://extempore.livejournal.com/212602.html 99. http://okasaki.blogspot.com/2008/02/in-praise-of-mandatory-indentation-for.html 100. http://osteele.com/archives/2008/02/inlined-frommaybe 101. http://the-programmers-stone.com/2008/03/04/a-first-haskell-experience/ 102. http://dukedave.blogspot.com/2008/03/back-in-action.html 103. http://jlouisramblings.blogspot.com/2008/03/why-i-dont-use-haskell-for-functional_08.html Quotes of the Week * teamonkey: the Haskell solutions that people are posting are generally so much more concise and elegant than for any other language * Dan Zwell: I am fairly new to Haskell, and I didn't realize how easy concurrent code is until I wrote this * anonymous: The Haskall (sic) language is often uses by very intelligent programmers, it often allows to use lazy computations and iterations, but it has the advantage that its iterators behave better (than in Python), and during the generation of some items you can, when you want, refer and use the items already generated. * Corun: I don't understand, what's the advantage of hugs? The uni here says to use hugs, though, but I kept finding myself going in to ghci to get a useful error message * They say that if it compiles, it will run correctly. It?s nearly true! I?m amazed. ... Such buglessness will remove a huge source of indeterminism in production environments where the work of many teams is co-ordinated by schedules. * dolio: I've made a domain specific notation for describing puddings. * cschneid: [Haskell] changed the way I look at decomposition of problems in the more corporate languages (Java and C#). I use far fewer variables, and more side-effect free methods. It's made my code clearer, and easier to test. * nicodemus: I've written some Erlang and much more Haskell. My take so far is that Erlang is good for teaching you how to fish, Haskell is good for teaching you about procuring food (including fish). * paulzork: Haskell is to functional programming like C is to imperative languages? Sort of the latin root? About the Haskell Weekly News New editions are posted to [104]the Haskell mailing list as well as to [105]the Haskell Sequence and [106]Planet Haskell. [107]RSS is also available, and headlines appear on [108]haskell.org. Headlines are available as [109]PDF. To help create new editions of this newsletter, please see the [110]contributing information. Send stories to dons at galois.com. The darcs repository is available at darcs get [111]http://code.haskell.org/~dons/code/hwn/ 104. http://www.haskell.org/mailman/listinfo/haskell 105. http://sequence.complete.org/ 106. http://planet.haskell.org/ 107. http://sequence.complete.org/node/feed 108. http://haskell.org/ 109. http://code.haskell.org/~dons/code/hwn/archives/20080309.pdf 110. http://haskell.org/haskellwiki/HWN 111. http://code.haskell.org/~dons/code/hwn/ From agl at imperialviolet.org Sun Mar 9 19:37:47 2008 From: agl at imperialviolet.org (Adam Langley) Date: Sun Mar 9 19:35:00 2008 Subject: [Haskell-cafe] STM example code In-Reply-To: <5ae4f2ba0803082139mff44e30haf09ad07713852ba@mail.gmail.com> References: <5ae4f2ba0803082139mff44e30haf09ad07713852ba@mail.gmail.com> Message-ID: <396556a20803091637r2467d912qc7ecd16fd0b67186@mail.gmail.com> 2008/3/8 Galchin Vasili : > I am playing around with the STM API. I would like to see examples of > STM other than the Santa.hs as I am having problems with STM vs IO. The STM papers were the best documentation for me: http://research.microsoft.com/~simonpj/papers/stm/index.htm -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org From gtener at gmail.com Sun Mar 9 21:48:42 2008 From: gtener at gmail.com (=?ISO-8859-2?Q?Krzysztof_Skrz=EAtnicki?=) Date: Sun Mar 9 21:45:55 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> Message-ID: <220e47b40803091848u5925dbe9l261a7ca076f9069e@mail.gmail.com> Ok, I did some search and found Data.Map, which can be used to implement pretty fast sorting: import qualified Data.Map as Map treeSort :: Ord a => [a] -> [a] treeSort = map (\(x,_) -> x ) . Map.toAscList . Map.fromList . map (\x->(x,())) In fact It is likely to behave like sort, with the exception that it is 23% faster. I did not hovever check the memory consumption. It works well on random, sorted and reverse-sorted inputs, and the speed difference is always about the same. I belive I could take Data.Map and get datatype isomorphic to specialized *Data.Map a ()* of it, so that treeSort will became Map.toAscList . Map.fromList. This may also bring some speedup. What do you think about this particular function? On Tue, Mar 4, 2008 at 1:45 AM, Krzysztof Skrz?tnicki wrote: > Hi > > I was playing with various versions of sorting algorithms. I know it's > very easy to create flawed benchmark and I don't claim those are good ones. > However, it really seems strange to me, that sort - library function - is > actually the worse measured function. I can hardly belive it, and I'd rather > say I have made a mistake preparing it. > > The overall winner seems to be qsort_iv - which is nothing less but old > sort replaced by mergesort now. > > Any clues? > > Regards > Christopher Skrz?tnicki > > --- cut here --- > [Tener@laptener haskell]$ ghc -O2 --make qsort.hs && ./qsort +RTS -sstderr > -RTS > /dev/null > [1 of 1] Compiling Main ( qsort.hs, qsort.o ) > Linking qsort ... > ./qsort +RTS -sstderr > (1.0,"iv") > (1.1896770400256864,"v") > (1.3091609772011856,"treeSort") > (1.592515715933153,"vii") > (1.5953543402198838,"vi") > (1.5961286512637272,"iii") > (1.8175480563244177,"i") > (1.8771604568641642,"ii") > (2.453160634439497,"mergeSort") > (2.6627090768870216,"sort") > 26,094,674,624 bytes allocated in the heap > 12,716,656,224 bytes copied during GC (scavenged) > 2,021,104,592 bytes copied during GC (not scavenged) > 107,225,088 bytes maximum residency (140 sample(s)) > > 49773 collections in generation 0 ( 21.76s) > 140 collections in generation 1 ( 23.61s) > > 305 Mb total memory in use > > INIT time 0.00s ( 0.00s elapsed) > MUT time 20.39s ( 20.74s elapsed) > GC time 45.37s ( 46.22s elapsed) > EXIT time 0.00s ( 0.00s elapsed) > Total time 65.76s ( 66.96s elapsed) > > %GC time 69.0% (69.0% elapsed) > > Alloc rate 1,279,723,644 bytes per MUT second > > Productivity 31.0% of total user, 30.5% of total elapsed > > > --- cut here --- > > {-# OPTIONS_GHC -O2 #-} > module Main where > > import System.CPUTime > import System.IO > import System.Environment > import System.Random > import Data.List( partition, sort ) > > data Tree a = > Node (Tree a) a (Tree a) > | Leaf > > > qsort_i [] = [] > qsort_i (x:xs) = qsort_i (filter (< x) xs) ++ [x] ++ qsort_i (filter (>= > x) xs) > > qsort_ii [] = [] > qsort_ii (x:xs) = let (ls,gt) = partition (< x) xs in qsort_ii ls ++ [x] > ++ qsort_ii gt > > qsort_iii xs = qsort_iii' [] xs > qsort_iii' acc [] = acc > qsort_iii' acc (x:xs) = > let (ls,gt) = partition (< x) xs in > let acc' = (x:(qsort_iii' acc gt)) in qsort_iii' acc' ls > > qsort_v [] = [] > qsort_v (x:xs) = let (xlt, xgt ) = foldl (\ (lt,gt) el -> case compare x > el of > GT -> (el:lt, > gt) > _ -> (lt, > el:gt) ) ([],[]) xs > in qsort_v xlt ++ [x] ++ qsort_v xgt > > -- zmodyfikowany i > qsort_vi [] = [] > qsort_vi (x:xs) = qsort_vi (filter (\y-> compare x y == GT) xs) ++ [x] ++ > qsort_vi (filter (\y-> compare x y /= GT) xs) > > > -- zmodyfikowany iii > qsort_vii xs = qsort_vii' [] xs > qsort_vii' acc [] = acc > qsort_vii' acc (x:xs) = > let (ls,gt) = partition (\y-> compare x y == GT) xs in > let acc' = (x:(qsort_vii' acc gt)) in qsort_vii' acc' ls > > > > -- qsort is stable and does not concatenate. > qsort_iv xs = qsort_iv' (compare) xs [] > > qsort_iv' _ [] r = r > qsort_iv' _ [x] r = x:r > qsort_iv' cmp (x:xs) r = qpart cmp x xs [] [] r > > -- qpart partitions and sorts the sublists > qpart cmp x [] rlt rge r = > -- rlt and rge are in reverse order and must be sorted with an > -- anti-stable sorting > rqsort_iv' cmp rlt (x:rqsort_iv' cmp rge r) > qpart cmp x (y:ys) rlt rge r = > case cmp x y of > GT -> qpart cmp x ys (y:rlt) rge r > _ -> qpart cmp x ys rlt (y:rge) r > > -- rqsort is as qsort but anti-stable, i.e. reverses equal elements > rqsort_iv' _ [] r = r > rqsort_iv' _ [x] r = x:r > rqsort_iv' cmp (x:xs) r = rqpart cmp x xs [] [] r > > rqpart cmp x [] rle rgt r = > qsort_iv' cmp rle (x:qsort_iv' cmp rgt r) > rqpart cmp x (y:ys) rle rgt r = > case cmp y x of > GT -> rqpart cmp x ys rle (y:rgt) r > _ -> rqpart cmp x ys (y:rle) rgt r > > > -- code by Orcus > > -- Zadanie 9 - merge sort > mergeSort :: Ord a => [a] -> [a] > mergeSort [] = [] > mergeSort [x] = [x] > mergeSort xs = let(l, r) = splitAt (length xs `quot` 2) xs > in mergeSortP (mergeSort l) (mergeSort r) > > -- funkcja pomocnicza scalaj??ca dwie listy uporz??dkowane w jedn?? > mergeSortP :: Ord a => [a] -> [a] -> [a] > mergeSortP xs [] = xs > mergeSortP [] ys = ys > mergeSortP (x:xs) (y:ys) > | x <= y = x:(mergeSortP xs (y:ys)) > | otherwise = y:(mergeSortP (x:xs) ys) > > -- Zadanie 10 - tree sort > treeSort :: Ord a => [a] -> [a] > -- pointless po raz drugi > treeSort = (treeSortInorder . treeSortToTree) > > treeSortToTree :: Ord a => [a] -> Tree a > treeSortToTree [] = Leaf > treeSortToTree (x:xs) = let (xlt, xgt) = foldl (\ (lt,gt) el -> case > compare x el of > GT -> (el:lt, > gt) > _ -> (lt, > el:gt) ) ([],[]) xs > in Node (treeSortToTree xlt) x (treeSortToTree > xgt) > > treeSortInorder :: Ord a => Tree a -> [a] > treeSortInorder Leaf = [] > treeSortInorder (Node l x r) = (treeSortInorder l) ++ [x] ++ > (treeSortInorder r) > > -- end code by Orcus > > > > -- > big_number = 1000000 :: Int > > > main = do > gen <- getStdGen > let xs' = randomRs (1::Int, big_number) gen > xs <- return (take big_number xs') > t1 <- getCPUTime > print (qsort_i xs) -- i > t2 <- getCPUTime > print (qsort_ii xs) -- ii > t3 <- getCPUTime > print (qsort_iii xs) -- iii > t4 <- getCPUTime > print (qsort_iv xs) -- iv > t5 <- getCPUTime > print (qsort_v xs) -- v > t6 <- getCPUTime > print (qsort_vi xs) -- vi > t7 <- getCPUTime > print (qsort_vii xs) -- vii > t8 <- getCPUTime > print (sort xs) -- sort > t9 <- getCPUTime > print (mergeSort xs) -- mergeSort > t10 <- getCPUTime > print (treeSort xs) -- treeSort > t11 <- getCPUTime > let getTimes xs = zipWith (-) (tail xs) xs > let timers = [t1,t2,t3,t4,t5,t6,t7,t8,t9,t10,t11] > let times = getTimes timers > let table = zip times ["i","ii","iii","iv", "v", "vi", "vii", > "sort","mergeSort","treeSort"] > let sorted = sort table > let scaled = map (\(x,n) -> (((fromIntegral x / (fromIntegral $ fst > (head sorted)))::Double),n)) sorted > let toShow = concatMap (\x-> show x ++ "\n") scaled > hPutStr stderr toShow > > main_small = do > gen <- getStdGen > let xs' = randomRs (1::Int, 100000) gen > xs <- return (take big_number xs') > t1 <- getCPUTime > print (qsort_iv xs) -- iv > t2 <- getCPUTime > print (sort xs) -- sort > t3 <- getCPUTime > print (mergeSort xs) -- mergeSort > t4 <- getCPUTime > print (treeSort xs) -- treeSort > t5 <- getCPUTime > let getTimes xs = zipWith (-) (tail xs) xs > let timers = [t1,t2,t3,t4,t5] > let times = getTimes timers > let table = zip times ["iv", "sort","mergeSort","treeSort"] > let sorted = sort table > let scaled = map (\(x,n) -> (((fromIntegral x / (fromIntegral $ fst > (head sorted)))::Double),n)) sorted > let toShow = concatMap (\x-> show x ++ "\n") scaled > hPutStr stderr toShow > hPrint stderr times > > --- cut here --- > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080310/a0c0f994/attachment-0001.htm From dan.doel at gmail.com Sun Mar 9 23:04:01 2008 From: dan.doel at gmail.com (Dan Doel) Date: Sun Mar 9 23:01:16 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: <220e47b40803091848u5925dbe9l261a7ca076f9069e@mail.gmail.com> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <220e47b40803091848u5925dbe9l261a7ca076f9069e@mail.gmail.com> Message-ID: <200803092304.02063.dan.doel@gmail.com> On Sunday 09 March 2008, Krzysztof Skrz?tnicki wrote: > Ok, I did some search and found Data.Map, which can be used to implement > pretty fast sorting: > > import qualified Data.Map as Map > > treeSort :: Ord a => [a] -> [a] > treeSort = map (\(x,_) -> x ) . Map.toAscList . Map.fromList . map > (\x->(x,())) > > In fact It is likely to behave like sort, with the exception that it is 23% > faster. I did not hovever check the memory consumption. It works well on > random, sorted and reverse-sorted inputs, and the speed difference is > always about the same. I belive I could take Data.Map and get datatype > isomorphic to specialized *Data.Map a ()* of it, so that treeSort will > became Map.toAscList . Map.fromList. This may also bring some speedup. > > What do you think about this particular function? Some thoughts: 1) To get your function specifically, you could just use Data.Set.Set a instead of Map a (). 2) What does it do with duplicate elements in the list? I expect it deletes them. To avoid this, you'd need to use something like fromListWith, keeping track of how many duplicates there are, and expanding at the end. 3) I imagine the time taken to get any output is always O(n*log n). Various lazy sorts can be written (and I'd guess the standard library sort is written this way, although I don't know for sure) such that 'head (sort l)' is O(n), or O(n + k*log n) for getting the first k elements. However, Map, being a balanced binary tree, doesn't (I think) have the right characteristics for this. At the very least, you'll probably want to test with a function that doesn't delete duplicate elements. Something like this: treeSort = concatMap (\(x,n) -> replicate n x) . Map.toAscList . Map.fromListWith (+) . map (\x -> (x,1)) -- Dan From dons at galois.com Sun Mar 9 23:08:32 2008 From: dons at galois.com (Don Stewart) Date: Sun Mar 9 23:05:46 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: <200803092304.02063.dan.doel@gmail.com> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <220e47b40803091848u5925dbe9l261a7ca076f9069e@mail.gmail.com> <200803092304.02063.dan.doel@gmail.com> Message-ID: <20080310030832.GG27150@scytale.galois.com> dan.doel: > On Sunday 09 March 2008, Krzysztof Skrz?tnicki wrote: > > Ok, I did some search and found Data.Map, which can be used to implement > > pretty fast sorting: > > > > import qualified Data.Map as Map > > > > treeSort :: Ord a => [a] -> [a] > > treeSort = map (\(x,_) -> x ) . Map.toAscList . Map.fromList . map > > (\x->(x,())) > > > > In fact It is likely to behave like sort, with the exception that it is 23% > > faster. I did not hovever check the memory consumption. It works well on > > random, sorted and reverse-sorted inputs, and the speed difference is > > always about the same. I belive I could take Data.Map and get datatype > > isomorphic to specialized *Data.Map a ()* of it, so that treeSort will > > became Map.toAscList . Map.fromList. This may also bring some speedup. > > > > What do you think about this particular function? > > Some thoughts: > > 1) To get your function specifically, you could just use Data.Set.Set a > instead of Map a (). > > 2) What does it do with duplicate elements in the list? I expect it deletes > them. To avoid this, you'd need to use something like fromListWith, keeping > track of how many duplicates there are, and expanding at the end. And a little QuickCheck to help things along: import qualified Data.Map as Map import Data.List import Test.QuickCheck treeSort :: Ord a => [a] -> [a] treeSort = map (\(x,_) -> x ) . Map.toAscList . Map.fromList . map (\x->(x,())) main = quickCheck prop_sort prop_sort xs = sort xs == treeSort xs where _ = xs :: [Int] Running: $ runhaskell A.hs Falsifiable, after 11 tests: [-2,-2,5] From chak at cse.unsw.edu.au Sun Mar 9 23:14:53 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Sun Mar 9 23:12:07 2008 Subject: [Haskell-cafe] Issues(Bugs?) with GHC Type Families In-Reply-To: <7b92c2840803061737g7fd31713tc8ba20be86de9edf@mail.gmail.com> References: <7b92c2840803030935t6ed5d2a6ne63d5f8b3d5fe917@mail.gmail.com> <7b92c2840803051727l6a31fd78j63c756ee9a1973ca@mail.gmail.com> <13737842-6754-4401-8F78-9A215F7BC0FB@cse.unsw.edu.au> <7b92c2840803061737g7fd31713tc8ba20be86de9edf@mail.gmail.com> Message-ID: Hugo Pacheco: > >If the equality does not hold, you should get a type error because > >your program is not type correct. So, what is it that you would like > >different? > > I would simply like the compiler not to use that instance if the > equality constraint does not hold, like some another instance > dependency constraint, but I assume that is not possible. This is independent of type families. The selection of type class instances does *never* dependent on the instance context, only on the instance head. I know that this is sometimes annoying, but type checking would be a a lot more complicated/expensive without that rule. Manuel From duncan.coutts at worc.ox.ac.uk Mon Mar 10 00:05:34 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Mar 10 00:02:52 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: <200803092304.02063.dan.doel@gmail.com> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <220e47b40803091848u5925dbe9l261a7ca076f9069e@mail.gmail.com> <200803092304.02063.dan.doel@gmail.com> Message-ID: <1205121934.11558.769.camel@localhost> On Sun, 2008-03-09 at 23:04 -0400, Dan Doel wrote: > On Sunday 09 March 2008, Krzysztof Skrz?tnicki wrote: > > What do you think about this particular function? > > Some thoughts: > > 1) To get your function specifically, you could just use Data.Set.Set a > instead of Map a (). > > 2) What does it do with duplicate elements in the list? I expect it deletes > them. To avoid this, you'd need to use something like fromListWith, keeping > track of how many duplicates there are, and expanding at the end. > > 3) I imagine the time taken to get any output is always O(n*log n). Various > lazy sorts can be written (and I'd guess the standard library sort is written > this way, although I don't know for sure) such that 'head (sort l)' is O(n), > or O(n + k*log n) for getting the first k elements. However, Map, being a > balanced binary tree, doesn't (I think) have the right characteristics for > this. Sounds to me like we should try a heap sort. As a data structure it should have similar constant factors to Data.Map (or .Set) but a heap is less ordered than a search tree and gives the O(n + k*log n) property. Duncan From donn at avvanta.com Mon Mar 10 03:37:14 2008 From: donn at avvanta.com (Donn Cave) Date: Mon Mar 10 03:34:29 2008 Subject: [Haskell-cafe] Exception handling when using STUArray In-Reply-To: References: <87wsod6ax8.fsf@columbia.edu> <6dbd4d000803080631s5d16e43cr7f7b2623c932b175@mail.gmail.com> Message-ID: On Mar 9, 2008, at 1:07 PM, Henning Thielemann wrote: > > Errors are programming errors and must be fixed as Denis explained. > Thus > there is no need for a complex system of handling these situations at > run-time. The program error might be unexpected but it isn't the > fault of > the user or of the context the program runs in but of the fault of the > programmer. The program may report "bug detected, send an e-mail to > the > author" but eventually it should quit (at least the buggy thread) > before > worse things happen. This is possible in Haskell but should not be > mixed > up with handling of exceptions like "non-existing file". I am not sure I see the difference in principle that you see. An exception is, for me, any state that isn't properly accounted for in its immediate context. openFile could return 'Maybe Handle', but it doesn't, so the context demands a Handle or an exception. 'head' demands data with at least one element, or an exception. Now, we do have the means to validate the latter assumption, and not the former - I can check that a file exists, but can't usually guarantee that it will exist at the instant I try to open it. Is that where you find the distinction? > > How precisely would you handle IndexError if it would be an > exception and > not just an error? > Well, to take a hypothetical example ... I have never looked into JPEG image decoding, but suppose that it's moderately complicated and further that it involves array indexing at some point, and I have written a web browser that needs to decode and display images. Maybe one in ten thousand JPEG images will be invalid for some reason, in a way that leads to an index beyond the bounds of its sequence. Because we have the data at hand, we can certainly validate indices vs. bounds and avoid an index error. Then we need an Either or Maybe or some such thing to express that, and some way to propagate the issue up to the top of the image renderer. Whereupon it will refuse to render the image and will put its broken image icon in its place. Or, I can just write the JPEG decoding algorithm, and catch index errors at that same place, and refuse to render the image etc.. To me, this doesn't pose any moral problem, and the code is bound to be clearer and more expressive of its core intention, than if it were burdened with layer upon layer of Rights and Justs to defend against a problem that has no real solution and may never even occur. If the image I'm supposed to decode isn't actually there when I try to open the file, then I'll display the very same icon in its place. We want the same thing to happen, whatever the problem with the image: display the broken image icon, and go on to render the rest of the page. Now if we want to be philosophical about it, all of these problems don't have to be with the image - maybe it's a variant JPEG type that I didn't know about, or even just my coding error that happened to escape testing. The web browser should carry on regardless, however, so the implementation shouldn't be sensitive to these philosophical distinctions. Donn Cave, donn@avvanta.com From ndmitchell at gmail.com Mon Mar 10 04:27:42 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon Mar 10 04:24:53 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: <200803092304.02063.dan.doel@gmail.com> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <220e47b40803091848u5925dbe9l261a7ca076f9069e@mail.gmail.com> <200803092304.02063.dan.doel@gmail.com> Message-ID: <404396ef0803100127p4e99997amf2e2a6d70dce6e8b@mail.gmail.com> Hi > 2) What does it do with duplicate elements in the list? I expect it deletes > them. To avoid this, you'd need to use something like fromListWith, keeping > track of how many duplicates there are, and expanding at the end. That would be wrong. Consider: data Foo = Foo Int Int instance Ord Foo where compare (Foo a _) (Foo b _) = compare a b sort [Foo 1 2, Foo 1 -2] must return the original list back, in that order. You cannot delete things and duplicate them later. To guarantee the ordering you must also do other stuff. Thanks Neil From lrpalmer at gmail.com Mon Mar 10 04:35:21 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Mon Mar 10 04:32:32 2008 Subject: [Haskell-cafe] Exception handling when using STUArray In-Reply-To: References: <87wsod6ax8.fsf@columbia.edu> <6dbd4d000803080631s5d16e43cr7f7b2623c932b175@mail.gmail.com> Message-ID: <7ca3f0160803100135rda69104l251ced2eb97f0a71@mail.gmail.com> On Mon, Mar 10, 2008 at 7:37 AM, Donn Cave wrote: > > On Mar 9, 2008, at 1:07 PM, Henning Thielemann wrote: > > > > > Errors are programming errors and must be fixed as Denis explained. > > Thus > > there is no need for a complex system of handling these situations at > > run-time. The program error might be unexpected but it isn't the > > fault of > > the user or of the context the program runs in but of the fault of the > > programmer. The program may report "bug detected, send an e-mail to > > the > > author" but eventually it should quit (at least the buggy thread) > > before > > worse things happen. This is possible in Haskell but should not be > > mixed > > up with handling of exceptions like "non-existing file". > > I am not sure I see the difference in principle that you see. > > An exception is, for me, any state that isn't properly accounted for > in its > immediate context. openFile could return 'Maybe Handle', but it > doesn't, > so the context demands a Handle or an exception. 'head' demands data > with at least one element, or an exception. Now, we do have the means > to validate the latter assumption, and not the former - I can check > that a > file exists, but can't usually guarantee that it will exist at the > instant I try > to open it. Is that where you find the distinction? Playing devil's advocate, I can see a difference in that openFile depends on the environment. But that's not a good reason. Another difference is that when you're in the IO monad (or alternatively any MonadError), failing (throwing an exception) versus returning a more descriptive value is a difference in calling convention, whereas the difference in pure code is greater since you need to be in IO to catch it. That's not a good reason either. My brainstorming cap goes on. I cannot come up with a good reason why openFile throws an exception when perfectly reasonable things happen, such as the file not existing. Maybe we need to step back a little and remember what exceptions were invented for. Exceptions are not necessary, explicit error handling works, and you'll find some C programmers with no problem with it. Exceptions are an abstraction over code that handles exceptional conditions. It designates a code path as special, the "normal" path, and assumes that in all other cases you want to abort the rest of the normal path up to some sequencing point. In my personal functional software design philosophy, I think that all functions (in a given interface, not talking about helpers) should be total. You shouldn't be able to pass a value to one of my functions and get an error unless you wrote the error message yourself (sorry, can't guard against fourierTransform (error "haha u were wrong")). Thus in my philosophy, head and tail are bad style, and I almost never use them. Exceptions are not the same as errors, exceptions are just a convenient notation for dealing with code paths that follow a common pattern. Errors just shouldn't happen, and I shouldn't use any non-total functions (unless I can prove that I'm using them correctly, which is quite a lot of work, it's easier just not to). MonadError is how we deal with that common pattern (it's a good way to do it), and there's Control.Exception.catch if we're dealing with code that is not so well-behaved. Unfortunately there is a lot of library code which is not so well behaved. > > > > How precisely would you handle IndexError if it would be an > > exception and > > not just an error? > > > > Well, to take a hypothetical example ... I have never looked into JPEG > image decoding, but suppose that it's moderately complicated and further > that it involves array indexing at some point, and I have written a web > browser that needs to decode and display images. Maybe one in ten > thousand JPEG images will be invalid for some reason, in a way that > leads to an index beyond the bounds of its sequence. > > Because we have the data at hand, we can certainly validate indices > vs. bounds and avoid an index error. Then we need an Either or Maybe > or some such thing to express that, and some way to propagate the > issue up to the top of the image renderer. Whereupon it will refuse > to render the image and will put its broken image icon in its place. > > Or, I can just write the JPEG decoding algorithm, and catch index errors > at that same place, and refuse to render the image etc.. To me, this > doesn't > pose any moral problem, and the code is bound to be clearer and more > expressive of its core intention, than if it were burdened with layer > upon > layer of Rights and Justs to defend against a problem that has no real > solution and may never even occur. > > If the image I'm supposed to decode isn't actually there when I try to > open the file, then I'll display the very same icon in its place. We > want > the same thing to happen, whatever the problem with the image: display > the broken image icon, and go on to render the rest of the page. Now > if we want to be philosophical about it, all of these problems don't > have to be with the image - maybe it's a variant JPEG type that I didn't > know about, or even just my coding error that happened to escape > testing. The web browser should carry on regardless, however, so > the implementation shouldn't be sensitive to these philosophical > distinctions. So here you don't trust your algorithm. And in that case Control.Exception.catch seems perfectly reasonable. If you don't like non-determinism, then you could put your computation in MonadError. But you'd have to wrap arrays to fail using, say, the monad pattern rather than erroring. That's kind of annoying, and sadly I think there's nothing to do but take it up with the library author. I'm just spouting nonsense... Luke From ndmitchell at gmail.com Mon Mar 10 04:36:52 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon Mar 10 04:34:04 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: <404396ef0803100127p4e99997amf2e2a6d70dce6e8b@mail.gmail.com> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <220e47b40803091848u5925dbe9l261a7ca076f9069e@mail.gmail.com> <200803092304.02063.dan.doel@gmail.com> <404396ef0803100127p4e99997amf2e2a6d70dce6e8b@mail.gmail.com> Message-ID: <404396ef0803100136s4f8d4bd0ub376095a747a2195@mail.gmail.com> Hi Can whoever picks this up please try the sort code from Yhc in their comparisons. In my benchmarks it ran up to twice as fast as the GHC code. http://darcs.haskell.org/yhc/src/packages/yhc-base-1.0/Data/List.hs I think what we really need is first quickCheck and timing framework for measuring sorts. After we have decided what makes one sort faster/better than another, then is the time to start deciding what sort is the best one. Ian did some initial work on this: http://www.haskell.org/pipermail/glasgow-haskell-users/2002-May/003376.html Until the sort-check package is uploaded to hackage I think most people will find it hard to be convinced of one sort over another. Thanks Neil On Mon, Mar 10, 2008 at 8:27 AM, Neil Mitchell wrote: > Hi > > > > 2) What does it do with duplicate elements in the list? I expect it deletes > > them. To avoid this, you'd need to use something like fromListWith, keeping > > track of how many duplicates there are, and expanding at the end. > > That would be wrong. Consider: > > data Foo = Foo Int Int > > instance Ord Foo where > compare (Foo a _) (Foo b _) = compare a b > > sort [Foo 1 2, Foo 1 -2] must return the original list back, in that > order. You cannot delete things and duplicate them later. To guarantee > the ordering you must also do other stuff. > > Thanks > > Neil > From malcolm.wallace at cs.york.ac.uk Mon Mar 10 05:57:00 2008 From: malcolm.wallace at cs.york.ac.uk (Malcolm Wallace) Date: Mon Mar 10 05:54:18 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: <404396ef0803100136s4f8d4bd0ub376095a747a2195@mail.gmail.com> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <220e47b40803091848u5925dbe9l261a7ca076f9069e@mail.gmail.com> <200803092304.02063.dan.doel@gmail.com> <404396ef0803100127p4e99997amf2e2a6d70dce6e8b@mail.gmail.com> <404396ef0803100136s4f8d4bd0ub376095a747a2195@mail.gmail.com> Message-ID: On 10 Mar 2008, at 08:36, Neil Mitchell wrote: > Can whoever picks this up please try the sort code from Yhc in their > comparisons. In my benchmarks it ran up to twice as fast as the GHC > code. http://darcs.haskell.org/yhc/src/packages/yhc-base-1.0/Data/List.hs I believe the Yhc sort implementation is faster because Lennart did some extensive performance tuning of sorting with hbc, about ten years ago, and contributed the resulting winner to nhc98 way back then. Regards, Malcolm From lemming at henning-thielemann.de Mon Mar 10 07:00:06 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon Mar 10 06:56:08 2008 Subject: [Haskell-cafe] Exception handling when using STUArray In-Reply-To: References: <87wsod6ax8.fsf@columbia.edu> <6dbd4d000803080631s5d16e43cr7f7b2623c932b175@mail.gmail.com> Message-ID: On Mon, 10 Mar 2008, Donn Cave wrote: > On Mar 9, 2008, at 1:07 PM, Henning Thielemann wrote: > >> How precisely would you handle IndexError if it would be an exception and >> not just an error? > > Well, to take a hypothetical example ... I have never looked into JPEG > image decoding, but suppose that it's moderately complicated and further > that it involves array indexing at some point, and I have written a web > browser that needs to decode and display images. Maybe one in ten > thousand JPEG images will be invalid for some reason, in a way that > leads to an index beyond the bounds of its sequence. Ok let's examine this example. The decoding algorithm you describe is a non-IO function: JFIF.decode :: ByteString -> Image You expect that there are inputs that must be considered corrupt. You cannot return an image for corrupt input, thus the signature must be JFIF.decode :: ByteString -> Maybe Image Now there are two possibilities: Either your implementation works properly, then it should return Nothing for a corrupt JFIF input, or it works improperly and accesses non-existing array elements and fails with an error. If you encounter that, you must fix that error, it would not help to catch the error at run-time. > Or, I can just write the JPEG decoding algorithm, and catch index errors > at that same place, and refuse to render the image etc.. To me, this doesn't > pose any moral problem, and the code is bound to be clearer and more > expressive of its core intention, than if it were burdened with layer upon > layer of Rights and Justs to defend against a problem that has no real > solution and may never even occur. Internally you must check the array bounds, this might indeed mean to cope with Lefts and Rights. However you can process this with monad combinators and syntax and then looks like exception handling in IO code. If you want it to be handled the same way as 'file not found' you can lift the 'Left' to an IO exception. In my opinion, IO functions should also expose their exceptions by types, e.g. openFile :: FilePath -> IOMode -> IO (Either IOError Handle) openFile :: FilePath -> IOMode -> ErrorT IOError IO Handle > If the image I'm supposed to decode isn't actually there when I try to > open the file, then I'll display the very same icon in its place. We want > the same thing to happen, whatever the problem with the image: display > the broken image icon, and go on to render the rest of the page. Now > if we want to be philosophical about it, all of these problems don't > have to be with the image - maybe it's a variant JPEG type that I didn't > know about, or even just my coding error that happened to escape > testing. The web browser should carry on regardless, however, so > the implementation shouldn't be sensitive to these philosophical > distinctions. Indeed all the situations "file not found", "unsupported format version", "corrupt file content" are exceptions, you must handle them properly with Maybe, Either, ErrorT, or IO exceptions, but you should not invoke 'error'. 'error' is reserved for the case when you forget to check array bounds and thus a corrupt file would corrupt your program if the libraries default check wouldn't intervene. Actually, the array library calls 'error' for indexes out of bound, precisely because they violate the calling conditions for, say (!). From ahey at iee.org Mon Mar 10 07:00:18 2008 From: ahey at iee.org (Adrian Hey) Date: Mon Mar 10 06:57:34 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: <404396ef0803100127p4e99997amf2e2a6d70dce6e8b@mail.gmail.com> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <220e47b40803091848u5925dbe9l261a7ca076f9069e@mail.gmail.com> <200803092304.02063.dan.doel@gmail.com> <404396ef0803100127p4e99997amf2e2a6d70dce6e8b@mail.gmail.com> Message-ID: <47D514C2.8050102@iee.org> Neil Mitchell wrote: >> 2) What does it do with duplicate elements in the list? I expect it deletes >> them. To avoid this, you'd need to use something like fromListWith, keeping >> track of how many duplicates there are, and expanding at the end. > > That would be wrong. Consider: > > data Foo = Foo Int Int > > instance Ord Foo where > compare (Foo a _) (Foo b _) = compare a b I would consider such an Ord instance to be hopelessly broken, and I don't think it's the responsibility of authors of functions with Ord constraints in their sigs (such as sort) to consider such possibilities or specify and control the behaviour of their behaviour for such instances. Trying to do this is what leads to horrors such as the "left biasing" of Data.Map (for example). Unfortunately the Haskell standards don't currently specify sane laws for Eq and Ord class instances, but they should. Otherwise knowing a type is an instance of Ord tells me nothing that I can rely on. Regards -- Adrian Hey From ahey at iee.org Mon Mar 10 07:07:26 2008 From: ahey at iee.org (Adrian Hey) Date: Mon Mar 10 07:04:44 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: <47D514C2.8050102@iee.org> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <220e47b40803091848u5925dbe9l261a7ca076f9069e@mail.gmail.com> <200803092304.02063.dan.doel@gmail.com> <404396ef0803100127p4e99997amf2e2a6d70dce6e8b@mail.gmail.com> <47D514C2.8050102@iee.org> Message-ID: <47D5166E.20609@iee.org> Adrian Hey wrote: > or specify and control the behaviour of their behaviour for such > instances. Urk, sorry for the gibberish. I guess I should get into the habit of reading what I write before posting :-) Regards -- Adrian Hey From lrpalmer at gmail.com Mon Mar 10 07:21:06 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Mon Mar 10 07:18:17 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: <47D514C2.8050102@iee.org> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <220e47b40803091848u5925dbe9l261a7ca076f9069e@mail.gmail.com> <200803092304.02063.dan.doel@gmail.com> <404396ef0803100127p4e99997amf2e2a6d70dce6e8b@mail.gmail.com> <47D514C2.8050102@iee.org> Message-ID: <7ca3f0160803100421t640902b2vc0b437d8368d750f@mail.gmail.com> On Mon, Mar 10, 2008 at 11:00 AM, Adrian Hey wrote: > Neil Mitchell wrote: > >> 2) What does it do with duplicate elements in the list? I expect it deletes > >> them. To avoid this, you'd need to use something like fromListWith, keeping > >> track of how many duplicates there are, and expanding at the end. > > > > That would be wrong. Consider: > > > > data Foo = Foo Int Int > > > > instance Ord Foo where > > compare (Foo a _) (Foo b _) = compare a b > > I would consider such an Ord instance to be hopelessly broken, and I > don't think it's the responsibility of authors of functions with Ord > constraints in their sigs (such as sort) to consider such possibilities > or specify and control the behaviour of their behaviour for such > instances. Trying to do this is what leads to horrors such as the "left > biasing" of Data.Map (for example). It could be. I actually don't know what Haskell specifies here. If a type has an Eq instance and x == y, must x and y be observationally equivalent? Or is it reasonable to allow some wiggle room? I'd say (==) definitely has to be an equivalence relation, but beyond that, it's open to the implementor, since if an algorithm only depends on (Eq a), it can't tell the difference between observational equality and any other equivalence relation. But that's just one argument ("by example", in a way). That is, an argument that this is hopelessly broken isn't trivial, it needs to be defended. There is nonetheless a need to handle duplicates gracefully, that is keeping a count won't cut it, because of sortBy. Luke From ndmitchell at gmail.com Mon Mar 10 07:28:36 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon Mar 10 07:25:46 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: <47D514C2.8050102@iee.org> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <220e47b40803091848u5925dbe9l261a7ca076f9069e@mail.gmail.com> <200803092304.02063.dan.doel@gmail.com> <404396ef0803100127p4e99997amf2e2a6d70dce6e8b@mail.gmail.com> <47D514C2.8050102@iee.org> Message-ID: <404396ef0803100428v68b4c533w23942c5ddafd7910@mail.gmail.com> Hi > > instance Ord Foo where > > compare (Foo a _) (Foo b _) = compare a b > > I would consider such an Ord instance to be hopelessly broken, and I > don't think it's the responsibility of authors of functions with Ord > constraints in their sigs (such as sort) to consider such possibilities > or specify and control the behaviour of their behaviour for such > instances. Trying to do this is what leads to horrors such as the "left > biasing" of Data.Map (for example). The sort in Haskell is specified to be "stable". What that means is that the above ord relation is fine. The above ordering observes all the necessary mathematical definitions of ordering, assuming an Eq of: instance Eq Foo where (==) (Foo a _) (Foo b _) = (==) a b > Unfortunately the Haskell standards don't currently specify sane laws > for Eq and Ord class instances, but they should. Otherwise knowing a > type is an instance of Ord tells me nothing that I can rely on. Please give the sane law that this ordering violates. I can't see any! What if I had made the definition of Foo: data Foo = Foo Int (Int -> Int) Now, is the only possible answer that any Ord instance for Foo is wrong? Thanks Neil From ahey at iee.org Mon Mar 10 08:33:11 2008 From: ahey at iee.org (Adrian Hey) Date: Mon Mar 10 08:30:28 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: <404396ef0803100428v68b4c533w23942c5ddafd7910@mail.gmail.com> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <220e47b40803091848u5925dbe9l261a7ca076f9069e@mail.gmail.com> <200803092304.02063.dan.doel@gmail.com> <404396ef0803100127p4e99997amf2e2a6d70dce6e8b@mail.gmail.com> <47D514C2.8050102@iee.org> <404396ef0803100428v68b4c533w23942c5ddafd7910@mail.gmail.com> Message-ID: <47D52A87.9060805@iee.org> Neil Mitchell wrote: > Hi > >> > instance Ord Foo where >> > compare (Foo a _) (Foo b _) = compare a b >> >> I would consider such an Ord instance to be hopelessly broken, and I >> don't think it's the responsibility of authors of functions with Ord >> constraints in their sigs (such as sort) to consider such possibilities >> or specify and control the behaviour of their behaviour for such >> instances. Trying to do this is what leads to horrors such as the "left >> biasing" of Data.Map (for example). > > The sort in Haskell is specified to be "stable". What that means is > that the above ord relation is fine. The above ordering observes all > the necessary mathematical definitions of ordering, assuming an Eq of: > > instance Eq Foo where > (==) (Foo a _) (Foo b _) = (==) a b > >> Unfortunately the Haskell standards don't currently specify sane laws >> for Eq and Ord class instances, but they should. Otherwise knowing a >> type is an instance of Ord tells me nothing that I can rely on. > > Please give the sane law that this ordering violates. I can't see any! The Eq instance you've given violates the law that (x == y) = True implies x = y. Of course the Haskell standard doesn't specify this law, but it should. The Haskell standard doen't even specify that compare x y = EQ implies (x == y) = True, but again it should (what's the purpose of the Eq constraint on Ord class otherwise). > What if I had made the definition of Foo: > > data Foo = Foo Int (Int -> Int) > > Now, is the only possible answer that any Ord instance for Foo is wrong? Yes, if the Foo constuctor is exported. If it's scope confined to one module then you could maintain the invariant that the same function is always associated with a given Int. However, if this is the case then the issue you raise wrt sort behaviour is irrelevant. Regards -- Adrian Hey From dan.doel at gmail.com Mon Mar 10 08:45:31 2008 From: dan.doel at gmail.com (Dan Doel) Date: Mon Mar 10 08:42:46 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: <404396ef0803100127p4e99997amf2e2a6d70dce6e8b@mail.gmail.com> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <200803092304.02063.dan.doel@gmail.com> <404396ef0803100127p4e99997amf2e2a6d70dce6e8b@mail.gmail.com> Message-ID: <200803100845.31683.dan.doel@gmail.com> On Monday 10 March 2008, Neil Mitchell wrote: > That would be wrong. Consider: > > data Foo = Foo Int Int > > instance Ord Foo where > compare (Foo a _) (Foo b _) = compare a b > > sort [Foo 1 2, Foo 1 -2] must return the original list back, in that > order. You cannot delete things and duplicate them later. To guarantee > the ordering you must also do other stuff. Ah! Quite right. So, instead, we'd have to store the elements themselves. Something like: treeSort = concatMap (reverse . snd) . Map.toAscList . Map.fromListWith (++) . map (\x -> (x,[x])) I had a feeling the duplicate counting one wasn't the correct answer, but your example slipped my mind last night. -- Dan From bulat.ziganshin at gmail.com Mon Mar 10 08:17:24 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Mon Mar 10 08:58:37 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: <47D514C2.8050102@iee.org> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <220e47b40803091848u5925dbe9l261a7ca076f9069e@mail.gmail.com> <200803092304.02063.dan.doel@gmail.com> <404396ef0803100127p4e99997amf2e2a6d70dce6e8b@mail.gmail.com> <47D514C2.8050102@iee.org> Message-ID: <1733569707.20080310151724@gmail.com> Hello Adrian, Monday, March 10, 2008, 2:00:18 PM, you wrote: >> instance Ord Foo where >> compare (Foo a _) (Foo b _) = compare a b > I would consider such an Ord instance to be hopelessly broken, and I hmmmm. for example, imagine files in file manager sorted by size or date -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From ahey at iee.org Mon Mar 10 09:15:54 2008 From: ahey at iee.org (Adrian Hey) Date: Mon Mar 10 09:13:11 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: <7ca3f0160803100421t640902b2vc0b437d8368d750f@mail.gmail.com> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <220e47b40803091848u5925dbe9l261a7ca076f9069e@mail.gmail.com> <200803092304.02063.dan.doel@gmail.com> <404396ef0803100127p4e99997amf2e2a6d70dce6e8b@mail.gmail.com> <47D514C2.8050102@iee.org> <7ca3f0160803100421t640902b2vc0b437d8368d750f@mail.gmail.com> Message-ID: <47D5348A.8090700@iee.org> Luke Palmer wrote: > It could be. I actually don't know what Haskell specifies here. If a > type has an Eq instance and x == y, must x and y be observationally > equivalent? I would say yes, without exception, at least as far as the public (exported) interface is concerned. > Or is it reasonable to allow some wiggle room? Well for abstract data types observational equivalence doesn't necessarily imply structural identity. An obvious example is the AVL tree lib, where trees with different shapes (and hence different heights possibly) are treated as being equal if they contain the same elements in the same order. But the solution here is not to export functions that can discriminate between "equal" trees (such as height). > I'd say > (==) definitely has to be an equivalence relation, but beyond that, > it's open to the implementor, since if an algorithm only depends on > (Eq a), it can't tell the difference between observational equality > and any other equivalence relation. I'm not sure what you're saying. Consider the max method, the Ord class definition doesn't specify which of two "equal" values should be returned. So, it must be generally assumed that it doesn't matter. You could treat the default method implementation as the specification, but the problem with this is as general rule that it still leaves us no specification for methods with no defaults. > There is nonetheless a need to handle duplicates gracefully, that is > keeping a count won't cut it, because of sortBy. For the overloaded sort, I would say keep a count of duplicates is a perfectly reasonable and correct solution (and more space efficient too). For sortBy things need specifying more precisely as it can accept any old function which happens to have the right type. Regards -- Adrian Hey From ndmitchell at gmail.com Mon Mar 10 09:32:41 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon Mar 10 09:29:52 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: <47D52A87.9060805@iee.org> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <220e47b40803091848u5925dbe9l261a7ca076f9069e@mail.gmail.com> <200803092304.02063.dan.doel@gmail.com> <404396ef0803100127p4e99997amf2e2a6d70dce6e8b@mail.gmail.com> <47D514C2.8050102@iee.org> <404396ef0803100428v68b4c533w23942c5ddafd7910@mail.gmail.com> <47D52A87.9060805@iee.org> Message-ID: <404396ef0803100632w6ae183f3w467aa02bae40caa2@mail.gmail.com> Hi > The Eq instance you've given violates the law that (x == y) = True > implies x = y. Of course the Haskell standard doesn't specify this law, > but it should. Wrong. It shouldn't, it doesn't, and I don't think it even can! > The Haskell standard doen't even specify that compare x y = EQ implies > (x == y) = True, but again it should (what's the purpose of the Eq > constraint on Ord class otherwise). Correct. Yes, this is one law that _should_ be true, along with others: a > b && b > c => a > c a == b => b == a etc. But a == b => a = b is not a law that needs to hold, and not a law that can be stated in Haskell, even as a quickcheck property. Thanks Neil From zs.szalai at gmail.com Mon Mar 10 09:41:37 2008 From: zs.szalai at gmail.com (Zsolt SZALAI) Date: Mon Mar 10 09:38:49 2008 Subject: [Haskell-cafe] concurrent definitions with parsec Message-ID: Hi! I'm writing a parser for a language, with a BNF like this: Type = "type" Def Def = RecordDef | RecordOfDef ... RecordDef = "record" Body RecordOfDef = "record" "of" With a perser what uses parsec module it can be mapped to haskell easily: structuredTypeDef = recordDef <|> recordOfDef But this way, the recordOfDef case will never be parsed at a line like "type record ", because recordDef will win in the first place always. Is there an option or an other operation instead of <|> to do the trick? I cant see if the problem can be solved with parsecperm or not. It is a possibility to do something like swap "recordDef <|> recordOfDef" with "recordlikeDefs " where recordlikeDefs = do { reserved "record" ; others } but that would be the dirty way... Do you have any advise on the case? Thanks, -- Zsolt Szalai -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080310/fcc18e10/attachment.htm From allbery at ece.cmu.edu Mon Mar 10 09:45:19 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Mon Mar 10 09:42:31 2008 Subject: [Haskell-cafe] concurrent definitions with parsec In-Reply-To: References: Message-ID: <750C4FC2-6CEE-47DB-8BBA-AD76E99E2C30@ece.cmu.edu> On Mar 10, 2008, at 9:41 , Zsolt SZALAI wrote: > It is a possibility to do something like swap "recordDef <|> > recordOfDef" with "recordlikeDefs " > where recordlikeDefs = do { reserved "record" ; others } > but that would be the dirty way... Er? Refactoring the grammar like that is the clean and preferred way. But if you insist, use the try combinator. structuredTypeDef = try recordDef <|> recordOfDef -- 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 zs.szalai at gmail.com Mon Mar 10 09:55:19 2008 From: zs.szalai at gmail.com (Zsolt SZALAI) Date: Mon Mar 10 09:52:30 2008 Subject: [Haskell-cafe] concurrent definitions with parsec In-Reply-To: <750C4FC2-6CEE-47DB-8BBA-AD76E99E2C30@ece.cmu.edu> References: <750C4FC2-6CEE-47DB-8BBA-AD76E99E2C30@ece.cmu.edu> Message-ID: > > > Er? Refactoring the grammar like that is the clean and preferred > way. But if you insist, use the try combinator. > Oh, all right, i was trying to be loyal to the BNF in standard. > > structuredTypeDef = try recordDef <|> recordOfDef > > -- > 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 > > > -- Szalai Zsolt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080310/6040240e/attachment.htm From allbery at ece.cmu.edu Mon Mar 10 10:03:21 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Mon Mar 10 10:00:50 2008 Subject: [Haskell-cafe] concurrent definitions with parsec In-Reply-To: References: <750C4FC2-6CEE-47DB-8BBA-AD76E99E2C30@ece.cmu.edu> Message-ID: <88C2EB2E-5B8E-4E7E-A8D9-19A8151AC626@ece.cmu.edu> On Mar 10, 2008, at 9:55 , Zsolt SZALAI wrote: > > Er? Refactoring the grammar like that is the clean and preferred > way. But if you insist, use the try combinator. > > Oh, all right, i was trying to be loyal to the BNF in standard. BNF doesn't necessarily apply cleanly to all types of parsers. Compare LALR(1) parsers (yacc, happy) to LL(1) (ideal Parsec grammars). You can use the try combinator to write such grammars, but it imposes a potentially large amount of overhead because it may have to hold on to a large parse tree that might end up being thrown out. -- 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 ahey at iee.org Mon Mar 10 10:10:52 2008 From: ahey at iee.org (Adrian Hey) Date: Mon Mar 10 10:08:09 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: <404396ef0803100632w6ae183f3w467aa02bae40caa2@mail.gmail.com> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <220e47b40803091848u5925dbe9l261a7ca076f9069e@mail.gmail.com> <200803092304.02063.dan.doel@gmail.com> <404396ef0803100127p4e99997amf2e2a6d70dce6e8b@mail.gmail.com> <47D514C2.8050102@iee.org> <404396ef0803100428v68b4c533w23942c5ddafd7910@mail.gmail.com> <47D52A87.9060805@iee.org> <404396ef0803100632w6ae183f3w467aa02bae40caa2@mail.gmail.com> Message-ID: <47D5416C.808@iee.org> Neil Mitchell wrote: > Hi > >> The Eq instance you've given violates the law that (x == y) = True >> implies x = y. Of course the Haskell standard doesn't specify this law, >> but it should. > > Wrong. It shouldn't, Should too > it doesn't, indeed > and I don't think it even can! Well we need to be precise about exactly what "=" means, but informally I guess we're talking about observational equvalence. But seriously, once you admit the possibility that even if x == y it still matters which of x or y is used in expressions than all hell breaks loose. I shudder to think just how much Haskell code there must be out there that is (at best) ambiguious or just plain "broken" if this is a serious possibility. Again, I have to cite Data.Map as an obvious example. It's unclear to me exactly what the proper interpretation of "left biasing" is for all functions in the API. Furthermore, until quite recently some function implementations in Data.Map we're actually broken wrt the stated "biasing" policy (though few actually noticed this for obvious reasons). Perhaps some still are? Who knows.. Regards -- Adrian Hey From roma at ro-che.info Mon Mar 10 10:30:02 2008 From: roma at ro-che.info (Roman Cheplyaka) Date: Mon Mar 10 10:27:24 2008 Subject: [Haskell-cafe] [GSoC] A data parallel physics engine Message-ID: <20080310143002.GA30015@home.ro-che.info> I'm looking for interesting project to work on during Google Summer of Code. So I found [1]"A data parallel physics engine" ticket and got excited about it. I'd like to know interested mentors and community opinion about the complexity of such project. I have not very deep knowledge about both NDP and physics engines. Is it feasible to learn all the necessary stuff during these 2 month before SoC starts? 1. http://hackage.haskell.org/trac/summer-of-code/ticket/1535 -- Roman I. Cheplyaka :: http://ro-che.info/ ...being in love is totally punk rock... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080310/ac302a72/attachment.bin From ketil at malde.org Mon Mar 10 10:40:23 2008 From: ketil at malde.org (Ketil Malde) Date: Mon Mar 10 10:37:28 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: <47D5416C.808@iee.org> (Adrian Hey's message of "Mon\, 10 Mar 2008 14\:10\:52 +0000") References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <220e47b40803091848u5925dbe9l261a7ca076f9069e@mail.gmail.com> <200803092304.02063.dan.doel@gmail.com> <404396ef0803100127p4e99997amf2e2a6d70dce6e8b@mail.gmail.com> <47D514C2.8050102@iee.org> <404396ef0803100428v68b4c533w23942c5ddafd7910@mail.gmail.com> <47D52A87.9060805@iee.org> <404396ef0803100632w6ae183f3w467aa02bae40caa2@mail.gmail.com> <47D5416C.808@iee.org> Message-ID: <871w6i8wx4.fsf@nmd9999.imr.no> Adrian Hey writes: > But seriously, once you admit the possibility that even if x == y it > still matters which of x or y is used in expressions than all hell > breaks loose. I shudder to think just how much Haskell code there must > be out there that is (at best) ambiguious or just plain "broken" if > this is a serious possibility. Just search for "copy" (on ByteStrings). One program of mine was extracting substrings from a large file. Since the file was pretty huge, I used lazy bytestrings for this purpose. Unfortunately, the short substrings I retained pulled with them rather large chunks from the file -- since a bytestring is essentially a pointer to a chunk, an offset, and a length. The solution is "copy", which creates a new string, indistinguishable from within Haskell, but with very different effects on the program. -k -- If I haven't seen further, it is by standing in the footprints of giants From ahey at iee.org Mon Mar 10 10:53:16 2008 From: ahey at iee.org (Adrian Hey) Date: Mon Mar 10 10:50:31 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: <1733569707.20080310151724@gmail.com> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <220e47b40803091848u5925dbe9l261a7ca076f9069e@mail.gmail.com> <200803092304.02063.dan.doel@gmail.com> <404396ef0803100127p4e99997amf2e2a6d70dce6e8b@mail.gmail.com> <47D514C2.8050102@iee.org> <1733569707.20080310151724@gmail.com> Message-ID: <47D54B5C.7010602@iee.org> Bulat Ziganshin wrote: > Hello Adrian, > > Monday, March 10, 2008, 2:00:18 PM, you wrote: > >>> instance Ord Foo where >>> compare (Foo a _) (Foo b _) = compare a b > >> I would consider such an Ord instance to be hopelessly broken, and I > > hmmmm. for example, imagine files in file manager sorted by size or date In such cases you should be using sortBy, not the overloaded sort (you have several reasonable orderings for the same record type say). Regards -- Adrian Hey From dbueno at gmail.com Mon Mar 10 11:00:19 2008 From: dbueno at gmail.com (Denis Bueno) Date: Mon Mar 10 10:57:32 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: <47D5416C.808@iee.org> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <220e47b40803091848u5925dbe9l261a7ca076f9069e@mail.gmail.com> <200803092304.02063.dan.doel@gmail.com> <404396ef0803100127p4e99997amf2e2a6d70dce6e8b@mail.gmail.com> <47D514C2.8050102@iee.org> <404396ef0803100428v68b4c533w23942c5ddafd7910@mail.gmail.com> <47D52A87.9060805@iee.org> <404396ef0803100632w6ae183f3w467aa02bae40caa2@mail.gmail.com> <47D5416C.808@iee.org> Message-ID: <6dbd4d000803100800k3a6a0242p7093bdfac3b95c5d@mail.gmail.com> On Mon, Mar 10, 2008 at 10:10 AM, Adrian Hey wrote: > >> The Eq instance you've given violates the law that (x == y) = True > >> implies x = y. Of course the Haskell standard doesn't specify this law, > >> but it should. Unless I'm missing something obvious, the example Neil gave earlier should make it clear how impossible this requirement is: What if I had made the definition of Foo: data Foo = Foo Int (Int -> Int) There is no way in general to decide the observational equivalence of two values of this data type (by reduction to the halting problem). Therefore it is impossible to write any function implementing such an equality test. -- Denis From ahey at iee.org Mon Mar 10 11:23:51 2008 From: ahey at iee.org (Adrian Hey) Date: Mon Mar 10 11:21:06 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: <871w6i8wx4.fsf@nmd9999.imr.no> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <220e47b40803091848u5925dbe9l261a7ca076f9069e@mail.gmail.com> <200803092304.02063.dan.doel@gmail.com> <404396ef0803100127p4e99997amf2e2a6d70dce6e8b@mail.gmail.com> <47D514C2.8050102@iee.org> <404396ef0803100428v68b4c533w23942c5ddafd7910@mail.gmail.com> <47D52A87.9060805@iee.org> <404396ef0803100632w6ae183f3w467aa02bae40caa2@mail.gmail.com> <47D5416C.808@iee.org> <871w6i8wx4.fsf@nmd9999.imr.no> Message-ID: <47D55287.5040701@iee.org> Ketil Malde wrote: > Adrian Hey writes: > >> But seriously, once you admit the possibility that even if x == y it >> still matters which of x or y is used in expressions than all hell >> breaks loose. I shudder to think just how much Haskell code there must >> be out there that is (at best) ambiguious or just plain "broken" if >> this is a serious possibility. > > Just search for "copy" (on ByteStrings). > > One program of mine was extracting substrings from a large > file. Since the file was pretty huge, I used lazy bytestrings for this > purpose. Unfortunately, the short substrings I retained pulled with them > rather large chunks from the file -- since a bytestring is essentially > a pointer to a chunk, an offset, and a length. The solution is > "copy", which creates a new string, indistinguishable from within > Haskell, but with very different effects on the program. We're talking about *semantic correctness*, not efficiency. If you want to fine tune your code like this you shouldn't be relying on overloaded general purpose function implementations. E.G. the COrdering type used by AVL lib is one way to do this. This lets a combining comparison chose which of two "equal" values is used (and other things). Indeed, one of my main objections the having things like biasing policy as part of a functions specification in that it seriously inhibits you when producing more refined and efficient implementations. BTW, I noticed this when I was writing my Data.Map clone. Respecting the stated biasing policy resulted in less efficient implementations. It "broke my heart" to knowingly write code that would slow down 99% of users code just keep the 1% who'd defined broken Ord instances happy, so I defined biasing policy differently for the clone. On reflection I think even that was a mistake and is something I intend drop if I ever do a Hackage release (the lib should not specify any biasing policy whatsoever). Regards -- Adrian Hey From ndmitchell at gmail.com Mon Mar 10 11:29:40 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon Mar 10 11:26:50 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: <47D55287.5040701@iee.org> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <200803092304.02063.dan.doel@gmail.com> <404396ef0803100127p4e99997amf2e2a6d70dce6e8b@mail.gmail.com> <47D514C2.8050102@iee.org> <404396ef0803100428v68b4c533w23942c5ddafd7910@mail.gmail.com> <47D52A87.9060805@iee.org> <404396ef0803100632w6ae183f3w467aa02bae40caa2@mail.gmail.com> <47D5416C.808@iee.org> <871w6i8wx4.fsf@nmd9999.imr.no> <47D55287.5040701@iee.org> Message-ID: <404396ef0803100829h44c8ac1dg4ee6f0132cb4f929@mail.gmail.com> Hi > We're talking about *semantic correctness*, not efficiency. If you > want to fine tune your code like this you shouldn't be relying > on overloaded general purpose function implementations. E.G. the > COrdering type used by AVL lib is one way to do this. This lets > a combining comparison chose which of two "equal" values is used > (and other things). I would have thought: sort x == sortBy compare x was a reasonable property to have. But you are proposing that sort should make assumptions on the compare function, which you can't even state in Haskell, but sortBy should not. That seems suspicious... I also know of a data type: data Set xs = Set [xs] where the Set constructor is all nicely hidden. If I define Set "ab" to be equal to Set "ba", should the compiler burst into flames? If we _require_ all Eq definitions to follow our very narrowly defined notion of equality, then the question comes up why we permit people to write Eq at all - why doesn't the compiler just do it for us, if there is only one right answer. Thanks Neil From apfelmus at quantentunnel.de Mon Mar 10 12:10:51 2008 From: apfelmus at quantentunnel.de (apfelmus) Date: Mon Mar 10 12:08:19 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: <1205121934.11558.769.camel@localhost> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <220e47b40803091848u5925dbe9l261a7ca076f9069e@mail.gmail.com> <200803092304.02063.dan.doel@gmail.com> <1205121934.11558.769.camel@localhost> Message-ID: Duncan Coutts wrote: > Sounds to me like we should try a heap sort. As a data structure it > should have similar constant factors to Data.Map (or .Set) but a heap is > less ordered than a search tree and gives the O(n + k*log n) property. Thanks to lazyness, mergesort is really a heapsort in disguise. Regards, apfelmus From ahey at iee.org Mon Mar 10 12:19:07 2008 From: ahey at iee.org (Adrian Hey) Date: Mon Mar 10 12:41:04 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: <6dbd4d000803100800k3a6a0242p7093bdfac3b95c5d@mail.gmail.com> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <220e47b40803091848u5925dbe9l261a7ca076f9069e@mail.gmail.com> <200803092304.02063.dan.doel@gmail.com> <404396ef0803100127p4e99997amf2e2a6d70dce6e8b@mail.gmail.com> <47D514C2.8050102@iee.org> <404396ef0803100428v68b4c533w23942c5ddafd7910@mail.gmail.com> <47D52A87.9060805@iee.org> <404396ef0803100632w6ae183f3w467aa02bae40caa2@mail.gmail.com> <47D5416C.808@iee.org> <6dbd4d000803100800k3a6a0242p7093bdfac3b95c5d@mail.gmail.com> Message-ID: <47D55F7B.6010508@iee.org> Denis Bueno wrote: > On Mon, Mar 10, 2008 at 10:10 AM, Adrian Hey wrote: >> >> The Eq instance you've given violates the law that (x == y) = True >> >> implies x = y. Of course the Haskell standard doesn't specify this law, >> >> but it should. > > Unless I'm missing something obvious, the example Neil gave earlier > should make it clear how impossible this requirement is: > > What if I had made the definition of Foo: > > data Foo = Foo Int (Int -> Int) > > There is no way in general to decide the observational equivalence of > two values of this data type (by reduction to the halting problem). > Therefore it is impossible to write any function implementing such an > equality test. Did you read my original response to this example? http://www.haskell.org/pipermail/haskell-cafe/2008-March/040356.html Regards -- Adrian Hey From dbueno at gmail.com Mon Mar 10 12:54:30 2008 From: dbueno at gmail.com (Denis Bueno) Date: Mon Mar 10 12:51:41 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: <47D55F7B.6010508@iee.org> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <200803092304.02063.dan.doel@gmail.com> <404396ef0803100127p4e99997amf2e2a6d70dce6e8b@mail.gmail.com> <47D514C2.8050102@iee.org> <404396ef0803100428v68b4c533w23942c5ddafd7910@mail.gmail.com> <47D52A87.9060805@iee.org> <404396ef0803100632w6ae183f3w467aa02bae40caa2@mail.gmail.com> <47D5416C.808@iee.org> <6dbd4d000803100800k3a6a0242p7093bdfac3b95c5d@mail.gmail.com> <47D55F7B.6010508@iee.org> Message-ID: <6dbd4d000803100954g3fcea3ceod05b4036de5ef4a9@mail.gmail.com> On Mon, Mar 10, 2008 at 12:19 PM, Adrian Hey wrote: > Denis Bueno wrote: > > On Mon, Mar 10, 2008 at 10:10 AM, Adrian Hey wrote: > >> >> The Eq instance you've given violates the law that (x == y) = True > >> >> implies x = y. Of course the Haskell standard doesn't specify this law, > >> >> but it should. > > > > Unless I'm missing something obvious, the example Neil gave earlier > > should make it clear how impossible this requirement is: > > > > What if I had made the definition of Foo: > > > > data Foo = Foo Int (Int -> Int) > > > > There is no way in general to decide the observational equivalence of > > two values of this data type (by reduction to the halting problem). > > Therefore it is impossible to write any function implementing such an > > equality test. > > Did you read my original response to this example? > > http://www.haskell.org/pipermail/haskell-cafe/2008-March/040356.html Yes. You would argue that one should not export the data constructor Foo. That is a decision that requires more details about the code providing Foo, although it certainly seems a reasonable approach in many cases. Supposing I wanted to export Foo, though, the condition you'd like to put on == breaks down. Even if I don't export Foo, how do I ensure that any standard library functions called from the Foo library don't depend on the condition you'd like to put on ==? Do I have to examine them individually? Wouldn't it be easier to reason about code if we constrain the semantics of == as *little* as possible (as an equivalence relation)? -- Denis From kalman.noel at bluebottle.com Mon Mar 10 13:10:34 2008 From: kalman.noel at bluebottle.com (Kalman Noel) Date: Mon Mar 10 13:07:11 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: <404396ef0803100428v68b4c533w23942c5ddafd7910@mail.gmail.com> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <220e47b40803091848u5925dbe9l261a7ca076f9069e@mail.gmail.com> <200803092304.02063.dan.doel@gmail.com> <404396ef0803100127p4e99997amf2e2a6d70dce6e8b@mail.gmail.com> <47D514C2.8050102@iee.org> <404396ef0803100428v68b4c533w23942c5ddafd7910@mail.gmail.com> Message-ID: <200803101710.m2AH9xwj012966@mi1.bluebottle.com> Neil Mitchell wrote: > instance Eq Foo where > (==) (Foo a _) (Foo b _) = (==) a b [...] > Please give the sane law that this ordering violates. I can't see any! The (non-existant) law would be (Eq1) x == y => f x == f y, for all f of appropriate type which is analogous to this (existant) law about observational equality: (Eq2) x = y => f x = f y, for all f of appropriate type Kalman ---------------------------------------------------------------------- Finally - A spam blocker that actually works. http://www.bluebottle.com/tag/4 From bos at serpentine.com Mon Mar 10 13:29:41 2008 From: bos at serpentine.com (Bryan O'Sullivan) Date: Mon Mar 10 13:26:51 2008 Subject: [Haskell-cafe] [GSoC] A data parallel physics engine In-Reply-To: <20080310143002.GA30015@home.ro-che.info> References: <20080310143002.GA30015@home.ro-che.info> Message-ID: <47D57005.4090904@serpentine.com> Roman Cheplyaka wrote: > I have not very deep knowledge about both NDP and physics engines. I've done some physics simulation work for games. One could certainly learn enough to be able to write a straightforward implementation in that time. Broadphase collision detection is easy; narrowphase somewhat more difficult; integration and interpenetration resolution would consume the bulk of your time. I very strongly doubt that one might both write a physics engine and adapt it to compute anything interesting using NDP in the SoC time frame. That's more like a meaty topic for a Masters thesis. References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <200803092304.02063.dan.doel@gmail.com> <404396ef0803100127p4e99997amf2e2a6d70dce6e8b@mail.gmail.com> <47D514C2.8050102@iee.org> <404396ef0803100428v68b4c533w23942c5ddafd7910@mail.gmail.com> <47D52A87.9060805@iee.org> <404396ef0803100632w6ae183f3w467aa02bae40caa2@mail.gmail.com> <47D5416C.808@iee.org> <871w6i8wx4.fsf@nmd9999.imr.no> <47D55287.5040701@iee.org> <404396ef0803100829h44c8ac1dg4ee6f0132cb4f929@mail.gmail.com> Message-ID: <47D56B7A.2030200@iee.org> Neil Mitchell wrote: > Hi > >> We're talking about *semantic correctness*, not efficiency. If you >> want to fine tune your code like this you shouldn't be relying >> on overloaded general purpose function implementations. E.G. the >> COrdering type used by AVL lib is one way to do this. This lets >> a combining comparison chose which of two "equal" values is used >> (and other things). > > I would have thought: > > sort x == sortBy compare x > > was a reasonable property to have. Certainly, but this is part of (but not the complete) specification for sortBy, not sort. But given sane Ord/Eq instances and sortBy implementation, then this is indeed also one of many possible correct implementatations of sort. > But you are proposing that sort > should make assumptions on the compare function, Not just sort, but any function with an Ord constraint is entited to assume sane behavior wrt to compare. Without this the Ord class just becomes quite useless, other than saving a few keystrokes for folk who be bothered to pass any old compare function as explicit arg. Surely type classes are supposed to be more than that? > which you can't even state in Haskell, There are plenty of formal statements about things that can't be written in Haskell. That doesn't mean they aren't true or should not be respected or relied upon. It just means Haskell is an imperfect language for expressing such things. > but sortBy should not. sortBy should not "assume" anything about the function of type x -> x -> Ordering. Rather, what sortBy actually does with that function should be specified. > I also know of a data type: > > data Set xs = Set [xs] > > where the Set constructor is all nicely hidden. If I define Set "ab" > to be equal to Set "ba", should the compiler burst into flames? ?? If we > _require_ all Eq definitions to follow our very narrowly defined > notion of equality, then the question comes up why we permit people to > write Eq at all - why doesn't the compiler just do it for us, if there > is only one right answer. You provided one example yourself.. data Foo = Foo Int (Int -> Int) It's perfectly possible for Foo to be an abstract type exported from a module that preserves the invariant that the same function is always associated with a given Int (value). If this is the case there's no reason why Foo should not be an instance of Ord or Eq. If this isn't the case then Foo should certainly not be an instance or either class IMO. If this was intended to be the case but in fact isn't the case, then that's a bug. Regards -- Adrian Hey From westondan at imageworks.com Mon Mar 10 14:57:24 2008 From: westondan at imageworks.com (Dan Weston) Date: Mon Mar 10 14:56:35 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: <47D514C2.8050102@iee.org> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <220e47b40803091848u5925dbe9l261a7ca076f9069e@mail.gmail.com> <200803092304.02063.dan.doel@gmail.com> <404396ef0803100127p4e99997amf2e2a6d70dce6e8b@mail.gmail.com> <47D514C2.8050102@iee.org> Message-ID: <47D58494.7080003@imageworks.com> > Unfortunately the Haskell standards don't currently specify sane laws > for Eq and Ord class instances, but they should. In fact there are requirements in the Haskell98 report: 6.3 Standard Haskell Classes Note the word "reasonable" in the paragraph below: "Default class method declarations (Section 4.3) are provided for many of the methods in standard classes. A comment with each class declaration in Chapter 8 specifies the smallest collection of method definitions that, together with the default declarations, provide a reasonable definition for all the class methods." This (coupled with the premise that anything not required is optional) means that default definitions are not normative, so the following Ord default code comment need not hold: "-- Note that (min x y, max x y) = (x,y) or (y,x)" However, the report text is normative: 6.3.2 (The Ord Class): "The Ord class is used for totally ordered datatypes." This *requires* that it be absolutely impossible in valid code to distinguish equivalent (in the EQ sense, not the == sense) things via the functions of Ord. The intended interpretation of these functions is clear and can be taken as normative: forall f . (compare x y == EQ and (f x or f y is defined)) ==> f x == f y) There is an (seriously insane but required by the total ordering, and in any case) officially encouraged use of left-bias in sum types: "The declared order of the constructors in the data declaration determines the ordering in derived Ord instances." Perhaps in Haskell' the total ordering requirement can be loosened to a partial order (say in a class between Eq and Ord), with comparePartial :: a -> a -> PartialOrdering? Dan Adrian Hey wrote: > Neil Mitchell wrote: >>> 2) What does it do with duplicate elements in the list? I expect it >>> deletes >>> them. To avoid this, you'd need to use something like fromListWith, >>> keeping >>> track of how many duplicates there are, and expanding at the end. >> >> That would be wrong. Consider: >> >> data Foo = Foo Int Int >> >> instance Ord Foo where >> compare (Foo a _) (Foo b _) = compare a b > > I would consider such an Ord instance to be hopelessly broken, and I > don't think it's the responsibility of authors of functions with Ord > constraints in their sigs (such as sort) to consider such possibilities > or specify and control the behaviour of their behaviour for such > instances. Trying to do this is what leads to horrors such as the "left > biasing" of Data.Map (for example). > > Unfortunately the Haskell standards don't currently specify sane laws > for Eq and Ord class instances, but they should. Otherwise knowing a > type is an instance of Ord tells me nothing that I can rely on. > > Regards > -- > Adrian Hey > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From gtener at gmail.com Mon Mar 10 15:07:07 2008 From: gtener at gmail.com (=?ISO-8859-2?Q?Krzysztof_Skrz=EAtnicki?=) Date: Mon Mar 10 15:04:18 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: <47D56B7A.2030200@iee.org> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <47D514C2.8050102@iee.org> <404396ef0803100428v68b4c533w23942c5ddafd7910@mail.gmail.com> <47D52A87.9060805@iee.org> <404396ef0803100632w6ae183f3w467aa02bae40caa2@mail.gmail.com> <47D5416C.808@iee.org> <871w6i8wx4.fsf@nmd9999.imr.no> <47D55287.5040701@iee.org> <404396ef0803100829h44c8ac1dg4ee6f0132cb4f929@mail.gmail.com> <47D56B7A.2030200@iee.org> Message-ID: <220e47b40803101207w6d4bb795k68d959b3ccff9849@mail.gmail.com> Ok, my turn now. Let's think about algorithm that takes equivalence relation EQ, ordering relation ORD on abstraction classes generated by this equivalence ( -> equivalence classes ) and divides given input elements XS into appropriate classes and then prints them out according to given ordering ORD. If we pose the restriction (let's call it (*)), that input XS should have at most one element from every abstraction class, we get sorting in a way that you desire. Hovewer, if we don't pose that restriction the algorithm still makes perfect sense and is given by standard library sortBy. I see no reason for restriction (*). For efficiency reasons there could be additional class StrictEq. If the type is in that class then we can assume (*) and use more space-efficient algorithm. Now, the problem with treeSort = concatMap (reverse . snd) . Map.toAscList . Map.fromListWith (++) . map (\x -> (x,[x])) is that i can't tell any compact way of implementing treeSortBy in nice manner. This is because Data.Map does not allow us to provide our own comparison test instead of compare. On Mon, Mar 10, 2008 at 6:10 PM, Adrian Hey wrote: > Neil Mitchell wrote: > > Hi > > > >> We're talking about *semantic correctness*, not efficiency. If you > >> want to fine tune your code like this you shouldn't be relying > >> on overloaded general purpose function implementations. E.G. the > >> COrdering type used by AVL lib is one way to do this. This lets > >> a combining comparison chose which of two "equal" values is used > >> (and other things). > > > > I would have thought: > > > > sort x == sortBy compare x > > > > was a reasonable property to have. > > Certainly, but this is part of (but not the complete) specification > for sortBy, not sort. But given sane Ord/Eq instances and sortBy > implementation, then this is indeed also one of many possible > correct implementatations of sort. > > > But you are proposing that sort > > should make assumptions on the compare function, > > Not just sort, but any function with an Ord constraint is entited > to assume sane behavior wrt to compare. Without this the Ord class > just becomes quite useless, other than saving a few keystrokes for > folk who be bothered to pass any old compare function as explicit arg. > Surely type classes are supposed to be more than that? > > > which you can't even state in Haskell, > > There are plenty of formal statements about things that can't be > written in Haskell. That doesn't mean they aren't true or should not > be respected or relied upon. It just means Haskell is an imperfect > language for expressing such things. > > > but sortBy should not. > > sortBy should not "assume" anything about the function of type > x -> x -> Ordering. Rather, what sortBy actually does with that > function should be specified. > > > I also know of a data type: > > > > data Set xs = Set [xs] > > > > where the Set constructor is all nicely hidden. If I define Set "ab" > > to be equal to Set "ba", should the compiler burst into flames? > > ?? > > If we > > _require_ all Eq definitions to follow our very narrowly defined > > notion of equality, then the question comes up why we permit people to > > write Eq at all - why doesn't the compiler just do it for us, if there > > is only one right answer. > > You provided one example yourself.. > > data Foo = Foo Int (Int -> Int) > > It's perfectly possible for Foo to be an abstract type exported from > a module that preserves the invariant that the same function is always > associated with a given Int (value). > > If this is the case there's no reason why Foo should not be an instance > of Ord or Eq. > > If this isn't the case then Foo should certainly not be an instance or > either class IMO. > > If this was intended to be the case but in fact isn't the case, then > that's a bug. > > Regards > -- > Adrian Hey > > _______________________________________________ > 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/20080310/19ad4433/attachment.htm From westondan at imageworks.com Mon Mar 10 15:06:36 2008 From: westondan at imageworks.com (Dan Weston) Date: Mon Mar 10 15:05:02 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: <47D58494.7080003@imageworks.com> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <220e47b40803091848u5925dbe9l261a7ca076f9069e@mail.gmail.com> <200803092304.02063.dan.doel@gmail.com> <404396ef0803100127p4e99997amf2e2a6d70dce6e8b@mail.gmail.com> <47D514C2.8050102@iee.org> <47D58494.7080003@imageworks.com> Message-ID: <47D586BC.4040208@imageworks.com> On the other hand, though the behavior of == is not defined by the Report, it does require in 6.3.1 that if compare is defined, then == must be defined. That strongly implies a semantic causal link (in the Free Theorem kind of way), that the semantics of Ord completely specify the semantics of Eq, and the only free and continuous way to specify this is to make == and EQ always agree. I would (almost) take this conclusion as normative as well. Dan Dan Weston wrote: > > > Unfortunately the Haskell standards don't currently specify sane laws > > for Eq and Ord class instances, but they should. > > In fact there are requirements in the Haskell98 report: > > 6.3 Standard Haskell Classes > > Note the word "reasonable" in the paragraph below: > > "Default class method declarations (Section 4.3) are provided for many > of the methods in standard classes. A comment with each class > declaration in Chapter 8 specifies the smallest collection of method > definitions that, together with the default declarations, provide a > reasonable definition for all the class methods." > > This (coupled with the premise that anything not required is optional) > means that default definitions are not normative, so the following Ord > default code comment need not hold: > > "-- Note that (min x y, max x y) = (x,y) or (y,x)" > > However, the report text is normative: > > 6.3.2 (The Ord Class): > > "The Ord class is used for totally ordered datatypes." > > This *requires* that it be absolutely impossible in valid code to > distinguish equivalent (in the EQ sense, not the == sense) things via > the functions of Ord. The intended interpretation of these functions is > clear and can be taken as normative: > > forall f . (compare x y == EQ and (f x or f y is defined)) > ==> f x == f y) > > There is an (seriously insane but required by the total ordering, and in > any case) officially encouraged use of left-bias in sum types: > > "The declared order of the constructors in the data > declaration determines the ordering in derived Ord instances." > > Perhaps in Haskell' the total ordering requirement can be loosened to a > partial order (say in a class between Eq and Ord), with comparePartial > :: a -> a -> PartialOrdering? > > Dan > > Adrian Hey wrote: >> Neil Mitchell wrote: >>>> 2) What does it do with duplicate elements in the list? I expect it >>>> deletes >>>> them. To avoid this, you'd need to use something like fromListWith, >>>> keeping >>>> track of how many duplicates there are, and expanding at the end. >>> >>> That would be wrong. Consider: >>> >>> data Foo = Foo Int Int >>> >>> instance Ord Foo where >>> compare (Foo a _) (Foo b _) = compare a b >> >> I would consider such an Ord instance to be hopelessly broken, and I >> don't think it's the responsibility of authors of functions with Ord >> constraints in their sigs (such as sort) to consider such possibilities >> or specify and control the behaviour of their behaviour for such >> instances. Trying to do this is what leads to horrors such as the "left >> biasing" of Data.Map (for example). >> >> Unfortunately the Haskell standards don't currently specify sane laws >> for Eq and Ord class instances, but they should. Otherwise knowing a >> type is an instance of Ord tells me nothing that I can rely on. >> >> Regards >> -- >> Adrian Hey >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > > From ndmitchell at gmail.com Mon Mar 10 15:12:55 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon Mar 10 15:10:07 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: <47D58494.7080003@imageworks.com> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <220e47b40803091848u5925dbe9l261a7ca076f9069e@mail.gmail.com> <200803092304.02063.dan.doel@gmail.com> <404396ef0803100127p4e99997amf2e2a6d70dce6e8b@mail.gmail.com> <47D514C2.8050102@iee.org> <47D58494.7080003@imageworks.com> Message-ID: <404396ef0803101212n1546326t6c6b236e9e6a24c5@mail.gmail.com> Hi > "The Ord class is used for totally ordered datatypes." > > This *requires* that it be absolutely impossible in valid code to > distinguish equivalent (in the EQ sense, not the == sense) things via > the functions of Ord. The intended interpretation of these functions is > clear and can be taken as normative: > > forall f . (compare x y == EQ and (f x or f y is defined)) > ==> f x == f y) Are you sure? I would have read this as the ordering must be reflexive, antisymetric and transitive - the standard restrictions on any ordering. See http://en.wikipedia.org/wiki/Total_ordering Thanks Neil From dbueno at gmail.com Mon Mar 10 15:20:55 2008 From: dbueno at gmail.com (Denis Bueno) Date: Mon Mar 10 15:18:06 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: <404396ef0803101212n1546326t6c6b236e9e6a24c5@mail.gmail.com> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <220e47b40803091848u5925dbe9l261a7ca076f9069e@mail.gmail.com> <200803092304.02063.dan.doel@gmail.com> <404396ef0803100127p4e99997amf2e2a6d70dce6e8b@mail.gmail.com> <47D514C2.8050102@iee.org> <47D58494.7080003@imageworks.com> <404396ef0803101212n1546326t6c6b236e9e6a24c5@mail.gmail.com> Message-ID: <6dbd4d000803101220p20ceea39x4c56594e2db1e65f@mail.gmail.com> On Mon, Mar 10, 2008 at 3:12 PM, Neil Mitchell wrote: > Hi > > > > "The Ord class is used for totally ordered datatypes." > > > > This *requires* that it be absolutely impossible in valid code to > > distinguish equivalent (in the EQ sense, not the == sense) things via > > the functions of Ord. The intended interpretation of these functions is > > clear and can be taken as normative: > > > > forall f . (compare x y == EQ and (f x or f y is defined)) > > ==> f x == f y) > > Are you sure? I would have read this as the ordering must be > reflexive, antisymetric and transitive - the standard restrictions on > any ordering. See http://en.wikipedia.org/wiki/Total_ordering This is my reading, too. In addition, to make it total, the property that any two elements are comparable (this is the property that a partial order does not necessarily have). -- Denis From gtener at gmail.com Mon Mar 10 15:31:37 2008 From: gtener at gmail.com (=?ISO-8859-2?Q?Krzysztof_Skrz=EAtnicki?=) Date: Mon Mar 10 15:28:48 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: <47D586BC.4040208@imageworks.com> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <220e47b40803091848u5925dbe9l261a7ca076f9069e@mail.gmail.com> <200803092304.02063.dan.doel@gmail.com> <404396ef0803100127p4e99997amf2e2a6d70dce6e8b@mail.gmail.com> <47D514C2.8050102@iee.org> <47D58494.7080003@imageworks.com> <47D586BC.4040208@imageworks.com> Message-ID: <220e47b40803101231x3c227c43neebd10141402e1c0@mail.gmail.com> It certainly makes perfect sense, because total order antisymmetry law states that IF a <= b AND b <= a THEN a = b However it should rather be written IF a <= b AND b <= a THEN a ~= b, since = could be any equivalence class. However, we can also specify the Ord on type type Foo = Foo Int (Int->Int) in this way: instance Ord Foo where compare (Foo a _) (Foo b _) = compare a b which yields equivalence relation that is not assuming equivalence of the functions. So this restriction does not seem to work on Adrian Hey's side. Christopher Skrz?tnicki On Mon, Mar 10, 2008 at 8:06 PM, Dan Weston wrote: > On the other hand, though the behavior of == is not defined by the > Report, it does require in 6.3.1 that if compare is defined, then == > must be defined. That strongly implies a semantic causal link (in the > Free Theorem kind of way), that the semantics of Ord completely specify > the semantics of Eq, and the only free and continuous way to specify > this is to make == and EQ always agree. > > I would (almost) take this conclusion as normative as well. > > Dan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080310/5e585896/attachment.htm From daniel.is.fischer at web.de Mon Mar 10 16:09:52 2008 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Mon Mar 10 16:05:24 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: <404396ef0803101212n1546326t6c6b236e9e6a24c5@mail.gmail.com> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <47D58494.7080003@imageworks.com> <404396ef0803101212n1546326t6c6b236e9e6a24c5@mail.gmail.com> Message-ID: <200803102109.52455.daniel.is.fischer@web.de> Am Montag, 10. M?rz 2008 20:12 schrieb Neil Mitchell: > Hi > > > "The Ord class is used for totally ordered datatypes." > > > > This *requires* that it be absolutely impossible in valid code to > > distinguish equivalent (in the EQ sense, not the == sense) things via > > the functions of Ord. The intended interpretation of these functions is > > clear and can be taken as normative: > > > > forall f . (compare x y == EQ and (f x or f y is defined)) > > ==> f x == f y) > > Are you sure? I would have read this as the ordering must be > reflexive, antisymetric and transitive - the standard restrictions on > any ordering. See http://en.wikipedia.org/wiki/Total_ordering > But antisymmetry means that (x <= y) && (y <= x) ==> x = y, where '=' means identity. Now what does (should) 'identity' mean? Depends on the type, I dare say. For e.g. Int, it should mean 'identical bit pattern', shouldn't it? For IntSet it should mean 'x and y contain exactly the same elements', the internal tree-structure being irrelevant. But that means IntSet shouldn't export functions that allow to distinguish (other than by performance) between x and y. In short, I would consider code where for some x, y and a function f we have (x <= y) && (y <= x) [or, equivalently, compare x y == EQ] but f x /= f y broken indeed. So for data Foo = Foo Int (Int -> Int), an Ord instance via compare (Foo a _) (Foo b _) = compare a b is okay if Foo is an abstract datatype and outside the defining module it's guaranteed that compare (Foo a f) (Foo b g) == EQ implies (forall n. f n == g n), but not if the data-constructor Foo is exported. > Thanks > > Neil From gtener at gmail.com Mon Mar 10 16:33:31 2008 From: gtener at gmail.com (=?ISO-8859-2?Q?Krzysztof_Skrz=EAtnicki?=) Date: Mon Mar 10 16:30:42 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: <200803102109.52455.daniel.is.fischer@web.de> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <47D58494.7080003@imageworks.com> <404396ef0803101212n1546326t6c6b236e9e6a24c5@mail.gmail.com> <200803102109.52455.daniel.is.fischer@web.de> Message-ID: <220e47b40803101333m13236584g65c53718e00b1ccb@mail.gmail.com> No, '=' should not mean an identity but any equivalence relation. Therefore, we can use whatever equivalence relation suits us. The reasoning you provided is IMHO rather blur. Anyway, having possibility of using different equivalence relations is great because they mean different abstraction classes - and not all of them are isomorphic. On Mon, Mar 10, 2008 at 9:09 PM, Daniel Fischer wrote: > But antisymmetry means that (x <= y) && (y <= x) ==> x = y, where '=' > means > identity. Now what does (should) 'identity' mean? > Depends on the type, I dare say. For e.g. Int, it should mean 'identical > bit > pattern', shouldn't it? For IntSet it should mean 'x and y contain exactly > the same elements', the internal tree-structure being irrelevant. But that > means IntSet shouldn't export functions that allow to distinguish (other > than > by performance) between x and y. > > In short, I would consider code where for some x, y and a function f we > have > (x <= y) && (y <= x) [or, equivalently, compare x y == EQ] but f x /= f y > broken indeed. > > So for > data Foo = Foo Int (Int -> Int), > an Ord instance via compare (Foo a _) (Foo b _) = compare a b > is okay if Foo is an abstract datatype and outside the defining module > it's > guaranteed that > compare (Foo a f) (Foo b g) == EQ implies (forall n. f n == g n), but not > if > the data-constructor Foo is exported. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080310/58cdff1e/attachment.htm From ndmitchell at gmail.com Mon Mar 10 16:34:00 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon Mar 10 16:31:11 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: <200803102109.52455.daniel.is.fischer@web.de> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <47D58494.7080003@imageworks.com> <404396ef0803101212n1546326t6c6b236e9e6a24c5@mail.gmail.com> <200803102109.52455.daniel.is.fischer@web.de> Message-ID: <404396ef0803101334w18b3f0ebq758b4db26360d589@mail.gmail.com> Hi > But antisymmetry means that (x <= y) && (y <= x) ==> x = y, where '=' means > identity. Now what does (should) 'identity' mean? I think you are using the word identity when the right would would be equality. Hence, the answer is, without a doubt, (==). If you define equality, then you are defining equality. > In short, I would consider code where for some x, y and a function f we have > (x <= y) && (y <= x) [or, equivalently, compare x y == EQ] but f x /= f y > broken indeed. I would consider it slightly bad code too. But not broken code. I think Ord functions can assume that Ord is a total ordering, nothing more. Nothing to do with the existence (or otherwise) of entirely unrelated code. Consider the following implementation of Data.Set, which *does* meet all the invariants in Data.Set: data Set a = Set [a] insert x (Set xs) = Set $ x : filter (/= x) xs elems (Set xs) = xs i.e. there is real code in the base libraries which breaks this notion of respecting classes etc. Is the interface to Data.Set broken? I would say it isn't. Thanks Neil From westondan at imageworks.com Mon Mar 10 17:01:53 2008 From: westondan at imageworks.com (Dan Weston) Date: Mon Mar 10 16:59:11 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: <404396ef0803101334w18b3f0ebq758b4db26360d589@mail.gmail.com> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <47D58494.7080003@imageworks.com> <404396ef0803101212n1546326t6c6b236e9e6a24c5@mail.gmail.com> <200803102109.52455.daniel.is.fischer@web.de> <404396ef0803101334w18b3f0ebq758b4db26360d589@mail.gmail.com> Message-ID: <47D5A1C1.2090008@imageworks.com> If x <= y && y <= x does not imply that x == y, then Ord has no business being a subclass of Eq. By your logic, there is absolutely no constructive subclassing going on here, only an existence proof of (==) given (<=). What is the rational basis of such an existence claim, unless == has the obvious meaning? Or should I take it that you are suggesting we should move Ord up to be a peer of Eq? Dan Neil Mitchell wrote: > Hi > >> But antisymmetry means that (x <= y) && (y <= x) ==> x = y, where '=' means >> identity. Now what does (should) 'identity' mean? > > I think you are using the word identity when the right would would be > equality. Hence, the answer is, without a doubt, (==). If you define > equality, then you are defining equality. > >> In short, I would consider code where for some x, y and a function f we have >> (x <= y) && (y <= x) [or, equivalently, compare x y == EQ] but f x /= f y >> broken indeed. > > I would consider it slightly bad code too. But not broken code. I > think Ord functions can assume that Ord is a total ordering, nothing > more. Nothing to do with the existence (or otherwise) of entirely > unrelated code. > > Consider the following implementation of Data.Set, which *does* meet > all the invariants in Data.Set: > > data Set a = Set [a] > insert x (Set xs) = Set $ x : filter (/= x) xs > elems (Set xs) = xs > > i.e. there is real code in the base libraries which breaks this notion > of respecting classes etc. Is the interface to Data.Set broken? I > would say it isn't. > > Thanks > > Neil > > From ndmitchell at gmail.com Mon Mar 10 17:08:29 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon Mar 10 17:05:40 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: <47D5A1C1.2090008@imageworks.com> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <47D58494.7080003@imageworks.com> <404396ef0803101212n1546326t6c6b236e9e6a24c5@mail.gmail.com> <200803102109.52455.daniel.is.fischer@web.de> <404396ef0803101334w18b3f0ebq758b4db26360d589@mail.gmail.com> <47D5A1C1.2090008@imageworks.com> Message-ID: <404396ef0803101408m52bf9c4fl352c02bf50ebf998@mail.gmail.com> Hi > If x <= y && y <= x does not imply that x == y, then Ord has no business > being a subclass of Eq. By your logic, there is absolutely no > constructive subclassing going on here, only an existence proof of (==) > given (<=). What is the rational basis of such an existence claim, > unless == has the obvious meaning? Is this directed at me? I think x <= y && y <= x implies x == y. My point above was that where you have used x = y, I think = should be ==. I also think (compare x y == EQ) <=> (x == y), where <=> is bi-implication or boolean equality. i.e. Eq is a fine parent to Ord, but given a Eq/Ord pair they must be in agreement. Thanks Neil From ahey at iee.org Mon Mar 10 17:13:14 2008 From: ahey at iee.org (Adrian Hey) Date: Mon Mar 10 17:10:30 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: <220e47b40803101207w6d4bb795k68d959b3ccff9849@mail.gmail.com> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <47D514C2.8050102@iee.org> <404396ef0803100428v68b4c533w23942c5ddafd7910@mail.gmail.com> <47D52A87.9060805@iee.org> <404396ef0803100632w6ae183f3w467aa02bae40caa2@mail.gmail.com> <47D5416C.808@iee.org> <871w6i8wx4.fsf@nmd9999.imr.no> <47D55287.5040701@iee.org> <404396ef0803100829h44c8ac1dg4ee6f0132cb4f929@mail.gmail.com> <47D56B7A.2030200@iee.org> <220e47b40803101207w6d4bb795k68d959b3ccff9849@mail.gmail.com> Message-ID: <47D5A46A.5010800@iee.org> Krzysztof Skrze;tnicki wrote: > Ok, my turn now. Let's think about algorithm that takes equivalence > relation EQ, ordering relation ORD on abstraction classes generated by > this equivalence ( -> equivalence classes ) and divides given input > elements XS into appropriate classes and then prints them out according > to given ordering ORD. If we pose the restriction (let's call it (*)), > that input XS should have at most one element from every abstraction > class, we get sorting in a way that you desire. Hovewer, if we don't > pose that restriction the algorithm still makes perfect sense and is > given by standard library sortBy. > > I see no reason for restriction (*). I don't understand the above paragraph. Let's consider a simple example: (sort [a,b]) in the case we have: (compare a b = EQ) Which of the following 4 possible results are correct/incorrect? 1- [a,a] 2- [a,b] 3- [b,a] 4- [b,b] I would say they are all correct and equivalent for any "sane" Ord instance, though from the point of view of space efficiency 1 or 4 are preferable to 2 or 3. > For efficiency reasons there could be additional class StrictEq. If the > type is in that class then we can assume (*) and use more > space-efficient algorithm. > > Now, the problem with > > treeSort = concatMap (reverse . snd) . Map.toAscList > . Map.fromListWith (++) . map (\x -> (x,[x])) > > is that i can't tell any compact way of implementing treeSortBy in nice > manner. This is because Data.Map does not allow us to provide our own > comparison test instead of compare. As a practical matter, for benchmarking you should also count the actual number of comparisons needed, not just execution times for simple types (Ints presumably). Also, I think you'll find that the AVL lib gives better performance than Data.Map, particularly for sorted inputs. Unfortunately you can't use this implementation in the standard libs without making the AVL lib a standard lib (the same happens to be true of Data.Map too, thought this is widely perceived as being standard because of ghc library bundling :-) But actually I would say that if either (both) of these is faster than the the standard sort then this is some kind of performance bug with the current ghc release. They weren't faster last time I tested (with Ints). I also happen to think that sort should be made an Ord class method, so that trie based sorts are possible (which should be faster for complex data types). We should only use sort = sortBy compare as the default. Regards -- Adrian Hey From ndmitchell at gmail.com Mon Mar 10 17:33:51 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon Mar 10 17:31:02 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: <47D5A46A.5010800@iee.org> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <47D52A87.9060805@iee.org> <404396ef0803100632w6ae183f3w467aa02bae40caa2@mail.gmail.com> <47D5416C.808@iee.org> <871w6i8wx4.fsf@nmd9999.imr.no> <47D55287.5040701@iee.org> <404396ef0803100829h44c8ac1dg4ee6f0132cb4f929@mail.gmail.com> <47D56B7A.2030200@iee.org> <220e47b40803101207w6d4bb795k68d959b3ccff9849@mail.gmail.com> <47D5A46A.5010800@iee.org> Message-ID: <404396ef0803101433s435bbc64j46617fe50ba46aa5@mail.gmail.com> Hi > (sort [a,b]) in the case we have: (compare a b = EQ) > > Which of the following 4 possible results are correct/incorrect? > 1- [a,a] > 2- [a,b] > 3- [b,a] > 4- [b,b] Fortunately the Haskell sort is meant to be stable, and sorting is meant to be a permutation, so we happily have the situation where this has a correct answer: 2. Anything else is incorrect. Anyone submitting a revised sort through the Haskell libraries process will have to ensure the answer is 2. I hope someone does take the time to do this, as a faster base library will benefit everyone. Adrian: I think its fairly clear we disagree about these things. However, we both understand the others point of view, so I guess its just a question of opinion - and I doubt either of us will change. As such I think any further discussion may just lead to sleep deprivation [1]. I think I'm coming from a more discrete maths/theoretical background while you are coming from a more practical/pragmatist background. Thanks Neil [1] http://xkcd.com/386/ From gtener at gmail.com Mon Mar 10 17:39:51 2008 From: gtener at gmail.com (=?ISO-8859-2?Q?Krzysztof_Skrz=EAtnicki?=) Date: Mon Mar 10 17:37:02 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: <47D5A46A.5010800@iee.org> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <47D52A87.9060805@iee.org> <404396ef0803100632w6ae183f3w467aa02bae40caa2@mail.gmail.com> <47D5416C.808@iee.org> <871w6i8wx4.fsf@nmd9999.imr.no> <47D55287.5040701@iee.org> <404396ef0803100829h44c8ac1dg4ee6f0132cb4f929@mail.gmail.com> <47D56B7A.2030200@iee.org> <220e47b40803101207w6d4bb795k68d959b3ccff9849@mail.gmail.com> <47D5A46A.5010800@iee.org> Message-ID: <220e47b40803101439q3977715cl5638a2549c691fe8@mail.gmail.com> On Mon, Mar 10, 2008 at 10:13 PM, Adrian Hey wrote: > > (sort [a,b]) in the case we have: (compare a b = EQ) > > Which of the following 4 possible results are correct/incorrect? > 1- [a,a] > 2- [a,b] > 3- [b,a] > 4- [b,b] I'd say 2 and 3 are sane, while 2 is correct - because we need stable sort. Stable - this is the keyword! If `==` would mean identity then we wouldn't need a stable sorting algorithm. Christopher Skrz?tnicki -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080310/d5503f1f/attachment.htm From daniel.is.fischer at web.de Mon Mar 10 17:48:59 2008 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Mon Mar 10 17:44:42 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: <404396ef0803101334w18b3f0ebq758b4db26360d589@mail.gmail.com> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <200803102109.52455.daniel.is.fischer@web.de> <404396ef0803101334w18b3f0ebq758b4db26360d589@mail.gmail.com> Message-ID: <200803102248.59549.daniel.is.fischer@web.de> Am Montag, 10. M?rz 2008 21:34 schrieb Neil Mitchell: > Hi > > > But antisymmetry means that (x <= y) && (y <= x) ==> x = y, where '=' > > means identity. Now what does (should) 'identity' mean? > > I think you are using the word identity when the right would would be > equality. Hence, the answer is, without a doubt, (==). If you define > equality, then you are defining equality. Okay, bad choice of words. Of course I expect compare x y == EQ <==> x == y for any Ord instance. And for f :: (Eq a, Eq b) => a -> b I expect (x == y) ==> (f x == f y). > > > In short, I would consider code where for some x, y and a function f we > > have (x <= y) && (y <= x) [or, equivalently, compare x y == EQ] but f x > > /= f y broken indeed. > > I would consider it slightly bad code too. But not broken code. I Perhaps 'broken' is a stronger word than I thought. I wouldn't say there can never be a reason for such. It would not necessarily be *badly* broken, though at the moment I can't see a case where such behaviour (in an exported function) would be reasonable. Of course, internal fuctions are a different matter. > think Ord functions can assume that Ord is a total ordering, nothing > more. Nothing to do with the existence (or otherwise) of entirely > unrelated code. > > Consider the following implementation of Data.Set, which *does* meet > all the invariants in Data.Set: > > data Set a = Set [a] > insert x (Set xs) = Set $ x : filter (/= x) xs > elems (Set xs) = xs > > i.e. there is real code in the base libraries which breaks this notion > of respecting classes etc. Is the interface to Data.Set broken? I > would say it isn't. I would say, if we have x = Set [1,2], y = Set [2,1] and an Eq instance where x == y, then elems shouldn't be exported. > > Thanks > > Neil Cheers, Daniel From pocm at soton.ac.uk Mon Mar 10 18:11:33 2008 From: pocm at soton.ac.uk (Paulo J. Matos) Date: Mon Mar 10 18:08:45 2008 Subject: [Haskell-cafe] IO () and IO [()] Message-ID: <11b141710803101511w5ac7894ch27bea31e1e277107@mail.gmail.com> Hello all, I find it funny that IO () is different from IO [()]. For example, if I define a function to output some lines with mapT, I would do: outputLines :: Int -> IO () outputLines i = mapM (putStrLn . show) (take i $ iterate ((+) 1) 1) However, this is in fact outputLines :: Int -> IO [()] I would like to know if in fact there's any difference in practice between (), [()], i.e. if in practice the difference matters. My first guess is that this is just a consequence of the Haskell type system and so that everything fits this really needs to be like this. Because mapM :: (Monad m) => (a -> m b) -> [a] -> m [b] So I guess that it makes sense that you get IO [()] instead of IO (), and adding an exception just to say that [()] == () isn't good. By the way, as a consequence can you possibly get IO (()) or IO ([()]) and are these all different from each other? Cheers, -- Paulo Jorge Matos - pocm at soton.ac.uk http://www.personal.soton.ac.uk/pocm PhD Student @ ECS University of Southampton, UK Sponsor ECS runners - Action against Hunger: http://www.justgiving.com/ecsrunslikethewind From ndmitchell at gmail.com Mon Mar 10 18:17:43 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon Mar 10 18:14:53 2008 Subject: [Haskell-cafe] IO () and IO [()] In-Reply-To: <11b141710803101511w5ac7894ch27bea31e1e277107@mail.gmail.com> References: <11b141710803101511w5ac7894ch27bea31e1e277107@mail.gmail.com> Message-ID: <404396ef0803101517q25344eabxa8c7fc5f6f1220e8@mail.gmail.com> Hi > I would like to know if in fact there's any difference in practice > between (), [()], i.e. if in practice the difference matters. Usually, not so much. A lot of Monad functions have _ variants, i.e. mapM and mapM_. If you don't need the result, use the mapM_ version, as it will run faster and not space/stack leak in some circumstances. > By the way, as a consequence can you possibly get IO (()) or IO ([()]) > and are these all different from each other? Read () as Unit. You can't put anything in a Unit, even if the bracket notation subtly suggests you can. You can have IO Unit and IO [Unit], but not IO Un(Unit)it or IO Un([Unit])it. The two types you gave can't exist. Thanks Neil From overdrigzed at gmail.com Mon Mar 10 18:18:01 2008 From: overdrigzed at gmail.com (Rodrigo Queiro) Date: Mon Mar 10 18:15:16 2008 Subject: [Haskell-cafe] IO () and IO [()] In-Reply-To: <11b141710803101511w5ac7894ch27bea31e1e277107@mail.gmail.com> References: <11b141710803101511w5ac7894ch27bea31e1e277107@mail.gmail.com> Message-ID: <2eb8984a0803101518q5915887n33e495d0557adb0b@mail.gmail.com> You're looking for mapM_ mapM_ :: (Monad m) => (a -> m b) -> [a] -> m () (see also sequence_ :: (Monad m) => [m a] -> m () ) I don't think that it is possible to have a 1-tuples, just 2 and up. () is a unit rather than a 0-tuple, apparently: http://www.haskell.org/onlinereport/basic.html#sect6.1.4 On 10/03/2008, Paulo J. Matos wrote: > > Hello all, > > I find it funny that IO () is different from IO [()]. > For example, if I define a function to output some lines with mapT, I > would do: > outputLines :: Int -> IO () > outputLines i = mapM (putStrLn . show) (take i $ iterate ((+) 1) 1) > > However, this is in fact > outputLines :: Int -> IO [()] > > I would like to know if in fact there's any difference in practice > between (), [()], i.e. if in practice the difference matters. > My first guess is that this is just a consequence of the Haskell type > system and so that everything fits this really needs to be like this. > Because > mapM :: (Monad m) => (a -> m b) -> [a] -> m [b] > > So I guess that it makes sense that you get IO [()] instead of IO (), > and adding an exception just to say that [()] == () isn't good. > By the way, as a consequence can you possibly get IO (()) or IO ([()]) > and are these all different from each other? > > Cheers, > > -- > Paulo Jorge Matos - pocm at soton.ac.uk > http://www.personal.soton.ac.uk/pocm > PhD Student @ ECS > University of Southampton, UK > Sponsor ECS runners - Action against Hunger: > http://www.justgiving.com/ecsrunslikethewind > _______________________________________________ > 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/20080310/6d988de1/attachment.htm From zao at acc.umu.se Mon Mar 10 18:19:09 2008 From: zao at acc.umu.se (Lars Viklund) Date: Mon Mar 10 18:16:28 2008 Subject: [Haskell-cafe] IO () and IO [()] In-Reply-To: <11b141710803101511w5ac7894ch27bea31e1e277107@mail.gmail.com> References: <11b141710803101511w5ac7894ch27bea31e1e277107@mail.gmail.com> Message-ID: <20080310221909.GC22702@shaka.acc.umu.se> On Mon, Mar 10, 2008 at 10:11:33PM +0000, Paulo J. Matos wrote: > mapM :: (Monad m) => (a -> m b) -> [a] -> m [b] > > So I guess that it makes sense that you get IO [()] instead of IO (), > and adding an exception just to say that [()] == () isn't good. > By the way, as a consequence can you possibly get IO (()) or IO ([()]) > and are these all different from each other? Note that there exists mapM_ which discards the return values. mapM_ :: (Monad m) => (a -> m b) -> [a] -> m () -- Lars Viklund | zao@acc.umu.se From john at repetae.net Mon Mar 10 18:19:39 2008 From: john at repetae.net (John Meacham) Date: Mon Mar 10 18:16:49 2008 Subject: [Haskell-cafe] automagically? In-Reply-To: <5ae4f2ba0803032056l18979319t384c527a337899b3@mail.gmail.com> References: <5ae4f2ba0803032056l18979319t384c527a337899b3@mail.gmail.com> Message-ID: <20080310221939.GA8569@sliver.repetae.net> On Mon, Mar 03, 2008 at 10:56:55PM -0600, Galchin Vasili wrote: > Say i am building package X that depends on A, H, D. How can I > automagically check to A, H, D need to "darcs get" down and built/install > before X? If this feature is not available it should be, i.e. an integration > of darcs and cabal. I use 'make' to do so. I find it much more straightforward/useful to have 'make' drive cabal than the other way around in general. John -- John Meacham - ?repetae.net?john? From alfonso.acosta at gmail.com Mon Mar 10 18:34:51 2008 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Mon Mar 10 18:32:00 2008 Subject: [Haskell-cafe] IO () and IO [()] In-Reply-To: <11b141710803101511w5ac7894ch27bea31e1e277107@mail.gmail.com> References: <11b141710803101511w5ac7894ch27bea31e1e277107@mail.gmail.com> Message-ID: <6a7c66fc0803101534x210c90e3q6392e69f6b28d1c3@mail.gmail.com> On Mon, Mar 10, 2008 at 11:11 PM, Paulo J. Matos wrote: > outputLines i = mapM (putStrLn . show) (take i $ iterate ((+) 1) 1) > > However, this is in fact > outputLines :: Int -> IO [()] As others suggested you can use mapM_ Furthermore, you can simplify it a bit with some syntactic sugar outputLines i = mapM_ (putStrLn . show) [1..i] BTW, considering how often is (putStrLn.show) used, it is surprising that there is no Ln variant for print (just like it happens with putStr and putStrLn) From ajb at spamcop.net Mon Mar 10 18:45:01 2008 From: ajb at spamcop.net (ajb@spamcop.net) Date: Mon Mar 10 18:42:11 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: <47D58494.7080003@imageworks.com> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <220e47b40803091848u5925dbe9l261a7ca076f9069e@mail.gmail.com> <200803092304.02063.dan.doel@gmail.com> <404396ef0803100127p4e99997amf2e2a6d70dce6e8b@mail.gmail.com> <47D514C2.8050102@iee.org> <47D58494.7080003@imageworks.com> Message-ID: <20080310184501.dgpbeu7cg0ocoowg@webmail.spamcop.net> G'day all. Quoting Dan Weston : > 6.3.2 (The Ord Class): > > "The Ord class is used for totally ordered datatypes." So... Double shouldn't be there, then? As previously noted, nowhere is it even required that x /= y should "do the same thing" as not (x == y). Cheers, Andrew Bromage From felipe.lessa at gmail.com Mon Mar 10 18:46:47 2008 From: felipe.lessa at gmail.com (Felipe Lessa) Date: Mon Mar 10 18:43:57 2008 Subject: [Haskell-cafe] IO () and IO [()] In-Reply-To: <6a7c66fc0803101534x210c90e3q6392e69f6b28d1c3@mail.gmail.com> References: <11b141710803101511w5ac7894ch27bea31e1e277107@mail.gmail.com> <6a7c66fc0803101534x210c90e3q6392e69f6b28d1c3@mail.gmail.com> Message-ID: On Mon, Mar 10, 2008 at 7:34 PM, Alfonso Acosta wrote: > BTW, considering how often is (putStrLn.show) used, it is surprising > that there is no Ln variant for print (just like it happens with > putStr and putStrLn) Actually, > print = putStrLn . show so > outputLines i = mapM_ print [1..i] -- Felipe. From daniel.is.fischer at web.de Mon Mar 10 18:48:36 2008 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Mon Mar 10 18:44:50 2008 Subject: [Haskell-cafe] IO () and IO [()] In-Reply-To: <6a7c66fc0803101534x210c90e3q6392e69f6b28d1c3@mail.gmail.com> References: <11b141710803101511w5ac7894ch27bea31e1e277107@mail.gmail.com> <6a7c66fc0803101534x210c90e3q6392e69f6b28d1c3@mail.gmail.com> Message-ID: <200803102348.36063.daniel.is.fischer@web.de> Am Montag, 10. M?rz 2008 23:34 schrieb Alfonso Acosta: > On Mon, Mar 10, 2008 at 11:11 PM, Paulo J. Matos wrote: > > outputLines i = mapM (putStrLn . show) (take i $ iterate ((+) 1) 1) > > > > However, this is in fact > > outputLines :: Int -> IO [()] > > As others suggested you can use mapM_ > > Furthermore, you can simplify it a bit with some syntactic sugar > > outputLines i = mapM_ (putStrLn . show) [1..i] > > BTW, considering how often is (putStrLn.show) used, it is surprising > that there is no Ln variant for print (just like it happens with > putStr and putStrLn) But print is (putStrLn . show), so what may be missing is (putStr . show). From ndmitchell at gmail.com Mon Mar 10 18:47:47 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon Mar 10 18:44:59 2008 Subject: [Haskell-cafe] IO () and IO [()] In-Reply-To: <6a7c66fc0803101534x210c90e3q6392e69f6b28d1c3@mail.gmail.com> References: <11b141710803101511w5ac7894ch27bea31e1e277107@mail.gmail.com> <6a7c66fc0803101534x210c90e3q6392e69f6b28d1c3@mail.gmail.com> Message-ID: <404396ef0803101547q676899dam7c32ba7c21c73d44@mail.gmail.com> Hi > BTW, considering how often is (putStrLn.show) used, it is surprising > that there is no Ln variant for print (just like it happens with > putStr and putStrLn) print = putStrLn . show There is no non-trailing-line version of print. Thanks Neil From alfonso.acosta at gmail.com Mon Mar 10 19:00:22 2008 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Mon Mar 10 18:57:32 2008 Subject: [Haskell-cafe] IO () and IO [()] In-Reply-To: <200803102348.36063.daniel.is.fischer@web.de> References: <11b141710803101511w5ac7894ch27bea31e1e277107@mail.gmail.com> <6a7c66fc0803101534x210c90e3q6392e69f6b28d1c3@mail.gmail.com> <200803102348.36063.daniel.is.fischer@web.de> Message-ID: <6a7c66fc0803101600u4a8e4fb0gd55fe43d6d3e6943@mail.gmail.com> On Mon, Mar 10, 2008 at 11:48 PM, Daniel Fischer wrote: > But print is (putStrLn . show), so what may be missing is (putStr . show). That's what I meant sorry .. From dpiponi at gmail.com Mon Mar 10 19:01:19 2008 From: dpiponi at gmail.com (Dan Piponi) Date: Mon Mar 10 18:58:30 2008 Subject: [Haskell-cafe] IO () and IO [()] In-Reply-To: <11b141710803101511w5ac7894ch27bea31e1e277107@mail.gmail.com> References: <11b141710803101511w5ac7894ch27bea31e1e277107@mail.gmail.com> Message-ID: <625b74080803101601j6aac8b7bl2e1119de4764eb96@mail.gmail.com> On Mon, Mar 10, 2008 at 3:11 PM, Paulo J. Matos wrote: > I would like to know if in fact there's any difference in practice > between (), [()], i.e. if in practice the difference matters. The type [()] is very similar to the type Integer and it's quite different from () because you can count with it. For example: main = do count <- mapM print ["Hello","World"] print $ "You printed " ++ show (length count) ++ " lines" You can't do that with a IO (). Not that I actually recommend doing this. -- Dan From jeremy at n-heptane.com Mon Mar 10 19:02:07 2008 From: jeremy at n-heptane.com (Jeremy Shaw) Date: Mon Mar 10 18:59:14 2008 Subject: [Haskell-cafe] IO () and IO [()] In-Reply-To: <11b141710803101511w5ac7894ch27bea31e1e277107@mail.gmail.com> References: <11b141710803101511w5ac7894ch27bea31e1e277107@mail.gmail.com> Message-ID: <87skyyp4i8.wl%jeremy@n-heptane.com> At Mon, 10 Mar 2008 22:11:33 +0000, Paulo J. Matos wrote: > I would like to know if in fact there's any difference in practice > between (), [()], i.e. if in practice the difference matters. Well, you could do something like this: outputLines :: Int -> IO [()] outputLines i = mapM (putStrLn . show) (take (i*2) $ iterate ((+) 1) 1) main = do l <- outputLines 10 putStrLn $ "I putted " ++ show (length l) ++ " lines." which is not very exciting in this case. But I think I may have done something similar in real code. j. From westondan at imageworks.com Mon Mar 10 19:17:04 2008 From: westondan at imageworks.com (Dan Weston) Date: Mon Mar 10 19:16:55 2008 Subject: [Haskell-cafe] IO () and IO [()] In-Reply-To: <2eb8984a0803101518q5915887n33e495d0557adb0b@mail.gmail.com> References: <11b141710803101511w5ac7894ch27bea31e1e277107@mail.gmail.com> <2eb8984a0803101518q5915887n33e495d0557adb0b@mail.gmail.com> Message-ID: <47D5C170.7000001@imageworks.com> I understand the lack of distinction between a unit type and a 0-tuple, since they are isomorphic. But it is strange that there is no 1-tuple, since _|_ and the 1-tuple (_|_) would be different things entirely, no? Dan Rodrigo Queiro wrote: > You're looking for mapM_ > mapM_ :: (Monad m) => (a -> m b) -> [a] -> m () > (see also sequence_ :: (Monad m) => [m a] -> m () ) > > I don't think that it is possible to have a 1-tuples, just 2 and up. () > is a unit rather than a 0-tuple, apparently: > http://www.haskell.org/onlinereport/basic.html#sect6.1.4 > > On 10/03/2008, *Paulo J. Matos* > wrote: > > Hello all, > > I find it funny that IO () is different from IO [()]. > For example, if I define a function to output some lines with mapT, > I would do: > outputLines :: Int -> IO () > outputLines i = mapM (putStrLn . show) (take i $ iterate ((+) 1) 1) > > However, this is in fact > outputLines :: Int -> IO [()] > > I would like to know if in fact there's any difference in practice > between (), [()], i.e. if in practice the difference matters. > My first guess is that this is just a consequence of the Haskell type > system and so that everything fits this really needs to be like this. > Because > mapM :: (Monad m) => (a -> m b) -> [a] -> m [b] > > So I guess that it makes sense that you get IO [()] instead of IO (), > and adding an exception just to say that [()] == () isn't good. > By the way, as a consequence can you possibly get IO (()) or IO ([()]) > and are these all different from each other? > > Cheers, > > -- > Paulo Jorge Matos - pocm at soton.ac.uk > http://www.personal.soton.ac.uk/pocm > PhD Student @ ECS > University of Southampton, UK > Sponsor ECS runners - Action against Hunger: > http://www.justgiving.com/ecsrunslikethewind > _______________________________________________ > 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 ndmitchell at gmail.com Mon Mar 10 19:24:39 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon Mar 10 19:21:50 2008 Subject: [Haskell-cafe] IO () and IO [()] In-Reply-To: <47D5C170.7000001@imageworks.com> References: <11b141710803101511w5ac7894ch27bea31e1e277107@mail.gmail.com> <2eb8984a0803101518q5915887n33e495d0557adb0b@mail.gmail.com> <47D5C170.7000001@imageworks.com> Message-ID: <404396ef0803101624h7879f5cqbf384541f833fdbb@mail.gmail.com> Hi > I understand the lack of distinction between a unit type and a 0-tuple, > since they are isomorphic. It's more we pronounce 0-tuple as unit, they are identical. > But it is strange that there is no 1-tuple, > since _|_ and the 1-tuple (_|_) would be different things entirely, no? Yes, it would be useful, but what would the syntax be? (x) already means something else - namely grouping. Yhc defines both Tuple1 and _E, both of which are the 1-tuple. I'd like it if there was a standard definition Box for the 1-tuple, in the base libraries. Thanks Neil From gtener at gmail.com Mon Mar 10 19:27:56 2008 From: gtener at gmail.com (=?ISO-8859-2?Q?Krzysztof_Skrz=EAtnicki?=) Date: Mon Mar 10 19:25:06 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: <404396ef0803100136s4f8d4bd0ub376095a747a2195@mail.gmail.com> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <220e47b40803091848u5925dbe9l261a7ca076f9069e@mail.gmail.com> <200803092304.02063.dan.doel@gmail.com> <404396ef0803100127p4e99997amf2e2a6d70dce6e8b@mail.gmail.com> <404396ef0803100136s4f8d4bd0ub376095a747a2195@mail.gmail.com> Message-ID: <220e47b40803101627g795fc89fk4519d0f35493284b@mail.gmail.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: sorting.tar.gz Type: application/x-gzip Size: 1877 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080311/a7c726d0/sorting.tar.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: sortbench.py Type: text/x-python Size: 1368 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080311/a7c726d0/sortbench.py -------------- next part -------------- A non-text attachment was scrubbed... Name: sortbench.hs Type: text/x-haskell Size: 2740 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080311/a7c726d0/sortbench.bin From dave.a.tapley at gmail.com Mon Mar 10 19:33:58 2008 From: dave.a.tapley at gmail.com (Dave Tapley) Date: Mon Mar 10 19:31:10 2008 Subject: [Haskell-cafe] Constructing Data.Map from ByteString Message-ID: Hi all, I've been plugging away at this all day and some discussion in #haskell has been fruitless. Perhaps you have the inspiration to see what's happening! Concerning this minimal example: http://hpaste.org/6268 It works as required, loading K/V pairs into a Data.Map, the concern is the amount of memory used. Pausing (using a getLine) after the readFile one can see (through 'ps v') that the whole file 'f' is loaded in to memory. However once the Map is created the memory footprint swells to around five times the size. Surely this can't be just overhead from Map? My reasoning was that by using ByteString and getting the whole file into memory a small and linear increase would be seen for Map overhead.. I have tried using both Data.ByteString.Char8 and Data.ByteString.Lazy.Char8 with negligible difference. For a hoot I tried it with String and yes, it's ridiculous :) Cheers, Dave From gtener at gmail.com Mon Mar 10 19:37:33 2008 From: gtener at gmail.com (=?ISO-8859-2?Q?Krzysztof_Skrz=EAtnicki?=) Date: Mon Mar 10 19:34:43 2008 Subject: [Haskell-cafe] IO () and IO [()] In-Reply-To: <404396ef0803101624h7879f5cqbf384541f833fdbb@mail.gmail.com> References: <11b141710803101511w5ac7894ch27bea31e1e277107@mail.gmail.com> <2eb8984a0803101518q5915887n33e495d0557adb0b@mail.gmail.com> <47D5C170.7000001@imageworks.com> <404396ef0803101624h7879f5cqbf384541f833fdbb@mail.gmail.com> Message-ID: <220e47b40803101637p7292ab13l14b50cde8ebfee45@mail.gmail.com> In Python the syntax to create 1-tuple is *(element,)*. Note the ",". It's not the most beautiful but is acceptable. Christopher Skrz?tnicki On Tue, Mar 11, 2008 at 12:24 AM, Neil Mitchell wrote: > Hi > > > I understand the lack of distinction between a unit type and a 0-tuple, > http://www.haskell.org/pipermail/ > > since they are isomorphic. > > It's more we pronounce 0-tuple as unit, they are identical. > > > But it is strange that there is no 1-tuple, > > since _|_ and the 1-tuple (_|_) would be different things entirely, no? > > Yes, it would be useful, but what would the syntax be? (x) already > means something else - namely grouping. Yhc defines both Tuple1 and > _E, both of which are the 1-tuple. I'd like it if there was a standard > definition Box for the 1-tuple, in the base libraries. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080311/f78f4243/attachment.htm From ndmitchell at gmail.com Mon Mar 10 19:41:59 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon Mar 10 19:39:09 2008 Subject: [Haskell-cafe] IO () and IO [()] In-Reply-To: <220e47b40803101637p7292ab13l14b50cde8ebfee45@mail.gmail.com> References: <11b141710803101511w5ac7894ch27bea31e1e277107@mail.gmail.com> <2eb8984a0803101518q5915887n33e495d0557adb0b@mail.gmail.com> <47D5C170.7000001@imageworks.com> <404396ef0803101624h7879f5cqbf384541f833fdbb@mail.gmail.com> <220e47b40803101637p7292ab13l14b50cde8ebfee45@mail.gmail.com> Message-ID: <404396ef0803101641i30307f13meb7cf0cbf9dcf46a@mail.gmail.com> Hi > In Python the syntax to create 1-tuple is (element,). Note the ",". It's not > the most beautiful but is acceptable. But in Haskell we can write tuples in infix syntax, i.e. (,) is the 2 tuple. Unfortunately, this syntax doesn't suggest anything for the infix 1-tuple, and clashes with the 2-tuple a bit. Thanks Neil From chak at cse.unsw.edu.au Mon Mar 10 19:48:25 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Mon Mar 10 19:45:40 2008 Subject: [Haskell-cafe] Re: [GSoC] A data parallel physics engine In-Reply-To: <20080310143002.GA30015@home.ro-che.info> References: <20080310143002.GA30015@home.ro-che.info> Message-ID: <9495446E-9F60-40CF-842E-1C1F4BFED055@cse.unsw.edu.au> Roman Cheplyaka: > I'm looking for interesting project to work on during Google Summer of > Code. So I found [1]"A data parallel physics engine" ticket and got > excited about it. I'd like to know interested mentors and community > opinion about the complexity of such project. > > I have not very deep knowledge about both NDP and physics engines. Is > it feasible to learn all the necessary stuff during these 2 month > before > SoC starts? > > 1. http://hackage.haskell.org/trac/summer-of-code/ticket/1535 Using NDP is actually pretty easy, that is, for somebody who is already used to functional programming. The idea is, for anything you want to have running in parallel, don't use explicit recursion, but use list comprehensions (well, array comprehensions, but it's the same idea) and combinators like mapP, foldP, scanP, etc (which are also like their list variants). Here, for example, is quicksort: > qsort :: Ord a => [:a:] -> [:a:] > qsort [::] = [::] > qsort xs = let > m = xs!:0 > ss = [:x | x <- xs, x < m:] > ms = [:x | x <- xs, x == m:] > gs = [:x | x <- xs, x > m:] > qs = [:qsort ys | ys <- [:ss, gs:]:] > in > qs!:0 +:+ ms +:+ qs!:1 where [:a:] is the type of arrays of as, [::] is an empty array, [: .. | .. :] are array comprehensions, (!:) is array indexing, and (+:+) array concatenation. The only funny thing is the bindings of qs, where we put ss and gs into an array and apply qsort recursively *inside* an array comprehension. This is so that the two recursive calls to qsort happen in parallel. Getting good parallel performance is the tricky bit, but in a project like the physics engine for GSoC, a basic parallelisation strategy is sufficient and performance can then be improved incrementally. We don't expect anybody to implement a fully-fledged, fully parallelised, high-performance physics engine during GSoC. It is rather about laying a solid foundation on which we can then build over time. (GSoC is a lot about getting exciting open source projects of the ground, not about producing a polished product that doesn't change anymore after GSoC.) Besides, there is more to physics engines than just collision detection. Another aspect is physical simulations of non-solid bodies, such as liquids and cloth - re the latter, see for an interesting SIGGRAPH paper. What aspect we'd cover in the GSoC project would really be a matter of what you are most interested in. So, overall, I agree with that this is an exciting project ;) Manuel From lrpalmer at gmail.com Mon Mar 10 19:50:38 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Mon Mar 10 19:47:48 2008 Subject: [Haskell-cafe] IO () and IO [()] In-Reply-To: <220e47b40803101637p7292ab13l14b50cde8ebfee45@mail.gmail.com> References: <11b141710803101511w5ac7894ch27bea31e1e277107@mail.gmail.com> <2eb8984a0803101518q5915887n33e495d0557adb0b@mail.gmail.com> <47D5C170.7000001@imageworks.com> <404396ef0803101624h7879f5cqbf384541f833fdbb@mail.gmail.com> <220e47b40803101637p7292ab13l14b50cde8ebfee45@mail.gmail.com> Message-ID: <7ca3f0160803101650w293e0793g82ed9c71e9e71dfd@mail.gmail.com> 2008/3/10 Krzysztof Skrz?tnicki : > In Python the syntax to create 1-tuple is (element,). Note the ",". It's not > the most beautiful but is acceptable. But that syntax ought to be for tuple sections. Is there a good reason that Haskell doesn't have tuple sections? ("hello", "world") :: (String,String) (,) :: a -> b -> (a,b) ("hello",) :: a -> (String,a) -- I want this (,"hello") :: a -> (a, String) -- this too On an unrelated note, the only time I can recall where I wanted a "Box" data type was when I was doing evil with the garbage collector. Can someone show me an example of when they would use a Box? Not that it's hard to make yourself... data Box a = Box a Luke From hpacheco at gmail.com Mon Mar 10 19:51:56 2008 From: hpacheco at gmail.com (Hugo Pacheco) Date: Mon Mar 10 19:49:08 2008 Subject: [Haskell-cafe] Equality constraints in type families Message-ID: <7b92c2840803101651x3673691eid310ab137805eeff@mail.gmail.com> Hi all, I have encoded a type family such that: type family F a :: * -> * and a function (I know it is complicated, but I think the problem is self explanatory): hyloPara :: (Functor (F a), Functor (F d), F d a ~ F a (a,a), F d c ~ F a (c,a)) => d -> (F d c -> c) -> (a -> F d a) -> a -> c hyloPara d g h = g . fmap (hyloPara d g h) . h it all works fine. However, if I change the declaration to (changed F d c for the "supposedly equivalent" F a (c,a)): hyloPara :: (Functor (F a), Functor (F d), F d a ~ F a (a,a), F d c ~ F a (c,a)) => d -> (F a (c,a) -> c) -> (a -> F d a) -> a -> c and I get Occurs check: cannot construct the infinite type: c = (c, a) When generalising the type(s) for `hyloPara' This really messes up my notions on equality constraints, is it the expected behavior? It would be essential for me to provide this definition. Thanks, hugo -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080310/3f7844e7/attachment-0001.htm From jonathanccast at fastmail.fm Mon Mar 10 20:48:29 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Mon Mar 10 20:45:58 2008 Subject: [Haskell-cafe] Exception handling when using STUArray In-Reply-To: References: <87wsod6ax8.fsf@columbia.edu> <6dbd4d000803080631s5d16e43cr7f7b2623c932b175@mail.gmail.com> Message-ID: <989AC059-9B60-40A1-9ECF-2CC9AC47D19E@fastmail.fm> On 10 Mar 2008, at 12:37 AM, Donn Cave wrote: > > On Mar 9, 2008, at 1:07 PM, Henning Thielemann wrote: > >> >> Errors are programming errors and must be fixed as Denis >> explained. Thus >> there is no need for a complex system of handling these situations at >> run-time. The program error might be unexpected but it isn't the >> fault of >> the user or of the context the program runs in but of the fault of >> the >> programmer. The program may report "bug detected, send an e-mail >> to the >> author" but eventually it should quit (at least the buggy thread) >> before >> worse things happen. This is possible in Haskell but should not be >> mixed >> up with handling of exceptions like "non-existing file". > > I am not sure I see the difference in principle that you see. > > An exception is, for me, any state that isn't properly accounted > for in its > immediate context. openFile could return 'Maybe Handle', but it > doesn't, > so the context demands a Handle or an exception. In the context of this discussion, `Maybe Handle' /is/ an exception type, because Maybe is an exception monad. As is IO. This distinction is one between an unusual-but-anticipated code path, and a case the programmer simply didn't handle at all. The former is an exception; the latter is an error. jcc From jonathanccast at fastmail.fm Mon Mar 10 21:08:04 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Mon Mar 10 21:05:40 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: <47D514C2.8050102@iee.org> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <220e47b40803091848u5925dbe9l261a7ca076f9069e@mail.gmail.com> <200803092304.02063.dan.doel@gmail.com> <404396ef0803100127p4e99997amf2e2a6d70dce6e8b@mail.gmail.com> <47D514C2.8050102@iee.org> Message-ID: <7383E6EC-83B6-4F28-98BA-0A187D0E52C5@fastmail.fm> On 10 Mar 2008, at 4:00 AM, Adrian Hey wrote: > Neil Mitchell wrote: >>> 2) What does it do with duplicate elements in the list? I expect >>> it deletes >>> them. To avoid this, you'd need to use something like >>> fromListWith, keeping >>> track of how many duplicates there are, and expanding at the end. >> That would be wrong. Consider: >> data Foo = Foo Int Int >> instance Ord Foo where >> compare (Foo a _) (Foo b _) = compare a b > > I would consider such an Ord instance to be hopelessly broken, and I > don't think it's the responsibility of authors of functions with Ord > constraints in their sigs (such as sort) to consider such > possibilities > or specify and control the behaviour of their behaviour for such > instances. Trying to do this is what leads to horrors such as the > "left > biasing" of Data.Map (for example). Data.Map is implicitly using such an Ord instance behind the scenes, and I think it has to to maintain its own invariants. If I take the `union' of two maps that take the same key to different values, I have to decide which value to use, even if every Ord instance supplied by my clients is 100% Adrian-compliant. jcc From dave at zednenem.com Mon Mar 10 22:14:02 2008 From: dave at zednenem.com (David Menendez) Date: Mon Mar 10 22:11:12 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: <7383E6EC-83B6-4F28-98BA-0A187D0E52C5@fastmail.fm> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <220e47b40803091848u5925dbe9l261a7ca076f9069e@mail.gmail.com> <200803092304.02063.dan.doel@gmail.com> <404396ef0803100127p4e99997amf2e2a6d70dce6e8b@mail.gmail.com> <47D514C2.8050102@iee.org> <7383E6EC-83B6-4F28-98BA-0A187D0E52C5@fastmail.fm> Message-ID: <49a77b7a0803101914s21ea38a6w17557b058ca7e432@mail.gmail.com> On Mon, Mar 10, 2008 at 9:08 PM, Jonathan Cast wrote: > On 10 Mar 2008, at 4:00 AM, Adrian Hey wrote: > > > I would consider such an Ord instance to be hopelessly broken, and I > > don't think it's the responsibility of authors of functions with Ord > > constraints in their sigs (such as sort) to consider such > > possibilities > > or specify and control the behaviour of their behaviour for such > > instances. Trying to do this is what leads to horrors such as the > > "left > > biasing" of Data.Map (for example). > > Data.Map is implicitly using such an Ord instance behind the scenes, > and I think it has to to maintain its own invariants. If I take the > `union' of two maps that take the same key to different values, I > have to decide which value to use, even if every Ord instance > supplied by my clients is 100% Adrian-compliant. I think Adrian is just arguing that a == b should imply f a == f b, for all definable f, in which case it doesn't *matter* which of two equal elements you choose, because there's no semantic difference. (Actually, it's probably not desirable to require it for *all* definable functions, since an implementation might define e.g. an unsafe function that does pointer comparisons. We'd probably also exclude functions using a private, "internal" interface that exposes implementation details.) I like that property, and it bugs me when I have to use a datatype whose Eq instance doesn't have it (either because (==) throws away information or because the type exposes non-semantic information). So, if a == b, then sort [a,b] could return [a,a], [a,b], [b,a], or [b,b] at will, because there wouldn't be any way to distinguish those results in Haskell. This might have performance implications. You might have a case where a and b are equal, but have difference performance characteristics. I don't know what, if anything, is the best way to deal with that. This discussion feels like it should have a wiki page. -- Dave Menendez From ok at cs.otago.ac.nz Tue Mar 11 00:14:32 2008 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Tue Mar 11 00:12:01 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: <220e47b40803101627g795fc89fk4519d0f35493284b@mail.gmail.com> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <220e47b40803091848u5925dbe9l261a7ca076f9069e@mail.gmail.com> <200803092304.02063.dan.doel@gmail.com> <404396ef0803100127p4e99997amf2e2a6d70dce6e8b@mail.gmail.com> <404396ef0803100136s4f8d4bd0ub376095a747a2195@mail.gmail.com> <220e47b40803101627g795fc89fk4519d0f35493284b@mail.gmail.com> Message-ID: <45FB4809-0CB9-4CEB-8F60-0D8CC006F4D0@cs.otago.ac.nz> On 11 Mar 2008, at 12:27 pm, Krzysztof Skrz?tnicki wrote: > I've written little framework to work on. See sortbench.hs and > sortbench.py attachments. > Furthermore, I checked Yhc's implementation of sort: it is indeed > very fast: I took his earlier code and plugged yhc's sort into it. Compiling with ghc -O2 using GHC 6.8.2, I found the yhc code (basically variant of natural merge) to be considerably slower than some of the alternatives. There is a pretty obvious way to speed up the YHC code which you would expect to provide nearly a factor of two speedup, and with the random integer data, it does. However, there is one simple but extremely important point which must be considered in evaluating a sorting routine: the library 'sort' function is, or should be, a *general-purpose* sort. It should be useful with any data type which is an instance of Ord or for which you can write a `cmp` function, and it should work at least as well with already-sorted input as with randomised input. quicksort (whose original reason for existence was to sort on a machine whose memory would disgrace today's wristwatches) is well known for doing deceptively well on randomised integer sequences. When I run Krzystztof's test harness (which I have currently brought up to 25 different sorting functions) with a list of the form [1..N] instead of a random list, suddenly all the variants of merge sort come out ahead of all the variants of quick sort. In fact his best version of quicksort, qsort_iv, comes out fully 1155 times slower than the YHC algorithm on a list of 10,000 ordered integers. That can be improved by spending a bit of effort on choosing a good pivot, but then the quicksort algorithms are no longer so competitive for randomised inputs. The classic "Engineering a Quicksort" paper by Bentley and McIlroy from Software : Practice & Experience recommends a whole bunch of distribution shapes (one run, two runs, sawtooth, organ pipes, random, ...) that should be benchmarked before drawing too many conclusions. It is also wise to try more than one data type. How do the different algorithms compare on random samples from a Scrabble dictionary? (Why that particular question? Because I mean to try it.) Right now, I remain happy with merge sort, because it is never mysteriously several thousand times slower than expected. From chaddai.fouche at gmail.com Tue Mar 11 00:20:42 2008 From: chaddai.fouche at gmail.com (=?ISO-8859-1?Q?Chadda=EF_Fouch=E9?=) Date: Tue Mar 11 00:18:04 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: <49a77b7a0803101914s21ea38a6w17557b058ca7e432@mail.gmail.com> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <220e47b40803091848u5925dbe9l261a7ca076f9069e@mail.gmail.com> <200803092304.02063.dan.doel@gmail.com> <404396ef0803100127p4e99997amf2e2a6d70dce6e8b@mail.gmail.com> <47D514C2.8050102@iee.org> <7383E6EC-83B6-4F28-98BA-0A187D0E52C5@fastmail.fm> <49a77b7a0803101914s21ea38a6w17557b058ca7e432@mail.gmail.com> Message-ID: 2008/3/11, David Menendez : > I think Adrian is just arguing that a == b should imply f a == f b, > for all definable f, in which case it doesn't *matter* which of two > equal elements you choose, because there's no semantic difference. > > (Actually, it's probably not desirable to require it for *all* > definable functions, since an implementation might define e.g. an > unsafe function that does pointer comparisons. We'd probably also > exclude functions using a private, "internal" interface that exposes > implementation details.) > > I like that property, and it bugs me when I have to use a datatype > whose Eq instance doesn't have it (either because (==) throws away > information or because the type exposes non-semantic information). I completely agree that this propriety should be true for all Eq instance exported by a public module. I don't care if it is not the case in a isolated code, but libraries shouldn't break expected invariant (or at least be very cautious and warn the user). Even Eq Double respects this propriety as far as I know. Ord case is less evident, but assuming a propriety like (compare x y = EQ => x == y) seems like a reasonable guess. Doing it in a library (with a warning) doesn't seems all that bad to me. -- Jeda? From allbery at ece.cmu.edu Tue Mar 11 01:43:36 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Tue Mar 11 01:40:49 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <220e47b40803091848u5925dbe9l261a7ca076f9069e@mail.gmail.com> <200803092304.02063.dan.doel@gmail.com> <404396ef0803100127p4e99997amf2e2a6d70dce6e8b@mail.gmail.com> <47D514C2.8050102@iee.org> <7383E6EC-83B6-4F28-98BA-0A187D0E52C5@fastmail.fm> <49a77b7a0803101914s21ea38a6w17557b058ca7e432@mail.gmail.com> Message-ID: On Mar 11, 2008, at 0:20 , Chadda? Fouch? wrote: > 2008/3/11, David Menendez : >> I think Adrian is just arguing that a == b should imply f a == f b, >> for all definable f, in which case it doesn't *matter* which of two >> equal elements you choose, because there's no semantic difference. >> > I completely agree that this propriety should be true for all Eq > instance exported by a public module. I don't care if it is not the > case in a isolated code, but libraries shouldn't break expected > invariant (or at least be very cautious and warn the user). Even Eq > Double respects this propriety as far as I know. I wouldn't want to bet on that (Eq Double, that is). Floating point's just *evil*. -- 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 Tue Mar 11 02:34:46 2008 From: dons at galois.com (Don Stewart) Date: Tue Mar 11 02:32:05 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: <45FB4809-0CB9-4CEB-8F60-0D8CC006F4D0@cs.otago.ac.nz> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <220e47b40803091848u5925dbe9l261a7ca076f9069e@mail.gmail.com> <200803092304.02063.dan.doel@gmail.com> <404396ef0803100127p4e99997amf2e2a6d70dce6e8b@mail.gmail.com> <404396ef0803100136s4f8d4bd0ub376095a747a2195@mail.gmail.com> <220e47b40803101627g795fc89fk4519d0f35493284b@mail.gmail.com> <45FB4809-0CB9-4CEB-8F60-0D8CC006F4D0@cs.otago.ac.nz> Message-ID: <20080311063446.GB6728@scytale.galois.com> ok: > > On 11 Mar 2008, at 12:27 pm, Krzysztof Skrz?tnicki wrote: > > >I've written little framework to work on. See sortbench.hs and > >sortbench.py attachments. > >Furthermore, I checked Yhc's implementation of sort: it is indeed > >very fast: > > I took his earlier code and plugged yhc's sort into it. > Compiling with ghc -O2 using GHC 6.8.2, I found the yhc code (basically > variant of natural merge) to be considerably slower than some of the > alternatives. > > There is a pretty obvious way to speed up the YHC code which you would > expect to provide nearly a factor of two speedup, and with the random > integer data, it does. > > However, there is one simple but extremely important point which must be > considered in evaluating a sorting routine: the library 'sort' function > is, or should be, a *general-purpose* sort. It should be useful with > any > data type which is an instance of Ord or for which you can write a `cmp` > function, and it should work at least as well with already-sorted input > as with randomised input. quicksort (whose original reason for > existence > was to sort on a machine whose memory would disgrace today's > wristwatches) > is well known for doing deceptively well on randomised integer > sequences. > > When I run Krzystztof's test harness (which I have currently brought > up to > 25 different sorting functions) with a list of the form [1..N] instead > of > a random list, suddenly all the variants of merge sort come out ahead of > all the variants of quick sort. In fact his best version of quicksort, > qsort_iv, comes out fully 1155 times slower than the YHC algorithm on a > list of 10,000 ordered integers. That can be improved by spending a bit > of effort on choosing a good pivot, but then the quicksort algorithms > are > no longer so competitive for randomised inputs. > > The classic "Engineering a Quicksort" paper by Bentley and McIlroy from > Software : Practice & Experience recommends a whole bunch of > distribution > shapes (one run, two runs, sawtooth, organ pipes, random, ...) that > should > be benchmarked before drawing too many conclusions. > > It is also wise to try more than one data type. How do the different > algorithms compare on random samples from a Scrabble dictionary? (Why > that particular question? Because I mean to try it.) > > Right now, I remain happy with merge sort, because it is never > mysteriously > several thousand times slower than expected. Do you have these tests bundled up in a repository? It would be very useful to drop these into the base library testsuite, so we can point to this when needed. -- Don From ahey at iee.org Tue Mar 11 03:48:51 2008 From: ahey at iee.org (Adrian Hey) Date: Tue Mar 11 03:46:05 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: <7383E6EC-83B6-4F28-98BA-0A187D0E52C5@fastmail.fm> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <220e47b40803091848u5925dbe9l261a7ca076f9069e@mail.gmail.com> <200803092304.02063.dan.doel@gmail.com> <404396ef0803100127p4e99997amf2e2a6d70dce6e8b@mail.gmail.com> <47D514C2.8050102@iee.org> <7383E6EC-83B6-4F28-98BA-0A187D0E52C5@fastmail.fm> Message-ID: <47D63963.4050903@iee.org> Jonathan Cast wrote: > On 10 Mar 2008, at 4:00 AM, Adrian Hey wrote: > >> Neil Mitchell wrote: >>>> 2) What does it do with duplicate elements in the list? I expect it >>>> deletes >>>> them. To avoid this, you'd need to use something like fromListWith, >>>> keeping >>>> track of how many duplicates there are, and expanding at the end. >>> That would be wrong. Consider: >>> data Foo = Foo Int Int >>> instance Ord Foo where >>> compare (Foo a _) (Foo b _) = compare a b >> >> I would consider such an Ord instance to be hopelessly broken, and I >> don't think it's the responsibility of authors of functions with Ord >> constraints in their sigs (such as sort) to consider such possibilities >> or specify and control the behaviour of their behaviour for such >> instances. Trying to do this is what leads to horrors such as the "left >> biasing" of Data.Map (for example). > > Data.Map is implicitly using such an Ord instance behind the scenes, and > I think it has to to maintain its own invariants. If I take the `union' > of two maps that take the same key to different values, I have to decide > which value to use, even if every Ord instance supplied by my clients is > 100% Adrian-compliant. The biasing policy for Data.Map/Set is refering to (Set) elements, or (Map) keys, not the associated values (in a Map). So during an insertion op, if an "equal" element/key is found the Set/Map the biasing policy tells me which of the two "equal" elements/keys in incorporated in the resulting Set/Map. So there's an implied acceptance of the posibility that the choice is significant and that the two elements/keys can be both "equal" and "not equal" at the same time. This is crazy IMO. Implementors should not have to offer an guarantees about this and should be perfectly free to make their own unspecified choice regarding which of two "equal" values is used in any expression (on space efficiency grounds say). For example, the left biasing of insertion on Data.Set forces the implementation to burn O(log n) heap space creating a new "equal" set, even if the set already contains an old element that is "equal" to the new element. I would argue that in this situation it should be perfectly correct to simply return the old set instead. Regards -- Adrian Hey From ahey at iee.org Tue Mar 11 04:01:08 2008 From: ahey at iee.org (Adrian Hey) Date: Tue Mar 11 03:58:21 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: <404396ef0803101433s435bbc64j46617fe50ba46aa5@mail.gmail.com> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <47D52A87.9060805@iee.org> <404396ef0803100632w6ae183f3w467aa02bae40caa2@mail.gmail.com> <47D5416C.808@iee.org> <871w6i8wx4.fsf@nmd9999.imr.no> <47D55287.5040701@iee.org> <404396ef0803100829h44c8ac1dg4ee6f0132cb4f929@mail.gmail.com> <47D56B7A.2030200@iee.org> <220e47b40803101207w6d4bb795k68d959b3ccff9849@mail.gmail.com> <47D5A46A.5010800@iee.org> <404396ef0803101433s435bbc64j46617fe50ba46aa5@mail.gmail.com> Message-ID: <47D63C44.7070704@iee.org> Neil Mitchell wrote: > Hi > >> (sort [a,b]) in the case we have: (compare a b = EQ) >> >> Which of the following 4 possible results are correct/incorrect? >> 1- [a,a] >> 2- [a,b] >> 3- [b,a] >> 4- [b,b] > > Fortunately the Haskell sort is meant to be stable, I would have said it is meant to be *correct* first and *efficient* second. You're ruling out a whole bunch of possibly more efficient and correct sorts on the grounds that they may give observably different results for a tiny minority of (IMO broken) Eq/Ord instances. Wrt to *sortBy* (vs. *sort*), I would be inclined to agree with you. I sure hope someone has proven that the (apparently) different sortBy implementations provided by ghc,nhc and h98 library report are precisely equivalent for all (type legal) function arguments. This is also good reason for not hardwiring the definition of sort as.. sort = sortBy compare This is just one of many possible correct sorts (including trie based sorts). > and sorting is > meant to be a permutation, so we happily have the situation where this > has a correct answer: 2. > Anything else is incorrect. Isn't 3 also a permutation? Why is it incorrect? > Anyone submitting > a revised sort through the Haskell libraries process will have to > ensure the answer is 2. I hope someone does take the time to do this, > as a faster base library will benefit everyone. Agreed, for sortBy, but not sort. More generally different sortBys should give identical results even for "crazy" comparisons (like sortBy (\_ _ = EQ)) If that seems too severe, then maybe sortBy should be removed altogether (if there's no obvious single correct and best implementation). If this was done then sort would have to be an (abstractly specified) Ord class method. > Adrian: I think its fairly clear we disagree about these things. > However, we both understand the others point of view, so I guess its > just a question of opinion - and I doubt either of us will change. As > such I think any further discussion may just lead to sleep deprivation > [1]. I think I'm coming from a more discrete maths/theoretical > background while you are coming from a more practical/pragmatist > background. If the "discrete maths/theoretical" POV necessatates to the kind of biasing madness of Data.Map/Set (for example) then it *sucks* bigtime IMO :-) I've never understood precisely what "left biasing" means, and it seems clear that in the past 2 fairly experienced and competent Haskellers have between them failed to deliver an implementation that respects it's own "biasing" promises. I would say it's not certain that even now Data.Map is correct in this respect. Having tried this approach myself too (with the clone) I can confirm that *this way lies madness*, so in future I will not be making any effort to define or respect "sane", unambiguous and stable behaviour for "insane" Eq/Ord instances for any lib I produce or hack on. Instead I will be aiming for correctness and optimal efficiency on the assumption that Eq and Ord instances are sensible. Regards -- Adrian Hey From gtener at gmail.com Tue Mar 11 04:11:41 2008 From: gtener at gmail.com (=?ISO-8859-2?Q?Krzysztof_Skrz=EAtnicki?=) Date: Tue Mar 11 04:08:52 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: <45FB4809-0CB9-4CEB-8F60-0D8CC006F4D0@cs.otago.ac.nz> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <220e47b40803091848u5925dbe9l261a7ca076f9069e@mail.gmail.com> <200803092304.02063.dan.doel@gmail.com> <404396ef0803100127p4e99997amf2e2a6d70dce6e8b@mail.gmail.com> <404396ef0803100136s4f8d4bd0ub376095a747a2195@mail.gmail.com> <220e47b40803101627g795fc89fk4519d0f35493284b@mail.gmail.com> <45FB4809-0CB9-4CEB-8F60-0D8CC006F4D0@cs.otago.ac.nz> Message-ID: <220e47b40803110111v567cc157oeeed107c72a86916@mail.gmail.com> Are you really sure that your results are correct? I obviously did all my tests with -O2 on. Please rerun your tests on the new "framework". Also note that this one contains tests for three cases: - sorted - revsorted - randomized From previous results I can guess that with randomized input Yhc's code will be ~3 times slower then the fastest quicksort out there. But I'm not going to run O(n^2) algorithm to compare with O(n log n) - and this is the case for (rev?)sorted inputs. Christopher Skrz?tnicki On Tue, Mar 11, 2008 at 5:14 AM, Richard A. O'Keefe wrote: > > On 11 Mar 2008, at 12:27 pm, Krzysztof Skrz?tnicki wrote: > > > I've written little framework to work on. See sortbench.hs and > > sortbench.py attachments. > > Furthermore, I checked Yhc's implementation of sort: it is indeed > > very fast: > > I took his earlier code and plugged yhc's sort into it. > Compiling with ghc -O2 using GHC 6.8.2, I found the yhc code (basically > variant of natural merge) to be considerably slower than some of the > alternatives. > (...) > When I run Krzystztof's test harness (which I have currently brought > up to > 25 different sorting functions) with a list of the form [1..N] instead > of > a random list, suddenly all the variants of merge sort come out ahead of > all the variants of quick sort. In fact his best version of quicksort, > qsort_iv, comes out fully 1155 times slower than the YHC algorithm on a > list of 10,000 ordered integers. That can be improved by spending a bit > of effort on choosing a good pivot, but then the quicksort algorithms > are > no longer so competitive for randomised inputs. This paper looks interesting, I'm going to implement those tests. > > The classic "Engineering a Quicksort" paper by Bentley and McIlroy from > Software : Practice & Experience recommends a whole bunch of > distribution > shapes (one run, two runs, sawtooth, organ pipes, random, ...) that > should > be benchmarked before drawing too many conclusions. This is the right point. A further work will be to add different input generators to run them too. > It is also wise to try more than one data type. How do the different > algorithms compare on random samples from a Scrabble dictionary? (Why > that particular question? Because I mean to try it.) > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080311/a1018bcf/attachment.htm From Tom.Schrijvers at cs.kuleuven.be Tue Mar 11 04:20:41 2008 From: Tom.Schrijvers at cs.kuleuven.be (Tom Schrijvers) Date: Tue Mar 11 04:19:07 2008 Subject: [Haskell-cafe] Equality constraints in type families In-Reply-To: <7b92c2840803101651x3673691eid310ab137805eeff@mail.gmail.com> References: <7b92c2840803101651x3673691eid310ab137805eeff@mail.gmail.com> Message-ID: Hi Hugo, > I have encoded a type family such that: > > type family F a :: * -> * > > and a function (I know it is complicated, but I think the problem is self > explanatory): > > hyloPara :: (Functor (F a), Functor (F d), F d a ~ F a (a,a), F d c ~ F a > (c,a)) => d -> (F d c -> c) -> (a -> F d a) -> a -> c > hyloPara d g h = g . fmap (hyloPara d g h) . h > > it all works fine. > > However, if I change the declaration to (changed F d c for the > "supposedly equivalent" F a (c,a)): > > hyloPara :: (Functor (F a), Functor (F d), F d a ~ F a (a,a), F d c ~ F a > (c,a)) => d -> (F a (c,a) -> c) -> (a -> F d a) -> a -> c > > and I get > > Occurs check: cannot construct the infinite type: c = (c, a) > When generalising the type(s) for `hyloPara' > > This really messes up my notions on equality constraints, is it the expected > behavior? It would be essential for me to provide this definition. I think you've uncovered a bug in the type checker. We made the design choice that type functions with a higher-kinded result type must be injective with respect to the additional paramters. I.e. in your case: F x y ~ F u v <=> F x ~ F u /\ y ~ v So if we apply that to F d c ~ F a (c,a) we get: F d ~ F a /\ c ~ (c,a) where the latter clearly is an occurs-check error, i.e. there's no finite type c such that c = (c,a). So the error in the second version is justified. There should have been one in the latter, but the type checker failed to do the decomposition: a bug. What instances do you have for F? Are they such that F d c ~ F a (c,a) can hold? By the way, for your function, you don't need equations in your type signature. This will do: hyloPara :: Functor (F d) => d -> (F d c -> c) -> (a -> F d a) -> a -> c Cheers, Tom -- Tom Schrijvers Department of Computer Science K.U. Leuven Celestijnenlaan 200A B-3001 Heverlee Belgium tel: +32 16 327544 e-mail: tom.schrijvers@cs.kuleuven.be url: http://www.cs.kuleuven.be/~toms/ From simonpj at microsoft.com Tue Mar 11 05:15:06 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue Mar 11 05:12:23 2008 Subject: [Haskell-cafe] Where does ~> come from? In-Reply-To: <200802191122.23121.g9ks157k@acme.softbase.org> References: <404396ef0802170541o70a37be0x82123be1b95aa52a@mail.gmail.com> <200802191122.23121.g9ks157k@acme.softbase.org> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C323E58B5F9B@EA-EXMSG-C334.europe.corp.microsoft.com> | I think, it won?t find it. As Cale said, it?s a type variable. It?s like | the ?a? in the following definition: | | data T a = T a a | | I think, Conal Elliott used an operator type variable in order to make his | code more readable. The (~>) is a type parameter which stands for an arrow | type. I've been thinking for some time that GHC's current lexicographic choice about type variables, although consistent, is an mistake. (I say "GHC" because Haskell 98 does not have operator symbols in the type namespace at all.) As of today, a is a type variable T is a type constructor ~> is a type variable :~> is a type constructor That's consistent with the syntax for data constructors. But it's a pain. For a start (->) is a type constructor not a type variable. More important, it's just so right to declare a sum type like this data a + b = Left a | Right b f :: a -> (a+b) f = ... But GHC currently makes you say data a :+: b = Left a | Right b f :: a -> (a:+:b) I hate those colons! The obvious thing is to say that operator symbols (of all kinds) are type constructors, and only alphabetic things are type variables. That's less consistent, but I think it might be more useful. I was provoked to type this by realising that Conal, at least, is using an operator symbol (~>) as a type variable. I wonder how bad it'd be in this case to have to use an alphabetic name (backquotes still work). Just flying a kite here -- this isn't high on my list. But the more we do at the type level, the more we want type expressions that look sensible. Simon From ketil at malde.org Tue Mar 11 05:32:12 2008 From: ketil at malde.org (Ketil Malde) Date: Tue Mar 11 05:29:16 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: <220e47b40803101627g795fc89fk4519d0f35493284b@mail.gmail.com> ("Krzysztof =?utf-8?Q?Skrz=C4=99tnicki=22's?= message of "Tue\, 11 Mar 2008 00\:27\:56 +0100") References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <220e47b40803091848u5925dbe9l261a7ca076f9069e@mail.gmail.com> <200803092304.02063.dan.doel@gmail.com> <404396ef0803100127p4e99997amf2e2a6d70dce6e8b@mail.gmail.com> <404396ef0803100136s4f8d4bd0ub376095a747a2195@mail.gmail.com> <220e47b40803101627g795fc89fk4519d0f35493284b@mail.gmail.com> Message-ID: <87r6eh1u8z.fsf@nmd9999.imr.no> "Krzysztof Skrz?tnicki" writes: > The above results are for 1000000 Ints x 10 runs, but I don't expect any > drastic changes in longer run. I leave the interpretation up to you. Might I suggest (also) testing with numbers of smaller magnitude? Lots of collisions is another killer for the na?ve quicksort (albeit easily remedied, of course), and something a general sorting algorithm should handle. -k -- If I haven't seen further, it is by standing in the footprints of giants From oleg at okmij.org Tue Mar 11 06:44:06 2008 From: oleg at okmij.org (oleg@okmij.org) Date: Tue Mar 11 06:41:23 2008 Subject: [Haskell-cafe] Instance selection based on a class constraint [was: Issues(Bugs?) with GHC Type Families] Message-ID: <20080311104406.9E17DA9B2@Adric.metnet.fnmoc.navy.mil> > Manuel M T Chakravarty: > Hugo Pacheco: > > I would simply like the compiler not to use that instance if the > > equality constraint does not hold, like some another instance > > dependency constraint, but I assume that is not possible. > > This is independent of type families. The selection of type class > instances does *never* dependent on the instance context, only on the > instance head. I know that this is sometimes annoying, but type > checking would be a a lot more complicated/expensive without that rule. What Hugo Pacheco wants *is* possible, in GHC as it is (and even as it was back in 2004). Although the selection of type class instances indeed depends only on the instance head, on the surface, the dependence on context is quite easy to accomplish. Here's is the outline of the idea. Suppose we wish to select one of the two instances, depending on whether the constraint C x hold or not: instance C x => CMain x instance CMain x We encode this as follows: class CMain x instance (CPred x flag, CMain' flag x) => CMain x The main class has only one instance, and there is no longer any overlapping. The main selection is done in an auxiliary class class CMain' flag x instance CMain' HTrue x -- will be selected when CPred holds instance CMain' HFalse x -- otherwise Note there are no overlapping instances required. The trick is to re-write constraint C x into the form CPred x flag (where flag functionally depends on x). Whereas C x succeeds, CPred x flag should succeed and unify flag with HTrue. Should C x fail, CPred should still succeed and unify flag with HFalse. TypeEq is such a predicate in the case of type equality. CPred is easy to implement with type-classes, and probably even easier with type families. The HList and OOHaskell papers use this technique to great extent. The following message describes that even backtracking is possible: http://okmij.org/ftp/Haskell/poly2.txt From martin.hofmann at uni-bamberg.de Tue Mar 11 06:57:52 2008 From: martin.hofmann at uni-bamberg.de (Martin Hofmann) Date: Tue Mar 11 06:50:54 2008 Subject: [Haskell-cafe] Reflective capabilities of Haskell Message-ID: <1205233072.5722.19.camel@ios.cogsys.wiai.uni-bamberg.de> I am trying to port a programme written in Maude, which is a reflective language based on rewriting logic ( http://maude.cs.uiuc.edu/ ), to Haskell. I thought using Template Haskell might be a good idea, but I got stuck and now I am wondering if this is really possible in Haskell. Let me give an example of a Maude module defining the function last over a list of Peano numbers. fmod LAST is sorts Peano PeanoList . op 0 : -> Peano [ctor] . op s : Peano -> Peano [ctor] . op [] : -> PeanoList [ctor] . op cons : Peano PeanoList -> PeanoList [ctor] . op last : PeanoList -> Peano . vars X Y : Peano . var Xs : PeanoList . eq last(cons(X,[])) = X . eq last(cons(X,cons(Y,Xs))) = last(cons(Y,Xs)) . endfm So, last(cons(s(0),cons(s(s(0)),cons(s(s(s(0))),[])))) would reduce to s(s(s(0))). The cool thing about Maude is, that terms, modules, ... can be lifted to the meta level. For example: upModule('LAST, false) would yield From oleg at okmij.org Tue Mar 11 07:00:20 2008 From: oleg at okmij.org (oleg@okmij.org) Date: Tue Mar 11 06:57:39 2008 Subject: [Haskell-cafe] Exception handling when using STUArray Message-ID: <20080311110020.39215A9B2@Adric.metnet.fnmoc.navy.mil> Sterling Clover wrote: > there's no standard way that I know of besides "inspection" to > determine if code might throw an exception, and this is particularly > the case with the dreaded lazy IO of prelude functions. The following old message showed even two ways of doing exactly that -- in Haskell, with no external tools. Exceptions in types and exception-free programming http://www.haskell.org/pipermail/haskell/2004-June/014271.html The third way described in the message -- ensuring that exceptions will never occur -- was further developed as lightweight static capabilities. > And as per a recent discussion on libraries, it's still a royal pain > to catch IO exceptions in monads with an IO base. That is again very easy. Takusen uses a CaughtMonadIO -- which includes a wide range of monads: IO itself and various transformations of it. I am extensively using a variant written by Jesse Tov based on the Takusen's idea. His code defines two classes: EMonad and EMonadIO -- which enclose most of the interesting monads. The latter is the subclass of the former and also allows arbitrary IO (via liftIO). In either case, I use gthrow, gbracket, gcatch, ghandle, gfinally, etc. -- without even thinking which Monad I'm in and how error handling is actually implemented (via ErrorT or via IO exceptions). It works universally for most of monads of interest. From hpacheco at gmail.com Tue Mar 11 07:03:17 2008 From: hpacheco at gmail.com (Hugo Pacheco) Date: Tue Mar 11 07:00:27 2008 Subject: [Haskell-cafe] Equality constraints in type families In-Reply-To: References: <7b92c2840803101651x3673691eid310ab137805eeff@mail.gmail.com> Message-ID: <7b92c2840803110403k12ac62ccnad0084fcb470a9e3@mail.gmail.com> I know I do not need these constraints, it was just the simplest way I found to explain the problem. I have fought about that: I was not expecting F d c ~ F a (c,a) not mean that F d ~F a /\ c ~(c,a), I thought the whole family was "parameterized". If I encoded the family type family F a x :: * F d c ~ F a (c,a) would be semantically different, meaning that this "decomposition rule" does not apply? Thanks, hugo -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080311/3bb9c23f/attachment.htm From martin.hofmann at uni-bamberg.de Tue Mar 11 07:17:39 2008 From: martin.hofmann at uni-bamberg.de (Martin Hofmann) Date: Tue Mar 11 07:10:38 2008 Subject: [Haskell-cafe] Reflective capabilities of Haskell (cont'd) Message-ID: <1205234259.5722.26.camel@ios.cogsys.wiai.uni-bamberg.de> I am trying to port a programme written in Maude, which is a reflective language based on rewriting logic ( http://maude.cs.uiuc.edu/ ), to Haskell. I thought using Template Haskell might be a good idea, but I got stuck and now I am wondering if this is really possible in Haskell. Let me give an example of a Maude module defining the function last over a list of Peano numbers. fmod LAST is sorts Peano PeanoList . op 0 : -> Peano [ctor] . op s : Peano -> Peano [ctor] . op [] : -> PeanoList [ctor] . op cons : Peano PeanoList -> PeanoList [ctor] . op last : PeanoList -> Peano . vars X Y : Peano . var Xs : PeanoList . eq last(cons(X,[])) = X . eq last(cons(X,cons(Y,Xs))) = last(cons(Y,Xs)) . endfm So, last(cons(s(0),cons(s(s(0)),cons(s(s(s(0))),[])))) would reduce to s(s(s(0))). The cool thing about Maude is, that terms, modules, ... can be lifted to the meta level. For example: upModule('LAST, false) would yield fmod 'LAST is including 'BOOL . sorts 'Peano ; 'PeanoList . none op '0 : nil -> 'Peano [ctor] . op '`[`] : nil -> 'PeanoList [ctor] . op 'cons : 'Peano 'PeanoList -> 'PeanoList [ctor] . op 'last : 'PeanoList -> 'Peano [none] . op 's : 'Peano -> 'Peano [ctor] . none eq 'last['cons['X:Peano,'`[`].PeanoList]] = 'X:Peano [none] . eq 'last['cons['X:Peano,'cons['Y:Peano,'Xs:PeanoList]]] = last['cons[ 'Y:Peano,'Xs:PeanoList]] [none] . endfm I also have access, e.g. to the defined type constructors. So upOpDecls('LAST,false). yields op '0 : nil -> 'Peano [ctor] . op '`[`] : nil -> 'PeanoList [ctor] . op 'cons : 'Peano 'PeanoList -> 'PeanoList [ctor] . op 'last : 'PeanoList -> 'Peano [none] . op 's : 'Peano -> 'Peano [ctor] . Given an arbitrary function, I have access to its definition, its types and the type constructors, all as ADTs. Is this possible with Template Haskell, or in some other way? Thanks a lot, Martin From dave.a.tapley at gmail.com Tue Mar 11 07:13:40 2008 From: dave.a.tapley at gmail.com (Dave Tapley) Date: Tue Mar 11 07:10:51 2008 Subject: [Haskell-cafe] Re: Constructing Data.Map from ByteString In-Reply-To: References: Message-ID: Just a few updates on this one: I've upgraded to bytestring-0.9.0.5 from Darcs, no improvement. Also this morning I tried using Data.HashMap with Bytestring's readInt and HashMap's hashInt.. The result was a Stack space overflow :( God damn it I don't want to have to go back to C++ but soon will have no choice with time constraints :( Dave, On 10/03/2008, Dave Tapley wrote: > Hi all, > > I've been plugging away at this all day and some discussion in > #haskell has been fruitless. Perhaps you have the inspiration to see > what's happening! > > Concerning this minimal example: > http://hpaste.org/6268 > > It works as required, loading K/V pairs into a Data.Map, the concern > is the amount of memory used. Pausing (using a getLine) after the > readFile one can see (through 'ps v') that the whole file 'f' is > loaded in to memory. > However once the Map is created the memory footprint swells to around > five times the size. Surely this can't be just overhead from Map? > My reasoning was that by using ByteString and getting the whole file > into memory a small and linear increase would be seen for Map > overhead.. > > I have tried using both Data.ByteString.Char8 and > Data.ByteString.Lazy.Char8 with negligible difference. > For a hoot I tried it with String and yes, it's ridiculous :) > > Cheers, > > Dave > From lemming at henning-thielemann.de Tue Mar 11 07:43:00 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue Mar 11 07:39:02 2008 Subject: [Haskell-cafe] IO () and IO [()] In-Reply-To: <404396ef0803101517q25344eabxa8c7fc5f6f1220e8@mail.gmail.com> References: <11b141710803101511w5ac7894ch27bea31e1e277107@mail.gmail.com> <404396ef0803101517q25344eabxa8c7fc5f6f1220e8@mail.gmail.com> Message-ID: On Mon, 10 Mar 2008, Neil Mitchell wrote: >> I would like to know if in fact there's any difference in practice >> between (), [()], i.e. if in practice the difference matters. > > Usually, not so much. A lot of Monad functions have _ variants, i.e. > mapM and mapM_. If you don't need the result, use the mapM_ version, > as it will run faster and not space/stack leak in some circumstances. In my opinion, mapM_ and sequence_ are in the wrong class, because they do not need much of Monads, or even Functors. They could well live, say, in Data.Monoid class. However, it's hard to integrate that in a hierarchy of type classes. instance Monoid a => Monoid (M a) where mempty = return mempty mappend = liftM2 mappend where M is a monad type. From Tom.Schrijvers at cs.kuleuven.be Tue Mar 11 07:57:54 2008 From: Tom.Schrijvers at cs.kuleuven.be (Tom Schrijvers) Date: Tue Mar 11 07:56:07 2008 Subject: [Haskell-cafe] Equality constraints in type families In-Reply-To: <7b92c2840803110403k12ac62ccnad0084fcb470a9e3@mail.gmail.com> References: <7b92c2840803101651x3673691eid310ab137805eeff@mail.gmail.com> <7b92c2840803110403k12ac62ccnad0084fcb470a9e3@mail.gmail.com> Message-ID: On Tue, 11 Mar 2008, Hugo Pacheco wrote: > I know I do not need these constraints, it was just the simplest way I found > to explain the problem. > > I have fought about that: I was not expecting F d c ~ F a (c,a) not mean > that F d ~F a /\ c ~(c,a), I thought the whole family was "parameterized". > If I encoded the family > > type family F a x :: * > > F d c ~ F a (c,a) would be semantically different, meaning that this > "decomposition rule" does not apply? Correct. However, then you cannot write "Functor (F a)" because type functions must be fully applied. So either way you have a problem. Could you show the type instances for F you have (in mind)? This way we can maybe see whether what you want to is valid and the type checker could be adjusted to cope with it, or whether what you're trying to do would not be valid (in general). I have my suspicions about your mentioning of both Functor (F d) and Functor (F a) in the signature. Which implementation of fmap do you want? Or should they be both the same (i.e. F d ~ F a)? Cheers, Tom -- Tom Schrijvers Department of Computer Science K.U. Leuven Celestijnenlaan 200A B-3001 Heverlee Belgium tel: +32 16 327544 e-mail: tom.schrijvers@cs.kuleuven.be url: http://www.cs.kuleuven.be/~toms/ From hpacheco at gmail.com Tue Mar 11 10:39:26 2008 From: hpacheco at gmail.com (Hugo Pacheco) Date: Tue Mar 11 10:36:36 2008 Subject: [Haskell-cafe] Equality constraints in type families In-Reply-To: References: <7b92c2840803101651x3673691eid310ab137805eeff@mail.gmail.com> <7b92c2840803110403k12ac62ccnad0084fcb470a9e3@mail.gmail.com> Message-ID: <7b92c2840803110739u3afbfeeex1ba381959a074368@mail.gmail.com> Yes, I have tried both implementations at the start and solved it by choosing for the following: type family F a :: * -> * type FList a x = Either () (a,x) type instance F [a] = FList a instance (Functor (F [a])) where fmap _ (Left _) = Left () fmap f (Right (a,x)) = Right (a,f x) The option was: type family F a x :: * type instance F [a] x = Either() (a,x) instance (Functor (F [a])) where -- error, not enough parameters passed to F fmap _ (Left _) = Left () fmap f (Right (a,x)) = Right (a,f x) So, indeed, with either implementation I have a problem. >I have my suspicions about your mentioning of both Functor (F d) and >Functor (F a) in the signature. Which implementation of fmap do you want? >Or should they be both the same (i.e. F d ~ F a)? This is an hard question to which the answer is both. In the definition of an hylomorphism I want the fmap from (F d): hylo :: (Functor (F d)) => d -> (F d c -> c) -> (a -> F d a) -> a -> c hylo d g h = g . fmap (hylo d g h) . h However, those constraints I have asked about would allow me to encode a paramorphism as an hylomorphism: class Mu a where inn :: F a a -> a out :: a -> F a a para :: (Mu a, Functor (F a),Mu d, Functor (F d),F d a ~ F a (a,a), F d c ~ F a (c,a)) => d -> (F a (c,a) -> c) -> a -> c para d f = hylo d f (fmap (id /\ id) . out) In para, I would want the fmap from (F a) but that would be implicitly forced by the usage of out :: a -> F a a Sorry for all the details, ignore them if they are too confusing. Do you think there might be a definition that would satisfy me both Functor instances and equality? Thanks for your pacience, hugo -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080311/ff319b2c/attachment.htm From dbueno at gmail.com Tue Mar 11 11:46:19 2008 From: dbueno at gmail.com (Denis Bueno) Date: Tue Mar 11 11:43:41 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: <47D63C44.7070704@iee.org> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <47D5416C.808@iee.org> <871w6i8wx4.fsf@nmd9999.imr.no> <47D55287.5040701@iee.org> <404396ef0803100829h44c8ac1dg4ee6f0132cb4f929@mail.gmail.com> <47D56B7A.2030200@iee.org> <220e47b40803101207w6d4bb795k68d959b3ccff9849@mail.gmail.com> <47D5A46A.5010800@iee.org> <404396ef0803101433s435bbc64j46617fe50ba46aa5@mail.gmail.com> <47D63C44.7070704@iee.org> Message-ID: <6dbd4d000803110846k3fcb94a8k9ad780c2dd8272fc@mail.gmail.com> On Tue, Mar 11, 2008 at 4:01 AM, Adrian Hey wrote: > > and sorting is > > meant to be a permutation, so we happily have the situation where this > > has a correct answer: 2. > > > Anything else is incorrect. > > Isn't 3 also a permutation? Why is it incorrect? Because it is not stable. The documentation for Data.List.sort says the sort is stable: "The sort function implements a stable sorting algorithm." A stable sort respects the order of equal elements as they occur in the input list. -- Denis From agl at imperialviolet.org Tue Mar 11 12:11:03 2008 From: agl at imperialviolet.org (Adam Langley) Date: Tue Mar 11 12:08:13 2008 Subject: [Haskell-cafe] Constructing Data.Map from ByteString In-Reply-To: References: Message-ID: <396556a20803110911t39e48e74ub50a06b90166c4af@mail.gmail.com> On Mon, Mar 10, 2008 at 4:33 PM, Dave Tapley wrote: > Concerning this minimal example: > http://hpaste.org/6268 Change the Data.ByteString.Char8 to Data.ByteString.Lazy.Char8, also the takeWhile, dropWhile pair is better expressed using span. With those two changes, and a 150MB test file, a compiled binary is using about 220MB of resident space. That seems pretty reasonable to me. As a purely subjective atheistic point: importing some modules qualified will help your sanity. Otherwise you have lots of common function names (readFile etc) and you have to try and figure out which module they are going to resolve into all the time! Cheers, AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org From phil at kantaka.co.uk Tue Mar 11 12:18:05 2008 From: phil at kantaka.co.uk (Philip Armstrong) Date: Tue Mar 11 12:15:16 2008 Subject: [Haskell-cafe] Constructing Data.Map from ByteString In-Reply-To: References: Message-ID: <20080311161805.GA10277@kantaka.co.uk> On Mon, Mar 10, 2008 at 11:33:58PM +0000, Dave Tapley wrote: >I've been plugging away at this all day and some discussion in >#haskell has been fruitless. Perhaps you have the inspiration to see >what's happening! > >Concerning this minimal example: >http://hpaste.org/6268 > >It works as required, loading K/V pairs into a Data.Map, the concern >is the amount of memory used. Pausing (using a getLine) after the >readFile one can see (through 'ps v') that the whole file 'f' is >loaded in to memory. >However once the Map is created the memory footprint swells to around >five times the size. Surely this can't be just overhead from Map? >My reasoning was that by using ByteString and getting the whole file >into memory a small and linear increase would be seen for Map >overhead.. Just looking at the code, I'd guess that it's making at least three copies of the data in total, plus Map overhead, so five times larger before garbage collection isn't completely outrageous. (Unless my intuition of what ByteString is doing is completely off-base of course.) Don't forget that Map construction is lazy in its value argument by default: Lots of potential for thunks to hang around the place. >I have tried using both Data.ByteString.Char8 and >Data.ByteString.Lazy.Char8 with negligible difference. For a hoot I >tried it with String and yes, it's ridiculous :) Strings won't help, since you're modifying the data, so you get to pay the string overhead without getting any sharing advantage from the String list implementation. You might do better feeding the input to a proper parser to build the map -- At least then you'd only be copying the input ByteString data once. I don't think you can do much better than that in an immutable world. Phil -- http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt From Tom.Schrijvers at cs.kuleuven.be Tue Mar 11 12:29:05 2008 From: Tom.Schrijvers at cs.kuleuven.be (Tom Schrijvers) Date: Tue Mar 11 12:27:22 2008 Subject: [Haskell-cafe] Equality constraints in type families In-Reply-To: <7b92c2840803110739u3afbfeeex1ba381959a074368@mail.gmail.com> References: <7b92c2840803101651x3673691eid310ab137805eeff@mail.gmail.com> <7b92c2840803110403k12ac62ccnad0084fcb470a9e3@mail.gmail.com> <7b92c2840803110739u3afbfeeex1ba381959a074368@mail.gmail.com> Message-ID: On Tue, 11 Mar 2008, Hugo Pacheco wrote: > Yes, I have tried both implementations at the start and solved it by > choosing for the following: > type family F a :: * -> * > type FList a x = Either () (a,x) > type instance F [a] = FList a > > instance (Functor (F [a])) where > fmap _ (Left _) = Left () > fmap f (Right (a,x)) = Right (a,f x) For this implementation we do have that F [a] b ~ F [c] d <=> F [a] ~ F [c] /\ b ~ d Right? So for this instance, your para via hylo wouldn't work anyway. I'd like to see some type instances and types such that the equation F d a ~ F a (a,a) holds. With your example above, it's not possible to make the equation hold, .e.g. F [t] [s] ~ F [s] ([s],[s]) <=> Either () (t,[s]) ~ Either ()(s,([s],[s])) is not true for any (finite) types t and s. Do you have such an example? You should have one, if you want to be able to call para. Tom >> I have my suspicions about your mentioning of both Functor (F d) and >> Functor (F a) in the signature. Which implementation of fmap do you want? >> Or should they be both the same (i.e. F d ~ F a)? > > This is an hard question to which the answer is both. > > In the definition of an hylomorphism I want the fmap from (F d): > > hylo :: (Functor (F d)) => d -> (F d c -> c) -> (a -> F d a) -> a -> c > hylo d g h = g . fmap (hylo d g h) . h > > However, those constraints I have asked about would allow me to encode a > paramorphism as an hylomorphism: > > class Mu a where > inn :: F a a -> a > out :: a -> F a a > > para :: (Mu a, Functor (F a),Mu d, Functor (F d),F d a ~ F a (a,a), F d c ~ > F a (c,a)) => d -> (F a (c,a) -> c) -> a -> c > para d f = hylo d f (fmap (id /\ id) . out) > > In para, I would want the fmap from (F a) but that would be implicitly > forced by the usage of out :: a -> F a a > > Sorry for all the details, ignore them if they are too confusing. > Do you think there might be a definition that would satisfy me both Functor > instances and equality? > > Thanks for your pacience, > hugo > -- Tom Schrijvers Department of Computer Science K.U. Leuven Celestijnenlaan 200A B-3001 Heverlee Belgium tel: +32 16 327544 e-mail: tom.schrijvers@cs.kuleuven.be url: http://www.cs.kuleuven.be/~toms/ From ahey at iee.org Tue Mar 11 12:20:16 2008 From: ahey at iee.org (Adrian Hey) Date: Tue Mar 11 13:15:12 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: <6dbd4d000803110846k3fcb94a8k9ad780c2dd8272fc@mail.gmail.com> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <47D5416C.808@iee.org> <871w6i8wx4.fsf@nmd9999.imr.no> <47D55287.5040701@iee.org> <404396ef0803100829h44c8ac1dg4ee6f0132cb4f929@mail.gmail.com> <47D56B7A.2030200@iee.org> <220e47b40803101207w6d4bb795k68d959b3ccff9849@mail.gmail.com> <47D5A46A.5010800@iee.org> <404396ef0803101433s435bbc64j46617fe50ba46aa5@mail.gmail.com> <47D63C44.7070704@iee.org> <6dbd4d000803110846k3fcb94a8k9ad780c2dd8272fc@mail.gmail.com> Message-ID: <47D6B140.4010002@iee.org> Denis Bueno wrote: > On Tue, Mar 11, 2008 at 4:01 AM, Adrian Hey wrote: >> > and sorting is >> > meant to be a permutation, so we happily have the situation where this >> > has a correct answer: 2. >> >> > Anything else is incorrect. >> >> Isn't 3 also a permutation? Why is it incorrect? > > Because it is not stable. > > The documentation for Data.List.sort says the sort is stable: > > "The sort function implements a stable sorting algorithm." > > A stable sort respects the order of equal elements as they occur in > the input list. This might be a reasonable thing to say about *sortBy*, but not sort as the ordering of equal elements should not be observable (for any correct instance of Ord). It should be impossible to implement a function which can discriminate between [a,a],[a,b],[b,a],[b,b] if compare a b = EQ. So really I think the docs have this backwards. It's sortBy that implements a stable sort (assuming a suitably sane comparison function I guess) and apparently sort is whatever you get from (sortBy compare). But this is unduly restrictive on possible correct sort implementations IMO. Regards -- Adrian Hey From hpacheco at gmail.com Tue Mar 11 13:21:43 2008 From: hpacheco at gmail.com (Hugo Pacheco) Date: Tue Mar 11 13:18:55 2008 Subject: [Haskell-cafe] Equality constraints in type families In-Reply-To: References: <7b92c2840803101651x3673691eid310ab137805eeff@mail.gmail.com> <7b92c2840803110403k12ac62ccnad0084fcb470a9e3@mail.gmail.com> <7b92c2840803110739u3afbfeeex1ba381959a074368@mail.gmail.com> Message-ID: <7b92c2840803111021s556497d9yae1fc1b0a6a8ba46@mail.gmail.com> That's simple Tom. Imagine the factorial function for Int written as a paramorphism: type instance F Int = Either One instance (Mu Int) where inn (Left _) = 0 inn (Right n) = succ n out 0 = Left () out n = Right (pred n) instance Functor (F Int) where fmap _ (Left ()) = Left () fmap f (Right n) = Right (f n) fact :: Int -> Int fact = para (const 1 \/ (uncurry (*)) . (id >< succ)) If we consider that the paramorphism is implemented as an hylomorphism, then an intermediate virtual type (d in the hylo definition) [Int] If you test the constraints for d = [Int], a = Int and c = Int F d c ~ F a (c,a) F d a = F [Int] Int = Either One (Int,Int) F a (c,a) = F Int (Int,Int) = Either One (Int,Int) F d a ~ F a (a,a) F d a = F a (a,a) -- pure substitution of the above case Hope this helps. Thanks again for you patience, hugo -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080311/ab244775/attachment.htm From sebastian.sylvan at gmail.com Tue Mar 11 14:13:21 2008 From: sebastian.sylvan at gmail.com (Sebastian Sylvan) Date: Tue Mar 11 14:10:34 2008 Subject: [Haskell-cafe] Re: [GSoC] A data parallel physics engine In-Reply-To: <9495446E-9F60-40CF-842E-1C1F4BFED055@cse.unsw.edu.au> References: <20080310143002.GA30015@home.ro-che.info> <9495446E-9F60-40CF-842E-1C1F4BFED055@cse.unsw.edu.au> Message-ID: <3d96ac180803111113v36cfcb02s1039ad862db17ef9@mail.gmail.com> On Mon, Mar 10, 2008 at 11:48 PM, Manuel M T Chakravarty < chak@cse.unsw.edu.au> wrote: > Roman Cheplyaka: > > I'm looking for interesting project to work on during Google Summer of > > Code. So I found [1]"A data parallel physics engine" ticket and got > > excited about it. I'd like to know interested mentors and community > > opinion about the complexity of such project. > > > > I have not very deep knowledge about both NDP and physics engines. Is > > it feasible to learn all the necessary stuff during these 2 month > > before > > SoC starts? > > > > 1. http://hackage.haskell.org/trac/summer-of-code/ticket/1535 > > Using NDP is actually pretty easy, that is, for somebody who is > already used to functional programming. The idea is, for anything you > want to have running in parallel, don't use explicit recursion, but > use list comprehensions (well, array comprehensions, but it's the same > idea) and combinators like mapP, foldP, scanP, etc (which are also > like their list variants). Here, for example, is quicksort: > > > qsort :: Ord a => [:a:] -> [:a:] > > qsort [::] = [::] > > qsort xs = let > > m = xs!:0 > > ss = [:x | x <- xs, x < m:] > > ms = [:x | x <- xs, x == m:] > > gs = [:x | x <- xs, x > m:] > > qs = [:qsort ys | ys <- [:ss, gs:]:] > > in > > qs!:0 +:+ ms +:+ qs!:1 > > where [:a:] is the type of arrays of as, [::] is an empty array, [: .. > | .. :] are array comprehensions, (!:) is array indexing, and (+:+) > array concatenation. The only funny thing is the bindings of qs, > where we put ss and gs into an array and apply qsort recursively > *inside* an array comprehension. This is so that the two recursive > calls to qsort happen in parallel. > > Getting good parallel performance is the tricky bit, but in a project > like the physics engine for GSoC, a basic parallelisation strategy is > sufficient and performance can then be improved incrementally. We > don't expect anybody to implement a fully-fledged, fully parallelised, > high-performance physics engine during GSoC. It is rather about > laying a solid foundation on which we can then build over time. (GSoC > is a lot about getting exciting open source projects of the ground, > not about producing a polished product that doesn't change anymore > after GSoC.) > > Besides, there is more to physics engines than just collision > detection. Another aspect is physical simulations of non-solid > bodies, such as liquids and cloth - re the latter, see < > http://graphics.snu.ac.kr/~kjchoi/publication/cloth.pdf > > for an interesting SIGGRAPH paper. What aspect we'd cover in the > GSoC project would really be a matter of what you are most interested > in. > There are a variety of approximate fluid simulation techniques (see SIGGRAPH, GDC papers etc., for example you could do the heightfield based approach, that simplifies the equations by working in 2D -- this runs in realtime on most decent hardware!) that aren't too complicated to implement, but looks really really cool. So I'd recommend doing something in that area because it's a "high coolness factor per unit time spent coding" kind of thing :-) -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080311/15cd585f/attachment.htm From donn at avvanta.com Tue Mar 11 14:27:39 2008 From: donn at avvanta.com (Donn Cave) Date: Tue Mar 11 14:24:48 2008 Subject: [Haskell-cafe] Exception handling when using STUArray In-Reply-To: <989AC059-9B60-40A1-9ECF-2CC9AC47D19E@fastmail.fm> References: <87wsod6ax8.fsf@columbia.edu> <6dbd4d000803080631s5d16e43cr7f7b2623c932b175@mail.gmail.com> <989AC059-9B60-40A1-9ECF-2CC9AC47D19E@fastmail.fm> Message-ID: On Mar 10, 2008, at 5:48 PM, Jonathan Cast wrote: > > On 10 Mar 2008, at 12:37 AM, Donn Cave wrote: ... >> >> An exception is, for me, any state that isn't properly accounted >> for in its >> immediate context. openFile could return 'Maybe Handle', but it >> doesn't, >> so the context demands a Handle or an exception. > > In the context of this discussion, `Maybe Handle' /is/ an exception > type, because Maybe is an exception monad. As is IO. This > distinction is one between an unusual-but-anticipated code path, > and a case the programmer simply didn't handle at all. The former > is an exception; the latter is an error. I am not sure I understand what you're saying. `Error' may be open to interpretation, but `exception' has a fairly unambiguous technical meaning in Haskell, a non-local flow of control with associated data type in Control.Exception. That flow of control involves `exception handlers', so named in the documentation, so if I install an exception handler in location that can intercept the exception, then you can't really say no one handled it, without some violence to the language. An exception, in the technical sense of the word, really can only be handled somewhere else, other than the exact location the exception was thrown, that being the nature and intent of non-local flow of control. What I'm trying to bring to this is that if we can let go of our fastidious notions about Maybe and Either and embrace what appears to be the reality of exceptions in Haskell that are more or less like other languages, then we'll be pleased at the improvement in the code. Here's a function I wrote a couple weeks ago while playing around with LDAP. I have read this ByteString from a socket, and verified that it's complete - it's all BER length encoded data, and the string is of the length specified in its length tag. Now I start breaking it down, according to my understanding of the Basic Encoding Rules and LDAP. The `berList' function handles the BER part, and this is the first LDAP step: readLDAPMessage s = let [(_, msgID), (tag, body)] = berList s in LDAPMessage (berInt msgID) (readResponse tag body) I go on to account for all the LDAP stuff I need in about 60 lines of that kind of thing, 1/3 of it devoted to declarations of the data types, and it isn't dense code, it's ... essentially declarative, in a simple, straightforward way, almost as if I copied it directly from the RFC. Is it `total'? No way! To get there, it seems to me I'd have to double the code, and significantly distract from its real sense. If there were anything to be gained, sure it's worth the price, but there isn't! Recall that this data comes from a socket. On the other end, anyone who cares about survival has an exception handler. I could gather up layers of Lefts and Rights and return a Left blah, and it really only adds another failure mode for the caller. I'm not saying Either is bad - I do use it like this, when it seems to be called for, but I'm very glad that it isn't the only way to deal with errors originating in functional code. I had the contrary impression from a discussion some years back, where I see now in review I may have conflated what you can't do in Haskell 98, with what you can't do in pure code for theoretical reasons. (Though I'm not saying that the argument for the latter was persuasive. I think handing exceptions in pure code is just the next step.) Donn Cave, donn@avvanta.com From derek at solidmath.com Tue Mar 11 14:54:55 2008 From: derek at solidmath.com (Derek Gladding) Date: Tue Mar 11 14:52:46 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <220e47b40803091848u5925dbe9l261a7ca076f9069e@mail.gmail.com> <200803092304.02063.dan.doel@gmail.com> <404396ef0803100127p4e99997amf2e2a6d70dce6e8b@mail.gmail.com> <47D514C2.8050102@iee.org> <7383E6EC-83B6-4F28-98BA-0A187D0E52C5@fastmail.fm> <49a77b7a0803101914s21ea38a6w17557b058ca7e432@mail.gmail.com> Message-ID: <47D6D57F.5030707@solidmath.com> Speaking as someone who often has to answer questions along the lines of "why isn't my code generating the results I want on your system?", I wouldn't call it evil, just "commonly mistaken for Real". NaN breaks most assumptions about ordering: (NaN <= _) == false (NaN == _) == false (NaN >= _) == false It doesn't even compare equal to a bitwise copy of itself. This would imply that it's impossible to write a stable sort for (IEEE) floating-point types. x < (x+n) (and variations thereof) does not always hold either. - Derek Brandon S. Allbery KF8NH wrote: > > On Mar 11, 2008, at 0:20 , Chadda? Fouch? wrote: > >> 2008/3/11, David Menendez : >>> I think Adrian is just arguing that a == b should imply f a == f b, >>> for all definable f, in which case it doesn't *matter* which of two >>> equal elements you choose, because there's no semantic difference. >>> >> I completely agree that this propriety should be true for all Eq >> instance exported by a public module. I don't care if it is not the >> case in a isolated code, but libraries shouldn't break expected >> invariant (or at least be very cautious and warn the user). Even Eq >> Double respects this propriety as far as I know. > > I wouldn't want to bet on that (Eq Double, that is). Floating point's > just *evil*. > From rturk at science.uva.nl Tue Mar 11 16:33:33 2008 From: rturk at science.uva.nl (Remi Turk) Date: Tue Mar 11 16:30:45 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <220e47b40803091848u5925dbe9l261a7ca076f9069e@mail.gmail.com> <200803092304.02063.dan.doel@gmail.com> <404396ef0803100127p4e99997amf2e2a6d70dce6e8b@mail.gmail.com> <47D514C2.8050102@iee.org> <7383E6EC-83B6-4F28-98BA-0A187D0E52C5@fastmail.fm> <49a77b7a0803101914s21ea38a6w17557b058ca7e432@mail.gmail.com> Message-ID: <20080311203332.GA4233@krikkit.lan> On Tue, Mar 11, 2008 at 01:43:36AM -0400, Brandon S. Allbery KF8NH wrote: > On Mar 11, 2008, at 0:20 , Chadda? Fouch? wrote: >> 2008/3/11, David Menendez : >>> I think Adrian is just arguing that a == b should imply f a == f b, >>> for all definable f, in which case it doesn't *matter* which of two >>> equal elements you choose, because there's no semantic difference. >>> >> I completely agree that this propriety should be true for all Eq >> instance exported by a public module. I don't care if it is not the >> case in a isolated code, but libraries shouldn't break expected >> invariant (or at least be very cautious and warn the user). Even Eq >> Double respects this propriety as far as I know. > > I wouldn't want to bet on that (Eq Double, that is). Floating point's just > *evil*. I wouldn't bet on it either: Prelude> 0.0 == -0.0 True Prelude> isNegativeZero 0.0 == isNegativeZero (-0.0) False Although isNegativeZero might be considered a ``private, "internal" interface that exposes implementation details.'' Groeten, Remi From michael at schmong.org Tue Mar 11 18:46:20 2008 From: michael at schmong.org (michael@schmong.org) Date: Tue Mar 11 18:43:29 2008 Subject: [Haskell-cafe] An offer to any haskell projects out there. Message-ID: <20080311224620.GA31622@schmong.org> Hello, My name is Michael Litchard. I'm a techie living in silicon valley, and I want to move into tech writing. I've got the background, now I need a portfolio. I figured the best way to go is to attach myself to some open source projects, and haskell has had my heart for a few years now. I am by no means an expert at haskell. My expertise is writing. So I make this offer. If you need documentation written for your haskell project, I'm your man. Whatever it is, I'll write it or edit it. Thanks for your time. P.S If this was the wrong list, or if anyone has other ideas about how to propogate my proposal, please let me know. Michael From agl at imperialviolet.org Tue Mar 11 19:51:27 2008 From: agl at imperialviolet.org (Adam Langley) Date: Tue Mar 11 19:48:36 2008 Subject: [Haskell-cafe] Re: Constructing Data.Map from ByteString In-Reply-To: References: Message-ID: <396556a20803111651i35f38a30v9b2ee798bf9baa57@mail.gmail.com> On Tue, Mar 11, 2008 at 4:13 AM, Dave Tapley wrote: > I've upgraded to bytestring-0.9.0.5 from Darcs, no improvement. > Also this morning I tried using Data.HashMap with Bytestring's readInt > and HashMap's hashInt.. The result was a Stack space overflow :( Map is probably a better choice than HashMap. Exactly how large is the input? Like I said, I got about 2x bloat (measured by RSS), maybe you can send a fuller example code? AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org From valgarv at gmx.net Tue Mar 11 19:52:57 2008 From: valgarv at gmx.net (askyle) Date: Tue Mar 11 19:50:04 2008 Subject: [Haskell-cafe] A question about "monad laws" Message-ID: <15975734.post@talk.nabble.com> > My favorite presentation of the monad laws is associativity of Kliesli > composition: > (a1 >=> a2) x = a1 x >>= a2 -- predefined in 6.8 control.monad > -- The laws > return >=> a = a > a >=> return = a > a >=> (b >=> c) = (a >=> b) >=> c If you use this presentation you also need the following law: (a . b) >=> c = (a >=> c) . b that is, compatibility with ordinary function composition. I like to call this "naturality", since it's instrumental in proving return and bind to be natural transformations. The law looks less alien if we use a flipped version of (>=>): (<=<) = flip (>=>) {- Monad Laws in terms of (<=<) -} return <=< f = f <=< return = f -- Identity f <=< (g <=< h) = (f <=< g) <=< h -- Associativity f <=< (g . h) = (f <=< g) . h -- Naturality (which happens to be my favorite presentation of the laws, followed by the derivations that lead to the 'do' notation, which lead to various 'ah' moments from unsuspecting FP-challenged friends) ----- Ariel J. Birnbaum -- View this message in context: http://www.nabble.com/A-question-about-%22monad-laws%22-tp15411587p15975734.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. From valgarv at gmx.net Tue Mar 11 19:53:42 2008 From: valgarv at gmx.net (askyle) Date: Tue Mar 11 19:50:51 2008 Subject: [Haskell-cafe] A question about "monad laws" In-Reply-To: References: <47B06B3B.2070504@cs.tcd.ie> <90533B63-96C0-4982-A695-8A217A61BBC2@cs.otago.ac.nz> <47B39936.10509@cse.unsw.edu.au> <6A400340-AA2D-47F9-9552-EAAED17F6403@cs.otago.ac.nz> <47B3CB1D.6040404@cse.unsw.edu.au> <47B408B2.3090900@cse.unsw.edu.au> Message-ID: <15976463.post@talk.nabble.com> I'm not sure whether this is the right branch of the thread for this post. Maybe it belongs to a different thread altogether. But here goes: Maybe most of our gripes with floating point arithmetic (besides broken implementations) is that we expect it to behave like Real arithmetic, and when it doesn't, we whine that it's unreliable, ill-defined, etc etc etc. If we consider FP as a mathematical entity of its own (e.g as defined in IEEE 754), we see that it has a well-defined, reliable behaviour which happens to emulate the behaviour of the real numbers within some margins. The accuracy of this emulation can be analyzed in a rigorous manner, see http://www.validlab.com/goldberg/paper.pdf So if floating point (==) doesn't correspond with numeric equality, it's not FP's fault, but ours for expecting it to do! By the way, IEEE754 does define another comparison operator which corresponds to our notion of 'equality'. FP (==) is just a partial equivalence relation which makes more sense than mathematical equality in an FP context. Of course, if an implementation doesn't guarantee that 'x == x' yields true whenever x is not a NaN, then the implementation is broken. An earlier post said that "Haskell is not math" (or something like it). I beg to differ -- one of its selling points, after all, is supposed to be the ability to perform equational reasoning. We work hard to give well-defined semantics to our expressions. We rely on types to tell us which properties to expect of which values, and which manipulations are valid. But then Haskell goes and fools us (just like most other languages do) into thinking FP arithmetic is something that it's not: the behaviour of operations depends on an unseen environment (e.g. rounding mode), the order of evaluation matters, evaluation can fail... not at all what we'd call purely functional! So if FP arithmetic is not purely functional, what do we do? If we could do Haskell all over again, I'd propose a different approach to FP arithmetic (and for stuff like Int, for that matter), which I'm actually surprised not to see discussed more often since it's after all the usual Haskell approach to things which are not purely functional. The original topic of this thread should already have hinted at it. ;) ----- Ariel J. Birnbaum -- View this message in context: http://www.nabble.com/A-question-about-%22monad-laws%22-tp15411587p15976463.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. From dons at galois.com Tue Mar 11 20:31:30 2008 From: dons at galois.com (Don Stewart) Date: Tue Mar 11 20:28:54 2008 Subject: [Haskell-cafe] Constructing Data.Map from ByteString In-Reply-To: References: Message-ID: <20080312003130.GG8667@scytale.galois.com> dave.a.tapley: > Hi all, > > I've been plugging away at this all day and some discussion in > #haskell has been fruitless. Perhaps you have the inspiration to see > what's happening! > > Concerning this minimal example: > http://hpaste.org/6268 > > It works as required, loading K/V pairs into a Data.Map, the concern > is the amount of memory used. Pausing (using a getLine) after the > readFile one can see (through 'ps v') that the whole file 'f' is > loaded in to memory. > However once the Map is created the memory footprint swells to around > five times the size. Surely this can't be just overhead from Map? > My reasoning was that by using ByteString and getting the whole file > into memory a small and linear increase would be seen for Map > overhead.. > > I have tried using both Data.ByteString.Char8 and > Data.ByteString.Lazy.Char8 with negligible difference. > For a hoot I tried it with String and yes, it's ridiculous :) Speaking to you on #haskell we worked out that the keys are integers, and elements can be bytestrings, so an IntMap ByteString seems like a good idea. The attached builds the Map directly (avoiding the lines splitting of the file), and seems to use around half the heap of the generic Map. It also builds much faster. Still, for big data, I'm not sure that a more specialised structure wouldn't be better. -- Don -------------- next part -------------- {-# OPTIONS -fbang-patterns #-} import System.Environment import Control.Monad import qualified Data.ByteString.Char8 as S import qualified Data.ByteString.Unsafe as S import qualified Data.IntMap as M main = do [f] <- getArgs x <- loadToMap f print (M.size x) getChar -- wait loadToMap :: String -> IO (M.IntMap S.ByteString) loadToMap f = parseLines `fmap` S.readFile f -- -- Build an IntMap as we traverse the NNN\tfoo\n lines of the file -- parseLines :: S.ByteString -> M.IntMap S.ByteString parseLines s = go s M.empty where go s m | S.null s = m | otherwise = case S.readInt s of Nothing -> error "No integer field" Just (n, y) -> go (S.tail rest) m' where (str,rest) = S.break ('\n'==) (S.unsafeTail y) m' = M.insert (fromIntegral n) str m From duncan.coutts at worc.ox.ac.uk Tue Mar 11 20:46:09 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Mar 11 20:43:19 2008 Subject: [Haskell-cafe] Re: Constructing Data.Map from ByteString In-Reply-To: References: Message-ID: <1205282769.11558.1012.camel@localhost> On Tue, 2008-03-11 at 11:13 +0000, Dave Tapley wrote: > Just a few updates on this one: > > I've upgraded to bytestring-0.9.0.5 from Darcs, no improvement. > Also this morning I tried using Data.HashMap with Bytestring's readInt > and HashMap's hashInt.. The result was a Stack space overflow :( > > God damn it I don't want to have to go back to C++ but soon will have > no choice with time constraints :( Just to keep haskel-cafe readers up-to-date with the discussion of this on #haskell... So if we take a step back and look at the size and form of the data. The input is a huge file of the form: 465 foo 1236 bar 594 baz And we have hundreds of megabytes of this. So more precisely it's lines with an integer (apparently guaranteed to fit into a 32bit unsigned word) a tab and a shortish string. The overall line length is around 10-15 characters in general. So let's look at some sizes: Let's assume the lines are 13 characters long (including \n terminator) so that's just 13 bytes. data Map k a = Tip | Bin {-# UNPACK #-} !Size !k a !(Map k a) !(Map k a) So an Data.Map node is 6 words. data ByteString = PS {-# UNPACK #-} !(ForeignPtr Word8) {-# UNPACK #-} !Int -- offset {-# UNPACK #-} !Int -- length This is also 5 words (because ForeignPtr unpacks to 2 words). So if we make a Map ByteString ByteString and we have an entry per line then we need 5+5+6 words. On a 32bit machine that's (5+5+6)*4 = 64bytes. So 64bytes storage for each 13 byte line. So that's approximately a factor of 5. That explains the original observation. So what is a more memory efficient representation? Well we can eliminate the ByteString key by taking advantage of the fact that the key is always guaranteed to fit into a Word. So we can use an IntMap. An IntMap is 3-5 words per node (3 for leaf and 5 for internal for an average of 4). Then the ByteString map value has redundancy, we know that all of them are substrings of the same big ByteString so we could factor that out and use a: data SubStr = SubStr {-# UNPACK #-} !Int -- offset {-# UNPACK #-} !Int -- length That's 3 words. So that's still (4+3)*4 = 28 bytes per 13 byte line. To get something really compact we could use an index composed of three unboxed Int arrays. One for the key, one for the offset and one for the length. We'd keep the key array sorted and the other two arrays synchronised. We'd use a binary search on the key array and then look up the corresponding entries in the offset and length arrays. That representation uses 3 words = 12 bytes per line. We could reduce that to 10 or 9 bytes if we assume the key lengths fit in a Word16 or Word8. So that gets us down to just double the original input file size. We could further reduce this by making a new value ByteString consisting of just all the values concatenated together without the keys in between. That'd temporarily use another copy but that might be acceptable given that this index is going to be used heavily later with more data. Duncan From wnoise at ofb.net Tue Mar 11 20:55:53 2008 From: wnoise at ofb.net (Aaron Denney) Date: Tue Mar 11 20:53:13 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <47D52A87.9060805@iee.org> <404396ef0803100632w6ae183f3w467aa02bae40caa2@mail.gmail.com> <47D5416C.808@iee.org> <871w6i8wx4.fsf@nmd9999.imr.no> <47D55287.5040701@iee.org> <404396ef0803100829h44c8ac1dg4ee6f0132cb4f929@mail.gmail.com> <47D56B7A.2030200@iee.org> <220e47b40803101207w6d4bb795k68d959b3ccff9849@mail.gmail.com> <47D5A46A.5010800@iee.org> <404396ef0803101433s435bbc64j46617fe50ba46aa5@mail.gmail.com> <47D63C44.7070704@iee.org> Message-ID: On 2008-03-11, Adrian Hey wrote: > Neil Mitchell wrote: >> Hi >> >>> (sort [a,b]) in the case we have: (compare a b = EQ) >>> >>> Which of the following 4 possible results are correct/incorrect? >>> 1- [a,a] >>> 2- [a,b] >>> 3- [b,a] >>> 4- [b,b] >> >> Fortunately the Haskell sort is meant to be stable, > > I would have said it is meant to be *correct* first and *efficient* > second. You're ruling out a whole bunch of possibly more efficient > and correct sorts on the grounds that they may give observably different > results for a tiny minority of (IMO broken) Eq/Ord instances. It's exactly your opinion that these are broken that we're arguing about. My view is that they are just equivalence and ordering relations, not complete equality relations. Using sortBy, or wrapping in a newtype with a different ordering instance and then using sort should be equivalent. > Wrt to *sortBy* (vs. *sort*), I would be inclined to agree with you. > I sure hope someone has proven that the (apparently) different sortBy > implementations provided by ghc,nhc and h98 library report are precisely > equivalent for all (type legal) function arguments. >> and sorting is >> meant to be a permutation, so we happily have the situation where this >> has a correct answer: 2. > >> Anything else is incorrect. > > Isn't 3 also a permutation? Why is it incorrect? Stability -- see "Fortunately the Haskell sort is meant to be stable," above. >> Adrian: I think its fairly clear we disagree about these things. >> However, we both understand the others point of view, so I guess its >> just a question of opinion - and I doubt either of us will change. As >> such I think any further discussion may just lead to sleep deprivation >> [1]. I think I'm coming from a more discrete maths/theoretical >> background while you are coming from a more practical/pragmatist >> background. > > If the "discrete maths/theoretical" POV necessatates to the kind of > biasing madness of Data.Map/Set (for example) then it *sucks* bigtime > IMO :-) > Having tried this approach myself too (with the clone) I can confirm > that *this way lies madness*, so in future I will not be making > any effort to define or respect "sane", unambiguous and stable behaviour > for "insane" Eq/Ord instances for any lib I produce or hack on. Instead > I will be aiming for correctness and optimal efficiency on the > assumption that Eq and Ord instances are sensible. Good. But sensible only means that the Eq and Ord instances agree, not that x == y => f x == f y. -- Aaron Denney -><- From hpacheco at gmail.com Tue Mar 11 23:16:41 2008 From: hpacheco at gmail.com (Hugo Pacheco) Date: Tue Mar 11 23:13:49 2008 Subject: [Haskell-cafe] Bug with GADT in function Patterns? Message-ID: <7b92c2840803112016l1f9df507h2ddc45679eeb71c1@mail.gmail.com> Hi guys, I have found a bug on the compiler (at least ghc >6.8.2). For some module (yes, the example does nothing at all): *module Test where data Type a where Func :: Type a -> Type b -> Type (a -> b) PF :: Type a -> Type (PF a) data PF a where ID :: PF (a -> a) test :: Type a -> a -> a test (PF (Func _ _)) ID = ID* I get the impossible: *$ ghci Test.hs -fglasgow-exts GHCi, version 6.9.20080303: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. [1 of 1] Compiling Test ( Test.hs, interpreted ) ghc-6.9.20080303: panic! (the 'impossible' happened) (GHC version 6.9.20080303 for i386-apple-darwin): Coercion.splitCoercionKindOf $co${tc aog} [tv] t_ao8{tv} [tau] ~ a{tv aob} [sk] -> a{tv aob} [sk] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug* However, the following implementations of *test* compile ok: *test :: Type a -> a -> a test (PF _) ID = ID test :: Type a -> a -> a test (PF (Func _ _)) x = x* It has something to do with mixing different GADTs contructors. Should this be submitted as a bug as it is? Cheers, hugo -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080312/364eaef1/attachment.htm From mutjida at gmail.com Tue Mar 11 23:18:45 2008 From: mutjida at gmail.com (jeff p) Date: Tue Mar 11 23:15:54 2008 Subject: [Haskell-cafe] Reflective capabilities of Haskell (cont'd) In-Reply-To: <1205234259.5722.26.camel@ios.cogsys.wiai.uni-bamberg.de> References: <1205234259.5722.26.camel@ios.cogsys.wiai.uni-bamberg.de> Message-ID: Hello, Data.Typeable gives you most of what you want except for access to function bodies. -Jeff On Tue, Mar 11, 2008 at 6:17 AM, Martin Hofmann wrote: > I am trying to port a programme written in Maude, which is a reflective > language based on rewriting logic ( http://maude.cs.uiuc.edu/ ), to > Haskell. I thought using Template Haskell might be a good idea, but I > got stuck and now I am wondering if this is really possible in Haskell. > Let me give an example of a Maude module defining the function last over > a list of Peano numbers. > > fmod LAST is > sorts Peano PeanoList . > > op 0 : -> Peano [ctor] . > op s : Peano -> Peano [ctor] . > > op [] : -> PeanoList [ctor] . > op cons : Peano PeanoList -> PeanoList [ctor] . > > op last : PeanoList -> Peano . > > vars X Y : Peano . > var Xs : PeanoList . > > eq last(cons(X,[])) = X . > eq last(cons(X,cons(Y,Xs))) = last(cons(Y,Xs)) . > > endfm > > So, last(cons(s(0),cons(s(s(0)),cons(s(s(s(0))),[])))) would reduce to > s(s(s(0))). The cool thing about Maude is, that terms, modules, ... can > be lifted to the meta level. For example: > > upModule('LAST, false) > > would yield > > fmod 'LAST is > including 'BOOL . > sorts 'Peano ; 'PeanoList . > none > op '0 : nil -> 'Peano [ctor] . > op '`[`] : nil -> 'PeanoList [ctor] . > op 'cons : 'Peano 'PeanoList -> 'PeanoList [ctor] . > op 'last : 'PeanoList -> 'Peano [none] . > op 's : 'Peano -> 'Peano [ctor] . > none > eq 'last['cons['X:Peano,'`[`].PeanoList]] = 'X:Peano [none] . > eq 'last['cons['X:Peano,'cons['Y:Peano,'Xs:PeanoList]]] = > last['cons[ 'Y:Peano,'Xs:PeanoList]] [none] . > endfm > > I also have access, e.g. to the defined type constructors. > > So > upOpDecls('LAST,false). > > yields > > op '0 : nil -> 'Peano [ctor] . > op '`[`] : nil -> 'PeanoList [ctor] . > op 'cons : 'Peano 'PeanoList -> 'PeanoList [ctor] . > op 'last : 'PeanoList -> 'Peano [none] . > op 's : 'Peano -> 'Peano [ctor] . > > Given an arbitrary function, I have access to its definition, its types > and the type constructors, all as ADTs. > > Is this possible with Template Haskell, or in some other way? > > Thanks a lot, > > Martin > > > > > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From jules at jellybean.co.uk Wed Mar 12 03:03:02 2008 From: jules at jellybean.co.uk (Jules Bean) Date: Wed Mar 12 03:00:11 2008 Subject: [Haskell-cafe] IO () and IO [()] In-Reply-To: References: <11b141710803101511w5ac7894ch27bea31e1e277107@mail.gmail.com> <404396ef0803101517q25344eabxa8c7fc5f6f1220e8@mail.gmail.com> Message-ID: <47D78026.5050704@jellybean.co.uk> Henning Thielemann wrote: > > On Mon, 10 Mar 2008, Neil Mitchell wrote: > >>> I would like to know if in fact there's any difference in practice >>> between (), [()], i.e. if in practice the difference matters. >> >> Usually, not so much. A lot of Monad functions have _ variants, i.e. >> mapM and mapM_. If you don't need the result, use the mapM_ version, >> as it will run faster and not space/stack leak in some circumstances. > > In my opinion, mapM_ and sequence_ are in the wrong class, because they > do not need much of Monads, or even Functors. They could well live, say, > in Data.Monoid class. However, it's hard to integrate that in a > hierarchy of type classes. > > > instance Monoid a => Monoid (M a) where > mempty = return mempty > mappend = liftM2 mappend > > where M is a monad type. Surely you mean to say: instance Monad m => Monoid (m ()) where mempty = return () mappend = (>>) ? That is the instance which is consistent with your text "don't need much of monads". Then sequence_ becomes mconcat, and mapM_ becomes foldMap (from Data.Foldable), or more directly mconcat $ map ... See also Control.Applicative, for things which can be sequence_'ed or even sequence'd without being Monads. Jules From martin.hofmann at uni-bamberg.de Wed Mar 12 05:04:50 2008 From: martin.hofmann at uni-bamberg.de (Martin Hofmann) Date: Wed Mar 12 04:57:49 2008 Subject: [Haskell-cafe] Re: Re: Reflective capabilities of Haskell (cont'd) In-Reply-To: References: <1205234259.5722.26.camel@ios.cogsys.wiai.uni-bamberg.de> Message-ID: <1205312690.5974.6.camel@ios.cogsys.wiai.uni-bamberg.de> > Data.Typeable gives you most of what you want except for access to > function bodies. Thanks a lot, this helps a bit, but access to function bodies is exactly what I need. Or being more precise, I need the functionality of ghci's command ':t'. So functions that behave as follows, where everything is of course meta-represented in some way as ADT: Prelude Data.Typeable> typeOf (\a -> (Just (a:""))) (\a -> (Just (a:""))) :: Char -> Maybe [Char] Prelude Data.Typeable> getDomain $ typeOf (\a -> (Just (a:""))) [Char] Prelude Data.Typeable>getCodomain $ typeOf (\a -> (Just (a:""))) (Maybe [Char]) Prelude Data.Typeable>getTypeConstructors (Maybe [Char]) [ (Just) :: [Char] -> Maybe [Char] , (Nothing) :: Maybe [Char] ] Prelude Data.Typeable>getTypeConstructors [Char] [ (:) :: Char -> [Char] -> [Char] , ([]) :: [Char] ] I am much obliged for any kind of hint. Cheers, Martin From ketil at malde.org Wed Mar 12 05:03:25 2008 From: ketil at malde.org (Ketil Malde) Date: Wed Mar 12 05:00:25 2008 Subject: [Haskell-cafe] Re: Constructing Data.Map from ByteString In-Reply-To: (Dave Tapley's message of "Tue\, 11 Mar 2008 11\:13\:40 +0000") References: Message-ID: <87hcfcxqjm.fsf@nmd9999.imr.no> "Dave Tapley" writes: > I've upgraded to bytestring-0.9.0.5 from Darcs, no improvement. > Also this morning I tried using Data.HashMap with Bytestring's readInt > and HashMap's hashInt.. The result was a Stack space overflow :( That's not so good. >> It works as required, loading K/V pairs into a Data.Map, the concern >> is the amount of memory used. Pausing (using a getLine) after the >> readFile one can see (through 'ps v') that the whole file 'f' is >> loaded in to memory. >> However once the Map is created the memory footprint swells to around >> five times the size. Surely this can't be just overhead from Map? >> My reasoning was that by using ByteString and getting the whole file >> into memory a small and linear increase would be seen for Map >> overhead.. What's the average line length? Roughly, the Data.Map will contain 2*#lines nodes - at some bytes each, and the #lines leaf nodes will have pointers to two ByteStrings, which carry an overhead of three pointers (IIRC: char array, offset, length). Not sure about the size of Map internal nodes, but I assume it will be at least two pointers to children, and possibly the size as well? If we presume three words per node, we get about 6*#lines*wordsize overhead, so 24*#lines on 32 bits, and 48*#lines on 64 a bit architecture. Copying GC means that in reality you need -- or at least, the program will consume, if available? -- a good bit more. (And yes, since each string is just a pointer into the orignial file contents, you need to retain that as well.) Short answer: Maps are expensive in terms of memory. One option could be to pack the keys into Ints (if they're short enough) and use Data.IntMap. Another could be to just sort an Array of offsets into the file contents and use binary search. -k ?) If your program is thrashing, make sure you limit heap to 80% of physical memory (use +RTS -Mxxxx). -- If I haven't seen further, it is by standing in the footprints of giants From ketil at malde.org Wed Mar 12 05:40:17 2008 From: ketil at malde.org (Ketil Malde) Date: Wed Mar 12 05:37:18 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: <47D6B140.4010002@iee.org> (Adrian Hey's message of "Tue\, 11 Mar 2008 16\:20\:16 +0000") References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <47D5416C.808@iee.org> <871w6i8wx4.fsf@nmd9999.imr.no> <47D55287.5040701@iee.org> <404396ef0803100829h44c8ac1dg4ee6f0132cb4f929@mail.gmail.com> <47D56B7A.2030200@iee.org> <220e47b40803101207w6d4bb795k68d959b3ccff9849@mail.gmail.com> <47D5A46A.5010800@iee.org> <404396ef0803101433s435bbc64j46617fe50ba46aa5@mail.gmail.com> <47D63C44.7070704@iee.org> <6dbd4d000803110846k3fcb94a8k9ad780c2dd8272fc@mail.gmail.com> <47D6B140.4010002@iee.org> Message-ID: <87d4q0xou6.fsf@nmd9999.imr.no> Adrian Hey writes: > So really I think the docs have this backwards. It's sortBy that > implements a stable sort (assuming a suitably sane comparison function > I guess) and apparently sort is whatever you get from (sortBy compare). > But this is unduly restrictive on possible correct sort implementations > IMO. Somebody (maybe you?) suggested that 'sort' should be a function in class Ord, giving the implementer freedom to decide exactly what is optimal for that particular data type. Could this also be used to solve the Data.Map issue? I mean, could Data.Map.insert use 'sort' instead of 'compare' to place new elements? For types where there is no observable difference between EQ elements (which you know when you instantiate Ord for the type), 'sort [a,b]' could return [a,a] when a == b, saving you space. For types with observably different but EQual values (like Neil's (Foo Int (Int->Int))), you would need to fall back to the old behavior. Just wondering. -k -- If I haven't seen further, it is by standing in the footprints of giants From jeremy.odonoghue at gmail.com Wed Mar 12 05:50:21 2008 From: jeremy.odonoghue at gmail.com (Jeremy O'Donoghue) Date: Wed Mar 12 05:47:27 2008 Subject: [Haskell-cafe] ANNOUNCE: wxHaskell 0.10.3 rc1 Message-ID: <1205315421.15905.1241945927@webmail.messagingengine.com> We are pleased to announce the first release candidate of wxHaskell 0.10.3. This is the first update with binary packages available since June 2005, and is the result of a great deal of work by a new team of contributors. We are hoping to make a full release shortly, and issues and bug reports either through the wxHaskell user mailing list (wxhaskell-users@sourceforge.net) or via the Sourceforge bug tracker (http://sourceforge.net/tracker/?group_id=73133&atid=536845). Highlights of 0.10.3 rc1 include: - Support for Unicode builds of wxWidgets - Support for additional widgets including calendar, toolbar divider, styled text control (wxScintilla), media control - Support for clipboard, drag and drop - Support for 64bit (Linux) targets - Support for wxWidgets 2.6.x (support for wxWidgets 2.4.2 retained if you compile from source) - Support for building with GHC 6.6.x and 6.8.x - Parts of wxHaskell are now built with Cabal - New test cases - Removed support GHC version < 6.4 - Profiling support - Smaller generated binary sizes (using --split-objs) Binary packages are available from the wxHaskell download site at http://sourceforge.net/project/showfiles.php?group_id=73133, for the following platforms: - Debian - Windows - OS X (Intel and PPC platforms) - Source code .tar.gz and .zip - Documentation (cross-platform) About wxHaskell wxHaskell is a Haskell binding to the wxWidgets GUI library. It provides a native look and feel on Windows, OS X and Linux, and a medium level programming interface. The main project page for wxHaskell is at http://wxhaskell.sourceforge.net. The latest source code for wxHaskell can always be obtained from http://darcs.haskell.org/wxhaskell. There are developer (wxhaskell-devel@lists.sourceforge.net and user (wxhaskell-users@lists.sourceforge.net) mailing lists, and a wiki page at http://haskell.org/haskellwiki/WxHaskell which can provide more information to those interested. wxHaskell was originally created by Daan Leijen. The contributors to this new release include: - Eric Kow - shelarcy - Arie Middelkoop - Mads Lindstroem - Jeremy O'Donoghue - Lennart Augustson -- Jeremy O'Donoghue jeremy.odonoghue@gmail.com From mail at philip.in-aachen.net Wed Mar 12 06:31:41 2008 From: mail at philip.in-aachen.net (=?ISO-8859-1?Q?Philip_M=FCller?=) Date: Wed Mar 12 06:28:50 2008 Subject: [Haskell-cafe] simple Haskell question - List comprehensions In-Reply-To: <20080309195343.GA25585@cs.cmu.edu> References: <47D43A3E.2080805@philip.in-aachen.net> <20080309195343.GA25585@cs.cmu.edu> Message-ID: <47D7B10D.5060903@philip.in-aachen.net> Dan Licata schrieb: > Does that help? > Yeah, it did - Thanks! - Philip From lemming at henning-thielemann.de Wed Mar 12 07:40:05 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed Mar 12 07:36:07 2008 Subject: [Haskell-cafe] Exception handling when using STUArray In-Reply-To: References: <87wsod6ax8.fsf@columbia.edu> <6dbd4d000803080631s5d16e43cr7f7b2623c932b175@mail.gmail.com> <989AC059-9B60-40A1-9ECF-2CC9AC47D19E@fastmail.fm> Message-ID: On Tue, 11 Mar 2008, Donn Cave wrote: > On Mar 10, 2008, at 5:48 PM, Jonathan Cast wrote: > >> On 10 Mar 2008, at 12:37 AM, Donn Cave wrote: > ... >>> >>> An exception is, for me, any state that isn't properly accounted for in >>> its >>> immediate context. openFile could return 'Maybe Handle', but it doesn't, >>> so the context demands a Handle or an exception. >> >> In the context of this discussion, `Maybe Handle' /is/ an exception type, >> because Maybe is an exception monad. As is IO. This distinction is one >> between an unusual-but-anticipated code path, and a case the programmer >> simply didn't handle at all. The former is an exception; the latter is an >> error. Thanks for that summary! > I am not sure I understand what you're saying. `Error' may be open > to interpretation, but `exception' has a fairly unambiguous technical > meaning in Haskell, a non-local flow of control with associated data > type in Control.Exception. The TRY construct for Maybe is called 'maybe', the exception handler is the first argument to 'maybe'. The absence of 'Maybe' after calling 'maybe' shows that the exception was handled. From ndmitchell at gmail.com Wed Mar 12 07:48:13 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Wed Mar 12 07:45:19 2008 Subject: [Haskell-cafe] [GSoC] A data parallel physics engine In-Reply-To: <20080310143002.GA30015@home.ro-che.info> References: <20080310143002.GA30015@home.ro-che.info> Message-ID: <404396ef0803120448l2560d882u15488a43e040199c@mail.gmail.com> Hi > I'm looking for interesting project to work on during Google Summer of > Code. So I found [1]"A data parallel physics engine" ticket and got > excited about it. I'd like to know interested mentors and community > opinion about the complexity of such project. I don't think there are a great deal of Haskell users who _really_ need a physics engine right now. However, there seem to be a massive number who are working with matrices. I am informed that a lot of physics is just matrix stuff underneath (but don't know anything myself). Perhaps a nice direction to take this project would be to build an NDP matrix library first, then use that library to build a physics engine on top of it. A physics engine would certainly be very cool, and a parallel matrix library would certainly be very much in demand. Thanks Neil From allbery at ece.cmu.edu Wed Mar 12 09:34:00 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Wed Mar 12 09:31:10 2008 Subject: [Haskell-cafe] Exception handling when using STUArray In-Reply-To: References: <87wsod6ax8.fsf@columbia.edu> <6dbd4d000803080631s5d16e43cr7f7b2623c932b175@mail.gmail.com> <989AC059-9B60-40A1-9ECF-2CC9AC47D19E@fastmail.fm> Message-ID: <2BDDF536-5617-405C-83C2-C9E56333B3F6@ece.cmu.edu> On Mar 11, 2008, at 14:27 , Donn Cave wrote: > readLDAPMessage s = let [(_, msgID), (tag, body)] = berList s in > LDAPMessage (berInt msgID) (readResponse tag body) > > I go on to account for all the LDAP stuff I need in about 60 lines > of that kind of thing, 1/3 of it devoted to declarations of the > data types, and it isn't dense code, it's ... essentially declarative, > in a simple, straightforward way, almost as if I copied it directly > from the RFC. > > Is it `total'? No way! To get there, it seems to me I'd have to > double the code, and significantly distract from its real sense. You might want to think about the monadic use of Maybe/Either (or more generally MonadError), which abstracts away the checking and tracking into (>>=). The error handler is then at the point where values are injected into / retrieved from the monadic exception, similar to catch (...). -- 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 jules at jellybean.co.uk Wed Mar 12 09:56:05 2008 From: jules at jellybean.co.uk (Jules Bean) Date: Wed Mar 12 09:53:13 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: <47D6B140.4010002@iee.org> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <47D5416C.808@iee.org> <871w6i8wx4.fsf@nmd9999.imr.no> <47D55287.5040701@iee.org> <404396ef0803100829h44c8ac1dg4ee6f0132cb4f929@mail.gmail.com> <47D56B7A.2030200@iee.org> <220e47b40803101207w6d4bb795k68d959b3ccff9849@mail.gmail.com> <47D5A46A.5010800@iee.org> <404396ef0803101433s435bbc64j46617fe50ba46aa5@mail.gmail.com> <47D63C44.7070704@iee.org> <6dbd4d000803110846k3fcb94a8k9ad780c2dd8272fc@mail.gmail.com> <47D6B140.4010002@iee.org> Message-ID: <47D7E0F5.6090907@jellybean.co.uk> Adrian Hey wrote: > Denis Bueno wrote: >> On Tue, Mar 11, 2008 at 4:01 AM, Adrian Hey wrote: >>> > and sorting is >>> > meant to be a permutation, so we happily have the situation where >>> this >>> > has a correct answer: 2. >>> >>> > Anything else is incorrect. >>> >>> Isn't 3 also a permutation? Why is it incorrect? >> >> Because it is not stable. >> >> The documentation for Data.List.sort says the sort is stable: >> >> "The sort function implements a stable sorting algorithm." >> >> A stable sort respects the order of equal elements as they occur in >> the input list. > > This might be a reasonable thing to say about *sortBy*, but not sort > as the ordering of equal elements should not be observable (for any > correct instance of Ord). It should be impossible to implement a > function which can discriminate between [a,a],[a,b],[b,a],[b,b] if > compare a b = EQ. The fact that you can't implement a function to differentiation does not meant the difference is not important. "[b,a]" might cause 500G of file IO which "[a,b]" will not cause. This is not observable within haskell, but is very observable to the user. Stability is a nice property. I don't understand why you are arguing against this so aggressiviely. Jules From jules at jellybean.co.uk Wed Mar 12 09:57:55 2008 From: jules at jellybean.co.uk (Jules Bean) Date: Wed Mar 12 09:55:02 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: <47D6D57F.5030707@solidmath.com> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <220e47b40803091848u5925dbe9l261a7ca076f9069e@mail.gmail.com> <200803092304.02063.dan.doel@gmail.com> <404396ef0803100127p4e99997amf2e2a6d70dce6e8b@mail.gmail.com> <47D514C2.8050102@iee.org> <7383E6EC-83B6-4F28-98BA-0A187D0E52C5@fastmail.fm> <49a77b7a0803101914s21ea38a6w17557b058ca7e432@mail.gmail.com> <47D6D57F.5030707@solidmath.com> Message-ID: <47D7E163.7090302@jellybean.co.uk> Derek Gladding wrote: > Speaking as someone who often has to answer questions along the lines of > "why isn't my code generating the results I want on your system?", I > wouldn't call it evil, just "commonly mistaken for Real". Yes, of course. Double is an excellent example since it indicates that there exist types for which Ord (and Eq) instances are not quite sensible, but nonetheless we want them to exist because it is a real pain if they don't. (Or at least, we definitely want Ord. It's easier make the argument that we don't really want Eq) Jules From ahey at iee.org Wed Mar 12 11:18:01 2008 From: ahey at iee.org (Adrian Hey) Date: Wed Mar 12 11:15:12 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: <87d4q0xou6.fsf@nmd9999.imr.no> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <47D5416C.808@iee.org> <871w6i8wx4.fsf@nmd9999.imr.no> <47D55287.5040701@iee.org> <404396ef0803100829h44c8ac1dg4ee6f0132cb4f929@mail.gmail.com> <47D56B7A.2030200@iee.org> <220e47b40803101207w6d4bb795k68d959b3ccff9849@mail.gmail.com> <47D5A46A.5010800@iee.org> <404396ef0803101433s435bbc64j46617fe50ba46aa5@mail.gmail.com> <47D63C44.7070704@iee.org> <6dbd4d000803110846k3fcb94a8k9ad780c2dd8272fc@mail.gmail.com> <47D6B140.4010002@iee.org> <87d4q0xou6.fsf@nmd9999.imr.no> Message-ID: <47D7F429.80305@iee.org> Ketil Malde wrote: > Adrian Hey writes: > >> So really I think the docs have this backwards. It's sortBy that >> implements a stable sort (assuming a suitably sane comparison function >> I guess) and apparently sort is whatever you get from (sortBy compare). >> But this is unduly restrictive on possible correct sort implementations >> IMO. > > Somebody (maybe you?) suggested that 'sort' should be a function in > class Ord, giving the implementer freedom to decide exactly what is > optimal for that particular data type. > > Could this also be used to solve the Data.Map issue? I mean, could > Data.Map.insert use 'sort' instead of 'compare' to place new elements? I don't really think so. To be consistent people would have to do this all over the place, not just in Data.Map/Set. Anywhere where you have code like this (for Ord instances) if (x==y) then f x -- f y should be just as good! else g x y you'd now have to have something like.. if (x==y) then f (head (sort ([x,y])) else g x y Also, since the problem is with the concept of equality, in that we're now admitting that things can be equal but also not equal at the same time then choice should really be a method of the Eq class.. Something like.. -- Returns Nothing if args are not equal -- Just p if args are equal, where p is the prefered equal value chose :: Eq a => a -> a -> Maybe a Like I said, this way lies madness!! Regards -- Adrian Hey From bjorn at bringert.net Wed Mar 12 13:46:25 2008 From: bjorn at bringert.net (Bjorn Bringert) Date: Wed Mar 12 13:43:35 2008 Subject: [Haskell-cafe] Reminder: 4th Haskell Hackathon, April 11-13 in Gothenburg Message-ID: ------------------------------------------------------------------------ Hac4 4th Haskell Hackathon April 11-13, 2008 Gothenburg, Sweden http://haskell.org/haskellwiki/Hac4 Sponsored by Credit Suisse and Galois. ------------------------------------------------------------------------ This is a reminder to register for the 4th Haskell Hackathon. The event will be held over 3 days, April 11-13, at Chalmers University of Technology in Gothenburg, Sweden. == NEWS == * Lunches and at least one dinner for the Hackathon attendees will be provided through our generous sponsors Credit Suisse and Galois. * If you plan to start a new project on community.haskell.org, please request an account and project in advance, so as to save valuable Hackathon time. See http://community.haskell.org/admin/ for more details. == What it is == The plan is to hack on Haskell infrastructure, tools, libraries and compilers. To attend please register, and get ready to hack those lambdas! Code to hack on: * Hackage * Cabal * Porting foreign libraries * Bug squashing * You decide! Before you attend, do start thinking and familiarizing yourself with 1 or 2 projects you wish to work on, to ensure no wasted effort during the Hackathon. A list of possible projects is available on the website. == Registration == We ask that you register your interest. Follow the instructions on the registration page: http://haskell.org/haskellwiki/Hac4/Register Once you've registered, do add your info to the attendees self-organizing page, http://haskell.org/haskellwiki/Hac4/Attendees if you are looking to share costs, or meet up prior to the hackathon, with other attendees. N.B. if you already expressed interest via the wiki, do confirm by registering `officially' anyway. == Important dates == Hackathon: April 11-13, 2008 == Organizers == Bj?rn Bringert (local) Thomas Schilling (local) Lennart Kolmodin (local) Krasimir Angelov (local) Jean-Philippe Bernardy (local) Ian Lynagh Duncan Coutts From donn at avvanta.com Wed Mar 12 14:17:39 2008 From: donn at avvanta.com (Donn Cave) Date: Wed Mar 12 14:14:46 2008 Subject: [Haskell-cafe] Exception handling when using STUArray In-Reply-To: <2BDDF536-5617-405C-83C2-C9E56333B3F6@ece.cmu.edu> References: <87wsod6ax8.fsf@columbia.edu> <6dbd4d000803080631s5d16e43cr7f7b2623c932b175@mail.gmail.com> <989AC059-9B60-40A1-9ECF-2CC9AC47D19E@fastmail.fm> <2BDDF536-5617-405C-83C2-C9E56333B3F6@ece.cmu.edu> Message-ID: <58308741-7D24-42AB-BF9C-8E777C5EE9D4@avvanta.com> On Mar 12, 2008, at 6:34 AM, Brandon S. Allbery KF8NH wrote: > > On Mar 11, 2008, at 14:27 , Donn Cave wrote: >> readLDAPMessage s = let [(_, msgID), (tag, body)] = berList s in >> LDAPMessage (berInt msgID) (readResponse tag body) >> >> I go on to account for all the LDAP stuff I need in about 60 lines >> of that kind of thing, 1/3 of it devoted to declarations of the >> data types, and it isn't dense code, it's ... essentially >> declarative, >> in a simple, straightforward way, almost as if I copied it directly >> from the RFC. >> >> Is it `total'? No way! To get there, it seems to me I'd have to >> double the code, and significantly distract from its real sense. > > You might want to think about the monadic use of Maybe/Either (or > more generally MonadError), which abstracts away the checking and > tracking into (>>=). The error handler is then at the point where > values are injected into / retrieved from the monadic exception, > similar to catch (...). Sure. It isn't a lot of code, so I subjected it to Either-ization as an experiment, and I did indeed take the monad procedural route. The example function above became readLDAPMessage s = do [(_, msgID), (tag, body)] <- berList s >>= exactLen 2 i <- berInt msgID r <- readResponse tag body return (LDAPMessage i r) ... and the end result, applying this style across a number of related functions, was no more than half again as much code, and I guess not severely unreadable. Maybe it depends on whether a procedural style suits you. There may be clever ways to torture this logic into an even smaller format, but since the original is the clearest expression of the protocol and its caller is almost guaranteed to have an exception handler anyway -- in my opinion, it was a silly exercise, I'll throw the code away. The Either version forces strict evaluation, true? Let's say for some reason the caller actually uses only the first part, the LDAP message ID, then we don't really need to validate and decode the whole message, but if I were to Either-ize it, then it has to go the whole distance before we know it's Right and not Left? And likewise for every value of every attribute in the message. What I naively picture as the next step, where pure code can handle exceptions, is an _implicit_ evaluation monad like Either. Pattern matches then throw exceptions in the sense described in Control.Monad.Error, which may be caught in pure code by optionally making the monadic type explicit, or otherwise are converted to exceptions in the sense of Control.Exception and caught in the IO monad. I suppose this would not force evaluation, because it's fine grained - I don't fold (Right i) and (Right r) into (Right (LDAPMessage i r)), etc., but rather you may encounter a (Left _) anywhere in there. At least this would let us rationalize the use of 'exception' with two radically different meanings between Control.Monad.Error and Control.Exception. Donn Cave, donn@avvanta.com From lennart at augustsson.net Wed Mar 12 14:48:00 2008 From: lennart at augustsson.net (Lennart Augustsson) Date: Wed Mar 12 14:45:07 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <871w6i8wx4.fsf@nmd9999.imr.no> <47D55287.5040701@iee.org> <404396ef0803100829h44c8ac1dg4ee6f0132cb4f929@mail.gmail.com> <47D56B7A.2030200@iee.org> <220e47b40803101207w6d4bb795k68d959b3ccff9849@mail.gmail.com> <47D5A46A.5010800@iee.org> <404396ef0803101433s435bbc64j46617fe50ba46aa5@mail.gmail.com> <47D63C44.7070704@iee.org> Message-ID: I agree, I view == as some kind of equivalence relation in Haskell, and not a congruence relation (which would force x==y => f x == f y). Of course, the Haskell type system isn't strong enough to enforce anything more than it being a function returning a boolean. -- Lennart On Wed, Mar 12, 2008 at 12:55 AM, Aaron Denney wrote: > On 2008-03-11, Adrian Hey wrote: > > Neil Mitchell wrote: > >> Hi > >> > >>> (sort [a,b]) in the case we have: (compare a b = EQ) > >>> > >>> Which of the following 4 possible results are correct/incorrect? > >>> 1- [a,a] > >>> 2- [a,b] > >>> 3- [b,a] > >>> 4- [b,b] > >> > >> Fortunately the Haskell sort is meant to be stable, > > > > I would have said it is meant to be *correct* first and *efficient* > > second. You're ruling out a whole bunch of possibly more efficient > > and correct sorts on the grounds that they may give observably different > > results for a tiny minority of (IMO broken) Eq/Ord instances. > > It's exactly your opinion that these are broken that we're arguing > about. My view is that they are just equivalence and ordering > relations, not complete equality relations. Using sortBy, or wrapping > in a newtype with a different ordering instance and then using sort > should be equivalent. > > > Wrt to *sortBy* (vs. *sort*), I would be inclined to agree with you. > > I sure hope someone has proven that the (apparently) different sortBy > > implementations provided by ghc,nhc and h98 library report are precisely > > equivalent for all (type legal) function arguments. > >> and sorting is > >> meant to be a permutation, so we happily have the situation where this > >> has a correct answer: 2. > > > >> Anything else is incorrect. > > > > Isn't 3 also a permutation? Why is it incorrect? > > Stability -- see "Fortunately the Haskell sort is meant to be stable," > above. > > >> Adrian: I think its fairly clear we disagree about these things. > >> However, we both understand the others point of view, so I guess its > >> just a question of opinion - and I doubt either of us will change. As > >> such I think any further discussion may just lead to sleep deprivation > >> [1]. I think I'm coming from a more discrete maths/theoretical > >> background while you are coming from a more practical/pragmatist > >> background. > > > > If the "discrete maths/theoretical" POV necessatates to the kind of > > biasing madness of Data.Map/Set (for example) then it *sucks* bigtime > > IMO :-) > > > > Having tried this approach myself too (with the clone) I can confirm > > that *this way lies madness*, so in future I will not be making > > any effort to define or respect "sane", unambiguous and stable behaviour > > for "insane" Eq/Ord instances for any lib I produce or hack on. Instead > > I will be aiming for correctness and optimal efficiency on the > > assumption that Eq and Ord instances are sensible. > > Good. But sensible only means that the Eq and Ord instances agree, not > that > x == y => f x == f y. > > -- > Aaron Denney > -><- > > _______________________________________________ > 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/20080312/fdb0ce95/attachment.htm From andrewcoppin at btinternet.com Wed Mar 12 15:06:44 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Wed Mar 12 15:03:55 2008 Subject: [Haskell-cafe] File I/O question Message-ID: <47D829C4.6090802@btinternet.com> Hi Cafe. There's good news and there's bad news. The bad news is... I'm back. [Did I miss anything good?] The good news is... I have an actual question to ask as well. When I write to a file using System.IO, the file is locked for exclusive access. I gather this is as specified in the Haskell Report. Which is nice, but... I'd actually prefer the file to *not* be locked. Anybody know how to do that? From k.kosciuszkiewicz at gmail.com Wed Mar 12 15:12:40 2008 From: k.kosciuszkiewicz at gmail.com (Krzysztof =?utf-8?Q?Ko=C5=9Bciuszkiewicz?=) Date: Wed Mar 12 15:10:16 2008 Subject: [Haskell-cafe] Space leak - help needed In-Reply-To: <20080303042009.GB4363@zombie.inf.tu-dresden.de> References: <20080303022318.GE29085@localdomain> <20080303042009.GB4363@zombie.inf.tu-dresden.de> Message-ID: <20080312191240.GA12019@localdomain> On Mon, Mar 03, 2008 at 05:20:09AM +0100, Bertram Felgenhauer wrote: > > Another story from an (almost) happy Haskell user that finds himself > > overwhelmed by laziness/space leaks. > > > > I'm trying to parse a large file (>600MB) with a single S-expression > > like structure. With the help of ByteStrings I'm down to 4min processing > > time in constant space. However, when I try to wrap the parse results > > in a data structure, the heap blows up - even though I never actually > > inspect the structure being built! This bugs me, so I come here looking > > for answers. > > The polyparse library (http://www.cs.york.ac.uk/fp/polyparse/) > offers some lazy parsers, maybe one of those fits your needs. > Text.ParserCombinators.Poly.StateLazy is the obvious candidate. I have tried both Poly.StateLazy and Poly.State and they work quite well - at least the space leak is eliminated. Now evaluation of the parser state blows the stack... The code is at http://hpaste.org/6310 Thanks in advance, -- Krzysztof Ko?ciuszkiewicz Skype: dr.vee, Gadu: 111851, Jabber: kokr@jabberpl.org "Simplicity is the ultimate sophistication" -- Leonardo da Vinci From jeff.polakow at db.com Wed Mar 12 15:06:29 2008 From: jeff.polakow at db.com (Jeff Polakow) Date: Wed Mar 12 15:11:51 2008 Subject: [Haskell-cafe] Re: Re: Reflective capabilities of Haskell (cont'd) In-Reply-To: <1205312690.5974.6.camel@ios.cogsys.wiai.uni-bamberg.de> Message-ID: Hello, > Thanks a lot, this helps a bit, but access to function bodies is exactly > what I need. Or being more precise, I need the functionality of ghci's > command ':t'. So functions that behave as follows, where everything is > of course meta-represented in some way as ADT: > > Prelude Data.Typeable> typeOf (\a -> (Just (a:""))) > (\a -> (Just (a:""))) :: Char -> Maybe [Char] > > Prelude Data.Typeable> getDomain $ typeOf (\a -> (Just (a:""))) > [Char] > > Prelude Data.Typeable>getCodomain $ typeOf (\a -> (Just (a:""))) > (Maybe [Char]) > Data.Typeable should allow for all of the previous. > Prelude Data.Typeable>getTypeConstructors (Maybe [Char]) > [ (Just) :: [Char] -> Maybe [Char] > , (Nothing) :: Maybe [Char] > ] > > Prelude Data.Typeable>getTypeConstructors [Char] > [ (:) :: Char -> [Char] -> [Char] > , ([]) :: [Char] > ] > Data.Generics allows you to do this (to a certain extent), i.e. there is a function dataTypeConstrs :: DataType -> [Constr] -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/20080312/2df39a1e/attachment.htm From jed at 59A2.org Wed Mar 12 15:18:22 2008 From: jed at 59A2.org (Jed Brown) Date: Wed Mar 12 15:15:36 2008 Subject: [Haskell-cafe] [GSoC] A data parallel physics engine In-Reply-To: <404396ef0803120448l2560d882u15488a43e040199c@mail.gmail.com> (Neil Mitchell's message of "Wed, 12 Mar 2008 11:48:13 +0000") References: <20080310143002.GA30015@home.ro-che.info> <404396ef0803120448l2560d882u15488a43e040199c@mail.gmail.com> Message-ID: <87d4pzpx8h.fsf@59A2.org> On 12 Mar 2008, ndmitchell@gmail.com wrote: >> I'm looking for interesting project to work on during Google Summer of >> Code. So I found [1]"A data parallel physics engine" ticket and got >> excited about it. I'd like to know interested mentors and community >> opinion about the complexity of such project. > > I don't think there are a great deal of Haskell users who _really_ > need a physics engine right now. However, there seem to be a massive > number who are working with matrices. I am informed that a lot of > physics is just matrix stuff underneath (but don't know anything > myself). > > Perhaps a nice direction to take this project would be to build an NDP > matrix library first, then use that library to build a physics engine > on top of it. A physics engine would certainly be very cool, and a > parallel matrix library would certainly be very much in demand. Indeed, a matrix library would be really nice. Before getting serious about this, please take a very close look at how PETSc (http://www-unix.mcs.anl.gov/petsc/) handles matrices. The abstraction is very important because most large matrices of interest are sparse or have some symmetry that makes them asymptotically cheaper to apply (like with an FFT, FMM, or tensor product). It would be a shame to put a lot of work into something and have it miss the very important point that a matrix is nothing more than a linear transformation between finite dimensional spaces. Certain algorithms may need a particular representation, but many don't (a Krylov iteration just needs to apply the matrix to a vector; the preconditioner usually needs more, but may not use the same matrix). At the more mundane level, there is frequently an order of magnitude performance difference between different sparse matrix formats, but which one wins is problem specific. Jed -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080312/63af465a/attachment.bin From ahey at iee.org Wed Mar 12 15:28:53 2008 From: ahey at iee.org (Adrian Hey) Date: Wed Mar 12 15:26:03 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: <47D7E0F5.6090907@jellybean.co.uk> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <47D5416C.808@iee.org> <871w6i8wx4.fsf@nmd9999.imr.no> <47D55287.5040701@iee.org> <404396ef0803100829h44c8ac1dg4ee6f0132cb4f929@mail.gmail.com> <47D56B7A.2030200@iee.org> <220e47b40803101207w6d4bb795k68d959b3ccff9849@mail.gmail.com> <47D5A46A.5010800@iee.org> <404396ef0803101433s435bbc64j46617fe50ba46aa5@mail.gmail.com> <47D63C44.7070704@iee.org> <6dbd4d000803110846k3fcb94a8k9ad780c2dd8272fc@mail.gmail.com> <47D6B140.4010002@iee.org> <47D7E0F5.6090907@jellybean.co.uk> Message-ID: <47D82EF5.70404@iee.org> Jules Bean wrote: > Adrian Hey wrote: >> This might be a reasonable thing to say about *sortBy*, but not sort >> as the ordering of equal elements should not be observable (for any >> correct instance of Ord). It should be impossible to implement a >> function which can discriminate between [a,a],[a,b],[b,a],[b,b] if >> compare a b = EQ. > > The fact that you can't implement a function to differentiation does not > meant the difference is not important. > > "[b,a]" might cause 500G of file IO which "[a,b]" will not cause. I can't imagine why, unless this is some weird side effect of lazy IO (which I thought was generally agreed to be a "bad thing"). What if it's the "[a,b]" ordering that causes this but the "[b,a]" ordering that doesn't? The choice is arbitrary (for sort), but neither is obviously correct. > This is not observable within haskell, but is very observable to the user. Yes, there are plenty of things like space and time behaviour that are not "observable" in the semantic sense, but have real obvervable consequenses in the practical sense of real executables running on real machines. But constraints like this and Data.Set/Map "left biasing" often mean that implementations have to be made unnecessarily time and space *inefficient* for no good semantic reason. > Stability is a nice property. I don't understand why you are arguing > against this so aggressiviely. I'm not arguing against it for sortBy. I wouldn't even object to the existance of an overloaded.. stableSort = sortBy compare by definition. I am arguing against it for the default sort that is applied to all types because for many types there will be more efficient alternatives which are perfectly correct in the semantic sense, but don't respect the (semantically meaningless IMO for Ord instances) stability property. Of course the proper place for this hypothetical sort (and several other variations) is probably as an Ord class method, not a single overloaded function in Data.List. I would also regard any use of stableSort (in preference to the hypothetical "unstable" overloaded sort) with about the same degree of suspicion as any use of unsafePerformIO. Regards -- Adrian Hey From ahey at iee.org Wed Mar 12 15:31:44 2008 From: ahey at iee.org (Adrian Hey) Date: Wed Mar 12 15:28:53 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: <20080311203332.GA4233@krikkit.lan> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <220e47b40803091848u5925dbe9l261a7ca076f9069e@mail.gmail.com> <200803092304.02063.dan.doel@gmail.com> <404396ef0803100127p4e99997amf2e2a6d70dce6e8b@mail.gmail.com> <47D514C2.8050102@iee.org> <7383E6EC-83B6-4F28-98BA-0A187D0E52C5@fastmail.fm> <49a77b7a0803101914s21ea38a6w17557b058ca7e432@mail.gmail.com> <20080311203332.GA4233@krikkit.lan> Message-ID: <47D82FA0.3070104@iee.org> Remi Turk wrote: > I wouldn't bet on it either: > > Prelude> 0.0 == -0.0 > True > Prelude> isNegativeZero 0.0 == isNegativeZero (-0.0) > False > > Although isNegativeZero might be considered a ``private, > "internal" interface that exposes implementation details.'' Interesting example. So is the correct conclusion from this that all (polymorphic) code that assumes (x == y) = True implies x=y is inherently broken, or is just this particular Eq instance that's broken? Regards -- Adrian Hey From allbery at ece.cmu.edu Wed Mar 12 15:32:50 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Wed Mar 12 15:29:55 2008 Subject: [Haskell-cafe] Exception handling when using STUArray In-Reply-To: <58308741-7D24-42AB-BF9C-8E777C5EE9D4@avvanta.com> References: <87wsod6ax8.fsf@columbia.edu> <6dbd4d000803080631s5d16e43cr7f7b2623c932b175@mail.gmail.com> <989AC059-9B60-40A1-9ECF-2CC9AC47D19E@fastmail.fm> <2BDDF536-5617-405C-83C2-C9E56333B3F6@ece.cmu.edu> <58308741-7D24-42AB-BF9C-8E777C5EE9D4@avvanta.com> Message-ID: <831CF579-6B18-4519-89E5-29F676AFB40B@ece.cmu.edu> On Mar 12, 2008, at 14:17 , Donn Cave wrote: > Sure. It isn't a lot of code, so I subjected it to Either-ization > as an experiment, and I did indeed take the monad procedural route. Monad != procedural, unless you insist on do notation. Think of it as composition (it may be easier to use (=<<) which "points the same direction" as (.)). -- 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 jgbailey at gmail.com Wed Mar 12 15:34:38 2008 From: jgbailey at gmail.com (Justin Bailey) Date: Wed Mar 12 15:31:44 2008 Subject: [Haskell-cafe] Space leak - help needed In-Reply-To: <20080312191240.GA12019@localdomain> References: <20080303022318.GE29085@localdomain> <20080303042009.GB4363@zombie.inf.tu-dresden.de> <20080312191240.GA12019@localdomain> Message-ID: On Wed, Mar 12, 2008 at 12:12 PM, Krzysztof Ko?ciuszkiewicz wrote: > I have tried both Poly.StateLazy and Poly.State and they work quite well > - at least the space leak is eliminated. Now evaluation of the parser > state blows the stack... > > The code is at http://hpaste.org/6310 > > Thanks in advance, The stack blows up when a bunch of unevaluated thunks build up, and you try to evaluate them. One way to determine where those thunks are getting built is to use GHCs "retainer" profiling. Retainer sets will show you the "call stack" that is holding on to memory. That can give you a clue where these thunks are being created. To get finer-grained results, annotate your code with {#- SCC "..." #-} pragmas. Then you can filter the retainer profile by those annotations. That will help you determine where in a given function the thunks are being created. If you need help with profiling basics, feel free to ask. Justin From ahey at iee.org Wed Mar 12 15:51:54 2008 From: ahey at iee.org (Adrian Hey) Date: Wed Mar 12 15:49:04 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <47D52A87.9060805@iee.org> <404396ef0803100632w6ae183f3w467aa02bae40caa2@mail.gmail.com> <47D5416C.808@iee.org> <871w6i8wx4.fsf@nmd9999.imr.no> <47D55287.5040701@iee.org> <404396ef0803100829h44c8ac1dg4ee6f0132cb4f929@mail.gmail.com> <47D56B7A.2030200@iee.org> <220e47b40803101207w6d4bb795k68d959b3ccff9849@mail.gmail.com> <47D5A46A.5010800@iee.org> <404396ef0803101433s435bbc64j46617fe50ba46aa5@mail.gmail.com> <47D63C44.7070704@iee.org> Message-ID: <47D8345A.9000201@iee.org> Aaron Denney wrote: > On 2008-03-11, Adrian Hey wrote: >> Having tried this approach myself too (with the clone) I can confirm >> that *this way lies madness*, so in future I will not be making >> any effort to define or respect "sane", unambiguous and stable behaviour >> for "insane" Eq/Ord instances for any lib I produce or hack on. Instead >> I will be aiming for correctness and optimal efficiency on the >> assumption that Eq and Ord instances are sensible. > > Good. But sensible only means that the Eq and Ord instances agree, not that > x == y => f x == f y. So can I assume that max x y = max y x? If not, how can I tell if I've made the correct choice of argument order. If I can't tell then I guess I have no alternative but document my arbitrary choice in the Haddock, and probably for the (sake of completeness) provide 2 or more alternative definitions of the "same" function which use a different argument order. Regards -- Adrian Hey From ketil at malde.org Wed Mar 12 15:55:06 2008 From: ketil at malde.org (Ketil Malde) Date: Wed Mar 12 15:52:04 2008 Subject: [Haskell-cafe] Re: Constructing Data.Map from ByteString In-Reply-To: <1205282769.11558.1012.camel@localhost> (Duncan Coutts's message of "Wed\, 12 Mar 2008 00\:46\:09 +0000") References: <1205282769.11558.1012.camel@localhost> Message-ID: <87od9jvht1.fsf@nmd9999.imr.no> Duncan Coutts writes: > To get something really compact we could use an index composed of three > unboxed Int arrays. To get something *really* compact, we could build a (kind of) suffix array. That is, we do a lexical sort of the lines, and store the sorted offsets of the lines in an array. You can then look up any index by binary search using this array. That's 10-15 characters plus one offset (4 bytes) per line, ~1.3 times the original file. (There are also compressed suffix array structures, but I don't think those will gain you anything if you don't store all the positions.) -k -- If I haven't seen further, it is by standing in the footprints of giants From jeff.polakow at db.com Wed Mar 12 15:59:36 2008 From: jeff.polakow at db.com (Jeff Polakow) Date: Wed Mar 12 15:55:00 2008 Subject: [Haskell-cafe] Re: Re: Reflective capabilities of Haskell (cont'd) In-Reply-To: Message-ID: Hello, > > Prelude Data.Typeable> typeOf (\a -> (Just (a:""))) > > (\a -> (Just (a:""))) :: Char -> Maybe [Char] > > > > Prelude Data.Typeable> getDomain $ typeOf (\a -> (Just (a:""))) > > [Char] > > > > Prelude Data.Typeable>getCodomain $ typeOf (\a -> (Just (a:""))) > > (Maybe [Char]) > > > Data.Typeable should allow for all of the previous. > > > Prelude Data.Typeable>getTypeConstructors (Maybe [Char]) > > [ (Just) :: [Char] -> Maybe [Char] > > , (Nothing) :: Maybe [Char] > > ] > > > > Prelude Data.Typeable>getTypeConstructors [Char] > > [ (:) :: Char -> [Char] -> [Char] > > , ([]) :: [Char] > > ] > > > Data.Generics allows you to do this (to a certain extent), i.e. > there is a function > > dataTypeConstrs :: DataType -> [Constr] > It might be hard, or even impossible, to get Data.Typeable and Data.Generics to play with each other. There seems to be no good way of converting a Data.Typeable.TypeRep to a Data.Generics.Basics.DataType. Another option might be to use Language.Haskell.Parser and Language.Haskell.Syntax, but I have little experience with this and am not sure if you'll be able to do what you want. -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/20080312/9c8cc54a/attachment.htm From lennart at augustsson.net Wed Mar 12 15:58:20 2008 From: lennart at augustsson.net (Lennart Augustsson) Date: Wed Mar 12 15:55:28 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: <47D82FA0.3070104@iee.org> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <200803092304.02063.dan.doel@gmail.com> <404396ef0803100127p4e99997amf2e2a6d70dce6e8b@mail.gmail.com> <47D514C2.8050102@iee.org> <7383E6EC-83B6-4F28-98BA-0A187D0E52C5@fastmail.fm> <49a77b7a0803101914s21ea38a6w17557b058ca7e432@mail.gmail.com> <20080311203332.GA4233@krikkit.lan> <47D82FA0.3070104@iee.org> Message-ID: I'd say that any polymorphic code that assumes that x==y implies x=y is broken. But apart from that, floating point numbers break all kinds of laws that we might expect to hold. Even so, they are convenient to have instances of various classes. On Wed, Mar 12, 2008 at 7:31 PM, Adrian Hey wrote: > Remi Turk wrote: > > I wouldn't bet on it either: > > > > Prelude> 0.0 == -0.0 > > True > > Prelude> isNegativeZero 0.0 == isNegativeZero (-0.0) > > False > > > > Although isNegativeZero might be considered a ``private, > > "internal" interface that exposes implementation details.'' > > Interesting example. > > So is the correct conclusion from this that all (polymorphic) code > that assumes (x == y) = True implies x=y is inherently broken, > or is just this particular Eq instance that's broken? > > Regards > -- > Adrian Hey > > > _______________________________________________ > 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/20080312/f795768e/attachment.htm From donn at avvanta.com Wed Mar 12 16:04:11 2008 From: donn at avvanta.com (Donn Cave) Date: Wed Mar 12 16:01:19 2008 Subject: [Haskell-cafe] Exception handling when using STUArray In-Reply-To: <831CF579-6B18-4519-89E5-29F676AFB40B@ece.cmu.edu> References: <87wsod6ax8.fsf@columbia.edu> <6dbd4d000803080631s5d16e43cr7f7b2623c932b175@mail.gmail.com> <989AC059-9B60-40A1-9ECF-2CC9AC47D19E@fastmail.fm> <2BDDF536-5617-405C-83C2-C9E56333B3F6@ece.cmu.edu> <58308741-7D24-42AB-BF9C-8E777C5EE9D4@avvanta.com> <831CF579-6B18-4519-89E5-29F676AFB40B@ece.cmu.edu> Message-ID: <4D60723B-5699-456B-8546-72AE6700692F@avvanta.com> On Mar 12, 2008, at 12:32 PM, Brandon S. Allbery KF8NH wrote: > > On Mar 12, 2008, at 14:17 , Donn Cave wrote: > >> Sure. It isn't a lot of code, so I subjected it to Either-ization >> as an experiment, and I did indeed take the monad procedural route. > > Monad != procedural, unless you insist on do notation. Think of it > as composition (it may be easier to use (=<<) which "points the > same direction" as (.)). Yes, I insist on do notation, because it provides a convenient binding form that works with what I'm doing - the original functional variation wasn't so suited to composition either, and used `let'. But I see that as only syntactic - equally procedural, either way. Expressions are evaluated in a fixed order, so seems inherently procedural to me and `do' is only a notational convenience. Donn Cave, donn@avvanta.com From lennart at augustsson.net Wed Mar 12 16:08:35 2008 From: lennart at augustsson.net (Lennart Augustsson) Date: Wed Mar 12 16:05:46 2008 Subject: [Haskell-cafe] IO () and IO [()] In-Reply-To: <47D5C170.7000001@imageworks.com> References: <11b141710803101511w5ac7894ch27bea31e1e277107@mail.gmail.com> <2eb8984a0803101518q5915887n33e495d0557adb0b@mail.gmail.com> <47D5C170.7000001@imageworks.com> Message-ID: Yes, I wish Haskell had a 1-tuple. The obvious syntax is already taken, but I could accept something different, like 'One a'. On Mon, Mar 10, 2008 at 11:17 PM, Dan Weston wrote: > I understand the lack of distinction between a unit type and a 0-tuple, > since they are isomorphic. But it is strange that there is no 1-tuple, > since _|_ and the 1-tuple (_|_) would be different things entirely, no? > > Dan > > Rodrigo Queiro wrote: > > You're looking for mapM_ > > mapM_ :: (Monad m) => (a -> m b) -> [a] -> m () > > (see also sequence_ :: (Monad m) => [m a] -> m () ) > > > > I don't think that it is possible to have a 1-tuples, just 2 and up. () > > is a unit rather than a 0-tuple, apparently: > > http://www.haskell.org/onlinereport/basic.html#sect6.1.4 > > > > On 10/03/2008, *Paulo J. Matos* > > wrote: > > > > Hello all, > > > > I find it funny that IO () is different from IO [()]. > > For example, if I define a function to output some lines with mapT, > > I would do: > > outputLines :: Int -> IO () > > outputLines i = mapM (putStrLn . show) (take i $ iterate ((+) 1) 1) > > > > However, this is in fact > > outputLines :: Int -> IO [()] > > > > I would like to know if in fact there's any difference in practice > > between (), [()], i.e. if in practice the difference matters. > > My first guess is that this is just a consequence of the Haskell > type > > system and so that everything fits this really needs to be like > this. > > Because > > mapM :: (Monad m) => (a -> m b) -> [a] -> m [b] > > > > So I guess that it makes sense that you get IO [()] instead of IO > (), > > and adding an exception just to say that [()] == () isn't good. > > By the way, as a consequence can you possibly get IO (()) or IO > ([()]) > > and are these all different from each other? > > > > Cheers, > > > > -- > > Paulo Jorge Matos - pocm at soton.ac.uk > > http://www.personal.soton.ac.uk/pocm > > PhD Student @ ECS > > University of Southampton, UK > > Sponsor ECS runners - Action against Hunger: > > http://www.justgiving.com/ecsrunslikethewind > > _______________________________________________ > > 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 > > > _______________________________________________ > 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/20080312/3b4d6ed6/attachment-0001.htm From v.dijk.bas at gmail.com Wed Mar 12 16:11:00 2008 From: v.dijk.bas at gmail.com (Bas van Dijk) Date: Wed Mar 12 16:08:06 2008 Subject: [Haskell-cafe] [GSoC] A data parallel physics engine In-Reply-To: <20080310143002.GA30015@home.ro-che.info> References: <20080310143002.GA30015@home.ro-che.info> Message-ID: 2008/3/10 Roman Cheplyaka : > I'm looking for interesting project to work on during Google Summer of > Code. So I found [1]"A data parallel physics engine" ticket and got > excited about it. I'd like to know interested mentors and community > opinion about the complexity of such project. A bit offtopic but slightly related: I just added a GSoC project proposal about adding a nVidia CUDA backend to Data Parallel Haskell: http://hackage.haskell.org/trac/summer-of-code/ticket/1537 It would be great if this physics engine or matrix library could run on a CUDA enabled nVidia "graphics" card! regards, Bas From andrewcoppin at btinternet.com Wed Mar 12 16:19:39 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Wed Mar 12 16:16:42 2008 Subject: [Haskell-cafe] [GSoC] A data parallel physics engine In-Reply-To: References: <20080310143002.GA30015@home.ro-che.info> Message-ID: <47D83ADB.4070903@btinternet.com> Bas van Dijk wrote: > A bit offtopic but slightly related: > I just added a GSoC project proposal about adding a nVidia CUDA > backend to Data Parallel Haskell: > http://hackage.haskell.org/trac/summer-of-code/ticket/1537 > > It would be great if this physics engine or matrix library could run > on a CUDA enabled nVidia "graphics" card! > That looks to me like something that would be amazingly cool if it was done successfully (and a pretty "killer feature" for using Haskell in general) - but it looks like a HELL of a lot of work to bring it from being a pipe dream to a practical reality... OTOH, I don't build compilers for a living, so...? From wnoise at ofb.net Wed Mar 12 16:29:36 2008 From: wnoise at ofb.net (Aaron Denney) Date: Wed Mar 12 16:26:53 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <47D52A87.9060805@iee.org> <404396ef0803100632w6ae183f3w467aa02bae40caa2@mail.gmail.com> <47D5416C.808@iee.org> <871w6i8wx4.fsf@nmd9999.imr.no> <47D55287.5040701@iee.org> <404396ef0803100829h44c8ac1dg4ee6f0132cb4f929@mail.gmail.com> <47D56B7A.2030200@iee.org> <220e47b40803101207w6d4bb795k68d959b3ccff9849@mail.gmail.com> <47D5A46A.5010800@iee.org> <404396ef0803101433s435bbc64j46617fe50ba46aa5@mail.gmail.com> <47D63C44.7070704@iee.org> <47D8345A.9000201@iee.org> Message-ID: On 2008-03-12, Adrian Hey wrote: > Aaron Denney wrote: >> On 2008-03-11, Adrian Hey wrote: >>> Having tried this approach myself too (with the clone) I can confirm >>> that *this way lies madness*, so in future I will not be making >>> any effort to define or respect "sane", unambiguous and stable behaviour >>> for "insane" Eq/Ord instances for any lib I produce or hack on. Instead >>> I will be aiming for correctness and optimal efficiency on the >>> assumption that Eq and Ord instances are sensible. >> >> Good. But sensible only means that the Eq and Ord instances agree, not that >> x == y => f x == f y. > > So can I assume that max x y = max y x? No. You can, however, assume that max x y == max y x. (Okay, this fails on Doubles, because of NaN. I'll agree that the Eq and Ord instances for Double are not sane.) > If not, how can I tell if I've made the correct choice of argument > order. When calling, or when defining max? It depends on what types you're using, and which equivalence and ordering relations are being used. When calling, and when it might matter which representative of an equivalence class comes back out (such as in sorts) you have no choice but to look at the documentation or implementation of max. The Haskell report guarantees that x == y => max x y = y (and hence max y x = x), and the opposite choice for min. This is to ensure that (min x y, max x y) = (x,y) or (y,x). IOW, the report notices that choice of representatives for equivalence classes matters in some circumstances, and makes it easy to do the right thing. This supports the reading that Eq a is not an absolute equality relation, but an equivalence relation. > If I can't tell then I guess I have no alternative but document > my arbitrary choice in the Haddock, and probably for the (sake of > completeness) provide 2 or more alternative definitions of the "same" > function which use a different argument order. When defining max, yes, you must take care to make sure it useable for cases when Eq is an equivalence relation, rather than equality. If you're writing library code, then it won't generally know whether Eq means true equality rather than equivalence. If this would let you optimize things, you need some other way to communicate this. The common typeclasses are for generic, parameterizable polymorphism. Equivalence is a more generally useful notion than equality, so that's what I want captured by the Eq typeclass. And no, an overloaded sort doesn't belong in Ord, either. If the implementation is truly dependent on the types in non-trivial, non-susbstitutable ways (i.e. beyond a substition of what <= means), then they should be /different/ algorithms. It would be possible to right an "Equal a" typeclass, which does guarantee actual observable equality (but has no methods). Then you can write one equalSort (or whatever) of type equalSort :: (Eq a, Ord a, Equal a) => [a] -> [a] that will work on any type willing to guarantee this, but rightly fail on types that only define an equivalence relation. A stable sort is more generally useful than an unstable one. It's composable for radix sorting on compound structures, etc. Hence we want to keep this guarantee. -- Aaron Denney -><- From dons at galois.com Wed Mar 12 16:42:33 2008 From: dons at galois.com (Don Stewart) Date: Wed Mar 12 16:39:42 2008 Subject: [Haskell-cafe] File I/O question In-Reply-To: <47D829C4.6090802@btinternet.com> References: <47D829C4.6090802@btinternet.com> Message-ID: <20080312204233.GF9203@scytale.galois.com> andrewcoppin: > Hi Cafe. > > There's good news and there's bad news. > > The bad news is... I'm back. [Did I miss anything good?] > > The good news is... I have an actual question to ask as well. > > When I write to a file using System.IO, the file is locked for exclusive > access. I gather this is as specified in the Haskell Report. Which is > nice, but... I'd actually prefer the file to *not* be locked. Anybody > know how to do that? Hey Andrew, What are you trying to do? Read and write to the same file (if so, you need to use strict IO), or are you trying something sneakier? -- Don From dons at galois.com Wed Mar 12 16:59:27 2008 From: dons at galois.com (Don Stewart) Date: Wed Mar 12 16:56:39 2008 Subject: [Haskell-cafe] An offer to any haskell projects out there. In-Reply-To: <20080311224620.GA31622@schmong.org> References: <20080311224620.GA31622@schmong.org> Message-ID: <20080312205927.GH9203@scytale.galois.com> michael: > > Hello, > My name is Michael Litchard. I'm a techie living in silicon > valley, and I want to move into tech writing. I've got the > background, now I need a portfolio. I figured the best way to go > is to attach myself to some open source projects, and haskell > has had my heart for a few years now. I am by no means an expert > at haskell. My expertise is writing. So I make this offer. > If you need documentation written for your haskell project, I'm > your man. Whatever it is, I'll write it or edit it. Thanks for > your time. > > P.S > If this was the wrong list, or if anyone has other ideas > about how to propogate my proposal, please let me know. > > Michael Michael, Thanks for your offer! One of the best things you could do would be to submit patches against the core library set where documentation is missing. Starting with things in base, array, containers, directory, filepath, pretty, time etc. That would likely help the largest number of users. Patches to these libraries can be submitted to the libraries@haskell.org list. Cheers, Don From andrewcoppin at btinternet.com Wed Mar 12 17:03:27 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Wed Mar 12 17:00:30 2008 Subject: [Haskell-cafe] File I/O question In-Reply-To: <20080312204233.GF9203@scytale.galois.com> References: <47D829C4.6090802@btinternet.com> <20080312204233.GF9203@scytale.galois.com> Message-ID: <47D8451F.10304@btinternet.com> Don Stewart wrote: > Hey Andrew, > > What are you trying to do? Read and write to the same file (if so, you > need to use strict IO), or are you trying something sneakier? > I have a long-running Haskell program that writes status information to a log file. I'd like to be able to open and read that log file before the program has actually terminated. I have a similar program written in Tcl that allows me to do this, since apparently the Tcl interpretter doesn't lock output files for exclusive access. Haskell, however, does. (This seems to be the stipulated behaviour as per the Report.) If there's an easy way to change this, it would be useful... From marco-oweber at gmx.de Wed Mar 12 17:04:40 2008 From: marco-oweber at gmx.de (Marc Weber) Date: Wed Mar 12 17:01:46 2008 Subject: [Haskell-cafe] Java interfacing and ghc-6.8? Message-ID: <20080312210440.GA16349@gmx.de> Hi, I've read on haskell org about gcjni Haskel/Java VM bridge Lambada (< ghc 6.6.1) Do you know wether any of them can be compiled with ghc-6.8 ? If not does it need much effort to patch them? Sincerly Marc Weber From dons at galois.com Wed Mar 12 17:04:59 2008 From: dons at galois.com (Don Stewart) Date: Wed Mar 12 17:02:07 2008 Subject: [Haskell-cafe] File I/O question In-Reply-To: <47D8451F.10304@btinternet.com> References: <47D829C4.6090802@btinternet.com> <20080312204233.GF9203@scytale.galois.com> <47D8451F.10304@btinternet.com> Message-ID: <20080312210459.GI9203@scytale.galois.com> andrewcoppin: > Don Stewart wrote: > >Hey Andrew, > > > >What are you trying to do? Read and write to the same file (if so, you > >need to use strict IO), or are you trying something sneakier? > > > > I have a long-running Haskell program that writes status information to > a log file. I'd like to be able to open and read that log file before > the program has actually terminated. I have a similar program written in > Tcl that allows me to do this, since apparently the Tcl interpretter > doesn't lock output files for exclusive access. Haskell, however, does. > (This seems to be the stipulated behaviour as per the Report.) If > there's an easy way to change this, it would be useful... Did you open the file in ReadWriteMode ? -- Don From ndmitchell at gmail.com Wed Mar 12 17:05:03 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Wed Mar 12 17:02:14 2008 Subject: [Haskell-cafe] Termination of substitution Message-ID: <404396ef0803121405q51e4dd58h856e37cb64ff6ff3@mail.gmail.com> Hi I'm trying to show that a system of rules for manipulating Haskell expressions is terminating. The rules can be applied in any order, to any subexpression - and there is a problem if there is any possible infinite sequence. The rule that is giving me particular problems is: (\v -> x) y => x[v/y] (I realise this rule may duplicate the computation of y, but that is not relevant for this purpose.) In particular, given the expression (\x -> x x) (\x -> x x) we can keep applying this rule infinitely. However, I don't believe this expression is type safe in Haskell. Are any such expressions that would cause this to non-terminate not type safe? What are the necessary conditions for this to be safe? Does GHC perform lambda reduction, probably by introducing a let binding? Does the combination of reducing lambdas and creating let bindings give similar problems, particularly if bindings are inlined? I'm wondering if this rule is genuinely unsafe in Haskell. If it is, why isn't it an issue in real simplifiers. If it isn't, what makes it safe. Thanks for any help, Neil From dons at galois.com Wed Mar 12 17:05:38 2008 From: dons at galois.com (Don Stewart) Date: Wed Mar 12 17:02:47 2008 Subject: [Haskell-cafe] Java interfacing and ghc-6.8? In-Reply-To: <20080312210440.GA16349@gmx.de> References: <20080312210440.GA16349@gmx.de> Message-ID: <20080312210538.GJ9203@scytale.galois.com> marco-oweber: > Hi, > > I've read on haskell org about > gcjni > Haskel/Java VM bridge > Lambada (< ghc 6.6.1) > > Do you know wether any of them can be compiled with ghc-6.8 ? > If not does it need much effort to patch them? > None of these are maintained, as far as I'm aware, but the Java FFI landscape may also have changed in the last few years -- perahps it is easier these days? -- Don From andrewcoppin at btinternet.com Wed Mar 12 17:07:11 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Wed Mar 12 17:04:16 2008 Subject: [Haskell-cafe] File I/O question In-Reply-To: <20080312210459.GI9203@scytale.galois.com> References: <47D829C4.6090802@btinternet.com> <20080312204233.GF9203@scytale.galois.com> <47D8451F.10304@btinternet.com> <20080312210459.GI9203@scytale.galois.com> Message-ID: <47D845FF.7090209@btinternet.com> Don Stewart wrote: > andrewcoppin: > >> Don Stewart wrote: >> >>> Hey Andrew, >>> >>> What are you trying to do? Read and write to the same file (if so, you >>> need to use strict IO), or are you trying something sneakier? >>> >>> >> I have a long-running Haskell program that writes status information to >> a log file. I'd like to be able to open and read that log file before >> the program has actually terminated. I have a similar program written in >> Tcl that allows me to do this, since apparently the Tcl interpretter >> doesn't lock output files for exclusive access. Haskell, however, does. >> (This seems to be the stipulated behaviour as per the Report.) If >> there's an easy way to change this, it would be useful... >> > > Did you open the file in ReadWriteMode ? > Nope. Just WriteMode. I'm trying to read the file from Notepad.exe while my Haskell program is still running - which takes about an hour. From dpiponi at gmail.com Wed Mar 12 17:08:07 2008 From: dpiponi at gmail.com (Dan Piponi) Date: Wed Mar 12 17:05:12 2008 Subject: [Haskell-cafe] [GSoC] A data parallel physics engine In-Reply-To: <87d4pzpx8h.fsf@59A2.org> References: <20080310143002.GA30015@home.ro-che.info> <404396ef0803120448l2560d882u15488a43e040199c@mail.gmail.com> <87d4pzpx8h.fsf@59A2.org> Message-ID: <625b74080803121408u635abdafx3a28ac8f4848daf1@mail.gmail.com> 2008/3/12 Jed Brown : > It would be a shame to ...miss the very important point that a > matrix is nothing more than a linear transformation between finite > dimensional spaces. I rate this obvious seeming fact as one of the most important things I've learnt about numerical linear algebra in my career. The number of times I've seen (and...oops...written it myself) code that copies data out of some structure into some standard matrix structure when the original structure could itself have been seen as a function that transforms vectors is scary. It pays to think functionally. -- Dan From lemming at henning-thielemann.de Wed Mar 12 17:10:04 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed Mar 12 17:06:03 2008 Subject: [Haskell-cafe] Exception handling when using STUArray In-Reply-To: <4D60723B-5699-456B-8546-72AE6700692F@avvanta.com> References: <87wsod6ax8.fsf@columbia.edu> <6dbd4d000803080631s5d16e43cr7f7b2623c932b175@mail.gmail.com> <989AC059-9B60-40A1-9ECF-2CC9AC47D19E@fastmail.fm> <2BDDF536-5617-405C-83C2-C9E56333B3F6@ece.cmu.edu> <58308741-7D24-42AB-BF9C-8E777C5EE9D4@avvanta.com> <831CF579-6B18-4519-89E5-29F676AFB40B@ece.cmu.edu> <4D60723B-5699-456B-8546-72AE6700692F@avvanta.com> Message-ID: On Wed, 12 Mar 2008, Donn Cave wrote: > On Mar 12, 2008, at 12:32 PM, Brandon S. Allbery KF8NH wrote: > >> On Mar 12, 2008, at 14:17 , Donn Cave wrote: >> >>> Sure. It isn't a lot of code, so I subjected it to Either-ization >>> as an experiment, and I did indeed take the monad procedural route. >> >> Monad != procedural, unless you insist on do notation. Think of it as >> composition (it may be easier to use (=<<) which "points the same >> direction" as (.)). > > Yes, I insist on do notation, because it provides a convenient > binding form that works with what I'm doing - the original functional > variation wasn't so suited to composition either, and used `let'. > > But I see that as only syntactic - equally procedural, either way. > Expressions are evaluated in a fixed order, Do notation only looks like there are statements that are processed from the beginning to the end. But that's not true, it's still purely lazy and expressions are evaluated in the order that is forced by data dependencies. I have added this issue to http://haskell.org/haskellwiki/Do_notation_considered_harmful From bos at serpentine.com Wed Mar 12 17:13:50 2008 From: bos at serpentine.com (Bryan O'Sullivan) Date: Wed Mar 12 17:10:54 2008 Subject: [Haskell-cafe] IO () and IO [()] In-Reply-To: References: <11b141710803101511w5ac7894ch27bea31e1e277107@mail.gmail.com> <2eb8984a0803101518q5915887n33e495d0557adb0b@mail.gmail.com> <47D5C170.7000001@imageworks.com> Message-ID: <47D8478E.4070302@serpentine.com> Lennart Augustsson wrote: > Yes, I wish Haskell had a 1-tuple. The obvious syntax is already taken, > but I could accept something different, like 'One a'. Python's one-tuple syntax is (1,). The obvious difficulty with adapting this notation to Haskell lies in how one might write the constructor as a section. References: <47D829C4.6090802@btinternet.com> <20080312204233.GF9203@scytale.galois.com> <47D8451F.10304@btinternet.com> <20080312210459.GI9203@scytale.galois.com> <47D845FF.7090209@btinternet.com> Message-ID: <20080312211347.GK9203@scytale.galois.com> andrewcoppin: > > Nope. Just WriteMode. I'm trying to read the file from Notepad.exe while > my Haskell program is still running - which takes about an hour. > Oh, you want another process in the system to read the file while GHC is writing to it? This works fine on unix systems -- and perhaps Neil, or one of the other windows experts, can explain what the story is on Windows. -- Don From andrewcoppin at btinternet.com Wed Mar 12 17:21:21 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Wed Mar 12 17:18:28 2008 Subject: [Haskell-cafe] File I/O question In-Reply-To: <20080312211347.GK9203@scytale.galois.com> References: <47D829C4.6090802@btinternet.com> <20080312204233.GF9203@scytale.galois.com> <47D8451F.10304@btinternet.com> <20080312210459.GI9203@scytale.galois.com> <47D845FF.7090209@btinternet.com> <20080312211347.GK9203@scytale.galois.com> Message-ID: <47D84951.2030102@btinternet.com> Don Stewart wrote: > Oh, you want another process in the system to read the file while GHC is > writing to it? That's the one. ;-) [Well, not GHC but my GHC-compiled binary, but anyway...] > This works fine on unix systems -- and perhaps Neil, or > one of the other windows experts, can explain what the story is on Windows. > I thought the Report... wait, let me check... Oh, OK, that's not what I thought the Report says. Section 21.2.3, "File Locking". I thought it says that Haskell is supposed to prevent access to the same file by multiple threads. (And that, presumably, is why it's using an exclusive lock to try to implement these semantics under the Win32 API.) However, that's apparently not what it says... (It says multiple reader / single writer.) So... does this count as a bug then? From dons at galois.com Wed Mar 12 17:26:25 2008 From: dons at galois.com (Don Stewart) Date: Wed Mar 12 17:23:38 2008 Subject: [Haskell-cafe] [GSoC] A data parallel physics engine In-Reply-To: <404396ef0803120448l2560d882u15488a43e040199c@mail.gmail.com> References: <20080310143002.GA30015@home.ro-che.info> <404396ef0803120448l2560d882u15488a43e040199c@mail.gmail.com> Message-ID: <20080312212625.GL9203@scytale.galois.com> ndmitchell: > Hi > > > I'm looking for interesting project to work on during Google Summer of > > Code. So I found [1]"A data parallel physics engine" ticket and got > > excited about it. I'd like to know interested mentors and community > > opinion about the complexity of such project. > > I don't think there are a great deal of Haskell users who _really_ > need a physics engine right now. However, there seem to be a massive > number who are working with matrices. I am informed that a lot of > physics is just matrix stuff underneath (but don't know anything > myself). > > Perhaps a nice direction to take this project would be to build an NDP > matrix library first, then use that library to build a physics engine > on top of it. A physics engine would certainly be very cool, and a > parallel matrix library would certainly be very much in demand. I'd chime in here -- actually getting arrays and parallel arrays with list-like interfaces, and then onto matrices, will impact a lot of people's work, in a good way. From dons at galois.com Wed Mar 12 17:27:45 2008 From: dons at galois.com (Don Stewart) Date: Wed Mar 12 17:25:14 2008 Subject: [Haskell-cafe] [GSoC] A data parallel physics engine In-Reply-To: References: <20080310143002.GA30015@home.ro-che.info> Message-ID: <20080312212745.GM9203@scytale.galois.com> v.dijk.bas: > 2008/3/10 Roman Cheplyaka : > > I'm looking for interesting project to work on during Google Summer of > > Code. So I found [1]"A data parallel physics engine" ticket and got > > excited about it. I'd like to know interested mentors and community > > opinion about the complexity of such project. > > A bit offtopic but slightly related: > I just added a GSoC project proposal about adding a nVidia CUDA > backend to Data Parallel Haskell: > http://hackage.haskell.org/trac/summer-of-code/ticket/1537 > > It would be great if this physics engine or matrix library could run > on a CUDA enabled nVidia "graphics" card! > Note there's already a project at UNSW, with a PhD student attached, doing an nvidia CUDA backend to Data Parallel Haskell. Perhaps this could be factored in somehow? At least there's a source of mentors here. From taralx at gmail.com Wed Mar 12 17:30:41 2008 From: taralx at gmail.com (Taral) Date: Wed Mar 12 17:27:45 2008 Subject: [Haskell-cafe] Termination of substitution In-Reply-To: <404396ef0803121405q51e4dd58h856e37cb64ff6ff3@mail.gmail.com> References: <404396ef0803121405q51e4dd58h856e37cb64ff6ff3@mail.gmail.com> Message-ID: On 3/12/08, Neil Mitchell wrote: > However, I don't believe this expression is type safe in Haskell. Using higher-order polymorphism: f (x :: forall a. a -> a) = x x -- Taral "Please let me know if there's any further trouble I can give you." -- Unknown From andrewcoppin at btinternet.com Wed Mar 12 17:33:00 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Wed Mar 12 17:30:03 2008 Subject: [Haskell-cafe] [GSoC] A data parallel physics engine In-Reply-To: <20080312212745.GM9203@scytale.galois.com> References: <20080310143002.GA30015@home.ro-che.info> <20080312212745.GM9203@scytale.galois.com> Message-ID: <47D84C0C.2030904@btinternet.com> Don Stewart wrote: > Note there's already a project at UNSW, with a PhD student attached, > doing an nvidia CUDA backend to Data Parallel Haskell. > > Perhaps this could be factored in somehow? At least there's a source > of mentors here. > Aahhhh... I'd forgotten what an exciting place the Haskell world is! Hanging around here, you really feel like you're at the cutting edge of... something... heh. OK, I'll shut up now... From stefanor at cox.net Wed Mar 12 17:35:40 2008 From: stefanor at cox.net (Stefan O'Rear) Date: Wed Mar 12 17:32:46 2008 Subject: [Haskell-cafe] Termination of substitution In-Reply-To: <404396ef0803121405q51e4dd58h856e37cb64ff6ff3@mail.gmail.com> References: <404396ef0803121405q51e4dd58h856e37cb64ff6ff3@mail.gmail.com> Message-ID: <20080312213540.GA3978@localhost.localdomain> On Wed, Mar 12, 2008 at 09:05:03PM +0000, Neil Mitchell wrote: > Hi > > I'm trying to show that a system of rules for manipulating Haskell > expressions is terminating. The rules can be applied in any order, to > any subexpression - and there is a problem if there is any possible > infinite sequence. > > The rule that is giving me particular problems is: > > (\v -> x) y => x[v/y] > > (I realise this rule may duplicate the computation of y, but that is > not relevant for this purpose.) > > In particular, given the expression > > (\x -> x x) (\x -> x x) > > we can keep applying this rule infinitely. > > However, I don't believe this expression is type safe in Haskell. Are > any such expressions that would cause this to non-terminate not type > safe? I think you mean all, and the answer is "no, but". (Very interesting topic here, for me at least.) Haskell's core type system (let, lambda, and application) can be mapped into the simply-typed lambda calculus by macro-expanding lets, and (by the construction of the Hindley-Milner type system) this mapping is typability-preserving. The simply-typed lambda calculus is not only terminating, it is strongly normalizing - ALL possible reduction sequences stop eventually. (There is a very elegant proof of this). The addition of data types in full generality breaks this: newtype Curry o = Curry { unCurry :: Curry o -> o } loop :: o loop = (\c -> unCurry c c) (Curry (\c -> unCurry c c)) Systems like Coq, which need to preserve strong normalization for logical soundness, adopt a variety of syntactic restrictions. Coq specifically forbids contravariant recursion in types. > What are the necessary conditions for this to be safe? Does GHC > perform lambda reduction, probably by introducing a let binding? Does > the combination of reducing lambdas and creating let bindings give > similar problems, particularly if bindings are inlined? Yes. If you feed that example into GHC, GHC will crash (even with the optimizer off). Works fine in Hugs/Yhc. http://www.haskell.org/ghc/docs/latest/html/users_guide/bugs.html#bugs-ghc > I'm wondering if this rule is genuinely unsafe in Haskell. If it is, > why isn't it an issue in real simplifiers. If it isn't, what makes it > safe. Nobody but us logic fans actually writes encodings of Curry's Paradox. Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080312/54c14816/attachment.bin From stefanor at cox.net Wed Mar 12 17:37:35 2008 From: stefanor at cox.net (Stefan O'Rear) Date: Wed Mar 12 17:34:41 2008 Subject: [Haskell-cafe] Termination of substitution In-Reply-To: References: <404396ef0803121405q51e4dd58h856e37cb64ff6ff3@mail.gmail.com> Message-ID: <20080312213735.GB3978@localhost.localdomain> On Wed, Mar 12, 2008 at 02:30:41PM -0700, Taral wrote: > On 3/12/08, Neil Mitchell wrote: > > However, I don't believe this expression is type safe in Haskell. > > Using higher-order polymorphism: > > f (x :: forall a. a -> a) = x x Interestingly, this doesn't work - f is a self-application function, but it does not have a type that can be made to look like forall a. a -> a. Indeed, higher-order polymorphism as implemented in GHC can be implemented in System F-omega, a strongly normalizing calculus. (The usual datatype caveats apply). Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080312/1cf9bc32/attachment.bin From v.dijk.bas at gmail.com Wed Mar 12 17:47:17 2008 From: v.dijk.bas at gmail.com (Bas van Dijk) Date: Wed Mar 12 17:44:21 2008 Subject: [Haskell-cafe] [GSoC] A data parallel physics engine In-Reply-To: <20080312212745.GM9203@scytale.galois.com> References: <20080310143002.GA30015@home.ro-che.info> <20080312212745.GM9203@scytale.galois.com> Message-ID: On Wed, Mar 12, 2008 at 10:27 PM, Don Stewart wrote: > Note there's already a project at UNSW, with a PhD student attached, > doing an nvidia CUDA backend to Data Parallel Haskell. Great, do you perhaps have a link to a page describing that project? Then I can link to it from the GSoC ticket. Bas From dpiponi at gmail.com Wed Mar 12 17:54:31 2008 From: dpiponi at gmail.com (Dan Piponi) Date: Wed Mar 12 17:51:37 2008 Subject: [Haskell-cafe] [GSoC] A data parallel physics engine In-Reply-To: <47D84C0C.2030904@btinternet.com> References: <20080310143002.GA30015@home.ro-che.info> <20080312212745.GM9203@scytale.galois.com> <47D84C0C.2030904@btinternet.com> Message-ID: <625b74080803121454n221996edxb38245c6891b6348@mail.gmail.com> On Wed, Mar 12, 2008 at 2:33 PM, Andrew Coppin wrote: > Hanging around here, you really feel like you're at the cutting edge > of... something... heh. Another approach isn't to target a CUDA back end for Haskell but to write an array library that builds computations that can target a CUDA (or other) back end. My first real world job that involved programming was APL [1] based. APL (and its offspring) is a functional-ish programming language that manipulates arrays using a relatively small number of primitives, most of which probably map nicely to CUDA hardware because of the potential for data parallelism. Despite the write-only nature of APL source code, and the negative comments about it by Dijkstra, the expressivity of APL for numerical work is unbelievable. I would love to see some of those ideas somehow brought into Haskell as a library. [1] http://en.wikipedia.org/wiki/APL_%28programming_language%29 -- Dan From donn at avvanta.com Wed Mar 12 18:45:27 2008 From: donn at avvanta.com (Donn Cave) Date: Wed Mar 12 18:42:33 2008 Subject: [Haskell-cafe] Exception handling when using STUArray In-Reply-To: References: <87wsod6ax8.fsf@columbia.edu> <6dbd4d000803080631s5d16e43cr7f7b2623c932b175@mail.gmail.com> <989AC059-9B60-40A1-9ECF-2CC9AC47D19E@fastmail.fm> <2BDDF536-5617-405C-83C2-C9E56333B3F6@ece.cmu.edu> <58308741-7D24-42AB-BF9C-8E777C5EE9D4@avvanta.com> <831CF579-6B18-4519-89E5-29F676AFB40B@ece.cmu.edu> <4D60723B-5699-456B-8546-72AE6700692F@avvanta.com> Message-ID: <00B5B0D7-2074-4A03-99EF-D5DC84A6A480@avvanta.com> On Mar 12, 2008, at 2:10 PM, Henning Thielemann wrote: > On Wed, 12 Mar 2008, Donn Cave wrote: > >> On Mar 12, 2008, at 12:32 PM, Brandon S. Allbery KF8NH wrote: >> >>> On Mar 12, 2008, at 14:17 , Donn Cave wrote: >>>> Sure. It isn't a lot of code, so I subjected it to Either-ization >>>> as an experiment, and I did indeed take the monad procedural route. >>> Monad != procedural, unless you insist on do notation. Think of >>> it as composition (it may be easier to use (=<<) which "points >>> the same direction" as (.)). >> >> Yes, I insist on do notation, because it provides a convenient >> binding form that works with what I'm doing - the original functional >> variation wasn't so suited to composition either, and used `let'. >> >> But I see that as only syntactic - equally procedural, either way. >> Expressions are evaluated in a fixed order, > > Do notation only looks like there are statements that are processed > from the beginning to the end. But that's not true, it's still > purely lazy and expressions are evaluated in the order that is > forced by data dependencies. Let me put it this way: if I write do (i, s') <- decodeInt s (v, _) <- decodeInt s' return (i, v) ... instead of, to just avoid the monad stuff case (decodeInt s) of Left e -> Left e Right (i, s') -> case (decodeInt s') of Left e -> Left e Right (v, _) -> Right (i, v) ... the `do' notation just emphasizes the procedural-ness of this computation. I can't arrive at the end, without completing these steps, whatever notation I choose. `do' just happens to be considerably more convenient. Of course data dependencies force the order of evaluation, but some of those dependencies are inevitably built into the expression: I can't evaluate the result (Right (i, _)) without evaluating the second decodeInt far enough to know that it isn't (Left _). The type that we'd need for that would be something like Either String (Int, (Either String Int)) (etc. ad nauseum as the return value gets more complex.) Well, the problem inherently requires a certain order of evaluation. But if you will just handle pattern match failure in the IO monad, then you can write a simple functional expression of the problem instead, let (i, s') = decodeInt s in let (v, _) = decodeInt s' in (i, v) ... where I think `i' can be evaluated without forcing unnecessary evaluation of v. It's clearer, and avoids unnecessary strictness! Donn Cave, donn@avvanta.com From catamorphism at gmail.com Wed Mar 12 18:47:30 2008 From: catamorphism at gmail.com (Tim Chevalier) Date: Wed Mar 12 18:44:40 2008 Subject: [Haskell-cafe] An offer to any haskell projects out there. In-Reply-To: <20080312205927.GH9203@scytale.galois.com> References: <20080311224620.GA31622@schmong.org> <20080312205927.GH9203@scytale.galois.com> Message-ID: <4683d9370803121547n621255cbqabe2a9235c2e3f6b@mail.gmail.com> On 3/12/08, Don Stewart wrote: > One of the best things you could do would be to submit patches against > the core library set where documentation is missing. Starting > with things in base, array, containers, directory, filepath, pretty, > time etc. > > That would likely help the largest number of users. > > Patches to these libraries can be submitted to the libraries@haskell.org > list. > To elaborate ever so slightly on what Don said: A lot of libraries only have type signatures for functions in the libraries as "documentation". What's missing is English descriptions of what the functions really do. You yourself may not know what the functions do, but you can learn by experimenting with the libraries (writing little programs that use the functions) and by asking on this mailing list (and reading old posts in the archive), if necessary. It would be really useful if you decided to put time into this. Thanks in advance! Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "You never have to aspire to difficulty, darling. It arrives, uninvited. Then it stays for dinner."--Sue Miller From agl at imperialviolet.org Wed Mar 12 18:49:32 2008 From: agl at imperialviolet.org (Adam Langley) Date: Wed Mar 12 18:46:40 2008 Subject: [Haskell-cafe] Starting Haskell with a web application In-Reply-To: <396556a20803051125o34ca2197w60773871f7059523@mail.gmail.com> References: <6cc20cea0803051009y7fedd8a2i304f63ac867c3c23@mail.gmail.com> <47CEEBD7.30005@serpentine.com> <20080305190018.GE16789@scytale.galois.com> <47CEEF5F.8010807@serpentine.com> <396556a20803051125o34ca2197w60773871f7059523@mail.gmail.com> Message-ID: <396556a20803121549wcf96e65kfd2289aacc4bb7ad@mail.gmail.com> On Wed, Mar 5, 2008 at 12:25 PM, Adam Langley wrote: > I'm > working towards, is an OpenID consumer. Once I have that working, I'll > do a second release. It's not that far off, it's just a question of > time. The darcs release of minihttp[1] can now do this. It's not a Hackage release because it needs a darcs version of HsOpenSSL[2] and network-connection[3]. The OpenID example is running in EC2[4] at the moment if anyone wants to play. [1] http://darcs.imperialviolet.org/network-minihttp [2] http://darcs.imperialviolet.org/HsOpenSSL [3] http://darcs.imperialviolet.org/network-connection [4] http://ec2-67-202-22-226.compute-1.amazonaws.com:4112/ AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org From agl at imperialviolet.org Wed Mar 12 19:31:42 2008 From: agl at imperialviolet.org (Adam Langley) Date: Wed Mar 12 19:28:50 2008 Subject: [Haskell-cafe] Starting Haskell with a web application In-Reply-To: <396556a20803121549wcf96e65kfd2289aacc4bb7ad@mail.gmail.com> References: <6cc20cea0803051009y7fedd8a2i304f63ac867c3c23@mail.gmail.com> <47CEEBD7.30005@serpentine.com> <20080305190018.GE16789@scytale.galois.com> <47CEEF5F.8010807@serpentine.com> <396556a20803051125o34ca2197w60773871f7059523@mail.gmail.com> <396556a20803121549wcf96e65kfd2289aacc4bb7ad@mail.gmail.com> Message-ID: <396556a20803121631w6782d90cr727ec9440fa57acd@mail.gmail.com> On Wed, Mar 12, 2008 at 3:49 PM, Adam Langley wrote: > The OpenID example is running in EC2[4] at the moment if anyone wants to play. Well, thanks to all the people who hit it, there's nothing like users to find the stupid bugs ;) * Caching was wrong on the front page, so it would act funky if you were behind a proxy * Serving from the filesystem (i.e. the CSS) was broken because I missed an action in that code All fixed... AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org From rl at cse.unsw.edu.au Wed Mar 12 19:36:31 2008 From: rl at cse.unsw.edu.au (Roman Leshchinskiy) Date: Wed Mar 12 19:33:49 2008 Subject: [Haskell-cafe] [GSoC] A data parallel physics engine In-Reply-To: <404396ef0803120448l2560d882u15488a43e040199c@mail.gmail.com> References: <20080310143002.GA30015@home.ro-che.info> <404396ef0803120448l2560d882u15488a43e040199c@mail.gmail.com> Message-ID: <47D868FF.8040804@cse.unsw.edu.au> Neil Mitchell wrote: > Hi > >> I'm looking for interesting project to work on during Google Summer of >> Code. So I found [1]"A data parallel physics engine" ticket and got >> excited about it. I'd like to know interested mentors and community >> opinion about the complexity of such project. > > I don't think there are a great deal of Haskell users who _really_ > need a physics engine right now. Well, we do :-) The idea is to provide a good testbed for NDP with some real-world appeal and a certain coolness factor. > Perhaps a nice direction to take this project would be to build an NDP > matrix library first, then use that library to build a physics engine > on top of it. A physics engine would certainly be very cool, and a > parallel matrix library would certainly be very much in demand. The problem with dense matrices is that they are regular and NDP isn't too good at handling regular data structures at the moment. Our main focus is on irregular stuff like sparse matrices, trees and so on. Still, we'll see what happens. Roman From rl at cse.unsw.edu.au Wed Mar 12 19:40:40 2008 From: rl at cse.unsw.edu.au (Roman Leshchinskiy) Date: Wed Mar 12 19:37:53 2008 Subject: [Haskell-cafe] [GSoC] A data parallel physics engine In-Reply-To: References: <20080310143002.GA30015@home.ro-che.info> Message-ID: <47D869F8.1070209@cse.unsw.edu.au> Bas van Dijk wrote: > > A bit offtopic but slightly related: > I just added a GSoC project proposal about adding a nVidia CUDA > backend to Data Parallel Haskell: > http://hackage.haskell.org/trac/summer-of-code/ticket/1537 > > It would be great if this physics engine or matrix library could run > on a CUDA enabled nVidia "graphics" card! As Don said, we're working on that. However, this is a lot more work than just a summer project. The reason is that you can't run arbitrary NDP computations on the GPU, just a fairly restricted subset. This means that you need to decide what to put on the GPU during code generation which, in turn, means a significant amount of compiler hacking. It's really more than enough work for a PhD thesis. Roman From ajb at spamcop.net Wed Mar 12 19:48:04 2008 From: ajb at spamcop.net (ajb@spamcop.net) Date: Wed Mar 12 19:45:11 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: <47D7E0F5.6090907@jellybean.co.uk> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <47D5416C.808@iee.org> <871w6i8wx4.fsf@nmd9999.imr.no> <47D55287.5040701@iee.org> <404396ef0803100829h44c8ac1dg4ee6f0132cb4f929@mail.gmail.com> <47D56B7A.2030200@iee.org> <220e47b40803101207w6d4bb795k68d959b3ccff9849@mail.gmail.com> <47D5A46A.5010800@iee.org> <404396ef0803101433s435bbc64j46617fe50ba46aa5@mail.gmail.com> <47D63C44.7070704@iee.org> <6dbd4d000803110846k3fcb94a8k9ad780c2dd8272fc@mail.gmail.com> <47D6B140.4010002@iee.org> <47D7E0F5.6090907@jellybean.co.uk> Message-ID: <20080312194804.o14f2bxhcwgo00sw@webmail.spamcop.net> G'day all. Adrian Hey wrote: >> This might be a reasonable thing to say about *sortBy*, but not sort >> as the ordering of equal elements should not be observable (for any >> correct instance of Ord). It should be impossible to implement a >> function which can discriminate between [a,a],[a,b],[b,a],[b,b] if >> compare a b = EQ. Nonsense. Consider a Schwartzian transform wrapper: data OrdWrap k v = OrdWrap k v instance (Ord k) => Ord (OrdWrap k v) where compare (OrdWrap k1 v1) (OrdWrap k2 v2) = OrdWrap k1 k2 It would be incorrect (and not sane) for sort [a,b] to return [a,a] in this case, though a case could be made that either [a,b] or [b,a] make sense. Quoting Jules Bean : > Stability is a nice property. I don't understand why you are arguing > against this so aggressiviely. Stability is an occasionally very useful property. However, if there is a tradeoff between stability and performance, I'd prefer it if the library didn't choose for me. Cheers, Andrew Bromage From gtener at gmail.com Wed Mar 12 19:53:08 2008 From: gtener at gmail.com (=?ISO-8859-2?Q?Krzysztof_Skrz=EAtnicki?=) Date: Wed Mar 12 19:50:12 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: <20080312194804.o14f2bxhcwgo00sw@webmail.spamcop.net> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <47D56B7A.2030200@iee.org> <220e47b40803101207w6d4bb795k68d959b3ccff9849@mail.gmail.com> <47D5A46A.5010800@iee.org> <404396ef0803101433s435bbc64j46617fe50ba46aa5@mail.gmail.com> <47D63C44.7070704@iee.org> <6dbd4d000803110846k3fcb94a8k9ad780c2dd8272fc@mail.gmail.com> <47D6B140.4010002@iee.org> <47D7E0F5.6090907@jellybean.co.uk> <20080312194804.o14f2bxhcwgo00sw@webmail.spamcop.net> Message-ID: <220e47b40803121653h2a441b06k7f7f1b6db9fe3a05@mail.gmail.com> In OCaml you have sort and fastsort - the latter doesn't have to be stable. It currently is, because fastsort = sort. I think it is a good thing to leave people an option, if there is something important to choose. On Thu, Mar 13, 2008 at 12:48 AM, wrote: > G'day all. > > Adrian Hey wrote: > > >> This might be a reasonable thing to say about *sortBy*, but not sort > >> as the ordering of equal elements should not be observable (for any > >> correct instance of Ord). It should be impossible to implement a > >> function which can discriminate between [a,a],[a,b],[b,a],[b,b] if > >> compare a b = EQ. > > Nonsense. Consider a Schwartzian transform wrapper: > > data OrdWrap k v = OrdWrap k v > > instance (Ord k) => Ord (OrdWrap k v) where > compare (OrdWrap k1 v1) (OrdWrap k2 v2) = OrdWrap k1 k2 > > It would be incorrect (and not sane) for sort [a,b] to return [a,a] in > this case, though a case could be made that either [a,b] or [b,a] make > sense. > > Quoting Jules Bean : > > > Stability is a nice property. I don't understand why you are arguing > > against this so aggressiviely. > > Stability is an occasionally very useful property. However, if there > is a tradeoff between stability and performance, I'd prefer it if the > library didn't choose for me. > > 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/20080313/5bb33bbe/attachment.htm From nominolo at googlemail.com Wed Mar 12 20:14:46 2008 From: nominolo at googlemail.com (Thomas Schilling) Date: Wed Mar 12 20:13:32 2008 Subject: [Haskell-cafe] [GSoC] A data parallel physics engine In-Reply-To: <625b74080803121454n221996edxb38245c6891b6348@mail.gmail.com> References: <20080310143002.GA30015@home.ro-che.info> <20080312212745.GM9203@scytale.galois.com> <47D84C0C.2030904@btinternet.com> <625b74080803121454n221996edxb38245c6891b6348@mail.gmail.com> Message-ID: <1919FEFA-E28C-4F8B-BA2D-95D2C9BC1916@googlemail.com> There's an effort going on to use techniques from Lava (the Haskell- based hardware description language) to target GPUs. Joel Svensson [1] has written his Master's thesis on this and is now working on this for his PhD, so if you ask kindly he might tell you more about this or send you the thesis. [1] .. http://www.chalmers.se/cse/EN/people/svensson-joel On 12 mar 2008, at 22.54, Dan Piponi wrote: > On Wed, Mar 12, 2008 at 2:33 PM, Andrew Coppin > wrote: > >> Hanging around here, you really feel like you're at the cutting edge >> of... something... heh. > > Another approach isn't to target a CUDA back end for Haskell but to > write an array library that builds computations that can target a CUDA > (or other) back end. My first real world job that involved programming > was APL [1] based. APL (and its offspring) is a functional-ish > programming language that manipulates arrays using a relatively small > number of primitives, most of which probably map nicely to CUDA > hardware because of the potential for data parallelism. Despite the > write-only nature of APL source code, and the negative comments about > it by Dijkstra, the expressivity of APL for numerical work is > unbelievable. I would love to see some of those ideas somehow brought > into Haskell as a library. > > [1] http://en.wikipedia.org/wiki/APL_%28programming_language%29 > -- > Dan > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From quark at bluespec.com Wed Mar 12 20:35:46 2008 From: quark at bluespec.com (Jacob Schwartz) Date: Wed Mar 12 20:33:32 2008 Subject: [Haskell-cafe] floating point operations and representation Message-ID: <8e47d1720803121735j17343d57x49fff089123f889b@mail.gmail.com> I have two questions about using the Double data type and the operations in the Floating typeclass on a computer that uses IEEE floating point numbers. I notice that the Floating class only provides "log" (presumably log base 'e') and "logBase" (which, in the latest source that I see for GHC is defined as "log y / log x"). However, in C, the "math.h" library provides specific "log2" and "log10" functions, for extra precision. A test on IEEE computers (x86 and x86-64), shows that for a range of 64-bit "double" values, the answers in C do differ (in the last bit) if you use "log2(x)" and "log10(x)" versus "log (x) / log(2)" and "log(x) / log(10)". I am under the restriction that I need to write Haskell programs using Double which mimic existing C/C++ programs or generated data sets, and get the same answers. (It's silly, but take it as a given requirement.) If the C programs are using "log2", then I need "log2" in the Haskell, or else I run the risk of not producing the same answers. My first thought is to import "log2" and "log10" through the FFI. I was wondering if anyone on Haskell-Cafe has already done this and/or has a better suggestion about how to get specialized "log2" and "log10" (among the many specialized functions that the "math.h" library provides, for better precision -- for now, I'm just concerned with "log2" and "log10"). My second question is how to get at the IEEE bit representation for a Double. I am already checking "isIEEE n" in my source code (and "floatRadix n == 2"). So I know that I am operating on hardware that implements floating point numbers by the IEEE standard. I would like to get at the 64 bits of a Double. Again, I can convert to a CDouble and use the FFI to wrap a C function which casts the "double" to a 64-bit number and returns it. But I'm wondering if there's not a better way to do this natively in Haskell/GHC (perhaps some crazy use of the Storable typeclass?). Or if someone has already tackled this problem with FFI, that would be interesting to know. Thanks. Jacob From ajb at spamcop.net Wed Mar 12 20:53:52 2008 From: ajb at spamcop.net (ajb@spamcop.net) Date: Wed Mar 12 20:51:22 2008 Subject: [Haskell-cafe] A question about "monad laws" In-Reply-To: <15975734.post@talk.nabble.com> References: <15975734.post@talk.nabble.com> Message-ID: <20080312205352.zruv2qkjk04s88cg@webmail.spamcop.net> G'day all. Quoting askyle : > If you use this presentation you also need the following law: > (a . b) >=> c = (a >=> c) . b > > that is, compatibility with ordinary function composition. I like to call > this "naturality", since it's instrumental in proving return and bind to be > natural transformations. Define: f >=> g = \x -> f x >>= g fmap f xs = xs >>= return . f Then: fmap f . return = (expand fmap) \x -> (return x >>= return . f) = (defn. of >=>) \x -> (return >=> return . f) x = (left identity) \x -> (return . f) x = return . f Therefore return is natural. Bind (or, equivalently, join) is left as an exercise. Cheers, Andrew Bromage From chak at cse.unsw.edu.au Wed Mar 12 21:13:17 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Wed Mar 12 21:10:48 2008 Subject: [Haskell-cafe] Bug with GADT in function Patterns? In-Reply-To: <7b92c2840803112016l1f9df507h2ddc45679eeb71c1@mail.gmail.com> References: <7b92c2840803112016l1f9df507h2ddc45679eeb71c1@mail.gmail.com> Message-ID: Hi Hugo, > I have found a bug on the compiler (at least ghc >6.8.2). For some > module (yes, the example does nothing at all): > > module Test where > > data Type a where > Func :: Type a -> Type b -> Type (a -> b) > PF :: Type a -> Type (PF a) > > data PF a where > ID :: PF (a -> a) > > test :: Type a -> a -> a > test (PF (Func _ _)) ID = ID > > I get the impossible: > > $ ghci Test.hs -fglasgow-exts > GHCi, version 6.9.20080303: http://www.haskell.org/ghc/ :? for help > Loading package base ... linking ... done. > [1 of 1] Compiling Test ( Test.hs, interpreted ) > ghc-6.9.20080303: panic! (the 'impossible' happened) > (GHC version 6.9.20080303 for i386-apple-darwin): > Coercion.splitCoercionKindOf > $co${tc aog} [tv] > t_ao8{tv} [tau] ~ a{tv aob} [sk] -> a{tv aob} [sk] > Please report this as a GHC bug: http://www.haskell.org/ghc/ > reportabug > > However, the following implementations of test compile ok: > > test :: Type a -> a -> a > test (PF _) ID = ID > > test :: Type a -> a -> a > test (PF (Func _ _)) x = x > > It has something to do with mixing different GADTs contructors. > > Should this be submitted as a bug as it is? The implementation of type checking of GADTs was completely redone in 6.9. Could you please check whether you have the same problem with the current version of 6.9 in the darcs repo. If yes, then please submit it as a bug. Thanks, Manuel From chak at cse.unsw.edu.au Wed Mar 12 21:22:17 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Wed Mar 12 21:19:28 2008 Subject: [Haskell-cafe] [GSoC] A data parallel physics engine In-Reply-To: <20080312212625.GL9203@scytale.galois.com> References: <20080310143002.GA30015@home.ro-che.info> <404396ef0803120448l2560d882u15488a43e040199c@mail.gmail.com> <20080312212625.GL9203@scytale.galois.com> Message-ID: <6056D18E-4974-4E0C-94D5-A0322033DBB3@cse.unsw.edu.au> Don Stewart: > I'd chime in here -- actually getting arrays and parallel arrays with > list-like interfaces, and then onto matrices, will impact a lot of > people's work, in a good way. I am not quite sure what you mean with a list-like interface. NDP/DPH- style arrays are exactly like Haskell lists, but restricted to finite structures and with a more eager evaluation strategy. The syntactic sugar is like lists, just with colons thrown in (eg, [:1,2,3:] instead of [1,2,3]) and the Prelude functions have the same names as the list functions, just with a suffix P (eg, mapP instead of map). Manuel From hpacheco at gmail.com Wed Mar 12 21:25:09 2008 From: hpacheco at gmail.com (Hugo Pacheco) Date: Wed Mar 12 21:22:14 2008 Subject: [Haskell-cafe] Bug with GADT in function Patterns? In-Reply-To: References: <7b92c2840803112016l1f9df507h2ddc45679eeb71c1@mail.gmail.com> Message-ID: <7b92c2840803121825t303d4422mbe2a753b7697fba5@mail.gmail.com> Hi have tried with all versions until ghci-6.9.20080303 (from the nightly builds), is that the one? I'm sorry but where in the darcs repo can I find it? I cannot find a ghc-6.9branch. Thanks, hugo -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080313/1562fd8c/attachment.htm From dons at galois.com Wed Mar 12 21:27:59 2008 From: dons at galois.com (Don Stewart) Date: Wed Mar 12 21:25:06 2008 Subject: [Haskell-cafe] floating point operations and representation In-Reply-To: <8e47d1720803121735j17343d57x49fff089123f889b@mail.gmail.com> References: <8e47d1720803121735j17343d57x49fff089123f889b@mail.gmail.com> Message-ID: <20080313012759.GA11389@scytale.galois.com> quark: > I have two questions about using the Double data type and the > operations in the Floating typeclass on a computer that uses IEEE > floating point numbers. > > I notice that the Floating class only provides "log" (presumably log > base 'e') and "logBase" (which, in the latest source that I see for > GHC is defined as "log y / log x"). However, in C, the "math.h" > library provides specific "log2" and "log10" functions, for extra > precision. A test on IEEE computers (x86 and x86-64), shows that for > a range of 64-bit "double" values, the answers in C do differ (in the > last bit) if you use "log2(x)" and "log10(x)" versus "log (x) / > log(2)" and "log(x) / log(10)". You could consider binding directly to the C functions, if needed, {-# OPTIONS -fffi -#include "math.h" #-} import Foreign.C.Types foreign import ccall unsafe "math.h log10" c_log10 :: CDouble -> CDouble log10 :: Double -> Double log10 x = realToFrac (c_log10 (realToFrac x)) main = mapM_ (print . log10) [1..10] Also, is there any difference if you compile with -fvia-C or -fexcess-precision (or both)? > My second question is how to get at the IEEE bit representation for a > Double. I am already checking "isIEEE n" in my source code (and > "floatRadix n == 2"). So I know that I am operating on hardware that > implements floating point numbers by the IEEE standard. I would like > to get at the 64 bits of a Double. Again, I can convert to a CDouble > and use the FFI to wrap a C function which casts the "double" to a > 64-bit number and returns it. But I'm wondering if there's not a > better way to do this natively in Haskell/GHC (perhaps some crazy use > of the Storable typeclass?). Or if someone has already tackled this > problem with FFI, that would be interesting to know. The FFI is a good way. You can just bind to any C code linked with your code. There's some similar code for messing with doubles and longs in the mersenne-random package you might be able to use for inspiration: http://code.haskell.org/~dons/code/mersenne-random/ -- Don From dons at galois.com Wed Mar 12 21:28:56 2008 From: dons at galois.com (Don Stewart) Date: Wed Mar 12 21:26:05 2008 Subject: [Haskell-cafe] [GSoC] A data parallel physics engine In-Reply-To: <6056D18E-4974-4E0C-94D5-A0322033DBB3@cse.unsw.edu.au> References: <20080310143002.GA30015@home.ro-che.info> <404396ef0803120448l2560d882u15488a43e040199c@mail.gmail.com> <20080312212625.GL9203@scytale.galois.com> <6056D18E-4974-4E0C-94D5-A0322033DBB3@cse.unsw.edu.au> Message-ID: <20080313012856.GB11389@scytale.galois.com> chak: > Don Stewart: > >I'd chime in here -- actually getting arrays and parallel arrays with > >list-like interfaces, and then onto matrices, will impact a lot of > >people's work, in a good way. > > I am not quite sure what you mean with a list-like interface. NDP/DPH- > style arrays are exactly like Haskell lists, but restricted to finite > structures and with a more eager evaluation strategy. The syntactic > sugar is like lists, just with colons thrown in (eg, [:1,2,3:] instead > of [1,2,3]) and the Prelude functions have the same names as the list > functions, just with a suffix P (eg, mapP instead of map). Right, I was hinting I'd like the ndp library released. Even if not for parallelism -- just having a good array interface would be enough :) -- Don From chak at cse.unsw.edu.au Wed Mar 12 21:30:40 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Wed Mar 12 21:27:49 2008 Subject: [Haskell-cafe] [GSoC] A data parallel physics engine In-Reply-To: <87d4pzpx8h.fsf@59A2.org> References: <20080310143002.GA30015@home.ro-che.info> <404396ef0803120448l2560d882u15488a43e040199c@mail.gmail.com> <87d4pzpx8h.fsf@59A2.org> Message-ID: Jed Brown: > On 12 Mar 2008, ndmitchell@gmail.com wrote: >> I don't think there are a great deal of Haskell users who _really_ >> need a physics engine right now. However, there seem to be a massive >> number who are working with matrices. I am informed that a lot of >> physics is just matrix stuff underneath (but don't know anything >> myself). >> >> Perhaps a nice direction to take this project would be to build an >> NDP >> matrix library first, then use that library to build a physics engine >> on top of it. A physics engine would certainly be very cool, and a >> parallel matrix library would certainly be very much in demand. > > Indeed, a matrix library would be really nice. Before getting serious > about this, please take a very close look at how PETSc > (http://www-unix.mcs.anl.gov/petsc/) handles matrices. The > abstraction > is very important because most large matrices of interest are sparse > or > have some symmetry that makes them asymptotically cheaper to apply > (like > with an FFT, FMM, or tensor product). I agree that a good matrix library would be very useful. However, I am less sure that starting with a general matrix library is a good way to make progress towards a physics engine. Especially, for a simple engine we have a small set of (application-dependent) types of matrices, requiring a small number of the many possible matrices representations. In contrast, to write a good general-purpose matrix library, you need to support a whole range of representation and algorithms. In my experience, it is a lot harder to get somebody who is motivated to write a general-purpose library than getting somebody who is motivated to write an application, which you can run and show to people at the end. Don't get me wrong, if there is anybody who wants to write a matrix library using NDP, that would be absolutely fabulous, but otherwise I'd happily settle for a person who implements just enough matrix operations to get some nice physics going. Manuel From chak at cse.unsw.edu.au Wed Mar 12 21:43:55 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Wed Mar 12 21:41:08 2008 Subject: [Haskell-cafe] [GSoC] A data parallel physics engine In-Reply-To: <47D869F8.1070209@cse.unsw.edu.au> References: <20080310143002.GA30015@home.ro-che.info> <47D869F8.1070209@cse.unsw.edu.au> Message-ID: <595730A6-ADF4-4EB9-9DAE-792982067A45@cse.unsw.edu.au> Roman Leshchinskiy: > Bas van Dijk wrote: >> A bit offtopic but slightly related: >> I just added a GSoC project proposal about adding a nVidia CUDA >> backend to Data Parallel Haskell: >> http://hackage.haskell.org/trac/summer-of-code/ticket/1537 >> It would be great if this physics engine or matrix library could run >> on a CUDA enabled nVidia "graphics" card! > > As Don said, we're working on that. However, this is a lot more work > than just a summer project. The reason is that you can't run > arbitrary NDP computations on the GPU, just a fairly restricted > subset. This means that you need to decide what to put on the GPU > during code generation which, in turn, means a significant amount of > compiler hacking. It's really more than enough work for a PhD thesis. To elaborate on that, our current, more moderate goal is to implement a sort of embedded, array DSL into Haskell/GHC, so that all array DSL code is compiled down to CUDA and linked into the rest of the Haskell application using the FFI. This requires the design of the array DSL (partially done), a small addition to GHC (not done), and a compiler from GHC Core to CUDA (partially done). All this is part of a PhD project, and we hope to have something to show later this year. Step 2, then, is to implement a backend to DPH using that array DSL. Doing that efficiently is going to be another significant project (much more than can be achieved in a GSoC project). Manuel From dave at zednenem.com Wed Mar 12 22:28:26 2008 From: dave at zednenem.com (David Menendez) Date: Wed Mar 12 22:25:30 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: <20080312194804.o14f2bxhcwgo00sw@webmail.spamcop.net> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <47D56B7A.2030200@iee.org> <220e47b40803101207w6d4bb795k68d959b3ccff9849@mail.gmail.com> <47D5A46A.5010800@iee.org> <404396ef0803101433s435bbc64j46617fe50ba46aa5@mail.gmail.com> <47D63C44.7070704@iee.org> <6dbd4d000803110846k3fcb94a8k9ad780c2dd8272fc@mail.gmail.com> <47D6B140.4010002@iee.org> <47D7E0F5.6090907@jellybean.co.uk> <20080312194804.o14f2bxhcwgo00sw@webmail.spamcop.net> Message-ID: <49a77b7a0803121928q24c800c8o2b84dafd5fb85c88@mail.gmail.com> On Wed, Mar 12, 2008 at 7:48 PM, wrote: > Adrian Hey wrote: > > >> This might be a reasonable thing to say about *sortBy*, but not sort > >> as the ordering of equal elements should not be observable (for any > >> correct instance of Ord). It should be impossible to implement a > >> function which can discriminate between [a,a],[a,b],[b,a],[b,b] if > >> compare a b = EQ. > > Nonsense. Consider a Schwartzian transform wrapper: > > data OrdWrap k v = OrdWrap k v > > instance (Ord k) => Ord (OrdWrap k v) where > compare (OrdWrap k1 v1) (OrdWrap k2 v2) = OrdWrap k1 k2 > > It would be incorrect (and not sane) for sort [a,b] to return [a,a] in > this case, though a case could be made that either [a,b] or [b,a] make > sense. Adrian is arguing that compare a b == EQ should imply compare (f a) (f b) == EQ for all functions f (excluding odd stuff). Thus, the problem with your example would be in the Ord instance, not the sort function. -- Dave Menendez From ajb at spamcop.net Wed Mar 12 22:46:04 2008 From: ajb at spamcop.net (ajb@spamcop.net) Date: Wed Mar 12 22:43:09 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: <49a77b7a0803121928q24c800c8o2b84dafd5fb85c88@mail.gmail.com> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <47D56B7A.2030200@iee.org> <220e47b40803101207w6d4bb795k68d959b3ccff9849@mail.gmail.com> <47D5A46A.5010800@iee.org> <404396ef0803101433s435bbc64j46617fe50ba46aa5@mail.gmail.com> <47D63C44.7070704@iee.org> <6dbd4d000803110846k3fcb94a8k9ad780c2dd8272fc@mail.gmail.com> <47D6B140.4010002@iee.org> <47D7E0F5.6090907@jellybean.co.uk> <20080312194804.o14f2bxhcwgo00sw@webmail.spamcop.net> <49a77b7a0803121928q24c800c8o2b84dafd5fb85c88@mail.gmail.com> Message-ID: <20080312224604.lekfvpfrmssg444k@webmail.spamcop.net> G'day all. Quoting David Menendez : > Adrian is arguing that compare a b == EQ should imply compare (f a) (f > b) == EQ for all functions f (excluding odd stuff). Thus, the problem > with your example would be in the Ord instance, not the sort function. Understood, and the Schwartzian transform might be better understood as "sortBy" rather than "sort". As others have noted, this really is a question of what Eq and Ord "mean". And the answer to that is: Whatever makes the most domain-specific sense. Cheers, Andrew Bromage From chak at cse.unsw.edu.au Wed Mar 12 23:04:57 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Wed Mar 12 23:02:04 2008 Subject: [Haskell-cafe] Bug with GADT in function Patterns? In-Reply-To: <7b92c2840803121825t303d4422mbe2a753b7697fba5@mail.gmail.com> References: <7b92c2840803112016l1f9df507h2ddc45679eeb71c1@mail.gmail.com> <7b92c2840803121825t303d4422mbe2a753b7697fba5@mail.gmail.com> Message-ID: <52988EF2-72F7-42B5-B885-F8BC3B2E3EC9@cse.unsw.edu.au> Hugo Pacheco: > Hi have tried with all versions until ghci-6.9.20080303 (from the > nightly builds), is that the one? Yep, that one is fine. > I'm sorry but where in the darcs repo can I find it? I cannot find a > ghc-6.9 branch. 6.9 is not a branch, it is the main repository; ie, http://darcs.haskell.org/ghc/ Manuel From drl at cs.cmu.edu Thu Mar 13 00:04:56 2008 From: drl at cs.cmu.edu (Dan Licata) Date: Thu Mar 13 00:02:05 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: <20080312224604.lekfvpfrmssg444k@webmail.spamcop.net> References: <220e47b40803101207w6d4bb795k68d959b3ccff9849@mail.gmail.com> <47D5A46A.5010800@iee.org> <404396ef0803101433s435bbc64j46617fe50ba46aa5@mail.gmail.com> <47D63C44.7070704@iee.org> <6dbd4d000803110846k3fcb94a8k9ad780c2dd8272fc@mail.gmail.com> <47D6B140.4010002@iee.org> <47D7E0F5.6090907@jellybean.co.uk> <20080312194804.o14f2bxhcwgo00sw@webmail.spamcop.net> <49a77b7a0803121928q24c800c8o2b84dafd5fb85c88@mail.gmail.com> <20080312224604.lekfvpfrmssg444k@webmail.spamcop.net> Message-ID: <20080313040456.GA14218@cs.cmu.edu> On Mar12, ajb@spamcop.net wrote: > G'day all. > > Quoting David Menendez : > > >Adrian is arguing that compare a b == EQ should imply compare (f a) (f > >b) == EQ for all functions f (excluding odd stuff). Thus, the problem > >with your example would be in the Ord instance, not the sort function. > > Understood, and the Schwartzian transform might be better understood as > "sortBy" rather than "sort". > > As others have noted, this really is a question of what Eq and Ord > "mean". And the answer to that is: Whatever makes the most > domain-specific sense. I think the notion of a quotient type (C / ~) may be helpful in this discussion. A quotient type represents the equivalence classes of some carrier type C under some equivalence relation ~. Functions of type (C / ~) -> A are often defined by working with the underlying carrier type C. However, not all functions C -> A define functions (C / ~) -> A: to be a well-defined function on equivalence classes, the function C -> A must respect the equivalence relation ~, in the sense that c ~ c implies f(c) =_A f(c') where =_A is whatever equality at A is. For example, you can think of a type Set of sets as (List / ~) where ~ equates two lists iff they are permutations of each other. Then a function List -> A counts as a function Set -> A iff it takes permutations to equal A's. For instance, you can't write a function tolist :: Set -> List that simply dumps out the underlying representation, because then you can distinguish different representatives of the same equivalence class. Now, Haskell doesn't let you define quotient types directly, but you can code them up with abstract types: if you hide the implementation of a type C and ensure that all functions C -> A respect some equivalence relation ~, then you effectively have a quotient type (C / ~), because all functions on C are well-defined on the equivalence classes. So, I think a way of summing up the two points of view on Eq are: (1) You're only allowed to add an instance Eq A where (==) = ~ if A "is really" (A / ~). Then all functions on A necessarily respect ==. (2) The instance for Eq A is just some equivalence relation ~ that I might quotient A by. I.e., in Eq A, is A the quotient type or the underlying carrier? Both are reasonable and useful notions, but it might make sense to have two different type classes for these two notions, since if you expect one and get the other you can get into trouble. -Dan From dons at galois.com Thu Mar 13 00:57:48 2008 From: dons at galois.com (Don Stewart) Date: Thu Mar 13 00:54:52 2008 Subject: [Haskell-cafe] floating point operations and representation Message-ID: <20080313045748.GA11783@scytale.galois.com> > I am under the restriction that I need to write Haskell programs using > Double which mimic existing C/C++ programs or generated data sets, and > get the same answers. (It's silly, but take it as a given > requirement.) If the C programs are using "log2", then I need "log2" > in the Haskell, or else I run the risk of not producing the same > answers. Hey Jacob, Just to make life super simple, I packaged up a binding to the basic math.h library for Doubles. You can find the library here: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/cmath For example, Prelude> Foreign.C.Math.Double.log10 5 0.6989700043360189 Prelude> log 5 / log 10 0.6989700043360187 Enjoy! -- Don From vigalchin at gmail.com Thu Mar 13 01:15:27 2008 From: vigalchin at gmail.com (Galchin Vasili) Date: Thu Mar 13 01:12:31 2008 Subject: [Haskell-cafe] linker question Message-ID: <5ae4f2ba0803122215q690d2011u170b94d85fa6e216@mail.gmail.com> Hello, I have made modifications against an existing Haskell library and installed in my --prefix=$HOME. How do I specify to link against this test .a and not the "global" archive? Regards, vasili -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080313/fe0dae44/attachment.htm From dons at galois.com Thu Mar 13 01:24:53 2008 From: dons at galois.com (Don Stewart) Date: Thu Mar 13 01:21:57 2008 Subject: [Haskell-cafe] linker question In-Reply-To: <5ae4f2ba0803122215q690d2011u170b94d85fa6e216@mail.gmail.com> References: <5ae4f2ba0803122215q690d2011u170b94d85fa6e216@mail.gmail.com> Message-ID: <20080313052453.GA11830@scytale.galois.com> vigalchin: > Hello, > > I have made modifications against an existing Haskell library and > installed in my --prefix=$HOME. How do I specify to link against this test > .a and not the "global" archive? > > Regards, vasili Install with cabal and use the --user flag From roma at ro-che.info Thu Mar 13 02:08:06 2008 From: roma at ro-che.info (Roman Cheplyaka) Date: Thu Mar 13 02:05:21 2008 Subject: [Haskell-cafe] [GSoC] A data parallel physics engine In-Reply-To: References: <20080310143002.GA30015@home.ro-che.info> <404396ef0803120448l2560d882u15488a43e040199c@mail.gmail.com> <87d4pzpx8h.fsf@59A2.org> Message-ID: <20080313060806.GA2978@home.ro-che.info> * Manuel M T Chakravarty [2008-03-13 12:30:40+1100] >> Indeed, a matrix library would be really nice. Before getting serious >> about this, please take a very close look at how PETSc >> (http://www-unix.mcs.anl.gov/petsc/) handles matrices. The >> abstraction >> is very important because most large matrices of interest are sparse >> or >> have some symmetry that makes them asymptotically cheaper to apply >> (like >> with an FFT, FMM, or tensor product). > > In my experience, it is a lot harder to get somebody who is motivated to > write a general-purpose library than getting somebody who is motivated to > write an application, which you can run and show to people at the end. You're absolutely right from my (i.e. student's) point of view :) -- Roman I. Cheplyaka :: http://ro-che.info/ ...being in love is totally punk rock... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080313/26aad62a/attachment.bin From oleg at okmij.org Thu Mar 13 02:17:09 2008 From: oleg at okmij.org (oleg@okmij.org) Date: Thu Mar 13 02:14:20 2008 Subject: [Haskell-cafe] Re: Reflective capabilities of Haskell (cont'd) Message-ID: <20080313061709.88A76A99B@Adric.metnet.fnmoc.navy.mil> Martin Hofmann wrote: > Thanks a lot, this helps a bit, but access to function bodies is exactly > what I need. Then perhaps you might like the method of reconstructing bodies (of possibly compiled) functions http://okmij.org/ftp/Computation/Generative.html#diff-th in the form of AST -- the template Haskell AST. The reconstructed bodies of functions can be arbitrarily manipulated (e.g., _symbolically_ differentiated or algebraically simplified) and then converted `back' to the compiled code. From bjorn.buckwalter at gmail.com Thu Mar 13 02:22:57 2008 From: bjorn.buckwalter at gmail.com (Bjorn Buckwalter) Date: Thu Mar 13 02:20:15 2008 Subject: [Haskell-cafe] Re: An offer to any haskell projects out there. References: <20080311224620.GA31622@schmong.org> Message-ID: schmong.org> writes: > Hello, > My name is Michael Litchard. I'm a techie living in silicon > valley, and I want to move into tech writing. I've got the > background, now I need a portfolio. I figured the best way to go > is to attach myself to some open source projects, and haskell > has had my heart for a few years now. I am by no means an expert > at haskell. My expertise is writing. So I make this offer. > If you need documentation written for your haskell project, I'm > your man. Whatever it is, I'll write it or edit it. Thanks for > your time. > > P.S > If this was the wrong list, or if anyone has other ideas > about how to propogate my proposal, please let me know. > > Michael Michael, that's an awesome offer. As others have already noted there are plenty of areas where you could make a significant contribution. I'd specifically recommend reposting your offer to the HAppS (http://happs.org) list/group. HAppS is a high profile project which seems to be getting quite a bit of interest from outside the Haskell community. If you're unfamiliar with it I recommend taking a look at the "BayFP Presentation" linked on the site. Unfortunately HAppS has a serious deficit of documentation (including the web site not being up to date) and consequently there is a high barrier to entry. While HAppS could certainly benefit from you help I would imagine that you could also benefit from helping HAppS. The high profile of HAppS should increase the chance of prospective clients being able to relate to your portfolio, and I'd also imagine that comprehensive documentation focused on a specific project is more "portfoliable" than random pieces scattered around the standard libraries (not that I want to disuade you from contributing there too!). Good luck! -Bjorn (I'm not involved in the HAppS project, nor have I used it.) From lrpalmer at gmail.com Thu Mar 13 02:23:27 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Thu Mar 13 02:20:30 2008 Subject: [Haskell-cafe] Exception handling when using STUArray In-Reply-To: <00B5B0D7-2074-4A03-99EF-D5DC84A6A480@avvanta.com> References: <87wsod6ax8.fsf@columbia.edu> <989AC059-9B60-40A1-9ECF-2CC9AC47D19E@fastmail.fm> <2BDDF536-5617-405C-83C2-C9E56333B3F6@ece.cmu.edu> <58308741-7D24-42AB-BF9C-8E777C5EE9D4@avvanta.com> <831CF579-6B18-4519-89E5-29F676AFB40B@ece.cmu.edu> <4D60723B-5699-456B-8546-72AE6700692F@avvanta.com> <00B5B0D7-2074-4A03-99EF-D5DC84A6A480@avvanta.com> Message-ID: <7ca3f0160803122323t25707fefn1233c15a1ce94dc2@mail.gmail.com> On Wed, Mar 12, 2008 at 4:45 PM, Donn Cave wrote: > Well, the problem inherently requires a certain order of > evaluation. But if you will just handle pattern match failure > in the IO monad, then you can write a simple functional > expression of the problem instead, > > let (i, s') = decodeInt s in > let (v, _) = decodeInt s' in > (i, v) > > ... where I think `i' can be evaluated without forcing unnecessary > evaluation of v. It's clearer, and avoids unnecessary strictness! Unless of course you don't have an IO monad handy. The issue is that exception handling semantics do induce an order of evaluation for determinacy: if both functions in a composition throw an exception at some point (say in the 3rd element of a list they're generating), you need to decide which exception ends up being thrown, and to do that based on the lazy evaluation order would break referential transparency. It bugs me a little how good Haskell is with laziness, but how bad it gets when you need laziness with a slightly different structure. I don't see any way it could reasonably be "fixed" if I were designing my own language, it's just unsettling. Luke From lemming at henning-thielemann.de Thu Mar 13 02:35:19 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu Mar 13 02:31:11 2008 Subject: [Haskell-cafe] Exception handling when using STUArray In-Reply-To: <00B5B0D7-2074-4A03-99EF-D5DC84A6A480@avvanta.com> References: <87wsod6ax8.fsf@columbia.edu> <6dbd4d000803080631s5d16e43cr7f7b2623c932b175@mail.gmail.com> <989AC059-9B60-40A1-9ECF-2CC9AC47D19E@fastmail.fm> <2BDDF536-5617-405C-83C2-C9E56333B3F6@ece.cmu.edu> <58308741-7D24-42AB-BF9C-8E777C5EE9D4@avvanta.com> <831CF579-6B18-4519-89E5-29F676AFB40B@ece.cmu.edu> <4D60723B-5699-456B-8546-72AE6700692F@avvanta.com> <00B5B0D7-2074-4A03-99EF-D5DC84A6A480@avvanta.com> Message-ID: On Wed, 12 Mar 2008, Donn Cave wrote: > On Mar 12, 2008, at 2:10 PM, Henning Thielemann wrote: > >> On Wed, 12 Mar 2008, Donn Cave wrote: >> >>> On Mar 12, 2008, at 12:32 PM, Brandon S. Allbery KF8NH wrote: >>> >>>> On Mar 12, 2008, at 14:17 , Donn Cave wrote: >>>>> Sure. It isn't a lot of code, so I subjected it to Either-ization >>>>> as an experiment, and I did indeed take the monad procedural route. >>>> Monad != procedural, unless you insist on do notation. Think of it as >>>> composition (it may be easier to use (=<<) which "points the same >>>> direction" as (.)). >>> >>> Yes, I insist on do notation, because it provides a convenient >>> binding form that works with what I'm doing - the original functional >>> variation wasn't so suited to composition either, and used `let'. >>> >>> But I see that as only syntactic - equally procedural, either way. >>> Expressions are evaluated in a fixed order, >> >> Do notation only looks like there are statements that are processed from >> the beginning to the end. But that's not true, it's still purely lazy and >> expressions are evaluated in the order that is forced by data dependencies. > > > Let me put it this way: if I write > > do > (i, s') <- decodeInt s > (v, _) <- decodeInt s' > return (i, v) > > ... instead of, to just avoid the monad stuff > > case (decodeInt s) of > Left e -> Left e > Right (i, s') -> case (decodeInt s') of > Left e -> Left e > Right (v, _) -> Right (i, v) Since the decision between Left and Right requires all parts to be evaluated, it's Either that might too strict for your application. What about a writer monad, where exceptions, or better say warnings, are written to the writer stream? From lemming at henning-thielemann.de Thu Mar 13 02:54:10 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu Mar 13 02:50:02 2008 Subject: [Haskell-cafe] floating point operations and representation In-Reply-To: <20080313045748.GA11783@scytale.galois.com> References: <20080313045748.GA11783@scytale.galois.com> Message-ID: On Wed, 12 Mar 2008, Don Stewart wrote: >> I am under the restriction that I need to write Haskell programs using >> Double which mimic existing C/C++ programs or generated data sets, and >> get the same answers. (It's silly, but take it as a given >> requirement.) If the C programs are using "log2", then I need "log2" >> in the Haskell, or else I run the risk of not producing the same >> answers. > > Hey Jacob, > > Just to make life super simple, I packaged up a binding to the basic > math.h library for Doubles. You can find the library here: > > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/cmath > > For example, > > Prelude> Foreign.C.Math.Double.log10 5 > 0.6989700043360189 > > Prelude> log 5 / log 10 > 0.6989700043360187 You may want to write a RULES pragma which replaces occurences of 'logBase 2' and 'logBase 10' by their specialised counterparts. From ahey at iee.org Thu Mar 13 03:00:47 2008 From: ahey at iee.org (Adrian Hey) Date: Thu Mar 13 02:57:54 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: <20080312194804.o14f2bxhcwgo00sw@webmail.spamcop.net> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <47D5416C.808@iee.org> <871w6i8wx4.fsf@nmd9999.imr.no> <47D55287.5040701@iee.org> <404396ef0803100829h44c8ac1dg4ee6f0132cb4f929@mail.gmail.com> <47D56B7A.2030200@iee.org> <220e47b40803101207w6d4bb795k68d959b3ccff9849@mail.gmail.com> <47D5A46A.5010800@iee.org> <404396ef0803101433s435bbc64j46617fe50ba46aa5@mail.gmail.com> <47D63C44.7070704@iee.org> <6dbd4d000803110846k3fcb94a8k9ad780c2dd8272fc@mail.gmail.com> <47D6B140.4010002@iee.org> <47D7E0F5.6090907@jellybean.co.uk> <20080312194804.o14f2bxhcwgo00sw@webmail.spamcop.net> Message-ID: <47D8D11F.3010002@iee.org> ajb@spamcop.net wrote: > G'day all. > > Adrian Hey wrote: > >>> This might be a reasonable thing to say about *sortBy*, but not sort >>> as the ordering of equal elements should not be observable (for any >>> correct instance of Ord). It should be impossible to implement a >>> function which can discriminate between [a,a],[a,b],[b,a],[b,b] if >>> compare a b = EQ. > > Nonsense. Consider a Schwartzian transform wrapper: > > data OrdWrap k v = OrdWrap k v > > instance (Ord k) => Ord (OrdWrap k v) where > compare (OrdWrap k1 v1) (OrdWrap k2 v2) = OrdWrap k1 k2 I take it you mean something like .. instance Ord k => Ord (OrdWrap k v) where compare (OrdWrap k1 v1) (OrdWrap k2 v2) = compare k1 k2 Where's the Eq instance for OrdWrap? This may or may not satisfy the law: (compare a b) = EQ implies (a == b) = True. I think everbody agrees about that, but I can't tell from the code you've posted if it does in this case. What's disputed is whether or not this law should hold: (a == b) = True implies a = b Again, I can't tell if it does or not in this case, but I assume the point of your post is that it doesn't. AFAICT the report is ambiguous about this, or at least the non-intutive equality semantics are not at all clear to me from what I can see in the Eq class definition (para 6.3.1). I think an the absence of any clear and *explicit* statement to the contrary people are entitled to assume this law is mandatory for all (correct) Eq instances. > It would be incorrect (and not sane) for sort [a,b] to return [a,a] in > this case, though a case could be made that either [a,b] or [b,a] make > sense. > > Quoting Jules Bean : > >> Stability is a nice property. I don't understand why you are arguing >> against this so aggressiviely. > > Stability is an occasionally very useful property. However, if there > is a tradeoff between stability and performance, I'd prefer it if the > library didn't choose for me. Well I hope you or anyone else hasn't used Data.Map or with OrdWrap keys because if so it's likely that the code has either been broken in the past, or is broken now (not sure which). But the equality semantics some people seem to want seem to me like a very good way to guarantee that similar bugs and ambiguities will occur all over the place, now and forever. Regards -- Adrian Hey From dekudekuplex at yahoo.com Thu Mar 13 03:49:29 2008 From: dekudekuplex at yahoo.com (Benjamin L. Russell) Date: Thu Mar 13 03:46:34 2008 Subject: [Haskell-cafe] An offer to any haskell projects out there. In-Reply-To: <4683d9370803121547n621255cbqabe2a9235c2e3f6b@mail.gmail.com> Message-ID: <286645.93522.qm@web30204.mail.mud.yahoo.com> I am also interested in helping out in this manner, particularly with HaskellWiki. I work as a patent translator in Tokyo, and my specialty is technical translation. In particular, I could help write English-language documentation on Haskell and also translate such documentation into Japanese for Japanese readers in my spare time. Although I took a course in formal semantics in college (under Paul Hudak at Yale, actually) many years ago and studied some beginning Haskell at that time, I haven't had much time to study Haskell since then, and am still a beginner at the language. However, I've been able to set aside some time to study Haskell formally recently, and should be able to help out soon. If anybody is interested in setting up a Japanese-language version of HaskellWiki, please let me know. Haskell is starting to become well-known here in Japan, and there are even two Japanese-language textbooks on Haskell sold in Japanese bookstore. What is probably needed is more online Japanese-language documentation. Benjamin L. Russell --- Tim Chevalier wrote: > On 3/12/08, Don Stewart wrote: > > One of the best things you could do would be to > submit patches against > > the core library set where documentation is > missing. Starting > > with things in base, array, containers, > directory, filepath, pretty, > > time etc. > > > > That would likely help the largest number of > users. > > > > Patches to these libraries can be submitted to > the libraries@haskell.org > > list. > > > > To elaborate ever so slightly on what Don said: A > lot of libraries > only have type signatures for functions in the > libraries as > "documentation". What's missing is English > descriptions of what the > functions really do. You yourself may not know what > the functions do, > but you can learn by experimenting with the > libraries (writing little > programs that use the functions) and by asking on > this mailing list > (and reading old posts in the archive), if > necessary. > > It would be really useful if you decided to put time > into this. Thanks > in advance! > > Cheers, > Tim > > -- > Tim Chevalier * http://cs.pdx.edu/~tjc * Often in > error, never in doubt > "You never have to aspire to difficulty, darling. It > arrives, > uninvited. Then it stays for dinner."--Sue Miller > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From emax at cs.chalmers.se Thu Mar 13 04:00:30 2008 From: emax at cs.chalmers.se (Emil Axelsson) Date: Thu Mar 13 03:57:48 2008 Subject: [Haskell-cafe] Template Haskell -- when are things evaluated? Message-ID: <47D8DF1E.4070909@cs.chalmers.se> Hello all! Up until yesterday I thought I understood the basics of Template Haskell, but now I'm a little confused. Consider the following code module A where a1 = [| (2::Int) + 2 |] a2 = let x = (2::Int) + 2 in [| x |] a3 = [| y |] where y = (2::Int) + 2 z = (2::Int) + 2 a4 = [| z |] module B where import A a1S = $a1 a2S = $a2 a3S = $a3 a4S = $a4 I'd have thought that in all four cases the addition was evaluated at compile-time, but compiling with -ddump-splices reveals that this is only the case for a2 and a3. Is there a general reliable rule for when things are evaluated? Thanks, / Emil From lrpalmer at gmail.com Thu Mar 13 04:08:21 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Thu Mar 13 04:05:24 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: <47D8D11F.3010002@iee.org> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <220e47b40803101207w6d4bb795k68d959b3ccff9849@mail.gmail.com> <47D5A46A.5010800@iee.org> <404396ef0803101433s435bbc64j46617fe50ba46aa5@mail.gmail.com> <47D63C44.7070704@iee.org> <6dbd4d000803110846k3fcb94a8k9ad780c2dd8272fc@mail.gmail.com> <47D6B140.4010002@iee.org> <47D7E0F5.6090907@jellybean.co.uk> <20080312194804.o14f2bxhcwgo00sw@webmail.spamcop.net> <47D8D11F.3010002@iee.org> Message-ID: <7ca3f0160803130108j63efdfb5h9ffe85fb9f62e04b@mail.gmail.com> On Thu, Mar 13, 2008 at 1:00 AM, Adrian Hey wrote: > AFAICT the report is ambiguous about this, or at least the non-intutive > equality semantics are not at all clear to me from what I can see in > the Eq class definition (para 6.3.1). I think an the absence of any > clear and *explicit* statement to the contrary people are entitled to > assume this law is mandatory for all (correct) Eq instances. In mathematics we usually *don't* assume things that aren't stated assumptions. Luke From alfonso.acosta at gmail.com Thu Mar 13 04:49:17 2008 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Thu Mar 13 04:46:19 2008 Subject: [Haskell-cafe] Template Haskell -- when are things evaluated? In-Reply-To: <47D8DF1E.4070909@cs.chalmers.se> References: <47D8DF1E.4070909@cs.chalmers.se> Message-ID: <6a7c66fc0803130149n6b452127l390563e96d65ccf5@mail.gmail.com> Hi Emil, Your problem is related to "how are things evaluated" not "when". The short answer is: if you want to make sure an expression is evaluated before you lift it, don't use quasiquotes, call Language.Haskell.TH.lift On Thu, Mar 13, 2008 at 9:00 AM, Emil Axelsson wrote: > a1 = [| (2::Int) + 2 |] You are lifting the expression AST, not its evaluation. a1 = lift ((2::Int) + 2) would work as you want. > a2 = let x = (2::Int) + 2 in [| x |] here you are enclosing a local variable in quasiquotes and, thus, [| x |] is equivalent to "lift x" > a3 = [| y |] > where > y = (2::Int) + 2 Same as in a2, y is local. Therefore [| y |] is equivalent to "lift y" > z = (2::Int) + 2 > > a4 = [| z |] z is a global variable and [| z |] is lifted to a variable expression (i.e. a4 is equivalent to "varE 'z" ) From simonpj at microsoft.com Thu Mar 13 04:54:03 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu Mar 13 04:51:07 2008 Subject: [Haskell-cafe] Termination of substitution In-Reply-To: <404396ef0803121405q51e4dd58h856e37cb64ff6ff3@mail.gmail.com> References: <404396ef0803121405q51e4dd58h856e37cb64ff6ff3@mail.gmail.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C3248F5FEE76@EA-EXMSG-C334.europe.corp.microsoft.com> As Stefan says, System Fw is strongly normalising. This is a remarkable result because (as you observe) it's very non-obvious how to prove it. However GHC goes beyond Fw by adding data types letrec This blows strong normalisation out of the water. (Assuming you have reasonable rules for case and letrec.) But perhaps if you restrict data types a bit, and place draconian restrictions on letrec (e.g. never inline one) you could retain strong normalisation. It depends how much you want your rules to do. GHC's simplifier deals with the letrec problem by cutting each recursive loop -- see the paper "Secrets of the GHC inliner". GHC doesn't solve the data type problem at all -- you can make the Simplifier loop if you try. Simon | -----Original Message----- | From: haskell-cafe-bounces@haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Neil Mitchell | Sent: 12 March 2008 21:05 | To: Haskell Cafe | Subject: [Haskell-cafe] Termination of substitution | | Hi | | I'm trying to show that a system of rules for manipulating Haskell | expressions is terminating. The rules can be applied in any order, to | any subexpression - and there is a problem if there is any possible | infinite sequence. | | The rule that is giving me particular problems is: | | (\v -> x) y => x[v/y] | | (I realise this rule may duplicate the computation of y, but that is | not relevant for this purpose.) | | In particular, given the expression | | (\x -> x x) (\x -> x x) | | we can keep applying this rule infinitely. | | However, I don't believe this expression is type safe in Haskell. Are | any such expressions that would cause this to non-terminate not type | safe? What are the necessary conditions for this to be safe? Does GHC | perform lambda reduction, probably by introducing a let binding? Does | the combination of reducing lambdas and creating let bindings give | similar problems, particularly if bindings are inlined? | | I'm wondering if this rule is genuinely unsafe in Haskell. If it is, | why isn't it an issue in real simplifiers. If it isn't, what makes it | safe. | | Thanks for any help, | | Neil | _______________________________________________ | Haskell-Cafe mailing list | Haskell-Cafe@haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe From ahey at iee.org Thu Mar 13 05:02:33 2008 From: ahey at iee.org (Adrian Hey) Date: Thu Mar 13 04:59:39 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: <7ca3f0160803130108j63efdfb5h9ffe85fb9f62e04b@mail.gmail.com> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <220e47b40803101207w6d4bb795k68d959b3ccff9849@mail.gmail.com> <47D5A46A.5010800@iee.org> <404396ef0803101433s435bbc64j46617fe50ba46aa5@mail.gmail.com> <47D63C44.7070704@iee.org> <6dbd4d000803110846k3fcb94a8k9ad780c2dd8272fc@mail.gmail.com> <47D6B140.4010002@iee.org> <47D7E0F5.6090907@jellybean.co.uk> <20080312194804.o14f2bxhcwgo00sw@webmail.spamcop.net> <47D8D11F.3010002@iee.org> <7ca3f0160803130108j63efdfb5h9ffe85fb9f62e04b@mail.gmail.com> Message-ID: <47D8EDA9.1050800@iee.org> Luke Palmer wrote: > On Thu, Mar 13, 2008 at 1:00 AM, Adrian Hey wrote: >> AFAICT the report is ambiguous about this, or at least the non-intutive >> equality semantics are not at all clear to me from what I can see in >> the Eq class definition (para 6.3.1). I think an the absence of any >> clear and *explicit* statement to the contrary people are entitled to >> assume this law is mandatory for all (correct) Eq instances. > > In mathematics we usually *don't* assume things that aren't stated > assumptions. But the trouble is the report says practically *nothing* about Eq class or what the (==) operator means. It all seems to be assumed, and even when it does talk about it informally it talks about "equality", not "equivalence" or some other word. The report doesn't state that for all Ints, (x==y = True) implies that x=y. There's no reason to suppose the Int instance is in any way special, so do you really seriously consider the possibility that this might not hold in your Int related code? if (x==y) then f x else g x y might not mean the same as.. if (x==y) then f y else g x y Regards -- Adrian Hey From Christian.Maeder at dfki.de Thu Mar 13 05:11:04 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Thu Mar 13 05:08:10 2008 Subject: [Haskell-cafe] Re: unification In-Reply-To: References: <47d18886$0$21194$5fc30a8@news.tiscali.it> <47d2a52c$0$26443$5fc30a8@news.tiscali.it> <47d7d0d0$0$21205$5fc30a8@news.tiscali.it> <47D7DE5E.5090202@dfki.de> Message-ID: <47D8EFA8.5090801@dfki.de> andrea wrote: >> data Tipo = Var Int | Const String | Tipo :-> Tipo deriving (Show, Eq) >> > But now how can I do to make the set of Const fixed?? > I want just a few base types, like "int" and "string", how could I > define it? your base types could be: Const "String" :: Tipo Const "Int" :: Tipo and the polymorphic type of the identity function could be: Var 1 :-> Var 1 :: Tipo (and with "infixr :->") the type of binary function like (+) Const "Int" :-> Const "Int" :-> Const "Int" Note: the data type does not support type constructors like "List". I recommend from: http://www.haskell.org/haskellwiki/Research_papers/Type_systems Typing Haskell in Haskell The first few pages will be enough (substitution is on page 7) However, the link http://www.cse.ogi.edu/~mpj/pubs/thih.html does not work for me Could someone correct that link? Christian From ketil at malde.org Thu Mar 13 05:12:46 2008 From: ketil at malde.org (Ketil Malde) Date: Thu Mar 13 05:09:42 2008 Subject: [Haskell-cafe] floating point operations and representation In-Reply-To: <8e47d1720803121735j17343d57x49fff089123f889b@mail.gmail.com> (Jacob Schwartz's message of "Wed\, 12 Mar 2008 20\:35\:46 -0400") References: <8e47d1720803121735j17343d57x49fff089123f889b@mail.gmail.com> Message-ID: <877ig7ugvl.fsf@nmd9999.imr.no> "Jacob Schwartz" writes: > A test on IEEE computers (x86 and x86-64), shows that for > a range of 64-bit "double" values, the answers in C do differ (in the > last bit) if you use "log2(x)" and "log10(x)" versus "log (x) / > log(2)" and "log(x) / log(10)". I think this may also depend on C compiler and optimization level. Perhaps now everybody uses SSE to do math, but earlier Intel FPU architectures did floating point with 80-bit registers, so the accuracy of the result could depend on whether an intermediate result was flushed to memory (by a context switch). Equality on floating point is tricky, if I were you, I'd round the results before comparing. -k -- If I haven't seen further, it is by standing in the footprints of giants From lrpalmer at gmail.com Thu Mar 13 05:28:58 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Thu Mar 13 05:26:01 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: <47D8EDA9.1050800@iee.org> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <404396ef0803101433s435bbc64j46617fe50ba46aa5@mail.gmail.com> <47D63C44.7070704@iee.org> <6dbd4d000803110846k3fcb94a8k9ad780c2dd8272fc@mail.gmail.com> <47D6B140.4010002@iee.org> <47D7E0F5.6090907@jellybean.co.uk> <20080312194804.o14f2bxhcwgo00sw@webmail.spamcop.net> <47D8D11F.3010002@iee.org> <7ca3f0160803130108j63efdfb5h9ffe85fb9f62e04b@mail.gmail.com> <47D8EDA9.1050800@iee.org> Message-ID: <7ca3f0160803130228w34c7e05csbf3d50fea161fe0b@mail.gmail.com> On Thu, Mar 13, 2008 at 3:02 AM, Adrian Hey wrote: > The report doesn't state that for all Ints, (x==y = True) implies that > x=y. There's no reason to suppose the Int instance is in any way > special, so do you really seriously consider the possibility that > this might not hold in your Int related code? > > if (x==y) then f x else g x y > > might not mean the same as.. > > if (x==y) then f y else g x y Of course not :-). However, on what grounds am I to assume that these two will be semantically equivalent for instances other than Int? Int *is* special insofar as its implementation of Eq differs from that of other types (of course, all other instances of Eq are special then, too). So it's reasonable that == means observational equivalence for Int but not for other types, since it's possible to implement them that way and there is no (explicitly stated) law which requires it. But I agree that Eq should have some laws, just maybe not observational equivalence because it is very limiting from a user's perspective (that is, if I have a data type, requiring observational equivalence makes it much less likely that I will be able to write an instance of Eq, even if it makes sense in some stretch of the imagination). Saying that it's reasonable for everyone, everywhere to assume that Eq means what you want it to mean is a stretch. I believe every for function I've written which was polymorphic in Eq it would have sufficed for Eq to be any equivalence relation. What reason do I have to restrict the users of my functions to those who can implement observational equivalence? But I'm just blabbering. Here's my position on the issue with an argument for why I think it's a good one: Eq should be allowed to be any equivalence relation, because there are many data types for which it is impossible to satisfy the constraint of observational equivalence, thus reducing the usefulness of data structures written over types with Eq. On the other hand, (and this is anecdotal), no data structures have been unable to cope with Eq not implying observational equivalence. Here's another argument. Since Eq has no stated laws in the report, give Eq no assumptions*, and allow the community to create an empty subclass of Eq (ObsEq, say) which documents the necessary laws. Then a data structure which relies on the observational equivalence property can specify it explicitly. But really the thing that makes me choose this position is that it sucks not to be able to use someone's code only because it is impossible to satisfy instance laws, even though the code would be perfectly reasonable anyway (though it isn't a strong argument, consider the case of the broken ListT, still, it's enough to convince me for the time being). * No assumptions at all would be strange, but also okay with me, as long as functions which rely on Eq specify that they need it to conform to certain laws. But I consider equivalence relation reasonable because (1) everyone here seems to be on common ground that it should *at least* be that, and (2) all the prelude functions on Eq assume that (and note that none assume obs. eq.). Indeed, "group" is almost meaningless if Eq imples obs. eq. Luke From ahey at iee.org Thu Mar 13 05:30:42 2008 From: ahey at iee.org (Adrian Hey) Date: Thu Mar 13 05:27:50 2008 Subject: Some clarity please! (was Re: [Haskell-cafe] Re: (flawed?) benchmark : sort) In-Reply-To: References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <47D52A87.9060805@iee.org> <404396ef0803100632w6ae183f3w467aa02bae40caa2@mail.gmail.com> <47D5416C.808@iee.org> <871w6i8wx4.fsf@nmd9999.imr.no> <47D55287.5040701@iee.org> <404396ef0803100829h44c8ac1dg4ee6f0132cb4f929@mail.gmail.com> <47D56B7A.2030200@iee.org> <220e47b40803101207w6d4bb795k68d959b3ccff9849@mail.gmail.com> <47D5A46A.5010800@iee.org> <404396ef0803101433s435bbc64j46617fe50ba46aa5@mail.gmail.com> <47D63C44.7070704@iee.org> <47D8345A.9000201@iee.org> Message-ID: <47D8F442.40704@iee.org> Hello All, I'm top posting because I'm getting bored and frustrated with this thread and I don't want to respond detail to everything Aaron has said below. Aaron: Where are you getting this equivalence stuff from? Searching the report for the word "equivalence" the only remotely relevant section seems to be in para. 17.6.. "When the ?By? function replaces an Eq context by a binary predicate, the predicate is assumed to define an equivalence" Which is fair enough, but this is talking about the argument of "By" functions. The Haskell wiki refers me to wikipedia, which contains the words "In Haskell, a class Eq intended to contain types that admit equality would be declared in the following way" http://en.wikipedia.org/wiki/Type_class Not that this is necessarily authoritative, but it seems to be contaradicting some peoples interpretation. Also, on page 60 of the report I find the words "Even though the equality is taken at the list type.." So I don't know if all this is really is the correct reading of the report, but if so would like to appeal to movers and shakers in the language definition to please decide exactly what the proper interpretation of standard Eq and Ord "class laws" are and in the next version of the report give an explanation of these in plain English using terms that people without a Mathematics degree are likely to understand. Aaron's interpretation may indeed be very correct and precise, but I fear in reality this is just going to be incomprehensible to many programmers and a terrible source of bugs in "real world" code. I cite previous "left biasing" bugs Data.Map as evidence. I would ask for any correct Eq instance something like the law: (x==y) = True implies x=y (and vice-versa) which implies f x = f y for all definable f which implies (f x == f y) = True (for expression types which are instances of Eq). This pretty much requires structural equality for concrete types. For abstract types you can do something different provided functions which can give different answers for two "equal" arguments are not exposed. Anything else is just wrong (according to the language specification, even if it can be right in some mathematical sense). Before anyone jumps down my throat, I remind you that this is a request, not an assertion! :-) On the subject of ambiguity, bugs and maxima, I see we have in Data.List -- | 'maximum' returns the maximum value from a list, -- which must be non-empty, finite, and of an ordered type. -- It is a special case of 'Data.List.maximumBy', which allows the -- programmer to supply their own comparison function. maximum :: (Ord a) => [a] -> a maximum [] = errorEmptyList "maximum" maximum xs = foldl1 max xs -- | The 'maximumBy' function takes a comparison function and a list -- and returns the greatest element of the list by the comparison function. -- The list must be finite and non-empty. maximumBy :: (a -> a -> Ordering) -> [a] -> a maximumBy _ [] = error "List.maximumBy: empty list" maximumBy cmp xs = foldl1 max xs where max x y = case cmp x y of GT -> x _ -> y So I believe I'm correct in saying that maximumBy returns the last of several possible maximum elements of the list. This obviously needs specifying in the Haddock. Because maximumBy documentation is ambiguous in this respect, so is the overloaded maximum documentation. At least you can't figure it out from the Haddock. Despite this ambiguity, the statement that maximum is a special case of maximumBy is true *provided* max in the Ord instance is defined the way Aaron says is should be: (x==y = True) implies max x y = y. But it could be be made unconditionally true using.. maximum :: Ord a => [a] -> a maximum [] = error "List.maximum: empty list" maximum xs = maximumBy compare xs AFAICT, the original report authors either did not perceive an ambiguity in maximum, or just failed to notice and resolve it. If there is no ambiguity this could be for 2 reasons. 1 - It doesn't matter which maximum is returned because: (x==y) = True implies x=y 2 - It does matter, and the result is guaranteed to be the last maximum in all cases because: (x==y) = True implies max x y = y But without either of the above, it is unsafe to assume maximum = maximumBy compare Regarding the alleged "max law" this too is not mentioned in the Haddock for the Ord class, nor is it a "law" AFAICT from reading the report. The report (page 83) just says that the default methods are "reasonable", but presumably not manditory in any semantic sense. This interpretation also seems to be the intent of this from the second para. of Chapter 8: "The default method definitions, given with class declarations, constitute a specification only of the default method. They do not constitute a specification of the meaning of the method in all instances." I wouldn't dispute that the default definition is reasonable, but it's certainly not clear to me from the report that it's something that I can safely assume for all Ord instances. In fact AFAICS the report quite clearly telling me *not* to assume this. But I have to assume *something* for maximum to make sense, so I guess that must be: (x==y) = True implies x=y IOW "I have no idea if it's the first or last maximum that is returned, but who cares?" Again, the report doesn't make it clear that the (==) law above holds (at least not on page 82). But I think in the absence of any explicit statement to the contary I think most programmers would assume that it does apply. I think this is quite reasonable and I have no intention of changing my programming habits to cope with weird instances for which: (x == y) = True does not imply x=y or max x y is not safely interchangeble with max y x. I'm not saying some people are not right to want classes with more mathematically inspired "laws", but I see nothing in the report to indicate to me that Eq/Ord are those classes and consequently that the "naive" programmers interpretation of (==) is incorrect. Rather the contrary in fact. Regards -- Adrian Hey Aaron Denney wrote: > On 2008-03-12, Adrian Hey wrote: >> Aaron Denney wrote: >>> On 2008-03-11, Adrian Hey wrote: >>>> Having tried this approach myself too (with the clone) I can confirm >>>> that *this way lies madness*, so in future I will not be making >>>> any effort to define or respect "sane", unambiguous and stable behaviour >>>> for "insane" Eq/Ord instances for any lib I produce or hack on. Instead >>>> I will be aiming for correctness and optimal efficiency on the >>>> assumption that Eq and Ord instances are sensible. >>> Good. But sensible only means that the Eq and Ord instances agree, not that >>> x == y => f x == f y. >> So can I assume that max x y = max y x? > > No. You can, however, assume that max x y == max y x. (Okay, this > fails on Doubles, because of NaN. I'll agree that the Eq and Ord > instances for Double are not sane.) > >> If not, how can I tell if I've made the correct choice of argument >> order. > > When calling, or when defining max? > > It depends on what types you're using, and which equivalence and > ordering relations are being used. > > When calling, and when it might matter which representative of an > equivalence class comes back out (such as in sorts) you have no choice > but to look at the documentation or implementation of max. > > The Haskell report guarantees that x == y => max x y = y (and hence max > y x = x), and the opposite choice for min. This is to ensure that (min > x y, max x y) = (x,y) or (y,x). IOW, the report notices that choice of > representatives for equivalence classes matters in some circumstances, > and makes it easy to do the right thing. This supports the reading that > Eq a is not an absolute equality relation, but an equivalence relation. > >> If I can't tell then I guess I have no alternative but document >> my arbitrary choice in the Haddock, and probably for the (sake of >> completeness) provide 2 or more alternative definitions of the "same" >> function which use a different argument order. > > When defining max, yes, you must take care to make sure it useable for > cases when Eq is an equivalence relation, rather than equality. > > If you're writing library code, then it won't generally know whether > Eq means true equality rather than equivalence. If this would let > you optimize things, you need some other way to communicate this. > > The common typeclasses are for generic, parameterizable polymorphism. > Equivalence is a more generally useful notion than equality, so that's > what I want captured by the Eq typeclass. > > And no, an overloaded sort doesn't belong in Ord, either. If the > implementation is truly dependent on the types in non-trivial, > non-susbstitutable ways (i.e. beyond a substition of what <= means), > then they should be /different/ algorithms. > > It would be possible to right an "Equal a" typeclass, which does > guarantee actual observable equality (but has no methods). Then you can > write one equalSort (or whatever) of type > equalSort :: (Eq a, Ord a, Equal a) => [a] -> [a] > that will work on any type willing to guarantee this, but rightly fail > on types that only define an equivalence relation. > > A stable sort is more generally useful than an unstable one. It's > composable for radix sorting on compound structures, etc. > Hence we want to keep this guarantee. > From wnoise at ofb.net Thu Mar 13 05:33:27 2008 From: wnoise at ofb.net (Aaron Denney) Date: Thu Mar 13 05:30:38 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <220e47b40803101207w6d4bb795k68d959b3ccff9849@mail.gmail.com> <47D5A46A.5010800@iee.org> <404396ef0803101433s435bbc64j46617fe50ba46aa5@mail.gmail.com> <47D63C44.7070704@iee.org> <6dbd4d000803110846k3fcb94a8k9ad780c2dd8272fc@mail.gmail.com> <47D6B140.4010002@iee.org> <47D7E0F5.6090907@jellybean.co.uk> <20080312194804.o14f2bxhcwgo00sw@webmail.spamcop.net> <47D8D11F.3010002@iee.org> <7ca3f0160803130108j63efdfb5h9ffe85fb9f62e04b@mail.gmail.com> <47D8EDA9.1050800@iee.org> Message-ID: On 2008-03-13, Adrian Hey wrote: > But the trouble is the report says practically *nothing* about Eq > class or what the (==) operator means. It all seems to be assumed, > and even when it does talk about it informally it talks about > "equality", not "equivalence" or some other word. > > The report doesn't state that for all Ints, (x==y = True) implies that > x=y. No, it doesn't. However, for Ints, it's the most reasonable natural (and generic) definition. The report should be clarified on this point. > There's no reason to suppose the Int instance is in any way > special, Well, what do you mean by "special"? That it has this additional guarantee? I don't see that as unusual for Eq instances, no. In fact, I expect typical Eq instances to satisfy this. However, if all I know is Eq a, I don't think it can be counted on, so it is special in that sense. Just as, say Maybe a, along with many, or even most other common Monads might satisfy more laws than a generic Monad a, doesn't necessarily make it special. But you can't still write generic Monad code assuming these other properties. Instead, you require MonadPlus instances, or similar for whatever additional properties you need. > so do you really seriously consider the possibility that > this might not hold in your Int related code? > > if (x==y) then f x else g x y > > might not mean the same as.. > > if (x==y) then f y else g x y In Int code, of course not, because I know the types, and I know the behaviour of (==) on Ints. But f is specialized to work on Ints, isn't it, so it's reasonable to know what semantics (==) has for Ints, and depend on them? -- Aaron Denney -><- From bjorn at bringert.net Thu Mar 13 05:42:34 2008 From: bjorn at bringert.net (Bjorn Bringert) Date: Thu Mar 13 05:39:43 2008 Subject: [Haskell-cafe] File I/O question In-Reply-To: <47D8451F.10304@btinternet.com> References: <47D829C4.6090802@btinternet.com> <20080312204233.GF9203@scytale.galois.com> <47D8451F.10304@btinternet.com> Message-ID: On Wed, Mar 12, 2008 at 10:03 PM, Andrew Coppin wrote: > Don Stewart wrote: > > Hey Andrew, > > > > What are you trying to do? Read and write to the same file (if so, you > > need to use strict IO), or are you trying something sneakier? > > > > I have a long-running Haskell program that writes status information to > a log file. I'd like to be able to open and read that log file before > the program has actually terminated. I have a similar program written in > Tcl that allows me to do this, since apparently the Tcl interpretter > doesn't lock output files for exclusive access. Haskell, however, does. > (This seems to be the stipulated behaviour as per the Report.) If > there's an easy way to change this, it would be useful... How about using appendFile? "appendFile :: FilePath -> String -> IO () The computation appendFile file str function appends the string str, to the file file." See http://haskell.org/ghc/docs/latest/html/libraries/base/System-IO.html#v%3AappendFile /Bj?rn From emax at cs.chalmers.se Thu Mar 13 05:50:57 2008 From: emax at cs.chalmers.se (Emil Axelsson) Date: Thu Mar 13 05:48:15 2008 Subject: [Haskell-cafe] Template Haskell -- when are things evaluated? In-Reply-To: <6a7c66fc0803130149n6b452127l390563e96d65ccf5@mail.gmail.com> References: <47D8DF1E.4070909@cs.chalmers.se> <6a7c66fc0803130149n6b452127l390563e96d65ccf5@mail.gmail.com> Message-ID: <47D8F901.1090805@cs.chalmers.se> Aha, I guess I thought for a while that [|x|] and lift x where the same thing. Having thought too much about partial evaluation lately, I forgot that the main purpose of quoting is to get the unevaluated AST. I'll just use lift in the future then (for partial evalutation). Thanks, Alfonso! / Emil On 2008-03-13 09:49, Alfonso Acosta wrote: > Hi Emil, > > Your problem is related to "how are things evaluated" not "when". The > short answer is: if you want to make sure an expression is evaluated > before you lift it, don't use quasiquotes, call > Language.Haskell.TH.lift > > On Thu, Mar 13, 2008 at 9:00 AM, Emil Axelsson wrote: >> a1 = [| (2::Int) + 2 |] > > You are lifting the expression AST, not its evaluation. a1 = lift > ((2::Int) + 2) would work as you want. > > >> a2 = let x = (2::Int) + 2 in [| x |] > > here you are enclosing a local variable in quasiquotes and, thus, [| x > |] is equivalent to "lift x" > >> a3 = [| y |] >> where >> y = (2::Int) + 2 > > Same as in a2, y is local. Therefore [| y |] is equivalent to "lift y" > >> z = (2::Int) + 2 >> >> a4 = [| z |] > > z is a global variable and [| z |] is lifted to a variable expression > (i.e. a4 is equivalent to "varE 'z" ) From wb at arb-phys.uni-dortmund.de Thu Mar 13 05:51:39 2008 From: wb at arb-phys.uni-dortmund.de (Wilhelm B. Kloke) Date: Thu Mar 13 05:48:51 2008 Subject: [Haskell-cafe] Re: floating point operations and representation References: <8e47d1720803121735j17343d57x49fff089123f889b@mail.gmail.com> Message-ID: Jacob Schwartz schrieb: > I have two questions about using the Double data type and the > operations in the Floating typeclass on a computer that uses IEEE > floating point numbers. > > I notice that the Floating class only provides "log" (presumably log > base 'e') and "logBase" (which, in the latest source that I see for > GHC is defined as "log y / log x"). However, in C, the "math.h" > library provides specific "log2" and "log10" functions, for extra > precision. A test on IEEE computers (x86 and x86-64), shows that for > a range of 64-bit "double" values, the answers in C do differ (in the > last bit) if you use "log2(x)" and "log10(x)" versus "log (x) / > log(2)" and "log(x) / log(10)". This is to be expected in about 25% of cases, as the GHC definition rounds two times, whereas the implementation provided in the SUN math library (file lib/msun/src/e_log10.c on FreeBSD) uses a representation in two doubles for log(10) to avoid one of the rounding errors: * Return the base 10 logarithm of x * * Method : * Let log10_2hi = leading 40 bits of log10(2) and * log10_2lo = log10(2) - log10_2hi, * ivln10 = 1/log(10) rounded. * Then * n = ilogb(x), * if(n<0) n = n+1; * x = scalbn(x,-n); * log10(x) := n*log10_2hi + (n*log10_2lo + ivln10*log(x)) -- Dipl.-Math. Wilhelm Bernhard Kloke Institut fuer Arbeitsphysiologie an der Universitaet Dortmund Ardeystrasse 67, D-44139 Dortmund, Tel. 0231-1084-257 PGP: http://vestein.arb-phys.uni-dortmund.de/~wb/mypublic.key From martin.hofmann at uni-bamberg.de Thu Mar 13 05:59:15 2008 From: martin.hofmann at uni-bamberg.de (Martin Hofmann) Date: Thu Mar 13 05:52:04 2008 Subject: [Haskell-cafe] Re: Re: Re: Reflective capabilities of Haskell (cont'd) In-Reply-To: References: Message-ID: <1205402355.5983.37.camel@ios.cogsys.wiai.uni-bamberg.de> On Wed, 2008-03-12 at 15:59 -0400, Jeff Polakow wrote: > > Data.Generics allows you to do this (to a certain extent), i.e. > > there is a function > > > > dataTypeConstrs :: DataType -> [Constr] > > > It might be hard, or even impossible, to get Data.Typeable and > Data.Generics to play with each other. There seems to be no good way > of converting a Data.Typeable.TypeRep to a > Data.Generics.Basics.DataType. > > Another option might be to use Language.Haskell.Parser and > Language.Haskell.Syntax, but I have little experience with this and am > not sure if you'll be able to do what you want. > On Wed, 2008-03-12 at 23:08 -0700, oleg@okmij.org wrote: > > Thanks a lot, this helps a bit, but access to function bodies is exactly > > what I need > Then perhaps you might like the method of reconstructing bodies (of > possibly compiled) functions > http://okmij.org/ftp/Computation/Generative.html#diff-th > in the form of AST -- the template Haskell AST. The reconstructed > bodies of functions can be arbitrarily manipulated (e.g., > _symbolically_ differentiated or algebraically simplified) and then > converted `back' to the compiled code. Thanks for the hints, they all seem to be promising, at least for some part of my problem. I'll try it out whether I can put them together. Cheers, Martin From ahey at iee.org Thu Mar 13 06:01:58 2008 From: ahey at iee.org (Adrian Hey) Date: Thu Mar 13 05:59:05 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: <7ca3f0160803130228w34c7e05csbf3d50fea161fe0b@mail.gmail.com> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <404396ef0803101433s435bbc64j46617fe50ba46aa5@mail.gmail.com> <47D63C44.7070704@iee.org> <6dbd4d000803110846k3fcb94a8k9ad780c2dd8272fc@mail.gmail.com> <47D6B140.4010002@iee.org> <47D7E0F5.6090907@jellybean.co.uk> <20080312194804.o14f2bxhcwgo00sw@webmail.spamcop.net> <47D8D11F.3010002@iee.org> <7ca3f0160803130108j63efdfb5h9ffe85fb9f62e04b@mail.gmail.com> <47D8EDA9.1050800@iee.org> <7ca3f0160803130228w34c7e05csbf3d50fea161fe0b@mail.gmail.com> Message-ID: <47D8FB96.2060800@iee.org> Luke Palmer wrote: > On Thu, Mar 13, 2008 at 3:02 AM, Adrian Hey wrote: >> The report doesn't state that for all Ints, (x==y = True) implies that >> x=y. There's no reason to suppose the Int instance is in any way >> special, so do you really seriously consider the possibility that >> this might not hold in your Int related code? >> >> if (x==y) then f x else g x y >> >> might not mean the same as.. >> >> if (x==y) then f y else g x y > > Of course not :-). However, on what grounds am I to assume that these > two will be semantically equivalent for instances other than Int? Umm..Maybe the fact that you're using the == method from the Eq class, not some Int specific isIntEqual function? :-) Regards -- Adrian Hey From emax at cs.chalmers.se Thu Mar 13 06:13:58 2008 From: emax at cs.chalmers.se (Emil Axelsson) Date: Thu Mar 13 06:11:17 2008 Subject: [Haskell-cafe] Template Haskell -- when are things evaluated? In-Reply-To: <6a7c66fc0803130149n6b452127l390563e96d65ccf5@mail.gmail.com> References: <47D8DF1E.4070909@cs.chalmers.se> <6a7c66fc0803130149n6b452127l390563e96d65ccf5@mail.gmail.com> Message-ID: <47D8FE66.6020108@cs.chalmers.se> I'm reading the following rule from your answer: [|exp|] normally returns the unevaluated AST of exp. However, if exp contains local variables, these are lifted using Language.Haskell.TH.lift (i.e. evaluated before lifting). Is that correct? / Emil On 2008-03-13 09:49, Alfonso Acosta wrote: > Hi Emil, > > Your problem is related to "how are things evaluated" not "when". The > short answer is: if you want to make sure an expression is evaluated > before you lift it, don't use quasiquotes, call > Language.Haskell.TH.lift > > On Thu, Mar 13, 2008 at 9:00 AM, Emil Axelsson wrote: >> a1 = [| (2::Int) + 2 |] > > You are lifting the expression AST, not its evaluation. a1 = lift > ((2::Int) + 2) would work as you want. > > >> a2 = let x = (2::Int) + 2 in [| x |] > > here you are enclosing a local variable in quasiquotes and, thus, [| x > |] is equivalent to "lift x" > >> a3 = [| y |] >> where >> y = (2::Int) + 2 > > Same as in a2, y is local. Therefore [| y |] is equivalent to "lift y" > >> z = (2::Int) + 2 >> >> a4 = [| z |] > > z is a global variable and [| z |] is lifted to a variable expression > (i.e. a4 is equivalent to "varE 'z" ) From ahey at iee.org Thu Mar 13 06:15:13 2008 From: ahey at iee.org (Adrian Hey) Date: Thu Mar 13 06:12:22 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <220e47b40803101207w6d4bb795k68d959b3ccff9849@mail.gmail.com> <47D5A46A.5010800@iee.org> <404396ef0803101433s435bbc64j46617fe50ba46aa5@mail.gmail.com> <47D63C44.7070704@iee.org> <6dbd4d000803110846k3fcb94a8k9ad780c2dd8272fc@mail.gmail.com> <47D6B140.4010002@iee.org> <47D7E0F5.6090907@jellybean.co.uk> <20080312194804.o14f2bxhcwgo00sw@webmail.spamcop.net> <47D8D11F.3010002@iee.org> <7ca3f0160803130108j63efdfb5h9ffe85fb9f62e04b@mail.gmail.com> <47D8EDA9.1050800@iee.org> Message-ID: <47D8FEB1.4020301@iee.org> Aaron Denney wrote: >> so do you really seriously consider the possibility that >> this might not hold in your Int related code? >> >> if (x==y) then f x else g x y >> >> might not mean the same as.. >> >> if (x==y) then f y else g x y > > In Int code, of course not, because I know the types, and I know the > behaviour of (==) on Ints. But f is specialized to work on Ints, isn't > it, so it's reasonable to know what semantics (==) has for Ints, and > depend on them? Why are Ints special in this way? Couldn't you use say exacly the same about any type (just substitute type "X" of your choice for "Int") IMO if your going to define a type X which is intended to be an Eq instance you should always ensure, one way or another that all exposed primitives that operate on that type respect equality, as defined by == for the instance method. (And hence more complex functions built on those primitives do too). Just MO, the report doesn't make this clear 1 way or another AFAICS. Regards -- Adrian Hey From wnoise at ofb.net Thu Mar 13 06:45:51 2008 From: wnoise at ofb.net (Aaron Denney) Date: Thu Mar 13 06:43:03 2008 Subject: [Haskell-cafe] Re: Some clarity please! (was Re: Re: (flawed?) benchmark : sort) References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <47D52A87.9060805@iee.org> <404396ef0803100632w6ae183f3w467aa02bae40caa2@mail.gmail.com> <47D5416C.808@iee.org> <871w6i8wx4.fsf@nmd9999.imr.no> <47D55287.5040701@iee.org> <404396ef0803100829h44c8ac1dg4ee6f0132cb4f929@mail.gmail.com> <47D56B7A.2030200@iee.org> <220e47b40803101207w6d4bb795k68d959b3ccff9849@mail.gmail.com> <47D5A46A.5010800@iee.org> <404396ef0803101433s435bbc64j46617fe50ba46aa5@mail.gmail.com> <47D63C44.7070704@iee.org> <47D8345A.9000201@iee.org> <47D8F442.40704@iee.org> Message-ID: On 2008-03-13, Adrian Hey wrote: > Hello All, > > I'm top posting because I'm getting bored and frustrated with this > thread and I don't want to respond detail to everything Aaron has said > below. > > Aaron: Where are you getting this equivalence stuff from? Not from the prose in the report, but from what the code in the report seems designed to support. There are several places where the code seems to take a (small -- much usually isn't needed) bit of care to support equivalencies. > So I don't know if all this is really is the correct reading of the > report, but if so would like to appeal to movers and shakers in the > language definition to please decide exactly what the proper > interpretation of standard Eq and Ord "class laws" are and in the > next version of the report give an explanation of these in plain > English using terms that people without a Mathematics degree are > likely to understand. I agree that the prose of the report should be clarified. Luke Palmer's message in haskell-cafe captures why I think that "Eq means equivalence, not strict observational equality" is a more generally useful notion. It's harder to guarantee observational equality, thus harder to use code that requires it of your types. Almost all the time (in my experience) equivalencies are all that's generically needed. My comments on this particular message are below. > Because maximumBy documentation is ambiguous in this respect, so is the > overloaded maximum documentation. At least you can't figure it out from > the Haddock. True. > Despite this ambiguity, the statement that maximum is a special case of > maximumBy is true *provided* max in the Ord instance is defined the way > Aaron says is should be: (x==y = True) implies max x y = y. Well, the way the report specifies that max's default definition is. I'd actually favor making that not an instance function at all, and instead have max and min be external functions. > AFAICT, the original report authors either did not perceive an > ambiguity in maximum, or just failed to notice and resolve it. > If there is no ambiguity this could be for 2 reasons. > > 1 - It doesn't matter which maximum is returned because: > (x==y) = True implies x=y > > 2 - It does matter, and the result is guaranteed to be the > last maximum in all cases because: > (x==y) = True implies max x y = y The second holds, so long as max isn't redefined. I'd be rather surprised at any redefinitino of max, as it's not part of any minimum definition for Ord, and I can't think of an actual optimization case for it. > Regarding the alleged "max law" this too is not mentioned in the > Haddock for the Ord class, nor is it a "law" AFAICT from reading the > report. The report (page 83) just says that the default methods are > "reasonable", but presumably not manditory in any semantic sense. > This interpretation also seems to be the intent of this from the > second para. of Chapter 8: Agreed. Elevating this to a "law" in my previous message was a mistake on my part. I still think this default in combination with the comment is very suggestive that (min x y, max x y) should preserve distinctness of elements. If you're unwilling to count on this holding for arbitrary Ord instances, why are you willing to count on (/=) and (==) returning opposite answers for arbitrary Eq instances? > I wouldn't dispute that the default definition is reasonable, but it's > certainly not clear to me from the report that it's something that I > can safely assume for all Ord instances. In fact AFAICS the report > quite clearly telling me *not* to assume this. But I have to assume > *something* for maximum to make sense, so I guess that must be: > (x==y) = True implies x=y > IOW "I have no idea if it's the first or last maximum that is returned, > but who cares?" Well, you have to assume something for maximum to do what it says it does, which isn't quite the same thing as "making sense"... > I'm not saying some people are not right to want classes with more > mathematically inspired "laws", but I see nothing in the report to > indicate to me that Eq/Ord are those classes and consequently that > the "naive" programmers interpretation of (==) is incorrect. Rather > the contrary in fact. It's not a question of more or less mathematically inspired, it's a question of more or less useful. Yes, it's slightly harder to write code that can handle any equivalency correctly. But code that only handles observational equality correctly is less reuseable. The compilers cannot and do not check if the various laws are obeyed. They are purely "social" interfaces, in that the community of code writers determines the real meaning, and what can be depended on. The community absolutely should come to a consensus of what these meanings are and document them better than they are currently. Currently, if you write code assuming a stricter meaning of Eq a, the consequences are: (a) it's easier for you to write code (b) it's harder for others to interoperate with your code and use it. Generally, you're the one that gets to make this trade off, because you're writing the code. Whether someone else uses your code, or others', or writes their own is then their own trade off. Because, indeed, many many types inhabiting Eq do obey observational equality, the consequences of (b) may be minor. With regards to Haskell 98, my best guess is that some of the committee members thought hard about the code so that Eq a would usually work for any equivalence class, and others took it to mean observational equality and wrote prose with this understanding. -- Aaron Denney -><- From wnoise at ofb.net Thu Mar 13 06:57:10 2008 From: wnoise at ofb.net (Aaron Denney) Date: Thu Mar 13 06:54:24 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <220e47b40803101207w6d4bb795k68d959b3ccff9849@mail.gmail.com> <47D5A46A.5010800@iee.org> <404396ef0803101433s435bbc64j46617fe50ba46aa5@mail.gmail.com> <47D63C44.7070704@iee.org> <6dbd4d000803110846k3fcb94a8k9ad780c2dd8272fc@mail.gmail.com> <47D6B140.4010002@iee.org> <47D7E0F5.6090907@jellybean.co.uk> <20080312194804.o14f2bxhcwgo00sw@webmail.spamcop.net> <47D8D11F.3010002@iee.org> <7ca3f0160803130108j63efdfb5h9ffe85fb9f62e04b@mail.gmail.com> <47D8EDA9.1050800@iee.org> <47D8FEB1.4020301@iee.org> Message-ID: On 2008-03-13, Adrian Hey wrote: > Aaron Denney wrote: >>> so do you really seriously consider the possibility that >>> this might not hold in your Int related code? >>> >>> if (x==y) then f x else g x y >>> >>> might not mean the same as.. >>> >>> if (x==y) then f y else g x y >> >> In Int code, of course not, because I know the types, and I know the >> behaviour of (==) on Ints. But f is specialized to work on Ints, isn't >> it, so it's reasonable to know what semantics (==) has for Ints, and >> depend on them? > > Why are Ints special in this way? Couldn't you use say exacly the same > about any type (just substitute type "X" of your choice for "Int") About any /type/, yes. When I'm writing code specific to type X, I can be expected to know more about the type than what guarantees a generic type inhabiting the same type classes will have. In fact, I better know more, because I'm calling specialized functions that take X, rather than a, or Eq a => a. If I didn't, I'd be writing a more or less generic function, that could operate on more types than X. But this doesn't hold for any old use of (==), or compare. The function sort (to go back to the beginning of this thread) as a generic function, need not assume /anything/ about observation equality to sort a list. All it needs do is use the comparison function on the elements to reorder them. This makes it /more useful/ than one that gets cute by duplicating elements that compare equal, because it can be used in more situations. -- Aaron Denney -><- From ketil at malde.org Thu Mar 13 07:05:18 2008 From: ketil at malde.org (Ketil Malde) Date: Thu Mar 13 07:02:12 2008 Subject: [Haskell-cafe] Re: Some clarity please! In-Reply-To: (Aaron Denney's message of "Thu\, 13 Mar 2008 10\:45\:51 +0000 \(UTC\)") References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <47D52A87.9060805@iee.org> <404396ef0803100632w6ae183f3w467aa02bae40caa2@mail.gmail.com> <47D5416C.808@iee.org> <871w6i8wx4.fsf@nmd9999.imr.no> <47D55287.5040701@iee.org> <404396ef0803100829h44c8ac1dg4ee6f0132cb4f929@mail.gmail.com> <47D56B7A.2030200@iee.org> <220e47b40803101207w6d4bb795k68d959b3ccff9849@mail.gmail.com> <47D5A46A.5010800@iee.org> <404396ef0803101433s435bbc64j46617fe50ba46aa5@mail.gmail.com> <47D63C44.7070704@iee.org> <47D8345A.9000201@iee.org> <47D8F442.40704@iee.org> Message-ID: <87iqzqubo1.fsf@nmd9999.imr.no> Aaron Denney writes: > Well, the way the report specifies that max's default definition > is. I'd actually favor making that not an instance function at > all, and instead have max and min be external functions. If you permit a na?ve question: Prelude> :i Ord class (Eq a) => Ord a where compare :: a -> a -> Ordering (<) :: a -> a -> Bool (>=) :: a -> a -> Bool (>) :: a -> a -> Bool (<=) :: a -> a -> Bool max :: a -> a -> a min :: a -> a -> a ..while all functions could be easily derived from 'compare'. Or from the Eq instance's (==) and (<), say. What is the reason for this? Efficiency? (Which couldn't be handled equally well by RULES?) Otherwise, it looks like an invitation for writing inconsistent instances. -k -- If I haven't seen further, it is by standing in the footprints of giants From jules at jellybean.co.uk Thu Mar 13 07:08:41 2008 From: jules at jellybean.co.uk (Jules Bean) Date: Thu Mar 13 07:05:45 2008 Subject: [Haskell-cafe] File I/O question In-Reply-To: <47D8451F.10304@btinternet.com> References: <47D829C4.6090802@btinternet.com> <20080312204233.GF9203@scytale.galois.com> <47D8451F.10304@btinternet.com> Message-ID: <47D90B39.9010907@jellybean.co.uk> Andrew Coppin wrote: > Don Stewart wrote: >> Hey Andrew, >> >> What are you trying to do? Read and write to the same file (if so, you >> need to use strict IO), or are you trying something sneakier? >> > > I have a long-running Haskell program that writes status information to > a log file. I'd like to be able to open and read that log file before > the program has actually terminated. I have a similar program written in > Tcl that allows me to do this, since apparently the Tcl interpretter > doesn't lock output files for exclusive access. Haskell, however, does. > (This seems to be the stipulated behaviour as per the Report.) If > there's an easy way to change this, it would be useful... AIUI, and I could be wrong: The haskell report mandates locking. On win32, this locking is implemented using win32 (mandatory) locking primitives, and thus it affects other processes. On unix, this locking is implementing using an advisory/optional locking system which is only noticed by other haskell threads. (On many versions of unix, at least historically, there was no mandatory locking; mandatory locking is an anathema to unix programmers) Thus, the problem you have is win32 specific and requires access to the Win32 primitive to resolve, as I understand it. There are probably primitives in Win32 packages for this? Or you could use appendfile instead, Jules From hthiel.char at zonnet.nl Thu Mar 13 08:07:23 2008 From: hthiel.char at zonnet.nl (Hans van Thiel) Date: Thu Mar 13 08:04:59 2008 Subject: [Haskell-cafe] An offer to any haskell projects out there. In-Reply-To: <20080311224620.GA31622@schmong.org> References: <20080311224620.GA31622@schmong.org> Message-ID: <1205410043.2998.24.camel@localhost.localdomain> On Tue, 2008-03-11 at 18:46 -0400, michael@schmong.org wrote: > Hello, > My name is Michael Litchard. I'm a techie living in silicon > valley, and I want to move into tech writing. I've got the > background, now I need a portfolio. I figured the best way to go > is to attach myself to some open source projects, and haskell > has had my heart for a few years now. I am by no means an expert > at haskell. My expertise is writing. So I make this offer. > If you need documentation written for your haskell project, I'm > your man. Whatever it is, I'll write it or edit it. Thanks for > your time. > > P.S > If this was the wrong list, or if anyone has other ideas > about how to propogate my proposal, please let me know. > > Michael Hello Michael, I agree that improving the docs for (some) standard libraries would be the most helpful. However, specializing in a special project would probably be better, if it's a visible portfolio you want. Have you thought of writing a tutorial on one of the HackageDB libraries, for example,database connectivity, XML processing, or even Cabal itself? That would be useful, and give you a clear cut deliverable too. http://www.gordonandgordon.com/aboutus.html is a web site with some good info on technical writing, and the differences between sdk documentation, white papers and technical marketing. All of which would be useful to the Haskell community, IMO, but that's a personal view. Best Regards, Hans van Thiel From Christian.Maeder at dfki.de Thu Mar 13 08:08:45 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Thu Mar 13 08:05:49 2008 Subject: [Haskell-cafe] Re: Some clarity please! (was Re: Re: (flawed?) benchmark : sort) In-Reply-To: <47D8F442.40704@iee.org> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <47D52A87.9060805@iee.org> <404396ef0803100632w6ae183f3w467aa02bae40caa2@mail.gmail.com> <47D5416C.808@iee.org> <871w6i8wx4.fsf@nmd9999.imr.no> <47D55287.5040701@iee.org> <404396ef0803100829h44c8ac1dg4ee6f0132cb4f929@mail.gmail.com> <47D56B7A.2030200@iee.org> <220e47b40803101207w6d4bb795k68d959b3ccff9849@mail.gmail.com> <47D5A46A.5010800@iee.org> <404396ef0803101433s435bbc64j46617fe50ba46aa5@mail.gmail.com> <47D63C44.7070704@iee.org> <47D8345A.9000201@iee.org> <47D8F442.40704@iee.org> Message-ID: <47D9194D.3070609@dfki.de> Adrian Hey wrote: > 2 - It does matter, and the result is guaranteed to be the > last maximum in all cases because: > (x==y) = True implies max x y = y This seems to be the case looking into GHC/Base.lhs max x y = if x <= y then y else x Christian From wnoise at ofb.net Thu Mar 13 08:15:17 2008 From: wnoise at ofb.net (Aaron Denney) Date: Thu Mar 13 08:12:39 2008 Subject: [Haskell-cafe] Re: Some clarity please! References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <47D52A87.9060805@iee.org> <404396ef0803100632w6ae183f3w467aa02bae40caa2@mail.gmail.com> <47D5416C.808@iee.org> <871w6i8wx4.fsf@nmd9999.imr.no> <47D55287.5040701@iee.org> <404396ef0803100829h44c8ac1dg4ee6f0132cb4f929@mail.gmail.com> <47D56B7A.2030200@iee.org> <220e47b40803101207w6d4bb795k68d959b3ccff9849@mail.gmail.com> <47D5A46A.5010800@iee.org> <404396ef0803101433s435bbc64j46617fe50ba46aa5@mail.gmail.com> <47D63C44.7070704@iee.org> <47D8345A.9000201@iee.org> <47D8F442.40704@iee.org> <87iqzqubo1.fsf@nmd9999.imr.no> Message-ID: On 2008-03-13, Ketil Malde wrote: > Aaron Denney writes: > >> Well, the way the report specifies that max's default definition >> is. I'd actually favor making that not an instance function at >> all, and instead have max and min be external functions. > > If you permit a na?ve question: > > Prelude> :i Ord > class (Eq a) => Ord a where > compare :: a -> a -> Ordering > (<) :: a -> a -> Bool > (>=) :: a -> a -> Bool > (>) :: a -> a -> Bool > (<=) :: a -> a -> Bool > max :: a -> a -> a > min :: a -> a -> a > > ..while all functions could be easily derived from 'compare'. Or from > the Eq instance's (==) and (<), say. > > What is the reason for this? Efficiency? (Which couldn't be handled > equally well by RULES?) Otherwise, it looks like an invitation for > writing inconsistent instances. My impression (which may not be entirely accurate) is not primarily for efficiency (though that is one reason), but for ease of implementation. It may be easier in some cases to think through the various cases of compare, or to just figure out what (<=) is. Either of these is sufficient (perhaps in combination with (==) from the superclass). You can write things so that any of (<), (<=), (>), or (>=) are sufficient, but for writing the default compare, it's easiest to know ahead of time which you are basing it on, so definitions don't get circular. max and min seem to have neither justification going for them, although I suppose it's technically possible to write compare in terms of them and (==). I don't think GHC's RULES were around when Haskell 98 was being formalized, nor is it clear that one compiler's method should let other efficiency concerns go by the wayside. Of course, it would be nice to be able to write (==) in terms of compare. While doable manually there's no way to default it to that "smartly". There are similar issues with Functor and Monad. ISTR some discussion about this on the list previously. -- Aaron Denney -><- From lennart at augustsson.net Thu Mar 13 08:20:28 2008 From: lennart at augustsson.net (Lennart Augustsson) Date: Thu Mar 13 08:17:31 2008 Subject: [Haskell-cafe] floating point operations and representation In-Reply-To: <8e47d1720803121735j17343d57x49fff089123f889b@mail.gmail.com> References: <8e47d1720803121735j17343d57x49fff089123f889b@mail.gmail.com> Message-ID: Wow, you have a tough mission if you want to replicate the bit level answers for double (btw, hi Jacob). Libraries differ for transcendental function, and even worse, CPUs differ. You may get different answers on an Intel and and AMD. That said, I think your best bet is to import log2 and log10 from C and use those. Haskell sadly lacks an efficient way to go from a Double to its bit pattern. :( -- Lennart On Thu, Mar 13, 2008 at 12:35 AM, Jacob Schwartz wrote: > I have two questions about using the Double data type and the > operations in the Floating typeclass on a computer that uses IEEE > floating point numbers. > > I notice that the Floating class only provides "log" (presumably log > base 'e') and "logBase" (which, in the latest source that I see for > GHC is defined as "log y / log x"). However, in C, the "math.h" > library provides specific "log2" and "log10" functions, for extra > precision. A test on IEEE computers (x86 and x86-64), shows that for > a range of 64-bit "double" values, the answers in C do differ (in the > last bit) if you use "log2(x)" and "log10(x)" versus "log (x) / > log(2)" and "log(x) / log(10)". > > I am under the restriction that I need to write Haskell programs using > Double which mimic existing C/C++ programs or generated data sets, and > get the same answers. (It's silly, but take it as a given > requirement.) If the C programs are using "log2", then I need "log2" > in the Haskell, or else I run the risk of not producing the same > answers. My first thought is to import "log2" and "log10" through the > FFI. I was wondering if anyone on Haskell-Cafe has already done this > and/or has a better suggestion about how to get specialized "log2" and > "log10" (among the many specialized functions that the "math.h" > library provides, for better precision -- for now, I'm just concerned > with "log2" and "log10"). > > My second question is how to get at the IEEE bit representation for a > Double. I am already checking "isIEEE n" in my source code (and > "floatRadix n == 2"). So I know that I am operating on hardware that > implements floating point numbers by the IEEE standard. I would like > to get at the 64 bits of a Double. Again, I can convert to a CDouble > and use the FFI to wrap a C function which casts the "double" to a > 64-bit number and returns it. But I'm wondering if there's not a > better way to do this natively in Haskell/GHC (perhaps some crazy use > of the Storable typeclass?). Or if someone has already tackled this > problem with FFI, that would be interesting to know. > > Thanks. > > Jacob > _______________________________________________ > 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/20080313/312f3444/attachment.htm From jmaessen at alum.mit.edu Thu Mar 13 08:22:50 2008 From: jmaessen at alum.mit.edu (Jan-Willem Maessen) Date: Thu Mar 13 08:19:56 2008 Subject: [Haskell-cafe] floating point operations and representation In-Reply-To: <8e47d1720803121735j17343d57x49fff089123f889b@mail.gmail.com> References: <8e47d1720803121735j17343d57x49fff089123f889b@mail.gmail.com> Message-ID: <935CBAC2-5EFE-4D11-B0FF-B813A96AD18D@alum.mit.edu> On Mar 12, 2008, at 8:35 PM, Jacob Schwartz wrote: > My second question is how to get at the IEEE bit representation for a > Double. My (rhetorical) question on this front isn't "how do I get the representation," but "why is it so hard and non-portable to get the representation sensibly"? A candidate for standardization, surely? -Jan-Willem Maessen From lennart at augustsson.net Thu Mar 13 08:29:22 2008 From: lennart at augustsson.net (Lennart Augustsson) Date: Thu Mar 13 08:26:23 2008 Subject: [Haskell-cafe] IO () and IO [()] In-Reply-To: <47D8478E.4070302@serpentine.com> References: <11b141710803101511w5ac7894ch27bea31e1e277107@mail.gmail.com> <2eb8984a0803101518q5915887n33e495d0557adb0b@mail.gmail.com> <47D5C170.7000001@imageworks.com> <47D8478E.4070302@serpentine.com> Message-ID: I don't think writing (1,) is an option for Haskell, it looks like a section (and should be one). On Wed, Mar 12, 2008 at 9:13 PM, Bryan O'Sullivan wrote: > Lennart Augustsson wrote: > > Yes, I wish Haskell had a 1-tuple. The obvious syntax is already taken, > > but I could accept something different, like 'One a'. > > Python's one-tuple syntax is (1,). The obvious difficulty with adapting > this notation to Haskell lies in how one might write the constructor as > a section. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080313/fe73899b/attachment.htm From bulat.ziganshin at gmail.com Thu Mar 13 06:39:31 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu Mar 13 08:31:31 2008 Subject: [Haskell-cafe] File I/O question In-Reply-To: <47D829C4.6090802@btinternet.com> References: <47D829C4.6090802@btinternet.com> Message-ID: <573937780.20080313133931@gmail.com> Hello Andrew, Wednesday, March 12, 2008, 10:06:44 PM, you wrote: > When I write to a file using System.IO, the file is locked for exclusive > access. I gather this is as specified in the Haskell Report. Which is > nice, but... I'd actually prefer the file to *not* be locked. Anybody > know how to do that? one (and only?) possible way is to use Streams library which happens to not lock files: http://haskell.org/haskellwiki/Library/Streams -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From hpacheco at gmail.com Thu Mar 13 08:36:38 2008 From: hpacheco at gmail.com (Hugo Pacheco) Date: Thu Mar 13 08:33:41 2008 Subject: [Haskell-cafe] Bug with GADT in function Patterns? In-Reply-To: <52988EF2-72F7-42B5-B885-F8BC3B2E3EC9@cse.unsw.edu.au> References: <7b92c2840803112016l1f9df507h2ddc45679eeb71c1@mail.gmail.com> <7b92c2840803121825t303d4422mbe2a753b7697fba5@mail.gmail.com> <52988EF2-72F7-42B5-B885-F8BC3B2E3EC9@cse.unsw.edu.au> Message-ID: <7b92c2840803130536w768ce75eo4abe236933aa7bc8@mail.gmail.com> Submited: http://hackage.haskell.org/trac/ghc/ticket/2151#preview hugo -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080313/10e57703/attachment.htm From lemming at henning-thielemann.de Thu Mar 13 08:51:45 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu Mar 13 08:48:45 2008 Subject: [Haskell-cafe] floating point operations and representation In-Reply-To: References: <8e47d1720803121735j17343d57x49fff089123f889b@mail.gmail.com> Message-ID: On Thu, 13 Mar 2008, Lennart Augustsson wrote: > Wow, you have a tough mission if you want to replicate the bit level answers > for double (btw, hi Jacob). > Libraries differ for transcendental function, and even worse, CPUs differ. > You may get different answers on an Intel and and AMD. > That said, I think your best bet is to import log2 and log10 from C and use > those. > > Haskell sadly lacks an efficient way to go from a Double to its bit pattern. > :( You can do nasty casting using STArray: http://slavepianos.org/rd/sw/sw-78/Sound/OpenSoundControl/Cast.hs From maverick_as_2000 at yahoo.es Thu Mar 13 08:56:21 2008 From: maverick_as_2000 at yahoo.es (Maverick) Date: Thu Mar 13 08:53:22 2008 Subject: [Haskell-cafe] Problem making a program in ghc Message-ID: <95129.40228.qm@web33405.mail.mud.yahoo.com> Hi, I have a problem when I am trying to use a binary file generated by ghc make in Windows. Ihave writed an application that parses xml files and returns a result(using HaXml), this is published as a service, I implemented a server(withSocketsDo), the server listen the port 5760 in a forever fashion,when a message arrives, then the program creates a new thread (forkIO)for attend the request. This works fine when I run it from ghci, when I make the program and run the binary (in Windows), the requests arrive to the program but I think that the response can?t be sentbecause the front end can?t receive the response (I am calling theservice from a .Net web application), I have a log that confirms that the response arrives correctly. I use make like this: ghc --make -package HaXml Main.hs HermesService.hs ..... What could be the problem? I am using HaXml 1.13.2 with Ghc 6.6.1, thanks in advance. Alvaro Sejas UMSS Cochabamba - Bolivia ______________________________________________ Enviado desde Correo Yahoo! El buz?n de correo sin l?mite de almacenamiento. http://es.docs.yahoo.com/mail/overview/index.html -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080313/2e49e138/attachment.htm From alfonso.acosta at gmail.com Thu Mar 13 09:49:47 2008 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Thu Mar 13 09:46:50 2008 Subject: [Haskell-cafe] Template Haskell -- when are things evaluated? In-Reply-To: <47D8FE66.6020108@cs.chalmers.se> References: <47D8DF1E.4070909@cs.chalmers.se> <6a7c66fc0803130149n6b452127l390563e96d65ccf5@mail.gmail.com> <47D8FE66.6020108@cs.chalmers.se> Message-ID: <6a7c66fc0803130649u14f85224kf13f904b4bfdfb26@mail.gmail.com> On Thu, Mar 13, 2008 at 11:13 AM, Emil Axelsson wrote: > I'm reading the following rule from your answer: > > [|exp|] normally returns the unevaluated AST of exp. However, if exp contains > local variables, these are lifted using Language.Haskell.TH.lift (i.e. evaluated > before lifting). > > Is that correct? > > > / Emil Yes, that seems to be true. I'm not an expert in the internals of TH though, so I have inferred that rule by extensive use of TH ;). SPJ can confirm if it's right. From alfonso.acosta at gmail.com Thu Mar 13 10:27:01 2008 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Thu Mar 13 10:24:05 2008 Subject: [Haskell-cafe] floating point operations and representation In-Reply-To: <8e47d1720803121735j17343d57x49fff089123f889b@mail.gmail.com> References: <8e47d1720803121735j17343d57x49fff089123f889b@mail.gmail.com> Message-ID: <6a7c66fc0803130727j11a0b5baw2057922829fd3366@mail.gmail.com> On Thu, Mar 13, 2008 at 1:35 AM, Jacob Schwartz wrote: > I have two questions about using the Double data type and the > operations in the Floating typeclass on a computer that uses IEEE > floating point numbers. > > I notice that the Floating class only provides "log" (presumably log > base 'e') and "logBase" (which, in the latest source that I see for > GHC is defined as "log y / log x"). However, in C, the "math.h" > library provides specific "log2" and "log10" functions, for extra > precision. A test on IEEE computers (x86 and x86-64), shows that for > a range of 64-bit "double" values, the answers in C do differ (in the > last bit) if you use "log2(x)" and "log10(x)" versus "log (x) / > log(2)" and "log(x) / log(10)". > > I am under the restriction that I need to write Haskell programs using > Double which mimic existing C/C++ programs or generated data sets, and > get the same answers. (It's silly, but take it as a given > requirement.) If the C programs are using "log2", then I need "log2" > in the Haskell, or else I run the risk of not producing the same > answers. My first thought is to import "log2" and "log10" through the > FFI. I was wondering if anyone on Haskell-Cafe has already done this > and/or has a better suggestion about how to get specialized "log2" and > "log10" (among the many specialized functions that the "math.h" > library provides, for better precision -- for now, I'm just concerned > with "log2" and "log10"). The RULES pragma + FFI solution (as suggested by Henning) seems to be the most sensible one so far. > My second question is how to get at the IEEE bit representation for a > Double. I am already checking "isIEEE n" in my source code (and > "floatRadix n == 2"). So I know that I am operating on hardware that > implements floating point numbers by the IEEE standard. I would like > to get at the 64 bits of a Double. Again, I can convert to a CDouble > and use the FFI to wrap a C function which casts the "double" to a > 64-bit number and returns it. But I'm wondering if there's not a > better way to do this natively in Haskell/GHC (perhaps some crazy use > of the Storable typeclass?). Posted in a a previous haskell-cafe message [1] {-# LANGUAGE MagicHash #-} import Data.Int import GHC.Exts foo :: Double -> Int64 --ghc only foo (D# x) = I64# (unsafeCoerce# x) [1] http://www.haskell.org/pipermail/haskell-cafe/2008-February/040000.html From allbery at ece.cmu.edu Thu Mar 13 12:36:44 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Thu Mar 13 12:33:47 2008 Subject: [Haskell-cafe] floating point operations and representation In-Reply-To: <877ig7ugvl.fsf@nmd9999.imr.no> References: <8e47d1720803121735j17343d57x49fff089123f889b@mail.gmail.com> <877ig7ugvl.fsf@nmd9999.imr.no> Message-ID: On Mar 13, 2008, at 5:12 , Ketil Malde wrote: > Perhaps now everybody uses SSE to do math, but earlier Intel FPU > architectures did floating point with 80-bit registers, so the > accuracy of the result could depend on whether an intermediate result > was flushed to memory (by a context switch). Double operations in IO, 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 bertram.felgenhauer at googlemail.com Thu Mar 13 12:52:05 2008 From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer) Date: Thu Mar 13 12:49:16 2008 Subject: [Haskell-cafe] Space leak - help needed In-Reply-To: <20080312191240.GA12019@localdomain> References: <20080303022318.GE29085@localdomain> <20080303042009.GB4363@zombie.inf.tu-dresden.de> <20080312191240.GA12019@localdomain> Message-ID: <20080313165205.GA4363@zombie.inf.tu-dresden.de> Krzysztof Ko?ciuszkiewicz wrote: > I have tried both Poly.StateLazy and Poly.State and they work quite well > - at least the space leak is eliminated. Now evaluation of the parser > state blows the stack... > > The code is at http://hpaste.org/6310 Apparently, stUpdate is too lazy. I'd define stUpdate' :: (s -> s) -> Parser s t () stUpdate' f = stUpdate f >> stGet >>= (`seq` return ()) and try using stUpdate' instead of stUpdate in incCount. HTH, Bertram From donn at avvanta.com Thu Mar 13 13:38:34 2008 From: donn at avvanta.com (Donn Cave) Date: Thu Mar 13 13:35:37 2008 Subject: [Haskell-cafe] Exception handling when using STUArray In-Reply-To: <7ca3f0160803122323t25707fefn1233c15a1ce94dc2@mail.gmail.com> References: <87wsod6ax8.fsf@columbia.edu> <989AC059-9B60-40A1-9ECF-2CC9AC47D19E@fastmail.fm> <2BDDF536-5617-405C-83C2-C9E56333B3F6@ece.cmu.edu> <58308741-7D24-42AB-BF9C-8E777C5EE9D4@avvanta.com> <831CF579-6B18-4519-89E5-29F676AFB40B@ece.cmu.edu> <4D60723B-5699-456B-8546-72AE6700692F@avvanta.com> <00B5B0D7-2074-4A03-99EF-D5DC84A6A480@avvanta.com> <7ca3f0160803122323t25707fefn1233c15a1ce94dc2@mail.gmail.com> Message-ID: On Mar 12, 2008, at 11:23 PM, Luke Palmer wrote: > > The issue is that exception handling semantics do induce an order of > evaluation for determinacy: if both functions in a composition throw > an exception at some point (say in the 3rd element of a list they're > generating), you need to decide which exception ends up being thrown, > and to do that based on the lazy evaluation order would break > referential transparency. OK, that is what I was getting several years ago when I brought this up, but ... check my reasoning on this. Maybe a contrived example of what you're talking about, if I write f _ [] = [] f n (a:x) = (div 3 n, j a):(f (n - 1) x) where j (Just v) = v main = print $ f 2 [Just 1, Just 2, Nothing] Running it, I'll hear about a divide by zero on the 3rd element, and not hear about the Just match failure on the 3rd element. Suppose you model exceptions with an data type X that implicitly describes all expressions in Haskell: data X a = Good a | Bad String such that a partial explicit expansion of the above is f _ [] = [] f n (a:x) = (div 3 n, j a):(f (n - 1) x) where j (Just v) = Good v j Nothing = Bad "X.hs:15:0-27: Non-exhaustive patterns in function j" div a 0 = Bad "divide by zero" div a b = Good (div a b) The expanded result of (f 2 [Just 1, Just 2, Nothing]) will be [(Good 1, Good 1), (Good 3, Good 2), (Bad "divide by zero", Bad "X.hs:15:0-27: Non-exhaustive patterns in function j")] My IO action (print) had to decide to throw "divide by zero", but arbitrary decisions like that are common and don't make the underlying principle unsound. Am I missing something, or is that a suitable model for pure, non-strict exceptions that could in principle be caught outside IO? (Of course, I do _not_ propose to write code per the expanded example above - that's only a partial expansion, and already too cumbersome to be useful. It's only a conceptual model.) Donn Cave, donn@avvanta.com From andrewcoppin at btinternet.com Thu Mar 13 14:16:58 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Thu Mar 13 14:13:57 2008 Subject: [Haskell-cafe] File I/O question In-Reply-To: <573937780.20080313133931@gmail.com> References: <47D829C4.6090802@btinternet.com> <573937780.20080313133931@gmail.com> Message-ID: <47D96F9A.10503@btinternet.com> Bulat Ziganshin wrote: > Hello Andrew, > > one (and only?) possible way is to use Streams library which happens > to not lock files: > Is that likely to compile on Windows? From g9ks157k at acme.softbase.org Thu Mar 13 15:43:15 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Thu Mar 13 15:41:16 2008 Subject: [Haskell-cafe] A question about "monad laws" In-Reply-To: <15976463.post@talk.nabble.com> References: <15976463.post@talk.nabble.com> Message-ID: <200803132043.15469.g9ks157k@acme.softbase.org> Am Mittwoch, 12. M?rz 2008 00:53 schrieb askyle: > [?] > So if floating point (==) doesn't correspond with numeric equality, it's > not FP's fault, but ours for expecting it to do! No, I think, it?s the Prelude?s fault to define (==) as ?floating point equality?. We should us a different identifier like floatingPointEq. (==) is expected to be an equivalence relation. (I think I already said this.) > [?] Best wishes, Wolfgang From agl at imperialviolet.org Thu Mar 13 15:47:15 2008 From: agl at imperialviolet.org (Adam Langley) Date: Thu Mar 13 15:44:16 2008 Subject: [Haskell-cafe] Problem making a program in ghc In-Reply-To: <95129.40228.qm@web33405.mail.mud.yahoo.com> References: <95129.40228.qm@web33405.mail.mud.yahoo.com> Message-ID: <396556a20803131247r7c34dfacieb4718770494dd77@mail.gmail.com> 2008/3/13 Maverick : > I have writed an application that parses xml files and returns a result > (using HaXml), this is published as a service, I implemented a server > (withSocketsDo), the server listen the port 5760 in a forever fashion, when > a message arrives, then the program creates a new thread (forkIO) for attend > the request. This works fine when I run it from ghci, when I make the > program and run the binary (in Windows), the requests arrive to the program > but I think that the response can?t be sent because the front end can?t > receive the response (I am calling the service from a .Net web application), > I have a log that confirms that the response arrives correctly. I hate to see any requests for help go unanswered here, but this one might be tough. I think you need to give some more information, otherwise the suggestions are going to be very general. Can you put the Haskell source code on a website somewhere and link to it. Since it's a network service, an example request and reply might be good to include. In general, you should check that you are correctly flushing your connection. If you are using Handles to interface to the network, they can buffer the response. hFlush[1] may need to be called when you have finished generating it. [1] http://haskell.org/ghc/docs/latest/html/libraries/base/System-IO.html#v%3AhFlush AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org From westondan at imageworks.com Thu Mar 13 16:10:25 2008 From: westondan at imageworks.com (Dan Weston) Date: Thu Mar 13 16:15:41 2008 Subject: [Haskell-cafe] A question about "monad laws" In-Reply-To: <200803132043.15469.g9ks157k@acme.softbase.org> References: <15976463.post@talk.nabble.com> <200803132043.15469.g9ks157k@acme.softbase.org> Message-ID: <47D98A31.7010407@imageworks.com> Not to be picky, but where did you hear that (==) established an equivalence relation? Not I expect from the Haskell98 Report! The only law I can find there is that x /= y iff not (x == y) So, the definition x == y = False x /= y = True would be perfectly legitimate, making x /= x = True, which kind of ruins the equivalence relation thing, no? Dan Wolfgang Jeltsch wrote: > Am Mittwoch, 12. M?rz 2008 00:53 schrieb askyle: >> [?] > >> So if floating point (==) doesn't correspond with numeric equality, it's >> not FP's fault, but ours for expecting it to do! > > No, I think, it?s the Prelude?s fault to define (==) as ?floating point > equality?. We should us a different identifier like floatingPointEq. (==) > is expected to be an equivalence relation. (I think I already said this.) > >> [?] > > Best wishes, > Wolfgang > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From ben.franksen at online.de Thu Mar 13 16:18:03 2008 From: ben.franksen at online.de (Ben Franksen) Date: Thu Mar 13 16:19:27 2008 Subject: [Haskell-cafe] Re: Exception handling when using STUArray References: <87wsod6ax8.fsf@columbia.edu> <989AC059-9B60-40A1-9ECF-2CC9AC47D19E@fastmail.fm> <2BDDF536-5617-405C-83C2-C9E56333B3F6@ece.cmu.edu> <58308741-7D24-42AB-BF9C-8E777C5EE9D4@avvanta.com> <831CF579-6B18-4519-89E5-29F676AFB40B@ece.cmu.edu> <4D60723B-5699-456B-8546-72AE6700692F@avvanta.com> <00B5B0D7-2074-4A03-99EF-D5DC84A6A480@avvanta.com> <7ca3f0160803122323t25707fefn1233c15a1ce94dc2@mail.gmail.com> Message-ID: Luke Palmer wrote: > On Wed, Mar 12, 2008 at 4:45 PM, Donn Cave wrote: >> Well, the problem inherently requires a certain order of >> evaluation. But if you will just handle pattern match failure >> in the IO monad, then you can write a simple functional >> expression of the problem instead, >> >> let (i, s') = decodeInt s in >> let (v, _) = decodeInt s' in >> (i, v) >> >> ... where I think `i' can be evaluated without forcing unnecessary >> evaluation of v. It's clearer, and avoids unnecessary strictness! > > Unless of course you don't have an IO monad handy. > > The issue is that exception handling semantics do induce an order of > evaluation for determinacy: if both functions in a composition throw > an exception at some point (say in the 3rd element of a list they're > generating), you need to decide which exception ends up being thrown, > and to do that based on the lazy evaluation order would break > referential transparency. > > It bugs me a little how good Haskell is with laziness, but how bad it > gets when you need laziness with a slightly different structure. I > don't see any way it could reasonably be "fixed" if I were designing > my own language, it's just unsettling. Isn't this what "imprecise exeptions" were invented (and implemented in GHC) for? See http://research.microsoft.com/Users/simonpj/Papers/imprecise-exn.htm Cheers Ben From rob at robhulme.com Thu Mar 13 17:09:14 2008 From: rob at robhulme.com (Robert Hulme) Date: Thu Mar 13 17:06:16 2008 Subject: [Haskell-cafe] Video / Slides: Type-driven testing in Haskell (Simon Peyton Jones) Message-ID: I was lucky enough to attend a lecture by SPJ yesterday. You're lucky that I taped it and have put it all online :-) http://www.foomongers.org.uk/videos/spj-typedriventestinginhaskell.html If you're a redditer please vote it up on programming.reddit! http://reddit.com/r/programming/info/6byuy/comments/ -Rob -- ----------------------------------------------------- "She's flushing me out with dogs and grenades, and a sincere desire to spend time with me" --Mark Corrigan "That's the way things are these days, let's just put a zip here, a swastika there. Who the hell even knows what these things were used for. Who cares?" --Mark Corrigan http://www.robhulme.com/ http://robhu.livejournal.com/ From conor at strictlypositive.org Thu Mar 13 18:08:22 2008 From: conor at strictlypositive.org (Conor McBride) Date: Thu Mar 13 18:05:27 2008 Subject: Some clarity please! (was Re: [Haskell-cafe] Re: (flawed?) benchmark : sort) In-Reply-To: <20080313161710.15217.qmail@schroeder.cas.mcmaster.ca> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <47D52A87.9060805@iee.org> <404396ef0803100632w6ae183f3w467aa02bae40caa2@mail.gmail.com> <47D5416C.808@iee.org> <871w6i8wx4.fsf@nmd9999.imr.no> <47D55287.5040701@iee.org> <404396ef0803100829h44c8ac1dg4ee6f0132cb4f929@mail.gmail.com> <47D56B7A.2030200@iee.org> <220e47b40803101207w6d4bb795k68d959b3ccff9849@mail.gmail.com> <47D5A46A.5010800@iee.org> <404396ef0803101433s435bbc64j46617fe50ba46aa5@mail.gmail.com> <47D63C44.7070704@iee.org> <47D8345A.9000201@iee.org> <47D8F442.40704@iee.org> <20080313161710.15217.qmail@schroeder.cas.mcmaster.ca> Message-ID: <0D3128D3-2493-498B-9966-4253804487C5@strictlypositive.org> Hi folks I'm late into this thread, so apologies if I'm being dim. On 13 Mar 2008, at 16:17, kahl@cas.mcmaster.ca wrote: > Adrian Hey wrote: > >> I would ask for any correct Eq instance something like the law: >> (x==y) = True implies x=y (and vice-versa) I wish I knew what = meant here. Did somebody say? I don't think it's totally obvious what equational propositions should mean. Nor do I think it's desirable to consider only those propositions expressible in QuickCheck. If = is reflexive and distinguishes undefined from True, then x = y implies (x == y) = True will be tricky to satisfy for quite a lot of types. What about undefined == undefined or repeat 'x' == repeat 'x' ? For some suitable (slightly subtle) definition of "finite", you might manage x finite and x = y implies (x == y) = True One rather intensional definition of x = y might be "x and y have a common n-step reduct" with respect to some suitable operational semantics. I don't think this is what Adrian had in mind, but it certainly falls foul of Wolfram's objection. > > The easiest counterexample are sets (or finite maps) > provided as an abstract data type (i.e., exported without access to > the > implementation, in particular constructors). > Different kinds of balanced trees typically do not produce the same > representation for the same set constructed by different construction > expressions. This suggests that we should seek to define x = y on a type by type basis, to mean "x and y support the same observations", for some suitable notion of observation, which might depend crucially on what operations are exported from the (notional or actual) module which defines the type. If so, it's clearly crucial to allow some observations which rely on waiting for ever, in order to avoid _|_-induced collapse. Something of the sort should allow this... > > Therefore, (==) on sets will be expected to produce equality of sets, > which will only be an equivalence on set representations. ...but this... > >> which implies (f x == f y) = True (for expression types which are >> instances of Eq). > > This specifies that (==) is a congurence for f, and is in my opinion > the right specification: (==) should be a congurence > on all datatypes with respect to all purely defineable functions. ...is more troublesome. Take f = repeat. Define f = f. I'd hope x == y = True would give us x = y, and that x == y would be defined if at least one of x and y is finite. That implies f x = f y, which should guarantee that f x == f y is not False. > But at least nowadays people occasionally do export functions > that allow access to representation details, [..] > I consider this as an argument to remove showTree from the > interface of > Data.Set, and to either specify toList to produce an ordered list > (replacing toAscList), or to remove it from the interface as well. Perhaps that's a little extreme but I agree with the sentiment. How about designating such abstraction- breaking functions "nosy", in the same way that functions which might break purity are "unsafe". > (mapMonotonic should of course be removed, too, > or specified to fail (preferably in some MonadZero) > if the precondition is violated, > which should still be implementable in linear time.) What's wrong with mapMonotonic that isn't wrong with, say, sortBy?, or Eq instances for parametrized types? > >> but if so would like to appeal to movers and shakers in the >> language definition to please decide exactly what the proper >> interpretation of standard Eq and Ord "class laws" are and in the >> next version of the report give an explanation of these > > Strongly seconded, inserting ``precise'' before ``explanation'' ;-) > > (And I'd expect equivalences and congruences to be accessible > on the basis of standard first-year math...) Before we can talk about what == should return, can we settle what we mean by = ? I think we need to pragmatic about breaking the rules, given suitable documentation and maybe warnings. We should at least aspire to some principles, which means we should try to know what we're talking about and to know what we're doing, even if we don't always do what we're talking about. I'll shut up now. Potatoes to peel Conor From dave at zednenem.com Thu Mar 13 18:20:22 2008 From: dave at zednenem.com (David Menendez) Date: Thu Mar 13 18:17:28 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <404396ef0803100829h44c8ac1dg4ee6f0132cb4f929@mail.gmail.com> <47D56B7A.2030200@iee.org> <220e47b40803101207w6d4bb795k68d959b3ccff9849@mail.gmail.com> <47D5A46A.5010800@iee.org> <404396ef0803101433s435bbc64j46617fe50ba46aa5@mail.gmail.com> <47D63C44.7070704@iee.org> <47D8345A.9000201@iee.org> Message-ID: <49a77b7a0803131520h500e2f8crc9feb119228b02b2@mail.gmail.com> On Wed, Mar 12, 2008 at 4:29 PM, Aaron Denney wrote: > > When defining max, yes, you must take care to make sure it useable for > cases when Eq is an equivalence relation, rather than equality. > > If you're writing library code, then it won't generally know whether > Eq means true equality rather than equivalence. If this would let > you optimize things, you need some other way to communicate this. > > The common typeclasses are for generic, parameterizable polymorphism. > Equivalence is a more generally useful notion than equality, so that's > what I want captured by the Eq typeclass. I agree that equivalence is more general than equality, but I think equality makes more sense for Eq. Unfortunately, my reasons are mostly circumstantial. (1) You get at most one instance of Eq per type, and you get at most one equality relation per type. On the other hand, you have at least one equivalence (trivial equivalence) and will usually have several. Type classes don't work well when you have more than one of something per type (consider monoids). (2) Libraries like Data.Set and the Edison have to go through a lot of hoops because they can't assume that an Eq tests equality. (The Edison API, in particular, has to create a distinction between observable and non-observable collections, in order to support, e.g., a bag that doesn't store multiple copies of equivalent elements.) (3) Eq uses (==), which is commonly known as the "equality" sign, not the "equivalence" sign. (4) The Prelude already provides alternative functions that support any equivalence (sortBy, nubBy, etc.). If I were creating Haskell right now, I'd use Eq for equality and provide an additional class for equivalences along these lines: data P r class Equivalence r where type EqOver r :: * equiv :: P r -> EqOver r -> EqOver r -> Bool data Equality a instance (Eq a) => Equivalence (Equality a) where type EqOver (Equality a) = a equiv _ = (==) data Trivial a instance Equivalence (Trivial a) where type EqOver (Trivial a) = a equiv _ _ _ = True Similar tricks can be used for orderings. -- Dave Menendez From ajb at spamcop.net Thu Mar 13 18:28:42 2008 From: ajb at spamcop.net (ajb@spamcop.net) Date: Thu Mar 13 18:25:43 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: <47D8D11F.3010002@iee.org> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <47D5416C.808@iee.org> <871w6i8wx4.fsf@nmd9999.imr.no> <47D55287.5040701@iee.org> <404396ef0803100829h44c8ac1dg4ee6f0132cb4f929@mail.gmail.com> <47D56B7A.2030200@iee.org> <220e47b40803101207w6d4bb795k68d959b3ccff9849@mail.gmail.com> <47D5A46A.5010800@iee.org> <404396ef0803101433s435bbc64j46617fe50ba46aa5@mail.gmail.com> <47D63C44.7070704@iee.org> <6dbd4d000803110846k3fcb94a8k9ad780c2dd8272fc@mail.gmail.com> <47D6B140.4010002@iee.org> <47D7E0F5.6090907@jellybean.co.uk> <20080312194804.o14f2bxhcwgo00sw@webmail.spamcop.net> <47D8D11F.3010002@iee.org> Message-ID: <20080313182842.23pl2dtt4owoo4sg@webmail.spamcop.net> G'day all. Quoting Adrian Hey : > I take it you mean something like .. Err... yes, I did. > Where's the Eq instance for OrdWrap? Omitted for brevity. > This may or may not satisfy > the law: (compare a b) = EQ implies (a == b) = True. I think > everbody agrees about that, but I can't tell from the code > you've posted if it does in this case. The default implementation of compare says that. One thing that's not explicitly stated in the report is whether or not the instances of typeclasses like Eq or Ord need to "do the same thing as"[*] the default implementations. Does x /= y "do the same thing as" not (x == y)? > What's disputed is whether or not this law should hold: > (a == b) = True implies a = b Apart from possibly your good self, I don't think this is disputed. Quotient types, as noted elsewhere in this thread, are very useful. Their common use predates Miranda, so it's way too late to unbless them now. > Well I hope you or anyone else hasn't used Data.Map or with OrdWrap > keys because if so it's likely that the code has either been broken in > the past, or is broken now (not sure which). For Data.Map, using an OrdWrap-like wrapper for keys is wrong, because it's not necessary. OrdWrap is for situations where you need to associate a value with a key which is, unsurprisingly, what Data.Map also does. As for sort, the behaviour hasn't been broken at any point in the past or present that I'm aware of, and a lot of people would strongly resist it if it ever were proposed that it be broken. Cheers, Andrew Bromage [*] "Do the same thing as" here means that they mean the same thing, but allows for the possibility that some implementation may be less stack-consuming, lazier or in some way more efficient than its default. From k.kosciuszkiewicz at gmail.com Thu Mar 13 18:38:06 2008 From: k.kosciuszkiewicz at gmail.com (Krzysztof =?utf-8?Q?Ko=C5=9Bciuszkiewicz?=) Date: Thu Mar 13 18:35:43 2008 Subject: [Haskell-cafe] Space leak - help needed In-Reply-To: <20080313165205.GA4363@zombie.inf.tu-dresden.de> References: <20080303022318.GE29085@localdomain> <20080303042009.GB4363@zombie.inf.tu-dresden.de> <20080312191240.GA12019@localdomain> <20080313165205.GA4363@zombie.inf.tu-dresden.de> Message-ID: <20080313223806.GB6554@localdomain> On Thu, Mar 13, 2008 at 05:52:05PM +0100, Bertram Felgenhauer wrote: > > ... Now evaluation of the parser state blows the stack... > > > > The code is at http://hpaste.org/6310 > > Apparently, stUpdate is too lazy. I'd define > > stUpdate' :: (s -> s) -> Parser s t () > stUpdate' f = stUpdate f >> stGet >>= (`seq` return ()) > > and try using stUpdate' instead of stUpdate in incCount. Yes, that solves the stack issue. Thanks! -- Krzysztof Ko?ciuszkiewicz Skype: dr.vee, Gadu: 111851, Jabber: kokr@jabberpl.org "Simplicity is the ultimate sophistication" -- Leonardo da Vinci From conor at strictlypositive.org Thu Mar 13 19:06:16 2008 From: conor at strictlypositive.org (Conor McBride) Date: Thu Mar 13 19:03:15 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: <20080313182842.23pl2dtt4owoo4sg@webmail.spamcop.net> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <47D5416C.808@iee.org> <871w6i8wx4.fsf@nmd9999.imr.no> <47D55287.5040701@iee.org> <404396ef0803100829h44c8ac1dg4ee6f0132cb4f929@mail.gmail.com> <47D56B7A.2030200@iee.org> <220e47b40803101207w6d4bb795k68d959b3ccff9849@mail.gmail.com> <47D5A46A.5010800@iee.org> <404396ef0803101433s435bbc64j46617fe50ba46aa5@mail.gmail.com> <47D63C44.7070704@iee.org> <6dbd4d000803110846k3fcb94a8k9ad780c2dd8272fc@mail.gmail.com> <47D6B140.4010002@iee.org> <47D7E0F5.6090907@jellybean.co.uk> <20080312194804.o14f2bxhcwgo00sw@webmail.spamcop.net> <47D8D11F.3010002@iee.org> <20080313182842.23pl2dtt4owoo4sg@webmail.spamcop.net> Message-ID: <00E7D026-8FAF-4BEE-9049-456374CE70C3@strictlypositive.org> Hi On 13 Mar 2008, at 22:28, ajb@spamcop.net wrote: > G'day all. > > Quoting Adrian Hey : >> What's disputed is whether or not this law should hold: >> (a == b) = True implies a = b > > Apart from possibly your good self, I don't think this is disputed. > Quotient types, as noted elsewhere in this thread, are very useful. For a suitable notion of = on quotients, and with a suitable abstraction barrier at least morally in place, is that really too much to ask? > Their common use predates Miranda, so it's way too late to unbless > them now. How depressing! Untyped programming also predates Miranda. We can always aspire for better. It's not that we need to get rid of Quotients: it's just that we need to manage information hiding properly, which is perhaps not such a tall order. Meanwhile, the sort/Ord/OrdWrap issue may be a storm in a different teacup: the type of sort is too tight. Ord (total ordering) is way too strong a requirement for sorting. Antisymmetry isn't needed for sorting and isn't possessed by OrdWrap. A bit more structure for order-related classes would surely help here. Isn't there room for hope? All the best Conor From ahey at iee.org Thu Mar 13 19:26:28 2008 From: ahey at iee.org (Adrian Hey) Date: Thu Mar 13 19:23:30 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: <20080313182842.23pl2dtt4owoo4sg@webmail.spamcop.net> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <47D5416C.808@iee.org> <871w6i8wx4.fsf@nmd9999.imr.no> <47D55287.5040701@iee.org> <404396ef0803100829h44c8ac1dg4ee6f0132cb4f929@mail.gmail.com> <47D56B7A.2030200@iee.org> <220e47b40803101207w6d4bb795k68d959b3ccff9849@mail.gmail.com> <47D5A46A.5010800@iee.org> <404396ef0803101433s435bbc64j46617fe50ba46aa5@mail.gmail.com> <47D63C44.7070704@iee.org> <6dbd4d000803110846k3fcb94a8k9ad780c2dd8272fc@mail.gmail.com> <47D6B140.4010002@iee.org> <47D7E0F5.6090907@jellybean.co.uk> <20080312194804.o14f2bxhcwgo00sw@webmail.spamcop.net> <47D8D11F.3010002@iee.org> <20080313182842.23pl2dtt4owoo4sg@webmail.spamcop.net> Message-ID: <47D9B824.6090407@iee.org> ajb@spamcop.net wrote: >> What's disputed is whether or not this law should hold: >> (a == b) = True implies a = b > > Apart from possibly your good self, I don't think this is disputed. If that's supposed it imply you think I'm in a minority of one I don't think you've been following this thread very well. Even the report uses the word "equality" in the prose. And as I pointed out in another post, even the standard library maximum function appears to ambiguous if the law doesn't hold. It can be disambiguated if Aarons "max law" holds: (a == b) = True implies max x y = y But this is only true for the *default* max implementation. One of the few explicit things the report does say on these matters is that the default methods should *not* be regarded as definitive. Besides there are good pragmatic safety and performance reasons why Haskell should provide at least one class that offers strong guarantees regarding equality and the (==) operator. If that class isn't Eq, then where is it? The (==) law holds for: 1- All "standard" Eq instances 2- All wholly derived Eq instances 3- Most hand defined instances I suspect. ..and has almost certainly been implicitly assumed by heaven knows what extant code (some of it in the standard libraries I suspect). So I think that we should recognise that this was the original intent for the Eq class and this should be made "official", albeit retrospectively. If there's a need for a similar class where the (==) law doesn't hold that's fine. But please don't insist that class must be Eq. Regards -- Adrian Hey From wnoise at ofb.net Thu Mar 13 19:33:12 2008 From: wnoise at ofb.net (Aaron Denney) Date: Thu Mar 13 19:30:22 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <47D5416C.808@iee.org> <871w6i8wx4.fsf@nmd9999.imr.no> <47D55287.5040701@iee.org> <404396ef0803100829h44c8ac1dg4ee6f0132cb4f929@mail.gmail.com> <47D56B7A.2030200@iee.org> <220e47b40803101207w6d4bb795k68d959b3ccff9849@mail.gmail.com> <47D5A46A.5010800@iee.org> <404396ef0803101433s435bbc64j46617fe50ba46aa5@mail.gmail.com> <47D63C44.7070704@iee.org> <6dbd4d000803110846k3fcb94a8k9ad780c2dd8272fc@mail.gmail.com> <47D6B140.4010002@iee.org> <47D7E0F5.6090907@jellybean.co.uk> <20080312194804.o14f2bxhcwgo00sw@webmail.spamcop.net> <47D8D11F.3010002@iee.org> <20080313182842.23pl2dtt4owoo4sg@webmail.spamcop.net> <00E7D026-8FAF-4BEE-9049-456374CE70C3@strictlypositive.org> Message-ID: On 2008-03-13, Conor McBride wrote: > Hi > > On 13 Mar 2008, at 22:28, ajb@spamcop.net wrote: > >> G'day all. >> >> Quoting Adrian Hey : >>> What's disputed is whether or not this law should hold: >>> (a == b) = True implies a = b >> >> Apart from possibly your good self, I don't think this is disputed. >> Quotient types, as noted elsewhere in this thread, are very useful. > > For a suitable notion of = on quotients, and with a > suitable abstraction barrier at least morally in place, > is that really too much to ask? I really think it is. I don't think the case of "equivalent for this purpose, but not that purpose" can be ignored. Now, it may be the case that fooBy functions are then the right thing, but it's not clear to me at all that this is true. And if the fooBy option works, then why would the foo option fail for equivalence classes? I've seen mention of difficulties with Data.Map, and edison, but not in enough detail to really grasp what the problems are. Until I do, my natural bias (which I'm trying to resist, really) is that it's a matter of lazy coding, not any inherent difficulty. >> Their common use predates Miranda, so it's way too late to unbless >> them now. > > How depressing! Untyped programming also predates > Miranda. We can always aspire for better. It's not > that we need to get rid of Quotients: it's just that > we need to manage information hiding properly, which > is perhaps not such a tall order. > > Meanwhile, the sort/Ord/OrdWrap issue may be a storm > in a different teacup: the type of sort is too tight. > Ord (total ordering) is way too strong a requirement > for sorting. Antisymmetry isn't needed for sorting > and isn't possessed by OrdWrap. A bit more structure > for order-related classes would surely help here. Say what? If I don't have a total ordering, then it's possible two elements are incomparable -- what should a sort algorithm do in such a situation? -- Aaron Denney -><- From wnoise at ofb.net Thu Mar 13 19:42:35 2008 From: wnoise at ofb.net (Aaron Denney) Date: Thu Mar 13 19:39:43 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <404396ef0803100829h44c8ac1dg4ee6f0132cb4f929@mail.gmail.com> <47D56B7A.2030200@iee.org> <220e47b40803101207w6d4bb795k68d959b3ccff9849@mail.gmail.com> <47D5A46A.5010800@iee.org> <404396ef0803101433s435bbc64j46617fe50ba46aa5@mail.gmail.com> <47D63C44.7070704@iee.org> <47D8345A.9000201@iee.org> <49a77b7a0803131520h500e2f8crc9feb119228b02b2@mail.gmail.com> Message-ID: On 2008-03-13, David Menendez wrote: > On Wed, Mar 12, 2008 at 4:29 PM, Aaron Denney wrote: >> >> When defining max, yes, you must take care to make sure it useable for >> cases when Eq is an equivalence relation, rather than equality. >> >> If you're writing library code, then it won't generally know whether >> Eq means true equality rather than equivalence. If this would let >> you optimize things, you need some other way to communicate this. >> >> The common typeclasses are for generic, parameterizable polymorphism. >> Equivalence is a more generally useful notion than equality, so that's >> what I want captured by the Eq typeclass. > > I agree that equivalence is more general than equality, but I think > equality makes more sense for Eq. Unfortunately, my reasons are mostly > circumstantial. Despite the circumstantial nature, still strong though. > (1) You get at most one instance of Eq per type, and you get at most > one equality relation per type. On the other hand, you have at least > one equivalence (trivial equivalence) and will usually have several. > Type classes don't work well when you have more than one of something > per type (consider monoids). Right. But wrapping in newtypes gets around that somewhat. > (2) Libraries like Data.Set and the Edison have to go through a lot of > hoops because they can't assume that an Eq tests equality. (The Edison > API, in particular, has to create a distinction between observable and > non-observable collections, in order to support, e.g., a bag that > doesn't store multiple copies of equivalent elements.) Why is this a distinction in the API, rather than just the same API by coalescing and non-coalescing collections? > (3) Eq uses (==), which is commonly known as the "equality" sign, not > the "equivalence" sign. Meh. Having the names be right is important, but choosing the right semantics comes first. Eq should be renamed (to either Equal or Equivalent, depending). > (4) The Prelude already provides alternative functions that support > any equivalence (sortBy, nubBy, etc.). Consider the old "if we have trees with different comparison operators, how do we keep the user from merging them together." Well, phantom types, and different instances provides a way to ensure this statically. > If I were creating Haskell right now, I'd use Eq for equality and > provide an additional class for equivalences along these lines: Well, Haskell' isn't yet finished... > data P r > class Equivalence r where > type EqOver r :: * > equiv :: P r -> EqOver r -> EqOver r -> Bool > > data Equality a > > instance (Eq a) => Equivalence (Equality a) where > type EqOver (Equality a) = a > equiv _ = (==) > > data Trivial a > > instance Equivalence (Trivial a) where > type EqOver (Trivial a) = a > equiv _ _ _ = True Hmm. Pretty nice, but I might prefer an MPTC solution. -- Aaron Denney -><- From k.kosciuszkiewicz at gmail.com Thu Mar 13 19:50:25 2008 From: k.kosciuszkiewicz at gmail.com (Krzysztof =?utf-8?Q?Ko=C5=9Bciuszkiewicz?=) Date: Thu Mar 13 19:47:50 2008 Subject: [Haskell-cafe] Space leak - help needed In-Reply-To: References: <20080303022318.GE29085@localdomain> <20080303042009.GB4363@zombie.inf.tu-dresden.de> <20080312191240.GA12019@localdomain> Message-ID: <20080313235025.GC6554@localdomain> On Wed, Mar 12, 2008 at 12:34:38PM -0700, Justin Bailey wrote: > The stack blows up when a bunch of unevaluated thunks build up, and > you try to evaluate them. One way to determine where those thunks are > getting built is to use GHCs "retainer" profiling. Retainer sets will > show you the "call stack" that is holding on to memory. That can give > you a clue where these thunks are being created. To get finer-grained > results, annotate your code with {#- SCC "..." #-} pragmas. Then you > can filter the retainer profile by those annotations. That will help > you determine where in a given function the thunks are being created. > > If you need help with profiling basics, feel free to ask. I'm not entirely sure if I understand retainer profiling correctly... So please clarify if you spot any obvious blunders. Retainers are thunks or objects on stack that keep references to live objects. All retainers of an object are called the object's retainer set. Now when one makes a profiling run, say with ./jobname +RTS -p -hr, the graph refernces retainer sets from jobname.prof. My understanding is that it is the total size of all objects retained by retainer sets being plotted, correct? About decoding the sets from jobname.prof - for example in > SET 2 = {} > SET 16 = {, } > SET 18 = {, } {...} means it's a set, and is the retainer cost centre (ccN) and hierarchy of parent cost centres up to the "top level" (cc0)? My understanding is that SET 18 above refers to objects that are retained by exactly two specified cost centres, right? Finally, what is the MAIN.SYSTEM retainer? Thanks in advance, -- Krzysztof Ko?ciuszkiewicz Skype: dr.vee, Gadu: 111851, Jabber: kokr@jabberpl.org "Simplicity is the ultimate sophistication" -- Leonardo da Vinci From ajb at spamcop.net Thu Mar 13 20:02:10 2008 From: ajb at spamcop.net (ajb@spamcop.net) Date: Thu Mar 13 19:59:09 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: <00E7D026-8FAF-4BEE-9049-456374CE70C3@strictlypositive.org> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <47D5416C.808@iee.org> <871w6i8wx4.fsf@nmd9999.imr.no> <47D55287.5040701@iee.org> <404396ef0803100829h44c8ac1dg4ee6f0132cb4f929@mail.gmail.com> <47D56B7A.2030200@iee.org> <220e47b40803101207w6d4bb795k68d959b3ccff9849@mail.gmail.com> <47D5A46A.5010800@iee.org> <404396ef0803101433s435bbc64j46617fe50ba46aa5@mail.gmail.com> <47D63C44.7070704@iee.org> <6dbd4d000803110846k3fcb94a8k9ad780c2dd8272fc@mail.gmail.com> <47D6B140.4010002@iee.org> <47D7E0F5.6090907@jellybean.co.uk> <20080312194804.o14f2bxhcwgo00sw@webmail.spamcop.net> <47D8D11F.3010002@iee.org> <20080313182842.23pl2dtt4owoo4sg@webmail.spamcop.net> <00E7D026-8FAF-4BEE-9049-456374CE70C3@strictlypositive.org> Message-ID: <20080313200210.wz3fo0d4g04ccwow@webmail.spamcop.net> G'day all. Quoting Conor McBride : > How depressing! Sorry, I don't understand that. Quotient types are good, but they're not the whole story. They just happen to be one use case with a solid history behind them. > it's just that > we need to manage information hiding properly, which > is perhaps not such a tall order. It's my opinion (and I know I'm not alone in this) that modularity is probably the one thing that Haskell really hasn't (yet) gotten right. Haskell's implementation of modules/namespaces/whatever is the bare minimum needed to be minimally useful. It's a shame, because abstraction, in Haskell, is extremely cheap. It's often only one line, and you've got a compiler-checked abstraction that can't be accidentally confused with its representation. This should encourage micro-abstractions everywhere, but without submodules, namespaces or whatever you want to call them, these abstractions are easy to break (on purpose, not by accident). If only you could add a couple more lines of code, and instantly have your abstraction unbreakable. Cheers, Andrew Bromage From conor at strictlypositive.org Thu Mar 13 20:27:42 2008 From: conor at strictlypositive.org (Conor McBride) Date: Thu Mar 13 20:24:39 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <47D5416C.808@iee.org> <871w6i8wx4.fsf@nmd9999.imr.no> <47D55287.5040701@iee.org> <404396ef0803100829h44c8ac1dg4ee6f0132cb4f929@mail.gmail.com> <47D56B7A.2030200@iee.org> <220e47b40803101207w6d4bb795k68d959b3ccff9849@mail.gmail.com> <47D5A46A.5010800@iee.org> <404396ef0803101433s435bbc64j46617fe50ba46aa5@mail.gmail.com> <47D63C44.7070704@iee.org> <6dbd4d000803110846k3fcb94a8k9ad780c2dd8272fc@mail.gmail.com> <47D6B140.4010002@iee.org> <47D7E0F5.6090907@jellybean.co.uk> <20080312194804.o14f2bxhcwgo00sw@webmail.spamcop.net> <47D8D11F.3010002@iee.org> <20080313182842.23pl2dtt4owoo4sg@webmail.spamcop.net> <00E7D026-8FAF-4BEE-9049-456374CE70C3@strictlypositive.org> Message-ID: <62B9D97C-0A24-4F67-BE32-9CCFCE33B8F3@strictlypositive.org> Hi On 13 Mar 2008, at 23:33, Aaron Denney wrote: > On 2008-03-13, Conor McBride wrote: >> Hi >> >> On 13 Mar 2008, at 22:28, ajb@spamcop.net wrote: >> >>> G'day all. >>> >>> Quoting Adrian Hey : >>>> What's disputed is whether or not this law should hold: >>>> (a == b) = True implies a = b >>> >>> Apart from possibly your good self, I don't think this is disputed. >>> Quotient types, as noted elsewhere in this thread, are very useful. >> >> For a suitable notion of = on quotients, and with a >> suitable abstraction barrier at least morally in place, >> is that really too much to ask? > > I really think it is. I don't think the case of "equivalent for this > purpose, but not that purpose" can be ignored. Sure. But use the right tools for the job. > Now, it may be the case > that fooBy functions are then the right thing, but it's not clear > to me > at all that this is true. > > And if the fooBy option works, then why would the foo option fail for > equivalence classes? It seems reasonable to construct quotients from arbitrary equivalences: if fooBy works for the carrier, foo should work for the quotient. Of course, if you want to expose the representation for some other legitimate purpose, then it wasn't equality you were interested in, so you should call it something else. >> A bit more structure >> for order-related classes would surely help here. > > Say what? Don't panic! > If I don't have a total ordering, then it's possible two > elements are incomparable Quite so. > -- what should a sort algorithm do in such a > situation? Not care. Produce a resulting list where for any [..., x, ..., y, ...] in the result, y <= x implies x <= y. Vacuously satisfied in the case of incomparable elements. In the case of a total order, that gives you y <= x implies x = y (and everything in between), but for a preorder, you put less in, you get less out. Will that do? Conor From ajb at spamcop.net Thu Mar 13 20:29:06 2008 From: ajb at spamcop.net (ajb@spamcop.net) Date: Thu Mar 13 20:26:06 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: <47D9B824.6090407@iee.org> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <47D5416C.808@iee.org> <871w6i8wx4.fsf@nmd9999.imr.no> <47D55287.5040701@iee.org> <404396ef0803100829h44c8ac1dg4ee6f0132cb4f929@mail.gmail.com> <47D56B7A.2030200@iee.org> <220e47b40803101207w6d4bb795k68d959b3ccff9849@mail.gmail.com> <47D5A46A.5010800@iee.org> <404396ef0803101433s435bbc64j46617fe50ba46aa5@mail.gmail.com> <47D63C44.7070704@iee.org> <6dbd4d000803110846k3fcb94a8k9ad780c2dd8272fc@mail.gmail.com> <47D6B140.4010002@iee.org> <47D7E0F5.6090907@jellybean.co.uk> <20080312194804.o14f2bxhcwgo00sw@webmail.spamcop.net> <47D8D11F.3010002@iee.org> <20080313182842.23pl2dtt4owoo4sg@webmail.spamcop.net> <47D9B824.6090407@iee.org> Message-ID: <20080313202906.dla6dyqv8gow4goo@webmail.spamcop.net> G'day all. Quoting Adrian Hey : > If that's supposed it imply you think I'm in a minority of one I > don't think you've been following this thread very well. Sorry, that was a bit of hyperbole. > Even the report uses the word "equality" in the prose. Indeed, and the only sensible meaning of "equality" that I can think of is _semantic_ equality. Two values are semantically equal if they mean the same thing. A concrete example of a quotient type that I had in mind is rationals. A rational is implemented as, for the sake of argument, a pair of integers. Two rational numbers, a/b and c/d, are equal iff ad = bc. That's what everyone means by equality for rationals. It's true that rationals have a normal form, and this can be enforced by a smart constructor and an unbreakable abstraction. But if you've got an unbreakable abstraction, then you've also got the mechanism to enforce observational equality. Moreover, not all quotient types have a "one true" normal form (e.g. regular expressions), and even in cases where there is a sensible normal form, it might be undesirable for reasons of performance or convenience. > Besides there are good pragmatic safety and performance reasons > why Haskell should provide at least one class that offers > strong guarantees regarding equality and the (==) operator. Well, I haven't heard any reasons that have convinced me yet. No arguing over taste, of course. > ..and has almost certainly been implicitly assumed by heaven knows > what extant code (some of it in the standard libraries I suspect). Nobody has yet gone to the trouble of consulting either heaven or the source code (in whatever order is deemed appropriate) to see if this claim is true. Cheers, Andrew Bromage From conor at strictlypositive.org Thu Mar 13 21:42:28 2008 From: conor at strictlypositive.org (Conor McBride) Date: Thu Mar 13 21:39:26 2008 Subject: Some clarity please! (was Re: [Haskell-cafe] Re: (flawed?) benchmark : sort) In-Reply-To: <20080313234203.15473.qmail@schroeder.cas.mcmaster.ca> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <47D52A87.9060805@iee.org> <404396ef0803100632w6ae183f3w467aa02bae40caa2@mail.gmail.com> <47D5416C.808@iee.org> <871w6i8wx4.fsf@nmd9999.imr.no> <47D55287.5040701@iee.org> <404396ef0803100829h44c8ac1dg4ee6f0132cb4f929@mail.gmail.com> <47D56B7A.2030200@iee.org> <220e47b40803101207w6d4bb795k68d959b3ccff9849@mail.gmail.com> <47D5A46A.5010800@iee.org> <404396ef0803101433s435bbc64j46617fe50ba46aa5@mail.gmail.com> <47D63C44.7070704@iee.org> <47D8345A.9000201@iee.org> <47D8F442.40704@iee.org> <20080313161710.15217.qmail@schroeder.cas.mcmaster.ca> <0D3128D3-2493-498B-9966-4253804487C5@strictlypositive.org> <20080313234203.15473.qmail@schroeder.cas.mcmaster.ca> Message-ID: <1A9C4D4A-E2F1-4D64-A840-E474001C5D78@strictlypositive.org> Hi On 13 Mar 2008, at 23:42, kahl@cas.mcmaster.ca wrote: > Conor McBride responded to my comment: > >>> (mapMonotonic should of course be removed, too, >>> or specified to fail (preferably in some MonadZero) >>> if the precondition is violated, >>> which should still be implementable in linear time.) >> >> What's wrong with mapMonotonic that isn't wrong >> with, say, sortBy?, or Eq instances for parametrized >> types? > > Prelude> :m + Data.Set > Prelude Data.Set> toAscList $ mapMonotonic (10 -) (fromList [1 .. 5]) > [9,8,7,6,5] > Prelude Data.Set> 5 `member` mapMonotonic (10 -) (fromList [1 .. 5]) > False > > > Something's certainly wrong there! But nothing out of the ordinary: garbage in, garbage out. Happens all the time, even in Haskell. Why pick on mapMonotonic? Prelude Data.List> sortBy (\_ _ -> GT) [1,3,2,5,4] [4,5,2,3,1] Prelude Data.List> sortBy (\_ _ -> GT) [4,5,3,2,1] [1,2,3,5,4] I guess there's a question of what we might call "toxic waste"---junk values other than undefined. I think undefined is bad enough already. So the type system can't express the spec. I don't think we should be casual about that: we should be precise in documentation about the obligations which fall on the programmer. Some dirt is pragmatically necessary: we shouldn't pretend that it ain't so; we shouldn't pretend that dirt is clean. > > >> >> Before we can talk about what == should return, >> can we settle what we mean by = ? > > ``='' is not in the Haskell interface! ;-) No, but "is" is in the human interface! > > Therefore, I talked only about (==). Ah, but you talked about things. Which things? Is one of the things you talked about the same as (==)? the same as (flip (==))? > > The best way to include ``='' seems to be the semantic equality of > P-logic > [Harrison-Kieburtz-2005], which is quite a heavy calibre, > and at least in that paper, classes are not yet included. I expect it's hard work. It's hard work in much better behaved systems. My point is that it's worth it, in order to facilitate more meaningful discussions. All the best Conor From robdockins at fastmail.fm Thu Mar 13 23:01:47 2008 From: robdockins at fastmail.fm (Robert Dockins) Date: Thu Mar 13 22:53:47 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <00E7D026-8FAF-4BEE-9049-456374CE70C3@strictlypositive.org> Message-ID: <200803132301.47720.robdockins@fastmail.fm> On Thursday 13 March 2008 07:33:12 pm Aaron Denney wrote: [snip] > I've seen mention of difficulties with Data.Map, and edison, but not > in enough detail to really grasp what the problems are. Until I do, my > natural bias (which I'm trying to resist, really) is that it's a matter > of lazy coding, not any inherent difficulty. For the specific case of Edison, the Haddock documentation for the following two modules tells the whole sordid story: http://hackage.haskell.org/packages/archive/EdisonAPI/1.2.1/doc/html/Data-Edison.html http://hackage.haskell.org/packages/archive/EdisonAPI/1.2.1/doc/html/Data-Edison-Coll.html The Cliff Notes version is that Edison assumes the following things about Eq and Ord instances: * An Eq instance correctly defines an equivalence relation (but not necessarily structural equality); that is, we assume (==) (considered as a relation) is reflexive, symmetric and transitive, but allow that equivalent items may be distinguishable by other means. * An Ord instance correctly defines a total order which is consistent with the Eq instance for that type. It's not explicitly stated, but Edison also assumes that the operations within a class are consistent, i.e., that (not (x == y)) calculates the same function as (x /= y), etc. I suppose that should go in the docs too. Edison makes no particular assumptions about min and max, except that they are consistent with the defined order. Anyway, the end result for Edison is that some operations aren't well-defined, and can't be made well-defined without restrictions. For example, consider the operation of folding in non-decreasing order over the elements of a multi-set. If the function being folded distinguishes between two elements x and y, but (compare x y) = EQ, and x and y are both contained in the multi-set, then the result of the fold depends on internal state that is not supposed to be user-visible (e.g., the exact shape of a balanced tree). Blah, blah, blah, its all in the documentation. The point is that making loose assumptions about the meaning of the operations provided by Eq and Ord complicates things in ways that can't be made to go away. Rob Dockins From donnie at darthik.com Thu Mar 13 23:47:27 2008 From: donnie at darthik.com (Donnie Jones) Date: Thu Mar 13 23:44:29 2008 Subject: [Haskell-cafe] Ackermann Function Memoization, GHC Weird Output or Bug? Message-ID: Hello, I'm learning Haskell, so I was attempting memoization based upon the Fibonacci examples but for the Ackermann function. In my tests, I found what seems to be truncated output. See my comments at the end of the code for the test cases and output. ### Begin Code ### module Main where import Data.Array main = do let m = 3 n = 1 a = ackermann_mem m n putStrLn("Ackermann-mem " ++ show m ++ " " ++ show n ++ " = " ++ show a) -- Functions. -- Based upon examples from: -- http://reddit.com/r/programming/info/16ofr/comments) tabulate bounds f = array bounds [(i, f i) | i <- range bounds] dp bounds f = (memo!) where memo = tabulate bounds (f (memo!)) -- Trying to apply memoization function to Ackermann. ackermann_mem m n = dp ((0,0), (30, 1000)) ack (m, n) where ack rec (0, n) = n + 1 ack rec (m, 0) = rec (m - 1, 1) ack rec (m, n) = rec (m - 1, rec (m, n - 1)) {- Test cases: ackermann_mem 4 1 = 533 -- when using (30, 1000) as upper bound. ackermann_mem 4 1 = 5533 -- when using (30, 10000) as upper bound. ackermann_mem 4 1 = 65533 -- when using (30, 100000) as upper bound. <--- correct answer! -} ### End Code ### It seems if I don't choose an upper bound pair for (m,n) that is large enough I get truncated output for the answer, instead of GHC giving me an array index exception... This behavior seems very odd to me, can someone explain? Or is this a bug? Thank you. __ Donnie Jones -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080313/ba95620d/attachment.htm From rl at cse.unsw.edu.au Thu Mar 13 23:48:42 2008 From: rl at cse.unsw.edu.au (Roman Leshchinskiy) Date: Thu Mar 13 23:46:16 2008 Subject: Some clarity please! (was Re: [Haskell-cafe] Re: (flawed?) benchmark : sort) In-Reply-To: <47D8F442.40704@iee.org> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <47D52A87.9060805@iee.org> <404396ef0803100632w6ae183f3w467aa02bae40caa2@mail.gmail.com> <47D5416C.808@iee.org> <871w6i8wx4.fsf@nmd9999.imr.no> <47D55287.5040701@iee.org> <404396ef0803100829h44c8ac1dg4ee6f0132cb4f929@mail.gmail.com> <47D56B7A.2030200@iee.org> <220e47b40803101207w6d4bb795k68d959b3ccff9849@mail.gmail.com> <47D5A46A.5010800@iee.org> <404396ef0803101433s435bbc64j46617fe50ba46aa5@mail.gmail.com> <47D63C44.7070704@iee.org> <47D8345A.9000201@iee.org> <47D8F442.40704@iee.org> Message-ID: <47D9F59A.2080703@cse.unsw.edu.au> Adrian Hey wrote: > > I would ask for any correct Eq instance something like the law: > (x==y) = True implies x=y (and vice-versa) > which implies f x = f y for all definable f > which implies (f x == f y) = True (for expression types which are > instances of Eq). This pretty much requires structural equality > for concrete types. For abstract types you can do something different > provided functions which can give different answers for two "equal" > arguments are not exposed. How do you propose something like this to be specified in the language definition? The report doesn't (and shouldn't) know about abstract types. It only talks about things which are exported and things which are not. The distinction between implementation modules and client modules is made by the programmer, not by the language. So you can either require your law to hold everywhere, which IMO isn't a good idea, or you don't require it to hold. From the language definition point of view, I don't see any middle ground here. Also, when you talk about definable functions, do you include things like I/O? What if I want to store things (such as a Set) on a disk? If the same abstract value can have multiple representations, do I have to convert them all to some canonical representation before writing them to a file? This might be rather slow and is, IMO, quite unnecessary. From a more philosophical points of view, I'd say that the appropriate concept of equality depends a lot on the problem domain. Personally, I quite strongly disagree with restricting Eq instances in the way you propose. I have never found much use for strict structural equality (as opposed to domain-specific equality which may or may not coincide with the structural one). > On the subject of ambiguity, bugs and maxima, I see we have in Data.List > > [...] > > So I believe I'm correct in saying that maximumBy returns the last > of several possible maximum elements of the list. This obviously > needs specifying in the Haddock. > > Because maximumBy documentation is ambiguous in this respect, so is the > overloaded maximum documentation. At least you can't figure it out from > the Haddock. Why not simply say that maximumBy returns some maximum element from the list but it's not specified which one? That's how I always understood the spec. Code which needs a particular maximum element can't use maximumBy but such code is rare. I don't see how this is ambiguous, it just leaves certain things unspecified which is perfectly ok. Roman From s.clover at gmail.com Fri Mar 14 00:06:24 2008 From: s.clover at gmail.com (Sterling Clover) Date: Fri Mar 14 00:02:52 2008 Subject: [Haskell-cafe] Problem making a program in ghc In-Reply-To: <396556a20803131247r7c34dfacieb4718770494dd77@mail.gmail.com> References: <95129.40228.qm@web33405.mail.mud.yahoo.com> <396556a20803131247r7c34dfacieb4718770494dd77@mail.gmail.com> Message-ID: <009C3A61-3F0F-4A84-832E-DB9E8B7E2DBF@gmail.com> This answer may be way off base, but if differences appear between ghci and compiled versions, I've often found its as simple as remembering to compile with the -threaded flag. The ghci runtime is threaded by default, as I understand it, while compiled binaries are not, and IO operations will block in very different fashions (i.e. in their own thread, or stalling the entire app) depending on the runtime. Regards, sterl. On Mar 13, 2008, at 3:47 PM, Adam Langley wrote: >> web application), >> I have a log that confirms that the response arrives correctly. > > I hate to see any requests for help go unanswered here, but this one > might be tough. I think you need to give some more information, > otherwise the suggestions are going to be very general. Can you put > the Haskell source code on a website somewhere and link to it. Since > it's a network service, an example request and reply might be good to > include. > > In general, you should check that you are correctly flushing your > connection. If you are using Handles to interface to the network, they > can buffer the response. hFlush[1] may need to be called when you have > finished generating it. > > [1] http://haskell.org/ghc/docs/latest/html/libraries/base/System- > IO.html#v%3AhFlush > > AGL > > -- > Adam Langley agl@imperialviolet.org http://www.imperialviolet.org > _______________________________________________ > Haskell-Cafe mailing list From allbery at ece.cmu.edu Fri Mar 14 00:20:04 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Fri Mar 14 00:17:06 2008 Subject: [Haskell-cafe] Ackermann Function Memoization, GHC Weird Output or Bug? In-Reply-To: References: Message-ID: On Mar 13, 2008, at 23:47 , Donnie Jones wrote: > It seems if I don't choose an upper bound pair for (m,n) that is > large enough I get truncated output for the answer, instead of GHC > giving me an array index exception... This behavior seems very odd > to me, can someone explain? Or is this a bug? Per http://www.haskell.org/ghc/docs/latest/html/libraries/base/ Control-Exception.html: "NOTE: GHC currently does not throw ArrayExceptions" -- 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 lgreg.meredith at biosimilarity.com Fri Mar 14 00:58:16 2008 From: lgreg.meredith at biosimilarity.com (Greg Meredith) Date: Fri Mar 14 00:55:16 2008 Subject: [Haskell-cafe] Naming as infection Message-ID: <5de3f5ca0803132158wd804eafod37d67eb6a31b4eb@mail.gmail.com> All, Here is a deliberately provocative posting (with running code and a shameless plug for BNFC) on the process of introducing naming and name management into the design of data structures. Comments greatly appreciated. Best wishes, --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/20080313/565587d8/attachment.htm From valgarv at gmx.net Fri Mar 14 02:05:13 2008 From: valgarv at gmx.net (askyle) Date: Fri Mar 14 02:02:12 2008 Subject: [Haskell-cafe] A question about "monad laws" In-Reply-To: <200803132043.15469.g9ks157k@acme.softbase.org> References: <47B06B3B.2070504@cs.tcd.ie> <90533B63-96C0-4982-A695-8A217A61BBC2@cs.otago.ac.nz> <47B39936.10509@cse.unsw.edu.au> <6A400340-AA2D-47F9-9552-EAAED17F6403@cs.otago.ac.nz> <47B3CB1D.6040404@cse.unsw.edu.au> <47B408B2.3090900@cse.unsw.edu.au> <15976463.post@talk.nabble.com> <200803132043.15469.g9ks157k@acme.softbase.org> Message-ID: <16044986.post@talk.nabble.com> Wolfgang Jeltsch-2 wrote: > > No, I think, it?s the Prelude?s fault to define (==) as ?floating point > equality?. > My bad, I meant IEEE (==) when I said it was "our" fault. I concur that the Prelude is at fault for using the (==) symbol for FP equality. Even if you don't demand from (==) to be an equivalence, you're giving a pure functional type to an impure operation (e.g because of SNaNs) My point was that since Haskell has a known and established mechanism for delimiting impurity, it seems as a shame not to use it to add some rigour to the myth-ridden, poorly understood floating point world. We need good FP for FP =) ----- Ariel J. Birnbaum -- View this message in context: http://www.nabble.com/A-question-about-%22monad-laws%22-tp15411587p16044986.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. From emertens at gmail.com Fri Mar 14 02:07:03 2008 From: emertens at gmail.com (Eric Mertens) Date: Fri Mar 14 02:04:02 2008 Subject: [Haskell-cafe] Ackermann Function Memoization, GHC Weird Output or Bug? In-Reply-To: References: Message-ID: <449c8cfc0803132307s64143823qa8f949930315dfd2@mail.gmail.com> Smaller example of this behavior: > array ((0,0),(1,1)) [((1,1),6)] ! (0,3) 6 -- Eric Mertens From valgarv at gmx.net Fri Mar 14 02:22:57 2008 From: valgarv at gmx.net (askyle) Date: Fri Mar 14 02:19:57 2008 Subject: [Haskell-cafe] A question about "monad laws" In-Reply-To: <20080312205352.zruv2qkjk04s88cg@webmail.spamcop.net> References: <404396ef0802110538q15db024cj2291edc87b873249@mail.gmail.com> <404396ef0802110559gea267b8q61646b85295ecfa9@mail.gmail.com> <20080211213454.GA3783@localhost.localdomain> <15975734.post@talk.nabble.com> <20080312205352.zruv2qkjk04s88cg@webmail.spamcop.net> Message-ID: <16045123.post@talk.nabble.com> ajb-2 wrote: > > Define: > f >=> g = \x -> f x >>= g > So you're either not taking (>=>) as primitive or you're stating the additional property that there exists (>>=) such that f >=> g === (>>= g) . f (from which you can easily show that (f . g) >=> h === (f >=> h) . g ). A presentation of the monad laws based on (>=>) (I prefer (<=<) since it meshes better with (.) ) should (IMHO) regard (>=>) as primitive and state its needed properties whence one can derive all other formulations (Note that he Identity law then requires the existence of return as another primitive). That done, you define (>>=), fmap and the rest in terms of (<=<) : (>>=) = flip (<=< id) -- I like to put it as (>>= g) = (g <=< id) fmap f = (return . f) <=< id ----- Ariel J. Birnbaum -- View this message in context: http://www.nabble.com/A-question-about-%22monad-laws%22-tp15411587p16045123.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. From ajb at spamcop.net Fri Mar 14 02:28:21 2008 From: ajb at spamcop.net (ajb@spamcop.net) Date: Fri Mar 14 02:25:21 2008 Subject: [Haskell-cafe] A question about "monad laws" In-Reply-To: <16045123.post@talk.nabble.com> References: <404396ef0802110538q15db024cj2291edc87b873249@mail.gmail.com> <404396ef0802110559gea267b8q61646b85295ecfa9@mail.gmail.com> <20080211213454.GA3783@localhost.localdomain> <15975734.post@talk.nabble.com> <20080312205352.zruv2qkjk04s88cg@webmail.spamcop.net> <16045123.post@talk.nabble.com> Message-ID: <20080314022821.kn171tmtcwwsc44s@webmail.spamcop.net> G'day all. Quoting askyle : > So you're either not taking (>=>) as primitive or you're stating the > additional > property that there exists (>>=) such that f >=> g === (>>= g) . f > (from which you can easily show that (f . g) >=> h === (f >=> h) . g ). If you wanted to prove that bind is natural, you would need to define bind, no? Cheers, Andrew Bromage From cgibbard at gmail.com Fri Mar 14 02:33:18 2008 From: cgibbard at gmail.com (Cale Gibbard) Date: Fri Mar 14 02:30:17 2008 Subject: [Haskell-cafe] Ackermann Function Memoization, GHC Weird Output or Bug? In-Reply-To: <449c8cfc0803132307s64143823qa8f949930315dfd2@mail.gmail.com> References: <449c8cfc0803132307s64143823qa8f949930315dfd2@mail.gmail.com> Message-ID: <89ca3d1f0803132333r6cc1a07cu11fd3c066330b35f@mail.gmail.com> Here's the bug: {-# INLINE safeIndex #-} safeIndex :: Ix i => (i, i) -> Int -> i -> Int safeIndex (l,u) n i = let i' = unsafeIndex (l,u) i in if (0 <= i') && (i' < n) then i' else error "Error in array index" unsafeIndex here is just a function which transforms indices into Int indices into the flat array and does no checking of validity. Then safeIndex simply checks if the result is nonnegative and less than the size of the array. Whoops! The actual test to see if the index was valid in the first place didn't actually get performed! - Cale On 14/03/2008, Eric Mertens wrote: > Smaller example of this behavior: > > > array ((0,0),(1,1)) [((1,1),6)] ! (0,3) > 6 > > -- > > Eric Mertens > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From conor at strictlypositive.org Fri Mar 14 05:48:33 2008 From: conor at strictlypositive.org (Conor McBride) Date: Fri Mar 14 05:45:30 2008 Subject: Some clarity please! (was Re: [Haskell-cafe] Re: (flawed?) benchmark : sort) In-Reply-To: <47D9F59A.2080703@cse.unsw.edu.au> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <47D52A87.9060805@iee.org> <404396ef0803100632w6ae183f3w467aa02bae40caa2@mail.gmail.com> <47D5416C.808@iee.org> <871w6i8wx4.fsf@nmd9999.imr.no> <47D55287.5040701@iee.org> <404396ef0803100829h44c8ac1dg4ee6f0132cb4f929@mail.gmail.com> <47D56B7A.2030200@iee.org> <220e47b40803101207w6d4bb795k68d959b3ccff9849@mail.gmail.com> <47D5A46A.5010800@iee.org> <404396ef0803101433s435bbc64j46617fe50ba46aa5@mail.gmail.com> <47D63C44.7070704@iee.org> <47D8345A.9000201@iee.org> <47D8F442.40704@iee.org> <47D9F59A.2080703@cse.unsw.edu.au> Message-ID: <795738AA-4A33-4A70-A325-318E10357A5E@strictlypositive.org> Hi On 14 Mar 2008, at 03:48, Roman Leshchinskiy wrote: > Adrian Hey wrote: >> I would ask for any correct Eq instance something like the law: >> (x==y) = True implies x=y (and vice-versa) >> which implies f x = f y for all definable f >> which implies (f x == f y) = True (for expression types which are >> instances of Eq). This pretty much requires structural equality >> for concrete types. For abstract types you can do something different >> provided functions which can give different answers for two "equal" >> arguments are not exposed. > > How do you propose something like this to be specified in the > language definition? The report doesn't (and shouldn't) know about > abstract types. Why not? Why shouldn't there be at least a standard convention, if not an abstype-like feature for establishing an abstraction barrier, and hence determine the appropriate observational equality for an abstract type? > So you can either require your law to hold everywhere, which IMO > isn't a good idea, or you don't require it to hold. From the > language definition point of view, I don't see any middle ground here. Why not demand it in the definition, but allow "unsafe" leaks in practice? As usual. Why are you so determined that there's nothing principled to do here? People like to say "Haskell's easy to reason about". How much of a lie would you like that not to be? > Also, when you talk about definable functions, do you include > things like I/O? What if I want to store things (such as a Set) on > a disk? If the same abstract value can have multiple > representations, do I have to convert them all to some canonical > representation before writing them to a file? Canonical representations are not necessary for observational congruence. Representation hiding is enough. > This might be rather slow and is, IMO, quite unnecessary. > > From a more philosophical points of view, I'd say that the > appropriate concept of equality depends a lot on the problem domain. It's certainly true that different predicates may respect different equivalence relations. The equivalence relation you call equality should be the finest of those, with finer representational distinctions abstracted away. What that buys you is a class of predicates which are guaranteed to respect equality without further ado... > Personally, I quite strongly disagree with restricting Eq instances > in the way you propose. I have never found much use for strict > structural equality (as opposed to domain-specific equality which > may or may not coincide with the structural one). ...which is how we use equality when we think. I certainly don't think "strict structural equality" should be compulsory. In fact, for Haskell's lazy data structures, you rather need lazy structural simulation if you want to explain why cycle "x" = cycle "xx" What would be so wrong with establishing a convention for saying, at each given type (1) this is the propositional equivalence which we expect functions on this type to respect (2) here is an interface which respects that equivalence (3) here are some unsafe functions which break that equivalence: use them at your own risk ? Why is it pragmatically necessary to make reasoning difficult? I'm sure that wise folk out there have wise answers to that question which they don't consider to be an embarrassment. When representation-hiding is bliss, 'tis folly to be wise. All the best Conor From gn at oglaroon.de Fri Mar 14 07:38:02 2008 From: gn at oglaroon.de (Georg Neis) Date: Fri Mar 14 07:34:58 2008 Subject: [Haskell-cafe] HFuse: ls fails in HelloFS Message-ID: Hello, I've installed the HFuse package from hackage and am playing with the HelloFS example in the System/Posix/HFuse directory. The problem that I encounter is that listing the directory doesn't work: % ghc --make HelloFS.hs [1 of 1] Compiling Main ( HelloFS.hs, HelloFS.o ) Linking HelloFS ... % mkdir bla % ./HelloFS bla % cd bla % cat hello Hello World, HFuse! % ls ls: cannot open directory .: Function not implemented Here's the relevant output from strace: open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|0x80000) = -1 ENOSYS (Function not implemented) write(2, "ls: ", 4ls: ) = 4 write(2, "cannot open directory .", 23cannot open directory .) = 23 write(2, ": Function not implemented", 26: Function not implemented) = 26 Some system information: - Debian unstable - Linux 2.6.24 - Fuse 2.7.3 - GHC 6.8.2 - HFuse 0.1 Any ideas? Thanks, Georg From ahey at iee.org Fri Mar 14 09:16:10 2008 From: ahey at iee.org (Adrian Hey) Date: Fri Mar 14 09:13:10 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: <47D58494.7080003@imageworks.com> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <220e47b40803091848u5925dbe9l261a7ca076f9069e@mail.gmail.com> <200803092304.02063.dan.doel@gmail.com> <404396ef0803100127p4e99997amf2e2a6d70dce6e8b@mail.gmail.com> <47D514C2.8050102@iee.org> <47D58494.7080003@imageworks.com> Message-ID: <47DA7A9A.5070704@iee.org> Dan Weston wrote: > 6.3.2 (The Ord Class): > > "The Ord class is used for totally ordered datatypes." > > This *requires* that it be absolutely impossible in valid code to > distinguish equivalent (in the EQ sense, not the == sense) things via > the functions of Ord. The intended interpretation of these functions is > clear and can be taken as normative: > > forall f . (compare x y == EQ and (f x or f y is defined)) > ==> f x == f y) Thanks Dan. I didn't grasp the significance of this at first, but I believe you are correct. But maybe it should be "=" not "==" in the last line? > forall f . (compare x y == EQ and (f x or f y is defined)) > ==> f x = f y) So assuming your (and my) logic is correct, the existing report text does indeed settle the original dispute that sparked this thread. Essentially you can't have 2 distinct values that compare equal, so if they do then they must be indistinguishable? Is that right? So there is no need for the sort on a list of elements whose type is an instance of Ord to be "stable" as the difference between the results of a stable and unstable sort cannot be observable for any (correct) Ord instance (assuming the the instances compare method was used to perform the sort). So if we have a compare method on this type we can establish the == method: x == y = case compare x y of EQ -> True _ -> False and from this it follows that (x == y) = True implies x and y are indistingushable. So I believe for types that are instances of both Eq and Ord, this settles the question of what (x == y) = True implies. So now I'm wondering what about types that are instances of Eq but not of Ord? Well from para. 6.3.1 "The Eq class provides equality (==) and inequality (/=) methods." Well I guess assuming that saying two values are "equal" is another way of saying they are indistinguishable then I think it's pretty clear what the report is saying. This interpretation also ensures consistency between Eq/Ord instances and Eq only instances. Assuming this is all correct, I think I can sleep easier now I can forget about all this "things being equal and not equal at the same time" craziness, at least for Eq/Ord instances that are compliant with the standard (which are the only ones I care about). I think anyone wanting standard classes with different mathematical properties should define them, stick them in Hackage and propose them for Haskell-prime (if that's still happening?) Regards -- Adrian Hey From bulat.ziganshin at gmail.com Fri Mar 14 07:23:25 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Fri Mar 14 09:15:33 2008 Subject: [Haskell-cafe] Problem making a program in ghc In-Reply-To: <009C3A61-3F0F-4A84-832E-DB9E8B7E2DBF@gmail.com> References: <95129.40228.qm@web33405.mail.mud.yahoo.com> <396556a20803131247r7c34dfacieb4718770494dd77@mail.gmail.com> <009C3A61-3F0F-4A84-832E-DB9E8B7E2DBF@gmail.com> Message-ID: <1392413705.20080314142325@gmail.com> Hello Sterling, Friday, March 14, 2008, 7:06:24 AM, you wrote: yes, it's another question. my own program also writes to logfile and it got lock-free only when i've switched to using my own IO routines > This answer may be way off base, but if differences appear between > ghci and compiled versions, I've often found its as simple as > remembering to compile with the -threaded flag. The ghci runtime is > threaded by default, as I understand it, while compiled binaries are > not, and IO operations will block in very different fashions (i.e. in > their own thread, or stalling the entire app) depending on the runtime. > Regards, > sterl. > On Mar 13, 2008, at 3:47 PM, Adam Langley wrote: >>> web application), >>> I have a log that confirms that the response arrives correctly. >> >> I hate to see any requests for help go unanswered here, but this one >> might be tough. I think you need to give some more information, >> otherwise the suggestions are going to be very general. Can you put >> the Haskell source code on a website somewhere and link to it. Since >> it's a network service, an example request and reply might be good to >> include. >> >> In general, you should check that you are correctly flushing your >> connection. If you are using Handles to interface to the network, they >> can buffer the response. hFlush[1] may need to be called when you have >> finished generating it. >> >> [1] http://haskell.org/ghc/docs/latest/html/libraries/base/System- >> IO.html#v%3AhFlush >> >> AGL >> >> -- >> Adam Langley agl@imperialviolet.org http://www.imperialviolet.org >> _______________________________________________ >> Haskell-Cafe mailing list > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From vitaliy.akimov at gmail.com Fri Mar 14 09:48:03 2008 From: vitaliy.akimov at gmail.com (Vitaliy Akimov) Date: Fri Mar 14 09:45:01 2008 Subject: [Haskell-cafe] all threads are blocked by recvFrom Message-ID: Hello, I have a problem with building multithreaded UDP server. If main thread is waiting for new request in recvFrom all other threads are blocked too. I've checked every variant with forkIO,forkOS,-threaded etc, nothing's helped. After reading GHC docs I've understood this is happened becouse foreign function call from recvFrom (network library) is marked to be unsefe, so it's execution blocks every other thread. How can I resolve it? Thank you. Vitaliy. From Anurag.Verma at motorola.com Fri Mar 14 09:54:11 2008 From: Anurag.Verma at motorola.com (Verma Anurag-VNF673) Date: Fri Mar 14 09:53:50 2008 Subject: [Haskell-cafe] FFI newbie question Message-ID: I am trying to figure out how to pass array of String (char **) from C to Haskell? I have read the FFI examples, but most of them are centered on calling C from Haskell. I have read in the mailing list, it is rare to call Haskell from C, but my requirement is such that I am going to write Haskell library that needs to be called from C. Also, I read that the linking in FFI needs to be done through ghc. However, I have an existing Make system that uses gcc to do the linking, so what extra steps I need to do make gcc do the linking instead? Anurag -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080314/1a9aa051/attachment.htm From g9ks157k at acme.softbase.org Fri Mar 14 10:13:49 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Fri Mar 14 10:11:57 2008 Subject: [Haskell-cafe] A question about "monad laws" In-Reply-To: <47D98A31.7010407@imageworks.com> References: <200803132043.15469.g9ks157k@acme.softbase.org> <47D98A31.7010407@imageworks.com> Message-ID: <200803141513.49173.g9ks157k@acme.softbase.org> Am Donnerstag, 13. M?rz 2008 21:10 schrieben Sie: > Not to be picky, but where did you hear that (==) established an > equivalence relation? I think that?s the way it should be according to most Haskeller?s opinion. It might be true that the Haskell 98 report doesn?t say so but I think that many library types and functions (Data.Set stuff, for example) rely on this. A future standard should state laws an instance has to obey for every class it introduces. > [?] Best wishes, Wolfgang From rl at cse.unsw.edu.au Fri Mar 14 10:15:29 2008 From: rl at cse.unsw.edu.au (Roman Leshchinskiy) Date: Fri Mar 14 10:12:50 2008 Subject: Some clarity please! (was Re: [Haskell-cafe] Re: (flawed?) benchmark : sort) In-Reply-To: <795738AA-4A33-4A70-A325-318E10357A5E@strictlypositive.org> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <47D52A87.9060805@iee.org> <404396ef0803100632w6ae183f3w467aa02bae40caa2@mail.gmail.com> <47D5416C.808@iee.org> <871w6i8wx4.fsf@nmd9999.imr.no> <47D55287.5040701@iee.org> <404396ef0803100829h44c8ac1dg4ee6f0132cb4f929@mail.gmail.com> <47D56B7A.2030200@iee.org> <220e47b40803101207w6d4bb795k68d959b3ccff9849@mail.gmail.com> <47D5A46A.5010800@iee.org> <404396ef0803101433s435bbc64j46617fe50ba46aa5@mail.gmail.com> <47D63C44.7070704@iee.org> <47D8345A.9000201@iee.org> <47D8F442.40704@iee.org> <47D9F59A.2080703@cse.unsw.edu.au> <795738AA-4A33-4A70-A325-318E10357A5E@strictlypositive.org> Message-ID: <47DA8881.9070806@cse.unsw.edu.au> Conor McBride wrote: > Hi > > On 14 Mar 2008, at 03:48, Roman Leshchinskiy wrote: > >> Adrian Hey wrote: >>> I would ask for any correct Eq instance something like the law: >>> (x==y) = True implies x=y (and vice-versa) >>> which implies f x = f y for all definable f >>> which implies (f x == f y) = True (for expression types which are >>> instances of Eq). This pretty much requires structural equality >>> for concrete types. For abstract types you can do something different >>> provided functions which can give different answers for two "equal" >>> arguments are not exposed. >> >> How do you propose something like this to be specified in the language >> definition? The report doesn't (and shouldn't) know about abstract types. > > Why not? Why shouldn't there be at least a standard convention, > if not an abstype-like feature for establishing an abstraction > barrier, and hence determine the appropriate observational > equality for an abstract type? Adrian's original question/proposal was about the language report. I'm only pointing out that all other considerations aside, it's not clear how to distinguish between the implementation part of the ADT and everything else in the report. >> So you can either require your law to hold everywhere, which IMO >> isn't a good idea, or you don't require it to hold. From the language >> definition point of view, I don't see any middle ground here. > > Why not demand it in the definition, but allow "unsafe" leaks > in practice? As usual. Why are you so determined that there's > nothing principled to do here? People like to say "Haskell's > easy to reason about". How much of a lie would you like that > not to be? I'm not sure what you mean here. Should the report say something like "a valid Eq instance must ensure that x == y implies f x == f y for all f"? Probably not, since this requires structural equality which is not what you want for ADTs. Should it be "for all f which are not part of the implementation of the type"? That's a non-requirement if the report doesn't specify what the "implementation" is. So what should it say? "Unsafe leaks" are ok as long as they are rarely used. If you have to resort to unsafe leaks to define an ADT, then something is wrong. >> Also, when you talk about definable functions, do you include things >> like I/O? What if I want to store things (such as a Set) on a disk? If >> the same abstract value can have multiple representations, do I have >> to convert them all to some canonical representation before writing >> them to a file? > > Canonical representations are not necessary for observational > congruence. Representation hiding is enough. I beg to disagree. If the representation is stored on the disk, for instance, then it becomes observable, even if it's still hidden in the sense that you can't do anything useful with it other than read it back. Actually, we don't even need the disk. What about ADTs which implement Storable, for instance? > What would be so wrong with establishing a convention > for saying, at each given type > > (1) this is the propositional equivalence which > we expect functions on this type to respect > (2) here is an interface which respects that > equivalence > (3) here are some unsafe functions which break > that equivalence: use them at your own risk My (probably erroneous) understanding of the above is that you propose to call (==) "propositional equivalence" and to require that for every type, we define what that means. To be honest, I don't quite see how this is different from saying that the meaning of (==) should be documented for every type, which I wholeheartedly agree with. But the "unsafe" bit really doesn't make sense to me. As an example, consider the following data type: data Expr = Var String | Lam String Expr | App Expr Expr The most natural notion of equality here is probably equality up to alpha conversion and that's what I usually would expect (==) to mean. In fact, I would be quite surprised if (==) meant structural equality. Should I now consider the Show instance for this type somehow unsafe? I don't see why this makes sense. Most of the time I probably don't even want to make this type abstract. Are the constructors also unsafe? Why? To summarise my views on this: an Eq instance should define a meaningful equivalence relation and be documented. Requiring anything beyond that just doesn't make sense to me. Roman From john at repetae.net Fri Mar 14 10:29:25 2008 From: john at repetae.net (John Meacham) Date: Fri Mar 14 10:26:23 2008 Subject: [Haskell-cafe] FFI newbie question In-Reply-To: References: Message-ID: <20080314142925.GA30301@sliver.repetae.net> On Fri, Mar 14, 2008 at 09:54:11PM +0800, Verma Anurag-VNF673 wrote: > I am trying to figure out how to pass array of String (char **) from C > to Haskell? I have read the FFI examples, but most of them are centered > on calling C from Haskell. I have read in the mailing list, it is rare > to call Haskell from C, but my requirement is such that I am going to > write Haskell library that needs to be called from C. here is a simple example. the first argument is the number of strings, the second is the pointer. The same code will work whether you are calling C from haskell or vice versa. getargs :: Int -> (Ptr CString) -> IO [String] getArgs argc argv = do let f n = peekElemOff argv n >>= peekCString mapM f [0 .. fromIntegral argc - 1] John -- John Meacham - ?repetae.net?john? From vitaliy.akimov at gmail.com Fri Mar 14 10:43:15 2008 From: vitaliy.akimov at gmail.com (Vitaliy Akimov) Date: Fri Mar 14 10:40:14 2008 Subject: [Haskell-cafe] Re: all threads are blocked by recvFrom In-Reply-To: References: Message-ID: Rebuilding of the network package with changed safety helped but I don't think this is the solution. BTW accept is declared as safe. What is the reason of declaring recvFrom as unsafe? I think this breaks highly required feature. Apparently it's impossible to make concurrent server for non connection based protocols. 2008/3/14, Vitaliy Akimov : > Hello, I have a problem with building multithreaded UDP server. If > main thread is waiting for new request in recvFrom all other threads > are blocked too. I've checked every variant with > forkIO,forkOS,-threaded etc, nothing's helped. After reading GHC docs > I've understood this is happened becouse foreign function call from > recvFrom (network library) is marked to be unsefe, so it's execution > blocks every other thread. How can I resolve it? > > Thank you. > > Vitaliy. > From agl at imperialviolet.org Fri Mar 14 10:57:20 2008 From: agl at imperialviolet.org (Adam Langley) Date: Fri Mar 14 10:54:19 2008 Subject: [Haskell-cafe] Re: all threads are blocked by recvFrom In-Reply-To: References: Message-ID: <396556a20803140757w1ac429e3q6655078e30961a4e@mail.gmail.com> On Fri, Mar 14, 2008 at 7:43 AM, Vitaliy Akimov wrote: > Rebuilding of the network package with changed safety helped but I > don't think this is the solution. BTW accept is declared as safe. What > is the reason of declaring recvFrom as unsafe? I think this breaks > highly required feature. Apparently it's impossible to make concurrent > server for non connection based protocols. I assume that you're binding the libc function directly here: In that case, you need to have the RTS manage sleeping your thread for you. You should make the socket non-blocking and handle the EAGAIN and EWOULDBLOCK cases by calling threadWaitRead[1] to block the current Haskell thread only, until the fd is readable. Note that threadWaitRead is GHC only. If you download the source to network-bytestring[2], you can see a very similar pattern in the code for send and recv in there. Alternatively, you can use the functions in Network.Socket, which should work fine. [1] http://haskell.org/ghc/docs/latest/html/libraries/base/Control-Concurrent.html#v%3AthreadWaitRead [2] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/network-bytestring-0.1.1.2 -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org From vitaliy.akimov at gmail.com Fri Mar 14 11:51:17 2008 From: vitaliy.akimov at gmail.com (Vitaliy Akimov) Date: Fri Mar 14 11:48:16 2008 Subject: [Haskell-cafe] Re: all threads are blocked by recvFrom In-Reply-To: <396556a20803140757w1ac429e3q6655078e30961a4e@mail.gmail.com> References: <396556a20803140757w1ac429e3q6655078e30961a4e@mail.gmail.com> Message-ID: > I assume that you're binding the libc function directly here: I'm using Network.Socket. Sory if it's not clear from my previous posts. > In that case, you need to have the RTS manage sleeping your thread for > you. You should make the socket non-blocking and handle the EAGAIN and > EWOULDBLOCK cases by calling threadWaitRead[1] to block the current > Haskell thread only, until the fd is readable. Note that > threadWaitRead is GHC only. > If you download the source to network-bytestring[2], you can see a > very similar pattern in the code for send and recv in there. Thanks, but I haven't managed to find a way of setting a socket into non blocking mode without using FFI directly (and I haven't found solution in network-bytestring too). How can I make this? The only way I've found is making handle by socketToHandle then reading by hGetBufNonBlocking. But this way seems not suited for non-connection based sockets. From g9ks157k at acme.softbase.org Fri Mar 14 12:30:19 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Fri Mar 14 12:28:16 2008 Subject: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?) In-Reply-To: <6a7c66fc0802020554i5e96eb84n296e2df8bfec9f46@mail.gmail.com> References: <6a7c66fc0801310302p6bdee4adm6cf6a2778772ecbf@mail.gmail.com> <200802012232.16922.g9ks157k@acme.softbase.org> <6a7c66fc0802020554i5e96eb84n296e2df8bfec9f46@mail.gmail.com> Message-ID: <200803141730.19202.g9ks157k@acme.softbase.org> Am Samstag, 2. Februar 2008 14:54 schrieben Sie: > On Feb 1, 2008 10:32 PM, Wolfgang Jeltsch wrote: > > Am Freitag, 1. Februar 2008 13:00 schrieb Alfonso Acosta: > [?] > > > To make it friendlier for the end user I thought about defining > > > aliases for lets say the first 10000 numbers using Template Haskell. > > > That could even make error reports friendlier (not sure to what point > > > though). What do you think? > > > > I have no clear opinion about that at the moment. Maybe it's okay to use > > the representation directly. This way, we don't introduce a dependeny on > > the Template Haskell language extension (which is only supported by GHC), > > and the actual representation will occur in error messages anyway > > whenever the message shows a computed number. > > Well, my EDSL already makes extensive use of TH. So, being selfish, it > wouldn't be a problem for me (or any other GHC user) and I think it > would make the library much more usable. Hello again, I have a feedback from my Grapefruit co-developer about those aliases in the type-level package. He told me that on his machine, building this package took about 15 minutes, obviously because the machine ran out of RAM. He also told me that the generated object code was very large, and that loading the documentation page generated by Haddock took very long. And he made a very good point: Who needs aliases for *all* numbers until, say, 10000? Who needs to hard-code the vector length 8247 in his code? I think that in practice, you only need very few numbers hard-coded. So it might be better to export a function for letting the package user generate the necessary aliases himself. I even think that it is probably sensible to drop the alias thing completely, at least if you have vector lengths in mind. What vector lengths will appear as fixed in a real world program? 1000? I think, usually you have only sizes like 2 or 3 hard-coded, for vectors in the mathematical sense. And their representation is already very short: D2, D3, ? Remember that computed numbers are not shown as aliases in error messages, only numbers that directly appear in your code. My co-author also mentioned that he doesn?t see much use for octal and hexadecimal notation. So I propose to drop alias support from type-level or at least let the package user do the necessary generation. > [?] Best wishes, Wolfgang From alfonso.acosta at gmail.com Fri Mar 14 12:46:48 2008 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Fri Mar 14 12:43:47 2008 Subject: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?) In-Reply-To: <200803141730.19202.g9ks157k@acme.softbase.org> References: <6a7c66fc0801310302p6bdee4adm6cf6a2778772ecbf@mail.gmail.com> <200802012232.16922.g9ks157k@acme.softbase.org> <6a7c66fc0802020554i5e96eb84n296e2df8bfec9f46@mail.gmail.com> <200803141730.19202.g9ks157k@acme.softbase.org> Message-ID: <6a7c66fc0803140946gb57e8c8k7277ba2be9a3e2d2@mail.gmail.com> On Fri, Mar 14, 2008 at 5:30 PM, Wolfgang Jeltsch wrote: > I have a feedback from my Grapefruit co-developer about those aliases in the > type-level package. He told me that on his machine, building this package > took about 15 minutes, obviously because the machine ran out of RAM. He also > told me that the generated object code was very large, and that loading the > documentation page generated by Haddock took very long. Fair point, it akes quite some time in my machine too (not 15minutes though) > And he made a very good point: Who needs aliases for *all* numbers until, say, > 10000? Who needs to hard-code the vector length 8247 in his code? If I remember correctly aliases are generated until decimal 5000, which might me really long anyway. > I think > that in practice, you only need very few numbers hard-coded. So it might be > better to export a function for letting the package user generate the > necessary aliases himself. > > I even think that it is probably sensible to drop the alias thing completely, > at least if you have vector lengths in mind. What vector lengths will appear > as fixed in a real world program? 1000? I think, usually you have only > sizes like 2 or 3 hard-coded, for vectors in the mathematical sense. And > their representation is already very short: D2, D3, ? Remember that computed > numbers are not shown as aliases in error messages, only numbers that > directly appear in your code. > > My co-author also mentioned that he doesn't see much use for octal and > hexadecimal notation. > > So I propose to drop alias support from type-level or at least let the package > user do the necessary generation. > I think that removing aliases completely is not a good idea. How about generating much lower aliases for decimals (lets say until 1000), droping the other bases, and exporting a function to extended the alias range at will? (that function could perfectly include the other bases as well). Something called extendAliases would do. I don't have the time to work on it now, but if you send me a patch I'd be happy to apply it. It should be something simple to do. All the Template Haskell machinery is already coded. > > [?] > > Best wishes, > Wolfgang > From list at phaedrusdeinus.org Fri Mar 14 13:05:02 2008 From: list at phaedrusdeinus.org (John Melesky) Date: Fri Mar 14 13:02:04 2008 Subject: [Haskell-cafe] File I/O question In-Reply-To: <47D845FF.7090209@btinternet.com> References: <47D829C4.6090802@btinternet.com> <20080312204233.GF9203@scytale.galois.com> <47D8451F.10304@btinternet.com> <20080312210459.GI9203@scytale.galois.com> <47D845FF.7090209@btinternet.com> Message-ID: <1D9E7C73-85DC-40EB-990A-4430A3258B5F@phaedrusdeinus.org> On Mar 12, 2008, at 4:07 PM, Andrew Coppin wrote: > I'm trying to read the file from Notepad.exe while my Haskell > program is still running - which takes about an hour. I'm not a Windows user, but... Is it possible that Notepad tries to write-lock by default (since it's an editor), and fails? Put another way, have you tried other ways of reading the file? Heck, copying the file should be a read-only action. Can you copy it during the runtime, and open the copy? -johnnnnnnn From agl at imperialviolet.org Fri Mar 14 13:13:47 2008 From: agl at imperialviolet.org (Adam Langley) Date: Fri Mar 14 13:10:45 2008 Subject: [Haskell-cafe] Re: all threads are blocked by recvFrom In-Reply-To: References: <396556a20803140757w1ac429e3q6655078e30961a4e@mail.gmail.com> Message-ID: <396556a20803141013w6ba1271bjc2ea1bbd9c80b729@mail.gmail.com> On Fri, Mar 14, 2008 at 8:51 AM, Vitaliy Akimov wrote: > > I assume that you're binding the libc function directly here: > > I'm using Network.Socket. Sory if it's not clear from my previous posts. Then everything should Just Work(tm). You might need to paste in code in order to figure out why this wouldn't be so. See [1] for an example which works for me. It starts a thread which prints "working..." once a second and, in another thread, listens for UDP packets on port 4112. I can use `nc -u 127.0.0.1 4112` to get this: "working..." "working..." ("testing\n",8,127.0.0.1:36179) "working..." "working..." ("testing two\n",12,127.0.0.1:36179) "working..." [1] http://hpaste.org/6362 -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org From apfelmus at quantentunnel.de Fri Mar 14 13:15:34 2008 From: apfelmus at quantentunnel.de (apfelmus) Date: Fri Mar 14 13:12:44 2008 Subject: [Haskell-cafe] Specification for Eq? In-Reply-To: <47DA8881.9070806@cse.unsw.edu.au> References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <47D52A87.9060805@iee.org> <404396ef0803100632w6ae183f3w467aa02bae40caa2@mail.gmail.com> <47D5416C.808@iee.org> <871w6i8wx4.fsf@nmd9999.imr.no> <47D55287.5040701@iee.org> <404396ef0803100829h44c8ac1dg4ee6f0132cb4f929@mail.gmail.com> <47D56B7A.2030200@iee.org> <220e47b40803101207w6d4bb795k68d959b3ccff9849@mail.gmail.com> <47D5A46A.5010800@iee.org> <404396ef0803101433s435bbc64j46617fe50ba46aa5@mail.gmail.com> <47D63C44.7070704@iee.org> <47D8345A.9000201@iee.org> <47D8F442.40704@iee.org> <47D9F59A.2080703@cse.unsw.edu.au> <795738AA-4A33-4A70-A325-318E10357A5E@strictlypositive.org> <47DA8881.9070806@cse.unsw.edu.au> Message-ID: Roman Leshchinskiy wrote: > Should the report say something like "a > valid Eq instance must ensure that x == y implies f x == f y for all f"? > Probably not, since this requires structural equality which is not what > you want for ADTs. Should it be "for all f which are not part of the > implementation of the type"? That's a non-requirement if the report > doesn't specify what the "implementation" is. So what should it say? "for all exported f" "(except functions whose names are prefixed with 'unsafe')" While not perfect, I think that this is a reasonable specification of "observational equality for ADTs". (Whether all Eq instance should behave that way is another question.) Note that if the ADT abstraction would be done via existential types instead of namespace control, we could honestly say "for all f". > If the representation is stored on the disk, for > instance, then it becomes observable, even if it's still hidden in the > sense that you can't do anything useful with it other than read it back. The trick here is to blame any observable differences on the nondeterminism of the IO monad serialize :: MyADT -> IO String It only guarantees to print out a "random" representation. Of course, in reality, serialize just prints the internal representation at hand, but we may not know that. > As an example, consider the following data type: > > data Expr = Var String | Lam String Expr | App Expr Expr > > The most natural notion of equality here is probably equality up to > alpha conversion and that's what I usually would expect (==) to mean. In > fact, I would be quite surprised if (==) meant structural equality. > Should I now consider the Show instance for this type somehow unsafe? I > don't see why this makes sense. Most of the time I probably don't even > want to make this type abstract. Are the constructors also unsafe? Why? Thanks for throwing in an example :) And a good one at that. So, alpha-equivalence is a natural Eq instance, but not an observational equivalence. Are there other such good examples? On the other hand, I'm not sure whether the Prelude functions like nub make sense / are that useful for alpha-equivalence. Furthermore, Expr is not an Ord instance. (Of course, one could argue that Var String is "the wrong way" or "a very unsafe way" to implement stuff with names. For instance, name generation needs a monad. There are alternatives like De Bruijn indices and even representations based on parametric polymorphism. But I think that this doesn't touch the issue of alpha-conversion being a natural Eq instance.) Regards, apfelmus From agl at imperialviolet.org Fri Mar 14 13:18:11 2008 From: agl at imperialviolet.org (Adam Langley) Date: Fri Mar 14 13:15:09 2008 Subject: [Haskell-cafe] Re: all threads are blocked by recvFrom In-Reply-To: <396556a20803141013w6ba1271bjc2ea1bbd9c80b729@mail.gmail.com> References: <396556a20803140757w1ac429e3q6655078e30961a4e@mail.gmail.com> <396556a20803141013w6ba1271bjc2ea1bbd9c80b729@mail.gmail.com> Message-ID: <396556a20803141018l1bbf87d3y4c46b8571eb040fc@mail.gmail.com> On Fri, Mar 14, 2008 at 10:13 AM, Adam Langley wrote: > See [1] for an example which works for me. (If you're on Windows, you probably need to wrap main in withSocketsDo) AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org From jgbailey at gmail.com Fri Mar 14 13:57:51 2008 From: jgbailey at gmail.com (Justin Bailey) Date: Fri Mar 14 13:54:52 2008 Subject: [Haskell-cafe] Space leak - help needed In-Reply-To: <20080313235025.GC6554@localdomain> References: <20080303022318.GE29085@localdomain> <20080303042009.GB4363@zombie.inf.tu-dresden.de> <20080312191240.GA12019@localdomain> <20080313235025.GC6554@localdomain> Message-ID: On Thu, Mar 13, 2008 at 4:50 PM, Krzysztof Ko?ciuszkiewicz wrote: > Retainers are thunks or objects on stack that keep references to > live objects. All retainers of an object are called the object's > retainer set. Now when one makes a profiling run, say with ./jobname > +RTS -p -hr, the graph refernces retainer sets from jobname.prof. My > understanding is that it is the total size of all objects retained by > retainer sets being plotted, correct? Yes, all retainer sets are being profiled. However, you can FILTER the retainer sets profiled to those containing certain cost-centres. This is a key point because it allows you to "divide-and-conquer" when tracking down a retainer leak. That is, if you filter to a certain cost-centre and the retainer graph is flat, you know that cost-centre is not involved. For example, if you have a cost-centre annotation like {-# SCC "leaky" #-} in your code, you can filter the retainer set like this: Leaky.exe +RTS -hr -hCleaky -RTS Review the documentation for other options. > > About decoding the sets from jobname.prof - for example in > > > SET 2 = {} > > SET 16 = {, } > > SET 18 = {, } > > {...} means it's a set, and is the retainer cost centre > (ccN) and hierarchy of parent cost centres up to the "top level" (cc0)? > > My understanding is that SET 18 above refers to objects that are > retained by exactly two specified cost centres, right? > The docs say "An object B retains object A if (i) B is a retainer object and (ii) object A can be reached by recursively following pointers starting from object B, but not meeting any other retainer objects on the way. Each live object is retained by one or more retainer objects, collectively called its retainer set ..." That says to me that SET18 above is the set of all objects which are retained by those two "call stacks", and only those call stacks. The individual <..> items aren't "call stacks" but I think they refer to where the retaining object (B in the paragraph) was itself retained, so they are like call stacks. My intuition is very fuzzy here. > Finally, what is the MAIN.SYSTEM retainer? I think that is "everything else" - any object created in the runtime system that is not directly attributable to something being profiled. Maybe it is objects from libraries that were not compiled with profiling? I imagine objects created by the GHC primitives would fall in this category too. Since someone else found your space leak, does the retainer profiling advice point to it? I'd like to know if it is actually accurate or not! I've only applied it in some very limited situations. Justin From andrewcoppin at btinternet.com Fri Mar 14 14:44:31 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Fri Mar 14 14:41:24 2008 Subject: [Haskell-cafe] File I/O question In-Reply-To: <1D9E7C73-85DC-40EB-990A-4430A3258B5F@phaedrusdeinus.org> References: <47D829C4.6090802@btinternet.com> <20080312204233.GF9203@scytale.galois.com> <47D8451F.10304@btinternet.com> <20080312210459.GI9203@scytale.galois.com> <47D845FF.7090209@btinternet.com> <1D9E7C73-85DC-40EB-990A-4430A3258B5F@phaedrusdeinus.org> Message-ID: <47DAC78F.9050206@btinternet.com> John Melesky wrote: > On Mar 12, 2008, at 4:07 PM, Andrew Coppin wrote: >> I'm trying to read the file from Notepad.exe while my Haskell program >> is still running - which takes about an hour. > > I'm not a Windows user, but... Is it possible that Notepad tries to > write-lock by default (since it's an editor), and fails? Notepad successfully opens the log file of another script I'm running, so that's not the issue. From andrewcoppin at btinternet.com Fri Mar 14 14:50:18 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Fri Mar 14 14:47:10 2008 Subject: [Haskell-cafe] Type system Message-ID: <47DAC8EA.2020107@btinternet.com> Haskell has an expressive and powerful type system - which I love. It also has a seemingly endless list of weird and obscure type system extensions. And there are various things you can do in Haskell which *require* some pretty serious type system hackery. And yet, none of this happens in any other programming language I've met. Take Java for example. In Java, a "type" is just an identifier. It has no further structure than that. It does have the added semantics that it refers to that class *or any subclass*, but that's about it. Even taking an extreme example like Eiffel [which supports generics], complex types are extremely rare. And yet they commonly pop up in Haskell. Can anybody put their finger on precisely why that is? Is it because Haskell is used by more PhDs? Is it because Haskell actually allows you to implement constructs that are impossible in other languages? Is it because Haskell really provides greater type safety? Is it something else? Not trying to suggest that either system is "superior", I'm just curios as to the origin of the difference... From donnie at darthik.com Fri Mar 14 15:35:02 2008 From: donnie at darthik.com (Donnie Jones) Date: Fri Mar 14 15:32:15 2008 Subject: [Haskell-cafe] Ackermann Function Memoization, GHC Weird Output or Bug? In-Reply-To: <89ca3d1f0803132333r6cc1a07cu11fd3c066330b35f@mail.gmail.com> References: <449c8cfc0803132307s64143823qa8f949930315dfd2@mail.gmail.com> <89ca3d1f0803132333r6cc1a07cu11fd3c066330b35f@mail.gmail.com> Message-ID: Hello, It seems this bug has already been submitted: http://hackage.haskell.org/trac/ghc/ticket/2120 Thanks for the help. __ Donnie Jones On 3/14/08, Cale Gibbard wrote: > > Here's the bug: > > {-# INLINE safeIndex #-} > safeIndex :: Ix i => (i, i) -> Int -> i -> Int > safeIndex (l,u) n i = let i' = unsafeIndex (l,u) i > in if (0 <= i') && (i' < n) > then i' > else error "Error in array index" > > unsafeIndex here is just a function which transforms indices into Int > indices into the flat array and does no checking of validity. Then > safeIndex simply checks if the result is nonnegative and less than the > size of the array. Whoops! The actual test to see if the index was > valid in the first place didn't actually get performed! > > > - Cale > > > On 14/03/2008, Eric Mertens wrote: > > Smaller example of this behavior: > > > > > array ((0,0),(1,1)) [((1,1),6)] ! (0,3) > > 6 > > > > -- > > > > Eric Mertens > > > > _______________________________________________ > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080314/b14bab36/attachment.htm From andrewcoppin at btinternet.com Fri Mar 14 15:48:54 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Fri Mar 14 15:45:46 2008 Subject: [Haskell-cafe] Gtk2hs Message-ID: <47DAD6A6.3080002@btinternet.com> Just a short one... gtk2hs won't build on my [Linux] laptop. What's the best channel for seeking help with this? From kolmodin at dtek.chalmers.se Fri Mar 14 16:29:07 2008 From: kolmodin at dtek.chalmers.se (Lennart Kolmodin) Date: Fri Mar 14 16:12:12 2008 Subject: [Haskell-cafe] Gtk2hs In-Reply-To: <47DAD6A6.3080002@btinternet.com> References: <47DAD6A6.3080002@btinternet.com> Message-ID: <47DAE013.1010507@dtek.chalmers.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andrew Coppin wrote: | Just a short one... gtk2hs won't build on my [Linux] laptop. What's the | best channel for seeking help with this? The #haskell (on freenode) isn't bad. You'll probably get help pretty quick here, it's known to be very user friendly. The subset #gentoo-haskell is good too, especially if you're using Gentoo Linux. You'll find both me and one of the gkt2hs maintainers (dcoutts) in both channels. Gtk2Hs also has mailing lists, see http://www.haskell.org/gtk2hs/development/ Note that there is pretty much the same people you're talking to no matter which method you pick :) Or... we can just continue here.. Which version of ghc and gtk2hs? Did you get an error message? Cheers, ~ Lennart Kolmodin -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH2uAT4txYG4KUCuERAjCrAKCC4HMw0b5vuhLxKhm5jyUIIB8ybACdFenO EqXbl/H8xpdjqMDimfbgpes= =5Du+ -----END PGP SIGNATURE----- From dave at zednenem.com Fri Mar 14 16:26:10 2008 From: dave at zednenem.com (David Menendez) Date: Fri Mar 14 16:23:08 2008 Subject: [Haskell-cafe] Type system In-Reply-To: <47DAC8EA.2020107@btinternet.com> References: <47DAC8EA.2020107@btinternet.com> Message-ID: <49a77b7a0803141326n514d2f72l888b32fcdd2c9367@mail.gmail.com> On Fri, Mar 14, 2008 at 2:50 PM, Andrew Coppin wrote: > Haskell has an expressive and powerful type system - which I love. It > also has a seemingly endless list of weird and obscure type system > extensions. And there are various things you can do in Haskell which > *require* some pretty serious type system hackery. Well, there wouldn't be much point to a type system extension if you could do just as well without it. > And yet they commonly pop up in Haskell. Can anybody put their finger on > precisely why that is? It's because Haskell is, among other things, a research language. Part of its stated purpose is providing a basis for experimenting with type systems and implementation strategies and so forth. When Haskell 98 was written, higher-ranked polymorphism wasn't considered practical, and no one had invented multi-parameter type classes yet. Even type classes started out as an experiment, and then they were extended to constructor classes (e.g., classes like Monad where the parameter is a type constructor, not a ground type). Eventually, the most successful extensions will be rolled into the next Haskell standard. The same thing happens in Java. Generics (what we call type constructors) were available in various extended Javas before being added to the main standard. The Haskell process is just a lot slower because we're doing things very few have done before. -- Dave Menendez From g9ks157k at acme.softbase.org Fri Mar 14 16:58:41 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Fri Mar 14 16:56:36 2008 Subject: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?) In-Reply-To: <6a7c66fc0803140946gb57e8c8k7277ba2be9a3e2d2@mail.gmail.com> References: <6a7c66fc0801310302p6bdee4adm6cf6a2778772ecbf@mail.gmail.com> <200803141730.19202.g9ks157k@acme.softbase.org> <6a7c66fc0803140946gb57e8c8k7277ba2be9a3e2d2@mail.gmail.com> Message-ID: <200803142158.41961.g9ks157k@acme.softbase.org> Am Freitag, 14. M?rz 2008 17:46 schrieben Sie: > [?] > I think that removing aliases completely is not a good idea. How about > generating much lower aliases for decimals (lets say until 1000), I don?t think, this is a good idea. Like nobody will need an alias for 8247, nobody will need an alias for 824. The main point is that it is unnecessary to have a continuous range of numbers for which aliases exist. If you need aliases, you need them for ?outstanding? values. Maybe you need aliases for all powers of 2 up to a certain number. Or aliases for all square numbers. Therefore I think that if we want aliases then we should let the user and only the user generate them. This has also the interesting consequence that the type-level package doesn?t need the Template Haskell language extension anymore. After all, using the template-haskell package doesn?t imply that you have to have a TH-enabled compiler, as far as I know. > droping the other bases, That?s a good idea. > and exporting a function to extended the alias range at will? I?d rather propose something like this: $(numAliasDecls [2 ^ n | n <- 0..16]) So that numAliasDecls has a type like [Int] -> [Decl]. > (that function could perfectly include the other bases as well). Maybe. > [?] > I don't have the time to work on it now, but if you send me a patch > I'd be happy to apply it. It should be something simple to do. All the > Template Haskell machinery is already coded. Okay, I could send you a patch realizing my above ideas but would like to hear your opinion first. > [?] Best wishes, Wolfgang From andrewcoppin at btinternet.com Fri Mar 14 17:08:51 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Fri Mar 14 17:05:43 2008 Subject: [Haskell-cafe] Gtk2hs In-Reply-To: <20080314203105.GF10521@scytale.galois.com> References: <47DAD6A6.3080002@btinternet.com> <20080314203105.GF10521@scytale.galois.com> Message-ID: <47DAE963.4050601@btinternet.com> Don Stewart wrote: > andrewcoppin: > >> Just a short one... gtk2hs won't build on my [Linux] laptop. What's the >> best channel for seeking help with this? >> > > Discuss it on the gtk2hs list, with a full error log. > Thanks. I'll go look at that. (Who knows, maybe somebody already solved this one...) From michael at schmong.org Fri Mar 14 17:13:28 2008 From: michael at schmong.org (michael@schmong.org) Date: Fri Mar 14 17:10:25 2008 Subject: [Haskell-cafe] thanks for your feedback concerning tech documentation. Message-ID: <20080314211328.GA24276@schmong.org> Thanks. I was encouraged by this response I got. I'm ready to go. Since I'm trapped in the space-time continuum like most people, I can't do it all at once. I would like to. Anything that supports haskell is okay by me. My first area of interest is HAppS. I wrote some e-mail to them yesterday, but have yet to hear anything. Should I belt out some e-mail to specific people? By the looks of things, the traffic on that list is pretty slow right now. Michael Litchard From dpiponi at gmail.com Fri Mar 14 17:29:41 2008 From: dpiponi at gmail.com (Dan Piponi) Date: Fri Mar 14 17:26:38 2008 Subject: [Haskell-cafe] Type system In-Reply-To: <47DAC8EA.2020107@btinternet.com> References: <47DAC8EA.2020107@btinternet.com> Message-ID: <625b74080803141429l5281864ew6e72841f3e1e60eb@mail.gmail.com> On Fri, Mar 14, 2008 at 11:50 AM, Andrew Coppin wrote: > Haskell has an expressive and powerful type system - which I love. It > also has a seemingly endless list of weird and obscure type system > extensions...And yet, none of this happens in any other programming language I've > met. Have you ever programmed in C++? Many of the exotic things that can be done in the Haskell type system can also be carried out in the C++ type system - ranging from factoring integers at compile time to implementing highly optimised array and matrix DSLs. The difference between C++ and Haskell is that in C++ these techniques are highly ad hoc. In the Haskell world people are a lot more conservative and so only allow type system shenanigans if they are supported by some theory that allows us to reason nicely about them. As a side effect, each type system extension is relatively small and controlled. So when you see lots of Haskell type system extensions it looks like a big complicated system, but that's just an illusion that results from it being broken down into reasonable pieces. Read some of the source code for the Boost C++ template libraries (especially the template metaprogramming library) to see how complex the C++ type system really is. -- Dan From dons at galois.com Fri Mar 14 17:31:32 2008 From: dons at galois.com (Don Stewart) Date: Fri Mar 14 17:28:38 2008 Subject: [Haskell-cafe] Type system In-Reply-To: <625b74080803141429l5281864ew6e72841f3e1e60eb@mail.gmail.com> References: <47DAC8EA.2020107@btinternet.com> <625b74080803141429l5281864ew6e72841f3e1e60eb@mail.gmail.com> Message-ID: <20080314213132.GA11597@scytale.galois.com> dpiponi: > On Fri, Mar 14, 2008 at 11:50 AM, Andrew Coppin > wrote: > > Haskell has an expressive and powerful type system - which I love. It > > also has a seemingly endless list of weird and obscure type system > > extensions...And yet, none of this happens in any other programming language I've > > met. > > Have you ever programmed in C++? Many of the exotic things that can be > done in the Haskell type system can also be carried out in the C++ > type system - ranging from factoring integers at compile time to > implementing highly optimised array and matrix DSLs. The difference > between C++ and Haskell is that in C++ these techniques are highly ad > hoc. In the Haskell world people are a lot more conservative and so > only allow type system shenanigans if they are supported by some > theory that allows us to reason nicely about them. As a side effect, > each type system extension is relatively small and controlled. So when > you see lots of Haskell type system extensions it looks like a big > complicated system, but that's just an illusion that results from it > being broken down into reasonable pieces. Read some of the source code > for the Boost C++ template libraries (especially the template > metaprogramming library) to see how complex the C++ type system really > is. As Manuel says, in C++ type level programming was an accident, in Haskell, it was by design. From wnoise at ofb.net Fri Mar 14 17:39:15 2008 From: wnoise at ofb.net (Aaron Denney) Date: Fri Mar 14 17:36:20 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <47D5416C.808@iee.org> <871w6i8wx4.fsf@nmd9999.imr.no> <47D55287.5040701@iee.org> <404396ef0803100829h44c8ac1dg4ee6f0132cb4f929@mail.gmail.com> <47D56B7A.2030200@iee.org> <220e47b40803101207w6d4bb795k68d959b3ccff9849@mail.gmail.com> <47D5A46A.5010800@iee.org> <404396ef0803101433s435bbc64j46617fe50ba46aa5@mail.gmail.com> <47D63C44.7070704@iee.org> <6dbd4d000803110846k3fcb94a8k9ad780c2dd8272fc@mail.gmail.com> <47D6B140.4010002@iee.org> <47D7E0F5.6090907@jellybean.co.uk> <20080312194804.o14f2bxhcwgo00sw@webmail.spamcop.net> <47D8D11F.3010002@iee.org> <20080313182842.23pl2dtt4owoo4sg@webmail.spamcop.net> <00E7D026-8FAF-4BEE-9049-456374CE70C3@strictlypositive.org> <62B9D97C-0A24-4F67-BE32-9CCFCE33B8F3@strictlypositive.org> Message-ID: On 2008-03-14, Conor McBride wrote: > Hi > > On 13 Mar 2008, at 23:33, Aaron Denney wrote: > >> On 2008-03-13, Conor McBride wrote: >>> For a suitable notion of = on quotients, and with a >>> suitable abstraction barrier at least morally in place, >>> is that really too much to ask? >> >> I really think it is. I don't think the case of "equivalent for this >> purpose, but not that purpose" can be ignored. > > Sure. But use the right tools for the job. So what are the right tools then? Why is a typeclass not the right tool? >> Now, it may be the case that fooBy functions are then the right >> thing, but it's not clear to me at all that this is true. >> >> And if the fooBy option works, then why would the foo option fail for >> equivalence classes? > > It seems reasonable to construct quotients from > arbitrary equivalences: if fooBy works for the > carrier, foo should work for the quotient. Of > course, if you want to expose the representation > for some other legitimate purpose, then it wasn't > equality you were interested in, so you should > call it something else. I'm perfectly happy calling it Equivalence. >> -- what should a sort algorithm do in such a >> situation? > > Not care. Produce a resulting list where for any > > [..., x, ..., y, ...] > > in the result, y <= x implies x <= y. Vacuously > satisfied in the case of incomparable elements. > In the case of a total order, that gives you > y <= x implies x = y (and everything in between), > but for a preorder, you put less in, you get less > out. That's a workable definition, but I don't know if I'd call it a sort, precisely. The standard unix tool "tsort" (for "topological sort", a bit of a misnomer) does this. > Will that do? Unfortunately, one can't just reuse the standard algorithms. One might think that one could reuse any standard algorithm by munging the comparison so that incomparable gets mapped to equivalent, but the following two chains shows that's not possible: a -> b -> c -> d a -> e -> d Instead, it seems that one has to use actual graph algorithms, which are both more complicated to reason about, and have worse performance. If a sort can't support the standard "sort on this key" technique, and don't munge everything for two keys that compare equal, something is wrong. And I don't think sort is that special a case. Instances, rather than explicit functions, are nice because they let us use the type system to ensure that we never have incompatible functions used when combining two data structures, or pass in a function that's incompatible with the invariants already in a data structure built with another function. So we surely do need an equivalence relation typeclass. And there are Eq instances that aren't quite equality, but are equivalences, and work with almost all code that takes Eq instances. The only time treating equalities as equivalences won't work is when we need to coalesce equivalent elements into one representative, and the choice of representative matters. (If it doesn't matter, we can just pick arbitrarily). If it does matter, a simple biasing scheme usually isn't going to be sufficient -- we really do need a coalescing function. So, do we mark equivalencies as special, or observational equality as special? Which is the tagging class, and which has the methods? I think it's pretty clear that the way to go is have (==) and (/=) live in Equiv, and have Equal be a tagging class. An equivalence is not a special type of equality, but equality is a special type of equivalence. Given all that, I think current Eq as Equivalence makes sense, and we need to add an Equal class for things where we truly can't tell equivalent elements apart. -- Aaron Denney -><- From ben.franksen at online.de Fri Mar 14 17:37:57 2008 From: ben.franksen at online.de (Ben Franksen) Date: Fri Mar 14 17:39:18 2008 Subject: [Haskell-cafe] Re: Type system References: <47DAC8EA.2020107@btinternet.com> Message-ID: Andrew Coppin wrote: > Haskell has an expressive and powerful type system - which I love. It > also has a seemingly endless list of weird and obscure type system > extensions. And there are various things you can do in Haskell which > *require* some pretty serious type system hackery. > > And yet, none of this happens in any other programming language I've > met. Take Java for example. In Java, a "type" is just an identifier. It > has no further structure than that. It does have the added semantics > that it refers to that class *or any subclass*, but that's about it. > Even taking an extreme example like Eiffel [which supports generics], > complex types are extremely rare. > > And yet they commonly pop up in Haskell. Can anybody put their finger on > precisely why that is? I think this is at least partly because Haskell takes being a (typed) functional language very serious. With OO languages, such as Java or Eiffel, you can swipe a lot of the complexity under the stateful object carpet. Functional programs explicitly operate on values, however complex their types may be... and thus themselves become values with even more complex types... I found this paper http://www.eecs.usma.edu/webs/people/okasaki/pubs.html#jfp98 quite illuminating (it uses SML, not Haskell, which rather confirms my point). Cheers Ben From g9ks157k at acme.softbase.org Fri Mar 14 17:41:32 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Fri Mar 14 17:39:29 2008 Subject: [Haskell-cafe] Type system In-Reply-To: <47DAC8EA.2020107@btinternet.com> References: <47DAC8EA.2020107@btinternet.com> Message-ID: <200803142241.32436.g9ks157k@acme.softbase.org> Am Freitag, 14. M?rz 2008 19:50 schrieb Andrew Coppin: > [?] > Is it because Haskell is used by more PhDs? Is it because Haskell > actually allows you to implement constructs that are impossible in other > languages? Is it because Haskell really provides greater type safety? Is > it something else? Haskell?s type system gives you greater type safety, i.e., it allows to statically check certain properties which cannot be statically checked in other languages. It also improves code reuse in certain cases. For example, the Control.Monad module works for all monads (lists, I/O actions, etc.) which is only possible because of constructor classes, at least, if you don?t want to introduce dynamic typing. > [?] Best wishes, Wolfgang From wnoise at ofb.net Fri Mar 14 17:41:14 2008 From: wnoise at ofb.net (Aaron Denney) Date: Fri Mar 14 17:42:02 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <00E7D026-8FAF-4BEE-9049-456374CE70C3@strictlypositive.org> <200803132301.47720.robdockins@fastmail.fm> Message-ID: On 2008-03-14, Robert Dockins wrote: > Blah, blah, blah, its all in the documentation. The point is that making > loose assumptions about the meaning of the operations provided by Eq and Ord > complicates things in ways that can't be made to go away. Thanks. All of these seem to me to be a case of "Well, it's arbitrary, so we don't guarantee anything but that we did something consistent." Which seems perfectly reasonable, and not a problem at all. -- Aaron Denney -><- From ben.franksen at online.de Fri Mar 14 17:41:22 2008 From: ben.franksen at online.de (Ben Franksen) Date: Fri Mar 14 17:47:02 2008 Subject: [Haskell-cafe] Re: Type system References: <47DAC8EA.2020107@btinternet.com> <625b74080803141429l5281864ew6e72841f3e1e60eb@mail.gmail.com> <20080314213132.GA11597@scytale.galois.com> Message-ID: Don Stewart wrote: > As Manuel says, in C++ type level programming was an accident, in > Haskell, it was by design. Was it, really? I was laways under teh impression that Oleg-style type system tricks were not in the least anticipated back when Haskell acquired type classes... Cheers Ben From wnoise at ofb.net Fri Mar 14 17:59:15 2008 From: wnoise at ofb.net (Aaron Denney) Date: Fri Mar 14 17:56:21 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <220e47b40803091848u5925dbe9l261a7ca076f9069e@mail.gmail.com> <200803092304.02063.dan.doel@gmail.com> <404396ef0803100127p4e99997amf2e2a6d70dce6e8b@mail.gmail.com> <47D514C2.8050102@iee.org> <47D58494.7080003@imageworks.com> Message-ID: On 2008-03-10, Dan Weston wrote: > However, the report text is normative: > > 6.3.2 (The Ord Class): > > "The Ord class is used for totally ordered datatypes." > > This *requires* that it be absolutely impossible in valid code to > distinguish equivalent (in the EQ sense, not the == sense) things via > the functions of Ord. The intended interpretation of these functions is > clear and can be taken as normative: > > forall f . (compare x y == EQ and (f x or f y is defined)) > ==> f x == f y) That depends a great deal on your definitions. Is the (=) in the set theory structure equality, or is it merely a binary relation with the appropriate properties? If we take the result of the compare function being EQ to mean structural equality, that throws out the possibility of even "safe" semantic equality, and no interesting data structures can be made instances of Ord. That's less than useful. Certainly, for the domain of /just the ordering comparisons/, yes, equal elements are equal, and cannot be distinguished, but that just means cannot be distinguished by the provided binary relations. -- Aaron Denney -><- From lennart at augustsson.net Fri Mar 14 18:49:32 2008 From: lennart at augustsson.net (Lennart Augustsson) Date: Fri Mar 14 18:46:30 2008 Subject: [Haskell-cafe] Re: Type system In-Reply-To: References: <47DAC8EA.2020107@btinternet.com> <625b74080803141429l5281864ew6e72841f3e1e60eb@mail.gmail.com> <20080314213132.GA11597@scytale.galois.com> Message-ID: No, Haskell wasn't designed with type level programming in mind. In fact it took a few years before any serious type level programming was done. And lo and behold, the type level has an untyped logic language. -- Lennart On Fri, Mar 14, 2008 at 9:41 PM, Ben Franksen wrote: > Don Stewart wrote: > > As Manuel says, in C++ type level programming was an accident, in > > Haskell, it was by design. > > Was it, really? I was laways under teh impression that Oleg-style type > system tricks were not in the least anticipated back when Haskell acquired > type classes... > > Cheers > Ben > > _______________________________________________ > 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/20080314/d5760783/attachment-0001.htm From rendel at rbg.informatik.tu-darmstadt.de Fri Mar 14 18:52:54 2008 From: rendel at rbg.informatik.tu-darmstadt.de (Tillmann Rendel) Date: Fri Mar 14 18:48:53 2008 Subject: [Haskell-cafe] Type system In-Reply-To: <47DAC8EA.2020107@btinternet.com> References: <47DAC8EA.2020107@btinternet.com> Message-ID: <47DB01C6.4050503@rbg.informatik.tu-darmstadt.de> Hi Andrew, Andrew Coppin wrote: > Haskell has an expressive and powerful type system - which I love. It > also has a seemingly endless list of weird and obscure type system > extensions. And there are various things you can do in Haskell which > *require* some pretty serious type system hackery. > > And yet, none of this happens in any other programming language I've > met. Take Java for example. In Java, a "type" is just an identifier. It > has no further structure than that. It does have the added semantics > that it refers to that class *or any subclass*, but that's about it. > Even taking an extreme example like Eiffel [which supports generics], > complex types are extremely rare. There are a lot of Java extensions in various directions (Multimethods, Mixins, Virtual Classes, Aspects, Effect Typing). Some extensions have been included into the "official" Java Language (Anonymous Classes, Generics). Other extensions have lead to the creation of new languages different from, but related to Java (Scala). A lot of research teams, both academic and industrial, are working on new extensions of the Java Language. Such extensions may come as libraries, preprocessors or compilers, they may reuse, extend or substitute the run time system. From my limited view, the Java research community seems to be bigger then the Haskell research community. But I may be wrong here, and the meaning of a "big community" isn't clear at all, so that's not the point. Clearly, Haskell feels like a research language, and Haskell hacking is like pushing the border into unexplored territory, while Java feels like a lot of boilerplate without actual content, and Java development is like taking care of paperwork. Why is this the case? I see four reasons all working together: First, Java is designed for the software industry, while Haskell "avoids success at all cost". This means that we have 90% research people working with Haskell, and 0.01% research people working with Java, *even if there are more Java researchers as Haskell researchers*. It's the absence of non-researchers which makes Haskell a research language, not the abundance of researchers. Second, Java extensions tend to be incompatible with each other, since they typically consist of an modified compiler, while Haskell extensions tend to get integrated into GHC or lost forever. With GHC as de-facto standard compiler, we have a number of extensions available for every productive Haskell system. Third, the theoretical base of pure functional languages is relatively clear and easy to understand, while the theoretical base of imperative object-oriented languages is still widely unexplored and hard to grasp. This means that formal, scientific papers about Haskell are more likely to be user-understandable then formal, scientific papers about Java. Ever seen one of the formal calculi proposed as semantic core of the Java language? Fourth, Haskell is just better. (Had to include this one to avoid being victim to a flame war). But hey, it is my personal opinion too. Tillmann From dons at galois.com Fri Mar 14 19:09:26 2008 From: dons at galois.com (Don Stewart) Date: Fri Mar 14 19:06:37 2008 Subject: [Haskell-cafe] Re: Type system In-Reply-To: References: <47DAC8EA.2020107@btinternet.com> <625b74080803141429l5281864ew6e72841f3e1e60eb@mail.gmail.com> <20080314213132.GA11597@scytale.galois.com> Message-ID: <20080314230926.GC11597@scytale.galois.com> Yeah, I should clarify, this quote came up in relation to ATs, which are designed speifically to make type programming easier (unlike MPTCs and FDs, where it was an Olegian accident) lennart: > No, Haskell wasn't designed with type level programming in mind. > In fact it took a few years before any serious type level > programming was done. And lo and behold, the type level has an > untyped logic language. > > -- Lennart > > On Fri, Mar 14, 2008 at 9:41 PM, Ben Franksen <[1]ben.franksen@online.de> > wrote: > > Don Stewart wrote: > > As Manuel says, in C++ type level programming was an accident, in > > Haskell, it was by design. > > Was it, really? I was laways under teh impression that Oleg-style type > system tricks were not in the least anticipated back when Haskell > acquired > type classes... > > Cheers > Ben > _______________________________________________ > Haskell-Cafe mailing list > [2]Haskell-Cafe@haskell.org > [3]http://www.haskell.org/mailman/listinfo/haskell-cafe > > References > > Visible links > 1. mailto:ben.franksen@online.de > 2. mailto:Haskell-Cafe@haskell.org > 3. 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 john at repetae.net Fri Mar 14 20:01:23 2008 From: john at repetae.net (John Meacham) Date: Fri Mar 14 19:58:22 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: <47D7F429.80305@iee.org> References: <404396ef0803100829h44c8ac1dg4ee6f0132cb4f929@mail.gmail.com> <47D56B7A.2030200@iee.org> <220e47b40803101207w6d4bb795k68d959b3ccff9849@mail.gmail.com> <47D5A46A.5010800@iee.org> <404396ef0803101433s435bbc64j46617fe50ba46aa5@mail.gmail.com> <47D63C44.7070704@iee.org> <6dbd4d000803110846k3fcb94a8k9ad780c2dd8272fc@mail.gmail.com> <47D6B140.4010002@iee.org> <87d4q0xou6.fsf@nmd9999.imr.no> <47D7F429.80305@iee.org> Message-ID: <20080315000123.GC30301@sliver.repetae.net> Note that even if you wanted Eq to mean observational equality, you still can't perform that kind of reordering or 'sort' optimizations without running into trouble. for a not contrived at all example: data Id = Id { idIdent :: Int, idFreeVarCache :: [Id] } instance Eq Id where x == y = idIdent x == idIdent y now, this type represents an identifier in a language that is annotated with the free variables it contains. Note that the Eq instance really does declare observational equality here, the free var cache is only a copy of what is in the definition of the Id. now consider the id for the simple v1 = v1 all of the following are observationally the same x = Id 1 [x] x = Id 1 [Id 1 [x]] x = Id 1 [Id 1 [Id 1 [Id 1 ... now, this is just fine, there is no way for a program to tell the difference between them, but the difference is very important! the second wastes space and the third is an honest to goodness space leak. One has to rely on the fact Set.insert really replaces its element, max x y where x == y is always y and other such things to reasonably reason about the space usage of haskell programs, something that is hard enough as it is without basics like 'sort' trying to be clever. So, even if a == b always meant observational equality, specifying bias is still very important. Even if you document it as 'unspecified' that is fine (though it limits the use of said library), but it is part of the API. For the record I also always thought of 'Eq' as an arbitrary equality relationship and 'Ord' as a compatible total ordering. It is not even clear whether structural equality is meaningful for a lot of types, even though they might have a 'natural' equality relationship. John -- John Meacham - ?repetae.net?john? From conal at conal.net Fri Mar 14 22:47:01 2008 From: conal at conal.net (Conal Elliott) Date: Fri Mar 14 22:43:59 2008 Subject: [Haskell-cafe] deconstruction of the list/backtracking applicative functor? Message-ID: Is there a known deconstruction of the list/backtracking applicative functor (AF)? If I decompose the list type into pieces (Maybe, product, composition), I think I can see where the ZipList AF comes from, but not the list/backtracking AF. Is there some construction simpler than lists (non-recursive) that introduces cross products? Thanks, - Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080314/8c620036/attachment.htm From mad.one at gmail.com Fri Mar 14 23:10:33 2008 From: mad.one at gmail.com (Austin Seipp) Date: Fri Mar 14 23:07:57 2008 Subject: [Haskell-cafe] HFuse: ls fails in HelloFS In-Reply-To: References: Message-ID: <1205550042-sup-1361@continuum> Excerpts from Georg Neis's message of Fri Mar 14 06:38:02 -0500 2008: > Hello, > > I've installed the HFuse package from hackage and am playing with the > HelloFS example in the System/Posix/HFuse directory. As far as I know, the package uploaded onto hackage is merely a cabal-ised version of the old(er) HFuse which I don't believe has been maintained in quite a while. The only recent work I know of on the project is that of Will Thompsons'. A darcs repository can be located here: http://www.willthompson.co.uk/darcs/hfuse/ I've tested it on 6.8 and it works fine (Will has 6.6 I believe,) and the HelloFS example should work, but it is still under development (notably I believe him mentioning that the BindFS example has a deadlock issue at the moment.) Testing out that version might yield better results. I would recommend contacting him on the matter, since he seems to be the only person in this project currently. Sorry I couldn't have been more help. -- "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 ajb at spamcop.net Sat Mar 15 02:45:04 2008 From: ajb at spamcop.net (ajb@spamcop.net) Date: Sat Mar 15 02:42:01 2008 Subject: [Haskell-cafe] Type system In-Reply-To: <47DAC8EA.2020107@btinternet.com> References: <47DAC8EA.2020107@btinternet.com> Message-ID: <20080315024504.x20carcbsoos88s8@webmail.spamcop.net> G'day all. Quoting Andrew Coppin : > And yet they commonly pop up in Haskell. Can anybody put their finger > on precisely why that is? One of the reasons why advanced type hackery shows up a lot in Haskell is that Haskell has never taken the easy way out. When confronted with an issue that doesn't seem to fit with purity, Haskell's answer has always been to apply more research, raid more category theory or generally think hard about the problem and come up with a clean solution, rather than sell out to impurity. And almost always, the theoretically clean solution has opened up new uses for types that were not previously considered. Cheers, Andrew Bromage From gour at mail.inet.hr Fri Mar 14 16:06:30 2008 From: gour at mail.inet.hr (Gour) Date: Sat Mar 15 02:57:00 2008 Subject: [Haskell-cafe] Re: Gtk2hs References: <47DAD6A6.3080002@btinternet.com> Message-ID: <87tzj96pfd.fsf@gaura-nitai.no-ip.org> >>>>> "Andrew" == Andrew Coppin writes: Andrew> Just a short one... gtk2hs won't build on my [Linux] Andrew> laptop. What's the best channel for seeking help with this? https://lists.sourceforge.net/lists/listinfo/gtk2hs-users Sincerely, Gour -- Gour | Zagreb, Croatia | GPG key: C6E7162D ---------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080314/ae184616/attachment.bin From lgreg.meredith at biosimilarity.com Sat Mar 15 03:20:14 2008 From: lgreg.meredith at biosimilarity.com (Greg Meredith) Date: Sat Mar 15 03:17:11 2008 Subject: [Haskell-cafe] 2-level type analysis of introducing naming into data types Message-ID: <5de3f5ca0803150020s65d3a63pdebf66a77f24ef9@mail.gmail.com> All, The following Haskell code gives a 2-level type analysis of a functorial approach to introducing naming and name management into a given (recursive) data type. The analysis is performed by means of an example (the type of Conway games). The type is naturally motivated because through the application of one functor we arrive at a lambda calculus with an embedded type for Conway games (giving access to field operations for arithmetic on virtually every type of number ever considered) -- while another functor provides a process calculi with a similarly embedded data type. Moreover, the technique extends to a wide variety of algebra(ic data type)s. The recipe is simple. 1. Provide a recursive specification of the algebra. Example. data Game = Game [Game] [Game] 2. Abstract the specification using parametric polymorphism. Example. data PolyGame g = PolyGame [g] [g] 2.a. Identify the 2-Level knot-tying version of the recursive type Example. data RGame = RGame (PolyGame RGame) 3. Insert name management type into the knot-tying step of the 2-Level version Example. data DefRefGame var = DefRefGame (PolyDefRef var (PolyGame (DefRefGame var))) given the basic form data PolyDefRef var val = Def var (PolyDefRef var val) (PolyDefRef var val) | Ref var | Val val is the name management technology We illustrate the idea with two other forms of name management technology: the lambda calculus and the pi-calculus. Then we show that names themselves can be provided as the codes of the terms of the new type. At the root of this work is the proposal that communication begins from the concrete -- a "closed" recursive type -- representing some observation or proposal of how something works in the universe (of discourse). As said proposal develops or is explored, calculations need to rely more and more on naming (i.e. "let x stand for ... in ..."). Thus, this capability is "injected" into the data type -- moving from the concrete to the general. The analysis above provides a concrete, disciplined procedure for achieving this in both a sequential and concurrent computational setting. Best wishes, --greg -- This code summarizes the previous post. It shows that for any -- "closed" recursive type we can devise a closed extension of this -- type embedding the type as a value in the lambda calculus module Grho( Game, PolyGame, PolyDefRef, DefRefGame, QDefRefGame ,Term, GTerm, QGTerm ,Sum, Agent, Process, GProcess, QGProcess ) where -- Conway's original data type data Game = Game [Game] [Game] deriving (Eq,Show) -- Abstracting Conway's data type data PolyGame g = PolyGame [g] [g] deriving (Eq,Show) -- Recovering Conway's data type in terms of the abstraction newtype RGame = RGame (PolyGame RGame) deriving (Eq,Show) -- RGame ~ Game -- Expressions with references and values data PolyDefRef var val = Def var (PolyDefRef var val) (PolyDefRef var val) | Ref var | Val val deriving (Eq,Show) -- Games with references and values data DefRefGame var = DefRefGame (PolyDefRef var (PolyGame (DefRefGame var))) deriving (Eq,Show) -- Games with references and values in which variables are quoted games newtype QDefRefGame = QDefRefGame (DefRefGame QDefRefGame) deriving (Eq,Show) -- Lambda terms with values data Term var val = Var var | Abs [var] (Term var val) | App (Term var val) [Term var val] | Value val deriving (Eq,Show) -- Lambda terms with games as values data GTerm var = Term var (PolyGame (GTerm var)) deriving (Eq,Show) -- Lambda terms with games as values and variables that are quoted lambda terms data QGTerm = GTerm QGTerm -- And the following defn's/eqns take it one step further by providing a notion of process with -- Conway games as embedded values -- Process terms with values -- Sums data Sum var val agent = PValue val | Locate var agent | Sum [Sum var val agent] deriving (Eq,Show) -- One of the recent observations i've had about the process calculi -- is that '0' is Ground, and as such is another place to introduce -- new Ground. Thus, we can remove the production for '0' and replace -- it with the types of values we would like processes to 'produce'; -- hence the PValue arm of the type, Sum, above. Note that this -- design choice means that we can have expressions of the form -- v1 + v2 + ... + vk + x1A1 + ... xnAn -- i am inclined to treat this as structurally equivalent to -- x1A1 + ... xnAn -- but there is another alternative: to allow -- sums of values to represent superpositions -- Agents data Agent var proc = Input [var] proc | Output [proc] deriving (Eq,Show) -- Processes data Process var sum = Case sum | Deref var | Compose [Process var sum] deriving (Eq,Show) -- Processes over games data GProcess var = Process var (Sum var (PolyGame (GProcess var)) (Agent var (GProcess var))) deriving (Eq,Show) -- Processes over games with quoted process for variables newtype QGProcess = QGProcess (GProcess QGProcess) deriving (Eq,Show) -- 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/20080315/d27d2403/attachment.htm From valgarv at gmx.net Sat Mar 15 05:17:06 2008 From: valgarv at gmx.net (askyle) Date: Sat Mar 15 05:14:02 2008 Subject: [Haskell-cafe] A question about "monad laws" In-Reply-To: <20080314022821.kn171tmtcwwsc44s@webmail.spamcop.net> References: <404396ef0802110538q15db024cj2291edc87b873249@mail.gmail.com> <404396ef0802110559gea267b8q61646b85295ecfa9@mail.gmail.com> <20080211213454.GA3783@localhost.localdomain> <15975734.post@talk.nabble.com> <20080312205352.zruv2qkjk04s88cg@webmail.spamcop.net> <16045123.post@talk.nabble.com> <20080314022821.kn171tmtcwwsc44s@webmail.spamcop.net> Message-ID: <16065960.post@talk.nabble.com> ajb-2 wrote: > > If you wanted to prove that bind is natural, you would need to define > bind, no? > Yup: bind f = f <=< id -- whence you can say (>>=) = flip bind My point is that (as far as I can see) you cannot prove the properties of bind by only assuming identity and associativity for (<=<). You need some way to relate (<=<) to normal composition. To be more explicit: Given: 1. m :: * -> * 2. return :: a -> m a 3. (<=<) :: (b -> m c) -> (a -> m b) -> (a -> m c) such that: 1. return <=< f === f <=< return === f 2. (f <=< g) <=< h === f <=< (g <=< h) Define: bind f = f <=< id (>>=) = flip bind fmap f = bind (return . f) join = bind id Show the monad laws hold, either for (return,bind), (return,(>>=)) or (fmap,return,join) (in the latter case, there's also showing that fmap is a functor and return and join are natural transformations). If someone can show it can be done without also assuming: 3. (f <=< g) . h === f <=< (g . h) I'll stand corrected. ----- Ariel J. Birnbaum -- View this message in context: http://www.nabble.com/A-question-about-%22monad-laws%22-tp15411587p16065960.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. From andrewcoppin at btinternet.com Sat Mar 15 05:20:10 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Sat Mar 15 05:16:59 2008 Subject: [Haskell-cafe] Re: Gtk2hs In-Reply-To: <87tzj96pfd.fsf@gaura-nitai.no-ip.org> References: <47DAD6A6.3080002@btinternet.com> <87tzj96pfd.fsf@gaura-nitai.no-ip.org> Message-ID: <47DB94CA.4070604@btinternet.com> Gour wrote: > https://lists.sourceforge.net/lists/listinfo/gtk2hs-users > Yeah... took me a little while it was on sourceforge not Haskell.org's mailman. (Especially since there are at least 2 defunct groups there that look like they might be the right one...) From ajb at spamcop.net Sat Mar 15 05:43:13 2008 From: ajb at spamcop.net (ajb@spamcop.net) Date: Sat Mar 15 05:40:09 2008 Subject: [Haskell-cafe] A question about "monad laws" In-Reply-To: <16065960.post@talk.nabble.com> References: <404396ef0802110538q15db024cj2291edc87b873249@mail.gmail.com> <404396ef0802110559gea267b8q61646b85295ecfa9@mail.gmail.com> <20080211213454.GA3783@localhost.localdomain> <15975734.post@talk.nabble.com> <20080312205352.zruv2qkjk04s88cg@webmail.spamcop.net> <16045123.post@talk.nabble.com> <20080314022821.kn171tmtcwwsc44s@webmail.spamcop.net> <16065960.post@talk.nabble.com> Message-ID: <20080315054313.32h0shbjcokww0o4@webmail.spamcop.net> G'day all. Quoting askyle : > Yup: bind f = f <=< id -- whence you can say (>>=) = flip bind Ah, yes. > My point is that (as far as I can see) you cannot prove the properties of > bind by only assuming identity and associativity for (<=<). One thing that may help is that if you can prove that fmap is sane: fmap (f . g) = fmap f . fmap g then the naturality of return is precisely its free theorem, and ditto for bind. So perhaps this law: (f <=< g) . h === f <=< (g . h) is actually the fmap law in disguise? Cheers, Andrew Bromage From will at willthompson.co.uk Sat Mar 15 07:44:59 2008 From: will at willthompson.co.uk (Will Thompson) Date: Sat Mar 15 07:38:29 2008 Subject: [Haskell-cafe] HFuse: ls fails in HelloFS In-Reply-To: <1205550042-sup-1361@continuum> References: <1205550042-sup-1361@continuum> Message-ID: <47DBB6BB.5070403@willthompson.co.uk> On 15/03/08 03:10, Austin Seipp wrote: > I've tested it on 6.8 and it works fine (Will has 6.6 I believe,) and > the HelloFS example should work, but it is still under development > (notably I believe him mentioning that the BindFS example > has a deadlock issue at the moment.) Testing out that version might > yield better results. (I recently fixed a couple of deadlocks, but not in that branch yet.) > I would recommend contacting him on the matter, since he seems to be > the only person in this project currently. Sorry I couldn't have been > more help. Taru Karttunen has been doing some work on it recently, too. I'm hoping to merge my work with his at darcs.haskell.org/hfuse in the next few days. -- Will -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080315/3664333e/signature.bin From alfonso.acosta at gmail.com Sat Mar 15 07:56:53 2008 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Sat Mar 15 07:53:48 2008 Subject: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?) In-Reply-To: <200803142158.41961.g9ks157k@acme.softbase.org> References: <6a7c66fc0801310302p6bdee4adm6cf6a2778772ecbf@mail.gmail.com> <200803141730.19202.g9ks157k@acme.softbase.org> <6a7c66fc0803140946gb57e8c8k7277ba2be9a3e2d2@mail.gmail.com> <200803142158.41961.g9ks157k@acme.softbase.org> Message-ID: <6a7c66fc0803150456w2732e4adxf248ca6529a146@mail.gmail.com> On Fri, Mar 14, 2008 at 9:58 PM, Wolfgang Jeltsch wrote: > Am Freitag, 14. M?rz 2008 17:46 schrieben Sie: > > I think that removing aliases completely is not a good idea. How about > > generating much lower aliases for decimals (lets say until 1000), > > I don't think, this is a good idea. Like nobody will need an alias for 8247, > nobody will need an alias for 824. The main point is that it is unnecessary > to have a continuous range of numbers for which aliases exist. If you need > aliases, you need them for "outstanding" values. Maybe you need aliases for > all powers of 2 up to a certain number. Or aliases for all square numbers. > > Therefore I think that if we want aliases then we should let the user and only > the user generate them. This has also the interesting consequence that the > type-level package doesn't need the Template Haskell language extension > anymore. After all, using the template-haskell package doesn't imply that > you have to have a TH-enabled compiler, as far as I know. I don't agree. Not using aliases is a big pain, which means that every user wanting to use vectors with sizes biger than 10 (i.e. all) will have to generate their own alias set. It would be really annoying having to generate the aliases every time the library is used. Let's agree on a minimum alias set likely to be used by most of the users, small enough to get a reasonable object code size and compile time (we can even prevent haddock from parsing the alias module and just write a comment indicating what aliases are and which ones are generated if that helps). Generating type redefinitions up to decimal 500 shouldn't be such a big overhead (at least compared to the quntity of aliases generated right now). > > > droping the other bases, > > That's a good idea. > > > and exporting a function to extended the alias range at will? > > I'd rather propose something like this: > > $(numAliasDecls [2 ^ n | n <- 0..16]) > > So that numAliasDecls has a type like [Int] -> [Decl]. That doesn't include bases, which might be important for the end user (for example Oleg wrote his type-evel numerical library in base 2 because it was aimed at system development). I'd rather propose a modification of Data.TypeLevel.Num.Aliases.genAliases which probably should be aware of the aliases already generated in the library so that they are not duplicated. From valgarv at gmx.net Sat Mar 15 12:01:58 2008 From: valgarv at gmx.net (askyle) Date: Sat Mar 15 11:58:53 2008 Subject: [Haskell-cafe] A question about "monad laws" In-Reply-To: <20080315054313.32h0shbjcokww0o4@webmail.spamcop.net> References: <404396ef0802110538q15db024cj2291edc87b873249@mail.gmail.com> <404396ef0802110559gea267b8q61646b85295ecfa9@mail.gmail.com> <20080211213454.GA3783@localhost.localdomain> <15975734.post@talk.nabble.com> <20080312205352.zruv2qkjk04s88cg@webmail.spamcop.net> <16045123.post@talk.nabble.com> <20080314022821.kn171tmtcwwsc44s@webmail.spamcop.net> <16065960.post@talk.nabble.com> <20080315054313.32h0shbjcokww0o4@webmail.spamcop.net> Message-ID: <16069396.post@talk.nabble.com> ajb-2 wrote: > > One thing that may help is that if you can prove that fmap is sane: > fmap (f . g) = fmap f . fmap g > I get stuck after expanding the rhs into: ((return . f) <=< id) . ((return . g) <=< id) ajb-2 wrote: > > then the naturality of return is precisely its free theorem, and ditto > for bind. > Care to develop? IIRC the free theorems have a certain parametericity requirement (which probably holds in all interesting cases, but still sounds like an additional assumption). I'm not too familiar with these, so a link would be appreciated =) ajb-2 wrote: > > So perhaps this law: > (f <=< g) . h === f <=< (g . h) > is actually the fmap law in disguise? > Could be. Maybe the fmap law is this one in disguise ;) ----- Ariel J. Birnbaum -- View this message in context: http://www.nabble.com/A-question-about-%22monad-laws%22-tp15411587p16069396.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. From conor at strictlypositive.org Sat Mar 15 13:07:09 2008 From: conor at strictlypositive.org (Conor McBride) Date: Sat Mar 15 13:04:00 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort In-Reply-To: References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <47D5416C.808@iee.org> <871w6i8wx4.fsf@nmd9999.imr.no> <47D55287.5040701@iee.org> <404396ef0803100829h44c8ac1dg4ee6f0132cb4f929@mail.gmail.com> <47D56B7A.2030200@iee.org> <220e47b40803101207w6d4bb795k68d959b3ccff9849@mail.gmail.com> <47D5A46A.5010800@iee.org> <404396ef0803101433s435bbc64j46617fe50ba46aa5@mail.gmail.com> <47D63C44.7070704@iee.org> <6dbd4d000803110846k3fcb94a8k9ad780c2dd8272fc@mail.gmail.com> <47D6B140.4010002@iee.org> <47D7E0F5.6090907@jellybean.co.uk> <20080312194804.o14f2bxhcwgo00sw@webmail.spamcop.net> <47D8D11F.3010002@iee.org> <20080313182842.23pl2dtt4owoo4sg@webmail.spamcop.net> <00E7D026-8FAF-4BEE-9049-456374CE70C3@strictlypositive.org> <62B9D97C-0A24-4F67-BE32-9CCFCE33B8F3@strictlypositive.org> Message-ID: <6331F8DE-7F8C-45A4-82EE-99D967864F39@strictlypositive.org> Hi On 14 Mar 2008, at 21:39, Aaron Denney wrote: > On 2008-03-14, Conor McBride wrote: >> Hi >> >> On 13 Mar 2008, at 23:33, Aaron Denney wrote: >> >>> On 2008-03-13, Conor McBride wrote: >>>> For a suitable notion of = on quotients, and with a >>>> suitable abstraction barrier at least morally in place, >>>> is that really too much to ask? >>> >>> I really think it is. I don't think the case of "equivalent for >>> this >>> purpose, but not that purpose" can be ignored. >> >> Sure. But use the right tools for the job. > > So what are the right tools then? Why is a typeclass not the right > tool? I guess I mean to distinguish *equality*, which is necessarily respected by all observations (for some notion of observation which it's important to pin down), from coarser equivalences where respect takes careful effort. Take Roman's example of alpha-equivalence for the lambda-terms with strings for bound variables. No way would I ever call that "equality", because respecting alpha-equivalence takes quite a lot of care. (Correspondingly, I'd switch to a representation which admitted equality.) [..] >> Of >> course, if you want to expose the representation >> for some other legitimate purpose, then it wasn't >> equality you were interested in, so you should >> call it something else. > > I'm perfectly happy calling it Equivalence. I'm perfectly happy having equivalences around, but if "Eq" means "has an equivalence" rather than "has equality", then I'm not very happy about the use of the == sign. [..] > That's a workable definition, but I don't know if I'd call it a > sort, precisely. The standard unix tool "tsort" (for "topological > sort", a bit of a misnomer) does this. > >> Will that do? > > Unfortunately, one can't just reuse the standard algorithms. Indeed. (Does anyone know a topological sort algorithm which behaves like an ordinary sort if you do give it a total order? Or a reason why there's no such thing?) So you're probably right that x <= y \/ y <= x should hold for the order relation used by library sort. That's not the axiom I was thinking of dropping when I said sort's type was too tight (it was you who brought up incomparability): I was thinking of dropping antisymmetry. > If a sort can't support the standard "sort on this key" technique, and > don't munge everything for two keys that compare equal, something is > wrong. And I don't think sort is that special a case. I quite agree. That's why I'm suggesting we drop antisymmetry as a requirement for sorting. > > Instances, rather than explicit functions, are nice because they > let us > use the type system to ensure that we never have incompatible > functions > used when combining two data structures, or pass in a function that's > incompatible with the invariants already in a data structure built > with > another function. I'm not sure what you mean here. > So we surely do need an equivalence relation typeclass. And there are > Eq instances that aren't quite equality, but are equivalences, and > work > with almost all code that takes Eq instances. My main concern is that we should know where we stand. I think it would be a very good thing if we knew what the semantic notion of equality should be for each type. What notion of equality should we use in discussion? What do we mean when we write "laws" like map f . map g = map (f . g) ? I write = to distinguish it from whatever Bool-valued function at some type or other that we might call ==. Given sneaky ways to observe memory pointers or fairly ordinary ways to expose representations which are supposed to be abstract, it's clearly impossible to ensure that = is absolutely always respected. It would be good if it was clear which operations were peculiar in this way. I'd like to know when I can reason just by replacing equals for equals, and when more care is required (eg, when ensuring that substitution respects alpha- equivalence). From the point of view of reasoning (informally or formally) it then becomes useful to know that some binary Bool-valued function is sound with respect to = and complete when one argument is defined and finite. It's useful to know that one is testing equality, rather than just some equivalence, because equality supports stronger reasoning principles. Equivalences are useful too, but harder to work with. I quite agree that we should support them, and that it is reasonable to do so via typeclasses: if a type supports multiple useful equivalences, then the usual newtype trick is a reasonable enough way to manage it. > > The only time treating equalities as equivalences won't work is > when we > need to coalesce equivalent elements into one representative, and the > choice of representative matters. Another time when treating equalities just as equivalences won't do is when it's time to think about whether your program works. This issue is not just an operational one, although in the case of TypeRep, for example, it can get pretty near the bone. > So, do we mark equivalencies as special, or observational equality as > special? Which is the tagging class, and which has the methods? I > think it's pretty clear that the way to go is have (==) and (/=) live > in Equiv, and have Equal be a tagging class. An equivalence is not a > special type of equality, but equality is a special type of > equivalence. Isn't it misleading to use the == symbol for something less than equality? One could keep == as a method of Equal, defined to coincide with ~=~ or whatever is the equivalence method. An alternative, contrary to your assertion, is to introduce an equivalence as the equality on a quotient via a newtype. That's a conventional "type with funny structure" use of newtype and it has the advantage of keeping just the one class, and of providing a syntactic cue (unpacking the newtype) to tell you when you've stepped outside the domain of observations for which equational reasoning just works. The point is to make it clear, one way or another, which modes of reasoning apply. > > Given all that, I think current Eq as Equivalence makes sense, and we > need to add an Equal class for things where we truly can't tell > equivalent elements apart. You may ultimately be right, but I don't think you've made the case. Moreover, if you are right, then people will need to change the way they think and write about Eq and == in the murk of its impoverished meaning. I don't suppose I'd complain too much at any outcome which allows the stronger discipline to expressed somehow. If we have to make the weaker notion the default, isn't that a little sad? All the best Conor From wnoise at ofb.net Sat Mar 15 15:00:35 2008 From: wnoise at ofb.net (Aaron Denney) Date: Sat Mar 15 14:57:40 2008 Subject: [Haskell-cafe] Re: (flawed?) benchmark : sort References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <47D5416C.808@iee.org> <871w6i8wx4.fsf@nmd9999.imr.no> <47D55287.5040701@iee.org> <404396ef0803100829h44c8ac1dg4ee6f0132cb4f929@mail.gmail.com> <47D56B7A.2030200@iee.org> <220e47b40803101207w6d4bb795k68d959b3ccff9849@mail.gmail.com> <47D5A46A.5010800@iee.org> <404396ef0803101433s435bbc64j46617fe50ba46aa5@mail.gmail.com> <47D63C44.7070704@iee.org> <6dbd4d000803110846k3fcb94a8k9ad780c2dd8272fc@mail.gmail.com> <47D6B140.4010002@iee.org> <47D7E0F5.6090907@jellybean.co.uk> <20080312194804.o14f2bxhcwgo00sw@webmail.spamcop.net> <47D8D11F.3010002@iee.org> <20080313182842.23pl2dtt4owoo4sg@webmail.spamcop.net> <00E7D026-8FAF-4BEE-9049-456374CE70C3@strictlypositive.org> <62B9D97C-0A24-4F67-BE32-9CCFCE33B8F3@strictlypositive.org> <6331F8DE-7F8C-45A4-82EE-99D967864F39@strictlypositive.org> Message-ID: On 2008-03-15, Conor McBride wrote: > Hi > > On 14 Mar 2008, at 21:39, Aaron Denney wrote: > >> On 2008-03-14, Conor McBride wrote: >>> Hi >>> >>> On 13 Mar 2008, at 23:33, Aaron Denney wrote: >>> >>>> On 2008-03-13, Conor McBride wrote: >>>>> For a suitable notion of = on quotients, and with a >>>>> suitable abstraction barrier at least morally in place, >>>>> is that really too much to ask? >>>> >>>> I really think it is. I don't think the case of "equivalent for >>>> this >>>> purpose, but not that purpose" can be ignored. >>> >>> Sure. But use the right tools for the job. >> >> So what are the right tools then? Why is a typeclass not the right >> tool? > > I guess I mean to distinguish *equality*, which is > necessarily respected by all observations (for some > notion of observation which it's important to pin > down), from coarser equivalences where respect takes > careful effort. Which is worth doing. But I think, in the end very little interesting could end up passing that muster totally. Once you weaken it a bit, the guarantees are gone. In practice, I think there are significant number of user defined type that implement Eq that just don't pass this test. We can recognize this, or declare all that code bad. > I'm perfectly happy having equivalences around, > but if "Eq" means "has an equivalence" rather > than "has equality", then I'm not very happy > about the use of the == sign. Well, no, it's not ideal. In fact, it's downright misleading. I also think it's the best we can do before Haskell', in terms of not causing gratuitous code breakage. > So you're probably right that > > x <= y \/ y <= x > > should hold for the order relation used by > library sort. That's not the axiom I was > thinking of dropping when I said sort's type > was too tight (it was you who brought up > incomparability): I was thinking of dropping > antisymmetry. > >> If a sort can't support the standard "sort on this key" >> technique, and don't munge everything for two keys that >> compare equal, something is wrong. And I don't think >> sort is that special a case. > > I quite agree. That's why I'm suggesting we > drop antisymmetry as a requirement for sorting. Ah. The normal weakening of a total order is a partial order, and I was stuck on that, instead of this weakening, which technically makes it a "total preorder". And I think that's the right semantics for the Ord class, because that's the common case for programming. Can we make a reasonable class hierarchy that supports all these notions? class Equiv a where (~=~), (~/~) :: a -> a -> Bool class Equiv a => Equal a where (==), (/=) :: a -> a -> Bool (==) = (~=~) (/=) = (~/~) class Equiv a => PreOrd a where compare :: a -> a -> Ordering (<), (<~), (>~), (>) :: a -> a -> Bool class (PreOrd a, Equal a) => Ord a where (<=), (>=) :: a -> a -> Bool (<=) = (<~) (>=) = (>~) (And both are orderings are total.) How do we nicely add partial orders? semantically we want class (PartialOrder a) => Order a where compare = narrow partialCompare but "narrow" by necessity has an incomplete pattern match. An easy thing would be instance (Order a) => PartialOrder a where partialCompare = inject compare but this lacks flexibility. Will this flexibility ever be necessary? Quite possibly. But, as usual, newtypes can come to the rescue, at the cost of some akwardness. Should this also be done for Equiv, Equal, PreOrder and Ord? >> Instances, rather than explicit functions, are nice because they let >> us use the type system to ensure that we never have incompatible >> functions used when combining two data structures, or pass in a >> function that's incompatible with the invariants already in a data >> structure built with another function. > > I'm not sure what you mean here. Consider data Treehelp a = Leaf | Branch (Treehelp a) a (Treehelp a) data Tree a = (a -> a -> Ordering, Treehelp a) how do we implement merge :: Tree a -> Tree a -> Tree a so that two incompatible orderings aren't used? Okay, you say, let's not embed the functions in the tree: data Tree a = Leaf | Branch (Tree a) a (Tree a) insert :: (a -> a -> Ordering) -> Tree a -> Tree a merge :: (a -> a -> Ordering) -> Tree a -> Tree a -> Tree a But these two will do something wrong if the trees were constructed with a different function. Instead, if we have merge :: Ord a => Tree a -> Tree a -> Tree a The ordering is carried along in the dictionary, and the typechecker ensures that only trees using the same ordering are merged. Different orders on the same underlying type can be achieved with newtype wrappers. > My main concern is that we should know where we > stand. I think it would be a very good thing if > we knew what the semantic notion of equality > should be for each type. What notion of equality > should we use in discussion? What do we mean when > we write "laws" like > > map f . map g = map (f . g) > > ? I write = to distinguish it from whatever > Bool-valued function at some type or other > that we might call ==. Right. My point of view is that whatever is denoted by = is a notion that lives outside the operators in the language itself, including (==). We can do certain formal manipulations using the definitions in the language. >> The only time treating equalities as equivalences won't >> work is when we need to coalesce equivalent elements into >> one representative, and the choice of representative >> matters. > > Another time when treating equalities just as > equivalences won't do is when it's time to think > about whether your program works. This issue is > not just an operational one, although in the > case of TypeRep, for example, it can get pretty > near the bone. > An alternative, contrary to your assertion, > is to introduce an equivalence as the equality > on a quotient via a newtype. That's a > conventional "type with funny structure" use > of newtype and it has the advantage of keeping > just the one class, and of providing a > syntactic cue (unpacking the newtype) to tell > you when you've stepped outside the domain of > observations for which equational reasoning > just works. The point is to make it clear, one > way or another, which modes of reasoning > apply. This sounds persuasive, but the example of a sort that feels free to replace equivalent elements shows that although we want two nonequal elements to be treated as "equal" for the purposes of comparison and reordering them, we don't really always mean truely, 100% of the time, equal, because substitution is not, in fact, allowable. And I do think that this is either the common case, or that it doesn't hurt 99% of the time to write code that works for this case. >> Given all that, I think current Eq as Equivalence makes >> sense, and we need to add an Equal class for things where >> we truly can't tell equivalent elements apart. > > You may ultimately be right, but I don't think > you've made the case. Moreover, if you are > right, then people will need to change the way > they think and write about Eq and == in the > murk of its impoverished meaning. Some people will need to change the way we think whichever semantics we assign. -- Aaron Denney -><- From uhollerbach at gmail.com Sat Mar 15 17:04:55 2008 From: uhollerbach at gmail.com (Uwe Hollerbach) Date: Sat Mar 15 17:01:52 2008 Subject: [Haskell-cafe] build recent(ish) ghc on macos 10.3.9 powerpc? Message-ID: <65d7a7e0803151404j275690b5pfe4951f37cb9dc5b@mail.gmail.com> [Augh! gmail won't send! Apologies if this shows up more than once...] Hi, all, I have an old iMac G3, running OSX 10.3.9, to which I have a sentimental attachment. I'd like to get ghc running on it, but the pre-built binaries I can find are all for more-recent iMacs, so I thought I would try to build it myself. I believe I read somewhere that gcc 3.3.X didn't work quite right for recent ghc -- I'm trying for now to build ghc 6.6.1 -- so I started by upgrading gcc to 3.4.6. That's working. So, with that in place, I went to the "porting ghc to a new arch" page and started going through the steps. I'm using a laptop running linux as the "host" computer, so that's i386-unknown-linux, some Fedora core derivative. It's using gcc 3.4.4. I think I did all the initial stuff right, but in the section in the porting guide where it says to start diving into all the subdirectories and do a bunch of "make boot && make", I start getting errors, and by the time it says to do that in .../libraries, it just croaks. Did I miss something earlier? Is this a completely hopeless endeavor from the get-go? I'm not even sure what intermediate files or error messages I should post. Any hints appreciated!. If you want to tell me, "Uwe, you're a bozo", that's fine, too, and you could well be right, just tell me why... Thanks! Uwe From magnus at therning.org Sat Mar 15 18:02:07 2008 From: magnus at therning.org (Magnus Therning) Date: Sat Mar 15 17:59:05 2008 Subject: [Haskell-cafe] ANNOUNCE: omnicodec Message-ID: <47DC475F.7050809@therning.org> I've just uploaded to hackage a package containing two command line utilities for encoding and decoding data, called omnicodec. It's built on top of dataenc. /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus?therning?org Jabber: magnus?therning?gmail?com http://therning.org/magnus What if I don't want to obey the laws? Do they throw me in jail with the other bad monads? -- Daveman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080315/f48182f0/signature.bin From gn at oglaroon.de Sat Mar 15 18:40:08 2008 From: gn at oglaroon.de (Georg Neis) Date: Sat Mar 15 18:37:08 2008 Subject: [Haskell-cafe] Re: HFuse: ls fails in HelloFS References: <1205550042-sup-1361@continuum> Message-ID: Austin Seipp wrote: > The only recent work I know of on the project is that of Will > Thompsons'. A darcs repository can be located here: > > http://www.willthompson.co.uk/darcs/hfuse/ This one is working. Thanks a lot, Austin and Will! Georg From judah.jacobson at gmail.com Sun Mar 16 02:11:03 2008 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Sun Mar 16 02:07:57 2008 Subject: [Haskell-cafe] build recent(ish) ghc on macos 10.3.9 powerpc? In-Reply-To: <65d7a7e0803151404j275690b5pfe4951f37cb9dc5b@mail.gmail.com> References: <65d7a7e0803151404j275690b5pfe4951f37cb9dc5b@mail.gmail.com> Message-ID: <6d74b0d20803152311q38fa04b1s936b82964762f970@mail.gmail.com> On Sat, Mar 15, 2008 at 2:04 PM, Uwe Hollerbach wrote: > > Hi, all, I have an old iMac G3, running OSX 10.3.9, to which I have a > sentimental attachment. I'd like to get ghc running on it, but the > pre-built binaries I can find are all for more-recent iMacs, so I > thought I would try to build it myself. I believe I read somewhere > that gcc 3.3.X didn't work quite right for recent ghc -- I'm trying > for now to build ghc 6.6.1 -- so I started by upgrading gcc to 3.4.6. > That's working. So, with that in place, I went to the "porting ghc to > a new arch" page and started going through the steps. I'm using a > laptop running linux as the "host" computer, so that's > i386-unknown-linux, some Fedora core derivative. It's using gcc 3.4.4. > It looks like ghc 6.4.1 had an installer package for 10.3.9; does that work for you? http://www.haskell.org/ghc/download_ghc_641.html I think that the current version of ghc is supposed to be buildable with 6.4, so you might be able to bootstrap 6.6 or 6.8 that way, without going through the whole porting process. Let us know if you run into problems with it. Hope that helps, -Judah From ashley at semantic.org Sun Mar 16 02:27:52 2008 From: ashley at semantic.org (Ashley Yakeley) Date: Sun Mar 16 02:24:55 2008 Subject: [Haskell-cafe] "GADT" rhymes with "cat" Message-ID: "GADT" rhymes with "cat". The "d" is silent, like the Danish "godt", or the German "Stadt", or the American trademark "Bundt". -- Ashley Yakeley From ajb at spamcop.net Sun Mar 16 02:34:50 2008 From: ajb at spamcop.net (ajb@spamcop.net) Date: Sun Mar 16 02:31:43 2008 Subject: [Haskell-cafe] "GADT" rhymes with "cat" In-Reply-To: References: Message-ID: <20080316023450.j5kpairr40sg4wk0@webmail.spamcop.net> G'day all. Quoting Ashley Yakeley : > "GADT" rhymes with "cat". The "d" is silent, like the Danish "godt", or > the German "Stadt", or the American trademark "Bundt". I pronounce it so that it rhymes with "ADT". Cheers, Andrew Bromage From nornagon at gmail.com Sun Mar 16 05:56:13 2008 From: nornagon at gmail.com (Jeremy Apthorp) Date: Sun Mar 16 05:53:05 2008 Subject: [Haskell-cafe] "GADT" rhymes with "cat" In-Reply-To: <20080316023450.j5kpairr40sg4wk0@webmail.spamcop.net> References: <20080316023450.j5kpairr40sg4wk0@webmail.spamcop.net> Message-ID: <14d615330803160256y12382aeem553196132ab42ba0@mail.gmail.com> On 16/03/2008, ajb@spamcop.net wrote: > Quoting Ashley Yakeley : > > > "GADT" rhymes with "cat". The "d" is silent, like the Danish "godt", or > > the German "Stadt", or the American trademark "Bundt". > > > I pronounce it so that it rhymes with "ADT". > Clearly, this pronounciation is "gay dee tea." I always new those types were a bit queer. Jeremy From ajb at spamcop.net Sun Mar 16 06:01:35 2008 From: ajb at spamcop.net (ajb@spamcop.net) Date: Sun Mar 16 05:58:30 2008 Subject: [Haskell-cafe] "GADT" rhymes with "cat" In-Reply-To: <14d615330803160256y12382aeem553196132ab42ba0@mail.gmail.com> References: <20080316023450.j5kpairr40sg4wk0@webmail.spamcop.net> <14d615330803160256y12382aeem553196132ab42ba0@mail.gmail.com> Message-ID: <20080316060135.r9v6u6dkgsg00ow0@webmail.spamcop.net> G'day all. Quoting Jeremy Apthorp : > Clearly, this pronounciation is "gay dee tea." I always new those > types were a bit queer. Not that there's anything wrong with that. Cheers, Andrew Bromage From allbery at ece.cmu.edu Sun Mar 16 06:09:53 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sun Mar 16 06:06:46 2008 Subject: [Haskell-cafe] "GADT" rhymes with "cat" In-Reply-To: <20080316060135.r9v6u6dkgsg00ow0@webmail.spamcop.net> References: <20080316023450.j5kpairr40sg4wk0@webmail.spamcop.net> <14d615330803160256y12382aeem553196132ab42ba0@mail.gmail.com> <20080316060135.r9v6u6dkgsg00ow0@webmail.spamcop.net> Message-ID: On Mar 16, 2008, at 6:01 , ajb@spamcop.net wrote: > G'day all. > > Quoting Jeremy Apthorp : > >> Clearly, this pronounciation is "gay dee tea." I always new those >> types were a bit queer. > > Not that there's anything wrong with that. A bit short of "gaiety"? -- 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 will at willthompson.co.uk Sun Mar 16 09:37:00 2008 From: will at willthompson.co.uk (Will Thompson) Date: Sun Mar 16 09:30:23 2008 Subject: [Haskell-cafe] Re: HFuse: ls fails in HelloFS In-Reply-To: References: <1205550042-sup-1361@continuum> Message-ID: <47DD227C.208@willthompson.co.uk> I just merged my work with Taru Karttunen's; you probably want to % darcs get http://code.haskell.org/hfuse/ The API is a tad different to the one in my old repository; I had some kind of pointless MVar state threading in my branch which I wrote on a whim but which isn't particularly useful, so I left it out. Taru has ByteString-ized reading from files, which is a win. Currently the module's name is HFuse. Presumably it really belongs under System somewhere; System.Posix.Fuse maybe? What do folks think? Are there any guidelines for picking a namespace? -- Will -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080316/6f02dfab/signature.bin From uhollerbach at gmail.com Sun Mar 16 12:03:18 2008 From: uhollerbach at gmail.com (Uwe Hollerbach) Date: Sun Mar 16 12:00:14 2008 Subject: [Haskell-cafe] build recent(ish) ghc on macos 10.3.9 powerpc? In-Reply-To: <6d74b0d20803152311q38fa04b1s936b82964762f970@mail.gmail.com> References: <65d7a7e0803151404j275690b5pfe4951f37cb9dc5b@mail.gmail.com> <6d74b0d20803152311q38fa04b1s936b82964762f970@mail.gmail.com> Message-ID: <65d7a7e0803160903l235e7802wc14507c3794ded36@mail.gmail.com> Thanks for the tip, Judah, I went and got the ghc 6.4.1 package... unfortunately, it installs ok, but isn't able to compile anything: I get "Unknown pseudo-op: .subsections_via_symbols" when I try to build a trivial test program. I found one note on the web that says "can't work, needs newer version of XCode than comes with OSX 10.3", and another note that says "you have to install all of XCode". So I'm going to see if I missed installing some portion of XCode (I don't think so, but it was a while ago), but otherwise I might just be out of luck :-( Uwe On 3/15/08, Judah Jacobson wrote: > On Sat, Mar 15, 2008 at 2:04 PM, Uwe Hollerbach wrote: > > > > Hi, all, I have an old iMac G3, running OSX 10.3.9, to which I have a > > sentimental attachment. I'd like to get ghc running on it, but the > > pre-built binaries I can find are all for more-recent iMacs, so I > > thought I would try to build it myself. I believe I read somewhere > > that gcc 3.3.X didn't work quite right for recent ghc -- I'm trying > > for now to build ghc 6.6.1 -- so I started by upgrading gcc to 3.4.6. > > That's working. So, with that in place, I went to the "porting ghc to > > a new arch" page and started going through the steps. I'm using a > > laptop running linux as the "host" computer, so that's > > i386-unknown-linux, some Fedora core derivative. It's using gcc 3.4.4. > > > > > It looks like ghc 6.4.1 had an installer package for 10.3.9; does that > work for you? > http://www.haskell.org/ghc/download_ghc_641.html > > I think that the current version of ghc is supposed to be buildable > with 6.4, so you might be able to bootstrap 6.6 or 6.8 that way, > without going through the whole porting process. Let us know if you > run into problems with it. > > Hope that helps, > > -Judah > From adam.smyczek at gmail.com Sun Mar 16 13:21:24 2008 From: adam.smyczek at gmail.com (Adam Smyczek) Date: Sun Mar 16 13:18:17 2008 Subject: [Haskell-cafe] Network.Browser and getCookies Message-ID: <1B8811DF-4BA5-4B15-8097-BFD266C8DBE0@gmail.com> Somehow I cannot get cookies from the Response using Network.Browser module (HTTP 3001.0.4). The cookie header part seams to be empty and getCookies returns empty list as well. Any idea how to debug this or does someone have a working example? Thanks, Adam From rodrigo.bonifacio at uol.com.br Sun Mar 16 13:42:30 2008 From: rodrigo.bonifacio at uol.com.br (rodrigo.bonifacio) Date: Sun Mar 16 13:39:24 2008 Subject: [Haskell-cafe] QuickCheck Message-ID: Hi all, I'm trying to use the quick-check library for checking some properties of a user defined data type. Bellow the target data type: data Feature = Feature Id Name FeatureType GroupType Children Properties | FeatureError where: Id = String Name = String FeatureType = int GroupType = int Children = [Feature] Propertyes = [String] I've written the following quick-check property: prop_AlternativeFeature :: Feature -> Feature -> QuickCheck.Property prop_AlternativeFeature fm fc = length (children fc) == 0 ==> length (checkAlternativeFeature fm fc) > 0 When I try to check such property, the result is: ERROR "./EshopModelChecking.hs":11 - Type error in instance member binding *** Term : arbitrary *** Type : Feature *** Does not match : Gen Feature I think that I need to write some arbitrary or generator functions, but I didn't realize how to do that with the availalble quick-checking documentation. Any help will be welcome. Thanks in advance. Rodrigo. From sebastian.sylvan at gmail.com Sun Mar 16 14:27:56 2008 From: sebastian.sylvan at gmail.com (Sebastian Sylvan) Date: Sun Mar 16 14:24:48 2008 Subject: [Haskell-cafe] QuickCheck In-Reply-To: References: Message-ID: <3d96ac180803161127o51fcdf50u9b966a2f88b90315@mail.gmail.com> On Sun, Mar 16, 2008 at 5:42 PM, rodrigo.bonifacio < rodrigo.bonifacio@uol.com.br> wrote: > Hi all, > > I'm trying to use the quick-check library for checking some properties of > a user defined data type. Bellow the target data type: > > data Feature = > Feature Id Name FeatureType GroupType Children Properties | > FeatureError > > where: > > Id = String > Name = String > FeatureType = int > GroupType = int > Children = [Feature] > Propertyes = [String] > > > I've written the following quick-check property: > > prop_AlternativeFeature :: Feature -> Feature -> QuickCheck.Property > prop_AlternativeFeature fm fc = length (children fc) == 0 ==> length > (checkAlternativeFeature fm fc) > 0 > > When I try to check such property, the result is: > > ERROR "./EshopModelChecking.hs":11 - Type error in instance member binding > *** Term : arbitrary > *** Type : Feature > *** Does not match : Gen Feature > > I think that I need to write some arbitrary or generator functions, but I > didn't realize how to do that with the availalble quick-checking > documentation. > > Any help will be welcome. > > You use the available functions to build up a generator for your data type. First, let's give the instanc itself. For this I'm just going to use the frequency function to use "featureGenNormal" five times more often than "return FeatureError". This means that will get a FeatureError every now and then, but mostly you'll get featureGenNormal (see below). You can change these frequences, of course. instance Arbitrary Feature where arbitrary = do frequency [ (5, featureGenNormal), (1, return FeatureError) ] In order to write featureGenNormal, we need to be able to generate random values of each of the parts of the data type. Often these types will already have Arbitrary instances, so generating an isntance for your type is quite often just a matter of calling "arbitrary" for each component, and then returning a datatype. However, there is no Arbitrary instance for String, which is a bit annoying, so let's write our own generator for strings. First a generator for a single letter: letterGen = oneof $ map return $ ['a'..'z'] ++ ['A'..'Z'] Then a combinator for generating a list of values given a generator for a single value: listGen :: Gen a -> Gen [a] listGen g = do x <- g xs <- frequency [ (1, return []), (10, listGen g) ] return (x:xs) And then we use this to build our "stringGen" generator. stringGen :: Gen String stringGen = listGen letterGen Now, we have all we need to write the featureGenNormal generator: featureGenNormal = do id <- stringGen name <- stringGen featuretype <- arbitrary grouptype <- arbitrary children <- arbitrary properties <- listGen stringGen return (Feature id name featuretype grouptype children properties) Note that we use "arbitrary" to generate the list of children recursively. -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080316/0875e0fb/attachment.htm From rodrigo.bonifacio at uol.com.br Sun Mar 16 15:19:22 2008 From: rodrigo.bonifacio at uol.com.br (rodrigo.bonifacio) Date: Sun Mar 16 15:16:16 2008 Subject: [Haskell-cafe] QuickCheck Message-ID: Dear Sebastian Sylvan, Thanks for your datailed answer. It saved me a lot of time. Best regards, Rodrigo. > On Sun, Mar 16, 2008 at 5:42 PM, rodrigo.bonifacio < > rodrigo.bonifacio@uol.com.br> wrote: > > > Hi all, > > > > I'm trying to use the quick-check library for checking some properties of > > a user defined data type. Bellow the target data type: > > > > data Feature = > > Feature Id Name FeatureType GroupType Children Properties | > > FeatureError > > > > where: > > > > Id = String > > Name = String > > FeatureType = int > > GroupType = int > > Children = [Feature] > > Propertyes = [String] > > > > > > I've written the following quick-check property: > > > > prop_AlternativeFeature :: Feature -> Feature -> QuickCheck.Property > > prop_AlternativeFeature fm fc = length (children fc) == 0 ==> length > > (checkAlternativeFeature fm fc) > 0 > > > > When I try to check such property, the result is: > > > > ERROR "./EshopModelChecking.hs":11 - Type error in instance member binding > > *** Term : arbitrary > > *** Type : Feature > > *** Does not match : Gen Feature > > > > I think that I need to write some arbitrary or generator functions, but I > > didn't realize how to do that with the availalble quick-checking > > documentation. > > > > Any help will be welcome. > > > > > You use the available functions to build up a generator for your data type. > > First, let's give the instanc itself. For this I'm just going to use the > frequency function to use "featureGenNormal" five times more often than > "return FeatureError". This means that will get a FeatureError every now and > then, but mostly you'll get featureGenNormal (see below). You can change > these frequences, of course. > > instance Arbitrary Feature where > arbitrary = do > frequency [ (5, featureGenNormal), (1, return FeatureError) ] > > In order to write featureGenNormal, we need to be able to generate random > values of each of the parts of the data type. Often these types will already > have Arbitrary instances, so generating an isntance for your type is quite > often just a matter of calling "arbitrary" for each component, and then > returning a datatype. However, there is no Arbitrary instance for String, > which is a bit annoying, so let's write our own generator for strings. > > First a generator for a single letter: > > letterGen = oneof $ map return $ ['a'..'z'] ++ ['A'..'Z'] > > Then a combinator for generating a list of values given a generator for a > single value: > > listGen :: Gen a -> Gen [a] > listGen g = do > x <- g > xs <- frequency [ (1, return []), (10, listGen g) ] > return (x:xs) > > And then we use this to build our "stringGen" generator. > > stringGen :: Gen String > stringGen = listGen letterGen > > Now, we have all we need to write the featureGenNormal generator: > > featureGenNormal = do > id <- stringGen > name <- stringGen > featuretype <- arbitrary > grouptype <- arbitrary > children <- arbitrary > properties <- listGen stringGen > return (Feature id name featuretype grouptype children properties) > > > Note that we use "arbitrary" to generate the list of children recursively. > > -- > Sebastian Sylvan > +44(0)7857-300802 > UIN: 44640862 > ----------------------------------- Rodrigo Bonif?cio de Almeida Universidade Cat?lica de Bras?lia - Grupo de Engenharia de Software - JavaComBr (www.ucb.br/java) From iahogsp at gmail.com Sun Mar 16 15:49:38 2008 From: iahogsp at gmail.com (Isto Aho) Date: Sun Mar 16 15:46:30 2008 Subject: [Haskell-cafe] type families, fun deps, lattices imposed on/by types Message-ID: <470880360803161249s6dd5a8c2m79cdb3a73412a5a8@mail.gmail.com> Hi all, I was trying to solve a problem and by chance found texts on functional dependencies and then on type families (papers, ghc docs). Please, consider the example 03 of "Understanding functional dependencies via Constraint Handling rules" by Sulzmann, Duck, Peyton-Jones and Stuckey. There we are defining a multiplication over different numeric types: class Mul a b c | a b -> c where (*) :: a -> b -> c instance Mul Int Int Int where ... instance Mul Int Float Float where ... Ok, we could add instance Mul Float Int Float where ... but if we want to make everything work nicely together, Integer, Complex, Rational etc, there will be a lot of instances, especially if we have to give both "Float Int" and "Int Float" instances. And now the question on "lattices of types" (didn't know any better name to refer to the following): Is the following possible? Or can something similar achieved with type families (easily)? type lattice T a b -- Each of the following gives a "<"-relation between types, -- "upper" gives a method, how we get the larger (2nd) from -- the smaller (1st). lattice instance T Int Integer where upper = fromIntegral lattice instance T Int Float where upper = fromIntegral lattice instance T Integer (Ratio Integer) where upper = ... lattice instance T (Ratio Integer) Double where ... lattice instance T Float Double ... lattice instance T Double (Complex Double) ... -- e.g. Now the compiler can check that the top type is -- unique and that there is a path from every type to the top type. -- If the compiler founds this not to be the case, an error is output. -- But otherwise there can be types that are not comparable but -- the common top is quaranteed to exist. class Mul a b c where lattice T (*) :: a -> b -> c (*) x y = (upper x y x) * (upper x y y) -- Now there is no need for the instances like. instance Mul Int Float Float where ... instance Mul Float (Ratio Integer) Double where ... The compiler can generate those instances, because we have given the "upper"-methods. There is always the top available. Function (*) x y = (upper x y x) * (upper x y y) might could be replaced with (*) x y = x * y because of the presence of lattice T and thus, the "upper"-function. If this were possible, the benefits would be: - No need to state "Int Float" and "Float Int" instances on cases where the operands do commute. - No need to write a large number of instances if you have several "types on lattice" (e.g. some more or less well defined relation). - If the relation between types is not clear, we could define another lattice T2 to our Mul2 class for the other uses. Continuing the idea: we could override the default instances generated by the compiler with our own instances when needed. Ok, so, is it possible to write something like that already? (I just wouldn't like write a lot of instances...) If not, would it be possible to extend, say ghc, to work that way or are there too much inconsistencies in the above presentation? (Yes, where is the bottom. Why top and not bottom? Should it be possible to tell, which one to use, if both present? e.g.) Thanks for reading this far! -- br, Isto -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080316/4dee6342/attachment.htm From niklas.broberg at gmail.com Sun Mar 16 16:34:36 2008 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Sun Mar 16 16:31:26 2008 Subject: [Haskell-cafe] ANN: haskell-src-exts 0.3.2 Message-ID: Hi all, I'm pleased to announce a new release for the haskell-src-exts package. haskell-src-exts 0.3.2 =========================== haskell-src-exts is a package for handling and manipulating Haskell source code. It is based on the haskell-src package that is part of the standard libraries, but extends this to support a number of syntactic extensions, e.g. MPTCs, fundeps, GADTs, TH etc. It is intended as a drop-in replacement for the standard haskell-src package, and exports the same functions and data types, plus some more. Apart from the more standard extensions supported by e.g. GHC, haskell-src-exts also provides support for HaRP (Haskell Regular Patterns) and HSX (Haskell Source with XML) syntax. Note that as of 0.3, haskell-src-exts /= HSX. * cabal sdist: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/haskell-src-exts-0.3.2 * darcs repo: darcs get http://code.haskell.org/HSP/haskell-src-exts === Changes from 0.2: === * Added support for - Indexed type families (including associated types/datatypes) - Explicit kind signatures - Standalone deriving * haskell-src-exts is now decoupled from hsx/trhsx and harp. - Modules renamed to Language.Haskell.Exts.* - Module Transform is removed from the package (now in package hsx) * New repository (i.e. darcs pull in an old repo won't work, use darcs get), containing only the haskell-src-exts package (no hsx or harp). * Builds with 6.8.2 (thanks Duncan Coutts) === Complete list of supported extensions === * Multi-parameter type classes (MPTCs) * Functional dependencies * Associated types, indexed type families * Liberal class and instance heads * Implicit parameters * Explicit kind signatures * Pattern guards * Generalized algebraic data types (GADTs) * Template Haskell (TH) * Universal and existential quantification (forall) * Empty data type declarations * Unboxed tuples (# #) * Standalone deriving * Regular patterns * Haskell XML, HSX style === Build Requirements === * happy >= 1.17 - It might work with 1.16 though I haven't tested. In that case change the cabal file. - It would work with older versions as well, though they insert a dependency on Array (haskell98) instead of Data.Array. If that's all you have to work with, update the cabal file with a dependency on haskell98. * Cabal >= 1.2 Patches are more than welcome. :-) Cheers, /Niklas From ganesh at earth.li Sun Mar 16 17:35:50 2008 From: ganesh at earth.li (Ganesh Sittampalam) Date: Sun Mar 16 17:32:41 2008 Subject: [Haskell-cafe] problem with type equality constraints Message-ID: Hi, When I try to compile this code with ghc-6.9.20080310: module Test2 where type family Id a type instance Id Int = Int type instance Id (a, b) = (Id a, Id b) class Id a ~ ida => Foo a ida instance Foo Int Int instance (Foo a ida, Foo b idb) => Foo (a, b) (ida, idb) I get these errors: Test2.hs:12:0: Couldn't match expected type `ida' against inferred type `Id a' `ida' is a rigid type variable bound by the instance declaration at Test2.hs:12:16 When checking the super-classes of an instance declaration In the instance declaration for `Foo (a, b) (ida, idb)' Test2.hs:12:0: Couldn't match expected type `idb' against inferred type `Id b' `idb' is a rigid type variable bound by the instance declaration at Test2.hs:12:27 When checking the super-classes of an instance declaration In the instance declaration for `Foo (a, b) (ida, idb)' It seems to me that since Foo a ida and Foo b idb are superclassess, Id a ~ ida and Id b ~ idb should be known and so this should have worked - am I missing something? Cheers, Ganesh From coeus at gmx.de Sun Mar 16 19:38:29 2008 From: coeus at gmx.de (Marc A. Ziegert) Date: Sun Mar 16 19:35:31 2008 Subject: [Haskell-cafe] "GADT" rhymes with "cat" In-Reply-To: References: <20080316060135.r9v6u6dkgsg00ow0@webmail.spamcop.net> Message-ID: <200803170038.37526.coeus@gmx.de> "GADTs" always reminds me of the japanese word . == == , spoken somehow like "gah-t--ts..." followed by a half spoken english "u" (second half). means in english "guts". that in mind, i was just GADDing in StarDict, which translates with "burning with desire for something, greedily". hm. that explains how excited some people are about this extension. guts are important. - marc -------------- 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/20080317/b08e7a2e/attachment.bin From anton at appsolutions.com Sun Mar 16 21:01:33 2008 From: anton at appsolutions.com (Anton van Straaten) Date: Sun Mar 16 20:49:02 2008 Subject: [Haskell-cafe] "GADT" rhymes with "cat" In-Reply-To: References: Message-ID: <47DDC2ED.1030400@appsolutions.com> Ashley Yakeley wrote: > "GADT" rhymes with "cat". The "d" is silent, like the Danish "godt", or > the German "Stadt", or the American trademark "Bundt". As long as you don't pronounce it like "gat" in Dutch and Afrikaans, which literally means "hole", but also has a vulgar sense which means anus or ass/arse: http://en.wiktionary.org/wiki/gat Those who believe that GADTs are unnecessary might appreciate the guttural pronunciation of "gat": which is something like "chut" where the "ch" is similar to that in "loch", and for good measure, it rhymes with "slut" (at least in Afrikaans). It lends itself well to being uttered contemptuously. Since this thread seems to indicate that the pronunciation of GADT is up for grabs, I propose "gaddit", as in "it's a gaddit, geddit?" or "I prefer to rely on mipticks[*] and fundeps rather than gaddits". Anton [*] Don't tell me that one's not settled yet, either! From rl at cse.unsw.edu.au Sun Mar 16 21:36:36 2008 From: rl at cse.unsw.edu.au (Roman Leshchinskiy) Date: Sun Mar 16 21:33:39 2008 Subject: [Haskell-cafe] Specification for Eq? In-Reply-To: References: <220e47b40803031645y3ca02ecbjc745604a2dc2e0b4@mail.gmail.com> <47D52A87.9060805@iee.org> <404396ef0803100632w6ae183f3w467aa02bae40caa2@mail.gmail.com> <47D5416C.808@iee.org> <871w6i8wx4.fsf@nmd9999.imr.no> <47D55287.5040701@iee.org> <404396ef0803100829h44c8ac1dg4ee6f0132cb4f929@mail.gmail.com> <47D56B7A.2030200@iee.org> <220e47b40803101207w6d4bb795k68d959b3ccff9849@mail.gmail.com> <47D5A46A.5010800@iee.org> <404396ef0803101433s435bbc64j46617fe50ba46aa5@mail.gmail.com> <47D63C44.7070704@iee.org> <47D8345A.9000201@iee.org> <47D8F442.40704@iee.org> <47D9F59A.2080703@cse.unsw.edu.au> <795738AA-4A33-4A70-A325-318E10357A5E@strictlypositive.org> <47DA8881.9070806@cse.unsw.edu.au> Message-ID: <47DDCB24.1050107@cse.unsw.edu.au> apfelmus wrote: > Roman Leshchinskiy wrote: >> Should the report say something like "a valid Eq instance must ensure >> that x == y implies f x == f y for all f"? >> Probably not, since this requires structural equality which is not >> what you want for ADTs. Should it be "for all f which are not part of >> the implementation of the type"? That's a non-requirement if the >> report doesn't specify what the "implementation" is. So what should it >> say? > > "for all exported f" This forces me to confine the implementation of my ADT to a single module instead of a package. Also (just to be nitpicky :-), it doesn't deal with methods of classes of which my ADT is an instance since I don't export those. It's quite interesting that so far in this discussion, nobody seems to have to come up with a clear and practically useful (in this context, of course) definition of observation. I suspect that this is because in practice, we can and, more importantly, want to observe a lot more than in theory. For instance, something like serialisation usually wouldn't even be mentioned in a theoretical paper about a data structure but is absolutely necessary for writing actual programs. >> If the representation is stored on the disk, for instance, then it >> becomes observable, even if it's still hidden in the sense that you >> can't do anything useful with it other than read it back. > > The trick here is to blame any observable differences on the > nondeterminism of the IO monad > > serialize :: MyADT -> IO String > > It only guarantees to print out a "random" representation. Of course, in > reality, serialize just prints the internal representation at hand, but > we may not know that. Hmm, I understand what you're saying but... So we go to all the trouble of placing quite severe restrictions on (==) and now we can't even rely on them when reasoning about effects? Also, this requires that I artificially embed my perfectly pure serialisation function in IO. This doesn't really make reasoning about it easier but ultimately, isn't that what this is all about? Roman From chak at cse.unsw.edu.au Sun Mar 16 22:34:38 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Sun Mar 16 22:31:31 2008 Subject: [Haskell-cafe] type families, fun deps, lattices imposed on/by types In-Reply-To: <470880360803161249s6dd5a8c2m79cdb3a73412a5a8@mail.gmail.com> References: <470880360803161249s6dd5a8c2m79cdb3a73412a5a8@mail.gmail.com> Message-ID: <961358DE-AEDA-4581-9B8E-0E26D5AE8263@cse.unsw.edu.au> Isto Aho: > Please, consider the example 03 of "Understanding functional > dependencies > via Constraint Handling rules" by Sulzmann, Duck, Peyton-Jones and > Stuckey. > > There we are defining a multiplication over different numeric types: > class Mul a b c | a b -> c where > (*) :: a -> b -> c > instance Mul Int Int Int where ... > instance Mul Int Float Float where ... > > Ok, we could add > instance Mul Float Int Float where ... > > but if we want to make everything work nicely together, Integer, > Complex, > Rational etc, there will be a lot of instances, especially if we > have to give > both "Float Int" and "Int Float" instances. > > And now the question on "lattices of types" (didn't know any better > name > to refer to the following): > Is the following possible? Or can something similar achieved with > type families (easily)? > > type lattice T a b > -- Each of the following gives a "<"-relation between types, > -- "upper" gives a method, how we get the larger (2nd) from > -- the smaller (1st). > lattice instance T Int Integer where upper = fromIntegral > lattice instance T Int Float where upper = fromIntegral > lattice instance T Integer (Ratio Integer) where upper = ... > lattice instance T (Ratio Integer) Double where ... > lattice instance T Float Double ... > lattice instance T Double (Complex Double) ... > > -- e.g. Now the compiler can check that the top type is > -- unique and that there is a path from every type to the top type. > -- If the compiler founds this not to be the case, an error is output. > -- But otherwise there can be types that are not comparable but > -- the common top is quaranteed to exist. > > class Mul a b c where > lattice T > (*) :: a -> b -> c > (*) x y = (upper x y x) * (upper x y y) > -- Now there is no need for the instances like. > instance Mul Int Float Float where ... > instance Mul Float (Ratio Integer) Double where ... In the definition, the upper function only has one argument... > The compiler can generate those instances, because we have given > the "upper"-methods. There is always the top available. > Function > (*) x y = (upper x y x) * (upper x y y) > might could be replaced with > (*) x y = x * y > because of the presence of lattice T and thus, the "upper"-function. > > > If this were possible, the benefits would be: > - No need to state "Int Float" and "Float Int" instances on cases > where the operands do commute. > - No need to write a large number of instances if you have several > "types on lattice" (e.g. some more or less well defined relation). > - If the relation between types is not clear, we could define another > lattice T2 to our Mul2 class for the other uses. > > Continuing the idea: we could override the default instances generated > by the compiler with our own instances when needed. > > > Ok, so, is it possible to write something like that already? (I just > wouldn't like write a lot of instances...) If not, would it be > possible to extend, say ghc, to work that way or are there too much > inconsistencies in the above presentation? Using your idea of separating the lattice and conversion from the definition of multiplication, you can at least save yourself the class instances: {-# LANGUAGE TypeFamilies, MultiParamTypeClasses #-} {-# LANGUAGE FlexibleContexts, FlexibleInstances, UndecidableInstances #-} type family Join a b :: * type instance Join Int Int = Int type instance Join Float Float = Float type instance Join Int Float = Float type instance Join Float Int = Float class Conv a b where conv :: a -> b instance Conv Int Float where conv = fromIntegral instance Conv Int Int where conv = id instance Conv Float Float where conv = id class Mul a b where mul :: a -> b -> Join a b instance (Conv a (Join a b), Conv b (Join a b), Num (Join a b)) => Mul a b where mul x y = conv x * conv y You will have to write quite a lot of type instances of Join. However, the rest of the code is as concise as you seem to want it. You could even do better with Join by using more sophisticated type- level data structures; i.e., you could define type-level association lists and define Join as a type-level lookup function, including rules for reflexivity and symmetry, on those lists. In other words, instead of hard-coding the laws of lattices into the compiler, you'd just programatically define them as part of your type-level program. This is more flexible, as I am sure there are other applications, where we don't want a lattice, but some other structure. See also Andrew Appleyard's recent BSc thesis on how a similar approach can be used to embed the type structure of a different programming language in Haskell. In his case, this was the subtyping relation of C#: http://www.cse.unsw.edu.au/~pls/thesis/aja-thesis.pdf Manuel PS: The use of UndecidableInstances in the above code is a bit unfortunate, but it is forced on us by the rather complicated instance context of Mul (even if the above set of family and class instances is of course perfectly decidable - GHC just can't tell that easily). From ashley at semantic.org Sun Mar 16 22:37:58 2008 From: ashley at semantic.org (Ashley Yakeley) Date: Sun Mar 16 22:34:49 2008 Subject: [Haskell-cafe] Re: "GADT" rhymes with "cat" In-Reply-To: <47DDC2ED.1030400@appsolutions.com> References: <47DDC2ED.1030400@appsolutions.com> Message-ID: <47DDD986.3020703@semantic.org> Anton van Straaten wrote: > Those who believe that GADTs are unnecessary might appreciate the > guttural pronunciation of "gat": which is something like "chut" where > the "ch" is similar to that in "loch", and for good measure, it rhymes > with "slut" (at least in Afrikaans). It lends itself well to being > uttered contemptuously. Who thinks GADTs are unnecessary, and why? -- Ashley Yakeley From chak at cse.unsw.edu.au Sun Mar 16 22:43:12 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Sun Mar 16 22:40:05 2008 Subject: [Haskell-cafe] problem with type equality constraints In-Reply-To: References: Message-ID: <7B454D5B-AE18-4E47-BC88-2867378CDD79@cse.unsw.edu.au> Ganesh Sittampalam: > When I try to compile this code with ghc-6.9.20080310: > > module Test2 where > > type family Id a > type instance Id Int = Int > type instance Id (a, b) = (Id a, Id b) > > class Id a ~ ida => Foo a ida > > instance Foo Int Int > instance (Foo a ida, Foo b idb) => Foo (a, b) (ida, idb) > > I get these errors: > > Test2.hs:12:0: > Couldn't match expected type `ida' against inferred type `Id a' > `ida' is a rigid type variable bound by > the instance declaration at Test2.hs:12:16 > When checking the super-classes of an instance declaration > In the instance declaration for `Foo (a, b) (ida, idb)' > > Test2.hs:12:0: > Couldn't match expected type `idb' against inferred type `Id b' > `idb' is a rigid type variable bound by > the instance declaration at Test2.hs:12:27 > When checking the super-classes of an instance declaration > In the instance declaration for `Foo (a, b) (ida, idb)' > > It seems to me that since Foo a ida and Foo b idb are superclassess, > Id a ~ ida and Id b ~ idb should be known and so this should have > worked - am I missing something? Your are completely right. Unfortunately, superclass equalities (ie, the Id a ~ ida in the class declaration of Foo) aren't fully implemented yet. If I am not mistaken, superclass equalities, class defaults for associated type families, and GADT data instances are the three major features of type families/equality constraint saga that aren't fully implemented yet. Manuel From anton at appsolutions.com Sun Mar 16 23:18:20 2008 From: anton at appsolutions.com (Anton van Straaten) Date: Sun Mar 16 23:05:46 2008 Subject: [Haskell-cafe] Re: "GADT" rhymes with "cat" In-Reply-To: <47DDD986.3020703@semantic.org> References: <47DDC2ED.1030400@appsolutions.com> <47DDD986.3020703@semantic.org> Message-ID: <47DDE2FC.20904@appsolutions.com> Ashley Yakeley wrote: > Anton van Straaten wrote: >> Those who believe that GADTs are unnecessary might appreciate the >> guttural pronunciation of "gat": which is something like "chut" where >> the "ch" is similar to that in "loch", and for good measure, it rhymes >> with "slut" (at least in Afrikaans). It lends itself well to being >> uttered contemptuously. > > Who thinks GADTs are unnecessary, and why? I was thinking of this: http://lambda-the-ultimate.org/node/2692 and this: http://article.gmane.org/gmane.comp.lang.haskell.general/14764 These links may give some clues as to "who", but I wasn't really thinking of anyone in particular. Anton From agl at imperialviolet.org Sun Mar 16 23:40:41 2008 From: agl at imperialviolet.org (Adam Langley) Date: Sun Mar 16 23:37:32 2008 Subject: [Haskell-cafe] GHC threaded RTS will call the finaliser of a ForeignPtr while references still exist Message-ID: <396556a20803162040h5ef62d35x94a24dcafca2c883@mail.gmail.com> I believe that I've managed to distill a crash which has been driving me crazy for a few days into a short enough test case (22 lines) that it might be useful. In short: the threaded RTS will call the finialiser of a ForeignPtr while an exception handler still holds a reference to it: % ghc -make fptest.hs cbits.c -threaded [1 of 1] Compiling Main ( fptest.hs, fptest.o ) Linking fptest ... % ./fptest New object getting created: 66f010 Finaliser getting called for 66f010 Use called for 66f010 cbits.c: http://hpaste.org/6420 fptest.hs: http://hpaste.org/6421 I'm hoping that this is useful to someone who knows the RTS. Cheers, -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org From agl at imperialviolet.org Sun Mar 16 23:42:43 2008 From: agl at imperialviolet.org (Adam Langley) Date: Sun Mar 16 23:39:33 2008 Subject: [Haskell-cafe] Re: GHC threaded RTS will call the finaliser of a ForeignPtr while references still exist In-Reply-To: <396556a20803162040h5ef62d35x94a24dcafca2c883@mail.gmail.com> References: <396556a20803162040h5ef62d35x94a24dcafca2c883@mail.gmail.com> Message-ID: <396556a20803162042h53a5923bl3d99186b4bdec8d1@mail.gmail.com> On Sun, Mar 16, 2008 at 8:40 PM, Adam Langley wrote: > I believe that I've managed to distill a crash which has been driving > me crazy for a few days into a short enough test case (22 lines) that > it might be useful. Cale made a suggestion which shortens it: fptest.hs: http://hpaste.org/6423 -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org From dons at galois.com Sun Mar 16 23:45:07 2008 From: dons at galois.com (Don Stewart) Date: Sun Mar 16 23:42:00 2008 Subject: [Haskell-cafe] GHC threaded RTS will call the finaliser of a ForeignPtr while references still exist In-Reply-To: <396556a20803162040h5ef62d35x94a24dcafca2c883@mail.gmail.com> References: <396556a20803162040h5ef62d35x94a24dcafca2c883@mail.gmail.com> Message-ID: <20080317034507.GA5479@scytale.galois.com> agl: > I believe that I've managed to distill a crash which has been driving > me crazy for a few days into a short enough test case (22 lines) that > it might be useful. > > In short: the threaded RTS will call the finialiser of a ForeignPtr > while an exception handler still holds a reference to it: > > > % ghc -make fptest.hs cbits.c -threaded > [1 of 1] Compiling Main ( fptest.hs, fptest.o ) > Linking fptest ... > % ./fptest > New object getting created: 66f010 > Finaliser getting called for 66f010 > Use called for 66f010 > > > cbits.c: http://hpaste.org/6420 > fptest.hs: http://hpaste.org/6421 > > I'm hoping that this is useful to someone who knows the RTS. Create a ticket on the bug tracker, and I'm sure Ian or Simon M will have a look at it. http://hackage.haskell.org/trac/ghc/newticket?type=bug -- Don From agl at imperialviolet.org Sun Mar 16 23:55:45 2008 From: agl at imperialviolet.org (Adam Langley) Date: Sun Mar 16 23:52:36 2008 Subject: [Haskell-cafe] GHC threaded RTS will call the finaliser of a ForeignPtr while references still exist In-Reply-To: <20080317034507.GA5479@scytale.galois.com> References: <396556a20803162040h5ef62d35x94a24dcafca2c883@mail.gmail.com> <20080317034507.GA5479@scytale.galois.com> Message-ID: <396556a20803162055q730835cfw9261b9d27e5fe648@mail.gmail.com> On Sun, Mar 16, 2008 at 8:45 PM, Don Stewart wrote: > Create a ticket on the bug tracker, and I'm sure Ian or Simon M will have a look at it. > > http://hackage.haskell.org/trac/ghc/newticket?type=bug Done, thanks: http://hackage.haskell.org/trac/ghc/ticket/2161 AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org From pasalic at cs.rice.edu Mon Mar 17 00:39:32 2008 From: pasalic at cs.rice.edu (Emir Pasalic) Date: Mon Mar 17 00:36:26 2008 Subject: [Haskell-cafe] Re: "GADT" rhymes with "cat" In-Reply-To: <47DDE2FC.20904@appsolutions.com> References: <47DDC2ED.1030400@appsolutions.com> <47DDD986.3020703@semantic.org> <47DDE2FC.20904@appsolutions.com> Message-ID: <798BA697-F4AD-4F57-889E-C5593BF23FB3@cs.rice.edu> And is the plural 'gatte'? :) On Mar 16, 2008, at 11:18 PM, Anton van Straaten wrote: > Ashley Yakeley wrote: >> Anton van Straaten wrote: >>> Those who believe that GADTs are unnecessary might appreciate the >>> guttural pronunciation of "gat": which is something like "chut" >>> where the "ch" is similar to that in "loch", and for good measure, >>> it rhymes with "slut" (at least in Afrikaans). It lends itself >>> well to being uttered contemptuously. >> Who thinks GADTs are unnecessary, and why? > > I was thinking of this: > > http://lambda-the-ultimate.org/node/2692 > > and this: > > http://article.gmane.org/gmane.comp.lang.haskell.general/14764 > > These links may give some clues as to "who", but I wasn't really > thinking of anyone in particular. > > Anton > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From anton at appsolutions.com Mon Mar 17 01:28:03 2008 From: anton at appsolutions.com (Anton van Straaten) Date: Mon Mar 17 01:15:30 2008 Subject: [Haskell-cafe] Re: "GADT" rhymes with "cat" In-Reply-To: <798BA697-F4AD-4F57-889E-C5593BF23FB3@cs.rice.edu> References: <47DDC2ED.1030400@appsolutions.com> <47DDD986.3020703@semantic.org> <47DDE2FC.20904@appsolutions.com> <798BA697-F4AD-4F57-889E-C5593BF23FB3@cs.rice.edu> Message-ID: <47DE0163.6050703@appsolutions.com> Emir Pasalic wrote: > And is the plural 'gatte'? :) Indeed! Many a sports fan backing the wrong team at the wrong time has been told something like "Ons het julle gatte lekker geskop", which is Afrikaans for "We kicked your asses good". > On Mar 16, 2008, at 11:18 PM, Anton van Straaten wrote: > >> Ashley Yakeley wrote: >>> Anton van Straaten wrote: >>>> Those who believe that GADTs are unnecessary might appreciate the >>>> guttural pronunciation of "gat": which is something like "chut" >>>> where the "ch" is similar to that in "loch", and for good measure, >>>> it rhymes with "slut" (at least in Afrikaans). It lends itself well >>>> to being uttered contemptuously. >>> Who thinks GADTs are unnecessary, and why? >> >> I was thinking of this: >> >> http://lambda-the-ultimate.org/node/2692 >> >> and this: >> >> http://article.gmane.org/gmane.comp.lang.haskell.general/14764 >> >> These links may give some clues as to "who", but I wasn't really >> thinking of anyone in particular. >> >> Anton >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe > From ryani.spam at gmail.com Mon Mar 17 04:47:04 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Mon Mar 17 04:43:54 2008 Subject: [Haskell-cafe] QuickCheck In-Reply-To: <3d96ac180803161127o51fcdf50u9b966a2f88b90315@mail.gmail.com> References: <3d96ac180803161127o51fcdf50u9b966a2f88b90315@mail.gmail.com> Message-ID: <2f9b2d30803170147r3d4fd49ckd67d0fe2e7cab4e9@mail.gmail.com> 2008/3/16 Sebastian Sylvan : > featureGenNormal = do > id <- stringGen > name <- stringGen > featuretype <- arbitrary > grouptype <- arbitrary > children <- arbitrary > properties <- listGen stringGen > return (Feature id name featuretype grouptype children properties) > > > Note that we use "arbitrary" to generate the list of children recursively. Also, you can shorten this significantly with liftM or ap (from Control.Monad): > featureGenNormal = liftM6 Feature stringGen stringGen arbitrary arbitrary arbitrary (listGen stringGen) > featureGenNormal = return Feature `ap` stringGen `ap` stringGen `ap` arbitrary `ap` arbitrary `ap` listGen stringGen From kolar at fit.vutbr.cz Mon Mar 17 05:28:44 2008 From: kolar at fit.vutbr.cz (Dusan Kolar) Date: Mon Mar 17 05:23:52 2008 Subject: [Haskell-cafe] Building HaXML 1.13.3 on Windows fails Message-ID: <47DE39CC.1040409@fit.vutbr.cz> Hello all, I'm trying to build HaXML 1.13.3 on Windows using build.bat - I have modified it even on places referred as "should work" (SRCS and OBJS variables); now it works till the last command: ghc-pkg register pkg.conf The error is: Reading package info from "pkg.conf" ... ghc-pkg.exe: Line 68: The field main-is was already defined on line 62 Taking a look into the pkg.conf says there are several lines main-is. I'm using ghc 6.6 to build the stuff. What shall I do? Thanks and regards, Dusan From vitaliy.akimov at gmail.com Mon Mar 17 05:29:01 2008 From: vitaliy.akimov at gmail.com (Vitaliy Akimov) Date: Mon Mar 17 05:25:50 2008 Subject: [Haskell-cafe] Re: all threads are blocked by recvFrom In-Reply-To: <396556a20803141013w6ba1271bjc2ea1bbd9c80b729@mail.gmail.com> References: <396556a20803140757w1ac429e3q6655078e30961a4e@mail.gmail.com> <396556a20803141013w6ba1271bjc2ea1bbd9c80b729@mail.gmail.com> Message-ID: Hi Adam, sorry for late answer. Here is my example [1], but yours doesn't work on my PC too. And it's strange it works on yours. According to documentation for Control.Concurrent module [2] every other thread should be blocked. > With the -threaded option, only foreign calls with the unsafe attribute will block all other threads. And after changing in the network package FFI declaration for c_recvfrom from unsafe to safe both examples start working. There are two solutions I see now. The first is to copy-paste definitions from the network package to mine with changing "unsafe" to "safe" for FFI declaration. The second is to use unblocking sockets. This by the way will help to get rid of hack-like solution of stopping server by closing listening socket, but it will get more effort. [1] http://hpaste.org/6426 [2] http://haskell.org/ghc/docs/latest/html/libraries/base/Control-Concurrent.html#4 2008/3/14, Adam Langley : > On Fri, Mar 14, 2008 at 8:51 AM, Vitaliy Akimov > > wrote: > > > > I assume that you're binding the libc function directly here: > > > > I'm using Network.Socket. Sory if it's not clear from my previous posts. > > > Then everything should Just Work(tm). You might need to paste in code > in order to figure out why this wouldn't be so. > > See [1] for an example which works for me. It starts a thread which > prints "working..." once a second and, in another thread, listens for > UDP packets on port 4112. I can use `nc -u 127.0.0.1 4112` to get > this: > "working..." > "working..." > ("testing\n",8,127.0.0.1:36179) > "working..." > "working..." > ("testing two\n",12,127.0.0.1:36179) > "working..." > > > > [1] http://hpaste.org/6362 > > > -- > Adam Langley agl@imperialviolet.org http://www.imperialviolet.org > From Malcolm.Wallace at cs.york.ac.uk Mon Mar 17 06:20:13 2008 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Mon Mar 17 06:22:08 2008 Subject: [Haskell-cafe] Building HaXML 1.13.3 on Windows fails In-Reply-To: <47DE39CC.1040409@fit.vutbr.cz> References: <47DE39CC.1040409@fit.vutbr.cz> Message-ID: <20080317102013.0946d777.Malcolm.Wallace@cs.york.ac.uk> Dusan Kolar wrote: > I'm trying to build HaXML 1.13.3 on Windows using build.bat > > $ ghc-pkg register pkg.conf > Reading package info from "pkg.conf" ... ghc-pkg.exe: Line 68: The > field main-is was already defined on line 62 > > Taking a look into the pkg.conf says there are several lines main-is. > I'm using ghc 6.6 to build the stuff. What shall I do? Try deleting all of the executable stanzas from the pkg.conf file. When the library is being registered with ghc, these are not needed anyway. (I am not sure why ghc-pkg-6.6 rejects them, rather than ignoring them.) Regards, Malcolm From gale at sefer.org Mon Mar 17 06:30:26 2008 From: gale at sefer.org (Yitzchak Gale) Date: Mon Mar 17 06:27:14 2008 Subject: [Haskell-cafe] QuickCheck In-Reply-To: <2f9b2d30803170147r3d4fd49ckd67d0fe2e7cab4e9@mail.gmail.com> References: <3d96ac180803161127o51fcdf50u9b966a2f88b90315@mail.gmail.com> <2f9b2d30803170147r3d4fd49ckd67d0fe2e7cab4e9@mail.gmail.com> Message-ID: <2608b8a80803170330j5015f3bbwd65203064d9e38cb@mail.gmail.com> Sebastian Sylvan: >> featureGenNormal = do >> id <- stringGen >> name <- stringGen >> featuretype <- arbitrary >> grouptype <- arbitrary >> children <- arbitrary >> properties <- listGen stringGen >> return (Feature id name featuretype grouptype children properties) Ryan Ingram wrote: > Also, you can shorten this significantly with liftM or ap (from Control.Monad): True, but in this case I like being able to see meaningful names for each parameter of the constructor. From rodrigo.bonifacio at uol.com.br Mon Mar 17 09:37:59 2008 From: rodrigo.bonifacio at uol.com.br (rodrigo.bonifacio) Date: Mon Mar 17 09:34:53 2008 Subject: [Haskell-cafe] QuickCheck Message-ID: Hi all, Is it possible to define a limit for the size of children list bellow? I've tried: children <- resize (10 (listGen featureGenNormal)) But it didn't work. Thanks a lot, Rodrigo. > Sebastian Sylvan: > >> featureGenNormal = do > >> id <- stringGen > >> name <- stringGen > >> featuretype <- arbitrary > >> grouptype <- arbitrary > >> children <- arbitrary > >> properties <- listGen stringGen > >> return (Feature id name featuretype grouptype children properties) > > Ryan Ingram wrote: > > Also, you can shorten this significantly with liftM or ap (from Control.Monad): > > True, but in this case I like being able to see meaningful > names for each parameter of the constructor. > ----------------------------------- Rodrigo Bonif?cio de Almeida Universidade Cat?lica de Bras?lia - Grupo de Engenharia de Software - JavaComBr (www.ucb.br/java) From lemming at henning-thielemann.de Mon Mar 17 09:42:38 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon Mar 17 09:38:14 2008 Subject: [Haskell-cafe] QuickCheck In-Reply-To: References: Message-ID: On Mon, 17 Mar 2008, rodrigo.bonifacio wrote: > Hi all, > > Is it possible to define a limit for the size of children list bellow? take 10 ? From nominolo at googlemail.com Mon Mar 17 09:54:28 2008 From: nominolo at googlemail.com (Thomas Schilling) Date: Mon Mar 17 09:51:27 2008 Subject: [Haskell-cafe] QuickCheck In-Reply-To: References: Message-ID: <889A6052-52B7-403E-A335-C8FC6A1F2A72@googlemail.com> On 17 mar 2008, at 14.37, rodrigo.bonifacio wrote: > Hi all, > > Is it possible to define a limit for the size of children list bellow? > > I've tried: > > children <- resize (10 (listGen featureGenNormal)) >> You are calling a number as a function. Also, listGen has to use the size argument. Try something like (not tested): listGen = sized (\maxSize -> do n <- arbitrary x <- g xs <- frequency [ (1, return []), (n, listGen g) ] return (x:xs) From maverick_as_2000 at yahoo.es Mon Mar 17 09:58:17 2008 From: maverick_as_2000 at yahoo.es (Maverick) Date: Mon Mar 17 09:55:05 2008 Subject: [Haskell-cafe] Re: Haskell-Cafe Digest, Vol 55, Issue 20 Message-ID: <656318.67804.qm@web33407.mail.mud.yahoo.com> Thanks Sterl, you're right, this was because I have don?t compiled with the -threaded flag, this works fine now. > This answer may be way off base, but if differences appear between > ghci and compiled versions, I've often found its as simple as > remembering to compile with the -threaded flag. The ghci runtime is > threaded by default, as I understand it, while compiled binaries are > not, and IO operations will block in very different fashions (i.e. in > their own thread, or stalling the entire app) depending on the runtime. > Regards, > sterl. Alvaro ______________________________________________ ?Con Mascota por primera vez? S? un mejor Amigo. Entra en Yahoo! Respuestas http://es.answers.yahoo.com/info/welcome -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080317/7dbff319/attachment.htm From niklas.broberg at gmail.com Mon Mar 17 10:06:44 2008 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Mon Mar 17 10:09:42 2008 Subject: [Haskell-cafe] Re: ANN: haskell-src-exts 0.3.2 In-Reply-To: References: Message-ID: > I'm pleased to announce a new release for the haskell-src-exts package. Twice in two days even. :-) haskell-src-exts 0.3.3 - now with support for type equality constraints. cabal sdist: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/haskell-src-exts-0.3.3 darcs repo: http://code.haskell.org/HSP/haskell-src-exts Cheers, /Niklas > > haskell-src-exts 0.3.2 > =========================== > > haskell-src-exts is a package for handling and manipulating Haskell > source code. It is based on the haskell-src package that is part of > the standard libraries, but extends this to support a number of > syntactic extensions, e.g. MPTCs, fundeps, GADTs, TH etc. It is > intended as a drop-in replacement for the standard haskell-src > package, and exports the same functions and data types, plus some > more. > > Apart from the more standard extensions supported by e.g. GHC, > haskell-src-exts also provides support for HaRP (Haskell Regular > Patterns) and HSX (Haskell Source with XML) syntax. > > Note that as of 0.3, haskell-src-exts /= HSX. > > * cabal sdist: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/haskell-src-exts-0.3.2 > * darcs repo: darcs get http://code.haskell.org/HSP/haskell-src-exts > > > === Changes from 0.2: === > > * Added support for > - Indexed type families (including associated types/datatypes) > - Explicit kind signatures > - Standalone deriving > > * haskell-src-exts is now decoupled from hsx/trhsx and harp. > - Modules renamed to Language.Haskell.Exts.* > - Module Transform is removed from the package (now in package hsx) > > * New repository (i.e. darcs pull in an old repo won't work, use darcs > get), containing only the haskell-src-exts package (no hsx or harp). > > * Builds with 6.8.2 (thanks Duncan Coutts) > > > === Complete list of supported extensions === > > * Multi-parameter type classes (MPTCs) > * Functional dependencies > * Associated types, indexed type families > * Liberal class and instance heads > * Implicit parameters > * Explicit kind signatures > * Pattern guards > * Generalized algebraic data types (GADTs) > * Template Haskell (TH) > * Universal and existential quantification (forall) > * Empty data type declarations > * Unboxed tuples (# #) > * Standalone deriving > * Regular patterns > * Haskell XML, HSX style > > > === Build Requirements === > > * happy >= 1.17 > - It might work with 1.16 though I haven't tested. In that case > change the cabal file. > - It would work with older versions as well, though they insert a > dependency on Array (haskell98) instead of Data.Array. If that's all > you have to work with, update the cabal file with a dependency on > haskell98. > > * Cabal >= 1.2 > > > Patches are more than welcome. :-) > > Cheers, > > > /Niklas > From jgbailey at gmail.com Mon Mar 17 11:52:08 2008 From: jgbailey at gmail.com (Justin Bailey) Date: Mon Mar 17 11:48:57 2008 Subject: [Haskell-cafe] 2-level type analysis of introducing naming into data types In-Reply-To: <5de3f5ca0803150020s65d3a63pdebf66a77f24ef9@mail.gmail.com> References: <5de3f5ca0803150020s65d3a63pdebf66a77f24ef9@mail.gmail.com> Message-ID: 2008/3/15 Greg Meredith : > All, > > > The following Haskell code gives a 2-level type analysis of a > functorial approach to introducing naming and name management into a > given (recursive) data type. The analysis is performed by means of an What's the upshot of this? That is, what does this analysis give you? I mostly follow the argument but I don't understand the benefits. I feel like I'm missing something. Justin From jgbailey at gmail.com Mon Mar 17 11:55:06 2008 From: jgbailey at gmail.com (Justin Bailey) Date: Mon Mar 17 11:51:59 2008 Subject: [Haskell-cafe] Network.Browser and getCookies In-Reply-To: <1B8811DF-4BA5-4B15-8097-BFD266C8DBE0@gmail.com> References: <1B8811DF-4BA5-4B15-8097-BFD266C8DBE0@gmail.com> Message-ID: On Sun, Mar 16, 2008 at 10:21 AM, Adam Smyczek wrote: > Somehow I cannot get cookies from the Response > using Network.Browser module (HTTP 3001.0.4). > The cookie header part seams to be empty and > getCookies returns empty list as well. Network.Browser comes with a built-in HTTP trace facility - I'd first make sure you are getting the HTTP responses you expect. I believe it's setErrHandler and setDebugHandler - use putStrLn to get a trace of HTTP traffic on your console. Justin From ryani.spam at gmail.com Mon Mar 17 12:34:39 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Mon Mar 17 12:31:28 2008 Subject: [Haskell-cafe] Need Cabal/library building help for windows Message-ID: <2f9b2d30803170934k14a5fe5hb2699eab6a51af77@mail.gmail.com> For reference, I'm using GHC6.8.1 on WinXP. I'm trying to package up some code into a library. But cabal fails to configure my project: >runhaskell setup.hs configure Configuring Prompt-1.0... setup.hs: ld is required but it could not be found. Prompt.cabal contains: name: Prompt version: 1.0 cabal-version: >= 1.2 build-type: Simple library exposed-modules: Control.Monad.Prompt Does GHC require additional tools in order to build libraries on Win32? If so, I hope this can be remedied; it builds executables without additional tools after all. What do I need to do next? -- ryan From daveroundy at gmail.com Mon Mar 17 12:59:09 2008 From: daveroundy at gmail.com (David Roundy) Date: Mon Mar 17 12:56:00 2008 Subject: [Haskell-cafe] floating point operations and representation In-Reply-To: <20080313012759.GA11389@scytale.galois.com> References: <8e47d1720803121735j17343d57x49fff089123f889b@mail.gmail.com> <20080313012759.GA11389@scytale.galois.com> Message-ID: <117f2cc80803170959v1c80eb18v625c8fd747de3aaf@mail.gmail.com> On Wed, Mar 12, 2008 at 9:27 PM, Don Stewart wrote: > You could consider binding directly to the C functions, if needed, > > {-# OPTIONS -fffi -#include "math.h" #-} > > import Foreign.C.Types > > foreign import ccall unsafe "math.h log10" > c_log10 :: CDouble -> CDouble > > log10 :: Double -> Double > log10 x = realToFrac (c_log10 (realToFrac x)) Actually, you could almost certainly just use foreign import ccall unsafe "math.h log10" log10 :: Double -> Double since in ghc CDouble and Double are identical. It's a bit sloppier, but shouldn't cause any trouble. And I've no idea how realToFrac is implemented, but would worry about it behaving oddly... for instance when given NaNs. David From bulat.ziganshin at gmail.com Mon Mar 17 13:06:39 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Mon Mar 17 13:03:27 2008 Subject: [Haskell-cafe] floating point operations and representation In-Reply-To: <117f2cc80803170959v1c80eb18v625c8fd747de3aaf@mail.gmail.com> References: <8e47d1720803121735j17343d57x49fff089123f889b@mail.gmail.com> <20080313012759.GA11389@scytale.galois.com> <117f2cc80803170959v1c80eb18v625c8fd747de3aaf@mail.gmail.com> Message-ID: <1642791339.20080317200639@gmail.com> Hello David, Monday, March 17, 2008, 7:59:09 PM, you wrote: >> foreign import ccall unsafe "math.h log10" >> c_log10 :: CDouble -> CDouble >> >> log10 :: Double -> Double >> log10 x = realToFrac (c_log10 (realToFrac x)) > It's a bit sloppier, but shouldn't cause any trouble. And I've no > idea how realToFrac is implemented, but would worry about it behaving > oddly... for instance when given NaNs. it should be nop (no operation) in such cases -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From agl at imperialviolet.org Mon Mar 17 13:06:54 2008 From: agl at imperialviolet.org (Adam Langley) Date: Mon Mar 17 13:03:44 2008 Subject: [Haskell-cafe] Re: all threads are blocked by recvFrom In-Reply-To: References: <396556a20803140757w1ac429e3q6655078e30961a4e@mail.gmail.com> <396556a20803141013w6ba1271bjc2ea1bbd9c80b729@mail.gmail.com> Message-ID: <396556a20803171006k3d84e585l735a4403894966cf@mail.gmail.com> On Mon, Mar 17, 2008 at 2:29 AM, Vitaliy Akimov wrote: > Hi Adam, sorry for late answer. Here is my example [1], but yours > doesn't work on my PC too. And it's strange it works on yours. Are you running Windows? Because you're hpaste example works, nonblocking for me too. > And after changing in the network package FFI declaration for > c_recvfrom from unsafe to safe both examples start working. The important point here is that the recvFrom calls in Network.Socket[1] don't block. They are non-blocking calls so, although other threads may be suspended while in the FFI call, the FFI call returns -EAGAIN if it would block and blocking is passed to the RTS to handle. While sleeping in the RTS (with threadWaitRead etc), other Haskell threads can read. See the code in [1] (esp throwErrnoIfMinus1Retry_repeatOnBlock) So, the only reason that other threads would be blocked is if the socket wasn't marked as non-blocking. Here's a snippet of strace output from compiling your hpaste example: socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 5 fcntl64(5, F_GETFL) = 0x2 (flags O_RDWR) fcntl64(5, F_SETFL, O_RDWR|O_NONBLOCK) = 0 You can see that the socket is set to non-blocking immediately. [1] http://haskell.org/ghc/docs/latest/html/libraries/network/src/Network-Socket.html#recvFrom -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org From jed at 59A2.org Mon Mar 17 13:25:53 2008 From: jed at 59A2.org (Jed Brown) Date: Mon Mar 17 13:22:30 2008 Subject: [Haskell-cafe] floating point operations and representation In-Reply-To: <1642791339.20080317200639@gmail.com> (Bulat Ziganshin's message of "Mon, 17 Mar 2008 20:06:39 +0300") References: <8e47d1720803121735j17343d57x49fff089123f889b@mail.gmail.com> <20080313012759.GA11389@scytale.galois.com> <117f2cc80803170959v1c80eb18v625c8fd747de3aaf@mail.gmail.com> <1642791339.20080317200639@gmail.com> Message-ID: <87tzj5l0ta.fsf@59A2.org> On 17 Mar 2008, bulat.ziganshin@gmail.com wrote: > Hello David, > > Monday, March 17, 2008, 7:59:09 PM, you wrote: > >>> foreign import ccall unsafe "math.h log10" >>> c_log10 :: CDouble -> CDouble >>> >>> log10 :: Double -> Double >>> log10 x = realToFrac (c_log10 (realToFrac x)) > >> It's a bit sloppier, but shouldn't cause any trouble. And I've no >> idea how realToFrac is implemented, but would worry about it behaving >> oddly... for instance when given NaNs. > > it should be nop (no operation) in such cases A related issue: http://hackage.haskell.org/trac/ghc/ticket/2110 Presumably everyone is aware of decodeFloat :: (RealFloat a) => a -> (Integer, Int) which really is a canonical representation of a floating point number. As for realToFrac, this really isn't okay: *GHCi> 0/0 NaN *GHCi> realToFrac (0/0) -Infinity Also, this one might surprise a few people. *GHCi> realToFrac (realToFrac 0.2 :: Ratio Int) -Infinity *GHCi> realToFrac 0.2 :: Ratio Int (-858993459)%0 Jed -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080317/cf8afe52/attachment.bin From dons at galois.com Mon Mar 17 13:28:10 2008 From: dons at galois.com (Don Stewart) Date: Mon Mar 17 13:25:02 2008 Subject: [Haskell-cafe] floating point operations and representation In-Reply-To: <117f2cc80803170959v1c80eb18v625c8fd747de3aaf@mail.gmail.com> References: <8e47d1720803121735j17343d57x49fff089123f889b@mail.gmail.com> <20080313012759.GA11389@scytale.galois.com> <117f2cc80803170959v1c80eb18v625c8fd747de3aaf@mail.gmail.com> Message-ID: <20080317172810.GA7364@scytale.galois.com> daveroundy: > On Wed, Mar 12, 2008 at 9:27 PM, Don Stewart wrote: > > You could consider binding directly to the C functions, if needed, > > > > {-# OPTIONS -fffi -#include "math.h" #-} > > > > import Foreign.C.Types > > > > foreign import ccall unsafe "math.h log10" > > c_log10 :: CDouble -> CDouble > > > > log10 :: Double -> Double > > log10 x = realToFrac (c_log10 (realToFrac x)) > > Actually, you could almost certainly just use > > foreign import ccall unsafe "math.h log10" log10 :: Double -> Double > > since in ghc CDouble and Double are identical. > > It's a bit sloppier, but shouldn't cause any trouble. And I've no > idea how realToFrac is implemented, but would worry about it behaving > oddly... for instance when given NaNs. It's a no-op (from the core I was looking at), and then you're not worrying about coercing newtypes. -- Don From sebastian.sylvan at gmail.com Mon Mar 17 14:02:08 2008 From: sebastian.sylvan at gmail.com (Sebastian Sylvan) Date: Mon Mar 17 13:58:56 2008 Subject: [Haskell-cafe] QuickCheck In-Reply-To: <889A6052-52B7-403E-A335-C8FC6A1F2A72@googlemail.com> References: <889A6052-52B7-403E-A335-C8FC6A1F2A72@googlemail.com> Message-ID: <3d96ac180803171102t5b0d4d0bkd9f0cd1c39a7b081@mail.gmail.com> On Mon, Mar 17, 2008 at 1:54 PM, Thomas Schilling wrote: > > On 17 mar 2008, at 14.37, rodrigo.bonifacio wrote: > > > Hi all, > > > > Is it possible to define a limit for the size of children list bellow? > > > > I've tried: > > > > children <- resize (10 (listGen featureGenNormal)) > >> > > You are calling a number as a function. > > Also, listGen has to use the size argument. Try something like (not > tested): > > listGen = > sized (\maxSize -> do > n <- arbitrary > x <- g > xs <- frequency [ (1, return []), (n, listGen g) ] > return (x:xs) > In retrospect, this function isn't very good at all, because it never generates the empty list... Something like this is probably better (untested): listGen g = sized (\maxSize -> do count <- choose (0, maxSize - 1) replicateM count g ) -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080317/9f8983c6/attachment.htm From john at repetae.net Mon Mar 17 14:15:21 2008 From: john at repetae.net (John Meacham) Date: Mon Mar 17 14:12:09 2008 Subject: [Haskell-cafe] floating point operations and representation In-Reply-To: <117f2cc80803170959v1c80eb18v625c8fd747de3aaf@mail.gmail.com> References: <8e47d1720803121735j17343d57x49fff089123f889b@mail.gmail.com> <20080313012759.GA11389@scytale.galois.com> <117f2cc80803170959v1c80eb18v625c8fd747de3aaf@mail.gmail.com> Message-ID: <20080317181521.GA14807@sliver.repetae.net> On Mon, Mar 17, 2008 at 12:59:09PM -0400, David Roundy wrote: > foreign import ccall unsafe "math.h log10" log10 :: Double -> Double > > since in ghc CDouble and Double are identical. > > It's a bit sloppier, but shouldn't cause any trouble. And I've no > idea how realToFrac is implemented, but would worry about it behaving > oddly... for instance when given NaNs. Yes. 'realToFrac' is inherently pretty broken and should be avoided whenever possible. It is not all all obvious to me what the correct primitive should be.. but we really should do something better for haskell'. relying on RULES firing as ghc currently does doesn't seem ideal.. hmm.. maybe a 'FloatMax' type and have 'fromFloatMax' and 'toFloatMax' in 'Fractional' and 'Real' respectively? hmm.. hc has 'fromDouble' and 'toDouble' there, but jhc also supports a 'Float128' type (when the underlying hardware does). so this still isn't quite right. John -- John Meacham - ?repetae.net?john? From josef.svenningsson at gmail.com Mon Mar 17 14:38:09 2008 From: josef.svenningsson at gmail.com (Josef Svenningsson) Date: Mon Mar 17 14:35:09 2008 Subject: [Haskell-cafe] STM example code In-Reply-To: <5ae4f2ba0803082139mff44e30haf09ad07713852ba@mail.gmail.com> References: <5ae4f2ba0803082139mff44e30haf09ad07713852ba@mail.gmail.com> Message-ID: <8dde104f0803171138g2e812d6eo23f274b9768bbe32@mail.gmail.com> 2008/3/9 Galchin Vasili : > I am playing around with the STM API. I would like to see examples of > STM other than the Santa.hs as I am having problems with STM vs IO. > Here's my implementation of the Dining Philosophers in STM: http://computationalthoughts.blogspot.com/2008/03/some-examples-of-software-transactional.html I hope you'll find it helpful. Josef From wnoise at ofb.net Mon Mar 17 14:51:06 2008 From: wnoise at ofb.net (Aaron Denney) Date: Mon Mar 17 14:48:02 2008 Subject: [Haskell-cafe] Re: floating point operations and representation References: <8e47d1720803121735j17343d57x49fff089123f889b@mail.gmail.com> <20080313012759.GA11389@scytale.galois.com> <117f2cc80803170959v1c80eb18v625c8fd747de3aaf@mail.gmail.com> <20080317181521.GA14807@sliver.repetae.net> Message-ID: On 2008-03-17, John Meacham wrote: > On Mon, Mar 17, 2008 at 12:59:09PM -0400, David Roundy wrote: >> foreign import ccall unsafe "math.h log10" log10 :: Double -> Double >> >> since in ghc CDouble and Double are identical. >> >> It's a bit sloppier, but shouldn't cause any trouble. And I've no >> idea how realToFrac is implemented, but would worry about it behaving >> oddly... for instance when given NaNs. > > Yes. 'realToFrac' is inherently pretty broken and should be avoided > whenever possible. It is not all all obvious to me what the correct > primitive should be.. but we really should do something better for > haskell'. relying on RULES firing as ghc currently does doesn't seem > ideal.. > > hmm.. maybe a 'FloatMax' type and have 'fromFloatMax' and 'toFloatMax' > in 'Fractional' and 'Real' respectively? hmm.. hc has 'fromDouble' and > 'toDouble' there, but jhc also supports a 'Float128' type (when the > underlying hardware does). so this still isn't quite right. Well, the whole numeric hierarchy needs to be redone to support proper mathematical structures like groups, rings, and fields. Once that's done, this might end up being clarified a bit. -- Aaron Denney -><- From lgreg.meredith at biosimilarity.com Mon Mar 17 15:51:04 2008 From: lgreg.meredith at biosimilarity.com (Greg Meredith) Date: Mon Mar 17 15:47:55 2008 Subject: [Haskell-cafe] 2-level type analysis of introducing naming into data types In-Reply-To: References: <5de3f5ca0803150020s65d3a63pdebf66a77f24ef9@mail.gmail.com> Message-ID: <5de3f5ca0803171251g69852e56i63978023df15f055@mail.gmail.com> Justin, Thanks for the query. Here are the considerations/concerns i with which i was working. - Data is *not* native to either lambda or pi-calculi - operational encodings for simple types (Bool and Nat) were given near the inception of these calculi - embeddings of these types took several decades to work out semantically (full abstraction for PCF is an example of the difficulty in the case of lambda; i submit that we haven't really figured out the corresponding story for concurrency, yet) - On the other hand, naming is necessary for effective work with any moderately complex recursive data structure - this is so common we are like fish to this water -- we don't even recognize when we're doing it (as an example see Conway's original presentation of numbers as games -- he starts using naming but does not acknowledge this very subtle shift in the mathematics) - Lambda and pi-calculi are the best name management technology we know - Is there a natural and elementary way to provide the benefits of these name management technologies for dealing with these concrete data structures? Yes, it turns out that the simplest way finds solutions as sitting between least and greatest fixpoints of the functor that pops out of the 2-level type analysis (hence the pretty domain equations that are expressed as Haskell data types). Moreover, it also gives a freebie way to embed data types in these decidedly operational calculi. Further, as i only recently realized it gives a way to compare Brian Smith style reflection with the reflection Matthias Radestock and i identified with the rho-calculus. See thisnew code. Best wishes, --greg On Mon, Mar 17, 2008 at 8:52 AM, Justin Bailey wrote: > 2008/3/15 Greg Meredith : > > All, > > > > > > The following Haskell code gives a 2-level type analysis of a > > functorial approach to introducing naming and name management into a > > given (recursive) data type. The analysis is performed by means of an > > What's the upshot of this? That is, what does this analysis give you? > I mostly follow the argument but I don't understand the benefits. I > feel like I'm missing something. > > Justin > -- 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/20080317/c220c763/attachment.htm From fmartini at gmail.com Mon Mar 17 17:24:51 2008 From: fmartini at gmail.com (Felix Martini) Date: Mon Mar 17 17:21:38 2008 Subject: [Haskell-cafe] Need Cabal/library building help for windows In-Reply-To: <2f9b2d30803170934k14a5fe5hb2699eab6a51af77@mail.gmail.com> References: <2f9b2d30803170934k14a5fe5hb2699eab6a51af77@mail.gmail.com> Message-ID: <6c0416190803171424u2342009bq6bb3989e366cd772@mail.gmail.com> Ryan Ingram wrote: > For reference, I'm using GHC6.8.1 on WinXP. > setup.hs: ld is required but it could not be found. I did have the same issue with GHC 6.8.1 on Windows. It is fixed in version 6.8.2. http://haskell.org/ghc/download_ghc_682.html#windows Regards, Felix From ryani.spam at gmail.com Mon Mar 17 17:26:28 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Mon Mar 17 17:23:18 2008 Subject: [Haskell-cafe] Need Cabal/library building help for windows In-Reply-To: <6c0416190803171424u2342009bq6bb3989e366cd772@mail.gmail.com> References: <2f9b2d30803170934k14a5fe5hb2699eab6a51af77@mail.gmail.com> <6c0416190803171424u2342009bq6bb3989e366cd772@mail.gmail.com> Message-ID: <2f9b2d30803171426n38ff9dd5wc911a1b8ef38393a@mail.gmail.com> Thanks, I was hoping it would be something simple like that! I'll give it a try when I get home. -- ryan On 3/17/08, Felix Martini wrote: > Ryan Ingram wrote: > > For reference, I'm using GHC6.8.1 on WinXP. > > > setup.hs: ld is required but it could not be found. > > I did have the same issue with GHC 6.8.1 on Windows. It is fixed in > version 6.8.2. > > http://haskell.org/ghc/download_ghc_682.html#windows > > Regards, > Felix > From ganesh at earth.li Mon Mar 17 17:41:43 2008 From: ganesh at earth.li (Ganesh Sittampalam) Date: Mon Mar 17 17:38:32 2008 Subject: [Haskell-cafe] problem with type equality constraints In-Reply-To: <7B454D5B-AE18-4E47-BC88-2867378CDD79@cse.unsw.edu.au> References: <7B454D5B-AE18-4E47-BC88-2867378CDD79@cse.unsw.edu.au> Message-ID: On Mon, 17 Mar 2008, Manuel M T Chakravarty wrote: > Your are completely right. Unfortunately, superclass equalities (ie, the Id > a ~ ida in the class declaration of Foo) aren't fully implemented yet. OK, thanks. Is there any rough idea of when they will be? > If I am not mistaken, superclass equalities, class defaults for > associated type families, and GADT data instances are the three major > features of type families/equality constraint saga that aren't fully > implemented yet. Even with the rough edges, type families are really nice, thanks! Cheers, Ganesh From hpacheco at gmail.com Mon Mar 17 18:04:45 2008 From: hpacheco at gmail.com (Hugo Pacheco) Date: Mon Mar 17 18:01:34 2008 Subject: [Haskell-cafe] Type parameters in type families Message-ID: <7b92c2840803171504p407fda12x61a6304bbfc277ce@mail.gmail.com> Hi, I am trying to understand some differences of parameterizing or not some arguments of type families. I have some code such as *type family G a :: * -> * instance Functor (G Int) where fmap f (Left ()) = Left () fmap f (Right x) = Right (f x) ggg :: Functor (G a) => G a x -> G a x ggg = fmap id* and it works fine. However, I need to parameterize one extra argument (due to type equality): *type family F a x :: * class FunctorF d where fmapF :: (x -> y) -> F d x -> F d y fff :: (FunctorF a) => F a b -> F a b fff = fmapF id* This second scenario fails to compile because the compiler cannot unify types a and b with types d and x from the fmapF declaration. Is there any other option than passing dummy variables to fmapF? * class FunctorF d where fmapF :: d -> x -> (x -> y) -> F d x -> F d y fff :: (FunctorF a) => a -> b -> F a b -> F a b fff a b = fmapF a b id* Thanks, hugo -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080317/92a75221/attachment.htm From bf3 at telenet.be Mon Mar 17 18:53:04 2008 From: bf3 at telenet.be (Peter Verswyvelen) Date: Mon Mar 17 18:49:56 2008 Subject: [Haskell-cafe] Re: ANN: haskell-src-exts 0.3.2 In-Reply-To: References: Message-ID: <47DEF650.6090506@telenet.be> Could this be used to add support for refactoring of source files containing language extensions? Because if I'm correct, the current most popular refactoring solution (I forgot the name) for Haskell does not support extensions. It would also be nice to add support for the arrows syntax :-) Cheers, Peter Verswyvelen www.anygma.com Niklas Broberg wrote: >> I'm pleased to announce a new release for the haskell-src-exts package. >> > > Twice in two days even. :-) > > haskell-src-exts 0.3.3 - now with support for type equality constraints. > > cabal sdist: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/haskell-src-exts-0.3.3 > darcs repo: http://code.haskell.org/HSP/haskell-src-exts > > Cheers, > > /Niklas > > >> haskell-src-exts 0.3.2 >> =========================== >> >> haskell-src-exts is a package for handling and manipulating Haskell >> source code. It is based on the haskell-src package that is part of >> the standard libraries, but extends this to support a number of >> syntactic extensions, e.g. MPTCs, fundeps, GADTs, TH etc. It is >> intended as a drop-in replacement for the standard haskell-src >> package, and exports the same functions and data types, plus some >> more. >> >> Apart from the more standard extensions supported by e.g. GHC, >> haskell-src-exts also provides support for HaRP (Haskell Regular >> Patterns) and HSX (Haskell Source with XML) syntax. >> >> Note that as of 0.3, haskell-src-exts /= HSX. >> >> * cabal sdist: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/haskell-src-exts-0.3.2 >> * darcs repo: darcs get http://code.haskell.org/HSP/haskell-src-exts >> >> >> === Changes from 0.2: === >> >> * Added support for >> - Indexed type families (including associated types/datatypes) >> - Explicit kind signatures >> - Standalone deriving >> >> * haskell-src-exts is now decoupled from hsx/trhsx and harp. >> - Modules renamed to Language.Haskell.Exts.* >> - Module Transform is removed from the package (now in package hsx) >> >> * New repository (i.e. darcs pull in an old repo won't work, use darcs >> get), containing only the haskell-src-exts package (no hsx or harp). >> >> * Builds with 6.8.2 (thanks Duncan Coutts) >> >> >> === Complete list of supported extensions === >> >> * Multi-parameter type classes (MPTCs) >> * Functional dependencies >> * Associated types, indexed type families >> * Liberal class and instance heads >> * Implicit parameters >> * Explicit kind signatures >> * Pattern guards >> * Generalized algebraic data types (GADTs) >> * Template Haskell (TH) >> * Universal and existential quantification (forall) >> * Empty data type declarations >> * Unboxed tuples (# #) >> * Standalone deriving >> * Regular patterns >> * Haskell XML, HSX style >> >> >> === Build Requirements === >> >> * happy >= 1.17 >> - It might work with 1.16 though I haven't tested. In that case >> change the cabal file. >> - It would work with older versions as well, though they insert a >> dependency on Array (haskell98) instead of Data.Array. If that's all >> you have to work with, update the cabal file with a dependency on >> haskell98. >> >> * Cabal >= 1.2 >> >> >> Patches are more than welcome. :-) >> >> Cheers, >> >> >> /Niklas >> >> > _______________________________________________ > 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/20080317/96bada26/attachment.htm From nominolo at googlemail.com Mon Mar 17 18:58:05 2008 From: nominolo at googlemail.com (Thomas Schilling) Date: Mon Mar 17 18:54:59 2008 Subject: [Haskell-cafe] Re: ANN: haskell-src-exts 0.3.2 In-Reply-To: <47DEF650.6090506@telenet.be> References: <47DEF650.6090506@telenet.be> Message-ID: On 17 mar 2008, at 23.53, Peter Verswyvelen wrote: > Could this be used to add support for refactoring of source files > containing language extensions? > > Because if I'm correct, the current most popular refactoring > solution (I forgot the name) for Haskell does not support extensions. HaRe - http://www.cs.kent.ac.uk/projects/refactor-fp/hare.html > > > It would also be nice to add support for the arrows syntax :-) > > Cheers, > Peter Verswyvelen > www.anygma.com > > > Niklas Broberg wrote: >> >>> I'm pleased to announce a new release for the haskell-src-exts >>> package. >> Twice in two days even. :-) haskell-src-exts 0.3.3 - now with >> support for type equality constraints. cabal sdist: http:// >> hackage.haskell.org/cgi-bin/hackage-scripts/package/haskell-src- >> exts-0.3.3 darcs repo: http://code.haskell.org/HSP/haskell-src- >> exts Cheers, /Niklas >>> >>> haskell-src-exts 0.3.2 =========================== haskell-src- >>> exts is a package for handling and manipulating Haskell source >>> code. It is based on the haskell-src package that is part of the >>> standard libraries, but extends this to support a number of >>> syntactic extensions, e.g. MPTCs, fundeps, GADTs, TH etc. It is >>> intended as a drop-in replacement for the standard haskell-src >>> package, and exports the same functions and data types, plus some >>> more. Apart from the more standard extensions supported by e.g. >>> GHC, haskell-src-exts also provides support for HaRP (Haskell >>> Regular Patterns) and HSX (Haskell Source with XML) syntax. Note >>> that as of 0.3, haskell-src-exts /= HSX. * cabal sdist: http:// >>> hackage.haskell.org/cgi-bin/hackage-scripts/package/haskell-src- >>> exts-0.3.2 * darcs repo: darcs get http://code.haskell.org/HSP/ >>> haskell-src-exts === Changes from 0.2: === * Added support for - >>> Indexed type families (including associated types/datatypes) - >>> Explicit kind signatures - Standalone deriving * haskell-src-exts >>> is now decoupled from hsx/trhsx and harp. - Modules renamed to >>> Language.Haskell.Exts.* - Module Transform is removed from the >>> package (now in package hsx) * New repository (i.e. darcs pull in >>> an old repo won't work, use darcs get), containing only the >>> haskell-src-exts package (no hsx or harp). * Builds with 6.8.2 >>> (thanks Duncan Coutts) === Complete list of supported extensions >>> === * Multi-parameter type classes (MPTCs) * Functional >>> dependencies * Associated types, indexed type families * Liberal >>> class and instance heads * Implicit parameters * Explicit kind >>> signatures * Pattern guards * Generalized algebraic data types >>> (GADTs) * Template Haskell (TH) * Universal and existential >>> quantification (forall) * Empty data type declarations * Unboxed >>> tuples (# #) * Standalone deriving * Regular patterns * Haskell >>> XML, HSX style === Build Requirements === * happy >= 1.17 - It >>> might work with 1.16 though I haven't tested. In that case change >>> the cabal file. - It would work with older versions as well, >>> though they insert a dependency on Array (haskell98) instead of >>> Data.Array. If that's all you have to work with, update the cabal >>> file with a dependency on haskell98. * Cabal >= 1.2 Patches are >>> more than welcome. :-) Cheers, /Niklas >> _______________________________________________ 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 hpacheco at gmail.com Mon Mar 17 18:59:59 2008 From: hpacheco at gmail.com (Hugo Pacheco) Date: Mon Mar 17 18:56:47 2008 Subject: [Haskell-cafe] Re: Type parameters in type families In-Reply-To: <7b92c2840803171504p407fda12x61a6304bbfc277ce@mail.gmail.com> References: <7b92c2840803171504p407fda12x61a6304bbfc277ce@mail.gmail.com> Message-ID: <7b92c2840803171559s6f640aecq9405795c5d091369@mail.gmail.com> I wonder if I am dealing with bugs in the type checker (replying to myself). Curiously if I have class FunctorF d where fmapF :: d -> (x -> y) -> F d x -> F d y fff a = fmapF a id it compiles correctly. If I infer the type signature of fff I get fff :: forall d x. (FunctorF d) => d -> F d x -> F d x On the other side, it fails to compile when this signature is explicit: fff :: forall d x. (FunctorF d) => d -> F d x -> F d x fff a = fmapF a id I am repeating myself in http://hackage.haskell.org/trac/ghc/ticket/2157#comment:6. Sorry for the cascaded messages, hugo -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080317/ac676c9c/attachment.htm From niklas.broberg at gmail.com Mon Mar 17 19:41:31 2008 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Mon Mar 17 19:38:18 2008 Subject: [Haskell-cafe] Re: ANN: haskell-src-exts 0.3.2 In-Reply-To: <47DEF650.6090506@telenet.be> References: <47DEF650.6090506@telenet.be> Message-ID: > Could this be used to add support for refactoring of source files > containing language extensions? > > Because if I'm correct, the current most popular refactoring solution (I > forgot the name) for Haskell does not support extensions. I supppose you're talking about HaRe, that Thomas Schilling linked to. I have no idea how that system is built so I can't answer your question. But in principle I don't see why not. :-) > It would also be nice to add support for the arrows syntax :-) Right, that's one of the few extensions missing, and as such it's pretty high on the todo list. I'll see what/ I can do about it (or when rather), or if anyone would send me a patch I'd be happy to include it. :-) Cheers, /Niklas From ryani.spam at gmail.com Mon Mar 17 21:12:35 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Mon Mar 17 21:09:23 2008 Subject: [Haskell-cafe] Type parameters in type families In-Reply-To: <7b92c2840803171504p407fda12x61a6304bbfc277ce@mail.gmail.com> References: <7b92c2840803171504p407fda12x61a6304bbfc277ce@mail.gmail.com> Message-ID: <2f9b2d30803171812h67bd8432m18a03948ad435d1@mail.gmail.com> On 3/17/08, Hugo Pacheco wrote: > type family G a :: * -> * > type instance G Int = Either () -- you forgot this line > > instance Functor (G Int) where > fmap f (Left ()) = Left () > fmap f (Right x) = Right (f x) One thing that you don't seem to be clear about is that there is something slightly magic going on in this Functor definition; you are not declaring Functor (G Int) but rather Functor (whatever (G Int) turns into). This is using a GHC extension "TypeSynonymInstances". The extension allows you to use type synonyms when declaring instances, but only if they are fully applied, and the compiler is simply applying the substitution for you. That is to say, this code is no different than the following: type family G a :: * -> * type instance G Int = Either () instance Functor (Either ()) where fmap f (Left ()) = Left () fmap f (Right x) = Right (f x) Once you declare a more complicated type function, such as type family F a x :: * this extension can no longer come into play. You can get around this restriction with a newtype: type family F a x :: * type instance F Int x = Either () x newtype F' a b = F' (F a b) instance Functor (F' Int) where fmap f (F' (Left ())) = F' (Left ()) fmap f (F' (Right x)) = F' (Right $ f x) From hpacheco at gmail.com Mon Mar 17 21:49:37 2008 From: hpacheco at gmail.com (Hugo Pacheco) Date: Mon Mar 17 21:46:24 2008 Subject: [Haskell-cafe] Type parameters in type families In-Reply-To: <2f9b2d30803171812h67bd8432m18a03948ad435d1@mail.gmail.com> References: <7b92c2840803171504p407fda12x61a6304bbfc277ce@mail.gmail.com> <2f9b2d30803171812h67bd8432m18a03948ad435d1@mail.gmail.com> Message-ID: <7b92c2840803171849k482eff06j1a001ac452910b13@mail.gmail.com> But by doing so I am changing type equality to the same as having "type family F a :: * -> *" F' a x ~ F' b y <=> F' a ~ F' b /\ x ~ y (equality for ADTs) and I would like this "decomposition rule not to apply" so. Thanks though, hugo On Tue, Mar 18, 2008 at 1:12 AM, Ryan Ingram wrote: > On 3/17/08, Hugo Pacheco wrote: > > type family G a :: * -> * > > type instance G Int = Either () -- you forgot this line > > > > instance Functor (G Int) where > > fmap f (Left ()) = Left () > > fmap f (Right x) = Right (f x) > > One thing that you don't seem to be clear about is that there is > something slightly magic going on in this Functor definition; you are > not declaring Functor (G Int) but rather Functor (whatever (G Int) > turns into). This is using a GHC extension "TypeSynonymInstances". > The extension allows you to use type synonyms when declaring > instances, but only if they are fully applied, and the compiler is > simply applying the substitution for you. > > That is to say, this code is no different than the following: > > type family G a :: * -> * > type instance G Int = Either () > instance Functor (Either ()) where > fmap f (Left ()) = Left () > fmap f (Right x) = Right (f x) > > Once you declare a more complicated type function, such as > type family F a x :: * > this extension can no longer come into play. > > You can get around this restriction with a newtype: > > type family F a x :: * > type instance F Int x = Either () x > > newtype F' a b = F' (F a b) > > instance Functor (F' Int) where > fmap f (F' (Left ())) = F' (Left ()) > fmap f (F' (Right x)) = F' (Right $ f x) > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080318/b1904995/attachment.htm From tom.davie at gmail.com Mon Mar 17 22:05:38 2008 From: tom.davie at gmail.com (Thomas Davie) Date: Mon Mar 17 22:02:31 2008 Subject: [Haskell-cafe] Re: ANN: haskell-src-exts 0.3.2 In-Reply-To: References: <47DEF650.6090506@telenet.be> Message-ID: <8700DEB6-1673-4A4F-B44B-B1A99AE2764A@gmail.com> On 17 Mar 2008, at 23:41, Niklas Broberg wrote: >> Could this be used to add support for refactoring of source files >> containing language extensions? >> >> Because if I'm correct, the current most popular refactoring >> solution (I >> forgot the name) for Haskell does not support extensions. > > I supppose you're talking about HaRe, that Thomas Schilling linked to. > I have no idea how that system is built so I can't answer your > question. But in principle I don't see why not. :-) I believe that the limitation is that they use Programatica's parser to get an AST to run their refactorings on. I think they've looked several times at using ghc's apis to do this, but hit various problems. I think that the main problem is that no other parser preserves things like code layout and commenting, which is of course pretty critical to refactoring programs in a sane kind of way. Thanks Tom From chak at cse.unsw.edu.au Mon Mar 17 23:13:48 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Mon Mar 17 23:10:39 2008 Subject: [Haskell-cafe] problem with type equality constraints In-Reply-To: References: <7B454D5B-AE18-4E47-BC88-2867378CDD79@cse.unsw.edu.au> Message-ID: <7231DE65-8338-4181-A160-BE0A85DE34A4@cse.unsw.edu.au> Ganesh Sittampalam: > On Mon, 17 Mar 2008, Manuel M T Chakravarty wrote: >> Your are completely right. Unfortunately, superclass equalities >> (ie, the Id a ~ ida in the class declaration of Foo) aren't fully >> implemented yet. > > OK, thanks. Is there any rough idea of when they will be? That's a bit difficult to say. The main problem is that the current handling of evidence for classes and access to superclass evidence doesn't mix well with the fact that the evidence for equalities are coercions (ie, type-level things, rather than value level things). It's high up on the list, but some other things like the interaction between GADTs and type families (basically done now) were higher up. If its important to you, I'd try to get to it earlier than if nobody is really waiting for it. Manuel From adam.smyczek at gmail.com Tue Mar 18 00:49:27 2008 From: adam.smyczek at gmail.com (Adam Smyczek) Date: Tue Mar 18 00:46:20 2008 Subject: [Haskell-cafe] Network.Browser and getCookies In-Reply-To: References: <1B8811DF-4BA5-4B15-8097-BFD266C8DBE0@gmail.com> Message-ID: <4755C5E6-C589-4D7C-B4BE-4DDA9D6F9F2C@gmail.com> Thanks for the tip. Turned out to be a server problem. Adam On Mar 17, 2008, at 8:55 AM, Justin Bailey wrote: > On Sun, Mar 16, 2008 at 10:21 AM, Adam Smyczek > wrote: >> Somehow I cannot get cookies from the Response >> using Network.Browser module (HTTP 3001.0.4). >> The cookie header part seams to be empty and >> getCookies returns empty list as well. > > Network.Browser comes with a built-in HTTP trace facility - I'd first > make sure you are getting the HTTP responses you expect. I believe > it's setErrHandler and setDebugHandler - use putStrLn to get a trace > of HTTP traffic on your console. > > Justin From ganesh at earth.li Tue Mar 18 01:39:58 2008 From: ganesh at earth.li (Ganesh Sittampalam) Date: Tue Mar 18 01:36:46 2008 Subject: [Haskell-cafe] problem with type equality constraints In-Reply-To: <7231DE65-8338-4181-A160-BE0A85DE34A4@cse.unsw.edu.au> References: <7B454D5B-AE18-4E47-BC88-2867378CDD79@cse.unsw.edu.au> <7231DE65-8338-4181-A160-BE0A85DE34A4@cse.unsw.edu.au> Message-ID: On Tue, 18 Mar 2008, Manuel M T Chakravarty wrote: > Ganesh Sittampalam: >> On Mon, 17 Mar 2008, Manuel M T Chakravarty wrote: >>> Your are completely right. Unfortunately, superclass equalities (ie, the >>> Id a ~ ida in the class declaration of Foo) aren't fully implemented yet. >> >> OK, thanks. Is there any rough idea of when they will be? > > It's high up on the list, but some other things like the interaction between > GADTs and type families (basically done now) were higher up. If its > important to you, I'd try to get to it earlier than if nobody is really > waiting for it. Well, I am waiting for it, but I'm not exactly desperate. There are also other things restricting me from a wholesale conversion from fundeps which I'll write up into questions on here over the next few days. Cheers, Ganesh From alistair at abayley.org Tue Mar 18 05:28:37 2008 From: alistair at abayley.org (Alistair Bayley) Date: Tue Mar 18 05:25:25 2008 Subject: [Haskell-cafe] Need Cabal/library building help for windows In-Reply-To: <6c0416190803171424u2342009bq6bb3989e366cd772@mail.gmail.com> References: <2f9b2d30803170934k14a5fe5hb2699eab6a51af77@mail.gmail.com> <6c0416190803171424u2342009bq6bb3989e366cd772@mail.gmail.com> Message-ID: <79d7c4980803180228t6241ee87x6d311b4dbdf66a3a@mail.gmail.com> On 17/03/2008, Felix Martini wrote: > Ryan Ingram wrote: > > For reference, I'm using GHC6.8.1 on WinXP. > > > setup.hs: ld is required but it could not be found. > > I did have the same issue with GHC 6.8.1 on Windows. It is fixed in > version 6.8.2. > > http://haskell.org/ghc/download_ghc_682.html#windows Upgrading GHC to fix this seems a little extreme. You can just add gcc-lib (i.e. C:\ghc\ghc-6.8.1\gcc-lib) to your path. Alistair From vitaliy.akimov at gmail.com Tue Mar 18 05:32:53 2008 From: vitaliy.akimov at gmail.com (Vitaliy Akimov) Date: Tue Mar 18 05:29:38 2008 Subject: [Haskell-cafe] Re: all threads are blocked by recvFrom In-Reply-To: <396556a20803171006k3d84e585l735a4403894966cf@mail.gmail.com> References: <396556a20803140757w1ac429e3q6655078e30961a4e@mail.gmail.com> <396556a20803141013w6ba1271bjc2ea1bbd9c80b729@mail.gmail.com> <396556a20803171006k3d84e585l735a4403894966cf@mail.gmail.com> Message-ID: 2008/3/17, Adam Langley : > On Mon, Mar 17, 2008 at 2:29 AM, Vitaliy Akimov > > > The important point here is that the recvFrom calls in > Network.Socket[1] don't block. Yes, this is the answer. Network.Socket.socket calls System.Posix.Internals.setNonBlockingFD to set socket non-blocking. I'm on Windows, and this function is simply "return ()" for this platform. So that's why it doesn't work on Windows, I think I should find some way to make a socket unblocking after its creation. Thank you. Vitaliy. From dekudekuplex at yahoo.com Tue Mar 18 06:00:46 2008 From: dekudekuplex at yahoo.com (Benjamin L. Russell) Date: Tue Mar 18 05:57:32 2008 Subject: [Haskell-cafe] Haskell board game, anyone? Message-ID: <794174.71111.qm@web30206.mail.mud.yahoo.com> Maybe off topic, but when I saw this, I thought, "Why isn't there a Haskell version of this game?" (Or is there?) C-jump is a neat idea, mapping something fun (downhill skiing) with programming. I look at this game and wonder what it would look like in the wonderful world of higher-order functions. Begin forwarded message from "Geoff Knauth" (with subject "[plt-scheme] Scheme board game, anyone?" on "PLT-list Mailing List" , dated "Mon, 17 Mar 2008 12:38:32 -0400"): > Maybe off topic, but when I saw this, I thought, "Why > isn't there a > Scheme version of this game?" (Or is there?) > > C-jump is a neat idea, mapping something fun (downhill > skiing) with programming. I look at this game and > wonder what it would look like > in the wonderful world of continuations. > > Begin forwarded message from Chase Turner: > > > Subject: Is there a Scheme version of this game? > > > > http://www.c-jump.com Benjamin L. Russell From fmartini at gmail.com Tue Mar 18 06:27:53 2008 From: fmartini at gmail.com (Felix Martini) Date: Tue Mar 18 06:24:39 2008 Subject: [Haskell-cafe] Need Cabal/library building help for windows In-Reply-To: <79d7c4980803180228t6241ee87x6d311b4dbdf66a3a@mail.gmail.com> References: <2f9b2d30803170934k14a5fe5hb2699eab6a51af77@mail.gmail.com> <6c0416190803171424u2342009bq6bb3989e366cd772@mail.gmail.com> <79d7c4980803180228t6241ee87x6d311b4dbdf66a3a@mail.gmail.com> Message-ID: <6c0416190803180327s5c177ea2vaa0ff929b34a5326@mail.gmail.com> Alistair Bayley wrote: > Upgrading GHC to fix this seems a little extreme. You can just add > gcc-lib (i.e. C:\ghc\ghc-6.8.1\gcc-lib) to your path. Version 6.8.2 is a bugfix release over 6.8.1 and fixes other bugs as well. From cmb21 at kent.ac.uk Tue Mar 18 06:28:59 2008 From: cmb21 at kent.ac.uk (C.M.Brown) Date: Tue Mar 18 06:26:25 2008 Subject: [Haskell-cafe] Re: ANN: haskell-src-exts 0.3.2 In-Reply-To: References: <47DEF650.6090506@telenet.be> Message-ID: Hi Nikolas, > I supppose you're talking about HaRe, that Thomas Schilling linked to. > I have no idea how that system is built so I can't answer your > question. But in principle I don't see why not. :-) In principle it would actually be quite difficult. HaRe is Haskell 98, built upon the Programatica front end, and to use extensions would mean a port to a system that has extensions (ghc say) and a re-evaluation of all the current refactorings so that they work over extensions as well. Porting to a system like GHC would require an almost complete re-engineering of HaRe, and, although simple in theory, in practice it has so far presented some problems. With the exposure of the GHC API though, we hope to address this issue in the near future. Kind regards, Chris. From marco-oweber at gmx.de Tue Mar 18 06:33:59 2008 From: marco-oweber at gmx.de (Marc Weber) Date: Tue Mar 18 06:30:49 2008 Subject: [Haskell-cafe] Haskell board game, anyone? In-Reply-To: <794174.71111.qm@web30206.mail.mud.yahoo.com> References: <794174.71111.qm@web30206.mail.mud.yahoo.com> Message-ID: <20080318103359.GA23057@gmx.de> > C-jump is a neat idea, mapping something fun (downhill > skiing) with programming. I look at this game and > wonder what it would look like in the wonderful world > of higher-order functions. http://haskell.org/haskellwiki/Potential_projects Greetings Marc Weber From nominolo at googlemail.com Tue Mar 18 06:39:45 2008 From: nominolo at googlemail.com (Thomas Schilling) Date: Tue Mar 18 06:36:37 2008 Subject: [Haskell-cafe] Re: ANN: haskell-src-exts 0.3.2 In-Reply-To: References: <47DEF650.6090506@telenet.be> Message-ID: <7BEE81B0-99E7-45E0-9E4D-384FA434B759@googlemail.com> Do you have any program transformation DSL to make things easier? Or quickcheck tests or anything to make things easier? On 18 mar 2008, at 11.28, C.M.Brown wrote: > Hi Nikolas, > >> I supppose you're talking about HaRe, that Thomas Schilling linked >> to. >> I have no idea how that system is built so I can't answer your >> question. But in principle I don't see why not. :-) > > In principle it would actually be quite difficult. HaRe is Haskell 98, > built upon the Programatica front end, and to use extensions would > mean a > port to a system that has extensions (ghc say) and a re-evaluation > of all > the current refactorings so that they work over extensions as well. > > Porting to a system like GHC would require an almost complete re- > engineering of HaRe, and, > although simple in theory, in practice it has so far presented some > problems. With the exposure of the GHC API though, we hope to > address this > issue in the near future. > > > Kind regards, > Chris. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From vitaliy.akimov at gmail.com Tue Mar 18 06:41:12 2008 From: vitaliy.akimov at gmail.com (Vitaliy Akimov) Date: Tue Mar 18 06:37:59 2008 Subject: [Haskell-cafe] Re: all threads are blocked by recvFrom In-Reply-To: References: <396556a20803140757w1ac429e3q6655078e30961a4e@mail.gmail.com> <396556a20803141013w6ba1271bjc2ea1bbd9c80b729@mail.gmail.com> <396556a20803171006k3d84e585l735a4403894966cf@mail.gmail.com> Message-ID: > So that's why it doesn't work on Windows, I think I should find some > way to make a socket unblocking after its creation. Unfortunally this way seems to be wrong. Error codes for winsockets and BSD-sockets are different. From cmb21 at kent.ac.uk Tue Mar 18 06:43:33 2008 From: cmb21 at kent.ac.uk (C.M.Brown) Date: Tue Mar 18 06:41:09 2008 Subject: [Haskell-cafe] Re: ANN: haskell-src-exts 0.3.2 In-Reply-To: <8700DEB6-1673-4A4F-B44B-B1A99AE2764A@gmail.com> References: <47DEF650.6090506@telenet.be> <8700DEB6-1673-4A4F-B44B-B1A99AE2764A@gmail.com> Message-ID: > I believe that the limitation is that they use Programatica's parser > to get an AST to run their refactorings on. I think they've looked > several times at using ghc's apis to do this, but hit various > problems. I think that the main problem is that no other parser > preserves things like code layout and commenting, which is of course > pretty critical to refactoring programs in a sane kind of way. I think the main issue was that we looked at the port too early. I believe GHC would offer everything in terms of position information but at the time of the port there were issues such as Strafunski traversing over GHC's AST (now made possible with derivable instances); together with time restraints and the learning curve of GHC's internals. There is a technical report available that details some of the work: (Porting HaRe to the GHC API) http://www.cs.kent.ac.uk/pubs/2005/2266/ Thanks, Chris. > > Thanks > > Tom > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From cmb21 at kent.ac.uk Tue Mar 18 06:47:58 2008 From: cmb21 at kent.ac.uk (C.M.Brown) Date: Tue Mar 18 06:45:23 2008 Subject: [Haskell-cafe] Re: ANN: haskell-src-exts 0.3.2 In-Reply-To: <7BEE81B0-99E7-45E0-9E4D-384FA434B759@googlemail.com> References: <47DEF650.6090506@telenet.be> <7BEE81B0-99E7-45E0-9E4D-384FA434B759@googlemail.com> Message-ID: > Do you have any program transformation DSL to make things easier? Or > quickcheck tests or anything to make things easier? I'm not sure I follow how these would make the port easier? We don't have a DSL, but we do have a very sophisticated API: http://www.cs.kent.ac.uk/projects/refactor-fp/hare/API_Doc/RefacUtils.html There has been some work done by Huiqing to generate test cases using Quickcheck for Erlang refactoring: http://www.cs.kent.ac.uk/pubs/2007/2648/index.html Chris. > > > On 18 mar 2008, at 11.28, C.M.Brown wrote: > > > Hi Nikolas, > > > >> I supppose you're talking about HaRe, that Thomas Schilling linked > >> to. > >> I have no idea how that system is built so I can't answer your > >> question. But in principle I don't see why not. :-) > > > > In principle it would actually be quite difficult. HaRe is Haskell 98, > > built upon the Programatica front end, and to use extensions would > > mean a > > port to a system that has extensions (ghc say) and a re-evaluation > > of all > > the current refactorings so that they work over extensions as well. > > > > Porting to a system like GHC would require an almost complete re- > > engineering of HaRe, and, > > although simple in theory, in practice it has so far presented some > > problems. With the exposure of the GHC API though, we hope to > > address this > > issue in the near future. > > > > > > Kind regards, > > Chris. > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From Malcolm.Wallace at cs.york.ac.uk Tue Mar 18 07:23:06 2008 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Tue Mar 18 07:25:01 2008 Subject: [Haskell-cafe] haskell.org is accepted to GSoC Message-ID: <20080318112306.59770bdc.Malcolm.Wallace@cs.york.ac.uk> Google announced last night that Haskell.org has been accepted as a mentoring organisation for this year's Summer of Code (amongst 175 Open Source organisations). http://code.google.com/soc/2008/ The game is on! Student applications open at 1900 UTC on Mon 24th March, and close at 2400 UTC on Mon 31st March. In the meantime, my _strong_ suggestion is for students to search for ideas amongst the many lists available on the web: http://hackage.haskell.org/trac/summer-of-code/ http://haskell.org/haskellwiki/Hac_2007_II/Projects http://haskell.org/haskellwiki/Hac4/Projects and when crafting your proposal: * post it to an appropriate mailing list for comments e.g. haskell-cafe, libraries, wxHaskell, cabal-devel (prefix your subject line with [GSoC] to make it easy to find) * use feedback from the list to improve your proposal. Potential mentors will rank your final submitted proposal based on your ability and commitment to engage with the wider Haskell community, in addition to technical merit. Proposals that will benefit the entire Haskell world will generally be ranked more highly than niche projects with only a few potential users. So things like Cabal-hacking, darcs-hacking, compiler-hacking, are good, as are new libraries to do tasks that are in high demand. (This is not an exhaustive list.) Regards, Malcolm From iliali16 at gmail.com Tue Mar 18 08:24:38 2008 From: iliali16 at gmail.com (iliali16) Date: Tue Mar 18 08:21:23 2008 Subject: [Haskell-cafe] Small question about something easy Message-ID: <16119618.post@talk.nabble.com> Hi guys I am a bit new to haskell but I am doing good till now. I have to write a function that takes 2 inputs and then reutns one composite output. Now my problem is that I have to make composition of that function meaning that I have to access in some way the output of the function before it is really computed. I will show you part of my code which is working prefectly: play :: Logo -> TurtleState -> (Image, TurtleState) play DoNothing (pen, (x,y), angle) = (emptyImage, (pen, (x,y), angle)) play PenDown (pen, (x,y), angle) = (emptyImage,(pen, (x,y), angle)) play PenUp (pen, (x,y), angle) = (emptyImage,(pen, (x,y), angle)) play (Forward n) (pen, (x,y), angle) |pen == True = ((line (x,y) (x+n,y+n)), (True, (x+n,y+n), angle)) |otherwise = (emptyImage,(pen, (x+n,y+n), angle)) play (Turn n) (pen, (x,y), angle) = (emptyImage, (pen, (x,y), (angle+n))) play (DoNothing :>: p2) (pen, (x,y), angle) = play p2 (pen, (x,y), angle) play (p1 :> DoNothing) (pen, (x,y), angle) = play p1 (pen, (x,y), angle) play (PenDown :>: PenUp) (pen, (x,y), angle) = (emptyImage,(pen, (x,y), angle)) play (PenDown :>: (Forward n)) (pen, (x,y), angle) = play (Forward n) (True, (x,y), angle) play (PenDown :>: PenDown) (pen, (x,y), angle) = (emptyImage,(pen, (x,y), angle)) play (PenDown :>: (Turn n)) (pen, (x,y), angle) = play (Turn n) (pen, (x,y), angle) play (PenUp :>: PenUp) (pen, (x,y), angle) = (emptyImage,(pen, (x,y), angle)) play (PenUp :>: (Forward n)) (pen, (x,y), angle) = play (Forward n) (False, (x,y), angle) play (PenUp :>: (Turn n)) (pen, (x,y), angle) = play (Turn n) (pen, (x,y), angle) play (PenUp :>: PenDown) (pen, (x,y), angle) = (emptyImage,(pen, (x,y), angle)) Now the problem comes here: play (p1 :>: p2) state |play p1 state == (i1,state1) && play p2 state1 == (i2,state2) = (i1+++i2,state2) I know that if I manage to do that function the one above with this sign :>: do not need to be impelmented since this one will cater for all the cases. Can you please help me? Thanks in advance! -- View this message in context: http://www.nabble.com/Small-question-about-something-easy-tp16119618p16119618.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. From lrpalmer at gmail.com Tue Mar 18 08:51:18 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Tue Mar 18 08:48:04 2008 Subject: [Haskell-cafe] Small question about something easy In-Reply-To: <16119618.post@talk.nabble.com> References: <16119618.post@talk.nabble.com> Message-ID: <7ca3f0160803180551y6b0257dby14c1a5e7f412c96f@mail.gmail.com> On Tue, Mar 18, 2008 at 12:24 PM, iliali16 wrote: > Now the problem comes here: > play (p1 :>: p2) state > |play p1 state == (i1,state1) && play p2 state1 == (i2,state2) > = (i1+++i2,state2) > > I know that if I manage to do that function the one above with this sign :>: > do not need to be impelmented since this one will cater for all the cases. > Can you please help me? You just need a nice simple let or where clause: play (p1 :>: p2) state = (i1 +++ i2, state2) where (i1,state1) = play p1 state (i2,state2) = play p2 state1 Or equivalently: play (p1 :>: p2) state = let (i1, state1) = play p1 state (i2, state2) = play p2 state1 in (i1 +++ i2, state2) And there's nothing lazily recursive about these, just the information usage is a little more complex. But it could be implemented perfectly naturally in scheme, for example. For further exploration: the pattern here where the state is threaded through different computations, is captured by the module Control.Monad.State. So if "play" returned an object of a State monad, such as: play :: Logo -> State TurtleState Image Then this case could be implemented as: play (p1 :>: p2) = do i1 <- play p1 i2 <- play p2 return (i1 +++ i2) Pretty, ain't it? A little too pretty if you ask me. Let's make it uglier and shorter still: play (p1 :>: p2) = liftM2 (+++) (play p1) (play p2) :-) Luke From duncan.coutts at worc.ox.ac.uk Tue Mar 18 08:53:24 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Mar 18 08:53:47 2008 Subject: [Haskell-cafe] Need Cabal/library building help for windows In-Reply-To: <79d7c4980803180228t6241ee87x6d311b4dbdf66a3a@mail.gmail.com> References: <2f9b2d30803170934k14a5fe5hb2699eab6a51af77@mail.gmail.com> <6c0416190803171424u2342009bq6bb3989e366cd772@mail.gmail.com> <79d7c4980803180228t6241ee87x6d311b4dbdf66a3a@mail.gmail.com> Message-ID: <1205844804.7594.49.camel@localhost> On Tue, 2008-03-18 at 09:28 +0000, Alistair Bayley wrote: > On 17/03/2008, Felix Martini wrote: > > Ryan Ingram wrote: > > > For reference, I'm using GHC6.8.1 on WinXP. > > > > > setup.hs: ld is required but it could not be found. > > > > I did have the same issue with GHC 6.8.1 on Windows. It is fixed in > > version 6.8.2. > > > > http://haskell.org/ghc/download_ghc_682.html#windows > > Upgrading GHC to fix this seems a little extreme. You can just add > gcc-lib (i.e. C:\ghc\ghc-6.8.1\gcc-lib) to your path. Or you can install Cabal-1.2.3.0 which is the version that comes with ghc-6.8.2 and contains the fix: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Cabal-1.2.3.0 Duncan From nominolo at googlemail.com Tue Mar 18 08:59:15 2008 From: nominolo at googlemail.com (Thomas Schilling) Date: Tue Mar 18 08:56:07 2008 Subject: [Haskell-cafe] Small question about something easy In-Reply-To: <7ca3f0160803180551y6b0257dby14c1a5e7f412c96f@mail.gmail.com> References: <16119618.post@talk.nabble.com> <7ca3f0160803180551y6b0257dby14c1a5e7f412c96f@mail.gmail.com> Message-ID: On 18 mar 2008, at 13.51, Luke Palmer wrote: > On Tue, Mar 18, 2008 at 12:24 PM, iliali16 wrote: >> Now the problem comes here: >> play (p1 :>: p2) state >> |play p1 state == (i1,state1) && play p2 state1 == >> (i2,state2) >> = (i1+++i2,state2) >> >> I know that if I manage to do that function the one above with >> this sign :>: >> do not need to be impelmented since this one will cater for all >> the cases. >> Can you please help me? > > You just need a nice simple let or where clause: > > play (p1 :>: p2) state = (i1 +++ i2, state2) > where > (i1,state1) = play p1 state > (i2,state2) = play p2 state1 > > Or equivalently: > > play (p1 :>: p2) state = > let (i1, state1) = play p1 state > (i2, state2) = play p2 state1 > in (i1 +++ i2, state2) > > And there's nothing lazily recursive about these, just the information > usage is a little more complex. But it could be implemented perfectly > naturally in scheme, for example. > > For further exploration: the pattern here where the state is threaded > through different computations, is captured by the module > Control.Monad.State. So if "play" returned an object of a State monad, > such as: > > play :: Logo -> State TurtleState Image > > Then this case could be implemented as: > > play (p1 :>: p2) = do > i1 <- play p1 > i2 <- play p2 > return (i1 +++ i2) > > Pretty, ain't it? A little too pretty if you ask me. Let's make it > uglier and shorter still: > > play (p1 :>: p2) = liftM2 (+++) (play p1) (play p2) Or use Applicative directly: play (p1 :>: p2) = (+++) <$> play p1 <*> play p2 From tux_rocker at reinier.de Tue Mar 18 10:04:37 2008 From: tux_rocker at reinier.de (Reinier Lamers) Date: Tue Mar 18 10:01:28 2008 Subject: [Haskell-cafe] Re: "GADT" rhymes with "cat" In-Reply-To: <798BA697-F4AD-4F57-889E-C5593BF23FB3@cs.rice.edu> References: <47DDC2ED.1030400@appsolutions.com> <47DDD986.3020703@semantic.org> <47DDE2FC.20904@appsolutions.com> <798BA697-F4AD-4F57-889E-C5593BF23FB3@cs.rice.edu> Message-ID: Op 17-mrt-2008, om 5:39 heeft Emir Pasalic het volgende geschreven: > And is the plural 'gatte'? :) Not in Dutch, then it's 'gaten' (which is irregular, and the Afrikaners don't like irregularities, so they regularized it). Reinier From iliali16 at gmail.com Tue Mar 18 10:56:16 2008 From: iliali16 at gmail.com (iliali16) Date: Tue Mar 18 10:53:01 2008 Subject: [Haskell-cafe] Small question about something easy In-Reply-To: <16119618.post@talk.nabble.com> References: <16119618.post@talk.nabble.com> Message-ID: <16121996.post@talk.nabble.com> Thanks to all of you I got it I was missing the notation. Thanks again! iliali16 wrote: > > Hi guys I am a bit new to haskell but I am doing good till now. I have to > write a function that takes 2 inputs and then reutns one composite output. > Now my problem is that I have to make composition of that function meaning > that I have to access in some way the output of the function before it is > really computed. I will show you part of my code which is working > prefectly: > > play :: Logo -> TurtleState -> (Image, TurtleState) > > play DoNothing (pen, (x,y), angle) = (emptyImage, (pen, (x,y), angle)) > > play PenDown (pen, (x,y), angle) = (emptyImage,(pen, (x,y), angle)) > > play PenUp (pen, (x,y), angle) = (emptyImage,(pen, (x,y), angle)) > > play (Forward n) (pen, (x,y), angle) > |pen == True = ((line (x,y) (x+n,y+n)), (True, (x+n,y+n), angle)) > |otherwise = (emptyImage,(pen, (x+n,y+n), angle)) > > play (Turn n) (pen, (x,y), angle) = (emptyImage, (pen, (x,y), (angle+n))) > > play (DoNothing :>: p2) (pen, (x,y), angle) = play p2 (pen, (x,y), angle) > play (p1 :> DoNothing) (pen, (x,y), angle) = play p1 (pen, (x,y), angle) > play (PenDown :>: PenUp) (pen, (x,y), angle) = (emptyImage,(pen, (x,y), > angle)) > play (PenDown :>: (Forward n)) (pen, (x,y), angle) = play (Forward n) > (True, (x,y), angle) > play (PenDown :>: PenDown) (pen, (x,y), angle) = (emptyImage,(pen, (x,y), > angle)) > play (PenDown :>: (Turn n)) (pen, (x,y), angle) = play (Turn n) (pen, > (x,y), angle) > play (PenUp :>: PenUp) (pen, (x,y), angle) = (emptyImage,(pen, (x,y), > angle)) > play (PenUp :>: (Forward n)) (pen, (x,y), angle) = play (Forward n) > (False, (x,y), angle) > play (PenUp :>: (Turn n)) (pen, (x,y), angle) = play (Turn n) (pen, (x,y), > angle) > play (PenUp :>: PenDown) (pen, (x,y), angle) = (emptyImage,(pen, (x,y), > angle)) > > Now the problem comes here: > play (p1 :>: p2) state > |play p1 state == (i1,state1) && play p2 state1 == > (i2,state2) = (i1+++i2,state2) > > I know that if I manage to do that function the one above with this sign > :>: do not need to be impelmented since this one will cater for all the > cases. Can you please help me? > > Thanks in advance! > :jumping::jumping::jumping::jumping::jumping::jumping::jumping::jumping::jumping::jumping::jumping::jumping::jumping::jumping: -- View this message in context: http://www.nabble.com/Small-question-about-something-easy-tp16119618p16121996.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. From iliali16 at gmail.com Tue Mar 18 11:00:31 2008 From: iliali16 at gmail.com (iliali16) Date: Tue Mar 18 10:57:16 2008 Subject: [Haskell-cafe] Converting image2PS function Message-ID: <16122095.post@talk.nabble.com> Hi guys again just want to ask you I have this function ready -- Creates a Postscript file from an Image -- page shows -200 <= x <= 200, 300 <= y <= 300 -- boundaries, plus origin plotted on output image2PS:: Image -> String -> IO() image2PS (Image contents) filename = writeFile filename (header++contents++footer) where header = unlines ["%!PS-Adobe-3.1" ,"%%BoundingBox: 100 125 500 725" ,"%%PageOrder: Ascend" ,"%%Pages: 1" ,"%%BeginDocument" ,"%%Page: 1 1" ,"100 125 moveto 500 125 lineto 500 725 lineto 100 725 lineto closepath gsave stroke grestore clip" ,"275 425 moveto 50 0 rlineto stroke" ,"300 400 moveto 0 50 rlineto stroke" ] footer = unlines ["showpage" ,"%%EndDocument" ] but when I use it for example image2PS spiral iliali it tells me that the iliali is undefined. What do you thing how should I use it. Thanks in advance! PS: I need to know how this works so that I make a similar function that converts logo2PS since I have a Logo spiral and I want to see it in PostScript. Thanks again! -- View this message in context: http://www.nabble.com/Converting-image2PS-function-tp16122095p16122095.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. From daniel.is.fischer at web.de Tue Mar 18 11:49:49 2008 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Tue Mar 18 11:44:56 2008 Subject: [Haskell-cafe] Converting image2PS function In-Reply-To: <16122095.post@talk.nabble.com> References: <16122095.post@talk.nabble.com> Message-ID: <200803181649.49657.daniel.is.fischer@web.de> Am Dienstag, 18. M?rz 2008 16:00 schrieb iliali16: > Hi guys again just want to ask you I have this function ready > but when I use it for example > > image2PS spiral iliali > > it tells me that the iliali is undefined. What do you thing how should I > use it. Thanks in advance! image2PS spiral "iliali" should work. String literals are enclosed in double quotes. > > PS: I need to know how this works so that I make a similar function that > converts logo2PS since I have a Logo spiral and I want to see it in > PostScript. Thanks again! From rendel at rbg.informatik.tu-darmstadt.de Tue Mar 18 11:57:34 2008 From: rendel at rbg.informatik.tu-darmstadt.de (Tillmann Rendel) Date: Tue Mar 18 11:53:08 2008 Subject: [Haskell-cafe] Converting image2PS function In-Reply-To: <16122095.post@talk.nabble.com> References: <16122095.post@talk.nabble.com> Message-ID: <47DFE66E.2090305@rbg.informatik.tu-darmstadt.de> iliali16 wrote: > I have this function ready > > image2PS:: Image -> String -> IO() > > but when I use it for example > > image2PS spiral iliali > > it tells me that the iliali is undefined. iliali is a variable, which has to be bound so it can be used, e.g. iliali = "iliali" main = image2PS spiral iliali alternatively, you can use a literal string (enclosed in double quotes) directly: main = image2PS spiral "iliali" Tillmann From agl at imperialviolet.org Tue Mar 18 11:57:52 2008 From: agl at imperialviolet.org (Adam Langley) Date: Tue Mar 18 11:54:38 2008 Subject: [Haskell-cafe] Re: all threads are blocked by recvFrom In-Reply-To: References: <396556a20803140757w1ac429e3q6655078e30961a4e@mail.gmail.com> <396556a20803141013w6ba1271bjc2ea1bbd9c80b729@mail.gmail.com> <396556a20803171006k3d84e585l735a4403894966cf@mail.gmail.com> Message-ID: <396556a20803180857l48cbfeb8lf0b73105f0730179@mail.gmail.com> On Tue, Mar 18, 2008 at 3:41 AM, Vitaliy Akimov wrote: > Unfortunally this way seems to be wrong. Error codes for winsockets > and BSD-sockets are different. Hmm, "Networking broken on Windows" would seem to be a pretty big issue. One of the Windows peeps like to speak up here? AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org From iliali16 at gmail.com Tue Mar 18 12:09:43 2008 From: iliali16 at gmail.com (iliali16) Date: Tue Mar 18 12:06:30 2008 Subject: [Haskell-cafe] Converting image2PS function In-Reply-To: <200803181649.49657.daniel.is.fischer@web.de> References: <16122095.post@talk.nabble.com> <200803181649.49657.daniel.is.fischer@web.de> Message-ID: <16124595.post@talk.nabble.com> Thanks very much Daniel Fischer-4 wrote: > > Am Dienstag, 18. M?rz 2008 16:00 schrieb iliali16: >> Hi guys again just want to ask you I have this function ready > >> but when I use it for example >> >> image2PS spiral iliali >> >> it tells me that the iliali is undefined. What do you thing how should I >> use it. Thanks in advance! > > image2PS spiral "iliali" > > should work. String literals are enclosed in double quotes. >> >> PS: I need to know how this works so that I make a similar function that >> converts logo2PS since I have a Logo spiral and I want to see it in >> PostScript. Thanks again! > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -- View this message in context: http://www.nabble.com/Converting-image2PS-function-tp16122095p16124595.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. From jgbailey at gmail.com Tue Mar 18 12:41:15 2008 From: jgbailey at gmail.com (Justin Bailey) Date: Tue Mar 18 12:38:01 2008 Subject: [Haskell-cafe] Dynamic typing makes you more productive? Message-ID: >From a recent interview[1] with the guy leading Ruby development on .NET at Microsoft: "You spend less time writing software than you spend maintaining software. Optimizing for writing software versus maintaining software is probably the wrong thing to do. Static typing makes it harder to maintain software because it's harder to change it." Two years ago I would have agreed with that statement. Now - no way. Make the compiler work for you. I've done a lot of Ruby development and I would never use it for a project of more than 3 or 4 people. It's an awesome language but I don't think it would scale to programming "in the large." Any object can be modified at any time. Determining where a particular method comes from can be an exercise in Sherlockian deduction. Give an organization of 100 developers that much freedom and I can only imagine chaos would result. Justin [1] http://www.regdeveloper.co.uk/2008/03/17/ironruby_work_schedule/ From vitaliy.akimov at gmail.com Tue Mar 18 12:51:02 2008 From: vitaliy.akimov at gmail.com (Vitaliy Akimov) Date: Tue Mar 18 12:47:48 2008 Subject: [Haskell-cafe] Re: all threads are blocked by recvFrom In-Reply-To: <396556a20803180857l48cbfeb8lf0b73105f0730179@mail.gmail.com> References: <396556a20803140757w1ac429e3q6655078e30961a4e@mail.gmail.com> <396556a20803141013w6ba1271bjc2ea1bbd9c80b729@mail.gmail.com> <396556a20803171006k3d84e585l735a4403894966cf@mail.gmail.com> <396556a20803180857l48cbfeb8lf0b73105f0730179@mail.gmail.com> Message-ID: It's not an issue of error codes. Though error code of WSAEWOULDBLOCK and EAGAIN is different this is not the problem. You've posted a link to preprocessed source code. And there is no implementation of throwErrnoIfMinus1Retry_repeatOnBlock for Windows. This function for Windows treat WSAEWOULDBLOCK as error, and it doesn't have loop for its correct processing. It's not a surprise since the socket isn't supposed to be blocked on windows. Here is source code with setting socket to non-blocking mode [1]. It terminates with error: > UdpEcho.exe: recvFrom: failed (Resource temporarily unavailable (WSAEWOULDBLOCK)) [1] http://hpaste.org/6476 Vitaliy. 2008/3/18, Adam Langley : > On Tue, Mar 18, 2008 at 3:41 AM, Vitaliy Akimov > > wrote: > > > Unfortunally this way seems to be wrong. Error codes for winsockets > > and BSD-sockets are different. > > > Hmm, "Networking broken on Windows" would seem to be a pretty big > issue. One of the Windows peeps like to speak up here? > > > AGL > > > -- > Adam Langley agl@imperialviolet.org http://www.imperialviolet.org > From blancolioni at gmail.com Tue Mar 18 12:55:41 2008 From: blancolioni at gmail.com (Fraser Wilson) Date: Tue Mar 18 12:52:27 2008 Subject: [Haskell-cafe] Dynamic typing makes you more productive? In-Reply-To: References: Message-ID: I find it interesting that "change" is equated with "maintenance". I would say that maintenance is a very small subset of change. It's true that you can change a program in a dynamically typed language more easily, in the same way that changes are easier to make if you don't use source control and everybody shares the same source folder. Changes that improve things, however, are more tricky. And as you say, a large multiple developer, dynamically typed project sounds like a disaster. (Of course, I don't have to tell any of you this) cheers, Fraser. On Tue, Mar 18, 2008 at 5:41 PM, Justin Bailey wrote: > >From a recent interview[1] with the guy leading Ruby development on > .NET at Microsoft: > > "You spend less time writing software than you spend maintaining > software. Optimizing for writing software versus maintaining software > is probably the wrong thing to do. Static typing makes it harder to > maintain software because it's harder to change it." > > Two years ago I would have agreed with that statement. Now - no way. > Make the compiler work for you. I've done a lot of Ruby development > and I would never use it for a project of more than 3 or 4 people. > It's an awesome language but I don't think it would scale to > programming "in the large." Any object can be modified at any time. > Determining where a particular method comes from can be an exercise in > Sherlockian deduction. Give an organization of 100 developers that > much freedom and I can only imagine chaos would result. > > Justin > > [1] http://www.regdeveloper.co.uk/2008/03/17/ironruby_work_schedule/ > _______________________________________________ > 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/20080318/dd27b478/attachment.htm From jules at jellybean.co.uk Tue Mar 18 13:24:34 2008 From: jules at jellybean.co.uk (Jules Bean) Date: Tue Mar 18 13:21:19 2008 Subject: [Haskell-cafe] Dynamic typing makes you more productive? In-Reply-To: References: Message-ID: <47DFFAD2.2040802@jellybean.co.uk> Justin Bailey wrote: >>From a recent interview[1] with the guy leading Ruby development on > .NET at Microsoft: > > "You spend less time writing software than you spend maintaining > software. Optimizing for writing software versus maintaining software > is probably the wrong thing to do. Static typing makes it harder to > maintain software because it's harder to change it." It's interesting to say that, because not only is it completely untrue, but the opposite is in fact true. I would make the following statement: "Static typing makes it easier to maintain software because it's easier to change it". When you change the type of something in a program (be it statically dynamically typed) you have to change all uses of it. If your program is dynamically typed, you have to work very hard to make sure you catch all instances, perhaps by having an enormous test suite, perhaps by having a powerful IDE with semantically aware search and replace. A common source of bugs is making a partial change in this way, where a rarely-tested code path develops a semantic bug from a 'far-away change'. If your program is statically typed, the compiler tells you all the places you need to change. Job done. Therefore I find that generally speak change/refactoring is an order of magnitude easier in haskell than, say, ruby. Jules From derek.a.elkins at gmail.com Tue Mar 18 13:37:00 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Tue Mar 18 13:33:50 2008 Subject: [Haskell-cafe] Re: ANN: Parsec 3.0.0 In-Reply-To: <20080306173151.GA20692@berkeley.edu> References: <1204786736.5936.18.camel@derek-laptop> <20080306173151.GA20692@berkeley.edu> Message-ID: <1205861820.5533.11.camel@derek-laptop> On Thu, 2008-03-06 at 09:31 -0800, John MacFarlane wrote: > > * A "compatibility" Text.ParserCombinators.Parsec tree for the old > > Parsec. It's not perfect, but it should work with most Parsec 2 > > code. > > A data point: I recompiled pandoc with the new Text.ParserCombinators.Parsec > compatibility module, and performance is much worse than with > parsec 2.1 (approximately twice as slow on my standard benchmark). > > That aside, this is a very welcome release! Yes, a speed hit is currently expected. I don't believe Paolo Martini did any performance tuning and I know I didn't so currently using parsec3 as a parsec2 drop-in is expected to be slower due to more abstraction/parameterization. However, one benefit (it should be a benefit, if not I want to know!) is that you can switch to bytestrings if possible and that should hopefully itself add quite a boost in speed. Now that -something- is out there, I intend to see what I can do about performance and am interested in any examples that run slower than one would expect. I have some ideas for improving performance, so hopefully this will get better in later releases. From rw at nelianur.org Tue Mar 18 11:03:15 2008 From: rw at nelianur.org (Rene Wagner) Date: Tue Mar 18 13:43:54 2008 Subject: [Haskell-cafe] build recent(ish) ghc on macos 10.3.9 powerpc? In-Reply-To: <65d7a7e0803151404j275690b5pfe4951f37cb9dc5b@mail.gmail.com> References: <65d7a7e0803151404j275690b5pfe4951f37cb9dc5b@mail.gmail.com> Message-ID: <1205852595.4150.14.camel@tephra.nelianur.org> Hi Uwe, On Sat, 2008-03-15 at 14:04 -0700, Uwe Hollerbach wrote: > I'm trying > for now to build ghc 6.6.1 -- so I started by upgrading gcc to 3.4.6. > That's working. So, with that in place, I went to the "porting ghc to > a new arch" page and started going through the steps. I'm using a > laptop running linux as the "host" computer, so that's > i386-unknown-linux, some Fedora core derivative. It's using gcc 3.4.4. > > I think I did all the initial stuff right, but in the section in the > porting guide where it says to start diving into all the > subdirectories and do a bunch of "make boot && make", I start getting > errors, and by the time it says to do that in .../libraries, it just > croaks. I did a GHC 6.6 bootstrap for Debian/armel a while ago and ran into some minor issues with regard to slight inaccuracies in the documentation and glitches in the GHC build system. A brief overview of what I did is given in a message I sent to the debian-arm list. Unfortunately, I never got around to sending a detailed report upstream :( http://lists.debian.org/debian-arm/2007/11/msg00038.html I don't know how much of that is applicable when building for a non-linux target, but perhaps it gives you a few pointers. Alternatively, you could make build logs/error messages available, so we can perhaps figure out what's going wrong together. Regards, Rene -- Rene Wagner rw at nelianur dot org http://nelianur.org From haskell at list.mightyreason.com Tue Mar 18 14:07:07 2008 From: haskell at list.mightyreason.com (ChrisK) Date: Tue Mar 18 14:04:00 2008 Subject: [Haskell-cafe] Re: Dynamic typing makes you more productive? In-Reply-To: <47DFFAD2.2040802@jellybean.co.uk> References: <47DFFAD2.2040802@jellybean.co.uk> Message-ID: <47E004CB.2020006@list.mightyreason.com> Jules Bean wrote: > Justin Bailey wrote: >>> From a recent interview[1] with the guy leading Ruby development on >> .NET at Microsoft: >> >> "You spend less time writing software than you spend maintaining >> software. Optimizing for writing software versus maintaining software >> is probably the wrong thing to do. Static typing makes it harder to >> maintain software because it's harder to change it." > > It's interesting to say that, because not only is it completely untrue, > but the opposite is in fact true. I would make the following statement: > > "Static typing makes it easier to maintain software because it's easier > to change it". It depends on type inferencing and tool support. If you change a type in Java (or C++) then you will have to change its declaration at each point of use in the project. This is only easy with tool support. In Ruby or Python there are few declarations to change -- but you have to be sure it is safe. In Haskell, the type inference meas there are few declarations to change -- and it catches all the unsafe usages. If you have many declarations then you are going to wish for more tool support. > > When you change the type of something in a program (be it statically > dynamically typed) you have to change all uses of it. If your program is > dynamically typed, you have to work very hard to make sure you catch all > instances, perhaps by having an enormous test suite, perhaps by having a > powerful IDE with semantically aware search and replace. A common source > of bugs is making a partial change in this way, where a rarely-tested > code path develops a semantic bug from a 'far-away change'. > > If your program is statically typed, the compiler tells you all the > places you need to change. Job done. > > Therefore I find that generally speak change/refactoring is an order of > magnitude easier in haskell than, say, ruby. > > Jules From bulat.ziganshin at gmail.com Tue Mar 18 13:58:21 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue Mar 18 14:11:35 2008 Subject: [Haskell-cafe] Dynamic typing makes you more productive? In-Reply-To: References: Message-ID: <492539690.20080318205821@gmail.com> Hello Justin, Tuesday, March 18, 2008, 7:41:15 PM, you wrote: > is probably the wrong thing to do. Static typing makes it harder to > maintain software because it's harder to change it." > Two years ago I would have agreed with that statement. Now - no way. f few weeks ago i made a post to main haskell list about static duck typing: type inference + flexible structure types created by use -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From dons at galois.com Tue Mar 18 14:47:56 2008 From: dons at galois.com (Don Stewart) Date: Tue Mar 18 14:44:43 2008 Subject: [Haskell-cafe] Dynamic typing makes you more productive? In-Reply-To: References: Message-ID: <20080318184756.GA301@scytale.galois.com> jgbailey: > >From a recent interview[1] with the guy leading Ruby development on > .NET at Microsoft: > > "You spend less time writing software than you spend maintaining > software. Optimizing for writing software versus maintaining software > is probably the wrong thing to do. Static typing makes it harder to > maintain software because it's harder to change it." > > Two years ago I would have agreed with that statement. Now - no way. > Make the compiler work for you. I've done a lot of Ruby development > and I would never use it for a project of more than 3 or 4 people. > It's an awesome language but I don't think it would scale to > programming "in the large." Any object can be modified at any time. > Determining where a particular method comes from can be an exercise in > Sherlockian deduction. Give an organization of 100 developers that > much freedom and I can only imagine chaos would result. > > Justin Agreed, maintainability is all about restricting the damage people can do, and making refactoring safer :) The kind of havoc a new programmer can create in a pure, strongly typed, polymorphic chunk of code is tiny compared to an "anything goes" language scenario. -- Don From nominolo at googlemail.com Tue Mar 18 15:00:04 2008 From: nominolo at googlemail.com (Thomas Schilling) Date: Tue Mar 18 14:56:59 2008 Subject: [Haskell-cafe] Dynamic typing makes you more productive? In-Reply-To: <20080318184756.GA301@scytale.galois.com> References: <20080318184756.GA301@scytale.galois.com> Message-ID: On 18 mar 2008, at 19.47, Don Stewart wrote: > jgbailey: >>> From a recent interview[1] with the guy leading Ruby development on >> .NET at Microsoft: >> >> "You spend less time writing software than you spend maintaining >> software. Optimizing for writing software versus maintaining software >> is probably the wrong thing to do. Static typing makes it harder to >> maintain software because it's harder to change it." >> >> Two years ago I would have agreed with that statement. Now - no way. >> Make the compiler work for you. I've done a lot of Ruby development >> and I would never use it for a project of more than 3 or 4 people. >> It's an awesome language but I don't think it would scale to >> programming "in the large." Any object can be modified at any time. >> Determining where a particular method comes from can be an >> exercise in >> Sherlockian deduction. Give an organization of 100 developers that >> much freedom and I can only imagine chaos would result. >> >> Justin > > Agreed, maintainability is all about restricting the damage people > can do, and making refactoring safer :) > > The kind of havoc a new programmer can create in a pure, strongly > typed, > polymorphic chunk of code is tiny compared to an "anything goes" > language scenario. > Well, that kind of sounds like new programmer = bad programmer (as you talk about damage prevention). I guess you don't mean it that way, but I think it's worth to try to make it clear that static typing can help programmers new to the code easily check where things are used and gives them the confidence that their changes won't introduce unintended side effects. A careless programmer can still break the whole program, just use "head" in a sufficiently hidden place, so it's not about preventing people from wreaking havoc to your code base *on purpose* but rather to give them a safety net. I think this is a common misconception in static vs. dynamic flame wars -- static typing is often dismissed as not trusting the programmer and overly constraining his/her latitude. / Thomas From ryani.spam at gmail.com Tue Mar 18 15:03:40 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Tue Mar 18 15:00:25 2008 Subject: [Haskell-cafe] Re: Type parameters in type families In-Reply-To: <7b92c2840803171559s6f640aecq9405795c5d091369@mail.gmail.com> References: <7b92c2840803171504p407fda12x61a6304bbfc277ce@mail.gmail.com> <7b92c2840803171559s6f640aecq9405795c5d091369@mail.gmail.com> Message-ID: <2f9b2d30803181203w6563610cya7acbd8a0e6daf75@mail.gmail.com> On 3/17/08, Hugo Pacheco wrote: > On the other side, it fails to compile when this signature is explicit: > fff :: forall d x. (FunctorF d) => d -> F d x -> F d x > fff a = fmapF a id Interestingly, this works when you also give a type signature to "id": fff :: forall d x. (FunctorF d) => d -> F d x -> F d x fff a = fmapF a (id :: x -> x) compiles for me (ghc6.8.2). There's probably a bug in the type checker; inference is working with no type signatures, but checking fails. From donn at avvanta.com Tue Mar 18 15:04:53 2008 From: donn at avvanta.com (Donn Cave) Date: Tue Mar 18 15:01:39 2008 Subject: [Haskell-cafe] Dynamic typing makes you more productive? In-Reply-To: References: <20080318184756.GA301@scytale.galois.com> Message-ID: <42A7C020-E9DD-4B52-84E2-BFB77691B267@avvanta.com> On Mar 18, 2008, at 12:00 PM, Thomas Schilling wrote: > ... I think it's worth to try to make it clear that static typing > can help programmers new to the code easily check where things are > used and gives them the confidence that their changes won't > introduce unintended side effects. It's `enabling', or `empowering' if we're still using that word. Donn From gmh at Cs.Nott.AC.UK Tue Mar 18 15:10:32 2008 From: gmh at Cs.Nott.AC.UK (Graham Hutton) Date: Tue Mar 18 15:10:31 2008 Subject: [Haskell-cafe] Two Lectureships in Nottingham Message-ID: <27049.1205867432@cs.nott.ac.uk> Dear all, We are advertising two new Lectureships (Assistant Professorships) in Computer Science at the University of Nottingham in England. Applications in the area of functional programming are particularly welcome. Further details are available from: http://jobs.nottingham.ac.uk/vacancies.aspx?cat=160#j2797 The closing date for applications is 28th March 2008. Best wishes, Graham Hutton +-----------------------------------------------------------------+ | Dr Graham Hutton Email : gmh@cs.nott.ac.uk | | School of Computer Science | | University of Nottingham Web : www.cs.nott.ac.uk/~gmh | | Jubilee Campus, Wollaton Road | | Nottingham NG8 1BB, UK Phone : +44 (0)115 951 4220 | +-----------------------------------------------------------------+ 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 iahogsp at gmail.com Tue Mar 18 15:26:50 2008 From: iahogsp at gmail.com (Isto Aho) Date: Tue Mar 18 15:23:36 2008 Subject: [Haskell-cafe] type families, fun deps, lattices imposed on/by types In-Reply-To: <961358DE-AEDA-4581-9B8E-0E26D5AE8263@cse.unsw.edu.au> References: <470880360803161249s6dd5a8c2m79cdb3a73412a5a8@mail.gmail.com> <961358DE-AEDA-4581-9B8E-0E26D5AE8263@cse.unsw.edu.au> Message-ID: <470880360803181226m269e714bqfecf0dbf97f5ad0e@mail.gmail.com> Hi & thanks for your answers Manuel, Using your idea of separating the lattice and conversion from the > definition of multiplication, you can at least save yourself the class > instances: Ok type family Join a b :: * Aah, meet and join but of course - memory memory memory seems to get easily corrupted... :) is more flexible, as I am sure there are other applications, where we > don't want a lattice, but some other structure. Yes, and then there can be cases where we don't know exactly, what we want or there are situations where two almost but not identical structures are needed. http://www.cse.unsw.edu.au/~pls/thesis/aja-thesis.pdf > Thanks again! I'll try to read it quite soon. -- br, Isto -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080318/b3a81e73/attachment.htm From jeremy at n-heptane.com Tue Mar 18 15:36:08 2008 From: jeremy at n-heptane.com (Jeremy Shaw) Date: Tue Mar 18 15:32:49 2008 Subject: [Haskell-cafe] Dynamic typing makes you more productive? In-Reply-To: References: Message-ID: <87bq5besev.wl%jeremy@n-heptane.com> At Tue, 18 Mar 2008 09:41:15 -0700, Justin Bailey wrote: > > >From a recent interview[1] with the guy leading Ruby development on > .NET at Microsoft: > > "You spend less time writing software than you spend maintaining > software. Optimizing for writing software versus maintaining software > is probably the wrong thing to do. Static typing makes it harder to > maintain software because it's harder to change it." > > Two years ago I would have agreed with that statement. Now - no way. I like to imagine it works like this: bad static type < dynamic typing < good static typing. Whenever someone says, dynamic typing is better than static typing -- just insert 'bad' in there and what they say actually makes a bit of sense ;) Since most programmers have never experienced a good static type system, it think it is fair to assume they are comparing dynamic typing to bad static typing -- unless they indicate otherwise. People also tend to mistake features commonly found in dynamically typed languages with things which could only be done in statically typed languages. For example, users of many popular dynamically typed languages like to be able to load code into an interpreter and run bits and pieces of it to test things out. This is obviously not a property of dynamically typed languages, since GHCi and hugs can do it as well. Many coverts to dynamic languages like to be able to just start coding with out having to first declare a bunch of stuff in .h files. But, of course, in Haskell you can just start writing code -- no type signatures or header files require. In this particular case, the ruby developer is attempting to attract attention and money to their project. The most likely converts are going to be Java, C++, and C# users. In that context, I suppose the claim that dynamic typing is better than (bad) static typing, could be true for some class of projects... j. From _ at whats-your.name Tue Mar 18 15:54:31 2008 From: _ at whats-your.name (carmen) Date: Tue Mar 18 15:51:35 2008 Subject: [Haskell-cafe] Dynamic typing makes you more productive? In-Reply-To: References: Message-ID: <20080318195431.GC3105@m.hsd1.ma.comcast.net> > > is probably the wrong thing to do. Static typing makes it harder to > > maintain software because it's harder to change it." ive found Ruby code is harder to change. you have to invest a significant amount of time duplicating virtually every expression in your entire system in test-form (with mocks, stubs, asserts, runtime-reflection comparisons etc) just to get something approaching the youd get from rigorous static-analysis/typechecking tooling. plus it all assumes you wrote your tests perfectly, and you have to invest time learning the various tools (all the needs here are at least as much mental load as learning about typeclasses) for that, etc. if you don't do all that, theres the nagging feeling that something may have broken somewhere. and theres still that possibility, given all the possibilities with instance_eval, module_eval, method aliasing, even module include order (its difficult/impossible to figure out where a function came from, which version it is, etc). the ultimate solution i think is an enhanced/sandboxed interpreter/VM which gives you a readout of all the possible type errors that _could_ occur at runtime, given all the runtime dynamism thats allowed. i should investigate what SmallTalk has come up with, but lack the time/funding/reinvention-interest to re-create all this for Ruby, especially as it would involve becoming intimately faimilar with Rubinius and/or MRI as well.. ive also found it virtually impossible to change other people's code since it requires getting used to their metaprogramming style and tricks, but maybe using _why's projects arent a good indicator of the greater Ruby community. ive seen plenty of Ruby code that reads almost like Java, and i wonder why they would even bother when they can get a much faster VM and better tools (especially wrt refactoring) by just going all the way. change might be easier, on paper, by a few characters. if you ignore all sorts of real factors. From lgreg.meredith at biosimilarity.com Tue Mar 18 15:59:05 2008 From: lgreg.meredith at biosimilarity.com (Greg Meredith) Date: Tue Mar 18 15:55:52 2008 Subject: [Haskell-cafe] NW Functional Programming Interest Group In-Reply-To: <5de3f5ca0802011155l771cc649wa0e671bbe3abe364@mail.gmail.com> References: <5de3f5ca0802011155l771cc649wa0e671bbe3abe364@mail.gmail.com> Message-ID: <5de3f5ca0803181259g5b8126deob020d86fd22cbd0d@mail.gmail.com> All, Apologies for multiple listings. A small cadre of us are organizing a Northwest Functional Programming Interest Group (hey... NWFPIG, that's kinda funny). Our next meeting is at the The Seattle Public Library 1000 - 4th Ave. Seattle, WA 98104 from 18:30 - 20:00 on March 19th. On this meeting's agenda - i'll give a highly idiosyncratic talk about the Curry-Howard isomorphism - followed an informal discussion section 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/20080318/ba3e2bd0/attachment.htm From potter at southwestern.edu Tue Mar 18 16:43:21 2008 From: potter at southwestern.edu (Walt Potter) Date: Tue Mar 18 16:40:11 2008 Subject: [Haskell-cafe] intersection of sets Message-ID: <82A17246-6B47-4E5F-87DB-9BCB54AFC031@southwestern.edu> All, We're running out of space when we intersect two large sets. We've imported Data.Set. Any suggestions? Thanks, Walt From vigalchin at gmail.com Tue Mar 18 16:43:55 2008 From: vigalchin at gmail.com (Galchin Vasili) Date: Tue Mar 18 16:40:41 2008 Subject: [Haskell-cafe] Satnam Singh of Microsoft Research Message-ID: <5ae4f2ba0803181343h22021ff2mf37aa9c44aa7a750@mail.gmail.com> Hello, Recently Satnam Singh of Microsoft Research gave a talk at Google about concurrency, Haskell STM, etc. Was there a transcript of this talk? Thanks, Vasili -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080318/efdc9307/attachment.htm From catamorphism at gmail.com Tue Mar 18 17:17:31 2008 From: catamorphism at gmail.com (Tim Chevalier) Date: Tue Mar 18 17:14:15 2008 Subject: [Haskell-cafe] intersection of sets In-Reply-To: <82A17246-6B47-4E5F-87DB-9BCB54AFC031@southwestern.edu> References: <82A17246-6B47-4E5F-87DB-9BCB54AFC031@southwestern.edu> Message-ID: <4683d9370803181417q3b57cd7ehe95ebfa4ff18574c@mail.gmail.com> On 3/18/08, Walt Potter wrote: > All, > We're running out of space when we intersect two large sets. We've > imported Data.Set. > Any suggestions? > What optimization and other compiler flags (heap size, etc.) are you using? Have you tried profiling? Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "Live fast, love hard, and wear corrective lenses if you need them." --Webb Wilder From agl at imperialviolet.org Tue Mar 18 17:41:21 2008 From: agl at imperialviolet.org (Adam Langley) Date: Tue Mar 18 17:38:07 2008 Subject: [Haskell-cafe] Satnam Singh of Microsoft Research In-Reply-To: <5ae4f2ba0803181343h22021ff2mf37aa9c44aa7a750@mail.gmail.com> References: <5ae4f2ba0803181343h22021ff2mf37aa9c44aa7a750@mail.gmail.com> Message-ID: <396556a20803181441iac8415fs789acf1018602f7a@mail.gmail.com> 2008/3/18 Galchin Vasili : > Recently Satnam Singh of Microsoft Research gave a talk at Google about > concurrency, Haskell STM, etc. Was there a transcript of this talk? Do you have the exact date of this talk? I can't see that anyone called Satnam has given a talk at Google. (It might have been very informal, in which case there wouldn't be a record of it, and nor would there be a video) Cheers, AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org From catamorphism at gmail.com Tue Mar 18 17:54:01 2008 From: catamorphism at gmail.com (Tim Chevalier) Date: Tue Mar 18 17:50:45 2008 Subject: [Haskell-cafe] intersection of sets In-Reply-To: <47E03809.7060505@southwestern.edu> References: <82A17246-6B47-4E5F-87DB-9BCB54AFC031@southwestern.edu> <4683d9370803181417q3b57cd7ehe95ebfa4ff18574c@mail.gmail.com> <47E03809.7060505@southwestern.edu> Message-ID: <4683d9370803181454w6a72b8b6i39c2e8c5c2635172@mail.gmail.com> [ccing to list] On 3/18/08, Walt Potter wrote: > Tim, > > We're using -O2 to optimize, but not changing the heap size. We're > trying to get the profiling running on our file. > The sets have about 25 million elements each. Each element is a sequence > of length 16. > > We'll want to compute larger examples! > > I do not know how intersection works in Data.Set. I'm worried that we're > having problems with stack overflow due to recursion. We'll try to > remove the lazy stuff. > Run profiling before you "try to remove the lazy stuff". There's no point in trying to optimize code until you know what's actually taking up space. If you have problems with profiling, then ask on the glasgow-haskell-users mailing list. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "Aw, honey, you can keep what's in my pockets, but send me back my pants." --Greg Brown From vigalchin at gmail.com Tue Mar 18 18:16:22 2008 From: vigalchin at gmail.com (Galchin Vasili) Date: Tue Mar 18 18:13:06 2008 Subject: [Haskell-cafe] Satnam Singh of Microsoft Research In-Reply-To: <396556a20803181441iac8415fs789acf1018602f7a@mail.gmail.com> References: <5ae4f2ba0803181343h22021ff2mf37aa9c44aa7a750@mail.gmail.com> <396556a20803181441iac8415fs789acf1018602f7a@mail.gmail.com> Message-ID: <5ae4f2ba0803181516r1fa9383fq8b6081f50598e4fd@mail.gmail.com> oops ... my bad ... it was at Standford's CS dept on Feb 29 at 1:30: This presentation describes a variety of ways to write parallel and concurrent programs in the lazy functional language Haskell. We start off by introducing par/pseq annotations which provide guidance to the run-time about how work can be performed speculatively which provides a basic mechanism for writing implicitly parallel programs. We then describe how a library of strategies can be used to force specific evaluation orders which are necessary to exploit parallelism. We then go on to describe the basic mechanism for writing explicitly parallel programs using Haskell's lightweight threads and then we describe how Haskell's STM implementation can help to write programs that share state between threads through the use of a special monads and as an example we describe the implementation of a multi-way rendezvous library. We then describe some work with Tim Harris on feedback directed implicit parallelism which provides yet another way to write implicitly parallel programs with out resorting to par/pseq annotations. Finally, we report on the progress of a nested data parallel library for Haskell inspired by the NESL language. Throughout the talk we shall emphasizes how Haskell's pure nature (with side effecting operations clearly indicated by the type system) facilitates the exploitation of parallelism. It would be great to get more than the above! Regards. Vasili On 3/18/08, Adam Langley wrote: > > 2008/3/18 Galchin Vasili : > > Recently Satnam Singh of Microsoft Research gave a talk at Google > about > > concurrency, Haskell STM, etc. Was there a transcript of this talk? > > Do you have the exact date of this talk? I can't see that anyone > called Satnam has given a talk at Google. > > (It might have been very informal, in which case there wouldn't be a > record of it, and nor would there be a video) > > > Cheers, > > AGL > > -- > Adam Langley agl@imperialviolet.org http://www.imperialviolet.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080318/dda38956/attachment.htm From cjb at laptop.org Tue Mar 18 18:31:15 2008 From: cjb at laptop.org (Chris Ball) Date: Tue Mar 18 18:27:14 2008 Subject: [Haskell-cafe] Re: Satnam Singh of Microsoft Research In-Reply-To: <5ae4f2ba0803181516r1fa9383fq8b6081f50598e4fd@mail.gmail.com> (Galchin Vasili's message of "Tue, 18 Mar 2008 17:16:22 -0500") References: <5ae4f2ba0803181343h22021ff2mf37aa9c44aa7a750@mail.gmail.com> <396556a20803181441iac8415fs789acf1018602f7a@mail.gmail.com> <5ae4f2ba0803181516r1fa9383fq8b6081f50598e4fd@mail.gmail.com> Message-ID: <86myov8y18.fsf@pullcord.laptop.org> Hi, > It would be great to get more than the above! The "Feedback Directed Implicit Parallelism" part is available in a paper from ICFP 2007: http://research.microsoft.com/~tharris/papers/2007-fdip.pdf There might be papers online for the other segments of the talk, too. - Chris. -- Chris Ball From ajb at spamcop.net Tue Mar 18 20:14:30 2008 From: ajb at spamcop.net (ajb@spamcop.net) Date: Tue Mar 18 20:11:13 2008 Subject: [Haskell-cafe] Dynamic typing makes you more productive? In-Reply-To: <87bq5besev.wl%jeremy@n-heptane.com> References: <87bq5besev.wl%jeremy@n-heptane.com> Message-ID: <20080318201430.127k9vo5c0sco44o@webmail.spamcop.net> G'day all. Quoting Jeremy Shaw : > I like to imagine it works like this: > > bad static type < dynamic typing < good static typing. More succinctly: Algol < Smalltalk < ML Or perhaps: C < Ruby < Haskell Cheers, Andrew Bromage From jon at ffconsultancy.com Tue Mar 18 21:43:12 2008 From: jon at ffconsultancy.com (Jon Harrop) Date: Tue Mar 18 21:39:09 2008 Subject: [Haskell-cafe] Dynamic typing makes you more productive? In-Reply-To: <20080318201430.127k9vo5c0sco44o@webmail.spamcop.net> References: <87bq5besev.wl%jeremy@n-heptane.com> <20080318201430.127k9vo5c0sco44o@webmail.spamcop.net> Message-ID: <200803190143.12988.jon@ffconsultancy.com> On Wednesday 19 March 2008 00:14:30 ajb@spamcop.net wrote: > Quoting Jeremy Shaw : > > I like to imagine it works like this: > > > > bad static type < dynamic typing < good static typing. > > More succinctly: > > Algol < Smalltalk < ML > > Or perhaps: > > C < Ruby < Haskell What are the requirements to make static typing "good"? Is it type inference? If so, is Scala's type inference enough? Are polymorphic variants necessary? Type classes? -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e From john at repetae.net Tue Mar 18 21:49:14 2008 From: john at repetae.net (John Meacham) Date: Tue Mar 18 21:45:58 2008 Subject: [Haskell-cafe] Dynamic typing makes you more productive? In-Reply-To: <20080318201430.127k9vo5c0sco44o@webmail.spamcop.net> References: <87bq5besev.wl%jeremy@n-heptane.com> <20080318201430.127k9vo5c0sco44o@webmail.spamcop.net> Message-ID: <20080319014914.GK14807@sliver.repetae.net> My current set of tools are Haskell / \ Perl --- C I often use all three in one project. I think they complement each other well as they are all relative extremes in their genre. John -- John Meacham - ?repetae.net?john? From uhollerbach at gmail.com Tue Mar 18 22:11:45 2008 From: uhollerbach at gmail.com (Uwe Hollerbach) Date: Tue Mar 18 22:08:29 2008 Subject: [Haskell-cafe] build recent(ish) ghc on macos 10.3.9 powerpc? In-Reply-To: <65d7a7e0803181248w4b2cc661m10eeff34137f6217@mail.gmail.com> References: <65d7a7e0803151404j275690b5pfe4951f37cb9dc5b@mail.gmail.com> <1205852595.4150.14.camel@tephra.nelianur.org> <65d7a7e0803181248w4b2cc661m10eeff34137f6217@mail.gmail.com> Message-ID: <65d7a7e0803181911q76b8e0b3gd9c39e68eb141065@mail.gmail.com> Hello, haskellers, a few days ago I had asked about building recent ghc on macos 10.3.9. I have made a bit of progress along those lines, here's a small update on what worked and what didn't. Instead of trying to proceed with the porting procedure, I went back to an install: I ended up going to 6.2.2. After a bit of fiddling, I found that another bit of messing-about I had done to the machine was messing me up: I had upgraded gcc from 3.3.x to 3.4.6 by just downloading the sources and building. That produced a working gcc 3.4.6, but apparently the apple-aware ghc 6.2.2 and the apple-unaware gcc 3.4.6 didn't play nicely together. Once I disabled gcc 3.4.6, stuff worked again. Then I tried building ghc 6.4.2 using the installed 6.2.2. This took a lot of time, the compiler was able (as far as I could tell) to go through all of its own bootstrapping, but after I happily installed what I thought was a working ghc 6.4.2, the installed version was unable to do anything: it segfaulted while trying to do "ghc --version". Oops... Out of somewhat morbid curiosity, I tried running that inside the debugger, but gave up after several hours of elapsed time. Back to the drawing board. So I tried jumping directly from 6.2.2 to 6.6.1; that is, using 6.2.2 to build 6.6.1. That took another lot of time, but I'm happy to report that it has produced a working executable: it did proceed all the way through its bootstrapping, I verified that the executable in compiler/stage2 was able to run "ghc --version" in-place, and after I installed it, it was still able to do that; and (extra bonus! :-) ) it's also able to compile and link at least one small Haskell program written by me! Cool! I'm going to keep going forward and try to build 6.8.2, and I'll report back if that succeeds, but this is already pretty good progress... regards, Uwe From mad.one at gmail.com Wed Mar 19 02:12:18 2008 From: mad.one at gmail.com (Austin Seipp) Date: Wed Mar 19 02:09:00 2008 Subject: [Haskell-cafe] Re: HFuse: ls fails in HelloFS In-Reply-To: <47DD227C.208@willthompson.co.uk> References: <1205550042-sup-1361@continuum> <47DD227C.208@willthompson.co.uk> Message-ID: <1205906992-sup-8266@continuum> Excerpts from Will Thompson's message of Sun Mar 16 08:37:00 -0500 2008: > Currently the module's name is HFuse. Presumably it really belongs > under System somewhere; System.Posix.Fuse maybe? What do folks think? > Are there any guidelines for picking a namespace? I don't think there's any sort of doc on picking a namespace or how to logically name your package modules (would likely be worth writing); for something like this, I would say something under System.Posix.* would be the most appropriate. -- "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 allbery at ece.cmu.edu Wed Mar 19 02:43:27 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Wed Mar 19 02:40:10 2008 Subject: [Haskell-cafe] Re: HFuse: ls fails in HelloFS In-Reply-To: <1205906992-sup-8266@continuum> References: <1205550042-sup-1361@continuum> <47DD227C.208@willthompson.co.uk> <1205906992-sup-8266@continuum> Message-ID: On Mar 19, 2008, at 2:12 , Austin Seipp wrote: > Excerpts from Will Thompson's message of Sun Mar 16 08:37:00 -0500 > 2008: >> Currently the module's name is HFuse. Presumably it really belongs >> under System somewhere; System.Posix.Fuse maybe? What do folks >> think? >> Are there any guidelines for picking a namespace? > > I don't think there's any sort of doc on picking a namespace or how to > logically name your package modules (would likely be worth writing); > for something like this, I would say something under System.Posix.* > would be the most appropriate. Erm, "POSIX" does not mean "Linux and sufficiently similar systems". FUSE is supported by open source Unixlikes, not by POSIX compliant systems in general. -- 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 Wed Mar 19 03:11:03 2008 From: dons at galois.com (Don Stewart) Date: Wed Mar 19 03:07:52 2008 Subject: [Haskell-cafe] Re: HFuse: ls fails in HelloFS In-Reply-To: <1205906992-sup-8266@continuum> References: <1205550042-sup-1361@continuum> <47DD227C.208@willthompson.co.uk> <1205906992-sup-8266@continuum> Message-ID: <20080319071103.GC2351@scytale.galois.com> mad.one: > Excerpts from Will Thompson's message of Sun Mar 16 08:37:00 -0500 2008: > > Currently the module's name is HFuse. Presumably it really belongs > > under System somewhere; System.Posix.Fuse maybe? What do folks think? > > Are there any guidelines for picking a namespace? > > I don't think there's any sort of doc on picking a namespace or how to > logically name your package modules (would likely be worth writing); > for something like this, I would say something under System.Posix.* > would be the most appropriate. Ah, but there is! http://haskell.org/haskellwiki/Hierarchical_module_names Enjoy! -- Don (grumbler of packages that use uncommon top level names) From dekudekuplex at yahoo.com Wed Mar 19 03:48:46 2008 From: dekudekuplex at yahoo.com (Benjamin L. Russell) Date: Wed Mar 19 03:45:30 2008 Subject: [Haskell-cafe] Any ideas for "->" (function type) in a simply-typed lambda calculus version of Brett Victor's Alligator Eggs game? Message-ID: <220158.22285.qm@web30204.mail.mud.yahoo.com> Brett Victor has invented an Alligator Eggs game (very loosely resembling Conway's Game of Life), using formal rules to determine feeding and breeding patterns for alligators and their eggs, but the game represents the *untyped* lambda calculus: Alligator Eggs! http://worrydream.com/AlligatorEggs/ I am interested in adapting this to the *simply typed* lambda calculus with Curry-style typing, to aid students of Haskell. Brett Victor's game currently aids students of LISP, and I think that it would be helpful to have a Haskell counterpart (see http://wadler.blogspot.com/2007/05/oh-no-alligators.html for a comment on how the Alligator Eggs game has been used by EE students at Caltech in learning LISP): Simply typed lambda calculus - Wikipedia, the free encyclopedia http://en.wikipedia.org/wiki/Simply_typed_lambda_calculus Thereafter, I would like to create a new entry for this Haskell version of Alligator Eggs on HaskellWiki, and create a link to it under a new subsection, "Board Games," under the current "Learning Haskell" category: http://www.haskell.org/haskellwiki/Learning_Haskell In Brett Victor's version, the following representations hold: * a hungry alligator: lambda abstraction * an old alligator: a pair of parentheses * an egg: a variable * the Eating Rule: beta-reduction * the Color Rule: (over-cautious) alpha-conversion * the Old Age Rule: the rule that a pair of parentheses containing a single term may be removed However, in thinking about how to adapt the game, I am not quite sure how to incorporate the representation of "->" (function type): * ???: "->" (function type) What ideas, if any, would anybody have on how "->" (function type) could be represented in a simply-typed lambda calculus version of Brett Victor's Alligator Eggs? Benjamin L. Russell From ccshan at post.harvard.edu Sun Mar 16 21:18:49 2008 From: ccshan at post.harvard.edu (Chung-chieh Shan) Date: Wed Mar 19 06:57:11 2008 Subject: [Haskell-cafe] Re: "GADT" rhymes with "cat" References: <20080316023450.j5kpairr40sg4wk0@webmail.spamcop.net> <14d615330803160256y12382aeem553196132ab42ba0@mail.gmail.com> <20080316060135.r9v6u6dkgsg00ow0@webmail.spamcop.net> Message-ID: ajb@spamcop.net wrote in article <20080316060135.r9v6u6dkgsg00ow0@webmail.spamcop.net> in gmane.comp.lang.haskell.cafe: > Quoting Jeremy Apthorp : > > Clearly, this pronounciation is "gay dee tea." I always new those > > types were a bit queer. > Not that there's anything wrong with that. ... If it type-checks, it must be correct! I thought the "t" was silent as well, an unaspirated stop? Egad! -- Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig Is mathematics a syntax of language? From loppermann at acm.org Wed Mar 19 08:17:55 2008 From: loppermann at acm.org (Lars Oppermann) Date: Wed Mar 19 08:14:37 2008 Subject: [Haskell-cafe] Scoping in template haskell Message-ID: Hi all, I am trying to get familiar with template haskell and I'm wondering whether the following is possible and if so, how it would be done properly... I have two templates, and I'd like to use one from the other. For instance the first one might be gen1 :: Int -> ExpQ gen1 i = [| "<<" ++ (show i) ++ ">>" |] Thus, I gould do > $(gen1 42) and I'd get "<<42>>" now I'd like to use gen2 in another generated expression so that I could so > $(gen2 [42, 66]) and get "<<42>><<66>>" My naive intention was to write gen2 :: [Int] -> ExpQ gen2 is = [| map (\x -> $(gen1 x)) is |] which gives me "Stage error: `x' is bound at stage 2 but used at stage 1 So I guess my actual question would be: how do I pass a variable bound outside a quotation into another splice used in that quotation? Bests, Lars From phil at kantaka.co.uk Wed Mar 19 09:31:26 2008 From: phil at kantaka.co.uk (Philip Armstrong) Date: Wed Mar 19 09:28:09 2008 Subject: [Haskell-cafe] Dynamic typing makes you more productive? In-Reply-To: References: Message-ID: <20080319133126.GB8869@kantaka.co.uk> On Tue, Mar 18, 2008 at 09:41:15AM -0700, Justin Bailey wrote: >Two years ago I would have agreed with that statement. Now - no way. >Make the compiler work for you. I've done a lot of Ruby development >and I would never use it for a project of more than 3 or 4 people. >It's an awesome language but I don't think it would scale to >programming "in the large." Any object can be modified at any time. >Determining where a particular method comes from can be an exercise in >Sherlockian deduction. Give an organization of 100 developers that >much freedom and I can only imagine chaos would result. It looks from the outside like Ruby is going through some growing pains as a result of the excerise of "too much freedom" at the moment. But I wouldn't write Ruby off on account of that: an interesting article I read recently made the comparision with Emacs lisp which offers a similar level of power to the programmer, in that pretty much any function can be redefined at any point, and yet it has a thriving culture of Emacs extensions, all written by disparate people who manage not to step on each other's toes. IOW, it's a cultural issue as well as a language issue. Ruby programmers will no doubt develop their own culture of what is and isn't "allowed" in publically available extensions just as Emacs lisp programmers have. Phil -- http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt From donnie at darthik.com Wed Mar 19 10:04:49 2008 From: donnie at darthik.com (Donnie Jones) Date: Wed Mar 19 10:01:32 2008 Subject: [Haskell-cafe] Satnam Singh of Microsoft Research In-Reply-To: <5ae4f2ba0803181516r1fa9383fq8b6081f50598e4fd@mail.gmail.com> References: <5ae4f2ba0803181343h22021ff2mf37aa9c44aa7a750@mail.gmail.com> <396556a20803181441iac8415fs789acf1018602f7a@mail.gmail.com> <5ae4f2ba0803181516r1fa9383fq8b6081f50598e4fd@mail.gmail.com> Message-ID: Hello, I contacted Satnam Singh about this talk and we tried to arrange with Stanford to video record the presentation, but it was not possible on the short notice... __ Donnie On 3/18/08, Galchin Vasili wrote: > > oops ... my bad ... it was at Standford's CS dept on Feb 29 at 1:30: > > > This presentation describes a variety of ways to write parallel and > concurrent programs in the lazy functional language Haskell. We start off by > introducing par/pseq annotations which provide guidance to the run-time > about how work can be performed speculatively which provides a basic > mechanism for writing implicitly parallel programs. We then describe how a > library of strategies can be used to force specific evaluation orders which > are necessary to exploit parallelism. We then go on to describe the basic > mechanism for writing explicitly parallel programs using Haskell's > lightweight threads and then we describe how Haskell's STM implementation > can help to write programs that share state between threads through the use > of a special monads and as an example we describe the implementation of a > multi-way rendezvous library. We then describe some work with Tim Harris on > feedback directed implicit parallelism which provides yet another way to > write implicitly parallel programs with out resorting to par/pseq > annotations. Finally, we report on the progress of a nested data parallel > library for Haskell inspired by the NESL language. Throughout the talk we > shall emphasizes how Haskell's pure nature (with side > effecting operations clearly indicated by the type system) facilitates the > exploitation of parallelism. > > It would be great to get more than the above! > > Regards. > > Vasili > > > > > > > On 3/18/08, Adam Langley wrote: > > > > 2008/3/18 Galchin Vasili : > > > Recently Satnam Singh of Microsoft Research gave a talk at Google > > about > > > concurrency, Haskell STM, etc. Was there a transcript of this talk? > > > > Do you have the exact date of this talk? I can't see that anyone > > called Satnam has given a talk at Google. > > > > (It might have been very informal, in which case there wouldn't be a > > record of it, and nor would there be a video) > > > > > > Cheers, > > > > AGL > > > > -- > > Adam Langley agl@imperialviolet.org http://www.imperialviolet.org > > > > > _______________________________________________ > 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/20080319/371dd501/attachment.htm From stevelihn at gmail.com Wed Mar 19 11:59:33 2008 From: stevelihn at gmail.com (Steve Lihn) Date: Wed Mar 19 11:56:15 2008 Subject: [Haskell-cafe] Satnam Singh of Microsoft Research In-Reply-To: References: <5ae4f2ba0803181343h22021ff2mf37aa9c44aa7a750@mail.gmail.com> <396556a20803181441iac8415fs789acf1018602f7a@mail.gmail.com> <5ae4f2ba0803181516r1fa9383fq8b6081f50598e4fd@mail.gmail.com> Message-ID: Related news -- Intel, Microsoft choose UC-Berkeley to host $10M parallel computing center March 19, 2008 8:36 AM ET http://news.moneycentral.msn.com/provider/providerarticle.aspx?feed=ACBJ&date=20080319&id=8361298 From claus.reinke at talk21.com Wed Mar 19 12:53:00 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Wed Mar 19 12:49:49 2008 Subject: [Haskell-cafe] Equality constraints in type families References: <7b92c2840803101651x3673691eid310ab137805eeff@mail.gmail.com> Message-ID: <00bf01c889e1$b34639b0$b9387ad5@cr3lt> >> type family F a :: * -> * .. > We made the design > choice that type functions with a higher-kinded result type must be > injective with respect to the additional paramters. I.e. in your case: > > F x y ~ F u v <=> F x ~ F u /\ y ~ v i'm still trying to understand this remark: - if we are talking about "type functions", i should be allowed to replace a function application with its result, and if that result doesn't mention some parameters, they shouldn't play a role at any stage, right? - if anything other than the function result matters, isn't it somewhat misleading to speak of "type functions"? - if the parameters have to match irrespective of whether they appear in the result, that sounds like phantom types. ok, but we're talking about a system that mixes unification with rewriting, so shouldn't the phantom parameters be represented in all rewrite results, just to make sure they cannot be ignored in any contexts? ie, with type instance F a = F a x should rewrite not to , but to _x, which would take care of the injectivity you want in the ~-case, but would also preserve the distinction if rewriting should come before ~, even if managed to consume x, by being a constant function on types. - things seem to be going wrong in the current implementation. consider this code, accepted by GHCi, version 6.9.20080317: ------------------------------------------ {-# LANGUAGE TypeFamilies #-} type family Const a :: * -> * type instance Const a = C a type C a t = a f :: Const Bool Int -> Const Bool Char -> Const Bool Bool f i c = False -- f i c = i f i c = i && True f i c = (i || c) ------------------------------------------ (note the partially applied type synonym in the type instance, which is a constant function on types). it looks as if: - False::Bool is accepted as Const Bool Bool - i::Const Bool Int is accepted as Bool - c::Const Bool Char is accepted as Bool - both i and c are accepted as Bool, so seem to be of an equivalent type, but aren't really.. - i::Const Bool Int is not accepted as Const Bool Char directly, but is accepted via one of the "eta expansions" for Bool, namely (&&True) my current guess is that the implementation is incomplete, but that the idea of "type functions" also needs to be adjusted to take your design decision into account, with "phantom types" and type parameter annotations for type function results suggesting themselves as potentially helpful concepts? or, perhaps, the implication isn't quite correct, and type parameters shouldn't be unified unless they appear in the result of applying the type function? the implementation would still be incomplete, but instead of rejecting more of the code, it should allow the commented-out case as well? could you please help me to clear up this confusion?-) thanks, claus From Tom.Schrijvers at cs.kuleuven.be Wed Mar 19 13:21:22 2008 From: Tom.Schrijvers at cs.kuleuven.be (Tom Schrijvers) Date: Wed Mar 19 13:19:06 2008 Subject: [Haskell-cafe] Equality constraints in type families In-Reply-To: <00bf01c889e1$b34639b0$b9387ad5@cr3lt> References: <7b92c2840803101651x3673691eid310ab137805eeff@mail.gmail.com> <00bf01c889e1$b34639b0$b9387ad5@cr3lt> Message-ID: > could you please help me to clear up this confusion?-) Let me summarize :-) The current design for type functions with result kinds other than * (e.g. * -> *) has not gotten very far yet. We are currently stabilizing the ordinary * type functions, and writing the story up. When that's done we can properly focus on this issue and consider different design choices. Cheers, Tom -- Tom Schrijvers Department of Computer Science K.U. Leuven Celestijnenlaan 200A B-3001 Heverlee Belgium tel: +32 16 327544 e-mail: tom.schrijvers@cs.kuleuven.be url: http://www.cs.kuleuven.be/~toms/ From claus.reinke at talk21.com Wed Mar 19 13:23:59 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Wed Mar 19 13:20:47 2008 Subject: [Haskell-cafe] Equality constraints in type families References: <7b92c2840803101651x3673691eid310ab137805eeff@mail.gmail.com> <00bf01c889e1$b34639b0$b9387ad5@cr3lt> Message-ID: <00cf01c889e6$06ae9fd0$b9387ad5@cr3lt> >>> type family F a :: * -> * > .. >> We made the design >> choice that type functions with a higher-kinded result type must be >> injective with respect to the additional paramters. I.e. in your case: >> >> F x y ~ F u v <=> F x ~ F u /\ y ~ v actually, i don't even understand the first part of that:-( why would F x and F u have to be the same functions? shouldn't it be sufficient for them to have the same result, when applied to y and v, respectively? consider: -------------------------------------- type family G1 a :: * -> * type instance G1 a = G3 type family G2 a :: * -> * type instance G2 a = G4 type family G3 a :: * type instance G3 Bool = Bool type instance G3 Char = Bool type family G4 a :: * type instance G4 Bool = Char type instance G4 Char = Bool h :: G1 a Bool ~ G2 a Char => G1 a Bool h = True -------------------------------------- for which GHCi, version 6.9.20080317 happily infers *Main> :t h h :: G1 a Bool *Main> h True even though G1 a ~ G3 ~/~ G4 ~ G2 a ? claus > i'm still trying to understand this remark: > > - if we are talking about "type functions", i should be allowed > to replace a function application with its result, and if that > result doesn't mention some parameters, they shouldn't > play a role at any stage, right? > > - if anything other than the function result matters, isn't it > somewhat misleading to speak of "type functions"? > > - if the parameters have to match irrespective of whether > they appear in the result, that sounds like phantom types. > > ok, but we're talking about a system that mixes unification > with rewriting, so shouldn't the phantom parameters be > represented in all rewrite results, just to make sure they > cannot be ignored in any contexts? > > ie, with > > type instance F a = > > F a x should rewrite not to , but to _x, > which would take care of the injectivity you want in the > ~-case, but would also preserve the distinction if > rewriting should come before ~, even if managed > to consume x, by being a constant function on types. > > - things seem to be going wrong in the current implementation. > consider this code, accepted by GHCi, version 6.9.20080317: > ------------------------------------------ > {-# LANGUAGE TypeFamilies #-} > > type family Const a :: * -> * > type instance Const a = C a > type C a t = a > > f :: Const Bool Int -> Const Bool Char -> Const Bool Bool > f i c = False > -- f i c = i > f i c = i && True > f i c = (i || c) > ------------------------------------------ > > (note the partially applied type synonym in the type instance, > which is a constant function on types). it looks as if: > > - False::Bool is accepted as Const Bool Bool > - i::Const Bool Int is accepted as Bool > - c::Const Bool Char is accepted as Bool > - both i and c are accepted as Bool, so seem to be of > an equivalent type, but aren't really.. > - i::Const Bool Int is not accepted as Const Bool Char > directly, but is accepted via one of the "eta expansions" > for Bool, namely (&&True) > > my current guess is that the implementation is incomplete, > but that the idea of "type functions" also needs to be adjusted > to take your design decision into account, with "phantom types" > and type parameter annotations for type function results > suggesting themselves as potentially helpful concepts? > > or, perhaps, the implication isn't quite correct, and > type parameters shouldn't be unified unless they appear > in the result of applying the type function? the implementation > would still be incomplete, but instead of rejecting more of the > code, it should allow the commented-out case as well? > > could you please help me to clear up this confusion?-) > > thanks, > claus > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From aeyakovenko at gmail.com Wed Mar 19 13:25:14 2008 From: aeyakovenko at gmail.com (Anatoly Yakovenko) Date: Wed Mar 19 13:21:57 2008 Subject: [Haskell-cafe] ghc 6.8.2 and timer_create error Message-ID: I have a gentoo box with ghc 6.8.2, and the binaries that ghc builds on that box do not work on redhat EL 4 or ubuntu 7.10. When I try to run the binary, i get an error: Main: timer_create: Invalid argument so is there any way to get ghc to build a binary that doesn't use timer_create? or is that something that is configured when ghc itself is built, if so, how do I turn that feature off? Thanks From ryani.spam at gmail.com Wed Mar 19 13:46:54 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Wed Mar 19 13:43:35 2008 Subject: [Haskell-cafe] Scoping in template haskell In-Reply-To: References: Message-ID: <2f9b2d30803191046w19f735afn35fe3d07fb80d0ef@mail.gmail.com> First off, the first code isn't doing exactly what you think; gen1 3, for example, generates the parse tree: "<<" ++ show 3 ++ ">>" You can improve this in the following way: gen1 i = let x = "<<" ++ show i ++ ">>" in [| x |] which generates (for gen1 3, again) ['<', '<', '3', '>', '>'] Alternatively, you can generate the expression directly: gen1 i = LitE $ StringE $ "<<" ++ show i ++ ">>" which gives you exactly the parse tree "<<3>>". Now, the compiler will definitely treat the last two the same, but I'm not sure it will constant-fold "show 3" into "3" in your case. The "runQ" trick is really useful; in ghci; just use runQ with the code that you want to generate: > :set -fth > :m +Language.Haskell.TH > runQ [| "<<42>><<66>>" |] LitE (StringL "<<42>><<66>>") You then just need to figure out how to make that object from the inputs you have. Also, here's something simple to try: appendStrQ :: [ExpQ] -> ExpQ appendStrQ = foldr (\x rest -> [| $(x) ++ $(rest) |]) [| "" |] gen2 = appendStrQ . map gen1 -- ryan On Wed, Mar 19, 2008 at 5:17 AM, Lars Oppermann wrote: > Hi all, > > I am trying to get familiar with template haskell and I'm wondering > whether the following is possible and if so, how it would be done > properly... > > I have two templates, and I'd like to use one from the other. For > instance the first one might be > > gen1 :: Int -> ExpQ > gen1 i = [| "<<" ++ (show i) ++ ">>" |] > > Thus, I gould do > > > $(gen1 42) > > and I'd get "<<42>>" > > now I'd like to use gen2 in another generated expression so that I could so > > > $(gen2 [42, 66]) > > and get "<<42>><<66>>" > > My naive intention was to write > > gen2 :: [Int] -> ExpQ > gen2 is = [| map (\x -> $(gen1 x)) is |] > > which gives me "Stage error: `x' is bound at stage 2 but used at stage 1 > > So I guess my actual question would be: how do I pass a variable bound > outside a quotation into another splice used in that quotation? > > Bests, > Lars > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From ryani.spam at gmail.com Wed Mar 19 13:50:34 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Wed Mar 19 13:47:17 2008 Subject: [Haskell-cafe] Scoping in template haskell In-Reply-To: <2f9b2d30803191046w19f735afn35fe3d07fb80d0ef@mail.gmail.com> References: <2f9b2d30803191046w19f735afn35fe3d07fb80d0ef@mail.gmail.com> Message-ID: <2f9b2d30803191050r3b92cc8eo5b4eac58a2c72dc8@mail.gmail.com> On Wed, Mar 19, 2008 at 10:46 AM, Ryan Ingram wrote: > gen1 i = LitE $ StringE $ "<<" ++ show i ++ ">>" Oops, two mistakes here: 1) StringE should be StringL 2) splices need to be in the Q monad. To fix (2), you can either add a "return" here, or, there are conveniently lowercase constructors for much of TH that return results in the Q monad: > gen1 i = return $ LitE $ StringL $ "<<" ++ show i ++ ">>" or > gen1 i = litE $ StringL $ "<<" ++ show i ++ ">>" From Christian.Maeder at dfki.de Wed Mar 19 13:51:20 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Wed Mar 19 13:48:05 2008 Subject: [Haskell-cafe] Re: ghc 6.8.2 and timer_create error In-Reply-To: References: Message-ID: <47E15298.6070000@dfki.de> This was discussed in http://www.haskell.org/pipermail/glasgow-haskell-users/2008-March/014498.html Your final guess is correct. #undef HAVE_TIMER_CREATE and/or USE_TIMER_CREATE in mk/config.h HTH Christian Anatoly Yakovenko wrote: > I have a gentoo box with ghc 6.8.2, and the binaries that ghc builds > on that box do not work on redhat EL 4 or ubuntu 7.10. When I try to > run the binary, i get an error: > > Main: timer_create: Invalid argument > > so is there any way to get ghc to build a binary that doesn't use > timer_create? or is that something that is configured when ghc itself > is built, if so, how do I turn that feature off? > > Thanks From marc.lisp at gmail.com Wed Mar 19 13:55:03 2008 From: marc.lisp at gmail.com (Marc Mertens) Date: Wed Mar 19 13:56:48 2008 Subject: [Haskell-cafe] Using HaskellDb to connect to PostgresSql Message-ID: Hello, I'm trying to learn to use HaskellDb. I have managed to finally compile and install it on my linux box (I have ghc 6.8.2). But when I try to create a database description (as described in http://haskelldb.sourceforge.net/getting-started.html) (using DBDirect-dynamic instead of DBDirect) I'm stuck. I have tried different names for the driver but I always get the message 'DBDirect-dynamic: user error (Missing field driver)'. Has someone get this working for PostgresSQL and if so, can he/she help me out with some instructions. Also if someone has some pointers to more recent documentation of HaskellDB, I would really be pleased if I could get these. Marc Mertens From waterson at maubi.net Wed Mar 19 14:09:00 2008 From: waterson at maubi.net (Chris Waterson) Date: Wed Mar 19 14:05:44 2008 Subject: [Haskell-cafe] libmad and os/x coreaudio wrappers Message-ID: <2388A41C-8F5D-42B5-8DB8-DDB2E9984E1E@maubi.net> Hi there! I've taken my first stab at writing some (admittedly minimal) libraries for Haskell, and would love to get feedback on them: * hmad: a wrapper for the libmad MP3 decoder. http://maubi.net/~waterson/REPO/hmad * CoreAudio: a wrapper for OS/X CoreAudio. http://maubi.net/~waterson/REPO/CoreAudio (You should be able to "darcs get" the above links, if you want.) I wrote the libmad wrapper to generate a "stream" (i.e., a lazy list) of audio samples. CoreAudio allows the input stream to be lazy, as well. So, here's a simple MP3 player: > module Main where > > import Sound.CoreAudio > import Codec.Audio.MP3.Mad > import qualified Data.ByteString.Lazy as B > import System > import System.IO > > main :: IO () > main = do files <- getArgs > mapM_ playFile files > > playFile :: String -> IO () > playFile file = > withBinaryFile file ReadMode $ \ inHandle -> > do xs <- B.hGetContents inHandle > samples <- decode xs > play samples I do have a couple questions... * The CoreAudio library requires its users to be compiled with "-threaded". Is there a way to specify that in the Cabal file? * I wanted to be able to generate a variety of streams from libmad. Besides stereo linear PCM data, it also seemed like it might be worth-while to produce a stream of MP3 frame headers, the unsynthesized frequency domain data, and so on. I tried to accomplish this with a the DecoderSink class, but I'm not sure I succeeded. Any thoughts here would be appreciated! I hope someone else finds these useful. The FFI was a joy to use once I figured it out... :) chris From claus.reinke at talk21.com Wed Mar 19 15:14:15 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Wed Mar 19 15:11:02 2008 Subject: [Haskell-cafe] Equality constraints in type families References: <7b92c2840803101651x3673691eid310ab137805eeff@mail.gmail.com><00bf01c889e1$b34639b0$b9387ad5@cr3lt> Message-ID: <00f501c889f5$6d805960$b9387ad5@cr3lt> > Let me summarize :-) > > The current design for type functions with result kinds other than * > (e.g. * -> *) has not gotten very far yet. We are currently stabilizing > the ordinary * type functions, and writing the story up. When that's done > we can properly focus on this issue and consider different design choices. thanks, seems i was too optimistic, then!-) btw, i noticed that the user guide points to the haskell wiki only, while the latest info seems to be on the ghc wiki. given the number of variations and the scope of development, it would also be helpful if the user guide had at least a one-paragraph executive summary of the state of play, dated to clarify how up-to-date that summary is. that would avoid discussions of not yet stabilized features (should ghc issue a warning when such are used?). claus From jgbailey at gmail.com Wed Mar 19 15:32:46 2008 From: jgbailey at gmail.com (Justin Bailey) Date: Wed Mar 19 15:29:28 2008 Subject: [Haskell-cafe] Using HaskellDb to connect to PostgresSql In-Reply-To: References: Message-ID: On Wed, Mar 19, 2008 at 10:55 AM, Marc Mertens wrote: > Hello, > > I'm trying to learn to use HaskellDb. I have managed to finally compile and > install it on my linux box (I have ghc 6.8.2). But when I try to create a > database description (as described in > http://haskelldb.sourceforge.net/getting-started.html) (using DBDirect-dynamic > instead of DBDirect) I'm stuck. I have tried different names for the driver but > I don't have much information about using DBDynamic, but I am able to connect to PostgreSQL easily. I have done it on Windows using GHC 6.8.2. I am using hdbc-postgresql, since hsql would not compile on Windows for me. Here are the import statements and the login function I have for a simple program that connects to postgresql and writes out table info: import Database.HaskellDB.DBSpec.DatabaseToDBSpec import Database.HaskellDB.DBSpec.DBSpecToDBDirect import Database.HaskellDB.Database import Database.HaskellDB.HDBC.PostgreSQL import Database.HaskellDB.PrimQuery import Database.HaskellDB.FieldType import Database.HaskellDB.DBSpec login :: MonadIO m => String -> Int -> String -> String -> String -> (Database -> m a) -> m a login server port user password dbname = postgresqlConnect [("host", server), ("port", show port), ("user", user), ("password", password), ("dbname", dbname)] The versions of all packages I'm using are: HDBC-1.1.4 HDBC-postgresql-1.1.4.0 haskelldb-hdbc-0.10 haskelldb-hdbc-postgresql-0.10 Note you might have to modify the haskelldb cabal files to get them to use later versions of HDBC. As for recent documentation, unfortunately the darcs repository and the code is the best place to go. The haddock documentation doesn't have everything. Finally, I'd suggest joining the haskell-db users mailing list for specific questions. You can find info about that and the darcs repository on the homepage at http://haskelldb.sourceforge.net. Justin From gwern0 at gmail.com Wed Mar 19 15:37:22 2008 From: gwern0 at gmail.com (gwern0@gmail.com) Date: Wed Mar 19 15:35:15 2008 Subject: [Haskell-cafe] libmad and os/x coreaudio wrappers In-Reply-To: <2388A41C-8F5D-42B5-8DB8-DDB2E9984E1E@maubi.net> References: <2388A41C-8F5D-42B5-8DB8-DDB2E9984E1E@maubi.net> Message-ID: <20080319193449.GA281687@localhost> On 2008.03.19 11:09:00 -0700, Chris Waterson scribbled 1.7K characters: > Hi there! I've taken my first stab at writing some (admittedly > minimal) libraries for Haskell, and would love to get feedback on > them: > > * hmad: a wrapper for the libmad MP3 decoder. > http://maubi.net/~waterson/REPO/hmad > > * CoreAudio: a wrapper for OS/X CoreAudio. > http://maubi.net/~waterson/REPO/CoreAudio > > (You should be able to "darcs get" the above links, if you want.) > > I wrote the libmad wrapper to generate a "stream" (i.e., a lazy list) > of audio samples. CoreAudio allows the input stream to be lazy, as > well. So, here's a simple MP3 player: > > > module Main where > > > > import Sound.CoreAudio > > import Codec.Audio.MP3.Mad > > import qualified Data.ByteString.Lazy as B > > import System > > import System.IO > > > > main :: IO () > > main = do files <- getArgs > > mapM_ playFile files > > > > playFile :: String -> IO () > > playFile file = > > withBinaryFile file ReadMode $ \ inHandle -> > > do xs <- B.hGetContents inHandle > > samples <- decode xs > > play samples > > I do have a couple questions... > > * The CoreAudio library requires its users to be compiled with > "-threaded". Is there a way to specify that in the Cabal file? I don't think so. Actually, I asked dcoutts, and he said Cabal cannot make a user use a specified ghc-option:. Apparently it did once, but it was abused and got removed: "The only problem is that threaded applies to the final program. If a library declares that it needs threaded, does that mean we have to propagate the flag and use it with all programs that use it? Propagating GHC flags is not possible currently - by design. GHC used to have such a feature and it was removed. Or perhaps we say it's an extension that only applies to executables?" ... > chris -- gwern enigma main Warfare DREC Intiso cards kilderkin Crypto Waihopai Oscor -------------- 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/20080319/6b414d8f/attachment.bin From gwern0 at gmail.com Wed Mar 19 15:56:03 2008 From: gwern0 at gmail.com (gwern0@gmail.com) Date: Wed Mar 19 15:53:04 2008 Subject: [Haskell-cafe] Re: HFuse: ls fails in HelloFS In-Reply-To: References: <1205550042-sup-1361@continuum> <47DD227C.208@willthompson.co.uk> <1205906992-sup-8266@continuum> Message-ID: <20080319195603.GB281687@localhost> On 2008.03.19 02:43:27 -0400, "Brandon S. Allbery KF8NH" scribbled 0.8K characters: > > On Mar 19, 2008, at 2:12 , Austin Seipp wrote: > >> Excerpts from Will Thompson's message of Sun Mar 16 08:37:00 -0500 2008: >>> Currently the module's name is HFuse. Presumably it really belongs >>> under System somewhere; System.Posix.Fuse maybe? What do folks think? >>> Are there any guidelines for picking a namespace? >> >> I don't think there's any sort of doc on picking a namespace or how to >> logically name your package modules (would likely be worth writing); >> for something like this, I would say something under System.Posix.* >> would be the most appropriate. > > Erm, "POSIX" does not mean "Linux and sufficiently similar systems". FUSE > is supported by open source Unixlikes, not by POSIX compliant systems in > general. > > -- > brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com Not sure that's a useful distinction to make. Wikipedia says "FUSE is available for Linux, FreeBSD, NetBSD (as PUFFS), OpenSolaris and Mac OS X (as MacFUSE)." Linux, the BSDs, and Solaris are all pretty POSIX compliant, where they have not actually been officially certified by POSIX; OS X Leopard is surprisingly enough, certified - says "Leopard is an Open Brand UNIX 03 Registered Product, conforming to the SUSv3 and POSIX 1003.1 specifications for the C API, Shell Utilities, and Threads. Since Leopard can compile and run all your existing UNIX code, you can deploy it in environments that demand full conformance ? complete with hooks to maintain compatibility with existing software." Since there's no Filesystem.* hierarchy, what's wrong with System.Posix.FUSE.*? I know of no non-Posix systems that run FUSE... -- gwern enigma main Warfare DREC Intiso cards kilderkin Crypto Waihopai Oscor -------------- 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/20080319/a7a46256/attachment.bin From allbery at ece.cmu.edu Wed Mar 19 16:02:43 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Wed Mar 19 15:59:25 2008 Subject: [Haskell-cafe] Re: HFuse: ls fails in HelloFS In-Reply-To: <20080319195603.GB281687@localhost> References: <1205550042-sup-1361@continuum> <47DD227C.208@willthompson.co.uk> <1205906992-sup-8266@continuum> <20080319195603.GB281687@localhost> Message-ID: <27BB7C4F-8221-4146-B1BB-C39A0A4ECF46@ece.cmu.edu> On Mar 19, 2008, at 15:56 , gwern0@gmail.com wrote: > Not sure that's a useful distinction to make. Wikipedia says "FUSE > is available for Linux, FreeBSD, NetBSD (as PUFFS), OpenSolaris and > Mac OS X (as MacFUSE)." AIX? HP/UX? Older Solaris (which I have a bunch of here, and ghc is a right pain to get working on them because "all the world's a Linux")? POSIX was not invented for Linux/*BSD and systems that choose to emulate 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 hjgtuyl at chello.nl Wed Mar 19 16:47:52 2008 From: hjgtuyl at chello.nl (hjgtuyl@chello.nl) Date: Wed Mar 19 16:44:31 2008 Subject: [Haskell-cafe] Error handling in calculations Message-ID: L.S., When playing with exceptions, I noticed the following strangeness: *Main> 1 / 0 Infinity *Main> 1 `div` 0 *** Exception: divide by zero This is in GHCi 6.8.2; WinHugs Sep 2006 gives: Main> 1 / 0 1.#INF Main> 1 `div` 0 Program error: divide by zero Is this difference between fractional and integral calculation intentional? It makes error handling more difficult. -- Met vriendelijke groet, Henk-Jan van Tuyl -- http://functor.bamikanarie.com http://Van.Tuyl.eu/ -- From roma at ro-che.info Wed Mar 19 17:03:51 2008 From: roma at ro-che.info (Roman Cheplyaka) Date: Wed Mar 19 17:00:31 2008 Subject: [Haskell-cafe] Error handling in calculations In-Reply-To: References: Message-ID: <20080319210351.GA8455@home.ro-che.info> * hjgtuyl@chello.nl [2008-03-19 21:47:52+0100] > > L.S., > > When playing with exceptions, I noticed the following strangeness: > *Main> 1 / 0 > Infinity > *Main> 1 `div` 0 > *** Exception: divide by zero > > This is in GHCi 6.8.2; WinHugs Sep 2006 gives: > Main> 1 / 0 > 1.#INF > Main> 1 `div` 0 > > Program error: divide by zero > > Is this difference between fractional and integral calculation > intentional? It makes error handling more difficult. I think it's because in the first case you have floating-point overflow (which can happen not just in case of division by 0 and means some very-large number -- remember, you cannot distinguish 0 and 0.00..001) and in the second case it's just division by zero -- meaningless operation. -- Roman I. Cheplyaka :: http://ro-che.info/ ...being in love is totally punk rock... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080319/c40e3425/attachment.bin From chak at cse.unsw.edu.au Wed Mar 19 20:54:16 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Wed Mar 19 20:51:01 2008 Subject: [Haskell-cafe] Re: Type parameters in type families In-Reply-To: <2f9b2d30803181203w6563610cya7acbd8a0e6daf75@mail.gmail.com> References: <7b92c2840803171504p407fda12x61a6304bbfc277ce@mail.gmail.com> <7b92c2840803171559s6f640aecq9405795c5d091369@mail.gmail.com> <2f9b2d30803181203w6563610cya7acbd8a0e6daf75@mail.gmail.com> Message-ID: <563CB539-9A9C-4764-991B-B38506722DF4@cse.unsw.edu.au> Ryan Ingram: > On 3/17/08, Hugo Pacheco wrote: >> On the other side, it fails to compile when this signature is >> explicit: >> fff :: forall d x. (FunctorF d) => d -> F d x -> F d x >> fff a = fmapF a id > > Interestingly, this works when you also give a type signature to "id": > > fff :: forall d x. (FunctorF d) => d -> F d x -> F d x > fff a = fmapF a (id :: x -> x) > > compiles for me (ghc6.8.2). There's probably a bug in the type > checker; inference is working with no type signatures, but checking > fails. The type checker is alright. It is an issue that we need to explain better in the documentation, though. As a simple example consider, class C a where type F a :: * foo :: F a The only occurrence of 'a' here is as an argument of the type family F. However, as discussed in this thread, decomposition does not hold for the type-indicies of a type family. In other words, from F a ~ F b, we can *not* deduce a ~ b. You have got the same situation for the 'x' in type type of fff. BTW, the same applies if you code the example with FDs. class C a ca | a -> ca where foo :: ca which means, we have foo :: C a ca => ca Here 'a' only appears in the context and as 'a' appears on the lhs of the FD arrow, that leads to ambiguities. In summary, a type variable in a signature that appears *only* as part of type-indicies of type families leads to the same sort of ambiguities as a type variable that appears only in the context of a type signature. Manuel From Ben.Lippmeier at anu.edu.au Thu Mar 20 02:09:36 2008 From: Ben.Lippmeier at anu.edu.au (Ben Lippmeier) Date: Thu Mar 20 02:06:19 2008 Subject: [Haskell-cafe] ANN: The Disciplined Disciple Compiler - alpha 1 Message-ID: <47E1FFA0.1090404@anu.edu.au> Hi All, I'm pleased to announce the initial alpha release of the Disciplined Disciple Compiler (DDC). Disciple is an explicitly lazy dialect of Haskell which includes: - first class destructive update of arbitrary data. - computational effects without the need for state monads. - type directed field projections. All this and more through the magic of effect typing. More information (and download!) available from: http://www.haskell.org/haskellwiki/DDC or http://code.google.com/p/disciple DDC: more than lambdas. Onward! Ben. From simonpj at microsoft.com Thu Mar 20 04:02:10 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu Mar 20 03:58:50 2008 Subject: [Haskell-cafe] ANNOUNCE: wxHaskell 0.10.3 rc1 In-Reply-To: <1205315421.15905.1241945927@webmail.messagingengine.com> References: <1205315421.15905.1241945927@webmail.messagingengine.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AB9A145A6@EA-EXMSG-C334.europe.corp.microsoft.com> Congratulations! wxHaskell is v cool but was suffering from lack of loving care. I'm delighted that it not only has a new team, but that you've pushed through to delivering a release. Brilliant. Simon | -----Original Message----- | From: haskell-cafe-bounces@haskell.org [mailto:haskell-cafe- | bounces@haskell.org] On Behalf Of Jeremy O'Donoghue | Sent: 12 March 2008 09:50 | To: haskell-cafe@haskell.org | Cc: wxhaskell-users@lists.sourceforge.net | Subject: [Haskell-cafe] ANNOUNCE: wxHaskell 0.10.3 rc1 | | We are pleased to announce the first release candidate of wxHaskell | 0.10.3. From loppermann at acm.org Thu Mar 20 05:23:46 2008 From: loppermann at acm.org (Lars Oppermann) Date: Thu Mar 20 05:20:26 2008 Subject: [Haskell-cafe] Scoping in template haskell In-Reply-To: <2f9b2d30803191050r3b92cc8eo5b4eac58a2c72dc8@mail.gmail.com> References: <2f9b2d30803191046w19f735afn35fe3d07fb80d0ef@mail.gmail.com> <2f9b2d30803191050r3b92cc8eo5b4eac58a2c72dc8@mail.gmail.com> Message-ID: Thanks for pointing me in the right direction... especially the mentioning of lowercase constructors helped a lot. I'll clean up my actual code (creating XML representation of record-style datatypes) a bit and post it. Maybe you or someone else has some comments. Bests, Lars On Wed, Mar 19, 2008 at 6:50 PM, Ryan Ingram wrote: > On Wed, Mar 19, 2008 at 10:46 AM, Ryan Ingram wrote: > > gen1 i = LitE $ StringE $ "<<" ++ show i ++ ">>" > > Oops, two mistakes here: > 1) StringE should be StringL > 2) splices need to be in the Q monad. > > To fix (2), you can either add a "return" here, or, there are > conveniently lowercase constructors for much of TH that return results > in the Q monad: > > gen1 i = return $ LitE $ StringL $ "<<" ++ show i ++ ">>" > or > > gen1 i = litE $ StringL $ "<<" ++ show i ++ ">>" > From g9ks157k at acme.softbase.org Thu Mar 20 10:08:59 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Thu Mar 20 10:07:05 2008 Subject: [Haskell-cafe] Re: [Haskell] ANN: The Disciplined Disciple Compiler - alpha 1 In-Reply-To: <47E1FFA0.1090404@anu.edu.au> References: <47E1FFA0.1090404@anu.edu.au> Message-ID: <200803201508.59413.g9ks157k@acme.softbase.org> Am Donnerstag, 20. M?rz 2008 07:09 schrieb Ben Lippmeier: > Hi All, > I'm pleased to announce the initial alpha release > of the Disciplined Disciple Compiler (DDC). > > Disciple is an explicitly lazy dialect of Haskell which includes: > - first class destructive update of arbitrary data. > - computational effects without the need for state monads. > - type directed field projections. > > All this and more through the magic of effect typing. > > More information (and download!) available from: > http://www.haskell.org/haskellwiki/DDC > or http://code.google.com/p/disciple > > DDC: more than lambdas. > > Onward! > Ben. Short question: Is it appropriate to put the homepage of a non-Haskell project on the Haskell Wiki? I mean, putting some basic info about such a project there and link to the project?s website might be okay and is already done in certain cases. But projects like Agda or Epigram typically don?t use haskell.org as a webspace provider and I think this is the way to go. What do others think? Best wishes, Wolfgang From Anurag.Verma at motorola.com Thu Mar 20 10:10:11 2008 From: Anurag.Verma at motorola.com (Verma Anurag-VNF673) Date: Thu Mar 20 10:09:41 2008 Subject: [Haskell-cafe] How to implement Read instance for user defined type Message-ID: Hi, I am trying to understand how to define instances for Read class for a user defined type. This is the sample code I wrote, but I am not able to get it correctly. So, let me know what's wrong with this program: module Mark where data Mark = Mark Int deriving (Show) instance Read Mark where readsPrec _ str = [(Mark x, t') | ("mark",t) <- reads str, (x,t') <- reads t When I run it in ghci: *Mark> reads "mark 5" :: [ (Mark,String)] ( I am intentionally using mark in lowercase) [] Why is the output coming out as [] as against expected output [(Mark 5, "")] ? -Anurag -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080320/6938f05f/attachment.htm From allbery at ece.cmu.edu Thu Mar 20 10:18:12 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Thu Mar 20 10:14:53 2008 Subject: [Haskell-cafe] Re: [Haskell] ANN: The Disciplined Disciple Compiler - alpha 1 In-Reply-To: <200803201508.59413.g9ks157k@acme.softbase.org> References: <47E1FFA0.1090404@anu.edu.au> <200803201508.59413.g9ks157k@acme.softbase.org> Message-ID: <0E538F0C-CA6B-4DA5-86FE-28D37622A857@ece.cmu.edu> On Mar 20, 2008, at 10:08 , Wolfgang Jeltsch wrote: > Am Donnerstag, 20. M?rz 2008 07:09 schrieb Ben Lippmeier: >> Hi All, >> I'm pleased to announce the initial alpha release >> of the Disciplined Disciple Compiler (DDC). >> > Short question: Is it appropriate to put the homepage of a non- > Haskell project > on the Haskell Wiki? Depends on how closely related it is, i.e. could this be considered a testbed for stuff that might end up in a future ghc release? -- 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 Thu Mar 20 10:22:29 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Mar 20 10:19:55 2008 Subject: [Haskell-cafe] Re: [Haskell] ANN: The Disciplined Disciple Compiler - alpha 1 In-Reply-To: <200803201508.59413.g9ks157k@acme.softbase.org> References: <47E1FFA0.1090404@anu.edu.au> <200803201508.59413.g9ks157k@acme.softbase.org> Message-ID: <1206022949.7594.142.camel@localhost> On Thu, 2008-03-20 at 15:08 +0100, Wolfgang Jeltsch wrote: > > More information (and download!) available from: > > http://www.haskell.org/haskellwiki/DDC > > or http://code.google.com/p/disciple > > > > DDC: more than lambdas. > Short question: Is it appropriate to put the homepage of a non-Haskell project > on the Haskell Wiki? I mean, putting some basic info about such a project > there and link to the project?s website might be okay and is already done in > certain cases. But projects like Agda or Epigram typically don?t use > haskell.org as a webspace provider and I think this is the way to go. What > do others think? I think it's fine. Agda and Epigram are not dialects of Haskell, DCC is. Also we tend to allow any project written in Haskell to use the haskellwiki, I don't see that compilers should be excluded. Duncan From jgbailey at gmail.com Thu Mar 20 10:58:47 2008 From: jgbailey at gmail.com (Justin Bailey) Date: Thu Mar 20 10:55:27 2008 Subject: [Haskell-cafe] Any ideas for "->" (function type) in a simply-typed lambda calculus version of Brett Victor's Alligator Eggs game? In-Reply-To: <220158.22285.qm@web30204.mail.mud.yahoo.com> References: <220158.22285.qm@web30204.mail.mud.yahoo.com> Message-ID: On Wed, Mar 19, 2008 at 12:48 AM, Benjamin L. Russell wrote: > However, in thinking about how to adapt the game, I am > not quite sure how to incorporate the representation > of "->" (function type): > > * ???: "->" (function type) > > What ideas, if any, would anybody have on how "->" > (function type) could be represented in a simply-typed > lambda calculus version of Brett Victor's Alligator > Eggs? Since color is already taken, how about representing types as skinny and fat alligators? Functions can then be represented by alligators with their tails joined together. For example, Nat -> Bool would be represented as a skinny alligator joined to a fat alligator. A skinny alligator will only eat anotehr skinny alligator, and then goes to take a nap (i.e. disappears). That leaves the fat alligator (bool). Just a sketch but maybe it will help you out! Justin From rendel at rbg.informatik.tu-darmstadt.de Thu Mar 20 11:16:22 2008 From: rendel at rbg.informatik.tu-darmstadt.de (Tillmann Rendel) Date: Thu Mar 20 11:13:02 2008 Subject: [Haskell-cafe] How to implement Read instance for user defined type In-Reply-To: References: Message-ID: <47E27FC6.4090005@rbg.informatik.tu-darmstadt.de> Verma Anurag wrote: > module Mark where > > data Mark = Mark Int deriving (Show) > > instance Read Mark where > readsPrec _ str = [(Mark x, t') | ("mark",t) <- reads str, > (x,t') <- reads t > The problem with this instance is that reads expect Strings to be enclosed in double quotes: *Mark> read "mark" :: String "*** Exception: Prelude.read: no parse *Mark> read "\"mark\"" :: String "mark" Let's try this with your instance: *Mark> read "\"mark\" 4" :: Mark Mark 4 That works, but is probably not what you want. You can use the lex function to parse identifiers not enclosed in quotes: > instance Read Mark where > readsPrec _ str = [(Mark x, t') | ("mark",t) <- lex str, > (x,t') <- reads t Now, it's working fine: *Mark> read "mark 4" :: Mark Mark 4 Tillmann From dons at galois.com Thu Mar 20 12:20:08 2008 From: dons at galois.com (Don Stewart) Date: Thu Mar 20 12:17:31 2008 Subject: [Haskell-cafe] Re: [Haskell] ANN: The Disciplined Disciple Compiler - alpha 1 In-Reply-To: <200803201508.59413.g9ks157k@acme.softbase.org> References: <47E1FFA0.1090404@anu.edu.au> <200803201508.59413.g9ks157k@acme.softbase.org> Message-ID: <20080320162008.GC14665@scytale.galois.com> g9ks157k: > Am Donnerstag, 20. M?rz 2008 07:09 schrieb Ben Lippmeier: > > Hi All, > > I'm pleased to announce the initial alpha release > > of the Disciplined Disciple Compiler (DDC). > > > > Disciple is an explicitly lazy dialect of Haskell which includes: > > - first class destructive update of arbitrary data. > > - computational effects without the need for state monads. > > - type directed field projections. > > > > All this and more through the magic of effect typing. > > > > More information (and download!) available from: > > http://www.haskell.org/haskellwiki/DDC > > or http://code.google.com/p/disciple > > > > DDC: more than lambdas. > > > > Onward! > > Ben. > > Short question: Is it appropriate to put the homepage of a non-Haskell project > on the Haskell Wiki? I mean, putting some basic info about such a project > there and link to the project?s website might be okay and is already done in > certain cases. But projects like Agda or Epigram typically don?t use > haskell.org as a webspace provider and I think this is the way to go. What > do others think? While YHC, lambdabot and xmonad do :) So I think the precedent has been that anything written in Haskell, or any Haskell-like compiler, can be happily hosted. -- Don From duncan.coutts at worc.ox.ac.uk Thu Mar 20 12:34:13 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Mar 20 12:32:56 2008 Subject: [Haskell-cafe] Three Cabal/Hackage GSoC project proposals Message-ID: <1206030853.7594.156.camel@localhost> All, I've proposed three GSoC proposals on different aspects of Cabal and Hackage: * Cabal 'make-like' dependency framework http://hackage.haskell.org/trac/summer-of-code/ticket/1552 * cabal-install package dependency resolution http://hackage.haskell.org/trac/summer-of-code/ticket/1553 * Hackage build reporting http://hackage.haskell.org/trac/summer-of-code/ticket/1554 This is in addition to the project that Neil proposed: * Hoogle 4 (using it as the main interface to the hackage website) http://hackage.haskell.org/trac/summer-of-code/ticket/1429 I'd like to invite interested people to help improve the proposals and to invite students to look at these and consider them. I'd also like other people interested in mentoring any of these projects to sign up. In particular, students who are interested should email the cabal-devel and/or libraries list (though they'd have to subscribe I think) to express their interest and work with us on improving the detail of their proposal. Duncan From ndmitchell at gmail.com Thu Mar 20 13:01:36 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Thu Mar 20 12:58:17 2008 Subject: [Haskell-cafe] Termination of substitution In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C3248F5FEE76@EA-EXMSG-C334.europe.corp.microsoft.com> References: <404396ef0803121405q51e4dd58h856e37cb64ff6ff3@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C3248F5FEE76@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <404396ef0803201001x706d115bxc16b489242163be9@mail.gmail.com> Hi Thanks for the interesting comments. Its looks like learning some of the basics about System Fw is probably the way forward. > However GHC goes beyond Fw by adding > data types > letrec > This blows strong normalisation out of the water. (Assuming you have reasonable rules for case and letrec.) But perhaps if you restrict data types a bit, and place draconian restrictions on letrec (e.g. never inline one) you could retain strong normalisation. It depends how much you want your rules to do. I have restricted letrec appropriately. I haven't looked at the data type problem, but given that GHC manages to ignore it, I think its probably fair for me to ignore it for the time being. Thanks very much for the helpful comments, Neil From dons at galois.com Thu Mar 20 13:45:37 2008 From: dons at galois.com (Don Stewart) Date: Thu Mar 20 13:42:29 2008 Subject: [Haskell-cafe] ANNOUNCE: wxHaskell 0.10.3 rc1 In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AB9A145A6@EA-EXMSG-C334.europe.corp.microsoft.com> References: <1205315421.15905.1241945927@webmail.messagingengine.com> <638ABD0A29C8884A91BC5FB5C349B1C32AB9A145A6@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <20080320174537.GB15505@scytale.galois.com> I created a summer of code ticket for generic wxHaskell work, http://hackage.haskell.org/trac/summer-of-code/ticket/1550 Perhaps the wxhaskell team would like to fill this out, and perhaps approach the wxWidgets SoC organisation, to see if work on wxHaskell could be funded under their umbrella? simonpj: > Congratulations! wxHaskell is v cool but was suffering from lack of loving care. I'm delighted that it not only has a new team, but that you've pushed through to delivering a release. Brilliant. > > Simon > > | -----Original Message----- > | From: haskell-cafe-bounces@haskell.org [mailto:haskell-cafe- > | bounces@haskell.org] On Behalf Of Jeremy O'Donoghue > | Sent: 12 March 2008 09:50 > | To: haskell-cafe@haskell.org > | Cc: wxhaskell-users@lists.sourceforge.net > | Subject: [Haskell-cafe] ANNOUNCE: wxHaskell 0.10.3 rc1 > | > | We are pleased to announce the first release candidate of wxHaskell > | 0.10.3. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From eric.kow at gmail.com Thu Mar 20 14:07:56 2008 From: eric.kow at gmail.com (Eric Kow) Date: Thu Mar 20 14:04:47 2008 Subject: [wxhaskell-users] [Haskell-cafe] ANNOUNCE: wxHaskell 0.10.3 rc1 In-Reply-To: <20080320174537.GB15505@scytale.galois.com> References: <1205315421.15905.1241945927@webmail.messagingengine.com> <638ABD0A29C8884A91BC5FB5C349B1C32AB9A145A6@EA-EXMSG-C334.europe.corp.microsoft.com> <20080320174537.GB15505@scytale.galois.com> Message-ID: <4a0b969d0803201107x96c2159sb2a5bac39acd8f29@mail.gmail.com> On 20/03/2008, Don Stewart wrote: > I created a summer of code ticket for generic wxHaskell work, > > http://hackage.haskell.org/trac/summer-of-code/ticket/1550 > > Perhaps the wxhaskell team would like to fill this out, and perhaps > approach the wxWidgets SoC organisation, to see if work on wxHaskell > could be funded under their umbrella? Thanks, Don! I have updated the ticket with some ideas from the mailing list discussions on the matter. Anybody else from the team have something to add? Users? Potential users? By the way, we do have a potential mentor lined up, this being Kido Takahiro (shelarcy) -- Eric Kow PGP Key ID: 08AC04F9 From Ben.Lippmeier at anu.edu.au Thu Mar 20 15:25:42 2008 From: Ben.Lippmeier at anu.edu.au (Ben Lippmeier) Date: Thu Mar 20 15:22:26 2008 Subject: [Haskell-cafe] ANN: The Disciplined Disciple Compiler - alpha 1 In-Reply-To: <200803201508.59413.g9ks157k@acme.softbase.org> References: <47E1FFA0.1090404@anu.edu.au> <200803201508.59413.g9ks157k@acme.softbase.org> Message-ID: <7B5E1E86-8796-4399-AB58-21AF26DF0085@anu.edu.au> Hi Wolfgang, Rest assured it really is a Haskell project. Apart from the way it does field projections, DDC will compile a significant number of Haskell programs with no modifications. Ben. On 21/03/2008, at 1:08 AM, Wolfgang Jeltsch wrote: > Short question: Is it appropriate to put the homepage of a non- > Haskell project > on the Haskell Wiki? I mean, putting some basic info about such a > project > there and link to the project?s website might be okay and is already > done in > certain cases. But projects like Agda or Epigram typically don?t use > haskell.org as a webspace provider and I think this is the way to > go. What > do others think? > > Best wishes, > Wolfgang > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From derek.a.elkins at gmail.com Thu Mar 20 15:32:05 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Thu Mar 20 15:28:48 2008 Subject: [Haskell-cafe] Re: [Haskell] ANN: The Disciplined Disciple Compiler - alpha 1 In-Reply-To: <20080320162008.GC14665@scytale.galois.com> References: <47E1FFA0.1090404@anu.edu.au> <200803201508.59413.g9ks157k@acme.softbase.org> <20080320162008.GC14665@scytale.galois.com> Message-ID: <1206041525.5533.17.camel@derek-laptop> On Thu, 2008-03-20 at 09:20 -0700, Don Stewart wrote: > g9ks157k: > > Am Donnerstag, 20. M?rz 2008 07:09 schrieb Ben Lippmeier: > > > Hi All, > > > I'm pleased to announce the initial alpha release > > > of the Disciplined Disciple Compiler (DDC). > > > > > > Disciple is an explicitly lazy dialect of Haskell which includes: > > > - first class destructive update of arbitrary data. > > > - computational effects without the need for state monads. > > > - type directed field projections. > > > > > > All this and more through the magic of effect typing. > > > > > > More information (and download!) available from: > > > http://www.haskell.org/haskellwiki/DDC > > > or http://code.google.com/p/disciple > > > > > > DDC: more than lambdas. > > > > > > Onward! > > > Ben. > > > > Short question: Is it appropriate to put the homepage of a non-Haskell project > > on the Haskell Wiki? I mean, putting some basic info about such a project > > there and link to the project?s website might be okay and is already done in > > certain cases. But projects like Agda or Epigram typically don?t use > > haskell.org as a webspace provider and I think this is the way to go. What > > do others think? > > While YHC, lambdabot and xmonad do :) So I think the precedent has been > that anything written in Haskell, or any Haskell-like compiler, can be > happily hosted. My experience has been that the Haskell community is and has been very supportive of such projects, and most Haskellers would be more than happy to have such a project on the Haskell Wiki. Pugs started on the Haskell wiki. From quuxman at gmail.com Thu Mar 20 16:07:55 2008 From: quuxman at gmail.com (ac) Date: Thu Mar 20 16:04:34 2008 Subject: [Haskell-cafe] Type checking of partial programs Message-ID: Is anybody interested in working on this? This is a project I've been interested in for some time, but recognize I probably need some guidance before I go off and start hacking on it. As dcoutts pointed out on #haskell-soc, this may be of particular interest to people working on yi and HaRe. Other interesting and related projects include parsing partial programs to insert "placeholders" in appropriate places. An example of a partial program could be: foo :: [Foo] -> foo xs = map xs What are the possible type signatures for placeholder 1 and the possible expressions for placeholder 2? I would like to stir up a discussion about this, and eventually write some useful code. -Abram -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080320/16722128/attachment.htm From andrewcoppin at btinternet.com Thu Mar 20 16:18:07 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Thu Mar 20 16:14:41 2008 Subject: [Haskell-cafe] ANNOUNCE: wxHaskell 0.10.3 rc1 In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AB9A145A6@EA-EXMSG-C334.europe.corp.microsoft.com> References: <1205315421.15905.1241945927@webmail.messagingengine.com> <638ABD0A29C8884A91BC5FB5C349B1C32AB9A145A6@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <47E2C67F.3050301@btinternet.com> Simon Peyton-Jones wrote: > Congratulations! wxHaskell is v cool but was suffering from lack of loving care. I'm delighted that it not only has a new team, but that you've pushed through to delivering a release. Brilliant. > Yeah, I thought wxHaskell was long since dead. Then I come back after a couple of weeks and find there's a new RC. I've never used wx before, but hopefully this might eventually enable me to build Windows apps that have a native look and feel, and don't require the GTK runtime [which is very uncommon on that platform]. From zunino at di.unipi.it Thu Mar 20 16:36:43 2008 From: zunino at di.unipi.it (Roberto Zunino) Date: Thu Mar 20 16:34:04 2008 Subject: [Haskell-cafe] Type checking of partial programs In-Reply-To: References: Message-ID: <47E2CADB.50008@di.unipi.it> ac wrote: > foo :: [Foo] -> > foo xs = map xs > > What are the possible type signatures for placeholder 1 and the possible > expressions for placeholder 2? A nice GHCi trick I learned from #haskell: > :t let foo xs = map ?placeholder2 xs in foo forall a b. (?placeholder2::a -> b) => [a] -> [b] Also, the djinn tool might provide some actual expression for placeholder 2. Zun. From dons at galois.com Thu Mar 20 16:38:41 2008 From: dons at galois.com (Don Stewart) Date: Thu Mar 20 16:35:46 2008 Subject: [Haskell-cafe] Type checking of partial programs In-Reply-To: <47E2CADB.50008@di.unipi.it> References: <47E2CADB.50008@di.unipi.it> Message-ID: <20080320203841.GD15505@scytale.galois.com> zunino: > ac wrote: > > foo :: [Foo] -> > > foo xs = map xs > > > > What are the possible type signatures for placeholder 1 and the possible > > expressions for placeholder 2? > > A nice GHCi trick I learned from #haskell: > > > :t let foo xs = map ?placeholder2 xs in foo > > forall a b. (?placeholder2::a -> b) => [a] -> [b] > > Also, the djinn tool might provide some actual expression for placeholder 2. > > Zun. Yes, it turns out implicit parameters provide a great mechanism for doing type checker queries :) -- Don From ryani.spam at gmail.com Thu Mar 20 16:41:56 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Thu Mar 20 16:38:35 2008 Subject: [Haskell-cafe] Type checking of partial programs In-Reply-To: References: Message-ID: <2f9b2d30803201341l2e36e63cl66ed78d38a574c5c@mail.gmail.com> You can transform this into valid Haskell98 in the following way: foo_infer xs _ | const False (xs :: [Foo]) = undefined foo_infer xs placeholder_2 = map ph xs foo xs = foo_infer xs undefined You can then do type inference on "foo_infer", giving you foo_infer :: [Foo] -> (Foo -> a) -> [a] which gives you the type of the placeholder: placeholder_2 :: Foo -> a and the type of "foo" (which is dependent on that): foo :: [Foo] -> [a] Of course this gets far more difficult when you add extensions that require type signatures so that you can't rely entirely on type inference, such as GADTs and higher rank types. But it's a start! -- ryan On 3/20/08, ac wrote: > Is anybody interested in working on this? This is a project I've been > interested in for some time, but recognize I probably need some guidance > before I go off and start hacking on it. As dcoutts pointed out on > #haskell-soc, this may be of particular interest to people working on yi and > HaRe. Other interesting and related projects include parsing partial > programs to insert "placeholders" in appropriate places. An example of a > partial program could be: > > foo :: [Foo] -> > foo xs = map xs > > What are the possible type signatures for placeholder 1 and the possible > expressions for placeholder 2? > > I would like to stir up a discussion about this, and eventually write some > useful code. > > -Abram > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From catamorphism at gmail.com Thu Mar 20 16:44:37 2008 From: catamorphism at gmail.com (Tim Chevalier) Date: Thu Mar 20 16:41:15 2008 Subject: [Haskell-cafe] ANN: The Disciplined Disciple Compiler - alpha 1 In-Reply-To: <7B5E1E86-8796-4399-AB58-21AF26DF0085@anu.edu.au> References: <47E1FFA0.1090404@anu.edu.au> <200803201508.59413.g9ks157k@acme.softbase.org> <7B5E1E86-8796-4399-AB58-21AF26DF0085@anu.edu.au> Message-ID: <4683d9370803201344qe4bd9e1w99103d7d4df634a5@mail.gmail.com> On 3/20/08, Ben Lippmeier wrote: > > Hi Wolfgang, > Rest assured it really is a Haskell project. Apart from the way it > does field projections, DDC will compile a significant number of > Haskell programs with no modifications. > Can you elaborate on "a significant number of Haskell programs"? Do you expect that DDC can compile any Haskell (98?) program except some weird corner cases, or are you aware of a particular class of Haskell programs it currently can't compile? (I'm asking in order to find out whether DDC would potentially be useful for my work, not so as to question whether it should be on haskell.org (I don't care about that :-)) Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "It's easy to consider women more emotional than men when you don't consider rage to be an emotion." -- Brenda Fine From agl at imperialviolet.org Thu Mar 20 18:26:48 2008 From: agl at imperialviolet.org (Adam Langley) Date: Thu Mar 20 18:23:29 2008 Subject: [Haskell-cafe] ANN: Network.MiniHTTP 0.2 Message-ID: <396556a20803201526n2e090f56t84c8ee7e7543fbb8@mail.gmail.com> Since many people are interested in a ByteString HTTP library, here's network-minihttp 0.2 [1]. * Has code for both clients and servers * HTTP and HTTPS support (the latter is a little shaky, but mostly works) * DNS lookups (in the client code) don't block the whole process The Haddock documentation is at: http://darcs.imperialviolet.org/minihttp-docs/index.html Half the interfaces are ill-thought out, and the rest are just as bad. However, if you send me your ideas for how it should look I'll certainly consider them. The major omission at the moment are defensive timeouts for talking to the network. However, these shouldn't be too hard. [1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/network-minihttp-0.2 -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org From jgbailey at gmail.com Thu Mar 20 18:57:50 2008 From: jgbailey at gmail.com (Justin Bailey) Date: Thu Mar 20 18:54:28 2008 Subject: [Haskell-cafe] Help me understand this pattern Message-ID: All, Yesterday I wrote some code I thought was very clever (even though I stole most of it) and I wonder what the pattern is. I have seen it in at least one other place, and I suspect it's well known to long-time Haskellers. The problem I wanted to solved was creating a combinator that could be defined to take any number of differently typed arguments and convert them to a more fundamental representation. To be concrete, I have a data type Expr: data Expr a = ... where a is a phantom type. I wanted users of the library (haskelldb) to be able to define functions[1] such as: -- Trim whitespace from the expression given. trim :: Expr a -> Expr String -- Pad the expression given to the correct length with the given string, if one is given. rpad :: Expr a -> Expr Int -> Maybe String -> Expr String I wanted them to be able to do this using one combinator from the library and I did not want to expose the guts of the library so they could define the functions directly in the untyped, primitive representation. That is, I did NOT want to define my combinator as: func :: String -> [PrimExpr] -> Expr a Using ideas already in haskelldb, I came up with this: data ExprNil = ExprNil data ExprCons h tl = ExprCons h tl func :: String -> (ExprNil -> ExprCons (Expr e) tl) -> Expr o arg :: (Expr a) -> (tl -> ExprCons (Expr a) tl) Using these two functions, I could define trim and rpad via composition and I did not have to expose a primitive representation or use an existentially quantified data type[2]: trim str = func "trim" $ arg str rpad str len (Just pad_str) = func "rpad" $ arg str . arg len . arg (toExpr pad_str) where toExpr :: String -> Expr String rpad str len Nothing = func "rpad" $ arg str . arg len Notice how in the second case of 'rpad', the function defined only has two arguments since no padding character was provided. With that background, I'm hoping others can tell me what this generalizes too. It's pretty clear I'm working with type-level lists, but I'm sure there is more. Is this encoding existentials? Is the (ExprCons hd tl) type really a continuation? I'm positive this is a well-known pattern and I'd really like to learn more about it (history, other uses, libraries that depend on it, etc.). Thanks in advance! Justin [1] These functions are used to generate SQL code and do not actually do the operations given. For example, trim causes the "trim" function to be applied to the column given when the SQL is actually generated. [2] Just a note that these functions are NOT in haskelldb right now - this is my own experimentation. From Ben.Lippmeier at anu.edu.au Thu Mar 20 19:34:59 2008 From: Ben.Lippmeier at anu.edu.au (Ben Lippmeier) Date: Thu Mar 20 19:31:52 2008 Subject: [Haskell-cafe] ANN: The Disciplined Disciple Compiler - alpha 1 In-Reply-To: <4683d9370803201344qe4bd9e1w99103d7d4df634a5@mail.gmail.com> References: <47E1FFA0.1090404@anu.edu.au> <200803201508.59413.g9ks157k@acme.softbase.org> <7B5E1E86-8796-4399-AB58-21AF26DF0085@anu.edu.au> <4683d9370803201344qe4bd9e1w99103d7d4df634a5@mail.gmail.com> Message-ID: <4DE9C221-6B59-4184-9AA5-5343ADD91790@anu.edu.au> Hi Tim, DDC doesn't aim for Haskell 98 compliance - its really a superset of a subset of it - but I've followed Haskell syntax and philosophy where ever possible. The compiler is written in Haskell and I want DDC to support as much of it as possible to make its eventual boot-strapping easier. There's much more common ground between Disciple and Haskell than say, ML and O'Caml, or Haskell and Clean. Most of the expression syntax is there eg: function binding, lambdas, let, where, pattern matching, case expressions, pattern guards, data type definitions, class and instance definitions etc etc. For the alpha version at least, the main deviations are: - dictionary passing is not finished. - you'll need to put region annots on recursive data type defs as the elaboration isn't quite finished. - it uses strict evaluation as default - field projections are different - no monadic desugaring in do notation. - no irrefutable patterns yet. The rest is all Haskell 98 (minus all the effect typing extensions, of course!). For the alpha2 release I'm hoping that most straight-up Haskell 98 programs will compile with it after some cosmetic modifications: mostly adding the suspension operator where appropriate, and using the new field projection syntax. Ben. > Can you elaborate on "a significant number of Haskell programs"? Do > you expect that DDC can compile any Haskell (98?) program except some > weird corner cases, or are you aware of a particular class of Haskell > programs it currently can't compile? > > (I'm asking in order to find out whether DDC would potentially be > useful for my work, not so as to question whether it should be on > haskell.org (I don't care about that :-)) > > Cheers, > Tim > > -- > Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in > doubt > "It's easy to consider women more emotional than men when you don't > consider rage to be an emotion." -- Brenda Fine From mfeathers at mindspring.com Thu Mar 20 21:43:04 2008 From: mfeathers at mindspring.com (Michael Feathers) Date: Thu Mar 20 21:41:21 2008 Subject: [Haskell-cafe] An ugly zip3 problem.. In-Reply-To: References: Message-ID: <47E312A8.7060700@mindspring.com> I'm working on something and it's looking rather ugly.. essentially, it it's an application of a low pass filer to a dataset. type Dataset = [Double] type FilterWindow3 = (Double,Double,Double) internalList :: [a] -> [a] internalList = tail . init lowPass3 :: FilterWindow3 -> Double lowPass3 (i, j, k) = (i + 2 * j + k) / 4.0 filter3 :: (FilterWindow3 -> Double) -> Dataset -> Dataset filter3 f3 ds = [(f3 x) | x <- formWindows ds] iterFilter :: (Dataset -> Dataset) -> Int -> Dataset -> Dataset iterFilter f n ds | n > 0 = iterFilter f (n - 1) (f ds) | otherwise = ds smooth :: Int -> Dataset -> Dataset smooth = iterFilter $ filter3 lowPass3 formWindows :: Dataset -> [FilterWindow3] formWindows ds = internalList $ zip3 x y z where c0 = [head ds] cn = [last ds] x = ds ++ cn ++ cn y = c0 ++ ds ++ cn z = c0 ++ c0 ++ ds The key idea is that I can take care of edge conditions with that last function. It lets me build a list of 3-tuples, each of which is reduced to a single point in the next rewrite of the dataset. I used zip3 to build up that list, and I take care to keep the lists the same length by duplicating the head and last elements as necessary. Has anyone done this sort of thing before? Any and all style advice welcome. Thanks, Michael Feathers -- Now Playing: http://www.youtube.com/watch?v=SsnDdq4V8zg From gtener at gmail.com Thu Mar 20 22:00:52 2008 From: gtener at gmail.com (=?ISO-8859-2?Q?Krzysztof_Skrz=EAtnicki?=) Date: Thu Mar 20 21:57:30 2008 Subject: [Haskell-cafe] Type constraints for class instances Message-ID: <220e47b40803201900u4bcc564ard2ab8ad6d1d32a81@mail.gmail.com> Hello everyone, I'm working on a small module for comparing things incomparable with Ord. More precisely I want to be able to compare equal infinite lists like [1..]. Obviously (1) compare [1..] [1..] = _|_ It is perfectly reasonable for Ord to behave this way. Hovever, it doesn't have to be just this way. Consider this class class YOrd a where ycmp :: a -> a -> (a,a) In a way, it tells a limited version of ordering, since there is no way to get `==` out of this. Still it can be useful when Ord fails. Consider this code: (2) sort [ [1..], [2..], [3..] ] It is ok, because compare can decide between any elements in finite time. However, this one (3) sort [ [1..], [1..] ] will fail because of (1). Compare is simply unable to tell that two infinite list are equivalent. I solved this by producing partial results while comparing lists. If we compare lists (1:xs) (1:ys) we may not be able to tell xs < ys, but we do can tell that 1 will be the first element of both of smaller and greater one. You can see this idea in the code below. --- cut here --- {-# OPTIONS_GHC -O2 #-} module Data.YOrd where -- Well defined where Eq means equality, not only equivalence class YOrd a where ycmp :: a -> a -> (a,a) instance (YOrd a) => YOrd [a] where ycmp [] [] = ([],[]) ycmp xs [] = ([],xs) ycmp [] xs = ([],xs) ycmp xs'@(x:xs) ys'@(y:ys) = let (sm,gt) = x `ycmp` y in let (smS,gtS) = xs `ycmp` ys in (sm:smS, gt:gtS) ycmpWrap x y = case x `compare` y of LT -> (x,y) GT -> (y,x) EQ -> (x,y) -- biased - but we have to make our minds! -- ugly, see the problem below instance YOrd Int where ycmp = ycmpWrap instance YOrd Char where ycmp = ycmpWrap instance YOrd Integer where ycmp = ycmpWrap -- ysort : sort of mergesort ysort :: (YOrd a) => [a] -> [a] ysort = head . mergeAll . wrap wrap :: [a] -> [[a]] wrap xs = map (:[]) xs mergeAll :: (YOrd a) => [[a]] -> [[a]] mergeAll [] = [] mergeAll [x] = [x] mergeAll (a:b:rest) = mergeAll ((merge a b) : (mergeAll rest)) merge :: (YOrd a) => [a] -> [a] -> [a] merge [] [] = [] merge xs [] = xs merge [] xs = xs merge (x:xs) (y:ys) = let (sm,gt) = x `ycmp` y in sm : (merge [gt] $ merge xs ys) --- cut here --- I'd like to write the following code: instance (Ord a) => YOrd a where ycmp x y = case x `compare` y of LT -> (x,y) GT -> (y,x) EQ -> (x,y) But i get an error "Undecidable instances" for any type [a]. Does anyone know the way to solve this? Best regards Christopher Skrz?tnicki From westondan at imageworks.com Thu Mar 20 22:07:05 2008 From: westondan at imageworks.com (Dan Weston) Date: Thu Mar 20 22:03:44 2008 Subject: [Haskell-cafe] An ugly zip3 problem.. In-Reply-To: <47E312A8.7060700@mindspring.com> References: <47E312A8.7060700@mindspring.com> Message-ID: <47E31849.5060202@imageworks.com> There's an interesting blog post by Dan Piponi on the subject: http://sigfpe.blogspot.com/2007/01/monads-hidden-behind-every-zipper.html Summary: "convolution is comonadic" Dan Michael Feathers wrote: > I'm working on something and it's looking rather ugly.. essentially, it > it's an application of a low pass filer to a dataset. > > > type Dataset = [Double] > type FilterWindow3 = (Double,Double,Double) > > internalList :: [a] -> [a] > internalList = tail . init > > lowPass3 :: FilterWindow3 -> Double > lowPass3 (i, j, k) = (i + 2 * j + k) / 4.0 > > filter3 :: (FilterWindow3 -> Double) -> Dataset -> Dataset > filter3 f3 ds = [(f3 x) | x <- formWindows ds] > > iterFilter :: (Dataset -> Dataset) -> Int -> Dataset -> Dataset > iterFilter f n ds > | n > 0 = iterFilter f (n - 1) (f ds) > | otherwise = ds > > smooth :: Int -> Dataset -> Dataset > smooth = iterFilter $ filter3 lowPass3 > > formWindows :: Dataset -> [FilterWindow3] > formWindows ds = > internalList $ zip3 x y z > where c0 = [head ds] > cn = [last ds] > x = ds ++ cn ++ cn > y = c0 ++ ds ++ cn > z = c0 ++ c0 ++ ds > > > The key idea is that I can take care of edge conditions with that last > function. It lets me build a list of 3-tuples, each of which is reduced > to a single point in the next rewrite of the dataset. I used zip3 to > build up that list, and I take care to keep the lists the same length by > duplicating the head and last elements as necessary. Has anyone done > this sort of thing before? > > Any and all style advice welcome. > > Thanks, > > Michael Feathers > > From mfeathers at mindspring.com Thu Mar 20 22:28:59 2008 From: mfeathers at mindspring.com (Michael Feathers) Date: Thu Mar 20 22:27:16 2008 Subject: [Haskell-cafe] An ugly zip3 problem.. In-Reply-To: <47E31849.5060202@imageworks.com> References: <47E312A8.7060700@mindspring.com> <47E31849.5060202@imageworks.com> Message-ID: <47E31D6B.3080004@mindspring.com> Thanks. That's interesting (but a little beyond me). Seems like he's assuming that values beyond his range are zero whereas I'm trying to use the values at the edges of the range. Is there anything I can do before I understand comonads? ;-) Michael Dan Weston wrote: > There's an interesting blog post by Dan Piponi on the subject: > > http://sigfpe.blogspot.com/2007/01/monads-hidden-behind-every-zipper.html > > Summary: "convolution is comonadic" > > Dan > > Michael Feathers wrote: >> I'm working on something and it's looking rather ugly.. essentially, >> it it's an application of a low pass filer to a dataset. >> >> >> type Dataset = [Double] >> type FilterWindow3 = (Double,Double,Double) >> >> internalList :: [a] -> [a] >> internalList = tail . init >> >> lowPass3 :: FilterWindow3 -> Double >> lowPass3 (i, j, k) = (i + 2 * j + k) / 4.0 >> >> filter3 :: (FilterWindow3 -> Double) -> Dataset -> Dataset >> filter3 f3 ds = [(f3 x) | x <- formWindows ds] >> >> iterFilter :: (Dataset -> Dataset) -> Int -> Dataset -> Dataset >> iterFilter f n ds >> | n > 0 = iterFilter f (n - 1) (f ds) >> | otherwise = ds >> >> smooth :: Int -> Dataset -> Dataset >> smooth = iterFilter $ filter3 lowPass3 >> >> formWindows :: Dataset -> [FilterWindow3] >> formWindows ds = >> internalList $ zip3 x y z >> where c0 = [head ds] >> cn = [last ds] >> x = ds ++ cn ++ cn >> y = c0 ++ ds ++ cn >> z = c0 ++ c0 ++ ds >> >> >> The key idea is that I can take care of edge conditions with that last >> function. It lets me build a list of 3-tuples, each of which is >> reduced to a single point in the next rewrite of the dataset. I used >> zip3 to build up that list, and I take care to keep the lists the same >> length by duplicating the head and last elements as necessary. Has >> anyone done this sort of thing before? >> >> Any and all style advice welcome. >> >> Thanks, >> >> Michael Feathers >> >> > > > -- Now Playing: http://www.youtube.com/watch?v=SsnDdq4V8zg From rendel at rbg.informatik.tu-darmstadt.de Thu Mar 20 23:12:08 2008 From: rendel at rbg.informatik.tu-darmstadt.de (Tillmann Rendel) Date: Thu Mar 20 23:08:48 2008 Subject: [Haskell-cafe] An ugly zip3 problem.. In-Reply-To: <47E312A8.7060700@mindspring.com> References: <47E312A8.7060700@mindspring.com> Message-ID: <47E32788.2030408@rbg.informatik.tu-darmstadt.de> Michael Feathers wrote: > I'm working on something and it's looking rather ugly. essentially, > it's an application of a low pass filer to a dataset. I would not consider your code ugly. it can be made shorter, though. > type Dataset = [Double] > type FilterWindow3 = (Double,Double,Double) > > internalList :: [a] -> [a] > internalList = tail . init > > lowPass3 :: FilterWindow3 -> Double > lowPass3 (i, j, k) = (i + 2 * j + k) / 4.0 > > filter3 :: (FilterWindow3 -> Double) -> Dataset -> Dataset > filter3 f3 ds = [(f3 x) | x <- formWindows ds] I would prefer this version to the list comprehension: filter3 f3 = map f3 . formWindows I tend to assume list comprehensions are doing something magical I have to figure out while reading a program, so a comprehension for a simple map looks wrong to me. read ahead for more magical list comprehensions. > iterFilter :: (Dataset -> Dataset) -> Int -> Dataset -> Dataset > iterFilter f n ds > | n > 0 = iterFilter f (n - 1) (f ds) > | otherwise = ds You can use iterate and list indexing to iterate a function a specified number of times. iterFilter f n = (!! n) . iterate f Probably iterateN :: (a -> a) -> Int -> a is a better type and name for this function. > formWindows :: Dataset -> [FilterWindow3] > formWindows ds = > internalList $ zip3 x y z > where c0 = [head ds] > cn = [last ds] > x = ds ++ cn ++ cn > y = c0 ++ ds ++ cn > z = c0 ++ c0 ++ ds internalList will delete the first and last element, so why create it at all? there is no problem with different list lengths, the result will be as long as the shortest list. formWindows ds = zip3 x y z where x = tail ds ++ [last ds] y = ds z = head ds : ds if you want to make clear what elements of the lists are used, you can use z = head ds : init ds instead. Note that definition for y clearly states that the middle element is the original list. I would consider swapping x and z to help me imagine a window moving over the dataset. as it is now, i have to imagine a window with an integrated mirror to make it fit. I don't like the definition of x, because I fear that the (last ds) thunk will hang around and hold the whole list ds in memory, which is unecessary because it's value only depends on the last element of said list. I would therefore consider a different implementation using tails. formWindows ds = [(f y z, y, x) | (x : y : z) <- tails (head ds : ds)] where f x [] = x f _ (x : _) = x the head corner case is taken care of by duplicating the head of ds. the last corner case is taken care of by the call to f, which uses y as default value if z doesn't contain another one. the list comprehension is used here to do three different things: * convert lists to tuples * apply f * throw away the last element of tails' result (pattern match failure means "ignore this element" in list comprehensions) Maybe headDefault :: a -> [a] -> a is a sensible name for f. > smooth :: Int -> Dataset -> Dataset > smooth = iterFilter $ filter3 lowPass3 by inlining the definition above, this can be given as a four-liner now: smooth n = (!! n) . iterate f where f ds = [(g y z + 2 * y + x) / 4.0 | x:y:z <- tails (head ds : ds)] g x [] = x g _ (x:_) = x :-) Tillmann From gtener at gmail.com Thu Mar 20 23:40:41 2008 From: gtener at gmail.com (=?ISO-8859-2?Q?Krzysztof_Skrz=EAtnicki?=) Date: Thu Mar 20 23:37:18 2008 Subject: [Haskell-cafe] YOrd and ysort Message-ID: <220e47b40803202040q3743d0b4gc86b2f645cf8a984@mail.gmail.com> The ysort function I've written for YOrd class was incredibly inefficient. Here is better one: ysort :: (YOrd a) => [a] -> [a] ysort = head . mergeAll . wrap wrap :: [a] -> [[a]] wrap xs = map (:[]) xs mergeAll :: (YOrd a) => [[a]] -> [[a]] mergeAll [] = [] mergeAll [x] = [x] mergeAll (a:b:rest) = mergeAll ((merge a b) : (mergeAll rest)) merge :: (YOrd a) => [a] -> [a] -> [a] merge [] [] = [] merge xs [] = xs merge [] xs = xs merge xs ys = let ((sm:smS),gts) = xs `ycmp` ys in smS `seq` gts `seq` sm : (merge smS gts) From lrpalmer at gmail.com Fri Mar 21 01:47:48 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Fri Mar 21 01:44:24 2008 Subject: [Haskell-cafe] Type constraints for class instances In-Reply-To: <220e47b40803201900u4bcc564ard2ab8ad6d1d32a81@mail.gmail.com> References: <220e47b40803201900u4bcc564ard2ab8ad6d1d32a81@mail.gmail.com> Message-ID: <7ca3f0160803202247r5eefb9ddk365a97a564c5d9@mail.gmail.com> First I'd like to say that this is a very clever idea. Thanks for the exposition. :-) 2008/3/21 Krzysztof Skrz?tnicki : > I'd like to write the following code: > > instance (Ord a) => YOrd a where > ycmp x y = case x `compare` y of > LT -> (x,y) > GT -> (y,x) > EQ -> (x,y) > > > But i get an error "Undecidable instances" for any type [a]. > Does anyone know the way to solve this? This type of superclassing is not supported by the typeclass system. Finding systems where it is supported is a point of much lost sleep on my part. The typical way to solve this is rather disappointing: wrap it in a newtype: newtype YOrdWrap a = YOrdWrap { yordUnwrap :: a } instance (Ord a) => YOrd (YOrdWrap a) where ycmp (YOrdWrap x) (YOrdWrap y) = ycmpWrap x y And then apply the constructor whenever you want to use a "normal" type. Luke From v.dijk.bas at gmail.com Fri Mar 21 04:43:35 2008 From: v.dijk.bas at gmail.com (Bas van Dijk) Date: Fri Mar 21 04:40:11 2008 Subject: [Haskell-cafe] Type constraints for class instances In-Reply-To: <220e47b40803201900u4bcc564ard2ab8ad6d1d32a81@mail.gmail.com> References: <220e47b40803201900u4bcc564ard2ab8ad6d1d32a81@mail.gmail.com> Message-ID: 2008/3/21 Krzysztof Skrz?tnicki : > ... > I'd like to write the following code: > > instance (Ord a) => YOrd a where > ycmp x y = case x `compare` y of > LT -> (x,y) > GT -> (y,x) > EQ -> (x,y) > > But i get an error "Undecidable instances" for any type [a]. > Does anyone know the way to solve this? The module compiles fine when you add the following pragma's to your module: {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE UndecidableInstances #-} See: http://www.haskell.org/ghc/docs/latest/html/users_guide/type-class-extensions.html#instance-rules http://www.haskell.org/ghc/docs/latest/html/users_guide/type-class-extensions.html#undecidable-instances regards, Bas From alistair at abayley.org Fri Mar 21 05:09:05 2008 From: alistair at abayley.org (Alistair Bayley) Date: Fri Mar 21 05:05:40 2008 Subject: [Haskell-cafe] ANN: Takusen 0.8.1 Message-ID: <79d7c4980803210209y30496aaeve42a0a88295afad3@mail.gmail.com> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Takusen-0.8.1 This is a fairly minor bugfix release. although there are some API changes. Mainly, we've re-exported a lot of the types from Database.InternalEnumerator in Database.Enumerator. This will hopefully address a common complaint that it's impossible to always write type sigs for functions doing database stuff. We've also tidied up some of the exports; there was stuff exposed that shouldn't have been. There's an outstanding bug involving datetime parameter marshaling in ODBC, which I have not had time to resolve (parameters after the datetime parameter get mangled somehow). I will be on holiday for a few weeks, so this will not be addressed by me for some time. Caveat user. The test suite highlights it, should someone else feel sufficiently motivated; I've been testing against PostgreSQL. Alistair From lemming at henning-thielemann.de Fri Mar 21 06:18:23 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri Mar 21 06:13:46 2008 Subject: [Haskell-cafe] Type checking of partial programs In-Reply-To: <47E2CADB.50008@di.unipi.it> References: <47E2CADB.50008@di.unipi.it> Message-ID: On Thu, 20 Mar 2008, Roberto Zunino wrote: > ac wrote: >> foo :: [Foo] -> >> foo xs = map xs >> >> What are the possible type signatures for placeholder 1 and the possible >> expressions for placeholder 2? > > A nice GHCi trick I learned from #haskell: > >> :t let foo xs = map ?placeholder2 xs in foo > > forall a b. (?placeholder2::a -> b) => [a] -> [b] > > Also, the djinn tool might provide some actual expression for placeholder 2. http://www.haskell.org/haskellwiki/Determining_the_type_of_an_expression From freeyourmind at gmail.com Fri Mar 21 11:11:53 2008 From: freeyourmind at gmail.com (Stephen Marsh) Date: Fri Mar 21 11:08:29 2008 Subject: [Haskell-cafe] Type constraints for class instances In-Reply-To: <220e47b40803201900u4bcc564ard2ab8ad6d1d32a81@mail.gmail.com> References: <220e47b40803201900u4bcc564ard2ab8ad6d1d32a81@mail.gmail.com> Message-ID: There is a bug in the code: *Main> ycmp [5,2] [2,5] :: ([Int], [Int]) ([2,2],[5,5]) I think it is impossible to define a working (YOrd a) => YOrd [a] instance. Consider: let (a, b) = ycmp [[1..], [2..]] [[1..],[1..]] head (b !! 1) -- would be nice if it was 2, but it is in fact _|_ We take forever to decide if [1..] is greater or less than [1..], so can never decide if [1..] or [2..] comes next. However Ord a => YOrd [a] can be made to work, and that is absolutely awesome, esp. once you start thinking about things like Ord a => YOrd (InfiniteTree a). This really is very cool, Krzysztof. Stephen 2008/3/20 Krzysztof Skrz?tnicki : > Hello everyone, > > I'm working on a small module for comparing things incomparable with Ord. > More precisely I want to be able to compare equal infinite lists like > [1..]. > Obviously > > (1) compare [1..] [1..] = _|_ > > It is perfectly reasonable for Ord to behave this way. > Hovever, it doesn't have to be just this way. Consider this class > > class YOrd a where > ycmp :: a -> a -> (a,a) > > In a way, it tells a limited version of ordering, since there is no > way to get `==` out of this. > Still it can be useful when Ord fails. Consider this code: > > (2) sort [ [1..], [2..], [3..] ] > > It is ok, because compare can decide between any elements in finite time. > However, this one > > (3) sort [ [1..], [1..] ] > > will fail because of (1). Compare is simply unable to tell that two > infinite list are equivalent. > I solved this by producing partial results while comparing lists. If > we compare lists > (1:xs) > (1:ys) > we may not be able to tell xs < ys, but we do can tell that 1 will be > the first element of both of smaller and greater one. > You can see this idea in the code below. > > > --- cut here --- > > {-# OPTIONS_GHC -O2 #-} > > module Data.YOrd where > > -- Well defined where Eq means equality, not only equivalence > > class YOrd a where > ycmp :: a -> a -> (a,a) > > > instance (YOrd a) => YOrd [a] where > ycmp [] [] = ([],[]) > ycmp xs [] = ([],xs) > ycmp [] xs = ([],xs) > ycmp xs'@(x:xs) ys'@(y:ys) = let (sm,gt) = x `ycmp` y in > let (smS,gtS) = xs `ycmp` ys in > (sm:smS, gt:gtS) > > > ycmpWrap x y = case x `compare` y of > LT -> (x,y) > GT -> (y,x) > EQ -> (x,y) -- biased - but we have to make our minds! > > -- ugly, see the problem below > instance YOrd Int where > ycmp = ycmpWrap > instance YOrd Char where > ycmp = ycmpWrap > instance YOrd Integer where > ycmp = ycmpWrap > > > -- ysort : sort of mergesort > > ysort :: (YOrd a) => [a] -> [a] > > ysort = head . mergeAll . wrap > > wrap :: [a] -> [[a]] > wrap xs = map (:[]) xs > > > mergeAll :: (YOrd a) => [[a]] -> [[a]] > mergeAll [] = [] > mergeAll [x] = [x] > mergeAll (a:b:rest) = mergeAll ((merge a b) : (mergeAll rest)) > > > merge :: (YOrd a) => [a] -> [a] -> [a] > merge [] [] = [] > merge xs [] = xs > merge [] xs = xs > merge (x:xs) (y:ys) = let (sm,gt) = x `ycmp` y in > sm : (merge [gt] $ merge xs ys) > > --- cut here --- > > I'd like to write the following code: > > instance (Ord a) => YOrd a where > ycmp x y = case x `compare` y of > LT -> (x,y) > GT -> (y,x) > EQ -> (x,y) > > > But i get an error "Undecidable instances" for any type [a]. > Does anyone know the way to solve this? > > > Best regards > > Christopher Skrz?tnicki > > _______________________________________________ > 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/20080321/610e1452/attachment.htm From heringtonlacey at mindspring.com Fri Mar 21 11:37:24 2008 From: heringtonlacey at mindspring.com (Dean Herington) Date: Fri Mar 21 11:34:27 2008 Subject: [Haskell-cafe] An ugly zip3 problem.. In-Reply-To: <47E32788.2030408@rbg.informatik.tu-darmstadt.de> References: <47E312A8.7060700@mindspring.com> <47E32788.2030408@rbg.informatik.tu-darmstadt.de> Message-ID: I like Tillmann's cleanup. Here's another variation (warning: untested code). filter3 :: (FilterWindow3 -> Double) -> Dataset -> Dataset filter3 f3 [] = [] filter3 f3 dss@(d:ds) = map f3 $ zip3 (d:dss) dss (shiftForward dss) -- Given a nonempty list, drops the first element and -- duplicates the last element at the end. shiftForward :: [a] -> [a] shiftForward (x:xs) = sf x xs where sf last [] = [last] sf _ (x:xs) = x : sf x xs Dean At 4:12 AM +0100 3/21/08, Tillmann Rendel wrote: >Michael Feathers wrote: >> I'm working on something and it's looking rather ugly. essentially, >> it's an application of a low pass filer to a dataset. > >I would not consider your code ugly. it can be made shorter, though. > >> type Dataset = [Double] >> type FilterWindow3 = (Double,Double,Double) >> >> internalList :: [a] -> [a] >> internalList = tail . init >> >> lowPass3 :: FilterWindow3 -> Double >> lowPass3 (i, j, k) = (i + 2 * j + k) / 4.0 >> >> filter3 :: (FilterWindow3 -> Double) -> Dataset -> Dataset >> filter3 f3 ds = [(f3 x) | x <- formWindows ds] > >I would prefer this version to the list comprehension: > > filter3 f3 = map f3 . formWindows > >I tend to assume list comprehensions are doing something magical I >have to figure out while reading a program, so a comprehension for a >simple map looks wrong to me. read ahead for more magical list >comprehensions. > >> iterFilter :: (Dataset -> Dataset) -> Int -> Dataset -> Dataset >> iterFilter f n ds >> | n > 0 = iterFilter f (n - 1) (f ds) >> | otherwise = ds > >You can use iterate and list indexing to iterate a function a >specified number of times. > > iterFilter f n = (!! n) . iterate f > >Probably > > iterateN :: (a -> a) -> Int -> a > >is a better type and name for this function. > >> formWindows :: Dataset -> [FilterWindow3] >> formWindows ds = >> internalList $ zip3 x y z >> where c0 = [head ds] >> cn = [last ds] >> x = ds ++ cn ++ cn >> y = c0 ++ ds ++ cn >> z = c0 ++ c0 ++ ds > >internalList will delete the first and last element, so why create >it at all? there is no problem with different list lengths, the >result will be as long as the shortest list. > > formWindows ds = zip3 x y z where > x = tail ds ++ [last ds] > y = ds > z = head ds : ds > >if you want to make clear what elements of the lists are used, you can use > > z = head ds : init ds > >instead. Note that definition for y clearly states that the middle >element is the original list. I would consider swapping x and z to >help me imagine a window moving over the dataset. as it is now, i >have to imagine a window with an integrated mirror to make it fit. > >I don't like the definition of x, because I fear that the (last ds) >thunk will hang around and hold the whole list ds in memory, which >is unecessary because it's value only depends on the last element of >said list. I would therefore consider a different implementation >using tails. > > formWindows ds = [(f y z, y, x) | (x : y : z) <- tails (head ds : ds)] > where f x [] = x > f _ (x : _) = x > >the head corner case is taken care of by duplicating the head of ds. >the last corner case is taken care of by the call to f, which uses y >as default value if z doesn't contain another one. the list >comprehension is used here to do three different things: > > * convert lists to tuples > * apply f > * throw away the last element of tails' result (pattern match > failure means "ignore this element" in list comprehensions) > >Maybe > > headDefault :: a -> [a] -> a > >is a sensible name for f. > >> smooth :: Int -> Dataset -> Dataset >> smooth = iterFilter $ filter3 lowPass3 > >by inlining the definition above, this can be given as a four-liner now: > > smooth n = (!! n) . iterate f where > f ds = [(g y z + 2 * y + x) / 4.0 | x:y:z <- tails (head ds : ds)] > g x [] = x > g _ (x:_) = x > >:-) > > Tillmann From freeyourmind at gmail.com Fri Mar 21 12:01:59 2008 From: freeyourmind at gmail.com (Stephen Marsh) Date: Fri Mar 21 11:58:35 2008 Subject: [Haskell-cafe] Type constraints for class instances In-Reply-To: References: <220e47b40803201900u4bcc564ard2ab8ad6d1d32a81@mail.gmail.com> Message-ID: Actually, infinite trees wouldn't work, for a similar reason to above. You can't decide sort order on the infinite left branches, so you could never choose the correct right branch. Stephen 2008/3/21 Stephen Marsh : > There is a bug in the code: > > *Main> ycmp [5,2] [2,5] :: ([Int], [Int]) > ([2,2],[5,5]) > > I think it is impossible to define a working (YOrd a) => YOrd [a] > instance. Consider: > > let (a, b) = ycmp [[1..], [2..]] [[1..],[1..]] > > head (b !! 1) -- would be nice if it was 2, but it is in fact _|_ > > We take forever to decide if [1..] is greater or less than [1..], so can > never decide if [1..] or [2..] comes next. > > However Ord a => YOrd [a] can be made to work, and that is absolutely > awesome, esp. once you start thinking about things like Ord a => YOrd > (InfiniteTree a). This really is very cool, Krzysztof. > > Stephen > > 2008/3/20 Krzysztof Skrz?tnicki : > > > Hello everyone, > > > > I'm working on a small module for comparing things incomparable with > > Ord. > > More precisely I want to be able to compare equal infinite lists like > > [1..]. > > Obviously > > > > (1) compare [1..] [1..] = _|_ > > > > It is perfectly reasonable for Ord to behave this way. > > Hovever, it doesn't have to be just this way. Consider this class > > > > class YOrd a where > > ycmp :: a -> a -> (a,a) > > > > In a way, it tells a limited version of ordering, since there is no > > way to get `==` out of this. > > Still it can be useful when Ord fails. Consider this code: > > > > (2) sort [ [1..], [2..], [3..] ] > > > > It is ok, because compare can decide between any elements in finite > > time. > > However, this one > > > > (3) sort [ [1..], [1..] ] > > > > will fail because of (1). Compare is simply unable to tell that two > > infinite list are equivalent. > > I solved this by producing partial results while comparing lists. If > > we compare lists > > (1:xs) > > (1:ys) > > we may not be able to tell xs < ys, but we do can tell that 1 will be > > the first element of both of smaller and greater one. > > You can see this idea in the code below. > > > > > > --- cut here --- > > > > {-# OPTIONS_GHC -O2 #-} > > > > module Data.YOrd where > > > > -- Well defined where Eq means equality, not only equivalence > > > > class YOrd a where > > ycmp :: a -> a -> (a,a) > > > > > > instance (YOrd a) => YOrd [a] where > > ycmp [] [] = ([],[]) > > ycmp xs [] = ([],xs) > > ycmp [] xs = ([],xs) > > ycmp xs'@(x:xs) ys'@(y:ys) = let (sm,gt) = x `ycmp` y in > > let (smS,gtS) = xs `ycmp` ys in > > (sm:smS, gt:gtS) > > > > > > ycmpWrap x y = case x `compare` y of > > LT -> (x,y) > > GT -> (y,x) > > EQ -> (x,y) -- biased - but we have to make our minds! > > > > -- ugly, see the problem below > > instance YOrd Int where > > ycmp = ycmpWrap > > instance YOrd Char where > > ycmp = ycmpWrap > > instance YOrd Integer where > > ycmp = ycmpWrap > > > > > > -- ysort : sort of mergesort > > > > ysort :: (YOrd a) => [a] -> [a] > > > > ysort = head . mergeAll . wrap > > > > wrap :: [a] -> [[a]] > > wrap xs = map (:[]) xs > > > > > > mergeAll :: (YOrd a) => [[a]] -> [[a]] > > mergeAll [] = [] > > mergeAll [x] = [x] > > mergeAll (a:b:rest) = mergeAll ((merge a b) : (mergeAll rest)) > > > > > > merge :: (YOrd a) => [a] -> [a] -> [a] > > merge [] [] = [] > > merge xs [] = xs > > merge [] xs = xs > > merge (x:xs) (y:ys) = let (sm,gt) = x `ycmp` y in > > sm : (merge [gt] $ merge xs ys) > > > > --- cut here --- > > > > I'd like to write the following code: > > > > instance (Ord a) => YOrd a where > > ycmp x y = case x `compare` y of > > LT -> (x,y) > > GT -> (y,x) > > EQ -> (x,y) > > > > > > But i get an error "Undecidable instances" for any type [a]. > > Does anyone know the way to solve this? > > > > > > Best regards > > > > Christopher Skrz?tnicki > > > > _______________________________________________ > > 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/20080321/d1825533/attachment.htm From paul at cogito.org.uk Fri Mar 21 14:02:18 2008 From: paul at cogito.org.uk (Paul Johnson) Date: Fri Mar 21 13:58:57 2008 Subject: [Haskell-cafe] AMQP framing layer: design help requested. Message-ID: <47E3F82A.7020405@cogito.org.uk> I'm trying to implement the AMQP framing layer. This is the bottom layer of the protocol that packs and unpacks data in lazy ByteStrings. I'm using the Binary package with its "Get" and "Put" monads to do the unpacking, and that works well. But I've run into a problem and I can't find an elegant solution. I'm wondering if someone can help. The following contains a simplified version of my current design. I've mapped the AMQP basic types to Haskell types. Sometimes this is a basic mapping, sometimes to something more complex. Strings have several AMQP representations, so I've created corresponding newtype declarations and instances. Some AMQP types can contain tagged types. For instance a "map" contains (key, tag, value) triples, where the tag is a single byte indicating the type of the value. I've defined the following type: data AmqpVariant = AmqpVarWord8 Word8 | AmqpVarWord16 Word16 | AmqpVarStr8 Str8 -- And so on for about 20 more types instance Binary AmqpVariant where put (AmqpVarWord8 v)= putWord8 0x01 >> putWord8 v put (AmqpVarWord16 v) = putWord8 0x02 >> putWord16be v put (AmqpVarStr8 v) = putWord8 0x03 >> put v -- And so on for about 20 more types get = do getter <- fmap (amqpGetTable !) getWord8 getter amqpGetTable :: Array Word8 (Get AmqpVariant) amqpGetTable = array (0,255) [ (0x01, fmap AmqpVarWord8 getWord8), (0x02, fmap AmqpVarWord16 getWord16be), (0x03, fmap AmqpVarStr8 get), -- And so on for about 20 more types ] This is a Brute Force and Ignorance solution, but it will probably work. But now I've come up against another type, which AMQP calls an "array". This has a single type tag at the start, followed by N items of that type. I'm wondering how to do this. One option would be to declare data AmqpArray = AmqpArrWord8 [Word8] | AmqpArrWord16 [Word16] -- and so on This effectively duplicates the AmqpVariant solution. It would work, but it feels horrible. I get the feeling that there ought to be a better way, possibly using classes or existential types. Any suggestions? Thanks, Paul. From dons at galois.com Fri Mar 21 14:03:38 2008 From: dons at galois.com (Don Stewart) Date: Fri Mar 21 14:00:20 2008 Subject: [Haskell-cafe] ANN: Takusen 0.8.1 In-Reply-To: <79d7c4980803210209y30496aaeve42a0a88295afad3@mail.gmail.com> References: <79d7c4980803210209y30496aaeve42a0a88295afad3@mail.gmail.com> Message-ID: <20080321180338.GE11577@scytale.galois.com> alistair: > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Takusen-0.8.1 > > This is a fairly minor bugfix release. although there are some API > changes. Mainly, we've re-exported a lot of the types from > Database.InternalEnumerator in Database.Enumerator. This will > hopefully address a common complaint that it's impossible to always > write type sigs for functions doing database stuff. > > We've also tidied up some of the exports; there was stuff exposed that > shouldn't have been. > > There's an outstanding bug involving datetime parameter marshaling in > ODBC, which I have not had time to resolve (parameters after the > datetime parameter get mangled somehow). I will be on holiday for a > few weeks, so this will not be addressed by me for some time. Caveat > user. The test suite highlights it, should someone else feel > sufficiently motivated; I've been testing against PostgreSQL. > > Alistair Great work Alistair! Thanks for your continuing work on Takusen. -- Don From garious at gmail.com Fri Mar 21 14:45:34 2008 From: garious at gmail.com (Greg Fitzgerald) Date: Fri Mar 21 14:42:13 2008 Subject: [Haskell-cafe] reactive programming, what's hot? Message-ID: <1f3dc80d0803211145o159d6e75vbabafce38ab2194d@mail.gmail.com> A new version of yampawas uploaded to hackage today, but it's website hasn't been updated since 2004. SpaceInvadersdepends on HGL and Yampa. There's been more noise around Phooeyand TV in recent months, but afaik, hasn't been used for any applications yet. There was also ParseP which seems to tackle a similar problem, but from the perspective of a more general parsing library. Are there other purely functional reactive libraries in active development? Why might one choose one over another? Thanks, Greg -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080321/be0ad980/attachment.htm From ggg at cs.nott.ac.uk Fri Mar 21 15:33:17 2008 From: ggg at cs.nott.ac.uk (George Giorgidze) Date: Fri Mar 21 15:29:53 2008 Subject: [Haskell-cafe] Problem with OpenAL Message-ID: I tried OpenAL binding (the one which is on the Hackage), but with no luck. I can not hear anything from speakers and also according to generated output on console it seems that "AL.play" never completes playback of a buffer as buffer remains registered as "unprocessed" in OpenAL context. Here is the piece of code. I am not getting any error messages from OpenAL library functions. playOpenAL :: Int -> IO () playOpenAL sr = do mDevice <- AL.openDevice Nothing when (isNothing mDevice) $ error "opening OpenAL device" let device = fromJust mDevice mContext <- AL.createContext device [ AL.Frequency (fromIntegral sr) , AL.Refresh (fromIntegral sr) ] when (isNothing mContext) $ error "creating OpenAL context" let context = fromJust mContext AL.currentContext AL.$= (Just context) let sampleNumber = 256 bufSize = sampleNumber * (sizeOf (undefined :: CShort)) buf2 <- mallocBytes bufSize -- here I am filling buf2 with noise .... [source] <- AL.genObjectNames 1 [buffer] <- AL.genObjectNames 1 let region = AL.MemoryRegion buf2 (fromIntegral bufSize) AL.bufferData buffer AL.$= (AL.BufferData region AL.Mono16 (fromIntegral sr)) AL.queueBuffers source [buffer] AL.loopingMode source AL.$= AL.OneShot let waitForSource = do putStrLn "waiting" s <- AL.get (AL.buffersProcessed source) putStrLn $ show s s <- AL.get (AL.buffersQueued source) putStrLn $ show s state <- AL.get (AL.sourceState source) case state of AL.Playing -> do threadDelay 1024 waitForSource _ -> return () putStrLn "Start Playing ... " AL.play [source] waitForSource AL.currentContext AL.$= Nothing AL.destroyContext context b <- AL.closeDevice device when (not b) $ error "closing device" Is this library still maintained? Best, George -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080321/4b29059a/attachment.htm From batterseapower at hotmail.com Fri Mar 21 18:23:37 2008 From: batterseapower at hotmail.com (Max Bolingbroke) Date: Fri Mar 21 18:20:13 2008 Subject: [Haskell-cafe] [GSoC] Plugins for GHC Message-ID: <9d4d38820803211523s131108e1le52e7f6840c43995@mail.gmail.com> Hi, I'm interested in working on a plugins system for the Glasgow Haskell Compiler. The idea here is to allow third parties to add more capabilities to the compiler in a way that doesn't involve messing around with modifying GHC itself. Potential use cases are: * Allow Haskell code to be selectively run on GPUs * Idiosyncratic application-specific optimization passes * And whatever clever ideas the community comes up with! This project has previously been proposed as an Microsoft Research internship project (http://hackage.haskell.org/trac/ghc/wiki/Internships).I have a preliminary wiki page with details at http://hackage.haskell.org/trac/ghc/wiki/Plugins I'd particularly like to get feedback from the list on: * Other design goals people would like to see * Improvements to the proposed (very half-baked!) user interface * Other hooks people think they might like to have into the compiler * Interested mentors. Simon PJ has indicated he would be interested in mentoring this, but there might be other projects that need him more? This project would satisfy a dependency that Manuel mentioned in http://groups.google.com/group/fa.haskell/msg/3ca260fb075a901e to implement an "array DSL" for GPUs in Haskell. It would mean GHC taking a dependency on hs-plugins (http://www.cse.unsw.edu.au/~dons/hs-plugins/), as that's our current strategy to allow GHC to dynamically link with the plugins. A little about my experience with GHC: this year I worked on implementing comprehensive comprehensions (http://research.microsoft.com/~simonpj/papers/list-comp/index.htm) as my final year undergraduate project, supervised by Simon PJ. I have subsequently implemented a few other patches, adding some core-level optimizations / bug fixes (some of which are pending review). Thanks in advance for your comments! Max From gtener at gmail.com Fri Mar 21 20:15:40 2008 From: gtener at gmail.com (=?ISO-8859-2?Q?Krzysztof_Skrz=EAtnicki?=) Date: Fri Mar 21 20:12:15 2008 Subject: [Haskell-cafe] Type constraints for class instances In-Reply-To: References: <220e47b40803201900u4bcc564ard2ab8ad6d1d32a81@mail.gmail.com> Message-ID: <220e47b40803211715u15c09920le1c5cf148b964e5c@mail.gmail.com> It compiles, but it doesn't work when i try to use it on lists. There are some bugs in that code, but I need some time to fix it. 2008/3/21 Bas van Dijk : > 2008/3/21 Krzysztof Skrz?tnicki : > > ... > > > I'd like to write the following code: > > > > instance (Ord a) => YOrd a where > > ycmp x y = case x `compare` y of > > LT -> (x,y) > > GT -> (y,x) > > EQ -> (x,y) > > > > But i get an error "Undecidable instances" for any type [a]. > > Does anyone know the way to solve this? > > The module compiles fine when you add the following pragma's to your module: > > {-# LANGUAGE FlexibleInstances #-} > {-# LANGUAGE UndecidableInstances #-} > > See: > http://www.haskell.org/ghc/docs/latest/html/users_guide/type-class-extensions.html#instance-rules > http://www.haskell.org/ghc/docs/latest/html/users_guide/type-class-extensions.html#undecidable-instances > > regards, > > Bas > From agl at imperialviolet.org Fri Mar 21 21:41:47 2008 From: agl at imperialviolet.org (Adam Langley) Date: Fri Mar 21 21:38:22 2008 Subject: [Haskell-cafe] AMQP framing layer: design help requested. In-Reply-To: <47E3F82A.7020405@cogito.org.uk> References: <47E3F82A.7020405@cogito.org.uk> Message-ID: <396556a20803211841o4438f557w6d3c41f9644db873@mail.gmail.com> On Fri, Mar 21, 2008 at 11:02 AM, Paul Johnson wrote: > This effectively duplicates the AmqpVariant solution. It would work, > but it feels horrible. I get the feeling that there ought to be a > better way, possibly using classes or existential types. Any suggestions? Firstly, I would use the Get and Put monads directly, rather than making them instances of Binary. I think, if I were doing it, I would start off with something like this: class AMQPValue a where putAMQP :: a -> Put instance AMQPValue Word8 where putAMQP v = putWord8 1 >> putWord8 v ... (many instances) instance (AMQPValue a) => AMQPValue [a] where putAMQP vs = putWord8 (length vs) >> mapM_ putAMQP vs You probably want a getAMQP member of the AMQPValue class too. Also > getter <- fmap (amqpGetTable !) getWord8 > getter is just > fmap (amqpGetTable !) getWord8 Hope that helps some AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org From agl at imperialviolet.org Fri Mar 21 21:43:27 2008 From: agl at imperialviolet.org (Adam Langley) Date: Fri Mar 21 21:40:02 2008 Subject: [Haskell-cafe] AMQP framing layer: design help requested. In-Reply-To: <396556a20803211841o4438f557w6d3c41f9644db873@mail.gmail.com> References: <47E3F82A.7020405@cogito.org.uk> <396556a20803211841o4438f557w6d3c41f9644db873@mail.gmail.com> Message-ID: <396556a20803211843s1ca7eefdna4071236575e41a6@mail.gmail.com> On Fri, Mar 21, 2008 at 6:41 PM, Adam Langley wrote: > Firstly, I would use the Get and Put monads directly, rather than > making them instances of Binary. Also, while I'm at it - I believe that AMQP messages and small and delineated. In which case, the Data.Binary.Strict.Get monad from the binary-strict package might be a better match (shameless self-plug) AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org From vigalchin at gmail.com Sat Mar 22 00:21:26 2008 From: vigalchin at gmail.com (Galchin Vasili) Date: Sat Mar 22 00:18:01 2008 Subject: [Haskell-cafe] compile error with FFI code Message-ID: <5ae4f2ba0803212121w17fe482ek105c13cf6999e603@mail.gmail.com> Hello, In my blah.hsc, I have "allocbytes (#const (struct bozo)) .. where struct bozo is a bunch of "long int" ,,, In the "runhaskell Setup.hs build" step I get a nasty error message about an "incomplete type". I have look at many times but this error doesn't make sense to me. ?? Kind regards, Vasili -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080321/273d5ca0/attachment.htm From shaun at cuttshome.net Sat Mar 22 02:20:38 2008 From: shaun at cuttshome.net (Shaun Cutts) Date: Sat Mar 22 02:13:59 2008 Subject: [Haskell-cafe] "doctest" for haskell -- a good project? Message-ID: <04bd01c88be4$d998c010$7000a8c0@INTERLINK> Hello, I am an experienced programmer, currently learning Haskell. Currently I write many things in python. I use both the "doctest" and "unittest" modules extensively. As I write code, I simultaneously write doctest code in the doc strings to explain/set out the "typical narrative" of how the code is used. Then finishing off a module I write unittests for boundary conditions, more complex test cases, and generally code that would be annoying to write & read in doctests. I note that there is a unit testing framework for Haskell, but I don't see any doctest module. Might this be a good project? If so, suggestions as to resources would be greatly appreciated. I believe I can't just "introspect" Haskell modules to get at documentation/comments, like I can in python? (Why not? :)) I notice that there are a few "documentation generators". Should I try to write an extension of one of these? Haddock, for instance? Are there any Haddock developers hanging out on this list, to encourage or dissuade me? :) (And where is the Haddock doc for Haddock?) In any case, thanks in advance for any comments & advice. - Shaun Cutts -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080322/185fb821/attachment.htm From bulat.ziganshin at gmail.com Sat Mar 22 03:08:50 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sat Mar 22 03:22:45 2008 Subject: [Haskell-cafe] [GSoC] Plugins for GHC In-Reply-To: <9d4d38820803211523s131108e1le52e7f6840c43995@mail.gmail.com> References: <9d4d38820803211523s131108e1le52e7f6840c43995@mail.gmail.com> Message-ID: <19110011979.20080322100850@gmail.com> Hello Max, Saturday, March 22, 2008, 1:23:37 AM, you wrote: > around with modifying GHC itself. Potential use cases are: > * And whatever clever ideas the community comes up with! i'm interested in syntax macros feature like metalua -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From roma at ro-che.info Sat Mar 22 04:29:33 2008 From: roma at ro-che.info (Roman Cheplyaka) Date: Sat Mar 22 04:26:09 2008 Subject: [Haskell-cafe] "doctest" for haskell -- a good project? In-Reply-To: <04bd01c88be4$d998c010$7000a8c0@INTERLINK> References: <04bd01c88be4$d998c010$7000a8c0@INTERLINK> Message-ID: <20080322082932.GA3361@home.ro-che.info> * Shaun Cutts [2008-03-22 02:20:38-0400] > Hello, > > I am an experienced programmer, currently learning Haskell. Currently I > write many things in python. I use both the "doctest" and "unittest" modules > extensively. As I write code, I simultaneously write doctest code in the doc > strings to explain/set out the "typical narrative" of how the code is used. > Then finishing off a module I write unittests for boundary conditions, more > complex test cases, and generally code that would be annoying to write & > read in doctests. > > I note that there is a unit testing framework for Haskell, but I don't see > any doctest module. Might this be a good project? > > If so, suggestions as to resources would be greatly appreciated. I believe I > can't just "introspect" Haskell modules to get at documentation/comments, > like I can in python? (Why not? :)) I notice that there are a few > "documentation generators". Should I try to write an extension of one of > these? Haddock, for instance? Are there any Haddock developers hanging out > on this list, to encourage or dissuade me? :) (And where is the Haddock doc > for Haddock?) > > In any case, thanks in advance for any comments & advice. > > - Shaun Cutts Did you try haddock? -- Roman I. Cheplyaka :: http://ro-che.info/ ...being in love is totally punk rock... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080322/0a310583/attachment.bin From dons at galois.com Sat Mar 22 04:39:44 2008 From: dons at galois.com (Don Stewart) Date: Sat Mar 22 04:36:20 2008 Subject: [Haskell-cafe] "doctest" for haskell -- a good project? In-Reply-To: <04bd01c88be4$d998c010$7000a8c0@INTERLINK> References: <04bd01c88be4$d998c010$7000a8c0@INTERLINK> Message-ID: <20080322083944.GA30413@scytale.galois.com> shaun: > Hello, > > I am an experienced programmer, currently learning Haskell. Currently I > write many things in python. I use both the "doctest" and "unittest" > modules extensively. As I write code, I simultaneously write doctest code > in the doc strings to explain/set out the "typical narrative" of how the > code is used. Then finishing off a module I write unittests for boundary > conditions, more complex test cases, and generally code that would be > annoying to write & read in doctests. > > I note that there is a unit testing framework for Haskell, but I don't see There's a couple, QuickCheck is the best, it generalises unit testing to property testing with random, or not so random, data. > any doctest module. Might this be a good project? > If so, suggestions as to resources would be greatly appreciated. I believe > I can't just "introspect" Haskell modules to get at > documentation/comments, like I can in python? (Why not? :)) I notice that > there are a few "documentation generators". Should I try to write an > extension of one of these? Haddock, for instance? Are there any Haddock > developers hanging out on this list, to encourage or dissuade me? :) (And > where is the Haddock doc for Haddock?) > > In any case, thanks in advance for any comments & advice. I'm not sure how doctest works, or how it would work in a Haskell setting, could you elaborate? One idea that does strike me is that it would be super useful to have the ability in ghci to extract the haddocks associated with a function. > :doc map would result in: -- | 'map' @f xs@ is the list obtained by applying @f@ to each element -- of @xs@, i.e., -- -- > map f [x1, x2, ..., xn] == [f x1, f x2, .. -- > map f [x1, x2, ...] == [f x1, f x2, ...] marked up in ascii. I'm not sure if that's related to doctest, but it sure would be useful! -- Don From ndmitchell at gmail.com Sat Mar 22 08:15:26 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Sat Mar 22 08:11:58 2008 Subject: [Haskell-cafe] [GSoC] Plugins for GHC In-Reply-To: <9d4d38820803211523s131108e1le52e7f6840c43995@mail.gmail.com> References: <9d4d38820803211523s131108e1le52e7f6840c43995@mail.gmail.com> Message-ID: <404396ef0803220515n52dc7cfbg5b565ba2e481c27b@mail.gmail.com> Hi Max, This sounds fantastic! My only question would be how this relates to the external Core work that Tim has been doing. If we have this, can external core become a plugin? If we have this, do we no longer need external Core? It seems to say that we don't want external Core as the interface, as it won't be stable in any way - does that mean we don't want external Core at all? Thanks Neil We certainly need a mechanism for doing On 3/21/08, Max Bolingbroke wrote: > Hi, > > I'm interested in working on a plugins system for the Glasgow Haskell > Compiler. The idea here is to allow third parties to add more > capabilities to the compiler in a way that doesn't involve messing > around with modifying GHC itself. Potential use cases are: > * Allow Haskell code to be selectively run on GPUs > * Idiosyncratic application-specific optimization passes > * And whatever clever ideas the community comes up with! > > This project has previously been proposed as an Microsoft Research > internship project > (http://hackage.haskell.org/trac/ghc/wiki/Internships).I have a > preliminary wiki page with details at > http://hackage.haskell.org/trac/ghc/wiki/Plugins > > I'd particularly like to get feedback from the list on: > * Other design goals people would like to see > * Improvements to the proposed (very half-baked!) user interface > * Other hooks people think they might like to have into the compiler > * Interested mentors. Simon PJ has indicated he would be interested in > mentoring this, but there might be other projects that need him more? > > This project would satisfy a dependency that Manuel mentioned in > http://groups.google.com/group/fa.haskell/msg/3ca260fb075a901e to > implement an "array DSL" for GPUs in Haskell. It would mean GHC taking > a dependency on hs-plugins > (http://www.cse.unsw.edu.au/~dons/hs-plugins/), as that's our current > strategy to allow GHC to dynamically link with the plugins. > > A little about my experience with GHC: this year I worked on > implementing comprehensive comprehensions > (http://research.microsoft.com/~simonpj/papers/list-comp/index.htm) as > my final year undergraduate project, supervised by Simon PJ. I have > subsequently implemented a few other patches, adding some core-level > optimizations / bug fixes (some of which are pending review). > > Thanks in advance for your comments! > Max > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From ndmitchell at gmail.com Sat Mar 22 08:17:48 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Sat Mar 22 08:14:22 2008 Subject: [Haskell-cafe] "doctest" for haskell -- a good project? In-Reply-To: <20080322083944.GA30413@scytale.galois.com> References: <04bd01c88be4$d998c010$7000a8c0@INTERLINK> <20080322083944.GA30413@scytale.galois.com> Message-ID: <404396ef0803220517w35ac8e81u41026c85bd9ebe1d@mail.gmail.com> Hi > One idea that does strike me is that it would be super useful to have > the ability in ghci to extract the haddocks associated with a function. > > > :doc map > > would result in: > > -- | 'map' @f xs@ is the list obtained by applying @f@ to each element > -- of @xs@, i.e., > -- > -- > map f [x1, x2, ..., xn] == [f x1, f x2, .. > -- > map f [x1, x2, ...] == [f x1, f x2, ...] That will be in Hoogle 4, as it does already directly relate to what Hoogle has to do. As for doctest, i think that could be implemented as a --warn flag to Haddock, and might be a useful thing to have. For example "90% of the base library has documentation, please go add documentation to 'sinh'", as a warning message. Thanks Neil From mfeathers at mindspring.com Sat Mar 22 08:45:01 2008 From: mfeathers at mindspring.com (Michael Feathers) Date: Sat Mar 22 08:43:16 2008 Subject: [Haskell-cafe] An ugly zip3 problem.. In-Reply-To: <47E32788.2030408@rbg.informatik.tu-darmstadt.de> References: <47E312A8.7060700@mindspring.com> <47E32788.2030408@rbg.informatik.tu-darmstadt.de> Message-ID: <47E4FF4D.5000000@mindspring.com> Thanks! I learned a lot from that. Michael Tillmann Rendel wrote: > Michael Feathers wrote: > > I'm working on something and it's looking rather ugly. essentially, > > it's an application of a low pass filer to a dataset. > > I would not consider your code ugly. it can be made shorter, though. > > > type Dataset = [Double] > > type FilterWindow3 = (Double,Double,Double) > > > > internalList :: [a] -> [a] > > internalList = tail . init > > > > lowPass3 :: FilterWindow3 -> Double > > lowPass3 (i, j, k) = (i + 2 * j + k) / 4.0 > > > > filter3 :: (FilterWindow3 -> Double) -> Dataset -> Dataset > > filter3 f3 ds = [(f3 x) | x <- formWindows ds] > > I would prefer this version to the list comprehension: > > filter3 f3 = map f3 . formWindows > > I tend to assume list comprehensions are doing something magical I have > to figure out while reading a program, so a comprehension for a simple > map looks wrong to me. read ahead for more magical list comprehensions. > > > iterFilter :: (Dataset -> Dataset) -> Int -> Dataset -> Dataset > > iterFilter f n ds > > | n > 0 = iterFilter f (n - 1) (f ds) > > | otherwise = ds > > You can use iterate and list indexing to iterate a function a specified > number of times. > > iterFilter f n = (!! n) . iterate f > > Probably > > iterateN :: (a -> a) -> Int -> a > > is a better type and name for this function. > > > formWindows :: Dataset -> [FilterWindow3] > > formWindows ds = > > internalList $ zip3 x y z > > where c0 = [head ds] > > cn = [last ds] > > x = ds ++ cn ++ cn > > y = c0 ++ ds ++ cn > > z = c0 ++ c0 ++ ds > > internalList will delete the first and last element, so why create it at > all? there is no problem with different list lengths, the result will be > as long as the shortest list. > > formWindows ds = zip3 x y z where > x = tail ds ++ [last ds] > y = ds > z = head ds : ds > > if you want to make clear what elements of the lists are used, you can use > > z = head ds : init ds > > instead. Note that definition for y clearly states that the middle > element is the original list. I would consider swapping x and z to help > me imagine a window moving over the dataset. as it is now, i have to > imagine a window with an integrated mirror to make it fit. > > I don't like the definition of x, because I fear that the (last ds) > thunk will hang around and hold the whole list ds in memory, which is > unecessary because it's value only depends on the last element of said > list. I would therefore consider a different implementation using tails. > > formWindows ds = [(f y z, y, x) | (x : y : z) <- tails (head ds : ds)] > where f x [] = x > f _ (x : _) = x > > the head corner case is taken care of by duplicating the head of ds. the > last corner case is taken care of by the call to f, which uses y as > default value if z doesn't contain another one. the list comprehension > is used here to do three different things: > > * convert lists to tuples > * apply f > * throw away the last element of tails' result (pattern match > failure means "ignore this element" in list comprehensions) > > Maybe > > headDefault :: a -> [a] -> a > > is a sensible name for f. > > > smooth :: Int -> Dataset -> Dataset > > smooth = iterFilter $ filter3 lowPass3 > > by inlining the definition above, this can be given as a four-liner now: > > smooth n = (!! n) . iterate f where > f ds = [(g y z + 2 * y + x) / 4.0 | x:y:z <- tails (head ds : ds)] > g x [] = x > g _ (x:_) = x > > :-) > > Tillmann > -- Now Playing: http://www.youtube.com/watch?v=SsnDdq4V8zg From mfeathers at mindspring.com Sat Mar 22 08:53:58 2008 From: mfeathers at mindspring.com (Michael Feathers) Date: Sat Mar 22 08:52:10 2008 Subject: [Haskell-cafe] An ugly zip3 problem.. In-Reply-To: <47E32788.2030408@rbg.informatik.tu-darmstadt.de> References: <47E312A8.7060700@mindspring.com> <47E32788.2030408@rbg.informatik.tu-darmstadt.de> Message-ID: <47E50166.8070302@mindspring.com> One thing that gets me about this solution.. as I was structuring mine I noticed that I was ending up with types like FilterWindow3 and functions like lowPass3. Inlining does eliminate them, but I wonder whether there is a good way to structure the computation generically so that it can be performed with windows of 5 as well as 3. The cons pattern matching here would get in the way, and in my original solution, the fact that I was using tuples got in the way also. Would Haskell's type system allow you to pass a function of arbitrary arity, discern its arity, use that information to construct the appropriate structure for iteration, and then apply it? Michael Tillmann Rendel wrote: > > by inlining the definition above, this can be given as a four-liner now: > > smooth n = (!! n) . iterate f where > f ds = [(g y z + 2 * y + x) / 4.0 | x:y:z <- tails (head ds : ds)] > g x [] = x > g _ (x:_) = x > > :-) > > Tillmann > -- Now Playing: http://www.youtube.com/watch?v=SsnDdq4V8zg From knifewolf at gmail.com Sat Mar 22 09:40:01 2008 From: knifewolf at gmail.com (Deng Chao) Date: Sat Mar 22 09:44:22 2008 Subject: [Haskell-cafe] How to program with sqlite? Message-ID: <1206193201.9417.4.camel@knifewolfUBUNTU> Hi all, I'm learning sqlite, and as I know haskell has some libraries like HDBC or HSQL can access sqlite DB. Can anybody give me a small example to show how to use it? It will be very appreciate? Thanks! Best Regards, Deng Chao From nominolo at googlemail.com Sat Mar 22 09:53:31 2008 From: nominolo at googlemail.com (Thomas Schilling) Date: Sat Mar 22 09:50:11 2008 Subject: [Haskell-cafe] "doctest" for haskell -- a good project? In-Reply-To: <404396ef0803220517w35ac8e81u41026c85bd9ebe1d@mail.gmail.com> References: <04bd01c88be4$d998c010$7000a8c0@INTERLINK> <20080322083944.GA30413@scytale.galois.com> <404396ef0803220517w35ac8e81u41026c85bd9ebe1d@mail.gmail.com> Message-ID: <1413441C-C2FE-4451-837E-19908C607843@googlemail.com> On 22 mar 2008, at 13.17, Neil Mitchell wrote: > Hi > >> One idea that does strike me is that it would be super useful to >> have >> the ability in ghci to extract the haddocks associated with a >> function. >> >>> :doc map >> >> would result in: >> >> -- | 'map' @f xs@ is the list obtained by applying @f@ to >> each element >> -- of @xs@, i.e., >> -- >> -- > map f [x1, x2, ..., xn] == [f x1, f x2, .. >> -- > map f [x1, x2, ...] == [f x1, f x2, ...] > > That will be in Hoogle 4, as it does already directly relate to what > Hoogle has to do. > > As for doctest, i think that could be implemented as a --warn flag to > Haddock, and might be a useful thing to have. For example "90% of the > base library has documentation, please go add documentation to > 'sinh'", as a warning message. > Though that would be a nice feature, too, I think you misunderstood what a doctest is. A doctest is a unit test in the documentation. This way it serves as a usage example as well as a formal specification of the semantics. I think we already have some way to run quickchecks inside documentation, but I can't remember what it was that could do that. / Thomas From sebastian.sylvan at gmail.com Sat Mar 22 10:15:02 2008 From: sebastian.sylvan at gmail.com (Sebastian Sylvan) Date: Sat Mar 22 10:11:35 2008 Subject: [Haskell-cafe] How to program with sqlite? In-Reply-To: <1206193201.9417.4.camel@knifewolfUBUNTU> References: <1206193201.9417.4.camel@knifewolfUBUNTU> Message-ID: <3d96ac180803220715q50c2f0c8gbbd538c3deb26c3e@mail.gmail.com> On Sat, Mar 22, 2008 at 1:40 PM, Deng Chao wrote: > Hi all, > I'm learning sqlite, and as I know haskell has some libraries like > HDBC or HSQL can access sqlite DB. Can anybody give me a small example > to show how to use it? It will be very appreciate? Thanks! > > Best Regards, > Deng Chao > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > Here's a quick GHCi session with HDBC. Prelude> :m +Database.HDBC Prelude Database.HDBC> :m +Database.HDBC.Sqlite3 Prelude Database.HDBC Database.HDBC.Sqlite3> conn <- connectSqlite3 "mydb" Prelude Database.HDBC Database.HDBC.Sqlite3> quickQuery conn "CREATE TABLE mytable (FirstName varchar, LastName varchar, Age int )" [] [] Prelude Database.HDBC Database.HDBC.Sqlite3> quickQuery conn "INSERT INTO mytable VALUES ('Sebastian','Sylvan',26)" [] [] Prelude Database.HDBC Database.HDBC.Sqlite3> commit conn Prelude Database.HDBC Database.HDBC.Sqlite3> quickQuery conn "SELECT * FROM mytable" [] [[SqlString "Sebastian",SqlString "Sylvan",SqlString "26"]] Prelude Database.HDBC Database.HDBC.Sqlite3> disconnect conn Not sure why that Age field came back as a string though :-) -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080322/37aaabaf/attachment.htm From sebastian.sylvan at gmail.com Sat Mar 22 10:20:10 2008 From: sebastian.sylvan at gmail.com (Sebastian Sylvan) Date: Sat Mar 22 10:16:42 2008 Subject: [Haskell-cafe] "doctest" for haskell -- a good project? In-Reply-To: <20080322083944.GA30413@scytale.galois.com> References: <04bd01c88be4$d998c010$7000a8c0@INTERLINK> <20080322083944.GA30413@scytale.galois.com> Message-ID: <3d96ac180803220720v49847f9fq9f6930cb372f5c6f@mail.gmail.com> On Sat, Mar 22, 2008 at 8:39 AM, Don Stewart wrote: > shaun: > > Hello, > > > > I am an experienced programmer, currently learning Haskell. Currently > I > > write many things in python. I use both the "doctest" and "unittest" > > modules extensively. As I write code, I simultaneously write doctest > code > > in the doc strings to explain/set out the "typical narrative" of how > the > > code is used. Then finishing off a module I write unittests for > boundary > > conditions, more complex test cases, and generally code that would be > > annoying to write & read in doctests. > > > > I note that there is a unit testing framework for Haskell, but I > don't see > > There's a couple, QuickCheck is the best, it generalises unit testing to > property testing with random, or not so random, data. > > > any doctest module. Might this be a good project? > > If so, suggestions as to resources would be greatly appreciated. I > believe > > I can't just "introspect" Haskell modules to get at > > documentation/comments, like I can in python? (Why not? :)) I notice > that > > there are a few "documentation generators". Should I try to write an > > extension of one of these? Haddock, for instance? Are there any > Haddock > > developers hanging out on this list, to encourage or dissuade me? :) > (And > > where is the Haddock doc for Haddock?) > > > > In any case, thanks in advance for any comments & advice. > > I'm not sure how doctest works, or how it would work in a Haskell > setting, could you elaborate? > > One idea that does strike me is that it would be super useful to have > the ability in ghci to extract the haddocks associated with a function. > > > :doc map > > would result in: > > -- | 'map' @f xs@ is the list obtained by applying @f@ to each element > -- of @xs@, i.e., > -- > -- > map f [x1, x2, ..., xn] == [f x1, f x2, .. > -- > map f [x1, x2, ...] == [f x1, f x2, ...] > > marked up in ascii. > > I'm not sure if that's related to doctest, but it sure would be useful! > To be honest, I think this is what we should see when we type ":info map". Preferably we'd get a proper GUI version of GHCi which prints it out into a HTML box or something with proper hyperlinks and formatting. -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080322/cee14b21/attachment.htm From rvollmert-lists at gmx.net Sat Mar 22 10:29:28 2008 From: rvollmert-lists at gmx.net (Robert Vollmert) Date: Sat Mar 22 10:26:01 2008 Subject: [Haskell-cafe] HXT and types in Control.Arrow.ArrowTree Message-ID: Hello, I'm having some trouble with HXT, the types of some functions in particular. This may well be caused by a lack of understanding for arrow programming -- I'd appreciate any hints. In short, I'm constantly running into what appear to be artificial type restrictions in Control.Arrow.ArrowTree. For example, the signature of "deep" is deep :: (Tree t, ArrowTree a) => a (t b) (t b) -> a (t b) (t b) instead of the more general deep :: (Tree t, ArrowTree a) => a (t b) c -> a (t b) c Say I have an arrow getLink :: (ArrowXml a) => a XmlTree Link that converts an HTML link (text) into some appropriate data type (code below). To collect all links in a document, I'd like to use deep getLink instead of deep (hasName "a") >>> getLink Is this the wrong approach to converting XML into Haskell data types? Cheers Robert module Links where import Text.XML.HXT.Arrow data Link = Link { url, text :: String } deriving Show getLink :: (ArrowXml a) => a XmlTree Link getLink = isElem >>> hasName "a" >>> (getAttrValue0 "href" &&& getAllText) >>> arr (uncurry Link) getAllText :: (ArrowXml a) => a XmlTree String getAllText = listA (deep isText >>> getText) >>> arr concat From dominic.steinitz at blueyonder.co.uk Sat Mar 22 11:00:44 2008 From: dominic.steinitz at blueyonder.co.uk (Dominic Steinitz) Date: Sat Mar 22 10:58:22 2008 Subject: [Haskell-cafe] Opening Windows .lnk Files Message-ID: <47E51F1C.7090808@blueyonder.co.uk> Does anyone know how to do this? If I open a file on Windows e.g. "asn_application.h.lnk" then I get the link data rather than the data in the linked file. Thanks, Dominic. From shaun at cuttshome.net Sat Mar 22 11:19:30 2008 From: shaun at cuttshome.net (Shaun Cutts) Date: Sat Mar 22 11:12:51 2008 Subject: [Haskell-cafe] "doctest" for haskell -- a good project? In-Reply-To: <1413441C-C2FE-4451-837E-19908C607843@googlemail.com> References: <04bd01c88be4$d998c010$7000a8c0@INTERLINK> <20080322083944.GA30413@scytale.galois.com> <404396ef0803220517w35ac8e81u41026c85bd9ebe1d@mail.gmail.com> <1413441C-C2FE-4451-837E-19908C607843@googlemail.com> Message-ID: <052801c88c30$211e93b0$7000a8c0@INTERLINK> Thanks for the quick responses. To elaborate on how doctests work in python: (Background: in python functions, classes & modules are all "objects" -- having attributes as well as (for functions) the ability to run them. They all have, in particular a documentation string associated with them. To get at these doctest module just loads the module, then examines its contents, looking for doc strings of contained functions & classes... so the language itself provides introspection capabilities: a strong point of python. Maybe Haskell should also have this :).) Doctests in python are bits of code in documentation strings specially annotated. In the docstring for a function "f", we might have (with apologies for python function call syntax :)): >>> f( foo ) bar This means: run f( foo ) and check that (the string representation of ) the output is "bar". You can put any code in docstring. In effect, the doctest module turns what you have written into a little module, together with imports, etc. For continuation lines on blocks of code the convention is: >>> f( ... foo ) A blank line after a ">>>" line means that no output is expected (you defined a function, for example). If a blank line is part of the string representation of output, then it is represented, e.g.: >>> f( foo ) bar If result has lots of text, you can use >>> f( foo ) bar This is helpful, e.g. if f is a helper function that catches an exception then prints it out; you don't want to check the resulting stack-trace -- just the part at the end about what exception was caught. There are lots of other switches & options, but no need to copy all of the details. (Anyway, by the time I get to worrying about them, I'll have my own opinions. :)) --------------------------------------- So Paul Johnson writes: > You need to support QuickCheck and Hunit In fact, at least in python, doctests are even more generic... They support "anything" -- though QuickCheck tests are also allowed. Does this approach seem ok/desirable here too? A bit worrisome info from Paul: > Haddock does not contain a full Haskell parser, which makes it difficult to extend in a principled way (or maybe I'm just not a good enough programmer). > I also looked at using the Haskell parser in the libraries, but that doesn't capture comments. > Associating a comment with a particular construct is not that simple either. Hmm... this makes me think that the first thing would be for me to put in an option to capture comments in the parse tree in the parser. Then Paul and crew would hack the parser's use into Haddock. Then I'd extend Haddock to support doctests! How about that? Or actually I think its overkill. If I can hook into the processing of the comment (presumably only extended comments), I can piece together a fake "module". The "..." convention means I should know how to stitch together expressions without having to understand them. One problem is checking the "output" of an expression. If an expression has output, it would seem I should throw in a test (using QuickCheck?). Hmmm. - Shaun > -----Original Message----- > From: Thomas Schilling [mailto:nominolo@googlemail.com] > Sent: Saturday, March 22, 2008 9:54 AM > To: Neil Mitchell > Cc: Don Stewart; Shaun Cutts; haskell-cafe@haskell.org > Subject: Re: [Haskell-cafe] "doctest" for haskell -- a good project? > > > On 22 mar 2008, at 13.17, Neil Mitchell wrote: > > > Hi > > > >> One idea that does strike me is that it would be super useful to > >> have the ability in ghci to extract the haddocks > associated with a > >> function. > >> > >>> :doc map > >> > >> would result in: > >> > >> -- | 'map' @f xs@ is the list obtained by applying > @f@ to each > >> element > >> -- of @xs@, i.e., > >> -- > >> -- > map f [x1, x2, ..., xn] == [f x1, f x2, .. > >> -- > map f [x1, x2, ...] == [f x1, f x2, ...] > > > > That will be in Hoogle 4, as it does already directly > relate to what > > Hoogle has to do. > > > > As for doctest, i think that could be implemented as a > --warn flag to > > Haddock, and might be a useful thing to have. For example > "90% of the > > base library has documentation, please go add documentation to > > 'sinh'", as a warning message. > > > > > Though that would be a nice feature, too, I think you > misunderstood what a doctest is. > > A doctest is a unit test in the documentation. This way it > serves as > a usage example as well as a formal specification of the semantics. > I think we already have some way to run quickchecks inside > documentation, but I can't remember what it was that could do that. > > / Thomas > From bos at serpentine.com Sat Mar 22 11:42:47 2008 From: bos at serpentine.com (Bryan O'Sullivan) Date: Sat Mar 22 11:39:18 2008 Subject: [Haskell-cafe] An ugly zip3 problem.. In-Reply-To: <47E50166.8070302@mindspring.com> References: <47E312A8.7060700@mindspring.com> <47E32788.2030408@rbg.informatik.tu-darmstadt.de> <47E50166.8070302@mindspring.com> Message-ID: <47E528F7.8060204@serpentine.com> Michael Feathers wrote: > Would Haskell's type system allow you to pass a function of arbitrary > arity, discern its arity, use that information to construct the > appropriate structure for iteration, and then apply it? The answer is probably "yes", because almost every time I've thought that a type system related question had an answer of "no", someone has been able to point me at a paper by Oleg Kiselyov. But if you're convolving a one-dimensional vector, and it's structured as a list, a simpler approach is to use a variant of a zipper data structure. Basically, as you traverse the list, you build a new list of the elements that you've already consumed. Let's say your list looks like this: [1,2,3,4,5,6,7,8] You start off with an empty list of items you've consumed, and for each item you pull off the list you're consuming, you push it onto the list you've consumed. [] 1 [2,3,4,5,6,7,8] [1] 2 [3,4,5,6,7,8] ... [4,3,2,1] 5 [6,7,8] ... Your consumption function can then use pattern matching to pick out an appropriate number of neighbouring elements from the fronts of the list you're about to consume and the list you've just consumed. To change the number of elements you're looking at, you just modify the two patterns, not the types or data structures you're using. This technique, though cute, has several drawbacks. 1. Lists won't exactly make your performance fly. You're also constructing an entire list of already seen values when you only need a handful from near the front. This capability makes sense when you need to be able to switch the direction of iteration for some reason, but that doesn't apply here. 2. Because you can't pattern match on elements in an array, you can't pick this approach up and transplant it to a different underlying data structure. 3. I don't know how to construct a useful zipper over lists of higher order (e.g. lists of lists), so at least with my limited brain power and attention span, the approach falls apart if you want to convolve a 2D or higher vector. References: <04bd01c88be4$d998c010$7000a8c0@INTERLINK> Message-ID: <47E52EE3.3040808@cogito.org.uk> Shaun Cutts wrote: > I note that there is a unit testing framework for Haskell, but I don't > see any doctest module. Might this be a good project? I once looked at doing this, but I didn't get very far. Haddock is important here because you want to include the tests as part of the documentation. QuickCheck properties in particular closely resemble a formal specification. For a couple of examples, see my RangedSet package and Neil Mitchel's FilePath package. I manually copied the RangedSet tests into the Haddock documentation, while Neil wrote a small Haskell script to extract his tests from his documentation automatically. Unfortunately his script is tied to specific aspects of his FilePath package. Haddock does not contain a full Haskell parser, which makes it difficult to extend in a principled way (or maybe I'm just not a good enough programmer). The problem is you need to have several different new kinds of mark-up, and its not always clear what to do. You need to support QuickCheck and HUnit. Also possibly SmallCheck and some other similar unit testing cum specification frameworks. For QuickCheck you need to have type information for the tests. For instance the classic specification / test of "reverse" is: > prop_reverse xs xy = (reverse xs ++ reverse ys) == reverse (ys ++ xs) Somewhere you need to flag that "xs" and "ys" are lists of integers. In the case of my RangedSets I needed to run the tests with both Integers and Doubles. I also looked at using the Haskell parser in the libraries, but that doesn't capture comments. Associating a comment with a particular construct is not that simple either. If you can manage this then it would be great. Paul. From paul at cogito.org.uk Sat Mar 22 12:08:23 2008 From: paul at cogito.org.uk (Paul Johnson) Date: Sat Mar 22 12:04:58 2008 Subject: [Haskell-cafe] AMQP framing layer: design help requested. In-Reply-To: References: <47E3F82A.7020405@cogito.org.uk> <396556a20803211841o4438f557w6d3c41f9644db873@mail.gmail.com> Message-ID: <47E52EF7.9000209@cogito.org.uk> Dean Herington wrote: > At 6:41 PM -0700 3/21/08, Adam Langley wrote: >> >> Also >>> getter <- fmap (amqpGetTable !) getWord8 >>> getter >> >> is just >> >> > fmap (amqpGetTable !) getWord8 > > I don't think so. Aren't there two "gettings": the first to get the > "type" byte and the second to get the item? > Yes. I didn't use it because it seemed obfuscated, but in fact the point-free version is > fmap (amqpGetTable !) getWord8 >>= id And I've also got an AmqpWire class similar to Dean's AmqpValue class. But both of these miss the point (which is why I didn't clutter up my simplified explanation with them). I'm looking for an alternative to the honking big AmqpVariant and AmqpArray types. I think I want something along the lines of: > class (Binary v) => VariantClass v where > typeCode :: v -> Word8 > fromVariant :: AmqpVariant -> Maybe v > > newtype AmqpVariant = forall a . (VariantClass a) => Variant a > > newtype AmqpArray = forall a . (VariantClass a) => AmqpArray [a] But I can't see how to write "fromVariant". I'm also unsure what the "amqpGet" and "amqpPut" methods might look like. Or maybe these two types are actually the best design. They do let you pattern-match on the contents. Extracting the contents of a variant from the design above would be something like: > processVariant (Variant v) = > case typeCode v of > 0x01 -> processWord8 $ fromJust $ fromVariant v > 0x02 -> ... and so on. Compare this with: > processVariant (VariantWord8 v) = processWord8 v > processVariant (VariantWord16 v) = processWord16 v > ... and so on. What do you think? Paul. From aslatter at gmail.com Sat Mar 22 12:13:54 2008 From: aslatter at gmail.com (Antoine Latter) Date: Sat Mar 22 12:10:26 2008 Subject: [Haskell-cafe] Problem with OpenAL In-Reply-To: References: Message-ID: <694519c50803220913l4e42d4c9s5b66265a3721c6a6@mail.gmail.com> For those of you following along, you'll need: > import qualified Sound.OpenAL as AL > import Data.Maybe > import Foreign.C.Types > import Control.Monad > import Control.Concurrent > import Foreign.Storable > import Foreign.Marshal.Alloc when I run "playOpenAL 440" I get no sound, and the following is repeatedly printed on the console: waiting 0 1 waiting 0 1 waiting 0 1 waiting 0 1 What do you think should be happening? -Antoine 2008/3/21 George Giorgidze : > I tried OpenAL binding (the one which is on the Hackage), but with no luck. > > I can not hear anything from speakers and also according to generated output > on console it seems that "AL.play" never completes playback of a buffer as > buffer remains registered as "unprocessed" in OpenAL context. > Here is the piece of code. I am not getting any error messages from OpenAL > library functions. > > playOpenAL :: Int -> IO () > playOpenAL sr = do > mDevice <- AL.openDevice Nothing > when (isNothing mDevice) $ error "opening OpenAL device" > let device = fromJust mDevice > > mContext <- AL.createContext device [ > AL.Frequency (fromIntegral sr) > , AL.Refresh (fromIntegral sr) > ] > when (isNothing mContext) $ error "creating OpenAL context" > let context = fromJust mContext > AL.currentContext AL.$= (Just context) > > > let sampleNumber = 256 > bufSize = sampleNumber * (sizeOf (undefined :: CShort)) > buf2 <- mallocBytes bufSize > > -- here I am filling buf2 with noise .... > > [source] <- AL.genObjectNames 1 > [buffer] <- AL.genObjectNames 1 > > let region = AL.MemoryRegion buf2 (fromIntegral bufSize) > AL.bufferData buffer AL.$= (AL.BufferData region AL.Mono16 (fromIntegral > sr)) > > > AL.queueBuffers source [buffer] > AL.loopingMode source AL.$= AL.OneShot > > let waitForSource = do > putStrLn "waiting" > s <- AL.get (AL.buffersProcessed source) > putStrLn $ show s > s <- AL.get (AL.buffersQueued source) > putStrLn $ show s > state <- AL.get (AL.sourceState source) > case state of > AL.Playing -> do > threadDelay 1024 > waitForSource > _ -> return () > > putStrLn "Start Playing ... " > AL.play [source] > waitForSource > > > AL.currentContext AL.$= Nothing > AL.destroyContext context > b <- AL.closeDevice device > when (not b) $ error "closing device" > > > Is this library still maintained? > > Best, George > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From derek.a.elkins at gmail.com Sat Mar 22 12:50:49 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Sat Mar 22 12:47:24 2008 Subject: [Haskell-cafe] AMQP framing layer: design help requested. In-Reply-To: <47E52EF7.9000209@cogito.org.uk> References: <47E3F82A.7020405@cogito.org.uk> <396556a20803211841o4438f557w6d3c41f9644db873@mail.gmail.com> <47E52EF7.9000209@cogito.org.uk> Message-ID: <1206204649.5533.23.camel@derek-laptop> On Sat, 2008-03-22 at 16:08 +0000, Paul Johnson wrote: > Dean Herington wrote: > > At 6:41 PM -0700 3/21/08, Adam Langley wrote: > >> > >> Also > >>> getter <- fmap (amqpGetTable !) getWord8 > >>> getter > >> > >> is just > >> > >> > fmap (amqpGetTable !) getWord8 > > > > I don't think so. Aren't there two "gettings": the first to get the > > "type" byte and the second to get the item? > > > Yes. I didn't use it because it seemed obfuscated, but in fact the > point-free version is > > > fmap (amqpGetTable !) getWord8 >>= id > Nah, the point-free version wouldn't be this. First, join = x >>= id so fmap (ampqGetTable !) getWord8 >>= id === join (fmap (ampqGetTable !) getWord8) Next, m >>= f = join (fmap f m) so join (fmap (ampqGetTable !) getWord8) === getWord8 >>= (ampqGetTable !) This would be the point-free version So the original code was a round-about way of saying: do word <- getWord8; ampqGetTable ! word From ndmitchell at gmail.com Sat Mar 22 13:11:06 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Sat Mar 22 13:07:43 2008 Subject: [Haskell-cafe] Opening Windows .lnk Files In-Reply-To: <47E51F1C.7090808@blueyonder.co.uk> References: <47E51F1C.7090808@blueyonder.co.uk> Message-ID: <404396ef0803221011j35c44a90i1924ed6fce92774f@mail.gmail.com> Hi Drop into the command line, rename the file from foo.lnk to foo.txt, using "ren foo.lnk foo.txt", then open "foo.txt". It's a chunk of binary goop, so will likely not be much use. There is a COM class for editing shortcut files (IShellLink), which I've used before from C code. See http://darcs.haskell.org/hugs98/src/winhugs/installer/ShellCode.cpp, in particular the CreateShortcut function. Thanks Neil From ndmitchell at gmail.com Sat Mar 22 13:16:55 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Sat Mar 22 13:13:26 2008 Subject: [Haskell-cafe] "doctest" for haskell -- a good project? In-Reply-To: <47E52EE3.3040808@cogito.org.uk> References: <04bd01c88be4$d998c010$7000a8c0@INTERLINK> <47E52EE3.3040808@cogito.org.uk> Message-ID: <404396ef0803221016u4919a2eaud9b916a4f32fa82b@mail.gmail.com> Hi > I once looked at doing this, but I didn't get very far. Me too, and I managed to get some way: > resemble a formal specification. For a couple of examples, see my > RangedSet package and Neil Mitchel's FilePath package. I manually > copied the RangedSet tests into the Haddock documentation, while Neil > wrote a small Haskell script to extract his tests from his documentation > automatically. Unfortunately his script is tied to specific aspects of > his FilePath package. Yes, the problem was that FilePath wants to execute half the tests twice with different modules, and half with just one namespace. As far as tests go, this is a very wacky requirement. I wanted to generalise it into a tool, but couldn't find a sensible generalisation that still worked with filepath - and hence didn't bother. I think the solution is to not permit the quirkyness of filepath, and write a general solution for everything else. As someone who has frequently considered writing this, even going as far as brainstorming on a whiteboard, I would be an enthusiastic user of this. I think the lack of this tool in Haskell is a big hole which someone needs to fill. I particularly like the facility in FilePath: -- > x == reverse (reverse x) -- > reverse "neil" = "lien" i.e. I can write both quickcheck properties (quantified over all single letter variables), or I can write an instance (like doctest in Python) Thanks, and good luck! Neil From dominic.steinitz at blueyonder.co.uk Sat Mar 22 13:32:38 2008 From: dominic.steinitz at blueyonder.co.uk (Dominic Steinitz) Date: Sat Mar 22 13:30:21 2008 Subject: [Haskell-cafe] Opening Windows .lnk Files In-Reply-To: <404396ef0803221011j35c44a90i1924ed6fce92774f@mail.gmail.com> References: <47E51F1C.7090808@blueyonder.co.uk> <404396ef0803221011j35c44a90i1924ed6fce92774f@mail.gmail.com> Message-ID: <47E542B6.6030000@blueyonder.co.uk> Neil Mitchell wrote: > Hi > > Drop into the command line, rename the file from foo.lnk to foo.txt, > using "ren foo.lnk foo.txt", then open "foo.txt". It's a chunk of > binary goop, so will likely not be much use. > > There is a COM class for editing shortcut files (IShellLink), which > I've used before from C code. See > http://darcs.haskell.org/hugs98/src/winhugs/installer/ShellCode.cpp, > in particular the CreateShortcut function. > > Thanks > > Neil > > > Neil, Thanks but following a discussion on #haskell, it's all beginning to sound a bit hard. Somehow I thought it would be easy. I know where the real files are so I'll just set a directory as a parameter, strip off the .lnk from the name and use that + the directory to manipulate them. Dominic. From shaun at cuttshome.net Sat Mar 22 14:02:16 2008 From: shaun at cuttshome.net (Shaun Cutts) Date: Sat Mar 22 13:55:36 2008 Subject: [Haskell-cafe] "doctest" for haskell -- a good project? In-Reply-To: <404396ef0803221016u4919a2eaud9b916a4f32fa82b@mail.gmail.com> References: <04bd01c88be4$d998c010$7000a8c0@INTERLINK> <47E52EE3.3040808@cogito.org.uk> <404396ef0803221016u4919a2eaud9b916a4f32fa82b@mail.gmail.com> Message-ID: <05d301c88c46$de0d92d0$7000a8c0@INTERLINK> > > resemble a formal specification. For a couple of > examples, see my > > RangedSet package and Neil Mitchel's FilePath package. I manually > > copied the RangedSet tests into the Haddock documentation, > while Neil > > wrote a small Haskell script to extract his tests from his > > documentation automatically. Unfortunately his script is tied to > > specific aspects of his FilePath package. > > Yes, the problem was that FilePath wants to execute half the > tests twice with different modules, and half with just one > namespace. As far as tests go, this is a very wacky > requirement. I wanted to generalise it into a tool, but > couldn't find a sensible generalisation that still worked > with filepath - and hence didn't bother. I think the solution > is to not permit the quirkyness of filepath, and write a > general solution for everything else. Niel -- I understand your script is part of FilePath... might it be a good starting point for abstraction? Can you point me to it? > As someone who has frequently considered writing this, even > going as far as brainstorming on a whiteboard, I would be an > enthusiastic user of this. I think the lack of this tool in > Haskell is a big hole which someone needs to fill. I > particularly like the facility in FilePath: > > -- > x == reverse (reverse x) > -- > reverse "neil" = "lien" > > i.e. I can write both quickcheck properties (quantified over > all single letter variables), or I can write an instance > (like doctest in > Python) > > Thanks, and good luck! > > Neil > Thank you for the support... This might take me a while, I must warn, as this is an "after work" project, and I am a consultant, so "after work" often doesn't come :). But its certainly motivating to work on something right away that could be useful (to myself as well). - Shaun From arnarbi at gmail.com Sat Mar 22 14:58:05 2008 From: arnarbi at gmail.com (Arnar Birgisson) Date: Sat Mar 22 14:54:36 2008 Subject: [Haskell-cafe] "doctest" for haskell -- a good project? In-Reply-To: <20080322083944.GA30413@scytale.galois.com> References: <04bd01c88be4$d998c010$7000a8c0@INTERLINK> <20080322083944.GA30413@scytale.galois.com> Message-ID: <28012bc60803221158p3b3cb2bdq3cff24bfb78f147@mail.gmail.com> Hey Don, On Sat, Mar 22, 2008 at 8:39 AM, Don Stewart wrote: > I'm not sure how doctest works, or how it would work in a Haskell > setting, could you elaborate? In a nutshell, Python doctest has the programmer put an example "interactive session" in a functions docstring. A doctest module then extracts those, tries running the function on the inputs and sees if it matches the output. Best shown by an example: def adder(a,b): """Returns the sum of the two arguments. >>> adder(10,10) 20 >>> adder("a","b") 'ab' >>> adder(10,"100") Traceback (most recent call last): File "test.py", line 6, in adder return a+b TypeError: unsupported operand type(s) for +: 'int' and 'str' """ return a+b if __name__ == "__main__": import doctest doctest.testmod() # Test this module Running this script with $ python test.py -v gives the following output Trying: adder(10,10) Expecting: 20 ok Trying: adder("a","b") Expecting: 'ab' ok Trying: adder(10,"100") Expecting: Traceback (most recent call last): File "test.py", line 6, in adder return a+b TypeError: unsupported operand type(s) for +: 'int' and 'str' ok 1 items had no tests: __main__ 1 items passed all tests: 3 tests in __main__.adder 3 tests in 2 items. 3 passed and 0 failed. Test passed. I.e it extracted the test cases from the sample interactive session and compared the real results. > One idea that does strike me is that it would be super useful to have > the ability in ghci to extract the haddocks associated with a function. > > > :doc map > > would result in: > > -- | 'map' @f xs@ is the list obtained by applying @f@ to each element > -- of @xs@, i.e., > -- > -- > map f [x1, x2, ..., xn] == [f x1, f x2, .. > -- > map f [x1, x2, ...] == [f x1, f x2, ...] > > marked up in ascii. > > I'm not sure if that's related to doctest, but it sure would be useful! Python does exactly that and it is very very useful. I'd love to see that in GHCi. Arnar From dons at galois.com Sat Mar 22 15:22:42 2008 From: dons at galois.com (Don Stewart) Date: Sat Mar 22 15:19:21 2008 Subject: [Haskell-cafe] "doctest" for haskell -- a good project? In-Reply-To: <28012bc60803221158p3b3cb2bdq3cff24bfb78f147@mail.gmail.com> References: <04bd01c88be4$d998c010$7000a8c0@INTERLINK> <20080322083944.GA30413@scytale.galois.com> <28012bc60803221158p3b3cb2bdq3cff24bfb78f147@mail.gmail.com> Message-ID: <20080322192242.GA32219@scytale.galois.com> arnarbi: > Hey Don, > > On Sat, Mar 22, 2008 at 8:39 AM, Don Stewart wrote: > > I'm not sure how doctest works, or how it would work in a Haskell > > setting, could you elaborate? > > In a nutshell, Python doctest has the programmer put an example "interactive > session" in a functions docstring. A doctest module then extracts those, tries > running the function on the inputs and sees if it matches the output. Ah yes. This is a great idea, and would be very useful. Haskell code is often documented with QuickCheck properties the code satisfies. Ensuring these are up to date is something that would be good to automate. It should be easier than in Python too, as fragments typically are pure, and don't require state to be initialised. -- Don From ndmitchell at gmail.com Sat Mar 22 15:27:11 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Sat Mar 22 15:23:43 2008 Subject: [Haskell-cafe] "doctest" for haskell -- a good project? In-Reply-To: <05d301c88c46$de0d92d0$7000a8c0@INTERLINK> References: <04bd01c88be4$d998c010$7000a8c0@INTERLINK> <47E52EE3.3040808@cogito.org.uk> <404396ef0803221016u4919a2eaud9b916a4f32fa82b@mail.gmail.com> <05d301c88c46$de0d92d0$7000a8c0@INTERLINK> Message-ID: <404396ef0803221227i2feda5afj66273ec7e8e0526a@mail.gmail.com> Hi > Niel -- I understand your script is part of FilePath... might it be a good > starting point for abstraction? Can you point me to it? You are certainly welcome to start from it, if it is of any use to you: darcs get http://darcs.haskell.org/packages/filepath/ Then look in the test directory. > Thank you for the support... This might take me a while, I must warn, as > this is an "after work" project, and I am a consultant, so "after work" > often doesn't come :). But its certainly motivating to work on something > right away that could be useful (to myself as well). I will be greatful for anything that comes out - and if you don't get anywhere with the code but do come up with a design, you can always write a blog post on it so if it ever gets continued people can start from where you left off. Thanks Neil From bf3 at telenet.be Sat Mar 22 15:48:20 2008 From: bf3 at telenet.be (Peter Verswyvelen) Date: Sat Mar 22 15:44:53 2008 Subject: [Haskell-cafe] ANNOUNCE: wxHaskell 0.10.3 rc1 In-Reply-To: <47E2C67F.3050301@btinternet.com> References: <1205315421.15905.1241945927@webmail.messagingengine.com> <638ABD0A29C8884A91BC5FB5C349B1C32AB9A145A6@EA-EXMSG-C334.europe.corp.microsoft.com> <47E2C67F.3050301@btinternet.com> Message-ID: <000001c88c55$ae508340$0af189c0$@be> Amazing, I downloaded and installed this release for Windows and it works out of the box, just as a lazy Windows user expects! Woohoo! Great work. > -----Original Message----- > From: haskell-cafe-bounces@haskell.org [mailto:haskell-cafe- > bounces@haskell.org] On Behalf Of Andrew Coppin > Sent: donderdag 20 maart 2008 21:18 > To: haskell-cafe@haskell.org > Subject: Re: [Haskell-cafe] ANNOUNCE: wxHaskell 0.10.3 rc1 > > Simon Peyton-Jones wrote: > > Congratulations! wxHaskell is v cool but was suffering from lack of > loving care. I'm delighted that it not only has a new team, but that > you've pushed through to delivering a release. Brilliant. > > > > Yeah, I thought wxHaskell was long since dead. Then I come back after a > couple of weeks and find there's a new RC. I've never used wx before, > but hopefully this might eventually enable me to build Windows apps > that > have a native look and feel, and don't require the GTK runtime [which > is > very uncommon on that platform]. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From shaun at cuttshome.net Sat Mar 22 17:16:40 2008 From: shaun at cuttshome.net (Shaun Cutts) Date: Sat Mar 22 17:10:00 2008 Subject: [Haskell-cafe] "doctest" for haskell -- a good project? In-Reply-To: <28012bc60803221158p3b3cb2bdq3cff24bfb78f147@mail.gmail.com> References: <04bd01c88be4$d998c010$7000a8c0@INTERLINK> <20080322083944.GA30413@scytale.galois.com> <28012bc60803221158p3b3cb2bdq3cff24bfb78f147@mail.gmail.com> Message-ID: <065001c88c62$0643a800$7000a8c0@INTERLINK> > In a nutshell, Python doctest has the programmer put an > example "interactive session" in a functions docstring. A > doctest module then extracts those, tries running the > function on the inputs and sees if it matches the output. > Best shown by > an example: > By the way, python does this by creating a temporary module from the docstring, then evaluating this. Is there a dynamic way in Haskell to evaulate a module? Or will I have to be content starting some sort of "subsession"... Which will make the doctest module less robust & portable. One idea would be just to produce a set of modules in the "core" doctest module. Then there would be a set of lightweight scripts for automating "produce & run" in various environments. But if there is a good "internal" way that I don't know about, I'm all ears. - Shaun From bjorn at bringert.net Sat Mar 22 18:57:04 2008 From: bjorn at bringert.net (Bjorn Bringert) Date: Sat Mar 22 18:53:35 2008 Subject: [Haskell-cafe] Using HaskellDb to connect to PostgresSql In-Reply-To: References: Message-ID: On Wed, Mar 19, 2008 at 8:32 PM, Justin Bailey wrote: > On Wed, Mar 19, 2008 at 10:55 AM, Marc Mertens wrote: > > Hello, > > > > I'm trying to learn to use HaskellDb. I have managed to finally compile and > > install it on my linux box (I have ghc 6.8.2). But when I try to create a > > database description (as described in > > http://haskelldb.sourceforge.net/getting-started.html) (using DBDirect-dynamic > > instead of DBDirect) I'm stuck. I have tried different names for the driver but > > > > I don't have much information about using DBDynamic, but I am able to > connect to PostgreSQL easily. I have done it on Windows using GHC > 6.8.2. I am using hdbc-postgresql, since hsql would not compile on > Windows for me. Here are the import statements and the login function > I have for a simple program that connects to postgresql and writes out > table info: > > import Database.HaskellDB.DBSpec.DatabaseToDBSpec > import Database.HaskellDB.DBSpec.DBSpecToDBDirect > import Database.HaskellDB.Database > import Database.HaskellDB.HDBC.PostgreSQL > import Database.HaskellDB.PrimQuery > import Database.HaskellDB.FieldType > import Database.HaskellDB.DBSpec > > login :: MonadIO m => String -> Int -> String -> String -> String -> > (Database -> m a) -> m a > login server port user password dbname = postgresqlConnect [("host", server), > ("port", show port), > ("user", user), > ("password", password), > ("dbname", dbname)] > > The versions of all packages I'm using are: > > HDBC-1.1.4 > HDBC-postgresql-1.1.4.0 > haskelldb-hdbc-0.10 > haskelldb-hdbc-postgresql-0.10 > > Note you might have to modify the haskelldb cabal files to get them to > use later versions of HDBC. > > As for recent documentation, unfortunately the darcs repository and > the code is the best place to go. The haddock documentation doesn't > have everything. > > Finally, I'd suggest joining the haskell-db users mailing list for > specific questions. You can find info about that and the darcs > repository on the homepage at http://haskelldb.sourceforge.net. > > Justin Just to add to what Justin said, try using DBDirect-hdbc-postgresql instead of DBDirect-dynamic. The "dynamic" driver adds an extra layer of problems, and I'm not sure that it (or hs-plugins?) has been updated to work with GHC 6.8.2. Because of a typo in a .cabal file, there was no DBDirect-hdbc-postgresql until a few minutes ago, but if you pull down the current darcs version and reinstall haskelldb-hdbc-postgresql you should get it. The HaskellDB documentation really is in a sorry state. Does anybody feel like adding a wiki page with a basic getting-started HaskellDB tutorial? It would be very appreciated. This page seems to contain mostly meta-information: http://www.haskell.org/haskellwiki/Applications_and_libraries/Database_interfaces/HaskellDB /Bj?rn From s.clover at gmail.com Sun Mar 23 02:21:38 2008 From: s.clover at gmail.com (Sterling Clover) Date: Sun Mar 23 02:18:15 2008 Subject: [Haskell-cafe] ANN (2 Libs) -- hvac 0.1b, a lightweight web framework and HStringTemplate 0.3 Message-ID: 1) hvac 0.1b: transactional, declarative framework for lightweight web applications. 2) HStringTemplate 0.3 1) hvac 0.1b hvac (short for http view and controller) has been my project for the last little while, and is finally in a fairly usable state, so I'm opening up the repo (darcs get http://community.haskell.org/~sclv/ hvac/) for folks to play with and to get some feedback. While not quite yet ready for hackage, the package as provided should be fully cabal installable. Documentation is available at http:// community.haskell.org/~sclv/hvac/html_docs/hvac/ The aim of hvac is to provide an environment that makes the creation of lightweight fastcgi based web applications as simple as possible, with an emphasis on concise, declarative style code, correct concurrent transactional logic, and transparency in adding caching combinators. There are two included example programs, naturally neither of which is feature complete. They share a common login module of about 50 lines of code, excluding imports, templates, and database schema. The first program is a classic, greenspun-style message board with basic login functionality. It totals roughly 40 lines and tends to use just under 4mb of resident memory on my system. The second is a wiki based on Pandoc and the PandocWiki code. The code totals roughly 30 lines (rendering borrowed from PandocWiki aside) and uses about 5mb of memory. hvac processes all requests in the STM monad, with some bells attached to properly interleave STM with session, database and filesystem operations such that they all conceptually occur together in a single transaction per request. Currently it is only fully tested with sqlite, but it should operate, modulo a few tweaks, with any database accessible via HDBC. hvac is particularly designed to use the HStringTemplate library as an output layer, in a simple declarative fashion. As the StringTemplate grammar is explicitly sub-turing, this ensures a clean separation of program logic from presentation, while providing a nonetheless fairly powerful language to express typical display tasks. The included cache combinators, still experimental, should allow a simple and fine-grained control over the level of caching of various disk-bound operations. Phantom types are used to ensure that no functions that modify state may be cached. To give a flavor of hvac code, the following is the complete (twenty lines!) source of the wiki controller (due to sql statements, some lines are rather long): wikiController tmpl = h |/ "login" *> login_plug tmpl <|> (h |/ "wiki" |\\ \pageName -> h |// "POST" *> withValidation [ ("contents", return) ] (\ [contents] -> do pageId <- selectVal "id from pages where name=?" [toSql pageName] maybe (addErrors [("Login","must be logged in.")] >> continue) (\user -> case fromSql pageId of Just (_::Int) -> execStat "insert into page_hist (pageId,contents,author) values(?,?,?)" [pageId, toSql contents, toSql . userName $ user] Nothing -> do execStat "insert into pages (name,locked) values(?,?)" [toSql pageName, toSql (0::Int)] pid <- selectVal "max(id) from pages" [] execStat "insert into page_hist (pageId,contents,author) values(?,?,?)" [pid, toSql contents, toSql . userName $ user]) =<< getSes continue) <|> do pageId <- selectVal "id from pages where name=?" [toSql pageName] (join $ renderf (tmpl "showPage") ("pageName", pageName) <$> "pageContents" |= selectRow "* from page_hist where pageId=? order by time desc limit 1" [pageId] )) <|> (redirect . ( ++ "/wiki/Index") =<< scriptName) Future directions for work on hvac include: Stress testing for correctness of transactional logic and benchmarks. Exploration of various efficiency tweaks. Unit tests. Further development of the cache combinator API. Improvement of the example apps and addition of a few others (a blog maybe). Expansion of the library of validator functions. Exploration of transferring hvac to the standard FastCGI bindings (currently it uses a custom modified version to work properly with STM). Improvement of the database layer, particularly with regards to common paging functions. Creation of a set of simple combinators for generating CRUD (create read update delete) pages. Creation of a minimal set of standard templates (maybe). 2) HStringTemplate 0.3.1 This release of HStringTemplate (up now at Hackage) fixes a number of bugs pointed out to me by its small but growing user base (thanks, cinema, elliottt!) ranging from the minor (a particular two-level iteration pattern wasn't working properly) to the truly irritating (poor handling of file groups). It's still unfortunately skimpy on the docs, outside of the haddocks and the main StringTemplate grammar documentation at http://www.stringtemplate.org (although the examples from hvac should also prove helpful). However, it does have a set of very nice and handy new features for development. * renderf, a function similar in spirit to printf, that takes an arbitrary number of heterogeneous (String, value) tuples as arguments. This should cut down considerably on long setAttribute chains. Additionally, with custom instances (not, I'll grant, trivial to write) it can be used to declaratively chain together strings of attribute retrieval functions in arbitrary monads, as in the above code example from hvac. * dumpAttribs, a function/template that prints out the tree of the entire attribute environment a template is operating in -- extremely handy for development. * nullGroup, also for use in development, a simple way to display more information about templates that can't be found. Error messages in usafeVolatileDirectoryGroup have also been significantly improved. * getStringTemplate', a version of getStringTemplate guaranteed not to be inlined. While the optimizer will still sometimes rearrange code such that a volatile group is not updated properly, this at least helps remedy the situation (I think). * Some minor changes: For grammar reasons, dots have been removed from template names -- however, underscores and slashes are now available. Additionally, there's a much improved logic for which aspects of a local environment are overridden and preserved when a template is called from another. For both of these libraries, patches, comments, bug reports, requests, and of course contributions more than welcome! Regards, Sterl. From john at repetae.net Sun Mar 23 04:20:45 2008 From: john at repetae.net (John Meacham) Date: Sun Mar 23 04:17:14 2008 Subject: [Haskell-cafe] compile error with FFI code In-Reply-To: <5ae4f2ba0803212121w17fe482ek105c13cf6999e603@mail.gmail.com> References: <5ae4f2ba0803212121w17fe482ek105c13cf6999e603@mail.gmail.com> Message-ID: <20080323082044.GA10545@sliver.repetae.net> On Fri, Mar 21, 2008 at 11:21:26PM -0500, Galchin Vasili wrote: > In my blah.hsc, I have "allocbytes (#const (struct bozo)) .. where you probably meant "allocBytes (#const sizeof(struct bozo))" John -- John Meacham - ?repetae.net?john? From marco-oweber at gmx.de Sun Mar 23 07:42:56 2008 From: marco-oweber at gmx.de (Marc Weber) Date: Sun Mar 23 07:39:23 2008 Subject: [Haskell-cafe] ANNOUNCE: wxHaskell 0.10.3 rc1 In-Reply-To: <000001c88c55$ae508340$0af189c0$@be> References: <1205315421.15905.1241945927@webmail.messagingengine.com> <638ABD0A29C8884A91BC5FB5C349B1C32AB9A145A6@EA-EXMSG-C334.europe.corp.microsoft.com> <47E2C67F.3050301@btinternet.com> <000001c88c55$ae508340$0af189c0$@be> Message-ID: <20080323114256.GA8760@gmx.de> On Sat, Mar 22, 2008 at 08:48:20PM +0100, Peter Verswyvelen wrote: > Amazing, I downloaded and installed this release for Windows and it works > out of the box, just as a lazy Windows user expects! Woohoo! Great work. I've had this success adding wxhaskell to nixos using the new distribution as well! Thanks Marc Weber From knifewolf at gmail.com Sun Mar 23 07:48:34 2008 From: knifewolf at gmail.com (Deng Chao) Date: Sun Mar 23 07:46:02 2008 Subject: [Haskell-cafe] Re: Haskell-Cafe Digest, Vol 55, Issue 30 In-Reply-To: <20080322175549.12F7532420B@www.haskell.org> References: <20080322175549.12F7532420B@www.haskell.org> Message-ID: <1206272914.7643.2.camel@knifewolfUBUNTU> Hi Sebastian Sylvan, Thank you very much! I thick the last column return a string because of the Haskell "Show" function, for when I made test, I got such an error message: Show ([SqlValue] -> IO [[SqlValue]]). Any way, thank you very much! Deng Chao ? 2008-03-22?? 13:55 -0400?haskell-cafe-request@haskell.org??? > Send Haskell-Cafe mailing list submissions to > haskell-cafe@haskell.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.haskell.org/mailman/listinfo/haskell-cafe > or, via email, send a message with subject or body 'help' to > haskell-cafe-request@haskell.org > > You can reach the person managing the list at > haskell-cafe-owner@haskell.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Haskell-Cafe digest..." > > > Today's Topics: > > 1. compile error with FFI code (Galchin Vasili) > 2. "doctest" for haskell -- a good project? (Shaun Cutts) > 3. Re: [GSoC] Plugins for GHC (Bulat Ziganshin) > 4. Re: "doctest" for haskell -- a good project? (Roman Cheplyaka) > 5. Re: "doctest" for haskell -- a good project? (Don Stewart) > 6. Re: [GSoC] Plugins for GHC (Neil Mitchell) > 7. Re: "doctest" for haskell -- a good project? (Neil Mitchell) > 8. Re: An ugly zip3 problem.. (Michael Feathers) > 9. Re: An ugly zip3 problem.. (Michael Feathers) > 10. How to program with sqlite? (Deng Chao) > 11. Re: "doctest" for haskell -- a good project? (Thomas Schilling) > 12. Re: How to program with sqlite? (Sebastian Sylvan) > 13. Re: "doctest" for haskell -- a good project? (Sebastian Sylvan) > 14. HXT and types in Control.Arrow.ArrowTree (Robert Vollmert) > 15. Opening Windows .lnk Files (Dominic Steinitz) > 16. RE: "doctest" for haskell -- a good project? (Shaun Cutts) > 17. Re: An ugly zip3 problem.. (Bryan O'Sullivan) > 18. Re: "doctest" for haskell -- a good project? (Paul Johnson) > 19. Re: AMQP framing layer: design help requested. (Paul Johnson) > 20. Re: Problem with OpenAL (Antoine Latter) > 21. Re: AMQP framing layer: design help requested. (Derek Elkins) > 22. Re: Opening Windows .lnk Files (Neil Mitchell) > 23. Re: "doctest" for haskell -- a good project? (Neil Mitchell) > 24. Re: Opening Windows .lnk Files (Dominic Steinitz) > 25. RE: "doctest" for haskell -- a good project? (Shaun Cutts) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 21 Mar 2008 23:21:26 -0500 > From: "Galchin Vasili" > Subject: [Haskell-cafe] compile error with FFI code > To: Haskell-cafe > Cc: Galchin Vasili > Message-ID: > <5ae4f2ba0803212121w17fe482ek105c13cf6999e603@mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Hello, > > In my blah.hsc, I have "allocbytes (#const (struct bozo)) .. where > > struct bozo is a bunch of "long int" ,,, In the "runhaskell Setup.hs build" > step I get a nasty error message about an "incomplete type". I have look at > many times but this error doesn't make sense to me. ?? > > Kind regards, Vasili > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080321/273d5ca0/attachment-0001.htm > > ------------------------------ > > Message: 2 > Date: Sat, 22 Mar 2008 02:20:38 -0400 > From: "Shaun Cutts" > Subject: [Haskell-cafe] "doctest" for haskell -- a good project? > To: > Message-ID: <04bd01c88be4$d998c010$7000a8c0@INTERLINK> > Content-Type: text/plain; charset="iso-8859-1" > > Hello, > > I am an experienced programmer, currently learning Haskell. Currently I > write many things in python. I use both the "doctest" and "unittest" modules > extensively. As I write code, I simultaneously write doctest code in the doc > strings to explain/set out the "typical narrative" of how the code is used. > Then finishing off a module I write unittests for boundary conditions, more > complex test cases, and generally code that would be annoying to write & > read in doctests. > > I note that there is a unit testing framework for Haskell, but I don't see > any doctest module. Might this be a good project? > > If so, suggestions as to resources would be greatly appreciated. I believe I > can't just "introspect" Haskell modules to get at documentation/comments, > like I can in python? (Why not? :)) I notice that there are a few > "documentation generators". Should I try to write an extension of one of > these? Haddock, for instance? Are there any Haddock developers hanging out > on this list, to encourage or dissuade me? :) (And where is the Haddock doc > for Haddock?) > > In any case, thanks in advance for any comments & advice. > > - Shaun Cutts > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080322/185fb821/attachment-0001.htm > > ------------------------------ > > Message: 3 > Date: Sat, 22 Mar 2008 10:08:50 +0300 > From: Bulat Ziganshin > Subject: Re: [Haskell-cafe] [GSoC] Plugins for GHC > To: "Max Bolingbroke" > Cc: haskell-cafe@haskell.org > Message-ID: <19110011979.20080322100850@gmail.com> > Content-Type: text/plain; charset=us-ascii > > Hello Max, > > Saturday, March 22, 2008, 1:23:37 AM, you wrote: > > > around with modifying GHC itself. Potential use cases are: > > * And whatever clever ideas the community comes up with! > > i'm interested in syntax macros feature like metalua > > > -- > Best regards, > Bulat mailto:Bulat.Ziganshin@gmail.com > > > > ------------------------------ > > Message: 4 > Date: Sat, 22 Mar 2008 10:29:33 +0200 > From: Roman Cheplyaka > Subject: Re: [Haskell-cafe] "doctest" for haskell -- a good project? > To: haskell-cafe@haskell.org > Message-ID: <20080322082932.GA3361@home.ro-che.info> > Content-Type: text/plain; charset="us-ascii" > > * Shaun Cutts [2008-03-22 02:20:38-0400] > > Hello, > > > > I am an experienced programmer, currently learning Haskell. Currently I > > write many things in python. I use both the "doctest" and "unittest" modules > > extensively. As I write code, I simultaneously write doctest code in the doc > > strings to explain/set out the "typical narrative" of how the code is used. > > Then finishing off a module I write unittests for boundary conditions, more > > complex test cases, and generally code that would be annoying to write & > > read in doctests. > > > > I note that there is a unit testing framework for Haskell, but I don't see > > any doctest module. Might this be a good project? > > > > If so, suggestions as to resources would be greatly appreciated. I believe I > > can't just "introspect" Haskell modules to get at documentation/comments, > > like I can in python? (Why not? :)) I notice that there are a few > > "documentation generators". Should I try to write an extension of one of > > these? Haddock, for instance? Are there any Haddock developers hanging out > > on this list, to encourage or dissuade me? :) (And where is the Haddock doc > > for Haddock?) > > > > In any case, thanks in advance for any comments & advice. > > > > - Shaun Cutts > > > Did you try haddock? > > -- > Roman I. Cheplyaka :: http://ro-che.info/ > ...being in love is totally punk rock... > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: application/pgp-signature > Size: 307 bytes > Desc: Digital signature > Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080322/0a310583/attachment-0001.bin > > ------------------------------ > > Message: 5 > Date: Sat, 22 Mar 2008 01:39:44 -0700 > From: Don Stewart > Subject: Re: [Haskell-cafe] "doctest" for haskell -- a good project? > To: Shaun Cutts > Cc: haskell-cafe@haskell.org > Message-ID: <20080322083944.GA30413@scytale.galois.com> > Content-Type: text/plain; charset=us-ascii > > shaun: > > Hello, > > > > I am an experienced programmer, currently learning Haskell. Currently I > > write many things in python. I use both the "doctest" and "unittest" > > modules extensively. As I write code, I simultaneously write doctest code > > in the doc strings to explain/set out the "typical narrative" of how the > > code is used. Then finishing off a module I write unittests for boundary > > conditions, more complex test cases, and generally code that would be > > annoying to write & read in doctests. > > > > I note that there is a unit testing framework for Haskell, but I don't see > > There's a couple, QuickCheck is the best, it generalises unit testing to > property testing with random, or not so random, data. > > > any doctest module. Might this be a good project? > > If so, suggestions as to resources would be greatly appreciated. I believe > > I can't just "introspect" Haskell modules to get at > > documentation/comments, like I can in python? (Why not? :)) I notice that > > there are a few "documentation generators". Should I try to write an > > extension of one of these? Haddock, for instance? Are there any Haddock > > developers hanging out on this list, to encourage or dissuade me? :) (And > > where is the Haddock doc for Haddock?) > > > > In any case, thanks in advance for any comments & advice. > > I'm not sure how doctest works, or how it would work in a Haskell > setting, could you elaborate? > > One idea that does strike me is that it would be super useful to have > the ability in ghci to extract the haddocks associated with a function. > > > :doc map > > would result in: > > -- | 'map' @f xs@ is the list obtained by applying @f@ to each element > -- of @xs@, i.e., > -- > -- > map f [x1, x2, ..., xn] == [f x1, f x2, .. > -- > map f [x1, x2, ...] == [f x1, f x2, ...] > > marked up in ascii. > > I'm not sure if that's related to doctest, but it sure would be useful! > > -- Don > > > ------------------------------ > > Message: 6 > Date: Sat, 22 Mar 2008 12:15:26 +0000 > From: "Neil Mitchell" > Subject: Re: [Haskell-cafe] [GSoC] Plugins for GHC > To: "Max Bolingbroke" > Cc: haskell-cafe@haskell.org > Message-ID: > <404396ef0803220515n52dc7cfbg5b565ba2e481c27b@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Hi Max, > > This sounds fantastic! > > My only question would be how this relates to the external Core work > that Tim has been doing. If we have this, can external core become a > plugin? If we have this, do we no longer need external Core? It seems > to say that we don't want external Core as the interface, as it won't > be stable in any way - does that mean we don't want external Core at > all? > > Thanks > > Neil > > > We certainly need a mechanism for doing > > On 3/21/08, Max Bolingbroke wrote: > > Hi, > > > > I'm interested in working on a plugins system for the Glasgow Haskell > > Compiler. The idea here is to allow third parties to add more > > capabilities to the compiler in a way that doesn't involve messing > > around with modifying GHC itself. Potential use cases are: > > * Allow Haskell code to be selectively run on GPUs > > * Idiosyncratic application-specific optimization passes > > * And whatever clever ideas the community comes up with! > > > > This project has previously been proposed as an Microsoft Research > > internship project > > (http://hackage.haskell.org/trac/ghc/wiki/Internships).I have a > > preliminary wiki page with details at > > http://hackage.haskell.org/trac/ghc/wiki/Plugins > > > > I'd particularly like to get feedback from the list on: > > * Other design goals people would like to see > > * Improvements to the proposed (very half-baked!) user interface > > * Other hooks people think they might like to have into the compiler > > * Interested mentors. Simon PJ has indicated he would be interested in > > mentoring this, but there might be other projects that need him more? > > > > This project would satisfy a dependency that Manuel mentioned in > > http://groups.google.com/group/fa.haskell/msg/3ca260fb075a901e to > > implement an "array DSL" for GPUs in Haskell. It would mean GHC taking > > a dependency on hs-plugins > > (http://www.cse.unsw.edu.au/~dons/hs-plugins/), as that's our current > > strategy to allow GHC to dynamically link with the plugins. > > > > A little about my experience with GHC: this year I worked on > > implementing comprehensive comprehensions > > (http://research.microsoft.com/~simonpj/papers/list-comp/index.htm) as > > my final year undergraduate project, supervised by Simon PJ. I have > > subsequently implemented a few other patches, adding some core-level > > optimizations / bug fixes (some of which are pending review). > > > > Thanks in advance for your comments! > > Max > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > > ------------------------------ > > Message: 7 > Date: Sat, 22 Mar 2008 12:17:48 +0000 > From: "Neil Mitchell" > Subject: Re: [Haskell-cafe] "doctest" for haskell -- a good project? > To: "Don Stewart" > Cc: Shaun Cutts , haskell-cafe@haskell.org > Message-ID: > <404396ef0803220517w35ac8e81u41026c85bd9ebe1d@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Hi > > > One idea that does strike me is that it would be super useful to have > > the ability in ghci to extract the haddocks associated with a function. > > > > > :doc map > > > > would result in: > > > > -- | 'map' @f xs@ is the list obtained by applying @f@ to each element > > -- of @xs@, i.e., > > -- > > -- > map f [x1, x2, ..., xn] == [f x1, f x2, .. > > -- > map f [x1, x2, ...] == [f x1, f x2, ...] > > That will be in Hoogle 4, as it does already directly relate to what > Hoogle has to do. > > As for doctest, i think that could be implemented as a --warn flag to > Haddock, and might be a useful thing to have. For example "90% of the > base library has documentation, please go add documentation to > 'sinh'", as a warning message. > > Thanks > > Neil > > > ------------------------------ > > Message: 8 > Date: Sat, 22 Mar 2008 08:45:01 -0400 > From: Michael Feathers > Subject: Re: [Haskell-cafe] An ugly zip3 problem.. > To: Tillmann Rendel > Cc: Haskell Cafe > Message-ID: <47E4FF4D.5000000@mindspring.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > > Thanks! I learned a lot from that. > > > Michael > > Tillmann Rendel wrote: > > Michael Feathers wrote: > > > I'm working on something and it's looking rather ugly. essentially, > > > it's an application of a low pass filer to a dataset. > > > > I would not consider your code ugly. it can be made shorter, though. > > > > > type Dataset = [Double] > > > type FilterWindow3 = (Double,Double,Double) > > > > > > internalList :: [a] -> [a] > > > internalList = tail . init > > > > > > lowPass3 :: FilterWindow3 -> Double > > > lowPass3 (i, j, k) = (i + 2 * j + k) / 4.0 > > > > > > filter3 :: (FilterWindow3 -> Double) -> Dataset -> Dataset > > > filter3 f3 ds = [(f3 x) | x <- formWindows ds] > > > > I would prefer this version to the list comprehension: > > > > filter3 f3 = map f3 . formWindows > > > > I tend to assume list comprehensions are doing something magical I have > > to figure out while reading a program, so a comprehension for a simple > > map looks wrong to me. read ahead for more magical list comprehensions. > > > > > iterFilter :: (Dataset -> Dataset) -> Int -> Dataset -> Dataset > > > iterFilter f n ds > > > | n > 0 = iterFilter f (n - 1) (f ds) > > > | otherwise = ds > > > > You can use iterate and list indexing to iterate a function a specified > > number of times. > > > > iterFilter f n = (!! n) . iterate f > > > > Probably > > > > iterateN :: (a -> a) -> Int -> a > > > > is a better type and name for this function. > > > > > formWindows :: Dataset -> [FilterWindow3] > > > formWindows ds = > > > internalList $ zip3 x y z > > > where c0 = [head ds] > > > cn = [last ds] > > > x = ds ++ cn ++ cn > > > y = c0 ++ ds ++ cn > > > z = c0 ++ c0 ++ ds > > > > internalList will delete the first and last element, so why create it at > > all? there is no problem with different list lengths, the result will be > > as long as the shortest list. > > > > formWindows ds = zip3 x y z where > > x = tail ds ++ [last ds] > > y = ds > > z = head ds : ds > > > > if you want to make clear what elements of the lists are used, you can use > > > > z = head ds : init ds > > > > instead. Note that definition for y clearly states that the middle > > element is the original list. I would consider swapping x and z to help > > me imagine a window moving over the dataset. as it is now, i have to > > imagine a window with an integrated mirror to make it fit. > > > > I don't like the definition of x, because I fear that the (last ds) > > thunk will hang around and hold the whole list ds in memory, which is > > unecessary because it's value only depends on the last element of said > > list. I would therefore consider a different implementation using tails. > > > > formWindows ds = [(f y z, y, x) | (x : y : z) <- tails (head ds : ds)] > > where f x [] = x > > f _ (x : _) = x > > > > the head corner case is taken care of by duplicating the head of ds. the > > last corner case is taken care of by the call to f, which uses y as > > default value if z doesn't contain another one. the list comprehension > > is used here to do three different things: > > > > * convert lists to tuples > > * apply f > > * throw away the last element of tails' result (pattern match > > failure means "ignore this element" in list comprehensions) > > > > Maybe > > > > headDefault :: a -> [a] -> a > > > > is a sensible name for f. > > > > > smooth :: Int -> Dataset -> Dataset > > > smooth = iterFilter $ filter3 lowPass3 > > > > by inlining the definition above, this can be given as a four-liner now: > > > > smooth n = (!! n) . iterate f where > > f ds = [(g y z + 2 * y + x) / 4.0 | x:y:z <- tails (head ds : ds)] > > g x [] = x > > g _ (x:_) = x > > > > :-) > > > > Tillmann > > > > > -- > Now Playing: http://www.youtube.com/watch?v=SsnDdq4V8zg > > > > ------------------------------ > > Message: 9 > Date: Sat, 22 Mar 2008 08:53:58 -0400 > From: Michael Feathers > Subject: Re: [Haskell-cafe] An ugly zip3 problem.. > To: Tillmann Rendel > Cc: Haskell Cafe > Message-ID: <47E50166.8070302@mindspring.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > > > One thing that gets me about this solution.. as I was structuring mine I > noticed that I was ending up with types like FilterWindow3 and functions > like lowPass3. Inlining does eliminate them, but I wonder whether there > is a good way to structure the computation generically so that it can be > performed with windows of 5 as well as 3. The cons pattern matching > here would get in the way, and in my original solution, the fact that I > was using tuples got in the way also. > > Would Haskell's type system allow you to pass a function of arbitrary > arity, discern its arity, use that information to construct the > appropriate structure for iteration, and then apply it? > > > Michael > > Tillmann Rendel wrote: > > > > > by inlining the definition above, this can be given as a four-liner now: > > > > smooth n = (!! n) . iterate f where > > f ds = [(g y z + 2 * y + x) / 4.0 | x:y:z <- tails (head ds : ds)] > > g x [] = x > > g _ (x:_) = x > > > > :-) > > > > Tillmann > > > > > -- > Now Playing: http://www.youtube.com/watch?v=SsnDdq4V8zg > > > > ------------------------------ > > Message: 10 > Date: Sat, 22 Mar 2008 21:40:01 +0800 > From: Deng Chao > Subject: [Haskell-cafe] How to program with sqlite? > To: haskell-cafe@haskell.org > Message-ID: <1206193201.9417.4.camel@knifewolfUBUNTU> > Content-Type: text/plain > > Hi all, > I'm learning sqlite, and as I know haskell has some libraries like > HDBC or HSQL can access sqlite DB. Can anybody give me a small example > to show how to use it? It will be very appreciate? Thanks! > > Best Regards, > Deng Chao > > > > ------------------------------ > > Message: 11 > Date: Sat, 22 Mar 2008 14:53:31 +0100 > From: Thomas Schilling > Subject: Re: [Haskell-cafe] "doctest" for haskell -- a good project? > To: "Neil Mitchell" > Cc: Shaun Cutts , haskell-cafe@haskell.org > Message-ID: <1413441C-C2FE-4451-837E-19908C607843@googlemail.com> > Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed > > > On 22 mar 2008, at 13.17, Neil Mitchell wrote: > > > Hi > > > >> One idea that does strike me is that it would be super useful to > >> have > >> the ability in ghci to extract the haddocks associated with a > >> function. > >> > >>> :doc map > >> > >> would result in: > >> > >> -- | 'map' @f xs@ is the list obtained by applying @f@ to > >> each element > >> -- of @xs@, i.e., > >> -- > >> -- > map f [x1, x2, ..., xn] == [f x1, f x2, .. > >> -- > map f [x1, x2, ...] == [f x1, f x2, ...] > > > > That will be in Hoogle 4, as it does already directly relate to what > > Hoogle has to do. > > > > As for doctest, i think that could be implemented as a --warn flag to > > Haddock, and might be a useful thing to have. For example "90% of the > > base library has documentation, please go add documentation to > > 'sinh'", as a warning message. > > > > > Though that would be a nice feature, too, I think you misunderstood > what a doctest is. > > A doctest is a unit test in the documentation. This way it serves as > a usage example as well as a formal specification of the semantics. > I think we already have some way to run quickchecks inside > documentation, but I can't remember what it was that could do that. > > / Thomas > > > ------------------------------ > > Message: 12 > Date: Sat, 22 Mar 2008 14:15:02 +0000 > From: "Sebastian Sylvan" > Subject: Re: [Haskell-cafe] How to program with sqlite? > To: knifewolf@gmail.com > Cc: haskell-cafe@haskell.org > Message-ID: > <3d96ac180803220715q50c2f0c8gbbd538c3deb26c3e@mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > On Sat, Mar 22, 2008 at 1:40 PM, Deng Chao wrote: > > > Hi all, > > I'm learning sqlite, and as I know haskell has some libraries like > > HDBC or HSQL can access sqlite DB. Can anybody give me a small example > > to show how to use it? It will be very appreciate? Thanks! > > > > Best Regards, > > Deng Chao > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > > Here's a quick GHCi session with HDBC. > > Prelude> :m +Database.HDBC > Prelude Database.HDBC> :m +Database.HDBC.Sqlite3 > Prelude Database.HDBC Database.HDBC.Sqlite3> conn <- connectSqlite3 "mydb" > Prelude Database.HDBC Database.HDBC.Sqlite3> quickQuery conn "CREATE TABLE > mytable (FirstName varchar, LastName varchar, Age int )" [] > [] > Prelude Database.HDBC Database.HDBC.Sqlite3> quickQuery conn "INSERT INTO > mytable VALUES ('Sebastian','Sylvan',26)" [] > [] > Prelude Database.HDBC Database.HDBC.Sqlite3> commit conn > Prelude Database.HDBC Database.HDBC.Sqlite3> quickQuery conn "SELECT * FROM > mytable" [] > [[SqlString "Sebastian",SqlString "Sylvan",SqlString "26"]] > Prelude Database.HDBC Database.HDBC.Sqlite3> disconnect conn > > > Not sure why that Age field came back as a string though :-) > > > -- > Sebastian Sylvan > +44(0)7857-300802 > UIN: 44640862 > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080322/37aaabaf/attachment-0001.htm > > ------------------------------ > > Message: 13 > Date: Sat, 22 Mar 2008 14:20:10 +0000 > From: "Sebastian Sylvan" > Subject: Re: [Haskell-cafe] "doctest" for haskell -- a good project? > To: "Don Stewart" > Cc: Shaun Cutts , haskell-cafe@haskell.org > Message-ID: > <3d96ac180803220720v49847f9fq9f6930cb372f5c6f@mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > On Sat, Mar 22, 2008 at 8:39 AM, Don Stewart wrote: > > > shaun: > > > Hello, > > > > > > I am an experienced programmer, currently learning Haskell. Currently > > I > > > write many things in python. I use both the "doctest" and "unittest" > > > modules extensively. As I write code, I simultaneously write doctest > > code > > > in the doc strings to explain/set out the "typical narrative" of how > > the > > > code is used. Then finishing off a module I write unittests for > > boundary > > > conditions, more complex test cases, and generally code that would be > > > annoying to write & read in doctests. > > > > > > I note that there is a unit testing framework for Haskell, but I > > don't see > > > > There's a couple, QuickCheck is the best, it generalises unit testing to > > property testing with random, or not so random, data. > > > > > any doctest module. Might this be a good project? > > > If so, suggestions as to resources would be greatly appreciated. I > > believe > > > I can't just "introspect" Haskell modules to get at > > > documentation/comments, like I can in python? (Why not? :)) I notice > > that > > > there are a few "documentation generators". Should I try to write an > > > extension of one of these? Haddock, for instance? Are there any > > Haddock > > > developers hanging out on this list, to encourage or dissuade me? :) > > (And > > > where is the Haddock doc for Haddock?) > > > > > > In any case, thanks in advance for any comments & advice. > > > > I'm not sure how doctest works, or how it would work in a Haskell > > setting, could you elaborate? > > > > One idea that does strike me is that it would be super useful to have > > the ability in ghci to extract the haddocks associated with a function. > > > > > :doc map > > > > would result in: > > > > -- | 'map' @f xs@ is the list obtained by applying @f@ to each element > > -- of @xs@, i.e., > > -- > > -- > map f [x1, x2, ..., xn] == [f x1, f x2, .. > > -- > map f [x1, x2, ...] == [f x1, f x2, ...] > > > > marked up in ascii. > > > > I'm not sure if that's related to doctest, but it sure would be useful! > > > > To be honest, I think this is what we should see when we type ":info map". > Preferably we'd get a proper GUI version of GHCi which prints it out into a > HTML box or something with proper hyperlinks and formatting. > > > > -- > Sebastian Sylvan > +44(0)7857-300802 > UIN: 44640862 > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080322/cee14b21/attachment-0001.htm > > ------------------------------ > > Message: 14 > Date: Sat, 22 Mar 2008 15:29:28 +0100 > From: Robert Vollmert > Subject: [Haskell-cafe] HXT and types in Control.Arrow.ArrowTree > To: haskell-cafe@haskell.org > Message-ID: > Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes > > Hello, > > I'm having some trouble with HXT, the types of some functions in > particular. This may well be caused by a lack of understanding for > arrow programming -- I'd appreciate any hints. > > In short, I'm constantly running into what appear to be artificial > type restrictions in Control.Arrow.ArrowTree. For example, the > signature of "deep" is > > deep :: (Tree t, ArrowTree a) => a (t b) (t b) -> a (t b) (t b) > > instead of the more general > > deep :: (Tree t, ArrowTree a) => a (t b) c -> a (t b) c > > Say I have an arrow > > getLink :: (ArrowXml a) => a XmlTree Link > > that converts an HTML link (text) into some > appropriate data type (code below). To collect all links in a > document, I'd like to use > > deep getLink > > instead of > > deep (hasName "a") >>> getLink > > Is this the wrong approach to converting XML into Haskell data types? > > Cheers > Robert > > > module Links where > > import Text.XML.HXT.Arrow > > data Link = Link { url, text :: String } > deriving Show > > getLink :: (ArrowXml a) => a XmlTree Link > getLink = isElem >>> hasName "a" > >>> (getAttrValue0 "href" &&& getAllText) > >>> arr (uncurry Link) > > getAllText :: (ArrowXml a) => a XmlTree String > getAllText = listA (deep isText >>> getText) >>> arr concat > > > > ------------------------------ > > Message: 15 > Date: Sat, 22 Mar 2008 15:00:44 +0000 > From: Dominic Steinitz > Subject: [Haskell-cafe] Opening Windows .lnk Files > To: haskell-cafe@haskell.org > Message-ID: <47E51F1C.7090808@blueyonder.co.uk> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Does anyone know how to do this? If I open a file on Windows e.g. > "asn_application.h.lnk" then I get the link data rather than the data in > the linked file. > > Thanks, Dominic. > > > > ------------------------------ > > Message: 16 > Date: Sat, 22 Mar 2008 11:19:30 -0400 > From: "Shaun Cutts" > Subject: RE: [Haskell-cafe] "doctest" for haskell -- a good project? > To: "'Thomas Schilling'" > Cc: haskell-cafe@haskell.org > Message-ID: <052801c88c30$211e93b0$7000a8c0@INTERLINK> > Content-Type: text/plain; charset="us-ascii" > > Thanks for the quick responses. To elaborate on how doctests work in python: > > (Background: in python functions, classes & modules are all "objects" -- > having attributes as well as (for functions) the ability to run them. They > all have, in particular a documentation string associated with them. To get > at these doctest module just loads the module, then examines its contents, > looking for doc strings of contained functions & classes... so the language > itself provides introspection capabilities: a strong point of python. Maybe > Haskell should also have this :).) > > Doctests in python are bits of code in documentation strings specially > annotated. In the docstring for a function "f", we might have (with > apologies for python function call syntax :)): > > >>> f( foo ) > bar > > This means: run f( foo ) and check that (the string representation of ) the > output is "bar". > > You can put any code in docstring. In effect, the doctest module turns what > you have written into a little module, together with imports, etc. > > For continuation lines on blocks of code the convention is: > > >>> f( > ... foo ) > > A blank line after a ">>>" line means that no output is expected (you > defined a function, for example). > If a blank line is part of the string representation of output, then it is > represented, e.g.: > > >>> f( foo ) > > bar > > If result has lots of text, you can use > > >>> f( foo ) > > bar > > This is helpful, e.g. if f is a helper function that catches an exception > then prints it out; you don't want to check the resulting stack-trace -- > just the part at the end about what exception was caught. > > There are lots of other switches & options, but no need to copy all of the > details. (Anyway, by the time I get to worrying about them, I'll have my own > opinions. :)) > > --------------------------------------- > > So Paul Johnson writes: > > > You need to support QuickCheck and Hunit > > In fact, at least in python, doctests are even more generic... They support > "anything" -- though > QuickCheck tests are also allowed. Does this approach seem ok/desirable here > too? > > A bit worrisome info from Paul: > > > Haddock does not contain a full Haskell parser, which makes it difficult > to extend in a principled way (or maybe I'm just not a good enough > programmer). > > > I also looked at using the Haskell parser in the libraries, but that > doesn't capture comments. > > Associating a comment with a particular construct is not that simple > either. > > Hmm... this makes me think that the first thing would be for me to put in an > option to capture comments in the parse tree in the parser. Then Paul and > crew would hack the parser's use into Haddock. Then I'd extend Haddock to > support doctests! > > How about that? > > Or actually I think its overkill. If I can hook into the processing of the > comment (presumably only extended comments), I can piece together a fake > "module". The "..." convention means I should know how to stitch together > expressions without having to understand them. One problem is checking the > "output" of an expression. If an expression has output, it would seem I > should throw in a test (using QuickCheck?). Hmmm. > > - Shaun > > > > -----Original Message----- > > From: Thomas Schilling [mailto:nominolo@googlemail.com] > > Sent: Saturday, March 22, 2008 9:54 AM > > To: Neil Mitchell > > Cc: Don Stewart; Shaun Cutts; haskell-cafe@haskell.org > > Subject: Re: [Haskell-cafe] "doctest" for haskell -- a good project? > > > > > > On 22 mar 2008, at 13.17, Neil Mitchell wrote: > > > > > Hi > > > > > >> One idea that does strike me is that it would be super useful to > > >> have the ability in ghci to extract the haddocks > > associated with a > > >> function. > > >> > > >>> :doc map > > >> > > >> would result in: > > >> > > >> -- | 'map' @f xs@ is the list obtained by applying > > @f@ to each > > >> element > > >> -- of @xs@, i.e., > > >> -- > > >> -- > map f [x1, x2, ..., xn] == [f x1, f x2, .. > > >> -- > map f [x1, x2, ...] == [f x1, f x2, ...] > > > > > > That will be in Hoogle 4, as it does already directly > > relate to what > > > Hoogle has to do. > > > > > > As for doctest, i think that could be implemented as a > > --warn flag to > > > Haddock, and might be a useful thing to have. For example > > "90% of the > > > base library has documentation, please go add documentation to > > > 'sinh'", as a warning message. > > > > > > > > > Though that would be a nice feature, too, I think you > > misunderstood what a doctest is. > > > > A doctest is a unit test in the documentation. This way it > > serves as > > a usage example as well as a formal specification of the semantics. > > I think we already have some way to run quickchecks inside > > documentation, but I can't remember what it was that could do that. > > > > / Thomas > > > > > > ------------------------------ > > Message: 17 > Date: Sat, 22 Mar 2008 08:42:47 -0700 > From: Bryan O'Sullivan > Subject: Re: [Haskell-cafe] An ugly zip3 problem.. > To: Michael Feathers > Cc: Haskell Cafe > Message-ID: <47E528F7.8060204@serpentine.com> > Content-Type: text/plain; charset=UTF-8 > > Michael Feathers wrote: > > > Would Haskell's type system allow you to pass a function of arbitrary > > arity, discern its arity, use that information to construct the > > appropriate structure for iteration, and then apply it? > > The answer is probably "yes", because almost every time I've thought > that a type system related question had an answer of "no", someone has > been able to point me at a paper by Oleg Kiselyov. > > But if you're convolving a one-dimensional vector, and it's structured > as a list, a simpler approach is to use a variant of a zipper data > structure. Basically, as you traverse the list, you build a new list of > the elements that you've already consumed. > > Let's say your list looks like this: > > [1,2,3,4,5,6,7,8] > > You start off with an empty list of items you've consumed, and for each > item you pull off the list you're consuming, you push it onto the list > you've consumed. > > [] 1 [2,3,4,5,6,7,8] > [1] 2 [3,4,5,6,7,8] > ... > [4,3,2,1] 5 [6,7,8] > ... > > Your consumption function can then use pattern matching to pick out an > appropriate number of neighbouring elements from the fronts of the list > you're about to consume and the list you've just consumed. To change > the number of elements you're looking at, you just modify the two > patterns, not the types or data structures you're using. > > This technique, though cute, has several drawbacks. > > 1. Lists won't exactly make your performance fly. You're also > constructing an entire list of already seen values when you only need a > handful from near the front. This capability makes sense when you need > to be able to switch the direction of iteration for some reason, but > that doesn't apply here. > 2. Because you can't pattern match on elements in an array, you can't > pick this approach up and transplant it to a different underlying data > structure. > 3. I don't know how to construct a useful zipper over lists of higher > order (e.g. lists of lists), so at least with my limited brain power and > attention span, the approach falls apart if you want to convolve a 2D or > higher vector. > > > > ------------------------------ > > Message: 18 > Date: Sat, 22 Mar 2008 16:08:03 +0000 > From: Paul Johnson > Subject: Re: [Haskell-cafe] "doctest" for haskell -- a good project? > To: Shaun Cutts , Haskell-cafe Cafe > > Message-ID: <47E52EE3.3040808@cogito.org.uk> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Shaun Cutts wrote: > > I note that there is a unit testing framework for Haskell, but I don't > > see any doctest module. Might this be a good project? > I once looked at doing this, but I didn't get very far. > > Haddock is important here because you want to include the tests as part > of the documentation. QuickCheck properties in particular closely > resemble a formal specification. For a couple of examples, see my > RangedSet package and Neil Mitchel's FilePath package. I manually > copied the RangedSet tests into the Haddock documentation, while Neil > wrote a small Haskell script to extract his tests from his documentation > automatically. Unfortunately his script is tied to specific aspects of > his FilePath package. > > Haddock does not contain a full Haskell parser, which makes it difficult > to extend in a principled way (or maybe I'm just not a good enough > programmer). The problem is you need to have several different new > kinds of mark-up, and its not always clear what to do. > > You need to support QuickCheck and HUnit. Also possibly SmallCheck and > some other similar unit testing cum specification frameworks. For > QuickCheck you need to have type information for the tests. For > instance the classic specification / test of "reverse" is: > > > prop_reverse xs xy = (reverse xs ++ reverse ys) == reverse (ys ++ xs) > > Somewhere you need to flag that "xs" and "ys" are lists of integers. In > the case of my RangedSets I needed to run the tests with both Integers > and Doubles. > > I also looked at using the Haskell parser in the libraries, but that > doesn't capture comments. Associating a comment with a particular > construct is not that simple either. > > If you can manage this then it would be great. > > Paul. > > > > ------------------------------ > > Message: 19 > Date: Sat, 22 Mar 2008 16:08:23 +0000 > From: Paul Johnson > Subject: Re: [Haskell-cafe] AMQP framing layer: design help requested. > To: Haskell-cafe Cafe > Message-ID: <47E52EF7.9000209@cogito.org.uk> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Dean Herington wrote: > > At 6:41 PM -0700 3/21/08, Adam Langley wrote: > >> > >> Also > >>> getter <- fmap (amqpGetTable !) getWord8 > >>> getter > >> > >> is just > >> > >> > fmap (amqpGetTable !) getWord8 > > > > I don't think so. Aren't there two "gettings": the first to get the > > "type" byte and the second to get the item? > > > Yes. I didn't use it because it seemed obfuscated, but in fact the > point-free version is > > > fmap (amqpGetTable !) getWord8 >>= id > > And I've also got an AmqpWire class similar to Dean's AmqpValue class. > But both of these miss the point (which is why I didn't clutter up my > simplified explanation with them). > > I'm looking for an alternative to the honking big AmqpVariant and > AmqpArray types. I think I want something along the lines of: > > > class (Binary v) => VariantClass v where > > typeCode :: v -> Word8 > > fromVariant :: AmqpVariant -> Maybe v > > > > newtype AmqpVariant = forall a . (VariantClass a) => Variant a > > > > newtype AmqpArray = forall a . (VariantClass a) => AmqpArray [a] > > But I can't see how to write "fromVariant". I'm also unsure what the > "amqpGet" and "amqpPut" methods might look like. > > Or maybe these two types are actually the best design. They do let you > pattern-match on the contents. Extracting the contents of a variant > from the design above would be something like: > > > processVariant (Variant v) = > > case typeCode v of > > 0x01 -> processWord8 $ fromJust $ fromVariant v > > 0x02 -> ... and so on. > > Compare this with: > > > processVariant (VariantWord8 v) = processWord8 v > > processVariant (VariantWord16 v) = processWord16 v > > ... and so on. > > What do you think? > > Paul. > > > > > ------------------------------ > > Message: 20 > Date: Sat, 22 Mar 2008 11:13:54 -0500 > From: "Antoine Latter" > Subject: Re: [Haskell-cafe] Problem with OpenAL > To: "George Giorgidze" > Cc: sven.panne@aedion.de, haskell-cafe@haskell.org > Message-ID: > <694519c50803220913l4e42d4c9s5b66265a3721c6a6@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > For those of you following along, you'll need: > > > import qualified Sound.OpenAL as AL > > import Data.Maybe > > import Foreign.C.Types > > import Control.Monad > > import Control.Concurrent > > import Foreign.Storable > > import Foreign.Marshal.Alloc > > when I run "playOpenAL 440" I get no sound, and the following is > repeatedly printed on the console: > > waiting > 0 > 1 > waiting > 0 > 1 > waiting > 0 > 1 > waiting > 0 > 1 > > What do you think should be happening? > > -Antoine > > 2008/3/21 George Giorgidze : > > I tried OpenAL binding (the one which is on the Hackage), but with no luck. > > > > I can not hear anything from speakers and also according to generated output > > on console it seems that "AL.play" never completes playback of a buffer as > > buffer remains registered as "unprocessed" in OpenAL context. > > Here is the piece of code. I am not getting any error messages from OpenAL > > library functions. > > > > playOpenAL :: Int -> IO () > > playOpenAL sr = do > > mDevice <- AL.openDevice Nothing > > when (isNothing mDevice) $ error "opening OpenAL device" > > let device = fromJust mDevice > > > > mContext <- AL.createContext device [ > > AL.Frequency (fromIntegral sr) > > , AL.Refresh (fromIntegral sr) > > ] > > when (isNothing mContext) $ error "creating OpenAL context" > > let context = fromJust mContext > > AL.currentContext AL.$= (Just context) > > > > > > let sampleNumber = 256 > > bufSize = sampleNumber * (sizeOf (undefined :: CShort)) > > buf2 <- mallocBytes bufSize > > > > -- here I am filling buf2 with noise .... > > > > [source] <- AL.genObjectNames 1 > > [buffer] <- AL.genObjectNames 1 > > > > let region = AL.MemoryRegion buf2 (fromIntegral bufSize) > > AL.bufferData buffer AL.$= (AL.BufferData region AL.Mono16 (fromIntegral > > sr)) > > > > > > AL.queueBuffers source [buffer] > > AL.loopingMode source AL.$= AL.OneShot > > > > let waitForSource = do > > putStrLn "waiting" > > s <- AL.get (AL.buffersProcessed source) > > putStrLn $ show s > > s <- AL.get (AL.buffersQueued source) > > putStrLn $ show s > > state <- AL.get (AL.sourceState source) > > case state of > > AL.Playing -> do > > threadDelay 1024 > > waitForSource > > _ -> return () > > > > putStrLn "Start Playing ... " > > AL.play [source] > > waitForSource > > > > > > AL.currentContext AL.$= Nothing > > AL.destroyContext context > > b <- AL.closeDevice device > > when (not b) $ error "closing device" > > > > > > Is this library still maintained? > > > > Best, George > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > > > > ------------------------------ > > Message: 21 > Date: Sat, 22 Mar 2008 11:50:49 -0500 > From: Derek Elkins > Subject: Re: [Haskell-cafe] AMQP framing layer: design help requested. > To: Paul Johnson > Cc: Haskell-cafe Cafe > Message-ID: <1206204649.5533.23.camel@derek-laptop> > Content-Type: text/plain > > On Sat, 2008-03-22 at 16:08 +0000, Paul Johnson wrote: > > Dean Herington wrote: > > > At 6:41 PM -0700 3/21/08, Adam Langley wrote: > > >> > > >> Also > > >>> getter <- fmap (amqpGetTable !) getWord8 > > >>> getter > > >> > > >> is just > > >> > > >> > fmap (amqpGetTable !) getWord8 > > > > > > I don't think so. Aren't there two "gettings": the first to get the > > > "type" byte and the second to get the item? > > > > > Yes. I didn't use it because it seemed obfuscated, but in fact the > > point-free version is > > > > > fmap (amqpGetTable !) getWord8 >>= id > > > Nah, the point-free version wouldn't be this. First, > join = x >>= id so > fmap (ampqGetTable !) getWord8 >>= id > === join (fmap (ampqGetTable !) getWord8) > Next, m >>= f = join (fmap f m) so > join (fmap (ampqGetTable !) getWord8) > === getWord8 >>= (ampqGetTable !) > This would be the point-free version > > So the original code was a round-about way of saying: > do word <- getWord8; ampqGetTable ! word > > > > > ------------------------------ > > Message: 22 > Date: Sat, 22 Mar 2008 17:11:06 +0000 > From: "Neil Mitchell" > Subject: Re: [Haskell-cafe] Opening Windows .lnk Files > To: "Dominic Steinitz" > Cc: haskell-cafe@haskell.org > Message-ID: > <404396ef0803221011j35c44a90i1924ed6fce92774f@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Hi > > Drop into the command line, rename the file from foo.lnk to foo.txt, > using "ren foo.lnk foo.txt", then open "foo.txt". It's a chunk of > binary goop, so will likely not be much use. > > There is a COM class for editing shortcut files (IShellLink), which > I've used before from C code. See > http://darcs.haskell.org/hugs98/src/winhugs/installer/ShellCode.cpp, > in particular the CreateShortcut function. > > Thanks > > Neil > > > ------------------------------ > > Message: 23 > Date: Sat, 22 Mar 2008 17:16:55 +0000 > From: "Neil Mitchell" > Subject: Re: [Haskell-cafe] "doctest" for haskell -- a good project? > To: "Paul Johnson" > Cc: Shaun Cutts , Haskell-cafe Cafe > > Message-ID: > <404396ef0803221016u4919a2eaud9b916a4f32fa82b@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Hi > > > I once looked at doing this, but I didn't get very far. > > Me too, and I managed to get some way: > > > resemble a formal specification. For a couple of examples, see my > > RangedSet package and Neil Mitchel's FilePath package. I manually > > copied the RangedSet tests into the Haddock documentation, while Neil > > wrote a small Haskell script to extract his tests from his documentation > > automatically. Unfortunately his script is tied to specific aspects of > > his FilePath package. > > Yes, the problem was that FilePath wants to execute half the tests > twice with different modules, and half with just one namespace. As far > as tests go, this is a very wacky requirement. I wanted to generalise > it into a tool, but couldn't find a sensible generalisation that still > worked with filepath - and hence didn't bother. I think the solution > is to not permit the quirkyness of filepath, and write a general > solution for everything else. > > As someone who has frequently considered writing this, even going as > far as brainstorming on a whiteboard, I would be an enthusiastic user > of this. I think the lack of this tool in Haskell is a big hole which > someone needs to fill. I particularly like the facility in FilePath: > > -- > x == reverse (reverse x) > -- > reverse "neil" = "lien" > > i.e. I can write both quickcheck properties (quantified over all > single letter variables), or I can write an instance (like doctest in > Python) > > Thanks, and good luck! > > Neil > > > ------------------------------ > > Message: 24 > Date: Sat, 22 Mar 2008 17:32:38 +0000 > From: Dominic Steinitz > Subject: Re: [Haskell-cafe] Opening Windows .lnk Files > To: Neil Mitchell > Cc: haskell-cafe@haskell.org > Message-ID: <47E542B6.6030000@blueyonder.co.uk> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Neil Mitchell wrote: > > Hi > > > > Drop into the command line, rename the file from foo.lnk to foo.txt, > > using "ren foo.lnk foo.txt", then open "foo.txt". It's a chunk of > > binary goop, so will likely not be much use. > > > > There is a COM class for editing shortcut files (IShellLink), which > > I've used before from C code. See > > http://darcs.haskell.org/hugs98/src/winhugs/installer/ShellCode.cpp, > > in particular the CreateShortcut function. > > > > Thanks > > > > Neil > > > > > > > Neil, > > Thanks but following a discussion on #haskell, it's all beginning to > sound a bit hard. Somehow I thought it would be easy. I know where the > real files are so I'll just set a directory as a parameter, strip off > the .lnk from the name and use that + the directory to manipulate them. > > Dominic. > > > > ------------------------------ > > Message: 25 > Date: Sat, 22 Mar 2008 14:02:16 -0400 > From: "Shaun Cutts" > Subject: RE: [Haskell-cafe] "doctest" for haskell -- a good project? > To: "'Neil Mitchell'" , "'Paul Johnson'" > > Cc: 'Haskell-cafe Cafe' > Message-ID: <05d301c88c46$de0d92d0$7000a8c0@INTERLINK> > Content-Type: text/plain; charset="iso-8859-1" > > > > > resemble a formal specification. For a couple of > > examples, see my > > > RangedSet package and Neil Mitchel's FilePath package. I manually > > > copied the RangedSet tests into the Haddock documentation, > > while Neil > > > wrote a small Haskell script to extract his tests from his > > > documentation automatically. Unfortunately his script is tied to > > > specific aspects of his FilePath package. > > > > Yes, the problem was that FilePath wants to execute half the > > tests twice with different modules, and half with just one > > namespace. As far as tests go, this is a very wacky > > requirement. I wanted to generalise it into a tool, but > > couldn't find a sensible generalisation that still worked > > with filepath - and hence didn't bother. I think the solution > > is to not permit the quirkyness of filepath, and write a > > general solution for everything else. > > Niel -- I understand your script is part of FilePath... might it be a good > starting point for abstraction? Can you point me to it? > > > As someone who has frequently considered writing this, even > > going as far as brainstorming on a whiteboard, I would be an > > enthusiastic user of this. I think the lack of this tool in > > Haskell is a big hole which someone needs to fill. I > > particularly like the facility in FilePath: > > > > -- > x == reverse (reverse x) > > -- > reverse "neil" = "lien" > > > > i.e. I can write both quickcheck properties (quantified over > > all single letter variables), or I can write an instance > > (like doctest in > > Python) > > > > Thanks, and good luck! > > > > Neil > > > Thank you for the support... This might take me a while, I must warn, as > this is an "after work" project, and I am a consultant, so "after work" > often doesn't come :). But its certainly motivating to work on something > right away that could be useful (to myself as well). > > - Shaun > > > > ------------------------------ > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > End of Haskell-Cafe Digest, Vol 55, Issue 30 > ******************************************** From gtener at gmail.com Sun Mar 23 08:39:40 2008 From: gtener at gmail.com (=?ISO-8859-2?Q?Krzysztof_Skrz=EAtnicki?=) Date: Sun Mar 23 08:36:10 2008 Subject: [Haskell-cafe] Type constraints for class instances In-Reply-To: References: <220e47b40803201900u4bcc564ard2ab8ad6d1d32a81@mail.gmail.com> Message-ID: <220e47b40803230539i42796fa1h480210020720e879@mail.gmail.com> I fixed the code, see below. In fact, it works now for any listst of type (YOrd a) => [a]. It works for things like > ysort [[1..],[1..],[2..],[1..]] Unfortunately, the performance of ysort is rather low. I belive that it is impossible to create any sorting algorithm that uses ycmp instead of compare, that is faster than O(n^2). In fact, ysort is Theta(n^2), and it appears to be optimal. Why? Well, consider the bubble sort algorithm. Then ycmp will be simply sort of swap used there: ycmp x y = case x `compare` y of LT -> (x,y) EQ -> (x,y) GT -> (y,x) And because it is the only possible operation here, it can't be faster. (Though I may be wrong.) Best regards, Christopher Skrz?tnicki. --- --- http://hpaste.org/6536#a1 {-# OPTIONS_GHC -O2 #-} module Data.YOrd (ysort, YOrd(..)) where -- Well defined where Eq means equality, not only equivalence class YOrd a where ycmp :: a -> a -> (a,a) instance (Ord a) => YOrd [a] where ycmp = ycmpWith compare where ycmpWith _ xs [] = ([],xs) ycmpWith _ [] xs = ([],xs) ycmpWith cmp (xs'@(x:xs)) (ys'@(y:ys)) = case x `cmp` y of LT -> (xs',ys') GT -> (ys',xs') EQ -> let (sm,gt) = xs `ycmp` ys in (x:sm,x:gt) -- assumes that cmp is equality not equivalence relation here! ycmpWrap cmp x y = case x `cmp` y of LT -> (x,y) EQ -> (x,y) GT -> (y,x) instance YOrd Integer where ycmp = ycmpWrap compare instance YOrd Char where ycmp = ycmpWrap compare instance YOrd Int where ycmp = ycmpWrap compare -- ysort : sorting in O(n^2) ysort :: (YOrd a) => [a] -> [a] ysort = head . mergeAll . wrap wrap xs = map (:[]) xs mergeAll [] = [] mergeAll [x] = [x] mergeAll (a:b:rest) = mergeAll ((merge a b) : (mergeAll rest)) merge xs [] = xs merge [] xs = xs merge (x:xs) (y:ys) = let (sm,gt) = x `ycmp` y in sm : (merge [gt] $ merge xs ys) 2008/3/21 Stephen Marsh : > Actually, infinite trees wouldn't work, for a similar reason to above. You > can't decide sort order on the infinite left branches, so you could never > choose the correct right branch. > > Stephen > > 2008/3/21 Stephen Marsh : > > > > There is a bug in the code: > > > > *Main> ycmp [5,2] [2,5] :: ([Int], [Int]) > > ([2,2],[5,5]) > > > > I think it is impossible to define a working (YOrd a) => YOrd [a] > instance. Consider: > > > > let (a, b) = ycmp [[1..], [2..]] [[1..],[1..]] > > > > head (b !! 1) -- would be nice if it was 2, but it is in fact _|_ > > > > We take forever to decide if [1..] is greater or less than [1..], so can > never decide if [1..] or [2..] comes next. > > > > However Ord a => YOrd [a] can be made to work, and that is absolutely > awesome, esp. once you start thinking about things like Ord a => YOrd > (InfiniteTree a). This really is very cool, Krzysztof. > > > > Stephen > > > > > > 2008/3/20 Krzysztof Skrz?tnicki : > > > > > > > > > > > > > > Hello everyone, > > > > > > I'm working on a small module for comparing things incomparable with > Ord. > > > More precisely I want to be able to compare equal infinite lists like > [1..]. > > > Obviously > > > > > > (1) compare [1..] [1..] = _|_ > > > > > > It is perfectly reasonable for Ord to behave this way. > > > Hovever, it doesn't have to be just this way. Consider this class > > > > > > class YOrd a where > > > ycmp :: a -> a -> (a,a) > > > > > > In a way, it tells a limited version of ordering, since there is no > > > way to get `==` out of this. > > > Still it can be useful when Ord fails. Consider this code: > > > > > > (2) sort [ [1..], [2..], [3..] ] > > > > > > It is ok, because compare can decide between any elements in finite > time. > > > However, this one > > > > > > (3) sort [ [1..], [1..] ] > > > > > > will fail because of (1). Compare is simply unable to tell that two > > > infinite list are equivalent. > > > I solved this by producing partial results while comparing lists. If > > > we compare lists > > > (1:xs) > > > (1:ys) > > > we may not be able to tell xs < ys, but we do can tell that 1 will be > > > the first element of both of smaller and greater one. > > > You can see this idea in the code below. > > > > > > > > > --- cut here --- > > > > > > {-# OPTIONS_GHC -O2 #-} > > > > > > module Data.YOrd where > > > > > > -- Well defined where Eq means equality, not only equivalence > > > > > > class YOrd a where > > > ycmp :: a -> a -> (a,a) > > > > > > > > > instance (YOrd a) => YOrd [a] where > > > ycmp [] [] = ([],[]) > > > ycmp xs [] = ([],xs) > > > ycmp [] xs = ([],xs) > > > ycmp xs'@(x:xs) ys'@(y:ys) = let (sm,gt) = x `ycmp` y in > > > let (smS,gtS) = xs `ycmp` ys in > > > (sm:smS, gt:gtS) > > > > > > > > > ycmpWrap x y = case x `compare` y of > > > LT -> (x,y) > > > GT -> (y,x) > > > EQ -> (x,y) -- biased - but we have to make our minds! > > > > > > -- ugly, see the problem below > > > instance YOrd Int where > > > ycmp = ycmpWrap > > > instance YOrd Char where > > > ycmp = ycmpWrap > > > instance YOrd Integer where > > > ycmp = ycmpWrap > > > > > > > > > -- ysort : sort of mergesort > > > > > > ysort :: (YOrd a) => [a] -> [a] > > > > > > ysort = head . mergeAll . wrap > > > > > > wrap :: [a] -> [[a]] > > > wrap xs = map (:[]) xs > > > > > > > > > mergeAll :: (YOrd a) => [[a]] -> [[a]] > > > mergeAll [] = [] > > > mergeAll [x] = [x] > > > mergeAll (a:b:rest) = mergeAll ((merge a b) : (mergeAll rest)) > > > > > > > > > merge :: (YOrd a) => [a] -> [a] -> [a] > > > merge [] [] = [] > > > merge xs [] = xs > > > merge [] xs = xs > > > merge (x:xs) (y:ys) = let (sm,gt) = x `ycmp` y in > > > sm : (merge [gt] $ merge xs ys) > > > > > > --- cut here --- > > > > > > I'd like to write the following code: > > > > > > instance (Ord a) => YOrd a where > > > ycmp x y = case x `compare` y of > > > LT -> (x,y) > > > GT -> (y,x) > > > EQ -> (x,y) > > > > > > > > > But i get an error "Undecidable instances" for any type [a]. > > > Does anyone know the way to solve this? > > > > > > > > > Best regards > > > > > > Christopher Skrz?tnicki > > > > > > _______________________________________________ > > > Haskell-Cafe mailing list > > > Haskell-Cafe@haskell.org > > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > > > > > > > > > From list at phaedrusdeinus.org Sun Mar 23 11:57:45 2008 From: list at phaedrusdeinus.org (John Melesky) Date: Sun Mar 23 11:54:25 2008 Subject: [Haskell-cafe] ANN (2 Libs) -- hvac 0.1b, a lightweight web framework and HStringTemplate 0.3 In-Reply-To: References: Message-ID: <92D7BD6C-3B31-4FCD-AE46-377B42AC4761@phaedrusdeinus.org> On Mar 23, 2008, at 1:21 AM, Sterling Clover wrote: > 1) hvac 0.1b: transactional, declarative framework for lightweight > web applications. > 2) HStringTemplate 0.3 Excellent! Thanks for these. -johnnnnnnn From marco-oweber at gmx.de Sun Mar 23 13:09:06 2008 From: marco-oweber at gmx.de (Marc Weber) Date: Sun Mar 23 13:05:35 2008 Subject: [Haskell-cafe] "doctest" for haskell -- a good project? In-Reply-To: <04bd01c88be4$d998c010$7000a8c0@INTERLINK> References: <04bd01c88be4$d998c010$7000a8c0@INTERLINK> Message-ID: <20080323170906.GA18248@gmx.de> Hi Shaun, I've read the whole thread till now. If you only look at the testing side Cabal is a possible target to run your tests. (I think you've already met it?) Adding documentation ficilities to ghci is nice, however my experience is that documentation is not complete everywhere. That's why I'm looking at source code directly (thus having doc strings if given else I can have look at source directly). One quick way to find the source location is using hasktags (comes with ghc). It's still some work to create tags for each package (that's why I've automated it within the nix distribution system). If you're interested send me a mail or contact me at #haskell. Marc W. From trebla at vex.net Sun Mar 23 13:53:55 2008 From: trebla at vex.net (Albert Y. C. Lai) Date: Sun Mar 23 13:50:24 2008 Subject: [Haskell-cafe] HXT and types in Control.Arrow.ArrowTree In-Reply-To: References: Message-ID: <47E69933.7040002@vex.net> Robert Vollmert wrote: > In short, I'm constantly running into what appear to be artificial type > restrictions in Control.Arrow.ArrowTree. For example, the signature of > "deep" is > > deep :: (Tree t, ArrowTree a) => a (t b) (t b) -> a (t b) (t b) > > instead of the more general > > deep :: (Tree t, ArrowTree a) => a (t b) c -> a (t b) c You are right, there is no harm generalizing deep, since a related combinator, multi, has the more general type. Meanwhile, I don't think > deep (hasName "a") >>> getLink looks too bad. :) Under suitable assumptions, you can use multi getLink if you want. From matthew.pocock at ncl.ac.uk Sun Mar 23 14:56:00 2008 From: matthew.pocock at ncl.ac.uk (Matthew Pocock) Date: Sun Mar 23 14:52:29 2008 Subject: [Haskell-cafe] hoisting as well as lifting and returning Message-ID: <200803231856.00532.matthew.pocock@ncl.ac.uk> Hi, Happy Easter! I've been using monad transformers for the first time in anger this week. They certainly do the job. However, there's an operation that I keep defining over and over again. It is sort of like lift and return in that it's glue to get operations and values into the monad from outside it. Here are two examples. hoistList :: (Monad m) => [a] -> ListT m a hoistList = foldr (mplus . return) mzero hoistMaybe :: (Monad m) => Maybe a -> MaybeT m a hoistMaybe = maybe mzero return The general idea is that you have some legacy, non-transform operation in some monad MonadFoo, and you are writing an operation in MonadFooT. You want to get the monadFoo value into MonadFooT. So, you say something like: do vInMFT <- hoist vInMF Is this a common enough operation on a monad transformer and it's 'raw' monad to warrant a class of its own? I have 'hoist' methods for several monad transformers, including RamdomMonadT, although I've probably defined them in ways that are overly eager or eat stack/heap, so I'd prefer knowledgable people to write them :) There must be other operations that link the base monad with its transformed version, other than 'hoist' - the runFooT method for example. Perhaps 'hoist' already exists and I'm re-inventing the wheel? Matthew From arnarbi at gmail.com Sun Mar 23 15:33:40 2008 From: arnarbi at gmail.com (Arnar Birgisson) Date: Sun Mar 23 15:30:08 2008 Subject: [Haskell-cafe] "doctest" for haskell -- a good project? In-Reply-To: <20080323170906.GA18248@gmx.de> References: <04bd01c88be4$d998c010$7000a8c0@INTERLINK> <20080323170906.GA18248@gmx.de> Message-ID: <28012bc60803231233p4df21ed6q2ab7137e5517964a@mail.gmail.com> On Sun, Mar 23, 2008 at 5:09 PM, Marc Weber wrote: > Adding documentation ficilities to ghci is nice, > however my experience is that documentation is not complete everywhere. > That's why I'm looking at source code directly (thus having doc strings if given > else I can have look at source directly). This reminds me of a very handy feature in ipython (a custom python repl) - you can type name? which prints the docstring associated with name (which can be a function, module, class etc.) - but if you type name?? you get the docstring _and_ the source code (colorized and all :). I use it a lot when I'm experimenting in a interactive session. I could see something similar for haskell being very useful, to me at least. Arnar From gale at sefer.org Sun Mar 23 16:27:44 2008 From: gale at sefer.org (Yitzchak Gale) Date: Sun Mar 23 16:24:14 2008 Subject: [Haskell-cafe] hoisting as well as lifting and returning In-Reply-To: <200803231856.00532.matthew.pocock@ncl.ac.uk> References: <200803231856.00532.matthew.pocock@ncl.ac.uk> Message-ID: <2608b8a80803231327k3af4bf34qb6867353678c7a11@mail.gmail.com> Matthew Pocock wrote: > I've been using monad transformers for the first time in anger this week. I hope your enjoyment in using monads has helped your anger to subside. :) > ...there's an operation that I keep defining over > and over again... > hoistList :: (Monad m) => [a] -> ListT m a > hoistMaybe :: (Monad m) => Maybe a -> MaybeT m a > do vInMFT <- hoist vInMF > Perhaps 'hoist' already exists and I'm re-inventing the wheel? You are correct. This is a fundamental operation. It exists for just about every monad, but in a haphazard and inconsistent way. In my opinion, its type needs to be more polymorphic in a slightly different direction than what you are suggesting. Here's a sampling of what we have now: State :: (s -> (a, s)) -> State s a StateT . return :: Monad m => (s -> (a, s)) -> StateT s m a liftList :: Monad m => [a] -> ListT m a -- ListT_Done_Right ErrorT . return :: Monad m => Either e a -> ErrorT e a You get the picture. Yes, it's a bit of a mess. A general "hoist" function that would work for disparate kinds of monads would require yet an additional parameter to the MonadFoo class for each monad. Or an additional MonadHoist type class. (Or whatever the corresponding additional complexity will be when we move to associated types.) This would be needed to specify what the "underlying structure" is that needs to be hoisted from. I'm not sure that kind of polymorphism would be worth the additional complexity - unless someone can suggest a more beautiful way to capture this generality. Otherwise, I think it would be enough to have a "hoist" function for each monad, based on the name of the monad. What I do sorely feel the need for is a "hoist" for each pair of base/transformer monads: i.e., polymorphic monad constructors. So, for example, if we had mkState :: (st -> (a, st)) -> m a as a member of the MonadState st m class, then it would be so much easier to write functions f :: MonadState st m => ... that could be used without having to refactor it every time the monad stack changes. In general, each monad Foo would have a MonadFoo class (even the monads that don't have one yet) containing (at least) a mkFoo method that lifts the "underlying structure" polymorphically either to Foo or to FooT. btw, a variation on this is to provide only a "hoist" or "mkFoo" for the transformer version of the monad, and then use only transformers, basing every monad stack at the Identity monad. This is what Iavor Diatchki does in his monadlib library. I don't particularly like that approach, though. In the most common simple case, I like being able to specify whether my monad is a transformer or not. Regards, Yitz From quuxman at gmail.com Sun Mar 23 17:24:03 2008 From: quuxman at gmail.com (ac) Date: Sun Mar 23 17:20:33 2008 Subject: [Haskell-cafe] Type checking of partial programs In-Reply-To: References: <47E2CADB.50008@di.unipi.it> Message-ID: So a number of people responded with various ways this is already possible. Of course GHC can already do this... it's type inference. The part I'm interested in working on is exposing the functionality in GHC's API to make this as easy as possible. -Abram -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080323/c4b752bd/attachment.htm From matthew.pocock at ncl.ac.uk Sun Mar 23 17:46:57 2008 From: matthew.pocock at ncl.ac.uk (Matthew Pocock) Date: Sun Mar 23 17:43:25 2008 Subject: [Haskell-cafe] hoisting as well as lifting and returning In-Reply-To: <2608b8a80803231327k3af4bf34qb6867353678c7a11@mail.gmail.com> References: <200803231856.00532.matthew.pocock@ncl.ac.uk> <2608b8a80803231327k3af4bf34qb6867353678c7a11@mail.gmail.com> Message-ID: <200803232146.57386.matthew.pocock@ncl.ac.uk> Hi Yitz, I was thinking along the lines of a class linking the monad transformer with the base monad: class (MonadTrans mt, Monad b) => MonadTForm mt b | mt -> b where hoist :: (Monad m) => b a -> mt m a This is to restrict it directly between the base monad and the transformed version. If you wish to 'adapt' any other pair of monads, then I think that's another operation, just as lift is a different operation to hoist. Matthew On Sunday 23 March 2008, Yitzchak Gale wrote: > You are correct. This is a fundamental operation. It exists > for just about every monad, but in a haphazard and > inconsistent way. In my opinion, its type needs to be > more polymorphic in a slightly different direction than what > you are suggesting. ... > What I do sorely feel the need for is a "hoist" for each pair > of base/transformer monads: i.e., polymorphic monad > constructors. > > So, for example, if we had > > mkState :: (st -> (a, st)) -> m a > > as a member of the MonadState st m class, > then it would be so much easier to write functions > > f :: MonadState st m => ... > > that could be used without having to refactor it every time > the monad stack changes. In general, each monad > Foo would have a MonadFoo class (even the monads > that don't have one yet) containing (at least) a mkFoo > method that lifts the "underlying structure" polymorphically > either to Foo or to FooT. ... > Regards, > Yitz From hjgtuyl at chello.nl Sun Mar 23 18:36:41 2008 From: hjgtuyl at chello.nl (hjgtuyl@chello.nl) Date: Sun Mar 23 18:33:22 2008 Subject: [Haskell-cafe] Terminating GLUT/GLFW programs Message-ID: L.S., I am trying GLUT and GLFW (on Windows XP, with GHC 6.8.2); the sample programs do not terminate when I close the window by clicking on the cross in the upper right corner of the window. The sample program for GLUT is at http://blog.mikael.johanssons.org/archive/2006/09/opengl-programming-in-haskell-a-tutorial-part-1/ the GLFW program: http://haskell.org/haskellwiki/GLFW I tried in the GLUT program: close = exitWith ExitSuccess closeCallback $= Just close -- => User error (unknown GLUT call getCloseFunc, check for freeglut) this needs freeglut (not documented); I downloaded freeglut.dll and placed it in the windows\system32 directory. The error message remained. What is needed to let these programs terminate properly? -- Met vriendelijke groet, Henk-Jan van Tuyl -- http://functor.bamikanarie.com http://Van.Tuyl.eu/ -- From vigalchin at gmail.com Sun Mar 23 22:44:18 2008 From: vigalchin at gmail.com (Galchin Vasili) Date: Sun Mar 23 22:40:52 2008 Subject: [Haskell-cafe] more on FFI build error Message-ID: <5ae4f2ba0803231944q30a1434cg2aafd84b149f2dcc@mail.gmail.com> line #102 ... allocaBytes (#const sizeof(struct mq_attr)) $ \ p_attrs -> do definition of struct mq_attr on Linux ... struct mq_attr { long int mq_flags; /* Message queue flags. */ long int mq_maxmsg; /* Maximum number of messages. */ long int mq_msgsize; /* Maximum message size. */ long int mq_curmsgs; /* Number of messages currently queued. */ long int __pad[4]; }; build errors received .... vigalchin@ubuntu:~/FTP/Haskell/unix-2.2.0.0$ runhaskell Setup.hs build Preprocessing library unix-2.2.0.0... MQueue.hsc: In function 'main': MQueue.hsc:102:0: error: invalid application of 'sizeof' to incomplete type 'struct mq_attr' MQueue.hsc:102:0: error: invalid application of 'sizeof' to incomplete type 'struct mq_attr' MQueue.hsc:102:0: error: invalid application of 'sizeof' to incomplete type 'struct mq_attr' compiling dist/build/System/Posix/MQueue_hsc_make.c failed comma ??? Kind regards, vasili -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080323/159662a3/attachment.htm From chak at cse.unsw.edu.au Mon Mar 24 00:14:09 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Mon Mar 24 00:11:01 2008 Subject: [Haskell-cafe] Equality constraints in type families In-Reply-To: <00bf01c889e1$b34639b0$b9387ad5@cr3lt> References: <7b92c2840803101651x3673691eid310ab137805eeff@mail.gmail.com> <00bf01c889e1$b34639b0$b9387ad5@cr3lt> Message-ID: <2240735C-74CC-4F5F-8B38-3402C0C278FF@cse.unsw.edu.au> Claus Reinke: >>> type family F a :: * -> * > .. >> We made the design choice that type functions with a higher-kinded >> result type must be injective with respect to the additional >> paramters. I.e. in your case: >> F x y ~ F u v <=> F x ~ F u /\ y ~ v > > i'm still trying to understand this remark: > > - if we are talking about "type functions", i should be allowed > to replace a function application with its result, and if that > result doesn't mention some parameters, they shouldn't > play a role at any stage, right? > > - if anything other than the function result matters, isn't it > somewhat misleading to speak of "type functions"? You will notice that I avoid calling them "type functions". In fact, the official term is "type families". That is what they are called in the spec and GHC's option is -XTypeFamilies, too. More precisely, they are "type-indexed type families". One difference between type families and (value-level) functions is that not all parameters of a type family are treated the same. A type family has a fixed number of type indicies. We call the number of type indicies the type family's arity and by convention, the type indicies come always before other type parameters. In the example type family F a :: * -> * F has arity 1, whereas type family G a b :: * has arity 2. So, the number of named parameters given is the arity. (The overall kind is still F :: * -> * -> *; ie, the arity is not obvious from the kind, which I am somewhat unhappy about.) In other words, in a type term like (F Int Bool), the two parameters Int and Bool are treated differently. Int is treated like a parameter to a function (which is what you where expecting), whereas Bool is treated like a parameter to a vanilla data constructor (the part you did not expect). To highlight this distinction, we call only Int a type index. Generally, if a type family F has arity n, it's first n parameters are type indicies, the rest are treated like the parameters of any other type constructor. Moreover, a type family of arity n, must always be applied to at least n parameters - ie, applications to type indicies cannot be partial. This is not just an arbitrary design decision, it is necessary to stay compatible with Haskell's existing notion of higher-kinded unification (see, Mark Jones' paper about constructor classes), while keeping the type system sound. To see why, consider that Haskell's higher-kinded type system, allows type terms, such as (c a), here c may be instantiated to be (F Int) or Maybe. This is only sound if F treats parameters beyond its arity like any other type constructor. A more formal discussion is in our TLDI paper about System F_C(X). Manuel From chak at cse.unsw.edu.au Mon Mar 24 00:16:28 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Mon Mar 24 00:13:04 2008 Subject: [Haskell-cafe] Equality constraints in type families In-Reply-To: References: <7b92c2840803101651x3673691eid310ab137805eeff@mail.gmail.com> <00bf01c889e1$b34639b0$b9387ad5@cr3lt> Message-ID: Tom Schrijvers: >> could you please help me to clear up this confusion?-) > > Let me summarize :-) > > The current design for type functions with result kinds other than * > (e.g. * -> *) has not gotten very far yet. We are currently > stabilizing the ordinary * type functions, and writing the story up. > When that's done we can properly focus on this issue and consider > different design choices. I don't quite agree. The current story was pretty much settled in the paper on associated type synonyms already and further clarified in the FC paper. Manuel From chak at cse.unsw.edu.au Mon Mar 24 00:18:25 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Mon Mar 24 00:15:03 2008 Subject: [Haskell-cafe] Equality constraints in type families In-Reply-To: <00cf01c889e6$06ae9fd0$b9387ad5@cr3lt> References: <7b92c2840803101651x3673691eid310ab137805eeff@mail.gmail.com> <00bf01c889e1$b34639b0$b9387ad5@cr3lt> <00cf01c889e6$06ae9fd0$b9387ad5@cr3lt> Message-ID: Claus Reinke: >>>> type family F a :: * -> * >> .. >>> We made the design choice that type functions with a higher-kinded >>> result type must be injective with respect to the additional >>> paramters. I.e. in your case: >>> F x y ~ F u v <=> F x ~ F u /\ y ~ v > > actually, i don't even understand the first part of that:-( > > why would F x and F u have to be the same functions? > shouldn't it be sufficient for them to have the same result, > when applied to y and v, respectively? Oh, yes, that is sufficient and exactly what is meant by F x ~ F u. It means, the two can be unified modulo any type instances and local given equalities. Manuel From dekudekuplex at yahoo.com Mon Mar 24 02:01:39 2008 From: dekudekuplex at yahoo.com (Benjamin L. Russell) Date: Mon Mar 24 01:58:05 2008 Subject: [Haskell-cafe] Any ideas for "->" (function type) in a simply-typed lambda calculus version of Brett Victor's Alligator Eggs game? In-Reply-To: Message-ID: <858949.71351.qm@web30201.mail.mud.yahoo.com> I like your idea of joining alligator tails to represent the connective, but just came up with a different idea about representing types. The difficulty with using alligator sizes to represent types is that deciding how to represent relationships between types could pose a problem. For example, suppose I have a function lengthOfAddedList, which takes a Char and a list, and returns the length of the list with the Char prepended: lengthOfAddedList.hs: lengthOfAddedList :: Char -> [Char] -> Int lengthOfAddedList c cs = length([c]++cs) If we represent types as sizes, then, we can have, say, Char having a smallest size, [Char] having a size one size larger than Char, and Int having a size one size still larger than [Char]. But then, how do we represent the difference in relationships between the Char and [Char], and the [Char] and Int? A [Char] is a list of Chars, but an Int is an unrelated type. Further, suppose we have the following function: lengthOfAddedListWithBool.hs: lengthOfAddedListWithBool :: Bool -> [Bool] -> Int lengthOfAddedListWithBool b bs = length([b]++bs) How do I decide whether Char or Bool has a larger alligator size, and how do I motivate this decision? Again, it is not clear. Therefore, I propose that types be represented by patterns (as it stripes vs. dots vs. a checkered pattern, etc.) instead of sizes. I.e., the Char type can be represented by a striped pattern on an alligator, the Bool type can be represented by a striped pattern, and so on. Then, we can establish the rule that putting a type in a list is represented by putting that pattern in bold on the alligator, so we can have lengthOfAddedList :: Char -> [Char] -> Int be represented by an alligator with a striped pattern tying its tail to an alligator with a bold striped pattern tying its tail to an alligator with, say, dots (assuming dots represent the Int type), and we can have lengthOfAddedListWithBool :: Bool -> [Bool] -> Int be represented by an alligator with a checkered pattern tying its tail to an alligator with a bold checkered pattern tying its tail to an alligator with dots. Patterns would seem to allow more freedom of expression in denoting relationships between types (say, a type of a list of Chars to a type of a Char) than sizes. There are probably even better ways of representing relationships between types on alligators. This seems a good start; what do you think? Benjamin L. Russell --- Justin Bailey wrote: > On Wed, Mar 19, 2008 at 12:48 AM, Benjamin L. > Russell > wrote: > > However, in thinking about how to adapt the game, > I am > > not quite sure how to incorporate the > representation > > of "->" (function type): > > > > * ???: "->" (function type) > > > > What ideas, if any, would anybody have on how > "->" > > (function type) could be represented in a > simply-typed > > lambda calculus version of Brett Victor's > Alligator > > Eggs? > > Since color is already taken, how about representing > types as skinny > and fat alligators? Functions can then be > represented by alligators > with their tails joined together. For example, Nat > -> Bool would be > represented as a skinny alligator joined to a fat > alligator. A skinny > alligator will only eat anotehr skinny alligator, > and then goes to > take a nap (i.e. disappears). That leaves the fat > alligator (bool). > Just a sketch but maybe it will help you out! > > Justin > From wnoise at ofb.net Mon Mar 24 02:29:26 2008 From: wnoise at ofb.net (Aaron Denney) Date: Mon Mar 24 02:26:08 2008 Subject: [Haskell-cafe] Re: more on FFI build error References: <5ae4f2ba0803231944q30a1434cg2aafd84b149f2dcc@mail.gmail.com> Message-ID: On 2008-03-24, Galchin Vasili wrote: > vigalchin@ubuntu:~/FTP/Haskell/unix-2.2.0.0$ runhaskell Setup.hs build > Preprocessing library unix-2.2.0.0... > MQueue.hsc: In function 'main': > > MQueue.hsc:102:0: > error: invalid application of 'sizeof' to incomplete type 'struct > mq_attr' > > MQueue.hsc:102:0: > error: invalid application of 'sizeof' to incomplete type 'struct > mq_attr' > > MQueue.hsc:102:0: > error: invalid application of 'sizeof' to incomplete type 'struct > mq_attr' > compiling dist/build/System/Posix/MQueue_hsc_make.c failed > comma This looks as if only a "struct mq_attr;" definition is found, which lets opaque types be defined in C -- only pointers to it may be allocated by the compiler, not the actual struct, nor can sizeof be taken. Does your system have both /usr/include/mqueue.h and /usr/include/bits/mqueue.h -- Aaron Denney -><- From wangqj at cpit.com.cn Mon Mar 24 02:31:45 2008 From: wangqj at cpit.com.cn (=?gb2312?B?zfXH5b78?=) Date: Mon Mar 24 02:28:18 2008 Subject: [Haskell-cafe] unsubscript In-Reply-To: References: <5ae4f2ba0803231944q30a1434cg2aafd84b149f2dcc@mail.gmail.com> Message-ID: <72175B41EA4E294A8B547CD900865561227676@ptmail.putian.com> unsubscript Powered by MessageSoft SMG=20 SPAM, virus-free and secure email From ryani.spam at gmail.com Mon Mar 24 03:11:15 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Mon Mar 24 03:07:41 2008 Subject: [Haskell-cafe] Gtk2hs on GHC6.8.2? Message-ID: <2f9b2d30803240011k1597d9e2sd0d1b7466120a8c0@mail.gmail.com> The WinXP binary release of Gtk2hs won't install for me; it seems to expect GHC6.8.1 and refuses to install on 6.8.2. Is there any significant difference in the compilers that would cause it not to work on 6.8.2? Is there a way I can trick it into installing? I really don't want to have to build from source. I've had nothing but trouble trying to get large projects to build within cygwin/mingw/msys. -- ryan From dons at galois.com Mon Mar 24 03:12:27 2008 From: dons at galois.com (Don Stewart) Date: Mon Mar 24 03:08:56 2008 Subject: [Haskell-cafe] Re: Libraries need a new owner In-Reply-To: <47497409.6050601@iee.org> References: <47497409.6050601@iee.org> Message-ID: <20080324071227.GA9750@scytale.galois.com> ahey: > Hello Folks, > > As some of you will be aware, I have been working on various Map > implementations that currently live here.. > > http://code.haskell.org/collections/collections-ghc6.8 > > The libs in question being Data.Tree.AVL, Data.Trie.General and a few > other bits like Data.COrdering and the AVL based Data.Map/Set clones. > > Well, I have decided to stop work on these. So they need a new owner if > they're going to go anywhere. If anyone is interested in the job then I > suggest they contact myself or Jean-Philippe Bernardy. > > Of course I will be happy to provide any help or advise anyone who takes > over these libs may feel they need from me. I might even contribute a > few patches from time to time myself :-) > > Thanks How about we propose this work be done for Summer of Code. I've created a ticket here: http://hackage.haskell.org/trac/summer-of-code/ticket/1549 Add comments, or if you can mentor, add that information too! Let's get a new faster Data.Map and other containers ready to go by the end of the northern summer? -- Don From bf3 at telenet.be Mon Mar 24 03:58:05 2008 From: bf3 at telenet.be (Peter Verswyvelen) Date: Mon Mar 24 03:54:40 2008 Subject: [Haskell-cafe] Terminating GLUT/GLFW programs In-Reply-To: References: Message-ID: <47E75F0D.4090500@telenet.be> Hi, I had a similar (unsolved) problem with GLUT but on my system (Windows XP + GHC 6.8.2) GLFW works fine, exiting is no problem at all. But when building GLFW, make sure that the GHC gcc-lib directory comes *before* the MinGW/Cygwin directory in your PATH environment variable, since when linking, the LD.EXE bundled with GHC *must* be used. Cheers, Peter hjgtuyl@chello.nl wrote: > > L.S., > > I am trying GLUT and GLFW (on Windows XP, with GHC 6.8.2); the sample > programs do not terminate when I close the window by clicking on the > cross in the upper right corner of the window. > > The sample program for GLUT is at > > http://blog.mikael.johanssons.org/archive/2006/09/opengl-programming-in-haskell-a-tutorial-part-1/ > > the GLFW program: > http://haskell.org/haskellwiki/GLFW > > I tried in the GLUT program: > close = exitWith ExitSuccess > > closeCallback $= Just close -- => User error (unknown GLUT call > getCloseFunc, check for freeglut) > > this needs freeglut (not documented); I downloaded freeglut.dll and > placed it in the windows\system32 directory. The error message remained. > > What is needed to let these programs terminate properly? > From jason.dusek at gmail.com Mon Mar 24 04:31:10 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Mon Mar 24 04:27:37 2008 Subject: [Haskell-cafe] Re: HFuse: ls fails in HelloFS In-Reply-To: <27BB7C4F-8221-4146-B1BB-C39A0A4ECF46@ece.cmu.edu> References: <1205550042-sup-1361@continuum> <47DD227C.208@willthompson.co.uk> <1205906992-sup-8266@continuum> <20080319195603.GB281687@localhost> <27BB7C4F-8221-4146-B1BB-C39A0A4ECF46@ece.cmu.edu> Message-ID: <42784f260803240131w76b3382fw71c9f91be3e795ae@mail.gmail.com> What about System.FUSE then? -- _jsn From matthew.pocock at ncl.ac.uk Mon Mar 24 06:47:48 2008 From: matthew.pocock at ncl.ac.uk (Matthew Pocock) Date: Mon Mar 24 06:44:13 2008 Subject: [Haskell-cafe] Re: Libraries need a new owner In-Reply-To: <20080324071227.GA9750@scytale.galois.com> References: <47497409.6050601@iee.org> <20080324071227.GA9750@scytale.galois.com> Message-ID: <200803241047.49217.matthew.pocock@ncl.ac.uk> On Monday 24 March 2008, Don Stewart wrote: > Let's get a new faster Data.Map and other containers ready to go by the > end of the northern summer? And while we are visiting this, can I put in a vote for a seperation between the default Data.* container concrete implementations and associated classes? E.g. between the cannonical Map implementation and a Map class that could (if I felt mad) be backed by a list, or (if I was more sane) the cannonical Map datatype? This would go /at least/ for Map, Set, List. Matthew > > -- Don > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From Anurag.Verma at motorola.com Mon Mar 24 07:40:18 2008 From: Anurag.Verma at motorola.com (Verma Anurag-VNF673) Date: Mon Mar 24 07:39:32 2008 Subject: [Haskell-cafe] RE: How to implement Read instance for user defined type Message-ID: That works, but is probably not what you want. You can use the lex function to parse identifiers not enclosed in quotes: > instance Read Mark where > readsPrec _ str = [(Mark x, t') | ("mark",t) <- lex str, > (x,t') <- reads t I played a bit around with lex function and it seems that under certain circumstances it doesn't read the string of token properly For e.g. -- IP address *Mark> lex "192.168.0.1" [("192.168",".0.1")] -- digit + char Also lex "8021p" output is *Mark> lex "8021p" [("8021","p")] Is there any other lex variant available? Or should I switch to using Parsec library, in that case, will I still be able to use it with Read instances? If so, how? Anurag -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080324/e66a24ff/attachment.htm From claus.reinke at talk21.com Mon Mar 24 07:45:06 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Mon Mar 24 07:41:39 2008 Subject: [Haskell-cafe] Equality constraints in type families References: <7b92c2840803101651x3673691eid310ab137805eeff@mail.gmail.com><00bf01c889e1$b34639b0$b9387ad5@cr3lt> <2240735C-74CC-4F5F-8B38-3402C0C278FF@cse.unsw.edu.au> Message-ID: <004b01c88da4$843f6800$ee3d8351@cr3lt> >>>> type family F a :: * -> * >>> F x y ~ F u v <=> F x ~ F u /\ y ~ v >> > words, in a type term like (F Int Bool), the two parameters Int and > Bool are treated differently. Int is treated like a parameter to a > function (which is what you where expecting), whereas Bool is treated > like a parameter to a vanilla data constructor (the part you did not > expect). To highlight this distinction, we call only Int a type > index. Generally, if a type family F has arity n, it's first n > parameters are type indicies, the rest are treated like the parameters > of any other type constructor. i'm not sure haskell offers the kind of distinction that we need to talk about this: 'data constructor' is value-level, 'type constructor' doesn't distinguish between type- vs data-defined type constructors. i think i know what you mean, but it confuses me that you use 'data constructor' (should be data/newtype-defined type constructor?) and 'type constructor' (don't you want to exclude type-defined type constructors here). data ConstD x y = ConstD x type ConstT x y = x 'ConstD x' and 'ConstT x' have the same kind, that of type constructors: * -> *. but: ConstD x y1 ~ ConstD x y2 => y1 ~ y2 whereas forall y1, y2: ConstT x y1 ~ ConstT x y2 and i thought 'type family' was meant to suggest type synonym families, in contrast to 'data family'? you did notice that i gave an example of how ghc does not seem to follow that decomposition rule, didn't you? ghc seems to behave almost as i would expect, not as the decomposition rule seems to suggest. still confused, claus From claus.reinke at talk21.com Mon Mar 24 07:55:30 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Mon Mar 24 07:52:00 2008 Subject: [Haskell-cafe] Equality constraints in type families References: <7b92c2840803101651x3673691eid310ab137805eeff@mail.gmail.com><00bf01c889e1$b34639b0$b9387ad5@cr3lt><00cf01c889e6$06ae9fd0$b9387ad5@cr3lt> Message-ID: <004d01c88da5$f744a350$ee3d8351@cr3lt> >>>>> type family F a :: * -> * >>>> F x y ~ F u v <=> F x ~ F u /\ y ~ v >> >> why would F x and F u have to be the same functions? >> shouldn't it be sufficient for them to have the same result, >> when applied to y and v, respectively? > > Oh, yes, that is sufficient and exactly what is meant by F x ~ F u. > It means, the two can be unified modulo any type instances and local > given equalities. sorry, i don't understand how that could be meant by 'F x ~ F u'; that equality doesn't even refer to any specific point on which these two need to be equal, so it can only be a point-free higher-order equality, can't it? the right-to-left implication is obvious, but the left-to-right implication seems to say that, for 'F x' and 'F u' to be equal on any concrete pair of types 'y' and 'u', they have to be equal on all possible types and 'y' and 'u' themselves have to be equal. again, i gave a concrete example of how ghc behaves as i would expect, not as that decomposition rule would suggest. i'll try to re-read the other paper you suggested, but it would help me if you could discuss the two concrete examples i gave in this thread. thanks, claus From duncan.coutts at worc.ox.ac.uk Mon Mar 24 08:25:14 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Mar 24 08:21:41 2008 Subject: [Haskell-cafe] Gtk2hs on GHC6.8.2? In-Reply-To: <2f9b2d30803240011k1597d9e2sd0d1b7466120a8c0@mail.gmail.com> Message-ID: <20080324122514.A0708B80AC@webmail223.herald.ox.ac.uk> In message <2f9b2d30803240011k1597d9e2sd0d1b7466120a8c0@mail.gmail.com> "Ryan Ingram" writes: > The WinXP binary release of Gtk2hs won't install for me; it seems to > expect GHC6.8.1 and refuses to install on 6.8.2. Right. It does that on purpose and with good reason. Do you think the error message could be improved? The message should already say that it detected ghc 6.8.2 but that it requires ghc 6.8.1 (or 6.6.1). > Is there any significant difference in the compilers that would cause it not > to work on 6.8.2? Yes. The .hi files are versioned and ghc will reject .hi files created by a different version of ghc. > Is there a way I can trick it into installing? You could probably trick the installer but it would not help you at all, as all you'll get is ghc reporting that the .hi files were written by ghc-6.8.1 rather than ghc-6.8.2. You are in luck however, I did a build with ghc-6.8.2 just the other day but hadn't announced it yet: http://haskell.org/~duncan/gtk2hs/gtk2hs-0.9.12.1.exe Let me know how you get on, though in general bugs are best reported to the gtk2hs-devel mailing list or in our bug tracker. Duncan From claudiusmaximus at goto10.org Mon Mar 24 09:12:34 2008 From: claudiusmaximus at goto10.org (Claude Heiland-Allen) Date: Mon Mar 24 09:05:59 2008 Subject: [Haskell-cafe] more on FFI build error In-Reply-To: <5ae4f2ba0803231944q30a1434cg2aafd84b149f2dcc@mail.gmail.com> References: <5ae4f2ba0803231944q30a1434cg2aafd84b149f2dcc@mail.gmail.com> Message-ID: <47E7A8C2.7040801@goto10.org> Galchin Vasili wrote: > > line #102 ... > > allocaBytes (#const sizeof(struct mq_attr)) $ \ p_attrs -> do > > definition of struct mq_attr on Linux ... > > struct mq_attr > { > long int mq_flags; /* Message queue flags. */ > long int mq_maxmsg; /* Maximum number of messages. */ > long int mq_msgsize; /* Maximum message size. */ > long int mq_curmsgs; /* Number of messages currently queued. */ > long int __pad[4]; > }; Did you #include the header file that defines this struct? Claude -- http://claudiusmaximus.goto10.org From apfelmus at quantentunnel.de Mon Mar 24 11:36:05 2008 From: apfelmus at quantentunnel.de (apfelmus) Date: Mon Mar 24 11:32:46 2008 Subject: [Haskell-cafe] Re: deconstruction of the list/backtracking applicative functor? In-Reply-To: References: Message-ID: (Sorry for the late reply) Conal Elliott wrote: > Is there a known deconstruction of the list/backtracking applicative functor > (AF)? If I decompose the list type into pieces (Maybe, product, > composition), I think I can see where the ZipList AF comes from, but not the > list/backtracking AF. So, you mean that the strange thing about the list monad is that the "natural" applicative structure for [a] is derived from the "composition" [a] ~ Maybe (a, Maybe (a, ...)) ~ Maybe `O` (a,) `O` Maybe `O` (a,) `O` ... ? Well, this is not quite true since the applicativity you're seeking is in the extra argument a , not in the argument of the composition. In fact, this infinite composition doesn't have an argument (that's the whole point of taking the fixed point). In other words, every chain like Maybe `O` (a,) `O` Maybe `O` (a,) Maybe `O` (a,) `O` Maybe `O` (a,) `O` Maybe `O` (a,) etc. is an applicative functor in its argument, but not necessarily in a . So, there is more to the "natural" ZipList AF than Maybe, product and composition. > Is there some construction simpler than lists > (non-recursive) that introduces cross products? What do you mean with "cross products" here? Something with sequence :: Applicative f => [f a] -> f [a] being the cartesian product for the list monad? Or simpler pure (,) :: Applicative f => (f a, f b) -> f (a,b) somehow "crossing" the "elements" of f a and f b ? Regards, apfelmus From rvollmert-lists at gmx.net Mon Mar 24 11:55:45 2008 From: rvollmert-lists at gmx.net (Robert Vollmert) Date: Mon Mar 24 11:52:12 2008 Subject: [Haskell-cafe] HXT and types in Control.Arrow.ArrowTree In-Reply-To: <47E69933.7040002@vex.net> References: <47E69933.7040002@vex.net> Message-ID: <19FC7E4A-28E7-4C74-83F8-13F240462CBD@gmx.net> Hello, On Mar 23, 2008, at 18:53, Albert Y. C. Lai wrote: > > You are right, there is no harm generalizing deep, since a related > combinator, multi, has the more general type. thanks for the reply! Perhaps I'll suggest the generalization to the HXT authors. Meanwhile, I've discovered examples of just the kind of thing I'm trying to do at http://www.haskell.org/haskellwiki/HXT/Practical/ . > Meanwhile, I don't think > >> deep (hasName "a") >>> getLink > > looks too bad. :) That's true, it was a bad example. It's just that if getLink already includes the hasName test, the above seems redundant. Cheers Robert From matthew.pocock at ncl.ac.uk Mon Mar 24 12:08:20 2008 From: matthew.pocock at ncl.ac.uk (Matthew Pocock) Date: Mon Mar 24 12:04:42 2008 Subject: [Haskell-cafe] Random Monad Message-ID: <200803241608.20992.matthew.pocock@ncl.ac.uk> Hi, Who currently maintains the Random monad code? I have some patches to contribute. Matthew From dominic.steinitz at blueyonder.co.uk Mon Mar 24 12:31:24 2008 From: dominic.steinitz at blueyonder.co.uk (Dominic Steinitz) Date: Mon Mar 24 12:29:05 2008 Subject: [Haskell-cafe] Haddock Help Required Message-ID: <47E7D75C.8010406@blueyonder.co.uk> What should I be using for the file name for the read-interface option in haddock? Trying to use the file on www.haskell.org gives this: dom@lagrange:~/asn15/asn1> haddock -html -o hdoc Pretty.hs -B /usr/lib/ghc-6.8.2 --optghc="-fglasgow-exts" --read-interface=http://www.haskell.org/ghc/docs/latest/html/libraries/base,http://www.haskell.org/ghc/docs/latest/html/libraries/base/base.haddock haddock: internal Haddock or GHC error: http://www.haskell.org/ghc/docs/latest/html/libraries/base/base.haddock: openBinaryFile: does not exist (No such file or directory) But if I download the file and try and use it locally, I get this dom@lagrange:~/asn15/asn1> haddock -v -html -o hdoc Pretty.hs -B /usr/lib/ghc-6.8.2 --optghc="-fglasgow-exts" --read-interface=http://www.haskell.org/ghc/docs/latest/html/libraries/base,base.haddock Warning: Cannot read base.haddock: "Magic number mismatch: couldn't load interface file: base.haddock" Skipping this interface. Warning: main:Language.ASN1: could not find link destinations for: GHC.Enum.Enum GHC.Base.Eq GHC.Base.Ord GHC.Show.Show GHC.Num.Integer Language.ASN1.ComponentIndex Language.ASN1.Tagged GHC.Base.String Data.Maybe.Maybe Language.ASN1.Octet Data.Map.Map Warning: main:Pretty: could not find link destinations for: Text.PrettyPrint.HughesPJ.Doc Pretty.Pretty Pretty.PrettyVal Warning: main:ConstrainedType: could not find link destinations for: Data.Maybe.Maybe GHC.Base.Bool GHC.Num.Integer Pretty.Pretty Pretty.PrettyVal GHC.Base.String GHC.Base.Eq GHC.Show.Show GHC.Base.Int GHC.Word.Word8 GHC.Base.Ord Data.Monoid.Monoid Data.Binary.Strict.BitPut.BitPut GHC.Real.Integral Control.Monad.State.Class.MonadState Data.ByteString.Internal.ByteString Control.Monad.Error.Class.MonadError GHC.Base.Char Data.Binary.Strict.BitGet.BitGet Any help would be appreciated. Dominic. From qdunkan at gmail.com Mon Mar 24 13:44:36 2008 From: qdunkan at gmail.com (Evan Laforge) Date: Mon Mar 24 13:41:03 2008 Subject: [Haskell-cafe] ghc warn-unused-imports Message-ID: <2518b95d0803241044p369bcf23g7d15dca19a082d5a@mail.gmail.com> So it appears that GHC will warn about "unused" imports when you import qualified if you could have gotten the symbol from somewhere else. For instance, if you write: import qualified Control.Monad.Trans as Trans import qualified Control.Monad.Writer as Writer and use "Trans.lift", it will complain because you could have used "Writer.lift". Then if you go import State, it will want you to use State.liftIO instead of Trans.liftIO (Writer doesn't have liftIO). Now, one question is why these modules are exporting random stuff from Trans, but in general the practice of warning when you use qualified imports seems not only misleading (since if you comment out the import your code breaks, and it's not obvious where it wanted you to get the symbol), but brittle since a messy export list on some module you import can suddenly trigger a flood of warnings. So I'd suggest that if you say "import qualified M" and then use "M.something", then "M is unused" msgs shouldn't appear. warn-unused-imports is genuinely useful most of the time, so I don't like to put on -fno-warn-unused-imports. Is there a better way to suppress the "false positives" here? From conal at conal.net Mon Mar 24 15:27:06 2008 From: conal at conal.net (Conal Elliott) Date: Mon Mar 24 15:23:35 2008 Subject: [Haskell-cafe] Re: deconstruction of the list/backtracking applicative functor? In-Reply-To: References: Message-ID: Thanks for the reply. Here's the decomposition I had in mind. Start with type List a = Maybe (a, List a) Rewrite a bit type List a = Maybe (Id a, List a) Then make the type *constructor* pairing explicit type List a = Maybe ((Id :*: List) a) where newtype (f :*: g) a = Prod { unProd :: (f a, g a) } Then make the type-constructor composition explicit type List = Maybe :. (Id :*: List) (which isn't legal Haskell, due to the type synonym cycle). From there use the Functor and Applicative instances for composition and pairing of type constructors and for Id. I think the result is equivalent to ZipList. To clarify my "cross products" question, I mean fs <*> xs = [f x | f <- fs, x <- xs], as with lists. Cheers, - Conal On Mon, Mar 24, 2008 at 8:36 AM, apfelmus wrote: > (Sorry for the late reply) > > Conal Elliott wrote: > > Is there a known deconstruction of the list/backtracking applicative > functor > > (AF)? If I decompose the list type into pieces (Maybe, product, > > composition), I think I can see where the ZipList AF comes from, but not > the > > list/backtracking AF. > > So, you mean that the strange thing about the list monad is that the > "natural" applicative structure for [a] is derived from the "composition" > > [a] ~ Maybe (a, Maybe (a, ...)) ~ Maybe `O` (a,) `O` Maybe `O` > (a,) `O` ... > > ? Well, this is not quite true since the applicativity you're seeking is > in the extra argument a , not in the argument of the composition. In > fact, this infinite composition doesn't have an argument (that's the > whole point of taking the fixed point). In other words, every chain like > > Maybe `O` (a,) `O` Maybe `O` (a,) > Maybe `O` (a,) `O` Maybe `O` (a,) `O` Maybe `O` (a,) > > etc. is an applicative functor in its argument, but not necessarily in > a . So, there is more to the "natural" ZipList AF than Maybe, product > and composition. > > > Is there some construction simpler than lists > > (non-recursive) that introduces cross products? > > What do you mean with "cross products" here? Something with > > sequence :: Applicative f => [f a] -> f [a] > > being the cartesian product for the list monad? Or simpler > > pure (,) :: Applicative f => (f a, f b) -> f (a,b) > > somehow "crossing" the "elements" of f a and f b ? > > > 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/20080324/a7d43329/attachment.htm From lemming at henning-thielemann.de Mon Mar 24 15:47:27 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon Mar 24 15:42:38 2008 Subject: [Haskell-cafe] Monad instance for Data.Set, again Message-ID: The blog article http://www.randomhacks.net/articles/2007/03/15/data-set-monad-haskell-macros describes a variant of the Monad class which allows to restrict the type of the monadic result, in order to be able to make Data.Set an instance of Monad (requiring Ord constraint for the monadic result). The same problem arises for container data structures with restricted element types, where the element type restriction depends on the implementation of the container structure (such as UArray). It would be cumbersome to have several class parts, even more, type constraints in type signatures may reveal implementation details. E.g. constraint (Container c x y z) might be needed for a 'zipWith' function, whereas (Container c y x z) is needed if you use 'zipWith' with swapped arguments. Here is another approach that looks tempting, but unfortunately does not work, and I wonder whether this can be made working. module RestrictedMonad where import Data.Set(Set) import qualified Data.Set as Set class AssociatedMonad m a where class RestrictedMonad m where return :: AssociatedMonad m a => a -> m a (>>=) :: (AssociatedMonad m a, AssociatedMonad m b) => m a -> (a -> m b) -> m b instance (Ord a) => AssociatedMonad Set a where instance RestrictedMonad Set where return = Set.singleton x >>= f = Set.unions (map f (Set.toList x)) GHC says: RestrictedMonad.hs:21:13: Could not deduce (Ord b) from the context (RestrictedMonad Set, AssociatedMonad Set a, AssociatedMonad Set b) arising from use of `Data.Set.unions' at RestrictedMonad.hs:21:13-22 Probable fix: add (Ord b) to the class or instance method `RestrictedMonad.>>=' In the definition of `>>=': >>= x f = Data.Set.unions (map f (Data.Set.toList x)) In the definition for method `RestrictedMonad.>>=' In the instance declaration for `RestrictedMonad Set' From jefferson.r.heard at gmail.com Mon Mar 24 16:07:09 2008 From: jefferson.r.heard at gmail.com (Jefferson Heard) Date: Mon Mar 24 16:03:34 2008 Subject: [Haskell-cafe] BUG: genObjectNames dies on Win32 Message-ID: <4165d3a70803241307n18ed5152pb93149c0520ecf9f@mail.gmail.com> Could this get forwarded on to another more appropriate maling list? Confirmed on GHC and GHCi 6.6 and 6.8, Graphics.Rendering.OpenGL.GL.genObjectNames n is dying if I ask it to return an IO :: [DisplayList] For an example, just open GHCI and change context to Graphics.Rendering.OpenGL.GL and do genObjectNames 4 :: IO [DisplayList] GHCi will merely die. Compiled with GHC, I'm simply running out of memory. It eats RAM indefinitely. -- Jeff From lemming at henning-thielemann.de Mon Mar 24 16:16:13 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon Mar 24 16:11:25 2008 Subject: [Haskell-cafe] Random Monad In-Reply-To: <200803241608.20992.matthew.pocock@ncl.ac.uk> References: <200803241608.20992.matthew.pocock@ncl.ac.uk> Message-ID: On Mon, 24 Mar 2008, Matthew Pocock wrote: > Who currently maintains the Random monad code? I have some patches to > contribute. Do you refer to the code on the wiki? From david.waern at gmail.com Mon Mar 24 16:18:35 2008 From: david.waern at gmail.com (David Waern) Date: Mon Mar 24 16:15:02 2008 Subject: [Haskell-cafe] Haddock Help Required In-Reply-To: <47E7D75C.8010406@blueyonder.co.uk> References: <47E7D75C.8010406@blueyonder.co.uk> Message-ID: 2008/3/24, Dominic Steinitz : > What should I be using for the file name for the read-interface option > in haddock? You must use a file that is on your own hard drive and that is generated with version 2.0 of Haddock, since that is what you're using. The interface file format was changed in Haddock 2.0 due its use of GHC data types, so you can't use 0.x interface files. You need to generate base.haddock with Haddock 2.0. One way to do that, is to make sure Haddock 2.0 is installed, then get the GHC 6.8.2 sources (with core libs) and build that with Haddock docs enabled. Hope this helps, David From matthew.pocock at ncl.ac.uk Mon Mar 24 16:18:57 2008 From: matthew.pocock at ncl.ac.uk (Matthew Pocock) Date: Mon Mar 24 16:15:17 2008 Subject: [Haskell-cafe] Random Monad In-Reply-To: References: <200803241608.20992.matthew.pocock@ncl.ac.uk> Message-ID: <200803242018.57816.matthew.pocock@ncl.ac.uk> On Monday 24 March 2008, Henning Thielemann wrote: > On Mon, 24 Mar 2008, Matthew Pocock wrote: > > Who currently maintains the Random monad code? I have some patches to > > contribute. > > Do you refer to the code on the wiki? No, to the code in darcs at http://code.haskell.org/monadrandom Matthew From lemming at henning-thielemann.de Mon Mar 24 16:22:19 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon Mar 24 16:17:28 2008 Subject: [Haskell-cafe] ghc warn-unused-imports In-Reply-To: <2518b95d0803241044p369bcf23g7d15dca19a082d5a@mail.gmail.com> References: <2518b95d0803241044p369bcf23g7d15dca19a082d5a@mail.gmail.com> Message-ID: On Mon, 24 Mar 2008, Evan Laforge wrote: > So it appears that GHC will warn about "unused" imports when you > import qualified if you could have gotten the symbol from somewhere > else. For instance, if you write: > > import qualified Control.Monad.Trans as Trans > import qualified Control.Monad.Writer as Writer > > and use "Trans.lift", it will complain because you could have used > "Writer.lift". I think, it's a known issue: http://hackage.haskell.org/trac/ghc/ticket/1148 From janeczek at gmail.com Mon Mar 24 16:38:07 2008 From: janeczek at gmail.com (=?UTF-8?Q?Micha=C5=82_Janeczek?=) Date: Mon Mar 24 16:34:34 2008 Subject: [Haskell-cafe] SoC project: Python-Haskell bridge - request for feedback Message-ID: <561cb5bc0803241338x25170cffyda72b0d8446a3bb4@mail.gmail.com> Hi, I am a student interested in participating in this year's SoC. At http://tsk.ch.uj.edu.pl/~janeczek/socapp.html (and also below in this email) you can find a draft of my project proposal. I'd like to ask you to comment on it, especially the deliverables part. Are you interested in such a project, and if yes, what features would be most important to you? Is anything missing, or should something get more priority or attention? Regards, Michal Python-Haskell bridge ===================== Description ----------- This project will seek to provide a comprehensive, high level (and thus easy to use) binding between Haskell and Python programming languages. This will allow using libraries of either side from each language. Benefits for Python ------------------- * Robust, high assurance components It might be beneficial to implement safety-critical components in a strongly, statically typed language, using Python to keep them together. Cryptography or authentication modules can be an example. * Performance improvements for speed-critical code Haskell compiled to native code is typically an order of magnitude faster than Python. Aside from that, advanced language features (such as multicore parallel runtime, very lightweight threads and software transactional memory) further serve in improving the performance. Haskell could become a safe, high level alternative to commonly used C extensions. * Access to sophisticated libraries While its set of libraries is not as comprehensive as that of Python, Haskell can still offer some well tested, efficient libraries. Examples might be rich parser combinator libraries (like Parsec) and persistent, functional data structures. QuickCheck testing library could also be used to drive analysis of Python code. Benefits for Haskell -------------------- The project would benefit Haskell by providing it with access to an impressive suite of libraries. It also has a potential to help Haskell adoption, by mitigating risk of using Haskell in a project. Deliverables ------------ * A low level library to access Python objects from Haskell * A set of low level functions to convert built-in data types between Haskell and Python (strings, numbers, lists, dictionaries, functions, generators etc.) * A higher level library allowing easy (transparent) access to Python functions from Haskell, and wrapping Haskell functions for Python to access * A way to easily derive conversion functions for user-defined data types/objects. Functions derived in such a way should work well with both low level and high level access libraries * Documentation and a set of examples for all of above Optional goals -------------- These are of lower priority, and might require a fair amount of work. I would like to implement most of them, if technically feasible. If they don't fit into Summer of Code timeframe, I am planning to finish afterwards. * A Python module for accessing functions from Haskell modules without manual wrapping (such wrapping should be already easy thanks to the high level library). It'd be accomplished through GHC api - if it allows it. The Haskell side of the high level library will already support such mode of operation * Extend and refactor the code, to make it support other similar dynamic languages. This is a lot of work, and definitely out of the scope of Summer of Code project, but some design decisions may be influenced by this. Related projects ---------------- They (and quite possibly some others) will be referenced for ideas. * MissingPy Provides a one way, low level binding to Python. Some of the code can be possibly reused, especially data conversion functions. It doesn't seem to export all features, in particular function callbacks are not supported * HaXR XML-RPC binding for Haskell. It could provide inspiration for reconciling Haskell and Python type systems, resulting in a friendly interface * rocaml A binding between Ruby and OCaml From bulat.ziganshin at gmail.com Mon Mar 24 16:51:19 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Mon Mar 24 16:49:44 2008 Subject: [Haskell-cafe] SoC project: Python-Haskell bridge - request for feedback In-Reply-To: <561cb5bc0803241338x25170cffyda72b0d8446a3bb4@mail.gmail.com> References: <561cb5bc0803241338x25170cffyda72b0d8446a3bb4@mail.gmail.com> Message-ID: <1679725785.20080324235119@gmail.com> Hello Michal, Monday, March 24, 2008, 11:38:07 PM, you wrote: > Python-Haskell bridge seems interesting > Benefits for Haskell you forget about ability to use Python as scripting language inside Haskell programs. look at HsLua library as example of this -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From apfelmus at quantentunnel.de Mon Mar 24 16:59:20 2008 From: apfelmus at quantentunnel.de (apfelmus) Date: Mon Mar 24 16:55:54 2008 Subject: [Haskell-cafe] Re: Type constraints for class instances In-Reply-To: <220e47b40803230539i42796fa1h480210020720e879@mail.gmail.com> References: <220e47b40803201900u4bcc564ard2ab8ad6d1d32a81@mail.gmail.com> <220e47b40803230539i42796fa1h480210020720e879@mail.gmail.com> Message-ID: Krzysztof Skrz?tnicki wrote: > class YOrd a where > ycmp :: a -> a -> (a,a) > Unfortunately, the performance of ysort is rather low. I believe that > it is impossible to create any sorting algorithm that uses ycmp > instead of compare, that is faster than O(n^2). It is possible, the following implementation of mergesort is O(n log n) :) ysort :: (YOrd a) => [a] -> [a] ysort = head . mergeAll . map (:[]) where mergeAll (x:y:zs) = mergeAll $ merge x y : mergeAll zs mergeAll xs = xs merge [] ys = ys merge (x:xs) ys = merge3 x ys xs merge3 x [] xs = x : xs merge3 x (y:ys) xs = x' : merge3 y' xs ys where (x',y') = x `ycmp` y Mergesort works like a tournament and the idea is to introduce merge3 :: YOrd a => a -> [a] -> [a] -> [a] to make the intermediate candidates explicit. In a call merge3 x ys zs , the candidate x is pitted against the head of ys . The winner is moved to the front and the loser is the new candidate ( ycmp is enough to do that). Furthermore, there is the invariant that x became candidate by winning over all xs (formally: x <= minimum xs), there is no need to pit x against them for a second time. The whole thing is O(n log n) for the usual reasons, the important part being that merge3 is O(1 + length xs + length ys). The problem with your solution was that merge [gt] (merge xs ys) could be O(2 * length ys) or something. Both solutions are almost the same because merge3 x ys xs ~ merge [x] (merge xs ys) , but merge3 incorporates the additional insight that we don't need to pit x against the xs anymore. Regards, apfelmus From bos at serpentine.com Mon Mar 24 17:14:17 2008 From: bos at serpentine.com (Bryan O'Sullivan) Date: Mon Mar 24 17:10:43 2008 Subject: [Haskell-cafe] Random Monad In-Reply-To: <200803242018.57816.matthew.pocock@ncl.ac.uk> References: <200803241608.20992.matthew.pocock@ncl.ac.uk> <200803242018.57816.matthew.pocock@ncl.ac.uk> Message-ID: <47E819A9.4030405@serpentine.com> Matthew Pocock wrote: > On Monday 24 March 2008, Henning Thielemann wrote: >> On Mon, 24 Mar 2008, Matthew Pocock wrote: >>> Who currently maintains the Random monad code? I have some patches to >>> contribute. >> Do you refer to the code on the wiki? > > No, to the code in darcs at http://code.haskell.org/monadrandom I believe it's Cale's baby. References: Message-ID: Conal Elliott wrote: > Thanks for the reply. Here's the decomposition I had in mind. Start with > > type List a = Maybe (a, List a) > > Rewrite a bit > > type List a = Maybe (Id a, List a) > > Then make the type *constructor* pairing explicit > > type List a = Maybe ((Id :*: List) a) > > where > > newtype (f :*: g) a = Prod { unProd :: (f a, g a) } > > Then make the type-constructor composition explicit > > type List = Maybe :. (Id :*: List) > > (which isn't legal Haskell, due to the type synonym cycle). From there use > the Functor and Applicative instances for composition and pairing of type > constructors and for Id. I think the result is equivalent to ZipList. Ah, I didn't think of feeding a to both f and g in the product f :* g . Your argument cheats a bit because of its circularity: assuming List is an applicative functor, you deduce that List is an applicative functor. But in this case, the recursion is (co-)inductive, so things work out. Here's the formalization: -- higher-order functors g :: (* -> *) -> (* -> *) -- (not sure how to do these classes directly in Haskell, -- but you know what I want to do here) class Functor2 g where forall f . Functor f => Functor (g f) class Applicative2 g where forall f . Applicative f => Applicative (g f) -- higher-order composition type (f :.. g) h = f :. (g :. h) -- fixed points for higher-order functors newtype Mu g a = In { out :: g (Mu g) a } type List a = Mu ((Maybe :.) :.. (Id :*)) a instance Applicative2 g => Applicative (Mu g) where pure x = In (pure x) (In f) <*> (In x) = In (f <*> g) This last class instance looks ridiculous of course, but does nothing more than use the assertion Applicative (Mu g) in its own definition. But fortunately, this definition terminates. >>> Is there some construction simpler than lists >>> (non-recursive) that introduces cross products? > > To clarify my "cross products" question, I mean fs <*> xs = [f x | f <- fs, > x <- xs], as with lists. I'm not sure how to decouple the notion of cross products from lists. Maybe the other characterization of applicative functors sheds some light on it: applicative functors f can also be defined with the following two primitive operations pure :: a -> f a cross :: (f a, f b) -> f (a,b) f <*> x = fmap eval (cross (f,x)) where eval (f,x) = f x Then, the choice pure x = repeat x [1,2] `cross` [3,4] = [(1,3), (2,4)] yields zip lists whereas the choice pure x = [x] [1,2] `cross` [3,4] = [(1,3), (1,4), (2,3), (2,4)] yields backtracking lists. I'm not sure whether other choices are possible too, they probably violate the laws mentioned in chapter 7 of the applicative functor paper. Regards, apfelmus From apfelmus at quantentunnel.de Mon Mar 24 17:22:31 2008 From: apfelmus at quantentunnel.de (apfelmus) Date: Mon Mar 24 17:19:02 2008 Subject: [Haskell-cafe] Re: Random Monad In-Reply-To: <200803241608.20992.matthew.pocock@ncl.ac.uk> References: <200803241608.20992.matthew.pocock@ncl.ac.uk> Message-ID: Matthew Pocock wrote: > Who currently maintains the Random monad code? /me whispers: have a look at http://code.haskell.org/monadrandom/MonadRandom.cabal Regards, apfelmus From apfelmus at quantentunnel.de Mon Mar 24 18:06:43 2008 From: apfelmus at quantentunnel.de (apfelmus) Date: Mon Mar 24 18:03:22 2008 Subject: [Haskell-cafe] Sorting with a weaker form of Ord (Re: Type constraints for class instances) In-Reply-To: References: <220e47b40803201900u4bcc564ard2ab8ad6d1d32a81@mail.gmail.com> <220e47b40803230539i42796fa1h480210020720e879@mail.gmail.com> Message-ID: apfelmus wrote: > Krzysztof Skrz?tnicki wrote: >> class YOrd a where >> ycmp :: a -> a -> (a,a) > >> Unfortunately, the performance of ysort is rather low. I believe that >> it is impossible to create any sorting algorithm that uses ycmp >> instead of compare, that is faster than O(n^2). > > It is possible, the following implementation of mergesort is O(n log > n) :) > > merge3 x [] xs = x : xs > merge3 x (y:ys) xs = x' : merge3 y' xs ys > where (x',y') = x `ycmp` y > > invariant that x became candidate by winning over all xs Oops, merge3 clearly violates this invariant since y' could be x . So, my previous post is all wrong ?(>_<)? . Regards, apfelmus From westondan at imageworks.com Mon Mar 24 18:29:51 2008 From: westondan at imageworks.com (Dan Weston) Date: Mon Mar 24 18:26:24 2008 Subject: [Haskell-cafe] SoC project: Python-Haskell bridge - request for feedback In-Reply-To: <1679725785.20080324235119@gmail.com> References: <561cb5bc0803241338x25170cffyda72b0d8446a3bb4@mail.gmail.com> <1679725785.20080324235119@gmail.com> Message-ID: <47E82B5F.2060604@imageworks.com> Bulat Ziganshin wrote: > Hello Michal, > > Monday, March 24, 2008, 11:38:07 PM, you wrote: > >> Python-Haskell bridge > > seems interesting This is indeed interesting for those (like me) wanting to introduce Haskell stealthily into a Python-based facility: essentially, leave the IO monad in Python but invoke non-IO Haskell functions. >> Benefits for Haskell > > you forget about ability to use Python as scripting language inside > Haskell programs. look at HsLua library as example of this This is much less interesting for those (like me) who, once in Haskell, don't feel the least inclined to go back to Python. Missing libraries in Haskell (for my applications) are usually also missing in Python and need FFI to some (usually numeric) library written in C/C++ anyway. Why do data marshalling twice? Dan From bulat.ziganshin at gmail.com Mon Mar 24 18:33:47 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Mon Mar 24 18:31:46 2008 Subject: [Haskell-cafe] SoC project: Python-Haskell bridge - request for feedback In-Reply-To: <47E82B5F.2060604@imageworks.com> References: <561cb5bc0803241338x25170cffyda72b0d8446a3bb4@mail.gmail.com> <1679725785.20080324235119@gmail.com> <47E82B5F.2060604@imageworks.com> Message-ID: <1798107517.20080325013347@gmail.com> Hello Dan, Tuesday, March 25, 2008, 1:29:51 AM, you wrote: >> you forget about ability to use Python as scripting language inside >> Haskell programs. look at HsLua library as example of this > This is much less interesting for those (like me) who, once in Haskell, > don't feel the least inclined to go back to Python. Missing libraries in > Haskell (for my applications) are usually also missing in Python and > need FFI to some (usually numeric) library written in C/C++ anyway. Why > do data marshalling twice? Python, unlike Haskell, can be compiled on the fly -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From dons at galois.com Mon Mar 24 18:45:10 2008 From: dons at galois.com (Don Stewart) Date: Mon Mar 24 18:41:42 2008 Subject: [Haskell-cafe] SoC project: Python-Haskell bridge - request for feedback In-Reply-To: <47E82B5F.2060604@imageworks.com> References: <561cb5bc0803241338x25170cffyda72b0d8446a3bb4@mail.gmail.com> <1679725785.20080324235119@gmail.com> <47E82B5F.2060604@imageworks.com> Message-ID: <20080324224510.GE15485@scytale.galois.com> westondan: > Bulat Ziganshin wrote: > >Hello Michal, > > > >Monday, March 24, 2008, 11:38:07 PM, you wrote: > > > >>Python-Haskell bridge > > > >seems interesting > > This is indeed interesting for those (like me) wanting to introduce > Haskell stealthily into a Python-based facility: essentially, leave the > IO monad in Python but invoke non-IO Haskell functions. Yes, exactly. The Haskell risk is mitigated, and you can use it exactly as you wish, for strongly typed, purely functionaly, robust components held together with Python glue. And then its easier to sneak Haskell into an existing python toolchain. > >>Benefits for Haskell > > > >you forget about ability to use Python as scripting language inside > >Haskell programs. look at HsLua library as example of this > > This is much less interesting for those (like me) who, once in Haskell, > don't feel the least inclined to go back to Python. Missing libraries in > Haskell (for my applications) are usually also missing in Python and > need FFI to some (usually numeric) library written in C/C++ anyway. Why > do data marshalling twice? Agreed. There are some libraries we don't have (pygments is one). -- Don From hjgtuyl at chello.nl Mon Mar 24 19:44:42 2008 From: hjgtuyl at chello.nl (hjgtuyl@chello.nl) Date: Mon Mar 24 19:41:18 2008 Subject: [Haskell-cafe] Terminating GLUT/GLFW programs In-Reply-To: <47E75F0D.4090500@telenet.be> References: <47E75F0D.4090500@telenet.be> Message-ID: Thanks for the info, but it doesn't solve my problem; I adjusted the path, reinstalled GLFW and recompiled the program, but it still does not terminate. Henk-Jan On Mon, 24 Mar 2008 08:58:05 +0100, Peter Verswyvelen wrote: > Hi, > > I had a similar (unsolved) problem with GLUT but on my system (Windows > XP + GHC 6.8.2) GLFW works fine, exiting is no problem at all. > > But when building GLFW, make sure that the GHC gcc-lib directory comes > *before* the MinGW/Cygwin directory in your PATH environment variable, > since when linking, the LD.EXE bundled with GHC *must* be used. > > Cheers, > Peter > > hjgtuyl@chello.nl wrote: >> >> L.S., >> >> I am trying GLUT and GLFW (on Windows XP, with GHC 6.8.2); the sample >> programs do not terminate when I close the window by clicking on the >> cross in the upper right corner of the window. >> >> The sample program for GLUT is at >> >> http://blog.mikael.johanssons.org/archive/2006/09/opengl-programming-in-haskell-a-tutorial-part-1/ >> the GLFW program: >> http://haskell.org/haskellwiki/GLFW >> >> I tried in the GLUT program: >> close = exitWith ExitSuccess >> >> closeCallback $= Just close -- => User error (unknown GLUT call >> getCloseFunc, check for freeglut) >> >> this needs freeglut (not documented); I downloaded freeglut.dll and >> placed it in the windows\system32 directory. The error message remained. >> >> What is needed to let these programs terminate properly? >> -- http://functor.bamikanarie.com http://Van.Tuyl.eu/ -- From etienne at atnnn.com Mon Mar 24 21:47:29 2008 From: etienne at atnnn.com (Etienne Laurin) Date: Mon Mar 24 21:43:54 2008 Subject: [Haskell-cafe] [GSoC] Parallel Benchmarking and Profiling Message-ID: Hello, I am putting together a student proposal to participate in Google's Summer of Code with one of the following project ideas. Parallel programming benchmarking and benchmark suite - http://hackage.haskell.org/trac/summer-of-code/ticket/1544 Are there open source projects and real world applications that rely on GHC's parrallel programming primitives and libraries? I have found many references to LOLITA, but it seems to be old and not available online. The idea page suggests porting existing benchmark suites such as PARSEC, but PARSEC is 5G of C code. Most of it seems to come from existing applications already written in C. It might also be interesting to automate the discovery of optimal strategies through empirical data, and to modify the thresholds dynamically. Parallel profiling tools for GHC - http://hackage.haskell.org/trac/summer-of-code/ticket/1559 Simon Marlow wrote on the idea page that Gransim was ported to a more up-to-date GHC. The documentation available on the web seems to be for GHC 0.29 but it describes many options for logging and visualising the activity of threads and processors over time. Getting GHC to display that information on the frontpanel would make a nice project. Do you have any comments or suggestions? Thank you, Etienne Laurin From chak at cse.unsw.edu.au Mon Mar 24 22:28:27 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Mon Mar 24 22:25:11 2008 Subject: [Haskell-cafe] Equality constraints in type families In-Reply-To: <004b01c88da4$843f6800$ee3d8351@cr3lt> References: <7b92c2840803101651x3673691eid310ab137805eeff@mail.gmail.com><00bf01c889e1$b34639b0$b9387ad5@cr3lt> <2240735C-74CC-4F5F-8B38-3402C0C278FF@cse.unsw.edu.au> <004b01c88da4$843f6800$ee3d8351@cr3lt> Message-ID: <3DF1C128-4178-4290-B1C0-6BE4DA0646C9@cse.unsw.edu.au> Claus Reinke: >>>>> type family F a :: * -> * >>>> F x y ~ F u v <=> F x ~ F u /\ y ~ v >>> >> words, in a type term like (F Int Bool), the two parameters Int >> and Bool are treated differently. Int is treated like a parameter >> to a function (which is what you where expecting), whereas Bool is >> treated like a parameter to a vanilla data constructor (the part >> you did not expect). To highlight this distinction, we call only >> Int a type index. Generally, if a type family F has arity n, it's >> first n parameters are type indicies, the rest are treated like >> the parameters of any other type constructor. > > i'm not sure haskell offers the kind of distinction that we > need to talk about this: 'data constructor' is value-level, > 'type constructor' doesn't distinguish between type- vs > data-defined type constructors. i think i know what you > mean, but it confuses me that you use 'data constructor' > (should be data/newtype-defined type constructor?) Yes, I meant to write "data type constructor". > and 'type constructor' (don't you want to exclude > type-defined type constructors here). It may have been clearer if I had written data type constructor, but then the Haskell 98 report doesn't bother with that either (so I tend to be slack about it, too). > data ConstD x y = ConstD x > type ConstT x y = x > > 'ConstD x' and 'ConstT x' have the same kind, that > of type constructors: * -> *. but: > > ConstD x y1 ~ ConstD x y2 => y1 ~ y2 > > whereas > > forall y1, y2: ConstT x y1 ~ ConstT x y2 But note that ConstT x ~ ConstT x is malformed. > and i thought 'type family' was meant to suggest type > synonym families, in contrast to 'data family'? My nomenclature is as follows. The keywords 'type family' introduces a "type synonym family" and 'data family' introduces a "data type family" (or just "data family"). The term "type family" includes both. This follows Haskell's common use of "type constructor", "type synonym constructor", and "data type constructor". > you did notice that i gave an example of how ghc does > not seem to follow that decomposition rule, didn't you? Yes, but I didn't see why you think GHC does the wrong thing. Manuel From chak at cse.unsw.edu.au Mon Mar 24 22:34:19 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Mon Mar 24 22:30:59 2008 Subject: [Haskell-cafe] Equality constraints in type families In-Reply-To: <004d01c88da5$f744a350$ee3d8351@cr3lt> References: <7b92c2840803101651x3673691eid310ab137805eeff@mail.gmail.com><00bf01c889e1$b34639b0$b9387ad5@cr3lt><00cf01c889e6$06ae9fd0$b9387ad5@cr3lt> <004d01c88da5$f744a350$ee3d8351@cr3lt> Message-ID: Claus Reinke: >>>>>> type family F a :: * -> * >>>>> F x y ~ F u v <=> F x ~ F u /\ y ~ v >>> >>> why would F x and F u have to be the same functions? >>> shouldn't it be sufficient for them to have the same result, >>> when applied to y and v, respectively? >> Oh, yes, that is sufficient and exactly what is meant by F x ~ F >> u. It means, the two can be unified modulo any type instances and >> local given equalities. > > sorry, i don't understand how that could be meant by 'F x ~ F u'; > that equality doesn't even refer to any specific point on which these > two need to be equal, so it can only be a point-free higher-order > equality, can't it? > > the right-to-left implication is obvious, but the left-to-right > implication seems to say that, for 'F x' and 'F u' to be equal on > any concrete pair of types 'y' and 'u', they have to be equal on all > possible types and 'y' and 'u' themselves have to be equal. You write 'y' and 'u'. Do you mean 'x' and 'u'? If so, why do you think the implication indicates that x and u need to be the same? > again, i gave a concrete example of how ghc behaves as i would > expect, not as that decomposition rule would suggest. Maybe you can explain why you think so. I didn't understand why you think the example is not following the decomposition rule. Manuel From oleg at okmij.org Tue Mar 25 00:19:37 2008 From: oleg at okmij.org (oleg@okmij.org) Date: Tue Mar 25 00:16:24 2008 Subject: [Haskell-cafe] Monad instance for Data.Set Message-ID: <20080325041937.1BE2AA99B@Adric.metnet.fnmoc.navy.mil> The following code solves exactly the problem of implementing (restricted) MonadPlus in terms of Data.Set: http://okmij.org/ftp/Haskell/DoRestrictedM.hs The code is written to demonstrate the do-notation. We write the monadic code as usual: > test1s_do () = do > x <- return "a" > return $ "b" ++ x and then instantiate it for Maybe String: > test1sr_do :: Maybe String > test1sr_do = unRM $ test1s_do () > -- Just "ba" or for Data.Set: > test2sr_do :: Set.Set String > test2sr_do = unSM $ test1s_do () > -- fromList ["ba"] It seems GHC 6.10 will support the do-notation even for the generalized monads. From chak at cse.unsw.edu.au Tue Mar 25 02:39:14 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Tue Mar 25 02:35:53 2008 Subject: [Haskell-cafe] Equality constraints in type families In-Reply-To: References: <7b92c2840803101651x3673691eid310ab137805eeff@mail.gmail.com><00bf01c889e1$b34639b0$b9387ad5@cr3lt><00cf01c889e6$06ae9fd0$b9387ad5@cr3lt> <004d01c88da5$f744a350$ee3d8351@cr3lt> Message-ID: Manuel M T Chakravarty: >> again, i gave a concrete example of how ghc behaves as i would >> expect, not as that decomposition rule would suggest. > > Maybe you can explain why you think so. I didn't understand why you > think the example is not following the decomposition rule. Actually, see http://hackage.haskell.org/trac/ghc/ticket/2157#comment:10 Manuel From thomas.engel1 at gmx.net Tue Mar 25 04:13:29 2008 From: thomas.engel1 at gmx.net (Thomas Engel) Date: Tue Mar 25 04:09:55 2008 Subject: [Haskell-cafe] separate input calculation output Message-ID: <20080325081329.GA2146@siduxbox> Hello, I'm new to haskell and want to write a small program for some winder calcucations. I want to input 10-15 values and based on this input doing some calculations. After this calculations I want to print out the results. My problem is: How can I get the input values into the calculations and back the result to the output. In an other language I would use global variables for this. So what should I use in haskell? An other point is that I want to separate the input from the calculations and the output. How can I achieve this with haskell? Modules? Data types? See some pseudo code below. inputvalues :: IO() inputvalues = do hSetBuffering stdout NoBuffering putStr "Berechnung Bremsgenerator \n\n" ve <- readNum "Bitte Maschinengeschwindigkeit (m/min) angeben: " de <- readNum "Bitte Durchmesser der vollen Rolle eingeben (mm): " dewalze <- readNum "Bitte Durchmesser der Walze eingeben (mm): " dewand <- readNum "Bitte Wandstaerke der Walze eingeben (mm): " and so on .............. readNum :: String -> IO Float readNum text = do putStrLn text readLn -- calculations nvr :: Float-> Float-> Float nvr ve de = ve / de /pi *1000 pzugmin :: Float-> Float-> Float->Float pzugmin ve femin be = 1.666 * ve * femin * be * 0.00000001 pzugmax :: Float-> Float-> Float->Float pzugmax ve femax be = 1.666 * ve * femax * be * 0.00000001 and so on .............. outputvalues = do putStr "\n\nErgebnisse Bremsgenerator \n\n" putStr "Drehzahl leere Trommel: " putStr(show(round(nvr))) putStr " U/min \n" putStr "Drehzahl volle Trommel: " putStr(show(round(drehbgmax))) putStr " U/min \n" and so on ...................... Thanks Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080325/f356e92a/attachment.bin From rvollmert-lists at gmx.net Tue Mar 25 05:36:49 2008 From: rvollmert-lists at gmx.net (Robert Vollmert) Date: Tue Mar 25 05:33:15 2008 Subject: [Haskell-cafe] separate input calculation output In-Reply-To: <20080325081329.GA2146@siduxbox> References: <20080325081329.GA2146@siduxbox> Message-ID: On Mar 25, 2008, at 09:13, Thomas Engel wrote: > My problem is: How can I get the input values into the calculations > and back > the result to the output. > > In an other language I would use global variables for this. So what > should I > use in haskell? (I think I know enough haskell to answer this, but I may be telling you all the wrong things.) You'll have to pass the values through, though this can be hidden to some extent. Try changing your functions to have types type Input = (Float, Float, ...) type Output = (Float, Float, ...) inputvalues :: IO Input -- add a "return (ve,de,...)" to the end compute :: Input -> Output outputvalues :: Output -> IO () You could then wrap them in main :: IO () main = do input <- inputvalues outputvalues (compute input) This should do what you want. It might be improved upon by using data types with appropriately named fields instead of tuples so as to keep your variable names around. Cheers Robert From ketil at malde.org Tue Mar 25 06:10:36 2008 From: ketil at malde.org (Ketil Malde) Date: Tue Mar 25 06:06:50 2008 Subject: [Haskell-cafe] separate input calculation output In-Reply-To: <20080325081329.GA2146@siduxbox> (Thomas Engel's message of "Tue\, 25 Mar 2008 09\:13\:29 +0100") References: <20080325081329.GA2146@siduxbox> Message-ID: <87d4pjunab.fsf@nmd9999.imr.no> Thomas Engel writes: > My problem is: How can I get the input values into the calculations and back > the result to the output. > In an other language I would use global variables for this. That would be bad style. > An other point is that I want to separate the input from the calculations and > the output. > So what should I use in haskell? I think your pseudocode is right on track. > inputvalues :: IO () The most obvious way to do it would be to define data Input = ... data Output = ... input_values :: IO Input calculate :: Input -> Output ouput_values :: Output -> IO () then: main = do i <- input_values let o = calculate i output_values o or: main = output_values . calculate =<< input_values -k -- If I haven't seen further, it is by standing in the footprints of giants From claus.reinke at talk21.com Tue Mar 25 07:04:05 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Tue Mar 25 07:00:44 2008 Subject: [Haskell-cafe] Equality constraints in type families References: <7b92c2840803101651x3673691eid310ab137805eeff@mail.gmail.com><00bf01c889e1$b34639b0$b9387ad5@cr3lt><00cf01c889e6$06ae9fd0$b9387ad5@cr3lt><004d01c88da5$f744a350$ee3d8351@cr3lt> Message-ID: <006e01c88e67$f6afef40$321e7ad5@cr3lt> >>> again, i gave a concrete example of how ghc behaves as i would >>> expect, not as that decomposition rule would suggest. >> >> Maybe you can explain why you think so. I didn't understand why you >> think the example is not following the decomposition rule. > > Actually, see > > http://hackage.haskell.org/trac/ghc/ticket/2157#comment:10 > > Manuel for those following along here: | However, I think I now understand what you are worried about. It is the | interaction of type families and GHC's generalised type synonyms (i.e., | type synonyms that may be partially applied). I agree that it does lead | to an odd interaction, because the outcome may depend on the order in | which the type checker performs various operations. In particular, | whether it first applies a type instance declaration to reduce a type | family application or whether it first performs decomposition. yes, indeed, thanks! that was the central point of example one. one might say that the central point of example two were two partially applied type synonym families in the same position (rhs of a type synonym family instance definition). usually, when reduction meets typing, there is a subject reduction theorem, stating that types do not change during reduction. since, in this case, reduction and constraint generation happen at the same (type) level, the equivalent would be a proof of confluence, so that it doesn't matter which type rules are applied in which order (in this case, decomposition and reduction). as far as i could determine, the TLDI paper does not deal with the full generality of ghc's type extensions, so it doesn't stumble over this issue, and might need elaboration. my suggestion was to annotate the results of type family application reductions with the type parameters. in essence, that would carry the phantom types along for type checking, and the decomposition rule could be taken care of even after reduction, by comparing these annotations. alternatively, use the decomposition rule as the reduction rule. both would make clear that one is *not* dealing with simple type-level function applications. | The most clean solution may indeed be to outlaw partial applications of | vanilla type synonyms in the rhes of type instances. (Which is what I | will implement unless anybody has a better idea.) i always dislike losing expressiveness, and ghc does almost seem to behave as i would expect in those examples, so perhaps there is a way to fit the partial applications into the theory of your TLDI paper. and i still don't like the decomposition rule, and i still don't even understand that first part about comparing partially applied type constructors!-) but in terms of actually implementing your design, and matching your theory and proofs, it might be best to treat the rhs of a type family instance like a type class instance parameter (where partial applications of synonyms and families are ruled out), not like the rhs of a type synonym definition (where everything is allowed). then users can try out an implementation that does what you say it would, including constraints needed for your proofs, which might lead to extension requests later - as Tom said, there may still be some open ends. perhaps you could keep those two examples around in a separate ticket, collecting experiences with and limitations of type families? thanks, claus From claus.reinke at talk21.com Tue Mar 25 07:42:38 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Tue Mar 25 07:39:12 2008 Subject: [Haskell-cafe] Equality constraints in type families References: <7b92c2840803101651x3673691eid310ab137805eeff@mail.gmail.com><00bf01c889e1$b34639b0$b9387ad5@cr3lt><00cf01c889e6$06ae9fd0$b9387ad5@cr3lt><004d01c88da5$f744a350$ee3d8351@cr3lt> Message-ID: <008d01c88e6d$57dc8b70$321e7ad5@cr3lt> >>>>>>> type family F a :: * -> * >>>>>> F x y ~ F u v <=> F x ~ F u /\ y ~ v >>>> >>>> why would F x and F u have to be the same functions? >>>> shouldn't it be sufficient for them to have the same result, >>>> when applied to y and v, respectively? >>> Oh, yes, that is sufficient and exactly what is meant by F x ~ F >>> u. It means, the two can be unified modulo any type instances and >>> local given equalities. >> >> sorry, i don't understand how that could be meant by 'F x ~ F u'; >> that equality doesn't even refer to any specific point on which these >> two need to be equal, so it can only be a point-free higher-order >> equality, can't it? >> >> the right-to-left implication is obvious, but the left-to-right >> implication seems to say that, for 'F x' and 'F u' to be equal on >> any concrete pair of types 'y' and 'u', they have to be equal on all >> possible types and 'y' and 'u' themselves have to be equal. > > You write 'y' and 'u'. Do you mean 'x' and 'u'? If so, why do you > think the implication indicates that x and u need to be the same? oops, sorry, i meant 'y' and 'v' - the second parameters. but my concern here was with the 'F x ~ F u' part - since it doesn't refer to the 'y' and 'v' parameters, i suspect that means a semantic comparison over all possible parameters forall y,v: F x y ~ F u v ie, comparing the type-level 'functions', implying some decidable approximation. my second example, using two partially applied type families G3 and G4, aimed to demonstrate that this doesn't happen in ghc, and that equality on specific points is sufficient. perhaps you want to exclude those partial applications as well, but i'm concerned that type families appear less and less as the straightforward type-level functional programming that i was hoping for. in fact, the decomposition rule seems to be saying that type function results cannot matter, only the structure of type family applications does: F x y ~ F u v <=> F x ~ F u /\ y ~ v or do you have a specific type rule application order in mind where all type-level reductions are performed before this decomposition rule can be applied? claus From thomas.engel1 at gmx.net Tue Mar 25 08:03:55 2008 From: thomas.engel1 at gmx.net (Thomas Engel) Date: Tue Mar 25 08:00:22 2008 Subject: [Haskell-cafe] separate input calculation output In-Reply-To: References: <20080325081329.GA2146@siduxbox> Message-ID: <20080325120355.GC13397@siduxbox> Hi Robert > > (I think I know enough haskell to answer this, but I may be telling you > all the wrong things.) Why? What's wrong? > > You'll have to pass the values through, though this can be hidden to > some extent. Try changing your functions to have types > > type Input = (Float, Float, ...) > type Output = (Float, Float, ...) > > inputvalues :: IO Input -- add a "return (ve,de,...)" to the end > compute :: Input -> Output How can I combine several function (calculations) in this function? > outputvalues :: Output -> IO () > > You could then wrap them in > > main :: IO () > main = do input <- inputvalues > outputvalues (compute input) > > This should do what you want. Thank's for your hints. > It might be improved upon by using data types with appropriately named > fields instead of tuples so as to keep your variable names around. Can you give me an example how do to it with named fields? Thanks Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080325/2513dc70/attachment.bin From rvollmert-lists at gmx.net Tue Mar 25 08:39:00 2008 From: rvollmert-lists at gmx.net (Robert Vollmert) Date: Tue Mar 25 08:35:26 2008 Subject: [Haskell-cafe] separate input calculation output In-Reply-To: <20080325120355.GC13397@siduxbox> References: <20080325081329.GA2146@siduxbox> <20080325120355.GC13397@siduxbox> Message-ID: <02A21690-61E7-4AB8-8DFD-0193360A0A64@gmx.net> On Mar 25, 2008, at 13:03, Thomas Engel wrote: > >> type Input = (Float, Float, ...) >> type Output = (Float, Float, ...) >> >> inputvalues :: IO Input -- add a "return (ve,de,...)" to the end >> compute :: Input -> Output > > How can I combine several function (calculations) in this function? compute (ve,de,dewalze,dewand,...) = ( nvr ve de, pzugmin ve femin, pzugmax ve femax be, ... ) > Can you give me an example how do to it with named fields? See e.g. http://www.haskell.org/tutorial/moretypes.html#sect6.2 . However, I'm not so sure anymore they'd be of much help here. Cheers Robert From kolar at fit.vutbr.cz Tue Mar 25 08:47:50 2008 From: kolar at fit.vutbr.cz (Dusan Kolar) Date: Tue Mar 25 08:41:13 2008 Subject: [Haskell-cafe] True parallelism missing :-( Message-ID: <47E8F476.2040109@fit.vutbr.cz> Dear all, I've thought the following three (dummy) programs would run some of their parts in parallel (on dual core) if compiled with option threaded (smp). The truth is that only the first one exploits multicore CPU. Why? Moreover, using RTS option -sstderr makes runtime not to evaluate in parallel even for the first program. Why? Thanks for tips Dusan My arch: Linux pcx 2.6.24-ARCH #1 SMP PREEMPT Sun Feb 10 15:44:59 CET 2008 x86_64 Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz GenuineIntel GNU/Linux My ghc: The Glorious Glasgow Haskell Compilation System, version 6.8.2 /64bit, binary distro for FC/ ---------------------------------------------------- Prog 1: module Main() where import Control.Parallel import Control.Parallel.Strategies fibs :: Integer -> Integer fibs n | n > 1 = fibs (n-1) + fibs (n-2) | n == 1 = 1 | True = 0 fib n = if n<0 then error "Negative input to fib!" else f1+f2 where [f1,f2] = parMap rnf fibs [(n-1),(n-2)] main = do putStrLn "Starting..." putStrLn $ "Fib 43: " ++ show (fib 43) putStrLn "Done!" ---------------------------------------------------- Prog 2: module Main() where import Control.Concurrent import Control.Concurrent.MVar fibs :: Integer -> Integer fibs n | n > 1 = fibs (n-1) + fibs (n-2) | n == 1 = 1 | True = 0 fib n = if n<0 then error "Negative input to fib!" else do v1 <- newEmptyMVar v2 <- newEmptyMVar h1 <- forkIO $ putMVar v1 $ fibs (n-1) h2 <- forkIO $ putMVar v2 $ fibs (n-2) f1 <- takeMVar v1 f2 <- takeMVar v2 killThread h1 killThread h2 return (f1+f2) main = do putStrLn "Starting..." f <- fib 43 putStrLn $ "Fib 43: " ++ show f putStrLn "Done!" ---------------------------------------------------- Prog 3: module Main() where import Control.Concurrent import Control.Concurrent.MVar fibs :: Integer -> Integer fibs n | n > 1 = fibs (n-1) + fibs (n-2) | n == 1 = 1 | True = 0 fib n = if n<0 then error "Negative input to fib!" else do v1 <- newEmptyMVar v2 <- newEmptyMVar h1 <- forkOS $ putMVar v1 $ fibs (n-1) h2 <- forkOS $ putMVar v2 $ fibs (n-2) f1 <- takeMVar v1 f2 <- takeMVar v2 killThread h1 killThread h2 return (f1+f2) main = do putStrLn "Starting..." f <- fib 43 putStrLn $ "Fib 43: " ++ show f putStrLn "Done!" From bulat.ziganshin at gmail.com Tue Mar 25 09:33:49 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue Mar 25 09:31:50 2008 Subject: [Haskell-cafe] True parallelism missing :-( In-Reply-To: <47E8F476.2040109@fit.vutbr.cz> References: <47E8F476.2040109@fit.vutbr.cz> Message-ID: <841114420.20080325163349@gmail.com> Hello Dusan, Tuesday, March 25, 2008, 3:47:50 PM, you wrote: > (smp). The truth is that only the first one exploits multicore CPU. Why? +RTS -N2 -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From claus.reinke at talk21.com Tue Mar 25 09:48:41 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Tue Mar 25 09:45:15 2008 Subject: [Haskell-cafe] Equality constraints in type families References: <7b92c2840803101651x3673691eid310ab137805eeff@mail.gmail.com><00bf01c889e1$b34639b0$b9387ad5@cr3lt><00cf01c889e6$06ae9fd0$b9387ad5@cr3lt><004d01c88da5$f744a350$ee3d8351@cr3lt> <008d01c88e6d$57dc8b70$321e7ad5@cr3lt> Message-ID: <00c701c88e7e$f3ced0e0$321e7ad5@cr3lt> > was hoping for. in fact, the decomposition rule seems to be > saying that type function results cannot matter, only the > structure of type family applications does: > > F x y ~ F u v <=> F x ~ F u /\ y ~ v > > or do you have a specific type rule application order in mind > where all type-level reductions are performed before this > decomposition rule can be applied? hmm, it seems that here i was confused by the extra syntactic restrictions you have alluded to, meaning that the decomposition rule only applies to extra parameters, not to the type indices. also, given type family F a :: * -> * 'F x' and 'F u' are full applications, so may still be rewritten according to the family instance rules, which means that decomposition does not prevent reduction. it would really be helpful to have local indications of such differences that have an influence on interpretation, eg, a way to distinguish the type indices from the extra parameters. given that type families are never meant to be partially applied, perhaps a different notation, avoiding confusion with type constructor applications in favour of something resembling products, could make that clearer? something simple, like braces to group families and indices: type family {F a} :: * -> * {F x} y ~ {F u} v <=> {F x} ~ {F u} && y ~ v would avoid confusion about which parameters need to be present (no partial application possible) and are subject to family instance rules, and which parameters are subject to the decomposition rule. assuming that you are going to rule out partial applications of type synonyms (example 1) and type families (example 2) in the rhs of type family instances for now, i think that answers my questions in this thread, although i'd strongly recommend the alternative syntax, grouping type indices with braces. sorry about the confusion, claus From bjorn at bringert.net Tue Mar 25 10:24:26 2008 From: bjorn at bringert.net (Bjorn Bringert) Date: Tue Mar 25 10:20:54 2008 Subject: [Haskell-cafe] How to program with sqlite? In-Reply-To: <3d96ac180803220715q50c2f0c8gbbd538c3deb26c3e@mail.gmail.com> References: <1206193201.9417.4.camel@knifewolfUBUNTU> <3d96ac180803220715q50c2f0c8gbbd538c3deb26c3e@mail.gmail.com> Message-ID: 2008/3/22 Sebastian Sylvan : > > On Sat, Mar 22, 2008 at 1:40 PM, Deng Chao wrote: > > Hi all, > > I'm learning sqlite, and as I know haskell has some libraries like > > HDBC or HSQL can access sqlite DB. Can anybody give me a small example > > to show how to use it? It will be very appreciate? Thanks! > > > > Best Regards, > > Deng Chao > > > Here's a quick GHCi session with HDBC. > > Prelude> :m +Database.HDBC > Prelude Database.HDBC> :m +Database.HDBC.Sqlite3 > Prelude Database.HDBC Database.HDBC.Sqlite3> conn <- connectSqlite3 "mydb" > Prelude Database.HDBC Database.HDBC.Sqlite3> quickQuery conn "CREATE TABLE > mytable (FirstName varchar, LastName varchar, Age int )" [] > [] > Prelude Database.HDBC Database.HDBC.Sqlite3> quickQuery conn "INSERT INTO > mytable VALUES ('Sebastian','Sylvan',26)" [] > [] > Prelude Database.HDBC Database.HDBC.Sqlite3> commit conn > Prelude Database.HDBC Database.HDBC.Sqlite3> quickQuery conn "SELECT * FROM > mytable" [] > [[SqlString "Sebastian",SqlString "Sylvan",SqlString "26"]] > Prelude Database.HDBC Database.HDBC.Sqlite3> disconnect conn > > > Not sure why that Age field came back as a string though :-) This is SQLite's fault. In SQLite, all types are aliases for STRING. Whatever type you use in the create and insert, you will get strings back. /Bj?rn From asandroq at gmail.com Tue Mar 25 10:29:49 2008 From: asandroq at gmail.com (Alex Sandro Queiroz e Silva) Date: Tue Mar 25 10:26:30 2008 Subject: [Haskell-cafe] How to program with sqlite? In-Reply-To: References: <1206193201.9417.4.camel@knifewolfUBUNTU> <3d96ac180803220715q50c2f0c8gbbd538c3deb26c3e@mail.gmail.com> Message-ID: <47E90C5D.3050006@gmail.com> Hallo, Bjorn Bringert wrote: > > This is SQLite's fault. In SQLite, all types are aliases for STRING. > Whatever type you use in the create and insert, you will get strings > back. > That's not true. SQLite has integers (64 bits) and reals. But, if you try to read the field as text it will gladly convert it for you. For reading as the correcting type, the binding should have used sqlite3_column_get_type first. Cheers, -alex From bjorn at bringert.net Tue Mar 25 10:35:23 2008 From: bjorn at bringert.net (Bjorn Bringert) Date: Tue Mar 25 10:31:50 2008 Subject: [Haskell-cafe] How to program with sqlite? In-Reply-To: <47E90C5D.3050006@gmail.com> References: <1206193201.9417.4.camel@knifewolfUBUNTU> <3d96ac180803220715q50c2f0c8gbbd538c3deb26c3e@mail.gmail.com> <47E90C5D.3050006@gmail.com> Message-ID: On Tue, Mar 25, 2008 at 3:29 PM, Alex Sandro Queiroz e Silva wrote: > Hallo, > > > Bjorn Bringert wrote: > > > > This is SQLite's fault. In SQLite, all types are aliases for STRING. > > Whatever type you use in the create and insert, you will get strings > > back. > > > > That's not true. SQLite has integers (64 bits) and reals. But, if > you try to read the field as text it will gladly convert it for you. For > reading as the correcting type, the binding should have used > sqlite3_column_get_type first. > > Cheers, > -alex Hi Alex, thanks for setting me straight. It would be great if you would want to submit a patch for HDBC-sqlite3 to fix this. /Bj?rn From zunino at di.unipi.it Tue Mar 25 10:38:38 2008 From: zunino at di.unipi.it (Roberto Zunino) Date: Tue Mar 25 10:35:17 2008 Subject: [Haskell-cafe] True parallelism missing :-( In-Reply-To: <47E8F476.2040109@fit.vutbr.cz> References: <47E8F476.2040109@fit.vutbr.cz> Message-ID: <47E90E6E.30407@di.unipi.it> Dusan Kolar wrote: > Dear all, > > I've thought the following three (dummy) programs would run some of > their parts in parallel (on dual core) if compiled with option threaded > (smp). The truth is that only the first one exploits multicore CPU. Why? > h1 <- forkIO $ putMVar v1 $ fibs (n-1) You are putting an unevaluated thunk in the MVar. Try: h1 <- forkIO (putMVar v1 $! fibs (n-1)) Zun. From ggg at cs.nott.ac.uk Tue Mar 25 11:26:02 2008 From: ggg at cs.nott.ac.uk (George Giorgidze) Date: Tue Mar 25 11:22:31 2008 Subject: [Haskell-cafe] Problem with OpenAL In-Reply-To: <694519c50803220913l4e42d4c9s5b66265a3721c6a6@mail.gmail.com> References: <694519c50803220913l4e42d4c9s5b66265a3721c6a6@mail.gmail.com> Message-ID: I am also getting the same output: "0" indicates the number of processed buffers, and "1" the number of queued buffers. It means that the small buffer which is queued for playback never gets processed completely. The first argument of playOpenAL functions is a sampling rate of an audio playback, so you might wont to try "playOpenAL 44100". Currently in my application for audio IO, I am using my own binding to portaudio (C library). As OpenAL is included with GHC source release, I thought it would be nice to have support for OpenAL as well. Can anyone report success with OpenAL and post some code examples? George P.S. I am using GHC 6.8.2 compiled from source on ubuntu linux OpenAL binding version OpenAL-1.3.1.1 OpenAL version libopenal 1.0.0.8 On Sat, Mar 22, 2008 at 4:13 PM, Antoine Latter wrote: > For those of you following along, you'll need: > > > import qualified Sound.OpenAL as AL > > import Data.Maybe > > import Foreign.C.Types > > import Control.Monad > > import Control.Concurrent > > import Foreign.Storable > > import Foreign.Marshal.Alloc > > when I run "playOpenAL 440" I get no sound, and the following is > repeatedly printed on the console: > > waiting > 0 > 1 > waiting > 0 > 1 > waiting > 0 > 1 > waiting > 0 > 1 > > What do you think should be happening? > > -Antoine > > 2008/3/21 George Giorgidze : > > I tried OpenAL binding (the one which is on the Hackage), but with no > luck. > > > > I can not hear anything from speakers and also according to generated > output > > on console it seems that "AL.play" never completes playback of a buffer > as > > buffer remains registered as "unprocessed" in OpenAL context. > > Here is the piece of code. I am not getting any error messages from > OpenAL > > library functions. > > > > playOpenAL :: Int -> IO () > > playOpenAL sr = do > > mDevice <- AL.openDevice Nothing > > when (isNothing mDevice) $ error "opening OpenAL device" > > let device = fromJust mDevice > > > > mContext <- AL.createContext device [ > > AL.Frequency (fromIntegral sr) > > , AL.Refresh (fromIntegral sr) > > ] > > when (isNothing mContext) $ error "creating OpenAL context" > > let context = fromJust mContext > > AL.currentContext AL.$= (Just context) > > > > > > let sampleNumber = 256 > > bufSize = sampleNumber * (sizeOf (undefined :: CShort)) > > buf2 <- mallocBytes bufSize > > > > -- here I am filling buf2 with noise .... > > > > [source] <- AL.genObjectNames 1 > > [buffer] <- AL.genObjectNames 1 > > > > let region = AL.MemoryRegion buf2 (fromIntegral bufSize) > > AL.bufferData buffer AL.$= (AL.BufferData region AL.Mono16(fromIntegral > > sr)) > > > > > > AL.queueBuffers source [buffer] > > AL.loopingMode source AL.$= AL.OneShot > > > > let waitForSource = do > > putStrLn "waiting" > > s <- AL.get (AL.buffersProcessed source) > > putStrLn $ show s > > s <- AL.get (AL.buffersQueued source) > > putStrLn $ show s > > state <- AL.get (AL.sourceState source) > > case state of > > AL.Playing -> do > > threadDelay 1024 > > waitForSource > > _ -> return () > > > > putStrLn "Start Playing ... " > > AL.play [source] > > waitForSource > > > > > > AL.currentContext AL.$= Nothing > > AL.destroyContext context > > b <- AL.closeDevice device > > when (not b) $ error "closing device" > > > > > > Is this library still maintained? > > > > Best, George > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > > -- George Giorgidze http://www.cs.nott.ac.uk/~ggg/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080325/b3f34bfd/attachment.htm From pkeir at dcs.gla.ac.uk Tue Mar 25 11:31:19 2008 From: pkeir at dcs.gla.ac.uk (Paul Keir) Date: Tue Mar 25 11:27:37 2008 Subject: [Haskell-cafe] Parsec (Zero or One of) Message-ID: <3CDFB8AFEA98E34CB599475AB11589C80E8978@EX2.ad.dcs.gla.ac.uk> Hi, I'm having some difficulty using the Parsec library, perhaps you could help. I've reduced my problem as shown below. I would like the 'only_prod' parser to require the reserved string "only", _optionally_ followed by an identifier. As part of 'mytest', this should then be followed by the reserved string "end". mytest = do { only_prod; end } only_prod = do { reserved "only"; try identifier } end = reserved "end" i.e. I'd like both > parseTest mytest "only end" and >parseTest mytest "only green end" to parse successfully. As it stands, only the second is successful. The first fails with: parse error at (line 1, column 9): unexpected end of input expecting letter or digit or "end" Does anyone have an idea how I could repair the situation? Thanks in advance, Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080325/aae76f05/attachment.htm From cetin.sert at gmail.com Tue Mar 25 11:36:51 2008 From: cetin.sert at gmail.com (Cetin Sert) Date: Tue Mar 25 11:33:14 2008 Subject: [Haskell-cafe] getChar Message-ID: <1ff5dedc0803250836y71f874c0w6884d84deea52eee@mail.gmail.com> Hi, is there a version of getChar that doesn't buffer keyboard input until enter is pressed? specialReadln :: IO String specialReadln = do c ? getChar if c == '#' then do return [] else do cs ? specialReadln return (c:cs) I want the input process to terminate when '#' or any other specific key has been pressed. Best Regards, Cetin Sert -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080325/b97ba77b/attachment.htm From trebla at vex.net Tue Mar 25 11:47:19 2008 From: trebla at vex.net (Albert Y. C. Lai) Date: Tue Mar 25 11:43:45 2008 Subject: [Haskell-cafe] Parsec (Zero or One of) In-Reply-To: <3CDFB8AFEA98E34CB599475AB11589C80E8978@EX2.ad.dcs.gla.ac.uk> References: <3CDFB8AFEA98E34CB599475AB11589C80E8978@EX2.ad.dcs.gla.ac.uk> Message-ID: <47E91E87.4050700@vex.net> Paul Keir wrote: > I?m having some difficulty using the Parsec library, perhaps you could > help. I?ve reduced my problem as shown below. I would like the > ?only_prod? parser to require the reserved string ?only?, _optionally_ > followed by an identifier. As part of ?mytest?, this should then be > followed by the reserved string ?end?. Look into option, optional, and optionMaybe. From trebla at vex.net Tue Mar 25 11:50:45 2008 From: trebla at vex.net (Albert Y. C. Lai) Date: Tue Mar 25 11:47:10 2008 Subject: [Haskell-cafe] getChar In-Reply-To: <1ff5dedc0803250836y71f874c0w6884d84deea52eee@mail.gmail.com> References: <1ff5dedc0803250836y71f874c0w6884d84deea52eee@mail.gmail.com> Message-ID: <47E91F55.70703@vex.net> Cetin Sert wrote: > is there a version of getChar that doesn't buffer keyboard input until > enter is pressed? Look into hSetBuffering (module System.IO or IO). As a quick start: hSetBuffering stdin NoBuffering From claudiusmaximus at goto10.org Tue Mar 25 11:59:13 2008 From: claudiusmaximus at goto10.org (Claude Heiland-Allen) Date: Tue Mar 25 11:52:34 2008 Subject: [Haskell-cafe] separate input calculation output In-Reply-To: <20080325120355.GC13397@siduxbox> References: <20080325081329.GA2146@siduxbox> <20080325120355.GC13397@siduxbox> Message-ID: <47E92151.2080608@goto10.org> Thomas Engel wrote: >> inputvalues :: IO Input -- add a "return (ve,de,...)" to the end >> compute :: Input -> Output > > How can I combine several function (calculations) in this function? compute1 :: Input -> Output1 compute2 :: Input -> Output2 combine :: Output1 -> Output2 -> Output compute input = combine c1 c2 where c1 = compute1 input c2 = compute2 input etc Claude -- http://claudiusmaximus.goto10.org From kolar at fit.vutbr.cz Tue Mar 25 12:05:00 2008 From: kolar at fit.vutbr.cz (Dusan Kolar) Date: Tue Mar 25 11:58:25 2008 Subject: [Haskell-cafe] True parallelism missing :-( In-Reply-To: <841114420.20080325163349@gmail.com> References: <47E8F476.2040109@fit.vutbr.cz> <841114420.20080325163349@gmail.com> Message-ID: <47E922AC.7010808@fit.vutbr.cz> I did use that option. :-) Dusan Bulat Ziganshin wrote: > Hello Dusan, > > Tuesday, March 25, 2008, 3:47:50 PM, you wrote: > > >> (smp). The truth is that only the first one exploits multicore CPU. Why? >> > > +RTS -N2 > > > From derek.a.elkins at gmail.com Tue Mar 25 12:19:33 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Tue Mar 25 12:16:58 2008 Subject: [Haskell-cafe] Parsec (Zero or One of) In-Reply-To: <47E91E87.4050700@vex.net> References: <3CDFB8AFEA98E34CB599475AB11589C80E8978@EX2.ad.dcs.gla.ac.uk> <47E91E87.4050700@vex.net> Message-ID: <1206461973.5533.26.camel@derek-laptop> On Tue, 2008-03-25 at 11:47 -0400, Albert Y. C. Lai wrote: > Paul Keir wrote: > > I?m having some difficulty using the Parsec library, perhaps you could > > help. I?ve reduced my problem as shown below. I would like the > > ?only_prod? parser to require the reserved string ?only?, _optionally_ > > followed by an identifier. As part of ?mytest?, this should then be > > followed by the reserved string ?end?. > > Look into option, optional, and optionMaybe. And in particular, try doesn't do what you (Paul) think it does. try however is a rather important combinator of Parsec so I would behoove you to look up it's documentation and the explanations of it in the Parsec letter. From kolar at fit.vutbr.cz Tue Mar 25 12:24:25 2008 From: kolar at fit.vutbr.cz (Dusan Kolar) Date: Tue Mar 25 12:17:48 2008 Subject: [Haskell-cafe] True parallelism missing :-( In-Reply-To: <47E90E6E.30407@di.unipi.it> References: <47E8F476.2040109@fit.vutbr.cz> <47E90E6E.30407@di.unipi.it> Message-ID: <47E92739.70507@fit.vutbr.cz> Yes, that's is. Thanks. My fault - missing wood seeing trees. ;-) Best regards, Dusan Roberto Zunino wrote: > Dusan Kolar wrote: >> Dear all, >> >> I've thought the following three (dummy) programs would run some of >> their parts in parallel (on dual core) if compiled with option >> threaded (smp). The truth is that only the first one exploits >> multicore CPU. Why? > >> h1 <- forkIO $ putMVar v1 $ fibs (n-1) > > You are putting an unevaluated thunk in the MVar. Try: > > h1 <- forkIO (putMVar v1 $! fibs (n-1)) > > Zun. From simonpj at microsoft.com Tue Mar 25 12:24:11 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue Mar 25 12:28:41 2008 Subject: [Haskell-cafe] Equality constraints in type families In-Reply-To: <006e01c88e67$f6afef40$321e7ad5@cr3lt> References: <7b92c2840803101651x3673691eid310ab137805eeff@mail.gmail.com><00bf01c889e1$b34639b0$b9387ad5@cr3lt><00cf01c889e6$06ae9fd0$b9387ad5@cr3lt><004d01c88da5$f744a350$ee3d8351@cr3lt> <006e01c88e67$f6afef40$321e7ad5@cr3lt> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AB9E0C8B1@EA-EXMSG-C334.europe.corp.microsoft.com> | | However, I think I now understand what you are worried about. It is the | | interaction of type families and GHC's generalised type synonyms (i.e., | | type synonyms that may be partially applied). I agree that it does lead | | to an odd interaction, because the outcome may depend on the order in | | which the type checker performs various operations. In particular, | | whether it first applies a type instance declaration to reduce a type | | family application or whether it first performs decomposition. | | yes, indeed, thanks! that was the central point of example one. Aha. Just to clarify, then, GHC's 'generalised type synonyms' behave like this. * H98 says that programmer-written types must obey certain constraints: - type synonym applications saturated - arguments of type applications are monotypes (apart from ->) * GHC says that these constraints must be obeyed only *after* the programmer-written type has been normalised by expanding saturated type synonyms http://www.haskell.org/ghc/docs/latest/html/users_guide/data-type-extensions.html#type-synonyms I regard this as a kind of pre-pass, before serious type checking takes place, so I don't think it should interact with type checking at all. I don't think this normalisation should include type families, although H98 type synonyms are a kind of degenerate case of type families. Would that design resolve this particular issue? Simon From pkeir at dcs.gla.ac.uk Tue Mar 25 12:43:08 2008 From: pkeir at dcs.gla.ac.uk (Paul Keir) Date: Tue Mar 25 12:44:02 2008 Subject: [Haskell-cafe] Parsec (Zero or One of) In-Reply-To: <1206461973.5533.26.camel@derek-laptop> References: <3CDFB8AFEA98E34CB599475AB11589C80E8978@EX2.ad.dcs.gla.ac.uk> <47E91E87.4050700@vex.net> <1206461973.5533.26.camel@derek-laptop> Message-ID: <3CDFB8AFEA98E34CB599475AB11589C80E897C@EX2.ad.dcs.gla.ac.uk> Thanks. I can't find optionMaybe in my version 2.1 of Parsec, but in any case, defining my only_prod as only_prod = do { reserved "only"; option [] identifier } or only_prod = do { reserved "only"; identifier <|> return [] } gives the same error responses as before. I will anyway look closer at option. You're right that I don't understand try, but it's not for lack of trying. My examples' use of try though was just a stab at a readable failure. Maybe I should refactor my example. Paul From ahey at iee.org Tue Mar 25 12:45:58 2008 From: ahey at iee.org (Adrian Hey) Date: Tue Mar 25 12:44:09 2008 Subject: [Haskell-cafe] Re: Libraries need a new owner In-Reply-To: <20080324071227.GA9750@scytale.galois.com> References: <47497409.6050601@iee.org> <20080324071227.GA9750@scytale.galois.com> Message-ID: <47E92C46.5020605@iee.org> Don Stewart wrote: > ahey: >> Hello Folks, >> >> As some of you will be aware, I have been working on various Map >> implementations that currently live here.. >> >> http://code.haskell.org/collections/collections-ghc6.8 >> >> The libs in question being Data.Tree.AVL, Data.Trie.General and a few >> other bits like Data.COrdering and the AVL based Data.Map/Set clones. >> >> Well, I have decided to stop work on these. So they need a new owner if >> they're going to go anywhere. If anyone is interested in the job then I >> suggest they contact myself or Jean-Philippe Bernardy. >> >> Of course I will be happy to provide any help or advise anyone who takes >> over these libs may feel they need from me. I might even contribute a >> few patches from time to time myself :-) >> >> Thanks > > How about we propose this work be done for Summer of Code. > > I've created a ticket here: > > http://hackage.haskell.org/trac/summer-of-code/ticket/1549 > > Add comments, or if you can mentor, add that information too! > > Let's get a new faster Data.Map and other containers ready to go by the > end of the northern summer? Hello Don, I'm not sure what you're proposing as the SOC project, but I don't think getting AVL based Data.Map/Set clones in Hackage is particularly suitable or challenging. This work is 99% done and also quite boring. It could be finished by the end of today if I set my mind to it :-) There are 3 significant things that really need doing IMO. 1- Try to reconcile the apparent differences between the collections package and Edison class APIs. I don't really understand either myself, but having multiple classes for "the same" things makes both implementors and test suite writers lives harder. The generalised trie class "GT" should still be kept separate as it needs some weird class methods in order to make new instances from old and can't really be finalised until this type families stuff is available anyway. 2- Write a polymorphic test and benchmarking suite for sets, maps, sequences etc. This would be really useful and is something that could reasonably be done as SOC project. But it may also be little boring :-( This could be based on classes defined as a result of 1 (above), or failing that the author would have to define yet another set of class APIs for test/benchmarking only. This may be the simpler approach as it doesn't assume anything about Edison or collections abstractions (it's just a way of testing concrete data structure implementations). 3- Produce some way of automatically deriving (efficient) generalised trie (GT) instances for user defined types. The API is huge and complex (and likely to get bigger still), so hand writing instances really isn't realistic in the long run. But this may be a bit premature for SOC as the GT class API itself is not yet complete or stable, and probably won't be until type families are available (and tested and documented and someone takes the trouble to finish it). So maybe this is something for next years SOC? That said, I know that type families are provisionally available, so maybe doing something with generalised tries might be possible. I don't mind mentoring anyone who wants to do something with any of this. Regards -- Adrian Hey From bf3 at telenet.be Tue Mar 25 13:11:29 2008 From: bf3 at telenet.be (Peter Verswyvelen) Date: Tue Mar 25 13:07:54 2008 Subject: [Haskell-cafe] Terminating GLUT/GLFW programs In-Reply-To: References: <47E75F0D.4090500@telenet.be> Message-ID: <001b01c88e9b$45107280$cf315780$@be> Indeed, the sample from the website does not close correctly when the window is closed; you must press the escape key. This problem has nothing to do with GLFW or the Haskell wrapper, but with the demo, which does not check if the window gets closed. I modified the example code on the wiki so it also exits when the window is closed (the original author might want to check my hack, it's not really clean). Of course this is all rather horrible imperative code :) For nicer alternatives, look at Yampa (the Space Invaders game or the Frag 3D shooter), or Reactive (which I don't understand yet ;-) and other functional reactive programming approaches . > -----Original Message----- > From: hjgtuyl@chello.nl [mailto:hjgtuyl@chello.nl] > Sent: dinsdag 25 maart 2008 0:45 > To: bf3@telenet.be > Cc: haskell-cafe@haskell.org > Subject: Re: [Haskell-cafe] Terminating GLUT/GLFW programs > > > Thanks for the info, but it doesn't solve my problem; I adjusted the > path, > reinstalled GLFW and recompiled the program, but it still does not > terminate. > > Henk-Jan > > > On Mon, 24 Mar 2008 08:58:05 +0100, Peter Verswyvelen > wrote: > > > Hi, > > > > I had a similar (unsolved) problem with GLUT but on my system > (Windows > > XP + GHC 6.8.2) GLFW works fine, exiting is no problem at all. > > > > But when building GLFW, make sure that the GHC gcc-lib directory > comes > > *before* the MinGW/Cygwin directory in your PATH environment > variable, > > since when linking, the LD.EXE bundled with GHC *must* be used. > > > > Cheers, > > Peter > > > > hjgtuyl@chello.nl wrote: > >> > >> L.S., > >> > >> I am trying GLUT and GLFW (on Windows XP, with GHC 6.8.2); the > sample > >> programs do not terminate when I close the window by clicking on the > >> cross in the upper right corner of the window. > >> > >> The sample program for GLUT is at > >> > >> http://blog.mikael.johanssons.org/archive/2006/09/opengl- > programming-in-haskell-a-tutorial-part-1/ > >> the GLFW program: > >> http://haskell.org/haskellwiki/GLFW > >> > >> I tried in the GLUT program: > >> close = exitWith ExitSuccess > >> > >> closeCallback $= Just close -- => User error (unknown GLUT > call > >> getCloseFunc, check for freeglut) > >> > >> this needs freeglut (not documented); I downloaded freeglut.dll and > >> placed it in the windows\system32 directory. The error message > remained. > >> > >> What is needed to let these programs terminate properly? > >> > > > -- > http://functor.bamikanarie.com > http://Van.Tuyl.eu/ > -- > From dan.doel at gmail.com Tue Mar 25 13:20:10 2008 From: dan.doel at gmail.com (Dan Doel) Date: Tue Mar 25 13:16:40 2008 Subject: [Haskell-cafe] Equality constraints in type families In-Reply-To: References: <7b92c2840803101651x3673691eid310ab137805eeff@mail.gmail.com> Message-ID: <200803251320.10381.dan.doel@gmail.com> On Tuesday 11 March 2008, Tom Schrijvers wrote: > I think you've uncovered a bug in the type checker. We made the design > choice that type functions with a higher-kinded result type must be > injective with respect to the additional paramters. I.e. in your case: > > F x y ~ F u v <=> F x ~ F u /\ y ~ v > > So if we apply that to F d c ~ F a (c,a) we get: > > F d ~ F a /\ c ~ (c,a) > > where the latter clearly is an occurs-check error, i.e. there's no finite > type c such that c = (c,a). So the error in the second version is > justified. There should have been one in the latter, but the type checker > failed to do the decomposition: a bug. While I think I understand why this is (due to the difference between index and non-index types), does this mean the following won't type check (it does in 6.8, but I gather its type family implementation wasn't exactly complete)? type family D a :: * type family E a :: * type instance D Int = Char type instance D Char = Int type instance E Char = Char type instance E Int = Int type family F a :: * -> * type instance F Int = D type instance F Char = E foo :: F Int Int ~ F Char Char => a foo = undefined Clearly, both F Int Int ~ Char and F Char Char ~ Char, but neither Int ~ Char nor F Int ~ F Char. Then again, looking at that code, I guess it's an error to have D and E partially applied like that? And one can't write, say: type instance F Int a = D a correct? I suppose that clears up situations where one might be able to construct a specific F X Y ~ F U V, but F X /~ F U \/ Y /~ V (at least, I can't thing of any others off the top of my head). Thanks. -- Dan From dave at zednenem.com Tue Mar 25 14:41:50 2008 From: dave at zednenem.com (David Menendez) Date: Tue Mar 25 14:38:16 2008 Subject: [Haskell-cafe] Equality constraints in type families In-Reply-To: <2240735C-74CC-4F5F-8B38-3402C0C278FF@cse.unsw.edu.au> References: <7b92c2840803101651x3673691eid310ab137805eeff@mail.gmail.com> <00bf01c889e1$b34639b0$b9387ad5@cr3lt> <2240735C-74CC-4F5F-8B38-3402C0C278FF@cse.unsw.edu.au> Message-ID: <49a77b7a0803251141g14b5369bu82623de64664a798@mail.gmail.com> On Mon, Mar 24, 2008 at 12:14 AM, Manuel M T Chakravarty wrote: > One difference between type families and (value-level) functions is > that not all parameters of a type family are treated the same. A type > family has a fixed number of type indicies. We call the number of > type indicies the type family's arity and by convention, the type > indicies come always before other type parameters. In the example > > type family F a :: * -> * > > F has arity 1, whereas > > type family G a b :: * > > has arity 2. So, the number of named parameters given is the arity. > (The overall kind is still F :: * -> * -> *; ie, the arity is not > obvious from the kind, which I am somewhat unhappy about.) Perhaps type families could use a different kind constructor to distinguish type indexes from type parameters. Currently, Haskell kinds are generated by this grammar: kind ::= "*" | kind "->" kind We create a new production for "family kinds", fkind ::= kind | kind "-|>" fkind Now, we can easily distinguish F and G, F :: * -|> * -> * G :: * -|> * -|> * The grammar allows higher-kinded indexes, like (* -> *) -|> *, but requires all indexes to precede the regular parameters. (That is, you can't abstract over a family.) -- Dave Menendez From niklas.broberg at gmail.com Tue Mar 25 15:33:36 2008 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Tue Mar 25 15:30:05 2008 Subject: [Haskell-cafe] ANNOUNCE: Haskell Server Pages v 0.4 Message-ID: Greetings fellow Haskelleers, I am very pleased to announce a new chapter in the Haskell Server Pages saga. After a two-year long hiatus, while we in the team have been busy with Other Stuff, we have resumed work on Project HSP, and this release marks the first milestone. ================= === Project HSP === ================= Haskell Server Pages (HSP) is a programming model for writing dynamic web pages in Haskell, both server-side and client-side. One of its core features is the use of literal XML syntax mixed with ordinary Haskell code. * Project HSP home (with bug/feature tracker): http://code.google.com/p/hsp * Project HSP mailing list: haskell-server-pages@googlegroups.com * Project HSP darcs repos: http://code.haskell.org/HSP For flavor, here is a simple Hello World application written in HSP: ----- module HelloWorld where import HSP import HSP.HJScript import HJScript import HJScript.DOM -- A simple HTML page holding a button with onClick action. page :: HSP XML page = Hello World <% `onClick` (window # alert (string "Hello World !")) %> ----- Note that literal XML elements are first class expressions in HSP, unlike languages like PHP. Also note that using literal XML syntax is by no means required, if you don't feel like writing the XML manually (I sure don't!). There are combinators for building XHTML pages (although they are currently missing from version 0.4, will be added shortly, but release early and all that...). The most interesting new feature in version 0.4 is that literal XML syntax (or the equivalent combinators) can now be used to create XML elements both server-side and client-side, with the same code. Here is another short example script showing this feature: ------------------ module AddParagraph where import HJScript hiding (test) import HJScript.DOM import HSP import HSP.HJScript makeP x =

<% x %>

page :: HSP XML page = Add paragraph <% do (r,b) <- ref <% makeP "Paragraph created Server-side!" %> let fun = do let x = document # getElementById (string r) x <: makeP "Paragraph created Client-side!" return () b <: ( `onClick` fun) %> -------------------- Project HSP v 0.4 consists of a set of packages with related functionality: == package hsx == Haskell Source with XML (HSX, hsx) is a package that contains everything pertaining to literal XML syntax. In particular it contains a) the trhsx preprocessor that translates hsx source files into vanilla Haskell, and b) modules defining the functions that are injected by trhsx. It also nominally contains generic combinators for creating values of the same types as the literal XML syntax, though these modules are not present in 0.4. darcs get --partial http://code.haskell.org/HSP/hsx http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hsx-0.4 == package hsp == The core HSP package defines the datatypes and functions for writing server-side dynamic web pages. Also defines how to use the HJScript functionality in HSP pages, to allow for client-side dynamics as well. darcs get --partial http://code.haskell.org/HSP/hsp http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hsp-0.4 == package HJavaScript == This package defines an abstract syntax and (not-so-)pretty printer for a large subset of JavaScript, as Language.HJavaScript. However, a significant difference from JavaScript is that HJavaScript is typed, even on the abstract syntax level using GADTs. The subset of JavaScript that is supported is those parts that lend themself to typing (i.e. no prototyping of classes). darcs get --partial http://code.haskell.org/HSP/hjavascript http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HJavaScript-0.4 == package HJScript == HJScript is a DSL built on top of HJavaScript, for writing client-side dynamic web pages. The programming model is fairly low-level, resembling the actual JavaScript code quite a lot, but should be easy to extend with higher-level functionality. Notable is that HJScript supports the use of literal XML syntax for creating DOM ElementNodes. Also notable is that HJScript supports Ajax functionality. HJScript and HJavaScript can be used independently of HSP, for creating JavaScript code. darcs get --partial http://code.haskell.org/HSP/hjscript http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HJScript-0.4 == package hsp-cgi == Run HSP pages as CGI scripts. darcs get --partial http://code.haskell.org/HSP/hsp-cgi http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hsp-cgi-0.4 (Note: Earlier versions of HSP have come with a server application, hspr, providing the runtime environment for HSP. As of 0.4, this server has been discontinued and should be considered deprecated.) ===================== Notable items on the TODO list for Project HSP: - More functionality, allowing for higher-level programming models. - Writing larger applications, in order to stress test, and serve as inspiration for higher-level functionality. - Integrate with HAppS, to allow stateful computation (among other things). - A home on the web for HSP, with a web page written in HSP. We welcome both users (of course) and contributors to the project. There is much work to be done, and we welcome all help we can get. If you think this is interesting stuff, drop by our mailing list (haskell-server-pages@googlegroups.com). Like to do web programming in Haskell? Want to do a GSoC project? We in the project would be happy to see applications for HSP projects, and the list above is a good starting place. See for instance (http://hackage.haskell.org/trac/summer-of-code/ticket/1538) and (http://hackage.haskell.org/trac/summer-of-code/ticket/1539). Cheers, /Niklas on behalf of the Project HSP team From ninegua at gmail.com Tue Mar 25 15:37:42 2008 From: ninegua at gmail.com (Paul L) Date: Tue Mar 25 15:34:12 2008 Subject: [Haskell-cafe] Terminating GLUT/GLFW programs In-Reply-To: <001b01c88e9b$45107280$cf315780$@be> References: <47E75F0D.4090500@telenet.be> <001b01c88e9b$45107280$cf315780$@be> Message-ID: <856033f20803251237q2b5366e1vbbd07147e1570371@mail.gmail.com> Peter is right at saying it's the sample GLFW program that didn't handle Window Close event. I didn't double check his modification because I run Linux/X11 with xmonad where there is no CLOSE button for any window, but I trust his modification works fine :-) As for the alternatives, I don't think there is a "nicer" model for general purpose GUI programming in functional style just yet. Yampa is nice in its treatment of continuous signals, but its event handling isn't any better. Sticking to plain-old imperative style with callbacks probably makes most practical sense. -- Regards, Paul Liu Yale Haskell Group http://www.haskell.org/yale From allbery at ece.cmu.edu Tue Mar 25 15:58:24 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Tue Mar 25 15:54:47 2008 Subject: [Haskell-cafe] Parsec (Zero or One of) In-Reply-To: <3CDFB8AFEA98E34CB599475AB11589C80E897C@EX2.ad.dcs.gla.ac.uk> References: <3CDFB8AFEA98E34CB599475AB11589C80E8978@EX2.ad.dcs.gla.ac.uk> <47E91E87.4050700@vex.net> <1206461973.5533.26.camel@derek-laptop> <3CDFB8AFEA98E34CB599475AB11589C80E897C@EX2.ad.dcs.gla.ac.uk> Message-ID: <2347E5ED-05FA-4D6A-84B2-EDD62185A4DE@ece.cmu.edu> On Mar 25, 2008, at 12:43 , Paul Keir wrote: > Thanks. I can't find optionMaybe in my version 2.1 of Parsec, but > in any case, defining my only_prod as > > only_prod = do { reserved "only"; option [] identifier } > > or > > only_prod = do { reserved "only"; identifier <|> return [] } > > gives the same error responses as before. I will anyway look closer > at option. The other problem here is that just using a given string in "reserved" doesn't prevent it from being parsed elsewhere by "identifier". (Note the character offset of the error was 9, i.e. just past "only end", and it was looking for "end" or more identifier characters.) Are you using the higher level parser facilities from Text.ParserCombinators.Parsec.Token, or rolling your own? If the latter, you will need to modify "identifier" to not accept keywords. -- 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 pkeir at dcs.gla.ac.uk Tue Mar 25 16:26:05 2008 From: pkeir at dcs.gla.ac.uk (Paul Keir) Date: Tue Mar 25 16:22:27 2008 Subject: [Haskell-cafe] Parsec (Zero or One of) References: <3CDFB8AFEA98E34CB599475AB11589C80E8978@EX2.ad.dcs.gla.ac.uk> <47E91E87.4050700@vex.net> <1206461973.5533.26.camel@derek-laptop> <3CDFB8AFEA98E34CB599475AB11589C80E897C@EX2.ad.dcs.gla.ac.uk> <2347E5ED-05FA-4D6A-84B2-EDD62185A4DE@ece.cmu.edu> Message-ID: <3CDFB8AFEA98E34CB599475AB11589C80CC9B4@EX2.ad.dcs.gla.ac.uk> Thankyou. Yes, I'd also noticed that "only end" could result in the "end" part being taken as an identifier. The language I'm parsing actually doesn't have reserved words though; so "end" and "only" are both possible valid identifiers. I should then probably replace my use of say, reserved "only", with string "only"; whiteSpace; for clarity. Still stuck though... P -----Original Message----- From: Brandon S. Allbery KF8NH [mailto:allbery@ece.cmu.edu] Sent: Tue 25/03/2008 19:58 To: Paul Keir; haskell-cafe@haskell.org Cafe Subject: Re: [Haskell-cafe] Parsec (Zero or One of) On Mar 25, 2008, at 12:43 , Paul Keir wrote: > Thanks. I can't find optionMaybe in my version 2.1 of Parsec, but > in any case, defining my only_prod as > > only_prod = do { reserved "only"; option [] identifier } > > or > > only_prod = do { reserved "only"; identifier <|> return [] } > > gives the same error responses as before. I will anyway look closer > at option. The other problem here is that just using a given string in "reserved" doesn't prevent it from being parsed elsewhere by "identifier". (Note the character offset of the error was 9, i.e. just past "only end", and it was looking for "end" or more identifier characters.) Are you using the higher level parser facilities from Text.ParserCombinators.Parsec.Token, or rolling your own? If the latter, you will need to modify "identifier" to not accept keywords. -- 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/20080325/25ee0268/attachment.htm From allbery at ece.cmu.edu Tue Mar 25 16:29:55 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Tue Mar 25 16:26:20 2008 Subject: [Haskell-cafe] Parsec (Zero or One of) In-Reply-To: <3CDFB8AFEA98E34CB599475AB11589C80CC9B4@EX2.ad.dcs.gla.ac.uk> References: <3CDFB8AFEA98E34CB599475AB11589C80E8978@EX2.ad.dcs.gla.ac.uk> <47E91E87.4050700@vex.net> <1206461973.5533.26.camel@derek-laptop> <3CDFB8AFEA98E34CB599475AB11589C80E897C@EX2.ad.dcs.gla.ac.uk> <2347E5ED-05FA-4D6A-84B2-EDD62185A4DE@ece.cmu.edu> <3CDFB8AFEA98E34CB599475AB11589C80CC9B4@EX2.ad.dcs.gla.ac.uk> Message-ID: <2388A613-E8F4-4B2A-B6E2-73F4852CDF9B@ece.cmu.edu> On Mar 25, 2008, at 16:26 , Paul Keir wrote: > Thankyou. Yes, I'd also noticed that "only end" could result in the > "end" part being taken as an identifier. The language I'm parsing > actually doesn't have reserved words though; so "end" and "only" > are both possible valid identifiers. I should then probably replace > my use of say, reserved "only", with string "only"; whiteSpace; for > clarity. Still stuck though... > But now you have an ambiguity in your language, which is exactly why the parse is failing: "only end" could be waiting for "end", or for end of file / whatever tokens might follow this clause. In the worst case, the latter might lead to a situation where an unambiguous parse is impossible. You might want to provide a better description of the full language --- and think about how it would need to be implemented to avoid ambiguity. -- 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 Tue Mar 25 16:46:09 2008 From: dons at galois.com (Don Stewart) Date: Tue Mar 25 16:42:59 2008 Subject: [Haskell-cafe] True parallelism missing :-( In-Reply-To: <47E92739.70507@fit.vutbr.cz> References: <47E8F476.2040109@fit.vutbr.cz> <47E90E6E.30407@di.unipi.it> <47E92739.70507@fit.vutbr.cz> Message-ID: <20080325204609.GC31952@scytale.galois.com> To avoid this in future, you can use the strict-concurrency package on hackage, which has some stricter container types, with their strategies. MVars and Chans are the main examples of where a stricter strategy is sometimes useful. kolar: > Yes, that's is. Thanks. My fault - missing wood seeing trees. ;-) > > Best regards, > > Dusan > > Roberto Zunino wrote: > >Dusan Kolar wrote: > >>Dear all, > >> > >> I've thought the following three (dummy) programs would run some of > >>their parts in parallel (on dual core) if compiled with option > >>threaded (smp). The truth is that only the first one exploits > >>multicore CPU. Why? > > > >> h1 <- forkIO $ putMVar v1 $ fibs (n-1) > > > >You are putting an unevaluated thunk in the MVar. Try: > > > >h1 <- forkIO (putMVar v1 $! fibs (n-1)) > > > >Zun. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From ryani.spam at gmail.com Tue Mar 25 17:13:45 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Tue Mar 25 17:10:08 2008 Subject: [Haskell-cafe] Monad instance for Data.Set In-Reply-To: <20080325041937.1BE2AA99B@Adric.metnet.fnmoc.navy.mil> References: <20080325041937.1BE2AA99B@Adric.metnet.fnmoc.navy.mil> Message-ID: <2f9b2d30803251413p568cb4a6o4eb2b4d053c0c805@mail.gmail.com> I was experimenting with Prompt today and found that you can get a "restricted monad" style of behavior out of a regular monad using Prompt: > {-# LANGUAGE GADTs #-} > module SetTest where > import qualified Data.Set as S Prompt is available from http://hackage.haskell.org/cgi-bin/hackage-scripts/package/MonadPrompt-1.0.0.1 > import Control.Monad.Prompt "OrdP" is a prompt that implements MonadPlus for orderable types: > data OrdP m a where > PZero :: OrdP m a > PRestrict :: Ord a => m a -> OrdP m a > PPlus :: Ord a => m a -> m a -> OrdP m a > type SetM = RecPrompt OrdP We can't make this an instance of MonadPlus; mplus would need an Ord constraint. But as long as we don't import it, we can overload the name. > mzero :: SetM a > mzero = prompt PZero > mplus :: Ord a => SetM a -> SetM a -> SetM a > mplus x y = prompt (PPlus x y) "mrestrict" can be inserted at various points in a computation to optimize it; it forces the passed in computation to complete and uses a Set to eliminate duplicate outputs. We could also implement mrestrict without an additional element in our prompt datatype, at the cost of some performance: mrestrict m = mplus mzero m > mrestrict :: Ord a => SetM a -> SetM a > mrestrict x = prompt (PRestrict x) Finally we need an interpretation function to run the monad and extract a set from it: > runSetM :: Ord r => SetM r -> S.Set r > runSetM = runPromptC ret prm . unRecPrompt where > -- ret :: r -> S.Set r > ret = S.singleton > -- prm :: forall a. OrdP SetM a -> (a -> S.Set r) -> S.Set r > prm PZero _ = S.empty > prm (PRestrict m) k = unionMap k (runSetM m) > prm (PPlus m1 m2) k = unionMap k (runSetM m1 `S.union` runSetM m2) unionMap is the equivalent of concatMap for lists. > unionMap :: Ord b => (a -> S.Set b) -> S.Set a -> S.Set b > unionMap f = S.fold (\a r -> f a `S.union` r) S.empty Oleg's test now works without modification: > test1s_do () = do > x <- return "a" > return $ "b" ++ x > olegtest :: S.Set String > olegtest = runSetM $ test1s_do () > -- fromList ["ba"] > settest :: S.Set Int > settest = runSetM $ do > x <- mplus (mplus mzero (return 2)) (mplus (return 2) (return 3)) > return (x+3) > -- fromList [5,6] What this does under the hood is treat the computation on each element of the set separately, except at programmer-specified synchronization points where the computation result is required to be a member of the Ord typeclass. Synchronization points happen at every "mplus" & "mrestrict"; these correspond to a gathering of the computation results up to that point into a Set and then dispatching the remainder of the computation from that Set. -- ryan From dons at galois.com Tue Mar 25 17:17:23 2008 From: dons at galois.com (Don Stewart) Date: Tue Mar 25 17:13:46 2008 Subject: [Haskell-cafe] Re: Libraries need a new owner In-Reply-To: <47E92C46.5020605@iee.org> References: <47497409.6050601@iee.org> <20080324071227.GA9750@scytale.galois.com> <47E92C46.5020605@iee.org> Message-ID: <20080325211723.GH31952@scytale.galois.com> ahey: > Don Stewart wrote: > >ahey: > >>Hello Folks, > >> > >>As some of you will be aware, I have been working on various Map > >>implementations that currently live here.. > >> > >>http://code.haskell.org/collections/collections-ghc6.8 > >> > >>The libs in question being Data.Tree.AVL, Data.Trie.General and a few > >>other bits like Data.COrdering and the AVL based Data.Map/Set clones. > >> > >>Well, I have decided to stop work on these. So they need a new owner if > >>they're going to go anywhere. If anyone is interested in the job then I > >>suggest they contact myself or Jean-Philippe Bernardy. > >> > >>Of course I will be happy to provide any help or advise anyone who takes > >>over these libs may feel they need from me. I might even contribute a > >>few patches from time to time myself :-) > >> > >>Thanks > > > >How about we propose this work be done for Summer of Code. > > > >I've created a ticket here: > > > > http://hackage.haskell.org/trac/summer-of-code/ticket/1549 > > > >Add comments, or if you can mentor, add that information too! > > > >Let's get a new faster Data.Map and other containers ready to go by the > >end of the northern summer? > > Hello Don, > > I'm not sure what you're proposing as the SOC project, but I don't think > getting AVL based Data.Map/Set clones in Hackage is particularly > suitable or challenging. This work is 99% done and also quite boring. > It could be finished by the end of today if I set my mind to it :-) I was more putting it in as a stub for you to round out to a full SoC proposal to work on data structure things.. :) > There are 3 significant things that really need doing IMO. > 1- Try to reconcile the apparent differences between the collections > package and Edison class APIs. I don't really understand either > myself, but having multiple classes for "the same" things makes > both implementors and test suite writers lives harder. > The generalised trie class "GT" should still be kept separate as > it needs some weird class methods in order to make new instances > from old and can't really be finalised until this type families > stuff is available anyway. > > 2- Write a polymorphic test and benchmarking suite for sets, maps, > sequences etc. This would be really useful and is something that > could reasonably be done as SOC project. But it may also be little > boring :-( > This could be based on classes defined as a result of 1 (above), > or failing that the author would have to define yet another set > of class APIs for test/benchmarking only. This may be the simpler > approach as it doesn't assume anything about Edison or collections > abstractions (it's just a way of testing concrete data structure > implementations). > > 3- Produce some way of automatically deriving (efficient) generalised > trie (GT) instances for user defined types. The API is huge and > complex (and likely to get bigger still), so hand writing instances > really isn't realistic in the long run. > But this may be a bit premature for SOC as the GT class API itself > is not yet complete or stable, and probably won't be until type > families are available (and tested and documented and someone > takes the trouble to finish it). > So maybe this is something for next years SOC? > > That said, I know that type families are provisionally available, so > maybe doing something with generalised tries might be possible. > I don't mind mentoring anyone who wants to do something with any of > this. Great! Would you like to revise the Soc ticket, with this information? Getting some usable generalised tries available would be a great result. -- Don From ganesh at earth.li Tue Mar 25 18:10:50 2008 From: ganesh at earth.li (Ganesh Sittampalam) Date: Tue Mar 25 18:07:16 2008 Subject: [Haskell-cafe] Monad instance for Data.Set In-Reply-To: <2f9b2d30803251413p568cb4a6o4eb2b4d053c0c805@mail.gmail.com> References: <20080325041937.1BE2AA99B@Adric.metnet.fnmoc.navy.mil> <2f9b2d30803251413p568cb4a6o4eb2b4d053c0c805@mail.gmail.com> Message-ID: On Tue, 25 Mar 2008, Ryan Ingram wrote: > I was experimenting with Prompt today and found that you can get a > "restricted monad" style of behavior out of a regular monad using Prompt: I recently developed a similar trick: http://hsenag.livejournal.com/11803.html It uses the regular MonadPlus rather than a custom mplus/mzero, and should work for any restricted monad. Your "mrestrict" is "Embed . unEmbed" in my code (and should be given a shorter name, like "reEmbed"). Of course, mplus and mzero can't optimise, since they don't have an Ord constraint. Cheers, Ganesh From lrpalmer at gmail.com Tue Mar 25 18:40:38 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Tue Mar 25 18:37:03 2008 Subject: [Haskell-cafe] Terminating GLUT/GLFW programs In-Reply-To: <856033f20803251237q2b5366e1vbbd07147e1570371@mail.gmail.com> References: <47E75F0D.4090500@telenet.be> <001b01c88e9b$45107280$cf315780$@be> <856033f20803251237q2b5366e1vbbd07147e1570371@mail.gmail.com> Message-ID: <7ca3f0160803251540i55c9935j1370b978af0d1951@mail.gmail.com> On Tue, Mar 25, 2008 at 7:37 PM, Paul L wrote: > Peter is right at saying it's the sample GLFW program that didn't > handle Window Close event. I didn't double check his modification > because I run Linux/X11 with xmonad where there is no CLOSE button for > any window, but I trust his modification works fine :-) Sure there is. The button is just on the keyboard (Ctrl-Shift-C) Luke From lrpalmer at gmail.com Tue Mar 25 18:42:52 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Tue Mar 25 18:39:13 2008 Subject: [Haskell-cafe] Terminating GLUT/GLFW programs In-Reply-To: <7ca3f0160803251540i55c9935j1370b978af0d1951@mail.gmail.com> References: <47E75F0D.4090500@telenet.be> <001b01c88e9b$45107280$cf315780$@be> <856033f20803251237q2b5366e1vbbd07147e1570371@mail.gmail.com> <7ca3f0160803251540i55c9935j1370b978af0d1951@mail.gmail.com> Message-ID: <7ca3f0160803251542s2624f614w64ef8e22a437ce13@mail.gmail.com> Er, not Ctrl, of course... Mod-Shift-C. /me goes to punish his hand for compusive "send" presses. On Tue, Mar 25, 2008 at 10:40 PM, Luke Palmer wrote: > On Tue, Mar 25, 2008 at 7:37 PM, Paul L wrote: > > Peter is right at saying it's the sample GLFW program that didn't > > handle Window Close event. I didn't double check his modification > > because I run Linux/X11 with xmonad where there is no CLOSE button for > > any window, but I trust his modification works fine :-) > > Sure there is. The button is just on the keyboard (Ctrl-Shift-C) > > Luke > From pkeir at dcs.gla.ac.uk Tue Mar 25 19:19:06 2008 From: pkeir at dcs.gla.ac.uk (Paul Keir) Date: Tue Mar 25 19:16:43 2008 Subject: [Haskell-cafe] Parsec (Zero or One of) References: <3CDFB8AFEA98E34CB599475AB11589C80E8978@EX2.ad.dcs.gla.ac.uk> <47E91E87.4050700@vex.net> <1206461973.5533.26.camel@derek-laptop> <3CDFB8AFEA98E34CB599475AB11589C80E897C@EX2.ad.dcs.gla.ac.uk> <2347E5ED-05FA-4D6A-84B2-EDD62185A4DE@ece.cmu.edu> <3CDFB8AFEA98E34CB599475AB11589C80CC9B4@EX2.ad.dcs.gla.ac.uk> <2388A613-E8F4-4B2A-B6E2-73F4852CDF9B@ece.cmu.edu> Message-ID: <3CDFB8AFEA98E34CB599475AB11589C80CC9B6@EX2.ad.dcs.gla.ac.uk> Many thanks. -----Original Message----- From: Brandon S. Allbery KF8NH [mailto:allbery@ece.cmu.edu] Sent: Tue 25/03/2008 20:29 To: Paul Keir; haskell-cafe@haskell.org Cafe Subject: Re: [Haskell-cafe] Parsec (Zero or One of) On Mar 25, 2008, at 16:26 , Paul Keir wrote: > Thankyou. Yes, I'd also noticed that "only end" could result in the > "end" part being taken as an identifier. The language I'm parsing > actually doesn't have reserved words though; so "end" and "only" > are both possible valid identifiers. I should then probably replace > my use of say, reserved "only", with string "only"; whiteSpace; for > clarity. Still stuck though... > But now you have an ambiguity in your language, which is exactly why the parse is failing: "only end" could be waiting for "end", or for end of file / whatever tokens might follow this clause. In the worst case, the latter might lead to a situation where an unambiguous parse is impossible. You might want to provide a better description of the full language --- and think about how it would need to be implemented to avoid ambiguity. -- 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/20080325/b28ac859/attachment.htm From ryani.spam at gmail.com Tue Mar 25 20:04:45 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Tue Mar 25 20:01:07 2008 Subject: [Haskell-cafe] Gtk2hs on GHC6.8.2? In-Reply-To: <20080324122514.A0708B80AC@webmail223.herald.ox.ac.uk> References: <2f9b2d30803240011k1597d9e2sd0d1b7466120a8c0@mail.gmail.com> <20080324122514.A0708B80AC@webmail223.herald.ox.ac.uk> Message-ID: <2f9b2d30803251704q3f195d25t138097b86935a73c@mail.gmail.com> Thanks, works like a charm! -- ryan On 3/24/08, Duncan Coutts wrote: > You are in luck however, I did a build with ghc-6.8.2 just the other day but > hadn't announced it yet: > http://haskell.org/~duncan/gtk2hs/gtk2hs-0.9.12.1.exe From chak at cse.unsw.edu.au Tue Mar 25 20:57:22 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Tue Mar 25 20:53:54 2008 Subject: [Haskell-cafe] Equality constraints in type families In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AB9E0C8B1@EA-EXMSG-C334.europe.corp.microsoft.com> References: <7b92c2840803101651x3673691eid310ab137805eeff@mail.gmail.com><00bf01c889e1$b34639b0$b9387ad5@cr3lt><00cf01c889e6$06ae9fd0$b9387ad5@cr3lt><004d01c88da5$f744a350$ee3d8351@cr3lt> <006e01c88e67$f6afef40$321e7ad5@cr3lt> <638ABD0A29C8884A91BC5FB5C349B1C32AB9E0C8B1@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <41687A81-42E7-4306-BFAA-5D816E1689E1@cse.unsw.edu.au> Simon Peyton-Jones: > | | However, I think I now understand what you are worried about. > It is the > | | interaction of type families and GHC's generalised type synonyms > (i.e., > | | type synonyms that may be partially applied). I agree that it > does lead > | | to an odd interaction, because the outcome may depend on the > order in > | | which the type checker performs various operations. In > particular, > | | whether it first applies a type instance declaration to reduce a > type > | | family application or whether it first performs decomposition. > | > | yes, indeed, thanks! that was the central point of example one. > > Aha. > > Just to clarify, then, GHC's 'generalised type synonyms' behave like > this. > > * H98 says that programmer-written types must obey certain > constraints: > - type synonym applications saturated > - arguments of type applications are monotypes (apart from ->) > > * GHC says that these constraints must be obeyed only > *after* the programmer-written type has been normalised > by expanding saturated type synonyms > > http://www.haskell.org/ghc/docs/latest/html/users_guide/data-type-extensions.html#type-synonyms > > I regard this as a kind of pre-pass, before serious type checking > takes place, so I don't think it should interact with type checking > at all. > > I don't think this normalisation should include type families, > although H98 type synonyms are a kind of degenerate case of type > families. > > Would that design resolve this particular issue? Not quite, but it refines my proposal of requiring that type synonyms in the rhs of type instances need to be saturated. Let me elaborate. The current implementation is wrong, as it permits type S a b = a type family F a :: * -> * type instance F a = S a Why do we need to forbid this type instance? Because it breaks the confluence of equality constraint normalisation. Here are two diverging normalisations: (1) F Int Bool ~ F Int Char ==> DECOMP F Int ~ F Int, Bool ~ Char ==> FAIL (2) F Int Bool ~ F Int Char ==> TOP S Int Bool ~ S Int Char ==> (expand type synonym) Int ~ Int ==> TRIVIAL However, here is a (somewhat silly) program that does have partially applied type synonyms in a type instances' rhs and that is perfectly ok: type S a b = a type family F (a :: * -> *) b :: * -> * type instance F a b = S (S a) b b This is ok, because we can expand the type synonyms in the rhs of the type instance S (S a) b b = S a b = a and get a valid type. So, the crucial point is that, as you wrote, > I don't think this normalisation should include type families, > although H98 type synonyms are a kind of degenerate case of type > families. The only way to stratify the normalisation of type synonyms and type families such that all type synonyms are expanded before any family applications are normalised is by requiring that after normalising the rhs of a type instance declaration *by itself*, we get a type that only contains saturated applications of type synonyms. (As Claus wrote, this is after all what we do for class instance heads.) Manuel From chak at cse.unsw.edu.au Tue Mar 25 21:24:20 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Tue Mar 25 21:21:04 2008 Subject: [Haskell-cafe] Equality constraints in type families In-Reply-To: <006e01c88e67$f6afef40$321e7ad5@cr3lt> References: <7b92c2840803101651x3673691eid310ab137805eeff@mail.gmail.com><00bf01c889e1$b34639b0$b9387ad5@cr3lt><00cf01c889e6$06ae9fd0$b9387ad5@cr3lt><004d01c88da5$f744a350$ee3d8351@cr3lt> <006e01c88e67$f6afef40$321e7ad5@cr3lt> Message-ID: <05107A5B-65C6-4A00-A2D5-7A697EA4113A@cse.unsw.edu.au> Claus Reinke: > one might say that the central point of example two were two > partially applied type synonym families in the same position > (rhs of a type synonym family instance definition). > > usually, when reduction meets typing, there is a subject reduction > theorem, stating that types do not change during reduction. since, > in this case, reduction and constraint generation happen at the > same (type) level, the equivalent would be a proof of confluence, > so that it doesn't matter which type rules are applied in which > order (in this case, decomposition and reduction). Well, we still need normal subject reduction (i.e., types don't change under value term reduction), and we have established that for System FC (in the TLDI paper). In addition, type term normalisation (much like value term normalisation) needs to be confluent; otherwise, you won't get a complete type inference/checking algorithm. > as far as i could determine, the TLDI paper does not deal with > the full generality of ghc's type extensions, so it doesn't stumble > over this issue, and might need elaboration. System FC as described in the paper is GHC's current Core language. What are you missing? > | The most clean solution may indeed be to outlaw partial > applications of > | vanilla type synonyms in the rhes of type instances. (Which is > what I > | will implement unless anybody has a better idea.) > > i always dislike losing expressiveness, and ghc does almost seem > to behave as i would expect in those examples, so perhaps there > is a way to fit the partial applications into the theory of your TLDI > paper. I don't think we can avoid losing that expressiveness, as you demonstrated that it leads to non-confluence of type term normalisation - see also my reply to SimonPJ's message in this thread. > and i still don't like the decomposition rule, and i still don't > even understand that first part about comparing partially applied > type constructors!-) Haskell always had the decomposition rule. Maybe we confused the matter, by always showing a particular instance of the decomposition rule, rather than the general rule. Here it is in all it's glory: t1 t2 ~ t1' t2' <==> t1 ~ t1', t2 ~ t2' No mention of a type family. However, the rule obviously still needs to be correct if we allow any of the type terms (including t1 and t1') to include *saturated* applications of type families. Manuel From chak at cse.unsw.edu.au Tue Mar 25 21:33:26 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Tue Mar 25 21:29:59 2008 Subject: [Haskell-cafe] Equality constraints in type families In-Reply-To: <00c701c88e7e$f3ced0e0$321e7ad5@cr3lt> References: <7b92c2840803101651x3673691eid310ab137805eeff@mail.gmail.com><00bf01c889e1$b34639b0$b9387ad5@cr3lt><00cf01c889e6$06ae9fd0$b9387ad5@cr3lt><004d01c88da5$f744a350$ee3d8351@cr3lt> <008d01c88e6d$57dc8b70$321e7ad5@cr3lt> <00c701c88e7e$f3ced0e0$321e7ad5@cr3lt> Message-ID: <933DC899-6A42-4BE1-ADC5-E52FB1AEC0A9@cse.unsw.edu.au> Claus Reinke wrote, > given that type families are never meant to be partially applied, > perhaps a different notation, avoiding confusion > with type constructor applications in favour of something > resembling products, could make that clearer? > > something simple, like braces to group families and indices: > > type family {F a} :: * -> * > {F x} y ~ {F u} v <=> {F x} ~ {F u} && y ~ v > > would avoid confusion about which parameters need > to be present (no partial application possible) and are > subject to family instance rules, and which parameters are subject > to the decomposition rule. and David Menendez wrote, > erhaps type families could use a different kind constructor to > distinguish type indexes from type parameters. > > Currently, Haskell kinds are generated by this grammar: > > kind ::= "*" | kind "->" kind > > We create a new production for "family kinds", > > fkind ::= kind | kind "-|>" fkind > > Now, we can easily distinguish F and G, > > F :: * -|> * -> * > G :: * -|> * -|> * > > The grammar allows higher-kinded indexes, like (* -> *) -|> *, but > requires all indexes to precede the regular parameters. (That is, you > can't abstract over a family.) Yes, this is something that we thought about, too. In the System FC paper, we subscript all type families with their arity to achieve a weak form of this; ie, we'd write F_1 Int Bool to make clear that (F_1 Int) is a non-decomposable family application, where the outermost application in ((F_1 Int) Bool) is decomposable. The extra syntax has its advantages (more local information) and disadvantages (more clutter). We weren't convinced that we need the extra syntax, so left it out for the moment. However, this is something that can always be changed if experience shows that programs are easier to understand with extra syntax. It doesn't affect the type theory and is really a pure language design question. I'd be glad to hear some more opinions about this matter. Manuel From hpacheco at gmail.com Tue Mar 25 22:07:51 2008 From: hpacheco at gmail.com (Hugo Pacheco) Date: Tue Mar 25 22:04:13 2008 Subject: [Haskell-cafe] Equality constraints in type families In-Reply-To: <933DC899-6A42-4BE1-ADC5-E52FB1AEC0A9@cse.unsw.edu.au> References: <7b92c2840803101651x3673691eid310ab137805eeff@mail.gmail.com> <00bf01c889e1$b34639b0$b9387ad5@cr3lt> <00cf01c889e6$06ae9fd0$b9387ad5@cr3lt> <004d01c88da5$f744a350$ee3d8351@cr3lt> <008d01c88e6d$57dc8b70$321e7ad5@cr3lt> <00c701c88e7e$f3ced0e0$321e7ad5@cr3lt> <933DC899-6A42-4BE1-ADC5-E52FB1AEC0A9@cse.unsw.edu.au> Message-ID: <7b92c2840803251907y159ffcf7t4b8b439701963d06@mail.gmail.com> > The extra syntax has its advantages (more local information) and > disadvantages (more clutter). We weren't convinced that we need the > extra syntax, so left it out for the moment. However, this is > something that can always be changed if experience shows that programs > are easier to understand with extra syntax. It doesn't affect the > type theory and is really a pure language design question. I'd be I would go for the braces as Claus suggested, although not necessary they would have helped me to better understand how type family application behaves. > | The most clean solution may indeed be to outlaw partial > > applications of > > | vanilla type synonyms in the rhes of type instances. (Which is > > what I > > | will implement unless anybody has a better idea.) > > > > i always dislike losing expressiveness, and ghc does almost seem > > to behave as i would expect in those examples, so perhaps there > > is a way to fit the partial applications into the theory of your TLDI > > paper. > > I don't think we can avoid losing that expressiveness, as you > demonstrated that it leads to non-confluence of type term > normalisation - see also my reply to SimonPJ's message in this thread. > glad to hear some more opinions about this matter. Since I was the one to start this thread, I have managed to implement what I initially wanted as F a :: *->* with F a x::*, and the cost of not having partially applied type synonyms was not much apart from some more equality coercions that I wasn't expecting. The most relevant tradeoffs are some more extra parameters in type classes (notice the d in fmapF) and having to bind explicit signatures to variables that only occur as a type-index to the type family (notice id::x->x). class FunctorF x where fmapF :: d -> (a -> b) -> F x a -> F x b fff :: forall d x. (FunctorF d) => d -> F d x -> F d x fff a = fmapF a (id::x->x) Generally, I love type-indexed types. hugo -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080326/dc9ccaf9/attachment.htm From chak at cse.unsw.edu.au Tue Mar 25 22:57:48 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Tue Mar 25 22:54:11 2008 Subject: [Haskell-cafe] Equality constraints in type families In-Reply-To: <200803251320.10381.dan.doel@gmail.com> References: <7b92c2840803101651x3673691eid310ab137805eeff@mail.gmail.com> <200803251320.10381.dan.doel@gmail.com> Message-ID: Dan Doel: > On Tuesday 11 March 2008, Tom Schrijvers wrote: >> I think you've uncovered a bug in the type checker. We made the >> design >> choice that type functions with a higher-kinded result type must be >> injective with respect to the additional paramters. I.e. in your >> case: >> >> F x y ~ F u v <=> F x ~ F u /\ y ~ v >> >> So if we apply that to F d c ~ F a (c,a) we get: >> >> F d ~ F a /\ c ~ (c,a) >> >> where the latter clearly is an occurs-check error, i.e. there's no >> finite >> type c such that c = (c,a). So the error in the second version is >> justified. There should have been one in the latter, but the type >> checker >> failed to do the decomposition: a bug. > > While I think I understand why this is (due to the difference > between index > and non-index types), does this mean the following won't type check > (it does > in 6.8, but I gather its type family implementation wasn't exactly > complete)? > > type family D a :: * > type family E a :: * > > type instance D Int = Char > type instance D Char = Int > > type instance E Char = Char > type instance E Int = Int > > type family F a :: * -> * > > type instance F Int = D > type instance F Char = E > > foo :: F Int Int ~ F Char Char => a > foo = undefined > > Clearly, both F Int Int ~ Char and F Char Char ~ Char, but neither > Int ~ Char > nor F Int ~ F Char. > > Then again, looking at that code, I guess it's an error to have D > and E > partially applied like that? Exactly. > And one can't write, say: > > type instance F Int a = D a > > correct? I suppose that clears up situations where one might be able > to > construct a specific F X Y ~ F U V, but F X /~ F U \/ Y /~ V (at > least, I > can't thing of any others off the top of my head). Yes, this type instance is invalid. However, early version of the type family implementation erroneously accepted such instances. Manuel From golubovsky at gmail.com Wed Mar 26 00:01:41 2008 From: golubovsky at gmail.com (Dimitry Golubovsky) Date: Tue Mar 25 23:58:02 2008 Subject: [Haskell-cafe] Haskell in Web Browser: draft tutorial Message-ID: Hi, I have written a draft of the tutorial on Haskell programming for client side of Web applications (related to Yhc/Javascript backend): http://www.haskell.org/haskellwiki/Haskell_in_web_browser Any feedback, suggestions, and additions (like your own code examples) are welcome. Thanks. PS This part of the Tutorial does not cover XMLHTTP programming; this is yet to be written, but there is Haddock documentation under http://www.golubovsky.org:5984/_utils/yhcws/index.html Yhc web service online (where you may experiment with your code): http://www.golubovsky.org:5984/static/yhcws/MainGUI.html Users guide: http://www.haskell.org/haskellwiki/Yhc_web_service -- Dimitry Golubovsky Anywhere on the Web From simonpj at microsoft.com Wed Mar 26 04:25:54 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed Mar 26 04:21:16 2008 Subject: [Haskell-cafe] Equality constraints in type families In-Reply-To: <41687A81-42E7-4306-BFAA-5D816E1689E1@cse.unsw.edu.au> References: <7b92c2840803101651x3673691eid310ab137805eeff@mail.gmail.com><00bf01c889e1$b34639b0$b9387ad5@cr3lt><00cf01c889e6$06ae9fd0$b9387ad5@cr3lt><004d01c88da5$f744a350$ee3d8351@cr3lt> <006e01c88e67$f6afef40$321e7ad5@cr3lt> <638ABD0A29C8884A91BC5FB5C349B1C32AB9E0C8B1@EA-EXMSG-C334.europe.corp.microsoft.com> <41687A81-42E7-4306-BFAA-5D816E1689E1@cse.unsw.edu.au> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AB9E0CB3E@EA-EXMSG-C334.europe.corp.microsoft.com> | > * GHC says that these constraints must be obeyed only | > *after* the programmer-written type has been normalised | > by expanding saturated type synonyms | > ... | > I regard this as a kind of pre-pass, before serious type checking | > takes place, so I don't think it should interact with type checking | > at all. | > | > I don't think this normalisation should include type families, | > although H98 type synonyms are a kind of degenerate case of type | > families. | > | > Would that design resolve this particular issue? | | Not quite, but it refines my proposal of requiring that type synonyms | in the rhs of type instances need to be saturated. Let me elaborate. Why not quite? | So, the crucial point is that, as you wrote, | | > I don't think this normalisation should include type families, | > although H98 type synonyms are a kind of degenerate case of type | > families. Exactly! Just to state it more clearly again: Any programmer-written type (i.e one forming part of the source text of the program) must obey the following rules: - well-kinded - type synonyms saturated - arguments of type applications are monotypes (but -> is special) However these rules are checked ONLY AFTER EXPANDING SATURATE TYPE SYNONYMS (but doing no reduction on type families) OK, let's try the examples Manuel suggests: | The current implementation is wrong, as it permits | | type S a b = a | type family F a :: * -> * | type instance F a = S a This is illegal because a programmer-written type (the (S a) on the rhs) is an unsaturated type synonym. | type S a b = a | type family F (a :: * -> *) b :: * -> * | type instance F a b = S (S a) b b This is legal because the programmer-written type (S (S a) b b) can be simplified to 'a' by expanding type synonyms. The above checks are performed by checkValidType in TcMType. In particular, the check for saturated synonyms is in check_type (line 1134 or thereabouts). I'm not sure why these checks are not firing for the RHS of a type family declaration. Maybe we aren't calling checkValidType on it. So I think we are agreed. I think the above statement of validity should probably appear in the user manual. Simon From chak at cse.unsw.edu.au Wed Mar 26 05:12:55 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Wed Mar 26 05:09:26 2008 Subject: [Haskell-cafe] Equality constraints in type families In-Reply-To: <7b92c2840803251907y159ffcf7t4b8b439701963d06@mail.gmail.com> References: <7b92c2840803101651x3673691eid310ab137805eeff@mail.gmail.com> <00bf01c889e1$b34639b0$b9387ad5@cr3lt> <00cf01c889e6$06ae9fd0$b9387ad5@cr3lt> <004d01c88da5$f744a350$ee3d8351@cr3lt> <008d01c88e6d$57dc8b70$321e7ad5@cr3lt> <00c701c88e7e$f3ced0e0$321e7ad5@cr3lt> <933DC899-6A42-4BE1-ADC5-E52FB1AEC0A9@cse.unsw.edu.au> <7b92c2840803251907y159ffcf7t4b8b439701963d06@mail.gmail.com> Message-ID: <489568E4-CC05-4F98-B6F2-58781A5293A1@cse.unsw.edu.au> Hugo Pacheco: > Since I was the one to start this thread, I have managed to > implement what I initially wanted as F a :: *->* with F a x::*, and > the cost of not having partially applied type synonyms was not much > apart from some more equality coercions that I wasn't expecting. [..] > Generally, I love type-indexed types. Glad to hear that! Manuel From claus.reinke at talk21.com Wed Mar 26 06:17:04 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Wed Mar 26 06:13:29 2008 Subject: [Haskell-cafe] Equality constraints in type families References: <7b92c2840803101651x3673691eid310ab137805eeff@mail.gmail.com><00bf01c889e1$b34639b0$b9387ad5@cr3lt><00cf01c889e6$06ae9fd0$b9387ad5@cr3lt><004d01c88da5$f744a350$ee3d8351@cr3lt><006e01c88e67$f6afef40$321e7ad5@cr3lt> <05107A5B-65C6-4A00-A2D5-7A697EA4113A@cse.unsw.edu.au> Message-ID: <00e301c88f2a$8b9ed5e0$0c0f7ad5@cr3lt> > Well, we still need normal subject reduction (i.e., types don't change > under value term reduction), and we have established that for System > FC (in the TLDI paper). > > In addition, type term normalisation (much like value term > normalisation) needs to be confluent; otherwise, you won't get a > complete type inference/checking algorithm. if you have separate rules for generating constraints (decomposition) and type term normalisation, that also needs to include confluence of the combined system, which was the issue here, i believe. >> as far as i could determine, the TLDI paper does not deal with >> the full generality of ghc's type extensions, so it doesn't stumble >> over this issue, and might need elaboration. > > System FC as described in the paper is GHC's current Core language. > What are you missing? for now, interaction with pre-Core features, such as generalised type synonyms?-) i just tend to program in ghc Front, not ghc Core;-) later, there'll be other fun, eg, my extensible record code depends on ghc's particular interpretation of the interaction between FDs and overlap resolution, much of Oleg's code depends on a trick that he has isolated in a small group of type equality predicates, carefully exploiting ghc's ideosynchrasies. neither his nor my code works in hugs, even though we nominally use language features supported by both ghc and hugs, even originating in hugs. probably, closed type families can provide better answers to these issues, but until they are here, and their interaction with other ghc type system features has been studied, the idea of mapping FDs to type families has to be taken with a grain of salt, i guess. as with FDs, it isn't a single feature that causes trouble, it is the interaction of many features, combined with real-life programs that stretch the language boundaries they run into. > I don't think we can avoid losing that expressiveness, as you > demonstrated that it leads to non-confluence of type term > normalisation - see also my reply to SimonPJ's message in this thread. i know that we sometimes have to give up features that look nice but have hidden traps - that doesn't mean i have to like it, though!-) > Haskell always had the decomposition rule. Maybe we confused the > matter, by always showing a particular instance of the decomposition > rule, rather than the general rule. Here it is in all it's glory: > > t1 t2 ~ t1' t2' <==> t1 ~ t1', t2 ~ t2' > > No mention of a type family. However, the rule obviously still needs > to be correct if we allow any of the type terms (including t1 and t1') > to include *saturated* applications of type families. before type families, t1 and t1' were straightforward type constructors (unless you include type synonyms, for which the decomposition doesn't apply). with type families, either may be a type-level function, and suddenly it looks as if you are matching on a function application. compare the expression-level: f (Just x) = x -- ok, because 'Just x' is irreducible g (f x) = x -- oops? so what i was missing was that you had arranged matters to exclude some problematic cases from that decomposition rule: - partially applied type synonyms (implicitly, by working in core) - partially applied (in terms of type indices) type families (by a side condition not directly visible in the rule system) in other words, the rule looks too general for what you had in mind, not too specific!-) claus From aneumann at inf.fu-berlin.de Wed Mar 26 06:56:05 2008 From: aneumann at inf.fu-berlin.de (Adrian Neumann) Date: Wed Mar 26 06:52:40 2008 Subject: [Haskell-cafe] HDBC, character encoding Message-ID: <257E3FFB-EF08-4D64-8AD5-4034A2F2250B@inf.fu-berlin.de> Hi, I wrote a CGI program to access a Postgres database using HDBC. The database stores books and I want to display those from a certain author. Everything works fine, unless I search for someone with an umlaut in his name. B?ll, for example. I have a function like this > bookByAuthor :: Connection -> AutorName -> IO [[String]] > bookByAuthor c aName = do > writeFile "./err.log" ((show aName)++" "++(show $ toSql aName)) > rows <- quickQuery c "SELECT * FROM buecher WHERE lower (autor_name) LIKE ? ORDER BY autor_name, buch_name" [toSql $ map toLower $ '%':aName++"%"] > return $ map (map fromSql) rows It returns me a SqlError. However, doing the same in ghci works perfectly. I can't understand why. err.log contains > "b\195\182ll" SqlString "b\195\182ll" which is ok I think. Since > quickQuery c "SELECT * FROM buecher WHERE lower(autor_name) LIKE ? ORDER BY autor_name, buch_name" [toSql "%b\195\182%"] works in ghci. I have tried "b\246ll", but that doesn't even work in ghci, although the database-encoding is utf-8. This all is really annoying... Adrian -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: Signierter Teil der Nachricht Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080326/bb1b3785/PGP.bin From chak at cse.unsw.edu.au Wed Mar 26 07:24:46 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Wed Mar 26 07:21:24 2008 Subject: [Haskell-cafe] Equality constraints in type families In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AB9E0CB3E@EA-EXMSG-C334.europe.corp.microsoft.com> References: <7b92c2840803101651x3673691eid310ab137805eeff@mail.gmail.com><00bf01c889e1$b34639b0$b9387ad5@cr3lt><00cf01c889e6$06ae9fd0$b9387ad5@cr3lt><004d01c88da5$f744a350$ee3d8351@cr3lt> <006e01c88e67$f6afef40$321e7ad5@cr3lt> <638ABD0A29C8884A91BC5FB5C349B1C32AB9E0C8B1@EA-EXMSG-C334.europe.corp.microsoft.com> <41687A81-42E7-4306-BFAA-5D816E1689E1@cse.unsw.edu.au> <638ABD0A29C8884A91BC5FB5C349B1C32AB9E0CB3E@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: Simon Peyton-Jones: > | > * GHC says that these constraints must be obeyed only > | > *after* the programmer-written type has been normalised > | > by expanding saturated type synonyms > | > > ... > | > I regard this as a kind of pre-pass, before serious type checking > | > takes place, so I don't think it should interact with type > checking > | > at all. > | > > | > I don't think this normalisation should include type families, > | > although H98 type synonyms are a kind of degenerate case of type > | > families. > | > > | > Would that design resolve this particular issue? > | > | Not quite, but it refines my proposal of requiring that type > synonyms > | in the rhs of type instances need to be saturated. Let me > elaborate. > > Why not quite? Maybe I was thinking too much in terms of GHC's implementation, but due to the lazy expansion type synonyms, the expansion is interleaved with all the rest of type checking. But I think I now know what you meant: the outcome should be *as if* type synonym expansion was done as a pre-pass. > | So, the crucial point is that, as you wrote, > | > | > I don't think this normalisation should include type families, > | > although H98 type synonyms are a kind of degenerate case of type > | > families. > > Exactly! Just to state it more clearly again: > > Any programmer-written type (i.e one forming part > of the source text of the program) must obey the > following rules: > - well-kinded > - type synonyms saturated > - arguments of type applications are monotypes > (but -> is special) > > However these rules are checked ONLY AFTER EXPANDING > SATURATE TYPE SYNONYMS (but doing no reduction on > type families) I agree. > The above checks are performed by checkValidType in TcMType. In > particular, the check for saturated synonyms is in check_type (line > 1134 or thereabouts). I'm not sure why these checks are not firing > for the RHS of a type family declaration. Maybe we aren't calling > checkValidType on it. I'll check that. Might be an oversight. > So I think we are agreed. I think the above statement of validity > should probably appear in the user manual. Yes, I'll take care of that. Manuel From pkeir at dcs.gla.ac.uk Wed Mar 26 07:32:53 2008 From: pkeir at dcs.gla.ac.uk (Paul Keir) Date: Wed Mar 26 07:29:15 2008 Subject: [Haskell-cafe] No newlines in the whitespace for Parsec lexeme parsers Message-ID: <3CDFB8AFEA98E34CB599475AB11589C80CC9B8@EX2.ad.dcs.gla.ac.uk> Hi, I'm looking to parse a Fortran dialect using Parsec, and was hoping to use the ParsecToken module. Fortran though is unlike the Parsec examples, and prohibits default line continuation (requiring instead an explicit ampersand token &). The lexical parsers of the ParsecToken module skip whitespace after each symbol parsed (lexeme parsers); including the newline. I was thinking of making a minor change to Parsec: In Token.hs, lexeme, whiteSpace, and simpleSpace are defined. lexeme uses whiteSpace which uses simpleSpace. simpleSpace is defined: simpleSpace = skipMany1 (satisfy isSpace) I could replace this locally with: simpleSpace = skipMany1 (satisfy isSpacePlusAmpersandMinusNewline) This approach may have other problems though. Has anyone experience of using Parsec to parse such a language? For example assembly or a preprocessor? Thanks in advance, Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080326/954a535b/attachment-0001.htm From bulat.ziganshin at gmail.com Wed Mar 26 07:42:20 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Mar 26 07:38:44 2008 Subject: [Haskell-cafe] No newlines in the whitespace for Parsec lexeme parsers In-Reply-To: <3CDFB8AFEA98E34CB599475AB11589C80CC9B8@EX2.ad.dcs.gla.ac.uk> References: <3CDFB8AFEA98E34CB599475AB11589C80CC9B8@EX2.ad.dcs.gla.ac.uk> Message-ID: <1918205459.20080326144220@gmail.com> Hello Paul, Wednesday, March 26, 2008, 2:32:53 PM, you wrote: > I'm looking to parse a Fortran dialect using Parsec, and was afair, some months ago BASIC parsing was discussed here. the first solution one can imagine is to add preprocessing stage replacing line ends with ';'-alike -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From simonpj at microsoft.com Wed Mar 26 07:44:33 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed Mar 26 07:40:54 2008 Subject: [Haskell-cafe] Equality constraints in type families In-Reply-To: References: <7b92c2840803101651x3673691eid310ab137805eeff@mail.gmail.com><00bf01c889e1$b34639b0$b9387ad5@cr3lt><00cf01c889e6$06ae9fd0$b9387ad5@cr3lt><004d01c88da5$f744a350$ee3d8351@cr3lt> <006e01c88e67$f6afef40$321e7ad5@cr3lt> <638ABD0A29C8884A91BC5FB5C349B1C32AB9E0C8B1@EA-EXMSG-C334.europe.corp.microsoft.com> <41687A81-42E7-4306-BFAA-5D816E1689E1@cse.unsw.edu.au> <638ABD0A29C8884A91BC5FB5C349B1C32AB9E0CB3E@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AB9E0CD42@EA-EXMSG-C334.europe.corp.microsoft.com> | > Why not quite? | | Maybe I was thinking too much in terms of GHC's implementation, but | due to the lazy expansion type synonyms, the expansion is interleaved | with all the rest of type checking. But I think I now know what you | meant: the outcome should be *as if* type synonym expansion was done | as a pre-pass. Well, validity checking is done when (and only when) converting an HsType to a Type. (The former being a programmer written type.) That's just what we want. It's done by checkValidType, which is not at all interleaved. Once that check is done, the lazy expansion can, I think, be left to itself; no further checking is required. Simon From andrewcoppin at btinternet.com Wed Mar 26 07:47:09 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Wed Mar 26 07:43:14 2008 Subject: [Haskell-cafe] No newlines in the whitespace for Parsec lexeme parsers In-Reply-To: <3CDFB8AFEA98E34CB599475AB11589C80CC9B8@EX2.ad.dcs.gla.ac.uk> References: <3CDFB8AFEA98E34CB599475AB11589C80CC9B8@EX2.ad.dcs.gla.ac.uk> Message-ID: <47EA37BD.4000607@btinternet.com> Paul Keir wrote: > > Hi, > > I'm looking to parse a Fortran dialect using Parsec, and was hoping to > use the ParsecToken module. Fortran though is unlike the Parsec > examples, and prohibits default line continuation (requiring instead > an explicit ampersand token &). The lexical parsers of the ParsecToken > module skip whitespace after each symbol parsed (lexeme parsers); > including the newline. > If you mean Text.ParserCombinators.Parsec.Token, can't you just change the setting of whiteSpace in TokenParser? From allbery at ece.cmu.edu Wed Mar 26 07:47:51 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Wed Mar 26 07:44:12 2008 Subject: [Haskell-cafe] No newlines in the whitespace for Parsec lexeme parsers In-Reply-To: <1918205459.20080326144220@gmail.com> References: <3CDFB8AFEA98E34CB599475AB11589C80CC9B8@EX2.ad.dcs.gla.ac.uk> <1918205459.20080326144220@gmail.com> Message-ID: <1E8A2DE6-54F6-4162-819F-E058CDCA9B7D@ece.cmu.edu> On Mar 26, 2008, at 7:42 , Bulat Ziganshin wrote: > Wednesday, March 26, 2008, 2:32:53 PM, you wrote: >> I'm looking to parse a Fortran dialect using Parsec, and was > > afair, some months ago BASIC parsing was discussed here. > > the first solution one can imagine is to add preprocessing stage > replacing line ends with ';'-alike FWIW I just ignored the lexeme parser and did my own on top of the basic Parsec primitives. You may need to do that anyway if you want to support older variants of Fortran, which don't actually have keywords and ignore spaces outside of string constants (Hollerith constants) --- Parsec's lexeme stuff doesn't even pretend to support 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 andrewcoppin at btinternet.com Wed Mar 26 08:37:53 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Wed Mar 26 08:34:00 2008 Subject: [Haskell-cafe] Unboxed arrays Message-ID: <47EA43A1.4070809@btinternet.com> Somebody asked me, so now I'm asking you... In Haskell, you can make "unboxed" arrays of certain value types. These are typically more efficient in space, and probably time too, and also make the array strict in its values. However, you can only do this magic trick for certain types - not for *all* types. Why is that? Is it because nobody has done anything about it yet? Is it because it's thought to be "not necessary" in some way? Is there some theoretical problem? Has somebody got a better idea? I did think it was along the lines of "oh, well, if you want to unbox a type of your own, you just need to write your own instance". The thing that makes me suspicious of this logic is the absense of an instance for tuples. Surely this would be trivial to write, and yet it's not present. If we had instances for a couple of sizes of tuples, it would surely be quite easy to write your own custom instances that just sit on top of this and tuple/untuple your custom values... Any insights here? From bulat.ziganshin at gmail.com Wed Mar 26 08:53:57 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Mar 26 08:50:22 2008 Subject: [Haskell-cafe] Unboxed arrays In-Reply-To: <47EA43A1.4070809@btinternet.com> References: <47EA43A1.4070809@btinternet.com> Message-ID: <1445656927.20080326155357@gmail.com> Hello Andrew, Wednesday, March 26, 2008, 3:37:53 PM, you wrote: > type of your own, you just need to write your own instance". The thing > that makes me suspicious of this logic is the absense of an instance for > tuples. > Any insights here? and even insiders :) i've rewrote arrays library to be more uniform using ideas of Simon Marlow and Oleg Kiselyov unboxed arrays implementation uses GHC primitives that fetches/stores array element by its index. these primitives implemented for simple types - from Word8 to Double but nothing more. they use *indexes*, not *byte offsets* which means that you can use them for addressing array of {Word8,Double}, for example i believe that it should be possible to rewrite array machinery using storable class (now it should not have any overheads compared to these primitives). meanwhile i recommend you to use storable array together with Storable instances for tuples -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From roma at ro-che.info Wed Mar 26 09:04:43 2008 From: roma at ro-che.info (Roman Cheplyaka) Date: Wed Mar 26 09:01:07 2008 Subject: [Haskell-cafe] Unboxed arrays In-Reply-To: <47EA43A1.4070809@btinternet.com> References: <47EA43A1.4070809@btinternet.com> Message-ID: <20080326130443.GA6675@home.ro-che.info> * Andrew Coppin [2008-03-26 12:37:53+0000] > Somebody asked me, so now I'm asking you... > > In Haskell, you can make "unboxed" arrays of certain value types. These > are typically more efficient in space, and probably time too, and also > make the array strict in its values. However, you can only do this magic > trick for certain types - not for *all* types. > > Why is that? Is it because nobody has done anything about it yet? Is it > because it's thought to be "not necessary" in some way? Is there some > theoretical problem? Has somebody got a better idea? > > I did think it was along the lines of "oh, well, if you want to unbox a > type of your own, you just need to write your own instance". The thing > that makes me suspicious of this logic is the absense of an instance for > tuples. Surely this would be trivial to write, and yet it's not present. > If we had instances for a couple of sizes of tuples, it would surely be > quite easy to write your own custom instances that just sit on top of > this and tuple/untuple your custom values... > > Any insights here? Could Data Parallel Haskell[1] be useful for you? It was designed for parallel computation, but it includes unboxed arrays, nice list-like syntax and array comprehensions. 1. http://www.haskell.org/haskellwiki/GHC/Data_Parallel_Haskell -- Roman I. Cheplyaka :: http://ro-che.info/ ...being in love is totally punk rock... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080326/2ac4ae6c/attachment.bin From lemming at henning-thielemann.de Wed Mar 26 09:22:20 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed Mar 26 09:18:35 2008 Subject: [Haskell-cafe] Unboxed arrays In-Reply-To: <20080326130443.GA6675@home.ro-che.info> References: <47EA43A1.4070809@btinternet.com> <20080326130443.GA6675@home.ro-che.info> Message-ID: On Wed, 26 Mar 2008, Roman Cheplyaka wrote: > * Andrew Coppin [2008-03-26 12:37:53+0000] >> Somebody asked me, so now I'm asking you... >> >> In Haskell, you can make "unboxed" arrays of certain value types. These >> are typically more efficient in space, and probably time too, and also >> make the array strict in its values. However, you can only do this magic >> trick for certain types - not for *all* types. >> >> Why is that? Is it because nobody has done anything about it yet? Is it >> because it's thought to be "not necessary" in some way? Is there some >> theoretical problem? Has somebody got a better idea? >> >> I did think it was along the lines of "oh, well, if you want to unbox a >> type of your own, you just need to write your own instance". The thing >> that makes me suspicious of this logic is the absense of an instance for >> tuples. Surely this would be trivial to write, and yet it's not present. >> If we had instances for a couple of sizes of tuples, it would surely be >> quite easy to write your own custom instances that just sit on top of >> this and tuple/untuple your custom values... >> >> Any insights here? > > Could Data Parallel Haskell[1] be useful for you? > It was designed for parallel computation, but it includes unboxed > arrays, nice list-like syntax and array comprehensions. > > 1. http://www.haskell.org/haskellwiki/GHC/Data_Parallel_Haskell A light-weight unboxed array variant is: http://code.haskell.org/~sjanssen/storablevector/ I thought it might be more efficient sometimes to split, say Word8 and Double data into two arrays, instead of padding data in order to align a (Word8,Double) record, but this wouldn't fit into the array data structure. From andrewcoppin at btinternet.com Wed Mar 26 09:27:46 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Wed Mar 26 09:23:52 2008 Subject: [Haskell-cafe] Unboxed arrays In-Reply-To: <20080326130443.GA6675@home.ro-che.info> References: <47EA43A1.4070809@btinternet.com> <20080326130443.GA6675@home.ro-che.info> Message-ID: <47EA4F52.3040003@btinternet.com> Roman Cheplyaka wrote: > * Andrew Coppin [2008-03-26 12:37:53+0000] > >> Any insights here? >> > > Could Data Parallel Haskell[1] be useful for you? > It was designed for parallel computation, but it includes unboxed > arrays, nice list-like syntax and array comprehensions. > > 1. http://www.haskell.org/haskellwiki/GHC/Data_Parallel_Haskell > Mmm, maybe. Does it implement unboxed arrays for arbitrary types? For that matter, it seems like this NDP stuff has been "in development" for a seemingly long time now. Does anybody know what the current status is? (I'm guessing the people working on this are more interested in working on it than documenting every step of their progress... which leaves outsiders with the impression that nothing is happening.) From voigt at tcs.inf.tu-dresden.de Wed Mar 26 09:33:52 2008 From: voigt at tcs.inf.tu-dresden.de (Janis Voigtlaender) Date: Wed Mar 26 09:30:13 2008 Subject: [Haskell-cafe] Unboxed arrays In-Reply-To: <47EA4F52.3040003@btinternet.com> References: <47EA43A1.4070809@btinternet.com> <20080326130443.GA6675@home.ro-che.info> <47EA4F52.3040003@btinternet.com> Message-ID: <47EA50C0.8040302@tcs.inf.tu-dresden.de> Andrew Coppin wrote: > Roman Cheplyaka wrote: > >> * Andrew Coppin [2008-03-26 12:37:53+0000] >> >> >>> Any insights here? >>> >> >> >> Could Data Parallel Haskell[1] be useful for you? >> It was designed for parallel computation, but it includes unboxed >> arrays, nice list-like syntax and array comprehensions. >> >> 1. http://www.haskell.org/haskellwiki/GHC/Data_Parallel_Haskell >> > > > Mmm, maybe. Does it implement unboxed arrays for arbitrary types? > > For that matter, it seems like this NDP stuff has been "in development" > for a seemingly long time now. Does anybody know what the current status > is? Google -> http://research.microsoft.com/~simonpj/papers/ndp/ > (I'm guessing the people working on this are more interested in > working on it than documenting every step of their progress... which > leaves outsiders with the impression that nothing is happening.) I don't think the above suggests that "nothing is happening" ... -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:voigt@tcs.inf.tu-dresden.de From andrewcoppin at btinternet.com Wed Mar 26 09:58:52 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Wed Mar 26 09:55:01 2008 Subject: [Haskell-cafe] Unboxed arrays In-Reply-To: <47EA50C0.8040302@tcs.inf.tu-dresden.de> References: <47EA43A1.4070809@btinternet.com> <20080326130443.GA6675@home.ro-che.info> <47EA4F52.3040003@btinternet.com> <47EA50C0.8040302@tcs.inf.tu-dresden.de> Message-ID: <47EA569C.5010802@btinternet.com> Janis Voigtlaender wrote: > Google -> http://research.microsoft.com/~simonpj/papers/ndp/ > > I don't think the above suggests that "nothing is happening" ... The latet thing on that page is dated over a year ago. From voigt at tcs.inf.tu-dresden.de Wed Mar 26 10:01:12 2008 From: voigt at tcs.inf.tu-dresden.de (Janis Voigtlaender) Date: Wed Mar 26 09:57:32 2008 Subject: [Haskell-cafe] Unboxed arrays In-Reply-To: <47EA569C.5010802@btinternet.com> References: <47EA43A1.4070809@btinternet.com> <20080326130443.GA6675@home.ro-che.info> <47EA4F52.3040003@btinternet.com> <47EA50C0.8040302@tcs.inf.tu-dresden.de> <47EA569C.5010802@btinternet.com> Message-ID: <47EA5728.9060104@tcs.inf.tu-dresden.de> Andrew Coppin wrote: > Janis Voigtlaender wrote: > >> Google -> http://research.microsoft.com/~simonpj/papers/ndp/ >> >> I don't think the above suggests that "nothing is happening" ... > > > The latet thing on that page is dated over a year ago. Well, if you expect monthly updates... -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:voigt@tcs.inf.tu-dresden.de From Malcolm.Wallace at cs.york.ac.uk Wed Mar 26 09:59:23 2008 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Wed Mar 26 09:59:32 2008 Subject: [Haskell-cafe] [GSoC] student applications deadline approaching Message-ID: <20080326135923.35dfeb33.Malcolm.Wallace@cs.york.ac.uk> Reply-To: haskell-cafe@haskell.org Just to remind students who are interested in Google Summer of Code. Student applications are now open, and the final deadline for submitting your proposals is 2400 UTC, 31st March. http://code.google.com/soc/2008/ Regards, Malcolm From roma at ro-che.info Wed Mar 26 10:23:57 2008 From: roma at ro-che.info (Roman Cheplyaka) Date: Wed Mar 26 10:20:30 2008 Subject: [Haskell-cafe] Unboxed arrays In-Reply-To: References: <47EA43A1.4070809@btinternet.com> <20080326130443.GA6675@home.ro-che.info> Message-ID: <20080326142357.GA7818@home.ro-che.info> * Henning Thielemann [2008-03-26 14:22:20+0100] > > On Wed, 26 Mar 2008, Roman Cheplyaka wrote: > >> * Andrew Coppin [2008-03-26 12:37:53+0000] >>> Somebody asked me, so now I'm asking you... >>> >>> In Haskell, you can make "unboxed" arrays of certain value types. These >>> are typically more efficient in space, and probably time too, and also >>> make the array strict in its values. However, you can only do this magic >>> trick for certain types - not for *all* types. >>> >>> Why is that? Is it because nobody has done anything about it yet? Is it >>> because it's thought to be "not necessary" in some way? Is there some >>> theoretical problem? Has somebody got a better idea? >>> >>> I did think it was along the lines of "oh, well, if you want to unbox a >>> type of your own, you just need to write your own instance". The thing >>> that makes me suspicious of this logic is the absense of an instance for >>> tuples. Surely this would be trivial to write, and yet it's not present. >>> If we had instances for a couple of sizes of tuples, it would surely be >>> quite easy to write your own custom instances that just sit on top of >>> this and tuple/untuple your custom values... >>> >>> Any insights here? >> >> Could Data Parallel Haskell[1] be useful for you? >> It was designed for parallel computation, but it includes unboxed >> arrays, nice list-like syntax and array comprehensions. >> >> 1. http://www.haskell.org/haskellwiki/GHC/Data_Parallel_Haskell > > A light-weight unboxed array variant is: > http://code.haskell.org/~sjanssen/storablevector/ > > > I thought it might be more efficient sometimes to split, say Word8 and > Double data into two arrays, instead of padding data in order to align a > (Word8,Double) record, but this wouldn't fit into the array data > structure. As far as I know, ndp (which I linked above) takes exactly this approach. -- Roman I. Cheplyaka :: http://ro-che.info/ ...being in love is totally punk rock... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080326/49926f2d/attachment.bin From hpacheco at gmail.com Wed Mar 26 10:31:12 2008 From: hpacheco at gmail.com (Hugo Pacheco) Date: Wed Mar 26 10:27:33 2008 Subject: [Haskell-cafe] Type synonyms Message-ID: <7b92c2840803260731v179eec8cj4ee63d85a45b0b67@mail.gmail.com> Hi guys, There is something I think not to fully understand: what are the differences between these two type synonyms? type FInt x = Either One x type FInt = Either One Their kind is the same, so do they differ or are exactly the same type? Thanks, hugo -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080326/6c511339/attachment.htm From dan.doel at gmail.com Wed Mar 26 10:39:35 2008 From: dan.doel at gmail.com (Dan Doel) Date: Wed Mar 26 10:35:56 2008 Subject: [Haskell-cafe] Type synonyms In-Reply-To: <7b92c2840803260731v179eec8cj4ee63d85a45b0b67@mail.gmail.com> References: <7b92c2840803260731v179eec8cj4ee63d85a45b0b67@mail.gmail.com> Message-ID: <200803261039.35746.dan.doel@gmail.com> On Wednesday 26 March 2008, Hugo Pacheco wrote: > Hi guys, > > There is something I think not to fully understand: what are the > differences between these two type synonyms? > > type FInt x = Either One x > type FInt = Either One > > Their kind is the same, so do they differ or are exactly the same type? The difference comes in that type synonyms must be fully applied to all the type parameters listed in their declaration. So, for instance, with the second, you could declare (with a type synonym instances extension), say: instance Monad FInt where ... But you could not with the first, because FInt would be partially applied; the first needs to always appear as 'FInt x' for some x. -- Dan From jed at 59A2.org Wed Mar 26 12:02:28 2008 From: jed at 59A2.org (Jed Brown) Date: Wed Mar 26 11:59:16 2008 Subject: [Haskell-cafe] Unboxed arrays In-Reply-To: References: <47EA43A1.4070809@btinternet.com> <20080326130443.GA6675@home.ro-che.info> Message-ID: <20080326160228.GA10709@brakk.ethz.ch> On Wed 2008-03-26 14:22, Henning Thielemann wrote: > A light-weight unboxed array variant is: > http://code.haskell.org/~sjanssen/storablevector/ There is also CArray which offers an immutable interface for any Storable. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/carray You can also do unsafe (no-copy) freeze/thaw to IOCArray which is equivalent to StorableArray. Unfortunately there is a performance hit to using Storable versus the built in unboxed types. On the other hand, CArray is binary compatible with C which is handy if you are making foreign calls. > I thought it might be more efficient sometimes to split, say Word8 and > Double data into two arrays, instead of padding data in order to align a > (Word8,Double) record, but this wouldn't fit into the array data structure. This depends on the access pattern, but if it makes you miss the cache frequently, then it is certainly not the way to go. For split storage to win, you must frequently traverse while only referencing one entry. It is not clear (to me) how to make an interface where the split storage is hidden, but the compiler can still remove all references to the unused part (without boxing which defeats the purpose). 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/20080326/07073fb3/attachment.bin From bulat.ziganshin at gmail.com Wed Mar 26 12:50:15 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Mar 26 12:47:26 2008 Subject: [Haskell-cafe] Unboxed arrays In-Reply-To: <20080326160228.GA10709@brakk.ethz.ch> References: <47EA43A1.4070809@btinternet.com> <20080326130443.GA6675@home.ro-che.info> <20080326160228.GA10709@brakk.ethz.ch> Message-ID: <1242925819.20080326195015@gmail.com> Hello Jed, Wednesday, March 26, 2008, 7:02:28 PM, you wrote: > StorableArray. Unfortunately there is a performance hit to using Storable > versus the built in unboxed types. are you sure? it was in ghc 6.4, now afair they should be the same. look in http://haskell.org/haskellwiki/Modern_array_libraries -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From jed at 59A2.org Wed Mar 26 13:25:55 2008 From: jed at 59A2.org (Jed Brown) Date: Wed Mar 26 13:22:34 2008 Subject: [Haskell-cafe] Unboxed arrays In-Reply-To: <1242925819.20080326195015@gmail.com> References: <47EA43A1.4070809@btinternet.com> <20080326130443.GA6675@home.ro-che.info> <20080326160228.GA10709@brakk.ethz.ch> <1242925819.20080326195015@gmail.com> Message-ID: <20080326172555.GA17369@brakk.ethz.ch> On Wed 2008-03-26 19:50, Bulat Ziganshin wrote: > Hello Jed, > > Wednesday, March 26, 2008, 7:02:28 PM, you wrote: > > > StorableArray. Unfortunately there is a performance hit to using Storable > > versus the built in unboxed types. > > are you sure? it was in ghc 6.4, now afair they should be the same. > look in http://haskell.org/haskellwiki/Modern_array_libraries The comparison I'm referring to is a micro-benchmark taken from the shootout. I modified the nsieve-bits code here: http://shootout.alioth.debian.org/gp4/benchmark.php?test=nsievebits&lang=ghc&id=0 The shootout code uses STUArray, one modification uses IOCArray, another uses StorableArray (which should be equivalent to IOCArray). Here are some timing results with ghc-6.8.2 on x86_64. $ for e in nsU nsC nsS; do time ./$e 12 > /dev/null; done 1.087 real 1.087 user 0.000 sys 99.96 cpu 3.454 real 3.326 user 0.127 sys 99.98 cpu 3.448 real 3.343 user 0.103 sys 99.94 cpu With ghc-6.8.2 on x86, I get $ for e in nsU nsC nsS; do time ./$e 12 > /dev/null; done ./nsU 12 4.57 real 4.45 user 0.01 sys ./nsC 12 10.46 real 9.88 user 0.27 sys ./nsS 12 10.59 real 9.86 user 0.24 sys That is, the STUArray version (nsU) is much faster than IOCArray (nsC) and StorableArray (nsS) for this test. To see for yourself, checkout CArray darcs get http://code.haskell.org/carray build it, then see the script in tests/runtests.sh. It will build an run these benchmarks, confirming that the output is the same and providing timing information. I would love to see this discrepancy go away, but sadly, it is not there yet. 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/20080326/e287b283/attachment.bin From dons at galois.com Wed Mar 26 13:43:37 2008 From: dons at galois.com (Don Stewart) Date: Wed Mar 26 13:39:58 2008 Subject: [Haskell-cafe] HDBC, character encoding In-Reply-To: <257E3FFB-EF08-4D64-8AD5-4034A2F2250B@inf.fu-berlin.de> References: <257E3FFB-EF08-4D64-8AD5-4034A2F2250B@inf.fu-berlin.de> Message-ID: <20080326174337.GB21456@scytale.galois.com> aneumann: > Hi, > > I wrote a CGI program to access a Postgres database using HDBC. The > database stores books and I want to display those from a certain > author. Everything works fine, unless I search for someone with an > umlaut in his name. B?ll, for example. I have a function like this > > > bookByAuthor :: Connection -> AutorName -> IO [[String]] > > bookByAuthor c aName = do > > writeFile "./err.log" ((show aName)++" "++(show $ toSql aName)) > > rows <- quickQuery c "SELECT * FROM buecher WHERE lower > (autor_name) LIKE ? ORDER BY autor_name, buch_name" [toSql $ map > toLower $ '%':aName++"%"] > > return $ map (map fromSql) rows > > It returns me a SqlError. However, doing the same in ghci works > perfectly. I can't understand why. err.log contains > > > "b\195\182ll" SqlString "b\195\182ll" > > which is ok I think. Since > > > quickQuery c "SELECT * FROM buecher WHERE lower(autor_name) LIKE ? > ORDER BY autor_name, buch_name" [toSql "%b\195\182%"] > > works in ghci. I have tried "b\246ll", but that doesn't even work in > ghci, although the database-encoding is utf-8. This all is really > annoying... Are you using the utf8-string package for necessary IO ? -- Don From iliali16 at gmail.com Wed Mar 26 14:12:46 2008 From: iliali16 at gmail.com (iliali16) Date: Wed Mar 26 14:09:05 2008 Subject: [Haskell-cafe] Wumpus World Message-ID: <16310198.post@talk.nabble.com> Hi guys I have to build the wumpus world problem. I didn't start yet since this is the first time in my life I have to do something like that and I feel not confident in starting it. So I have basic idea of what prolog and haskell can do and I know a bit of Java. I am wandering if you can tell me which one is best to use to build this problem.Thanks couse I am really confused -- View this message in context: http://www.nabble.com/Wumpus-World-tp16310198p16310198.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. From dons at galois.com Wed Mar 26 15:04:15 2008 From: dons at galois.com (Don Stewart) Date: Wed Mar 26 15:00:40 2008 Subject: [Haskell-cafe] Unboxed arrays In-Reply-To: <47EA569C.5010802@btinternet.com> References: <47EA43A1.4070809@btinternet.com> <20080326130443.GA6675@home.ro-che.info> <47EA4F52.3040003@btinternet.com> <47EA50C0.8040302@tcs.inf.tu-dresden.de> <47EA569C.5010802@btinternet.com> Message-ID: <20080326190415.GA27060@scytale.galois.com> andrewcoppin: > Janis Voigtlaender wrote: > >Google -> http://research.microsoft.com/~simonpj/papers/ndp/ > > > >I don't think the above suggests that "nothing is happening" ... > > The latet thing on that page is dated over a year ago. It's very active. See: http://haskell.org/haskellwiki/GHC/Data_Parallel_Haskell and watch the commits coming in from Roman. -- Don From andrewcoppin at btinternet.com Wed Mar 26 16:08:47 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Wed Mar 26 16:04:53 2008 Subject: [Haskell-cafe] Unboxed arrays In-Reply-To: <20080326190415.GA27060@scytale.galois.com> References: <47EA43A1.4070809@btinternet.com> <20080326130443.GA6675@home.ro-che.info> <47EA4F52.3040003@btinternet.com> <47EA50C0.8040302@tcs.inf.tu-dresden.de> <47EA569C.5010802@btinternet.com> <20080326190415.GA27060@scytale.galois.com> Message-ID: <47EAAD4F.9050909@btinternet.com> Don Stewart wrote: > It's very active. See: > > http://haskell.org/haskellwiki/GHC/Data_Parallel_Haskell > > and watch the commits coming in from Roman. > *digs around* Hmm. So in summary, stuff is happening behind the scenes, there's just not a lot of visible activity at the surface. From jsnow at cs.pdx.edu Wed Mar 26 17:33:20 2008 From: jsnow at cs.pdx.edu (Jim Snow) Date: Wed Mar 26 17:28:22 2008 Subject: [Haskell-cafe] announce: Glome.hs raytracer Message-ID: <47EAC120.1050909@cs.pdx.edu> I have recently posted a haskell port of my ocaml raytracer, Glome: http://syn.cs.pdx.edu/~jsnow/glome/ It supports spheres and triangles as base primitives, and is able to parse files in the NFF format used by the standard procedural database (http://tog.acm.org/resources/SPD/). It uses a bounding interval heirarchy acceleration structure, so it can render fairly complicated scenes in a reasonable amount of time. Shadows and reflections are supported, but not specular highlights or refraction. It's still slower than the ocaml version, but at least they're in the same ballpark (and a good part of that difference may be inefficiencies in my BIH traversal). I would welcome any advice on making it go faster or use less memory. I compile the program with "ghc Glome.hs --make -fasm -O2 -threaded -fglasgow-exts -funbox-strict-fields -fbang-patterns -fexcess-precision -optc-ffast-math -optc-O2 -optc-mfpmath=sse -optc-msse2". (I assume the -optc options don't do anything unless you compile via C.) Here are some of my current concerns: -Multi-core parallelism is working, but not as well as I'd expect: I get about a 25% reduction in runtime on two cores rather than 50%. I split the default screen size of 512x512 into 16 blocks, and run "parMap" on those blocks with a function that turns the screen coordinates of that block into a list of (x,y,r,g,b) tuples that get drawn as pixels to the screen through OpenGL by the original thread. -Memory consumption is atrocious: 146 megs to render a scene that's a 33k ascii file. Where does it all go? A heap profile reports the max heap size at a rather more reasonable 500k or so. (My architecture is 64 bit ubuntu on a dual-core amd.) -Collecting rendering stats is not easy without global variables. It occurs to me that it would be neat if there were some sort of write-only global variables that can be incremented by pure code but can only be read from within monadic code; that would be sufficient to ensure that the pure code wasn't affected by the values. The sorts of things I'm looking for are the number of calls to "trace" per image, the number of BIH branches traversed and ray/triangle and ray/sphere intersections per pixel. (Disclaimer: I don't really fully understand monads, so I may be oblivious to an obvious solution.) -Is there a fast way to cast between Float and Double? I'm using Float currently, and the only reason is because that's what the OpenGL api expects. I'd like to be able to use either representation, but the only way to cast that I've found so far is "float_conv x = fromRational(toRational x)", which is too slow. thanks, -jim From dons at galois.com Wed Mar 26 17:45:08 2008 From: dons at galois.com (Don Stewart) Date: Wed Mar 26 17:41:48 2008 Subject: [Haskell-cafe] announce: Glome.hs raytracer In-Reply-To: <47EAC120.1050909@cs.pdx.edu> References: <47EAC120.1050909@cs.pdx.edu> Message-ID: <20080326214508.GA31130@scytale.galois.com> jsnow: > I have recently posted a haskell port of my ocaml raytracer, Glome: > > http://syn.cs.pdx.edu/~jsnow/glome/ > > It supports spheres and triangles as base primitives, and is able to > parse files in the NFF format used by the standard procedural database > (http://tog.acm.org/resources/SPD/). It uses a bounding interval > heirarchy acceleration structure, so it can render fairly complicated > scenes in a reasonable amount of time. Shadows and reflections are > supported, but not specular highlights or refraction. > > It's still slower than the ocaml version, but at least they're in the > same ballpark (and a good part of that difference may be inefficiencies > in my BIH traversal). I would welcome any advice on making it go faster > or use less memory. > > I compile the program with "ghc Glome.hs --make -fasm -O2 -threaded > -fglasgow-exts -funbox-strict-fields -fbang-patterns -fexcess-precision > -optc-ffast-math -optc-O2 -optc-mfpmath=sse -optc-msse2". (I assume the > -optc options don't do anything unless you compile via C.) > > Here are some of my current concerns: > > -Multi-core parallelism is working, but not as well as I'd expect: I get > about a 25% reduction in runtime on two cores rather than 50%. I split > the default screen size of 512x512 into 16 blocks, and run "parMap" on > those blocks with a function that turns the screen coordinates of that > block into a list of (x,y,r,g,b) tuples that get drawn as pixels to the > screen through OpenGL by the original thread. > > -Memory consumption is atrocious: 146 megs to render a scene that's a > 33k ascii file. Where does it all go? A heap profile reports the max > heap size at a rather more reasonable 500k or so. (My architecture is > 64 bit ubuntu on a dual-core amd.) > -Collecting rendering stats is not easy without global variables. It > occurs to me that it would be neat if there were some sort of write-only > global variables that can be incremented by pure code but can only be > read from within monadic code; that would be sufficient to ensure that > the pure code wasn't affected by the values. The sorts of things I'm > looking for are the number of calls to "trace" per image, the number of > BIH branches traversed and ray/triangle and ray/sphere intersections per > pixel. (Disclaimer: I don't really fully understand monads, so I may > be oblivious to an obvious solution.) Use a Writer monad to log statistics? Maybe a State monad. > -Is there a fast way to cast between Float and Double? I'm using Float > currently, and the only reason is because that's what the OpenGL api > expects. I'd like to be able to use either representation, but the only > way to cast that I've found so far is "float_conv x = > fromRational(toRational x)", which is too slow. I'd try realToFrac, which should be pretty much optimised away. With doubles, ensure you use -fexcess-precision -- Don From lemming at henning-thielemann.de Wed Mar 26 17:52:36 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed Mar 26 17:47:40 2008 Subject: [Haskell-cafe] announce: Glome.hs raytracer In-Reply-To: <20080326214508.GA31130@scytale.galois.com> References: <47EAC120.1050909@cs.pdx.edu> <20080326214508.GA31130@scytale.galois.com> Message-ID: On Wed, 26 Mar 2008, Don Stewart wrote: > jsnow: > >> -Is there a fast way to cast between Float and Double? I'm using Float >> currently, and the only reason is because that's what the OpenGL api >> expects. I'd like to be able to use either representation, but the only >> way to cast that I've found so far is "float_conv x = >> fromRational(toRational x)", which is too slow. > > I'd try realToFrac, which should be pretty much optimised away. http://haskell.org/haskellwiki/Converting_numbers From jgbailey at gmail.com Wed Mar 26 17:52:43 2008 From: jgbailey at gmail.com (Justin Bailey) Date: Wed Mar 26 17:49:00 2008 Subject: [Haskell-cafe] announce: Glome.hs raytracer In-Reply-To: <47EAC120.1050909@cs.pdx.edu> References: <47EAC120.1050909@cs.pdx.edu> Message-ID: On Wed, Mar 26, 2008 at 2:33 PM, Jim Snow wrote: > -Memory consumption is atrocious: 146 megs to render a scene that's a > 33k ascii file. Where does it all go? A heap profile reports the max > heap size at a rather more reasonable 500k or so. (My architecture is > 64 bit ubuntu on a dual-core amd.) Try retainer profiling to see who's holding on to memory. To track down a suspect, add SCC annotations and filter the retainer profile to just those annotations (-hC option). Heap profiling is documented at http://haskell.org/ghc/docs/latest/html/users_guide/prof-heap.html Justin From bulat.ziganshin at gmail.com Wed Mar 26 18:09:47 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Mar 26 18:06:11 2008 Subject: [Haskell-cafe] announce: Glome.hs raytracer In-Reply-To: <47EAC120.1050909@cs.pdx.edu> References: <47EAC120.1050909@cs.pdx.edu> Message-ID: <455379655.20080327010947@gmail.com> Hello Jim, Thursday, March 27, 2008, 12:33:20 AM, you wrote: > -Multi-core parallelism is working, but not as well as I'd expect: I get > about a 25% reduction in runtime on two cores rather than 50%. I split this may be an effect of limited memory bandwidth > -Memory consumption is atrocious: 146 megs to render a scene that's a standard answer: ByteString > -Collecting rendering stats is not easy without global variables. It > occurs to me that it would be neat if there were some sort of write-only > global variables that can be incremented by pure code but can only be > read from within monadic code; that would be sufficient to ensure that > the pure code wasn't affected by the values. the code is called *pure* exactly because it has no side-effects and compiler may select either to call some function two times or reuse already computed result. actually, you can make sideeffects with unsafePerformIO, but there is no guarantees of how many times such code will be executed. try this: plus a b = unsafePerformIO (modifyIORef counter (+1)) `seq` a+b -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From derek.a.elkins at gmail.com Wed Mar 26 18:09:45 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Wed Mar 26 18:06:24 2008 Subject: [Haskell-cafe] announce: Glome.hs raytracer In-Reply-To: <20080326214508.GA31130@scytale.galois.com> References: <47EAC120.1050909@cs.pdx.edu> <20080326214508.GA31130@scytale.galois.com> Message-ID: <1206569386.5533.44.camel@derek-laptop> On Wed, 2008-03-26 at 14:45 -0700, Don Stewart wrote: > jsnow: > > I have recently posted a haskell port of my ocaml raytracer, Glome: > > > > http://syn.cs.pdx.edu/~jsnow/glome/ > > > > It supports spheres and triangles as base primitives, and is able to > > parse files in the NFF format used by the standard procedural database > > (http://tog.acm.org/resources/SPD/). It uses a bounding interval > > heirarchy acceleration structure, so it can render fairly complicated > > scenes in a reasonable amount of time. Shadows and reflections are > > supported, but not specular highlights or refraction. > > > > It's still slower than the ocaml version, but at least they're in the > > same ballpark (and a good part of that difference may be inefficiencies > > in my BIH traversal). I would welcome any advice on making it go faster > > or use less memory. > > > > I compile the program with "ghc Glome.hs --make -fasm -O2 -threaded > > -fglasgow-exts -funbox-strict-fields -fbang-patterns -fexcess-precision > > -optc-ffast-math -optc-O2 -optc-mfpmath=sse -optc-msse2". (I assume the > > -optc options don't do anything unless you compile via C.) > > > > Here are some of my current concerns: > > > > -Multi-core parallelism is working, but not as well as I'd expect: I get > > about a 25% reduction in runtime on two cores rather than 50%. I split > > the default screen size of 512x512 into 16 blocks, and run "parMap" on > > those blocks with a function that turns the screen coordinates of that > > block into a list of (x,y,r,g,b) tuples that get drawn as pixels to the > > screen through OpenGL by the original thread. > > > > -Memory consumption is atrocious: 146 megs to render a scene that's a > > 33k ascii file. Where does it all go? A heap profile reports the max > > heap size at a rather more reasonable 500k or so. (My architecture is > > 64 bit ubuntu on a dual-core amd.) > > > -Collecting rendering stats is not easy without global variables. It > > occurs to me that it would be neat if there were some sort of write-only > > global variables that can be incremented by pure code but can only be > > read from within monadic code; that would be sufficient to ensure that > > the pure code wasn't affected by the values. The sorts of things I'm > > looking for are the number of calls to "trace" per image, the number of > > BIH branches traversed and ray/triangle and ray/sphere intersections per > > pixel. (Disclaimer: I don't really fully understand monads, so I may > > be oblivious to an obvious solution.) > > Use a Writer monad to log statistics? Maybe a State monad. > > > -Is there a fast way to cast between Float and Double? I'm using Float > > currently, and the only reason is because that's what the OpenGL api > > expects. I'd like to be able to use either representation, but the only > > way to cast that I've found so far is "float_conv x = > > fromRational(toRational x)", which is too slow. > > I'd try realToFrac, which should be pretty much optimised away. > > With doubles, ensure you use -fexcess-precision Unless something has changed, you also want to be compiling with -fvia-C if you are going to be doing floating point intensive computations. From paul at cogito.org.uk Wed Mar 26 18:37:09 2008 From: paul at cogito.org.uk (Paul Johnson) Date: Wed Mar 26 18:33:31 2008 Subject: [Haskell-cafe] Wumpus World In-Reply-To: <16310198.post@talk.nabble.com> References: <16310198.post@talk.nabble.com> Message-ID: <47EAD015.7000704@cogito.org.uk> iliali16 wrote: > Hi guys I have to build the wumpus world problem. I didn't start yet since > this is the first time in my life I have to do something like that and I > feel not confident in starting it. So I have basic idea of what prolog and > haskell can do and I know a bit of Java. I am wandering if you can tell me > which one is best to use to build this problem.Thanks couse I am really > confused > This sounds like a homework problem. Any of those languages will do. Of course Haskell will be shorter. Jump in, get started. The way to solve a problem you don't understand is to do any bit of it you do understand, and then look at the problem again. Paul. From droundy at darcs.net Wed Mar 26 20:02:39 2008 From: droundy at darcs.net (David Roundy) Date: Wed Mar 26 19:58:58 2008 Subject: [Haskell-cafe] announce: Glome.hs raytracer In-Reply-To: <455379655.20080327010947@gmail.com> References: <47EAC120.1050909@cs.pdx.edu> <455379655.20080327010947@gmail.com> Message-ID: <20080327000238.GG15354@darcs.net> On Thu, Mar 27, 2008 at 01:09:47AM +0300, Bulat Ziganshin wrote: > > -Collecting rendering stats is not easy without global variables. It > > occurs to me that it would be neat if there were some sort of write-only > > global variables that can be incremented by pure code but can only be > > read from within monadic code; that would be sufficient to ensure that > > the pure code wasn't affected by the values. > > the code is called *pure* exactly because it has no side-effects and > compiler may select either to call some function two times or reuse > already computed result. actually, you can make sideeffects with > unsafePerformIO, but there is no guarantees of how many times such > code will be executed. try this: > > plus a b = unsafePerformIO (modifyIORef counter (+1)) `seq` a+b This is exactly what he wants to do. The point of putting traces into the code is precisely to figure out how many times it is called. The only trouble is that unsafePerformIO (I believe) can inhibit optimizations, since there are certain transformations that ghc won't do to unsafePerformIO code. -- David Roundy Department of Physics Oregon State University From dons at galois.com Wed Mar 26 20:07:10 2008 From: dons at galois.com (Don Stewart) Date: Wed Mar 26 20:03:29 2008 Subject: [Haskell-cafe] announce: Glome.hs raytracer In-Reply-To: <20080327000238.GG15354@darcs.net> References: <47EAC120.1050909@cs.pdx.edu> <455379655.20080327010947@gmail.com> <20080327000238.GG15354@darcs.net> Message-ID: <20080327000710.GA6779@scytale.galois.com> droundy: > On Thu, Mar 27, 2008 at 01:09:47AM +0300, Bulat Ziganshin wrote: > > > -Collecting rendering stats is not easy without global variables. It > > > occurs to me that it would be neat if there were some sort of write-only > > > global variables that can be incremented by pure code but can only be > > > read from within monadic code; that would be sufficient to ensure that > > > the pure code wasn't affected by the values. > > > > the code is called *pure* exactly because it has no side-effects and > > compiler may select either to call some function two times or reuse > > already computed result. actually, you can make sideeffects with > > unsafePerformIO, but there is no guarantees of how many times such > > code will be executed. try this: > > > > plus a b = unsafePerformIO (modifyIORef counter (+1)) `seq` a+b > > This is exactly what he wants to do. The point of putting traces into the > code is precisely to figure out how many times it is called. The only > trouble is that unsafePerformIO (I believe) can inhibit optimizations, > since there are certain transformations that ghc won't do to > unsafePerformIO code. could we just use -fhpc or profiling here. HPC at least will tell you how many times top level things are called, and print pretty graphs about it. From droundy at darcs.net Wed Mar 26 20:17:49 2008 From: droundy at darcs.net (David Roundy) Date: Wed Mar 26 20:14:07 2008 Subject: [Haskell-cafe] announce: Glome.hs raytracer In-Reply-To: <20080327000710.GA6779@scytale.galois.com> References: <47EAC120.1050909@cs.pdx.edu> <455379655.20080327010947@gmail.com> <20080327000238.GG15354@darcs.net> <20080327000710.GA6779@scytale.galois.com> Message-ID: <20080327001748.GJ15354@darcs.net> On Wed, Mar 26, 2008 at 05:07:10PM -0700, Don Stewart wrote: > droundy: > > On Thu, Mar 27, 2008 at 01:09:47AM +0300, Bulat Ziganshin wrote: > > > > -Collecting rendering stats is not easy without global variables. It > > > > occurs to me that it would be neat if there were some sort of write-only > > > > global variables that can be incremented by pure code but can only be > > > > read from within monadic code; that would be sufficient to ensure that > > > > the pure code wasn't affected by the values. > > > > > > the code is called *pure* exactly because it has no side-effects and > > > compiler may select either to call some function two times or reuse > > > already computed result. actually, you can make sideeffects with > > > unsafePerformIO, but there is no guarantees of how many times such > > > code will be executed. try this: > > > > > > plus a b = unsafePerformIO (modifyIORef counter (+1)) `seq` a+b > > > > This is exactly what he wants to do. The point of putting traces into the > > code is precisely to figure out how many times it is called. The only > > trouble is that unsafePerformIO (I believe) can inhibit optimizations, > > since there are certain transformations that ghc won't do to > > unsafePerformIO code. > > could we just use -fhpc or profiling here. HPC at least will tell you > how many times top level things are called, and print pretty graphs > about it. It depends what the point is. I've found traces to be very helpful at times when debugging (for instance, to get values as well as counts). Also, I imagine that manual tracing is likely to be far less invasive (if you do it somewhat discretely) than profiling or using hpc. -- David Roundy Department of Physics Oregon State University From jsnow at cs.pdx.edu Wed Mar 26 21:36:18 2008 From: jsnow at cs.pdx.edu (Jim Snow) Date: Wed Mar 26 21:31:21 2008 Subject: [Haskell-cafe] announce: Glome.hs raytracer In-Reply-To: <20080327001748.GJ15354@darcs.net> References: <47EAC120.1050909@cs.pdx.edu> <455379655.20080327010947@gmail.com> <20080327000238.GG15354@darcs.net> <20080327000710.GA6779@scytale.galois.com> <20080327001748.GJ15354@darcs.net> Message-ID: <47EAFA12.90707@cs.pdx.edu> David Roundy wrote: > On Wed, Mar 26, 2008 at 05:07:10PM -0700, Don Stewart wrote: > >> droundy: >> >>> On Thu, Mar 27, 2008 at 01:09:47AM +0300, Bulat Ziganshin wrote: >>> >>>>> -Collecting rendering stats is not easy without global variables. It >>>>> occurs to me that it would be neat if there were some sort of write-only >>>>> global variables that can be incremented by pure code but can only be >>>>> read from within monadic code; that would be sufficient to ensure that >>>>> the pure code wasn't affected by the values. >>>>> >>>> the code is called *pure* exactly because it has no side-effects and >>>> compiler may select either to call some function two times or reuse >>>> already computed result. actually, you can make sideeffects with >>>> unsafePerformIO, but there is no guarantees of how many times such >>>> code will be executed. try this: >>>> >>>> plus a b = unsafePerformIO (modifyIORef counter (+1)) `seq` a+b >>>> >>> This is exactly what he wants to do. The point of putting traces into the >>> code is precisely to figure out how many times it is called. The only >>> trouble is that unsafePerformIO (I believe) can inhibit optimizations, >>> since there are certain transformations that ghc won't do to >>> unsafePerformIO code. >>> >> could we just use -fhpc or profiling here. HPC at least will tell you >> how many times top level things are called, and print pretty graphs >> about it. >> > > It depends what the point is. I've found traces to be very helpful at > times when debugging (for instance, to get values as well as counts). > Also, I imagine that manual tracing is likely to be far less invasive (if > you do it somewhat discretely) than profiling or using hpc. > The unsafePerformIO looks like what I want. Profiling isn't really that helpful in this situation, since sometimes what you want is the number of times something gets called per ray and then add a bit to the color value of the corresponding pixel. Something like this http://syn.cs.pdx.edu/~jsnow/glome/dragon-bih.png tells you a lot more about where your code is spending its time (the bright green places) than some numbers from a profiler. I could return the relevant stats as part of the standard results from ray-intersection tests, but I think that would clutter the code unnecessarily. Thanks everyone for the advice, it'll keep me busy for awhile. I got converted over to doubles, it seems to be about 10% faster or so with -fvia-C than regular floats with -fasm. (I'm using ghc 6.8.2 by the way, which seems to generate faster code than the 6.6.1 version I was using earlier, so maybe the difference between -fasm and -fvia-C isn't as significant as it used to be.) I'm looking into using ByteString, but it doesn't seem compatible with "lex" and "reads". I should probably do more heap profiling before I get too carried away, though. -jim From igloo at earth.li Wed Mar 26 22:49:35 2008 From: igloo at earth.li (Ian Lynagh) Date: Wed Mar 26 22:45:54 2008 Subject: [Haskell-cafe] announce: Glome.hs raytracer In-Reply-To: <47EAC120.1050909@cs.pdx.edu> References: <47EAC120.1050909@cs.pdx.edu> Message-ID: <20080327024935.GA29895@matrix.chaos.earth.li> On Wed, Mar 26, 2008 at 02:33:20PM -0700, Jim Snow wrote: > > -Memory consumption is atrocious: 146 megs to render a scene that's a > 33k ascii file. Where does it all go? A heap profile reports the max > heap size at a rather more reasonable 500k or so. (My architecture is > 64 bit ubuntu on a dual-core amd.) I haven't looked properly yet, but it looks like something is leaking memory that shouldn't be. The attached Gloom.hs uses constant memory, but if you replace the "map" with the commented out "(parMap rnf)" then the memory use seems to keep increasing, even once it has run display once and is running it a second or third time. Thanks Ian -------------- next part -------------- A non-text attachment was scrubbed... Name: Glome.hs Type: text/x-haskell Size: 2016 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080327/60ff70b6/Glome.bin From dekudekuplex at yahoo.com Wed Mar 26 23:23:48 2008 From: dekudekuplex at yahoo.com (Benjamin L. Russell) Date: Wed Mar 26 23:20:06 2008 Subject: [Haskell-cafe] Wumpus World In-Reply-To: <47EAD015.7000704@cogito.org.uk> Message-ID: <370295.79690.qm@web30201.mail.mud.yahoo.com> After briefly searching the Internet and coming up with a page entitled "CIS587: The Wumpus World" (http://www.cis.temple.edu/~ingargio/cis587/readings/wumpus.shtml), I think that since the statement of this problem there, involving the Situation Calculus, chiefly involves a sequence of logical statements with truth values and the relations between the statements, the statements there could perhaps initially be more directly applied with Prolog than with Haskell. However, note that it has been demonstrated in the following book that it is possible to consider logic programming as a natural extension of functional programming as well (although this book is on Scheme, the concepts can be extended to Haskell as well): * Daniel P. Friedman, William E. Byrd and Oleg Kiselyov. _The Reasoned Schemer._ Cambridge, MA: The MIT Press, July 2005. ISBN-10: 0-262-56214-6 ISBN-13: 978-0-262-56214-0 http://mitpress.mit.edu/catalog/item/default.asp?ttype=2&tid=10663 I would suggest that you read about both Prolog and Haskell, take a look at the above book (after first looking at its prerequisite, _The Little Schemer_), and then compare whether you would prefer more directly applying Prolog or using the above book and extending it to apply Haskell. Also, you may wish to keep in mind the following differences between Haskell and Prolog: * Prolog is initially better suited to representing knowledge originally represented as a sequence of logic statements and the relations among them * Haskell is well-suited to writing programs that can be expressed as mathematical functions, and incorporates lazy evaluation, which allows delaying the evaluation of an argument until evaluation is required * Haskell code tends to be more succinct (as Paul Johnson mentioned) * Haskell code tends to run faster, and can often be optimized to run at a speed on par with OCaml * Prolog tends to be one of the slowest-running programming languages I would also suggest that you take a look at the HaskellWiki (http://www.haskell.org/haskellwiki/Haskell), and in particular, at the following example related to logic programming: * HaskellWiki Logic programming example: http://www.haskell.org/haskellwiki/Logic_programming_example Compare this example to examples of Prolog code, and see which one suits your taste. Lastly, when learning Haskell, please try to learn from books, not tutorials. Haskell has a very steep learning curve, and is very difficult to cover adequately in a short tutorial. In particular, I recommend the following titles: * Hudak, Paul. _The Haskell School of Expression._ New York: Cambridge University Press, 2000. http://www.haskell.org/soe/ (Just make sure that you review your trigonometry before reading this book, because some of the exercises in it assume knowledge of trigonometry. I found this book extremely interesting, but discovered that it does assume some domain knowledge in that area.) * Kees Doets and Jan van Eijck. _The Haskell Road to Logic, Maths and Programming._ College Publications, April 2004. http://homepages.cwi.nl/~jve/HR/ A book that uses Haskell as a tool for learning about logic and mathematics. Nevertheless, the book is highly readable, and does a good job of introducing Haskell. It also assumes less domain knowledge than the above book. (Write to me personally if you want more information about this book.) Good luck! Benjamin L. Russell --- Paul Johnson wrote: > iliali16 wrote: > > Hi guys I have to build the wumpus world problem. > I didn't start yet since > > this is the first time in my life I have to do > something like that and I > > feel not confident in starting it. So I have basic > idea of what prolog and > > haskell can do and I know a bit of Java. I am > wandering if you can tell me > > which one is best to use to build this > problem.Thanks couse I am really > > confused > > > This sounds like a homework problem. Any of those > languages will do. > Of course Haskell will be shorter. > > Jump in, get started. The way to solve a problem > you don't understand > is to do any bit of it you do understand, and then > look at the problem > again. > > Paul. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From janeczek at gmail.com Thu Mar 27 01:00:16 2008 From: janeczek at gmail.com (=?UTF-8?Q?Micha=C5=82_Janeczek?=) Date: Thu Mar 27 00:56:35 2008 Subject: [Haskell-cafe] Re: SoC project: Python-Haskell bridge - request for feedback In-Reply-To: <561cb5bc0803241338x25170cffyda72b0d8446a3bb4@mail.gmail.com> References: <561cb5bc0803241338x25170cffyda72b0d8446a3bb4@mail.gmail.com> Message-ID: <561cb5bc0803262200g72f64dcna878fd85bf8037da@mail.gmail.com> Hi, This is my second take on the project proposal. I have expanded on a few points, and hopefully also clarified a little bit. Please comment :) Regards, Michal Python-Haskell bridge ===================== Description ----------- This project will seek to provide a comprehensive, high level (and thus easy to use) binding between Haskell and Python programming languages. This will allow using libraries of either side from each language. If we decide to support function callbacks, these two functionalities (embedding Haskell in Python, and vice versa) become interrelated. In this light, it makes sense to implement them in the scope of the same project. Advantages of calling Haskell from Python ----------------------------------------- * Robust components It might be beneficial to implement safety-critical componenets in a strongly, statically typed language. Since Python itself is a terrific "glue language", such components would usually be purely functional, leaving IO to the Python side. Embedding Haskell code in this way is of particular interest when there already is a large existing Python infrastructure. One can implement new functionality in a form of Haskell plugin/component, even if complete rewrite is not feasible. * Performance improvements for speed-critical code Haskell compiled to native code is typically an order of magnitude faster than Python. Aside from that, advanced language features (such as multicore parallel runtime, very lightweight threads and software transactional memory) further serve to improve the performance. Haskell could become a safe, high level alternative to commonly used C extensions. * Access to sophisticated libraries While its set of libraries is not as comprehensive as that of Python, Haskell can still offer some well tested, efficient libraries. Some of the examples might be: * rich parser combinator libraries (like Parsec) * persistent, functional data structures (i.e. Data.Map, Data.IntMap, Data.Sequence, Data.ByteString) * QuickCheck testing library to drive analysis of Python code Advantages of calling Python from Haskell ----------------------------------------- * Python as a scripting language for Haskell applications Python is widely considered to be more approachable for regular users. As such, it could be used as a configuration/extension language for applications that benefit from extra flexibility. One example of such application is xmonad window manager. * Access to a large number of libraries As a much more popular language, Python has built up an impressive suite of libraries. There already are Haskell projects which rely on Python code to implement missing functionality, for example a paste bin application hpaste, which uses Pygments syntax coloring library. Deliverables ------------ * A low level library to access and manage Python objects from Haskell * Library support for wrapping Haskell values in Python objects. This is necessary to allow function callbacks. In addition, thanks to that feature large and/or lazy data structures can be efficiently passed from Haskell to Python * A set of low level functions to convert built-in data types between Haskell and Python (strings, numbers, lists, dictionaries, generators etc.) * A high level wrapper library for Haskell that simplifies embedding and calling Python code * A set of functions, and possibly a tool, to wrap up monomorphic functions and expose them to Python through foreign export facility * A way (an external tool, or a Template Haskell macro) to easily derive conversion functions for user-defined data types/objects * Documentation and a set of examples for all of above Optional goals -------------- In order of increasing amount of work and decreasing priority: * Exporting a wider class of functions to Python * A Python module that inspects a compiled Haskell module and transparently exposes functions within. This might be possible thanks to GHC API From ok at cs.otago.ac.nz Thu Mar 27 01:15:15 2008 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Thu Mar 27 01:11:41 2008 Subject: [Haskell-cafe] Wumpus World In-Reply-To: <370295.79690.qm@web30201.mail.mud.yahoo.com> References: <370295.79690.qm@web30201.mail.mud.yahoo.com> Message-ID: <938B3F1C-6C2F-4EA2-9AAF-20828D95E187@cs.otago.ac.nz> On 27 Mar 2008, at 4:23 pm, Benjamin L. Russell wrote: > After briefly searching the Internet and coming up > with a page entitled "CIS587: The Wumpus World" > (http://www.cis.temple.edu/~ingargio/cis587/readings/wumpus.shtml), > > I think that since the statement of this problem > there, involving the Situation Calculus, chiefly > involves a sequence of logical statements with truth > values and the relations between the statements, the > statements there could perhaps initially be more > directly applied with Prolog than with Haskell. A solution to the problem is a sequence of actions. In Prolog, action(right). action(left). action(forward). action(shoot). action(grab). action(release). action(climb). solution(Actions) :- initial_state(State0), length(Actions, _), fill_in(Actions, State0). fill_in([], State) :- final_state(State). fill_in([Action|Actions], State0) :- action(Action), effect(Action, State0, State1), fill_in(Actions, State1). Now all that's left is to implement effect(Action, State0, State1), which means "(known) action Action can be carried out in (known) state State0 and results in state State1". By inspection, we can see that [forward,left,forward,forward,grab,left,shoot, left,forward,forward,right,forward,climb] will solve the problem, so we must search to a depth of 13, and have 7 actions to choose from, so a blind iterative-deepening search like this must check on the order of 1.1x10**11 states. > Also, you may wish to keep in mind the following > differences between Haskell and Prolog: [snip] > > > * Haskell code tends to be more succinct (as Paul > Johnson mentioned) Not really an issue for this problem. > > > * Haskell code tends to run faster, and can often be > optimized to run at a speed on par with OCaml > > * Prolog tends to be one of the slowest-running > programming languages That largely depends on which compiler you use and what coding style you follow. I've known Prolog code outperform published Fortran for the same problem, thanks to using a better algorithm that was easy to express in Prolog and practically impossible in Fortran 77. The Prolog results at http://shootout.alioth.debian.org/ are only for the open source system SWI Prolog, which is basically a one-man effort. The commercial SICStus Prolog is substantially faster. Some of the Prolog benchmark versions look distinctly odd. It is certainly true that Prolog can be slow *if* you try to write conventional imperative code in it, which many people do. But then, conventional imperative code isn't the best way to use Haskell either. Prolog's strongly-typed-and-moded brother, Mercury, gives you a combination of - logic programming - strict functional programming - Haskell-like typeclasses which makes it a candidate. However, checking 1.1x10**11 states is going to take a while no matter *what* language you use. Looking at the problem again, we see that if you can get the gold and shoot the wumpus, then you can certainly get out again by retracing your steps, because the pits do not move around. So in the solution [forward,left,forward,forward,grab,left,shoot, left,forward,forward,right,forward,climb] the second line consists of steps that are entirely predictable from the first. So we *really* only have to search to a depth of 7, checking 9.5x10**5 states. That's a speedup of 117649, which is much more than you are going to get from ANY programming language. I should point out that Prolog is not well suited to *directly* expressing rules like Smelly(l1) = > (EXISTS l2 At(Wumpus,l2,s) & (l2=l1 OR Adjacent(l1,l2))) This is going to require some programming. Something that might be rather fun would be feeding the Wumpus World axioms to the free theorem prover OTTER, which is quite impressive. From wrwills at gmail.com Thu Mar 27 03:25:41 2008 From: wrwills at gmail.com (Robert Wills) Date: Thu Mar 27 03:21:59 2008 Subject: [Haskell-cafe] Wumpus World In-Reply-To: <370295.79690.qm@web30201.mail.mud.yahoo.com> References: <370295.79690.qm@web30201.mail.mud.yahoo.com> Message-ID: <47EB4BF5.6070807@gmail.com> This might also be relevant: http://web.engr.oregonstate.edu/~erwig/zurg/ From jvlask at hotmail.com Thu Mar 27 04:13:38 2008 From: jvlask at hotmail.com (john lask) Date: Thu Mar 27 04:09:57 2008 Subject: [Haskell-cafe] FW: containers-0.1.0.1 Message-ID: who is maintainer of containers package ... ---------------------------------------- > From: jvlask@hotmail.com > To: libraries@haskell.org > Subject: containers-0.1.0.1 > Date: Wed, 12 Mar 2008 23:48:33 +0000 > > > > containers-0.1.0.1 will not build with ghc-6.6, the lines > #include "Typeable.h" INSTANCE_TYPEABLE1(Set,setTc,"Set") > > cause a parsing error, due no doubt to Typeable.h being different to 6.8 version > _________________________________________________________________ > What are you waiting for? Join Lavalife FREE > _________________________________________________________________ Are you paid what you're worth? Find out: SEEK Salary Centre http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fninemsn%2Eseek%2Ecom%2Eau%2Fcareer%2Dresources%2Fsalary%2Dcentre%2F%3Ftracking%3Dsk%3Ahet%3Asc%3Anine%3A0%3Ahot%3Atext&_t=764565661&_r=OCT07_endtext_salary&_m=EXT From andrewcoppin at btinternet.com Thu Mar 27 05:27:47 2008 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Thu Mar 27 05:23:51 2008 Subject: [Haskell-cafe] announce: Glome.hs raytracer In-Reply-To: <455379655.20080327010947@gmail.com> References: <47EAC120.1050909@cs.pdx.edu> <455379655.20080327010947@gmail.com> Message-ID: <47EB6893.4010800@btinternet.com> Bulat Ziganshin wrote: > plus a b = unsafePerformIO (modifyIORef counter (+1)) `seq` a+b > Erm... might it be better to use an MVar? (To avoid lost updates if there are multiple render threads.) From bulat.ziganshin at gmail.com Thu Mar 27 05:51:01 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu Mar 27 05:47:21 2008 Subject: [Haskell-cafe] announce: Glome.hs raytracer In-Reply-To: <47EB6893.4010800@btinternet.com> References: <47EAC120.1050909@cs.pdx.edu> <455379655.20080327010947@gmail.com> <47EB6893.4010800@btinternet.com> Message-ID: <1681958761.20080327125101@gmail.com> Hello Andrew, Thursday, March 27, 2008, 12:27:47 PM, you wrote: >> plus a b = unsafePerformIO (modifyIORef counter (+1)) `seq` a+b > Erm... might it be better to use an MVar? (To avoid lost updates if > there are multiple render threads.) you are right, IORef is appropriate only for single-threaded program -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From pkeir at dcs.gla.ac.uk Thu Mar 27 06:38:20 2008 From: pkeir at dcs.gla.ac.uk (Paul Keir) Date: Thu Mar 27 06:34:38 2008 Subject: [Haskell-cafe] No newlines in the whitespace for Parsec lexeme parsers In-Reply-To: <1E8A2DE6-54F6-4162-819F-E058CDCA9B7D@ece.cmu.edu> References: <3CDFB8AFEA98E34CB599475AB11589C80CC9B8@EX2.ad.dcs.gla.ac.uk> <1918205459.20080326144220@gmail.com> <1E8A2DE6-54F6-4162-819F-E058CDCA9B7D@ece.cmu.edu> Message-ID: <3CDFB8AFEA98E34CB599475AB11589C80E898A@EX2.ad.dcs.gla.ac.uk> Thankyou all. Once I get more familiar with Parsec I might do my own lexeme parser. For now I've changed its definition of "simpleSpace" to simpleSpace = skipMany1 (satisfy (\c -> (c /= '\n') && (isSpace c))) so that it skips whitespace, but not newlines. My parser then explicitly matches newlines whenever I need to. Cheers, Paul -----Original Message----- From: Brandon S. Allbery KF8NH [mailto:allbery@ece.cmu.edu] Sent: 26 March 2008 11:48 To: haskell-cafe@haskell.org Cafe; Paul Keir Subject: Re: [Haskell-cafe] No newlines in the whitespace for Parsec lexeme parsers On Mar 26, 2008, at 7:42 , Bulat Ziganshin wrote: > Wednesday, March 26, 2008, 2:32:53 PM, you wrote: >> I'm looking to parse a Fortran dialect using Parsec, and was > > afair, some months ago BASIC parsing was discussed here. > > the first solution one can imagine is to add preprocessing stage > replacing line ends with ';'-alike FWIW I just ignored the lexeme parser and did my own on top of the basic Parsec primitives. You may need to do that anyway if you want to support older variants of Fortran, which don't actually have keywords and ignore spaces outside of string constants (Hollerith constants) --- Parsec's lexeme stuff doesn't even pretend to support 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 mnislaih at gmail.com Thu Mar 27 08:56:57 2008 From: mnislaih at gmail.com (pepe) Date: Thu Mar 27 08:53:16 2008 Subject: [Haskell-cafe] announce: Glome.hs raytracer In-Reply-To: <20080327024935.GA29895@matrix.chaos.earth.li> References: <47EAC120.1050909@cs.pdx.edu> <20080327024935.GA29895@matrix.chaos.earth.li> Message-ID: On 27/03/2008, at 3:49, Ian Lynagh wrote: > On Wed, Mar 26, 2008 at 02:33:20PM -0700, Jim Snow wrote: >> >> -Memory consumption is atrocious: 146 megs to render a scene that's a >> 33k ascii file. Where does it all go? A heap profile reports the >> max >> heap size at a rather more reasonable 500k or so. (My architecture >> is >> 64 bit ubuntu on a dual-core amd.) > > I haven't looked properly yet, but it looks like something is leaking > memory that shouldn't be. The attached Gloom.hs uses constant memory, > but if you replace the "map" with the commented out "(parMap rnf)" > then > the memory use seems to keep increasing, even once it has run display > once and is running it a second or third time. > In my system the leak only appears with +RTS -N1 (which is the default). If I use -N2 or higher, then your version runs in constant memory with (parmap rnf). Cheers pepe From haberg at math.su.se Thu Mar 27 09:40:11 2008 From: haberg at math.su.se (Hans Aberg) Date: Thu Mar 27 09:36:29 2008 Subject: [Haskell-cafe] Recursion problem in infinite list model Message-ID: <7CD6C496-9327-4982-90D3-82240C8BFD28@math.su.se> When experimenting with list index sets (i.e. lists more general than provided by Haskell), I arrived at the problem that in the example code below for example h(list 6) does not (in Hugs) write out the beginning of the list lazily. It does work for list 6 first (list 6) rest (list 6) 10 -+ (list 3) and so on. So it seems to be a problem with h, also suggested by heap profiling, perhaps similar to that of "foldl". So is it possible to fix it? The function h x is derived by unwinding the monadic construct corresponding to (for lists) do {i <- [x..]; return i} So there are not many possibilities of change. Below, (-+) corresponds, for lists, to ":", "first" to "head", and "rest" to "tail". Hans Aberg -------- data List a = List(Integer->a) instance Show a => Show (List a) where show (List f) = "[" ++ show (f(0)) ++ concat ["," ++ show (f(toInteger i))| i<-[1..]] ++ "]" list :: Integer -> List Integer list x = List(\z -> x+z) (-+) :: a -> List a -> List a x -+ (List y) = List(f) where f 0 = x f k = y(k-1) first :: List a -> a first (List f) = f 0 rest :: List a -> List a rest (List y) = List(f) where f k = y(k+1) h :: List a -> List a h x = (-+) (first x) (h (rest x)) -------- From claudiusmaximus at goto10.org Thu Mar 27 10:18:00 2008 From: claudiusmaximus at goto10.org (Claude Heiland-Allen) Date: Thu Mar 27 10:11:13 2008 Subject: [Haskell-cafe] Recursion problem in infinite list model In-Reply-To: <7CD6C496-9327-4982-90D3-82240C8BFD28@math.su.se> References: <7CD6C496-9327-4982-90D3-82240C8BFD28@math.su.se> Message-ID: <47EBAC98.5020709@goto10.org> Hans Aberg wrote: > When experimenting with list index sets (i.e. lists more general than > provided by Haskell), I arrived at the problem that in the example code > below for example > h(list 6) > does not (in Hugs) write out the beginning of the list lazily. It does > work for > list 6 > first (list 6) > rest (list 6) > 10 -+ (list 3) > and so on. So it seems to be a problem with h, also suggested by heap > profiling, perhaps similar to that of "foldl". > > So is it possible to fix it? The function h x is derived by unwinding > the monadic construct corresponding to (for lists) > do {i <- [x..]; return i} > So there are not many possibilities of change. > > Below, (-+) corresponds, for lists, to ":", "first" to "head", and > "rest" to "tail". > > Hans Aberg > > > -------- > data List a = List(Integer->a) > > instance Show a => Show (List a) where > show (List f) = "[" ++ show (f(0)) ++ > concat ["," ++ show (f(toInteger i))| i<-[1..]] ++ "]" > > list :: Integer -> List Integer > list x = List(\z -> x+z) > > (-+) :: a -> List a -> List a > x -+ (List y) = List(f) where > f 0 = x > f k = y(k-1) > > first :: List a -> a > first (List f) = f 0 > > rest :: List a -> List a > rest (List y) = List(f) where > f k = y(k+1) > > h :: List a -> List a > h x = (-+) (first x) (h (rest x)) The combination of (-+) and h is too strict, this modification works: (-+) :: a -> List a -> List a x -+ ~(List y) = List(f) where -- lazy pattern match f 0 = x f k = y(k-1) Claude -- http://claudiusmaximus.goto10.org From ahey at iee.org Thu Mar 27 10:16:25 2008 From: ahey at iee.org (Adrian Hey) Date: Thu Mar 27 10:12:46 2008 Subject: [Haskell-cafe] Re: Libraries need a new owner In-Reply-To: <20080325211723.GH31952@scytale.galois.com> References: <47497409.6050601@iee.org> <20080324071227.GA9750@scytale.galois.com> <47E92C46.5020605@iee.org> <20080325211723.GH31952@scytale.galois.com> Message-ID: <47EBAC39.2030307@iee.org> Don Stewart wrote: >> That said, I know that type families are provisionally available, so >> maybe doing something with generalised tries might be possible. >> I don't mind mentoring anyone who wants to do something with any of >> this. > > Great! Would you like to revise the Soc ticket, with this information? > > Getting some usable generalised tries available would be a great > result. Hello Don, I created a new Generalised Tries specific ticket.. http://hackage.haskell.org/trac/summer-of-code/ticket/1560 Do I need to do more? (not really sure how the whole process works). Who decides if proposals are good/ok/bad? Not me I assume :-) Regards -- Adrian Hey From lrpalmer at gmail.com Thu Mar 27 10:32:23 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Thu Mar 27 10:28:43 2008 Subject: [Haskell-cafe] Recursion problem in infinite list model In-Reply-To: <47EBAC98.5020709@goto10.org> References: <7CD6C496-9327-4982-90D3-82240C8BFD28@math.su.se> <47EBAC98.5020709@goto10.org> Message-ID: <7ca3f0160803270732y5163f102xc2feb4e02865fa2c@mail.gmail.com> On Thu, Mar 27, 2008 at 2:18 PM, Claude Heiland-Allen > The combination of (-+) and h is too strict, this modification works: > > > (-+) :: a -> List a -> List a > x -+ ~(List y) = List(f) where -- lazy pattern match > > f 0 = x > f k = y(k-1) More to the point, if List is declared as: newtype List a = List (Integer -> a) Instead of with "data", it also works. The problem, as was stated, was that -+ is too strict. That is, without the ~ there, -+ evaluates its right argument to make sure it's not _|_ (that is the only other possibility in this case), and then proceeds with the rest of the function. So in: h x = first x -+ h (rest X) This first evaluates the recursive call, which will evaluate the recursive call, which ... Luke From haberg at math.su.se Thu Mar 27 10:41:13 2008 From: haberg at math.su.se (Hans Aberg) Date: Thu Mar 27 10:37:34 2008 Subject: [Haskell-cafe] Recursion problem in infinite list model In-Reply-To: <47EBAC98.5020709@goto10.org> References: <7CD6C496-9327-4982-90D3-82240C8BFD28@math.su.se> <47EBAC98.5020709@goto10.org> Message-ID: <44E07E91-6E9F-401A-8AA4-E4D6EEA80CAC@math.su.se> On 27 Mar 2008, at 15:18, Claude Heiland-Allen wrote: > The combination of (-+) and h is too strict, this modification works: > > (-+) :: a -> List a -> List a > x -+ ~(List y) = List(f) where -- lazy pattern match > f 0 = x > f k = y(k-1) Thank you for the fast response. Yes, that might be what I want. I had a look at lazy patterns, but could not figure out how to put them in. So thanks again. Hans Aberg From haberg at math.su.se Thu Mar 27 10:55:58 2008 From: haberg at math.su.se (Hans Aberg) Date: Thu Mar 27 10:52:24 2008 Subject: [Haskell-cafe] Recursion problem in infinite list model In-Reply-To: <7ca3f0160803270732y5163f102xc2feb4e02865fa2c@mail.gmail.com> References: <7CD6C496-9327-4982-90D3-82240C8BFD28@math.su.se> <47EBAC98.5020709@goto10.org> <7ca3f0160803270732y5163f102xc2feb4e02865fa2c@mail.gmail.com> Message-ID: On 27 Mar 2008, at 15:32, Luke Palmer wrote: > More to the point, if List is declared as: > > newtype List a = List (Integer -> a) > > Instead of with "data", it also works. > > The problem, as was stated, was that -+ is too strict. That is, > without the ~ there, -+ evaluates its right argument to make sure it's > not _|_ (that is the only other possibility in this case), and then > proceeds with the rest of the function. So in: > > h x = first x -+ h (rest X) > > This first evaluates the recursive call, which will evaluate the > recursive call, which ... Thank for the suggestion, and explanation. The reason I used a "data" construct was that I include the size of the list, excluded in order to keep the example as simple as possible: data List a = List(Ordinal -> a, Ordinal) In addition, there seems to be no way to choose default value for a given (non-empty) type in Haskell, so I wrote it data List a = Empty | List(Ordinal -> a, Ordinal) Here, if a type T has a default element t, I can represent the empty list by List(\_ -> t, 0) making the constructor "Empty" redundant. Hans Aberg From miguelimo38 at yandex.ru Thu Mar 27 10:58:34 2008 From: miguelimo38 at yandex.ru (Miguel Mitrofanov) Date: Thu Mar 27 10:55:09 2008 Subject: [Haskell-cafe] Recursion problem in infinite list model In-Reply-To: <7CD6C496-9327-4982-90D3-82240C8BFD28@math.su.se> References: <7CD6C496-9327-4982-90D3-82240C8BFD28@math.su.se> Message-ID: Hmmm, seems like your (-+) is not lazy enough. Since pattern matching is strict by default, you have anything -+ (_|_) = (_|_) Therefore, the function, which is constantly (_|_), is a fixed point for the equation defining h. In other words, if you define h' x = undefined then you have h' x = (-+) anything (h anything) in particular, h' x = (-+) (first x) (h (rest x)) You can fix it by defining (-+) as x -+ ~(List y) = ... > data List a = List(Integer->a) > > instance Show a => Show (List a) where > show (List f) = "[" ++ show (f(0)) ++ > concat ["," ++ show (f(toInteger i))| i<-[1..]] ++ "]" > > list :: Integer -> List Integer > list x = List(\z -> x+z) > > (-+) :: a -> List a -> List a > x -+ (List y) = List(f) where > f 0 = x > f k = y(k-1) > > first :: List a -> a > first (List f) = f 0 > > rest :: List a -> List a > rest (List y) = List(f) where > f k = y(k+1) > > h :: List a -> List a > h x = (-+) (first x) (h (rest x)) > -------- > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From haberg at math.su.se Thu Mar 27 11:12:47 2008 From: haberg at math.su.se (Hans Aberg) Date: Thu Mar 27 11:09:11 2008 Subject: [Haskell-cafe] Recursion problem in infinite list model In-Reply-To: References: <7CD6C496-9327-4982-90D3-82240C8BFD28@math.su.se> Message-ID: <376E9723-6E66-40D3-834D-05CF169AEA9C@math.su.se> On 27 Mar 2008, at 15:58, Miguel Mitrofanov wrote: > Hmmm, seems like your (-+) is not lazy enough. ... > You can fix it by defining (-+) as > > x -+ ~(List y) = ... Yes, this has been pointed out... > > Since pattern matching is strict by default, you have > > anything -+ (_|_) = (_|_) > > Therefore, the function, which is constantly (_|_), is a fixed > point for the equation defining h. In other words, if you define > > h' x = undefined > > then you have > > h' x = (-+) anything (h anything) > > in particular, > > h' x = (-+) (first x) (h (rest x)) But additional explanation is helpful. Thank you. Hans Aberg From hpacheco at gmail.com Thu Mar 27 12:45:22 2008 From: hpacheco at gmail.com (Hugo Pacheco) Date: Thu Mar 27 12:41:39 2008 Subject: [Haskell-cafe] Equality constraints in type families In-Reply-To: <41687A81-42E7-4306-BFAA-5D816E1689E1@cse.unsw.edu.au> References: <7b92c2840803101651x3673691eid310ab137805eeff@mail.gmail.com> <00bf01c889e1$b34639b0$b9387ad5@cr3lt> <00cf01c889e6$06ae9fd0$b9387ad5@cr3lt> <004d01c88da5$f744a350$ee3d8351@cr3lt> <006e01c88e67$f6afef40$321e7ad5@cr3lt> <638ABD0A29C8884A91BC5FB5C349B1C32AB9E0C8B1@EA-EXMSG-C334.europe.corp.microsoft.com> <41687A81-42E7-4306-BFAA-5D816E1689E1@cse.unsw.edu.au> Message-ID: <7b92c2840803270945l7ea4aec7id0489e18a981c392@mail.gmail.com> > > The current implementation is wrong, as it permits > > type S a b = a > type family F a :: * -> * > type instance F a = S a > > Why do we need to forbid this type instance? Because it breaks the > confluence of equality constraint normalisation. Here are two > diverging normalisations: > > (1) > > F Int Bool ~ F Int Char > > ==> DECOMP > > F Int ~ F Int, Bool ~ Char > > ==> FAIL > > > (2) > > F Int Bool ~ F Int Char > > ==> TOP > > S Int Bool ~ S Int Char > > ==> (expand type synonym) > > Int ~ Int > > ==> TRIVIAL > > This does mean that a program such as type FList a = Either One ((,) a) type instance F [a] = FList a will be disallowed in further versions? Doesn't this problem occur only for type synonyms that ignore one or more of the parameters? If so, this could be checked... hugo -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080327/4806d385/attachment.htm From hpacheco at gmail.com Thu Mar 27 12:46:31 2008 From: hpacheco at gmail.com (Hugo Pacheco) Date: Thu Mar 27 12:42:50 2008 Subject: [Haskell-cafe] Equality constraints in type families In-Reply-To: <7b92c2840803270945l7ea4aec7id0489e18a981c392@mail.gmail.com> References: <7b92c2840803101651x3673691eid310ab137805eeff@mail.gmail.com> <00cf01c889e6$06ae9fd0$b9387ad5@cr3lt> <004d01c88da5$f744a350$ee3d8351@cr3lt> <006e01c88e67$f6afef40$321e7ad5@cr3lt> <638ABD0A29C8884A91BC5FB5C349B1C32AB9E0C8B1@EA-EXMSG-C334.europe.corp.microsoft.com> <41687A81-42E7-4306-BFAA-5D816E1689E1@cse.unsw.edu.au> <7b92c2840803270945l7ea4aec7id0489e18a981c392@mail.gmail.com> Message-ID: <7b92c2840803270946g7cb69fe6ue72f1e08e10a9efc@mail.gmail.com> Sorry, I meant type FList a x = Either One (a,x) type instance F [a] = FList a On Thu, Mar 27, 2008 at 4:45 PM, Hugo Pacheco wrote: > > > > The current implementation is wrong, as it permits > > > > type S a b = a > > type family F a :: * -> * > > type instance F a = S a > > > > Why do we need to forbid this type instance? Because it breaks the > > confluence of equality constraint normalisation. Here are two > > diverging normalisations: > > > > (1) > > > > F Int Bool ~ F Int Char > > > > ==> DECOMP > > > > F Int ~ F Int, Bool ~ Char > > > > ==> FAIL > > > > > > (2) > > > > F Int Bool ~ F Int Char > > > > ==> TOP > > > > S Int Bool ~ S Int Char > > > > ==> (expand type synonym) > > > > Int ~ Int > > > > ==> TRIVIAL > > > > This does mean that a program such as > > type FList a = Either One ((,) a) > type instance F [a] = FList a > > will be disallowed in further versions? > Doesn't this problem occur only for type synonyms that ignore one or more > of the parameters? If so, this could be checked... > > hugo > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080327/b0d10751/attachment.htm From lrpalmer at gmail.com Thu Mar 27 12:51:17 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Thu Mar 27 12:47:33 2008 Subject: [Haskell-cafe] Recursion problem in infinite list model In-Reply-To: References: <7CD6C496-9327-4982-90D3-82240C8BFD28@math.su.se> <47EBAC98.5020709@goto10.org> <7ca3f0160803270732y5163f102xc2feb4e02865fa2c@mail.gmail.com> Message-ID: <7ca3f0160803270951y9fb1d26u1ae1977f6bfcbc06@mail.gmail.com> A few comments: On Thu, Mar 27, 2008 at 2:55 PM, Hans Aberg wrote: > The reason I used a "data" construct was that I include the size of > the list, excluded in order to keep the example as simple as possible: > data List a = List(Ordinal -> a, Ordinal) This could still be a newtype, because of the tuple you used here. A more standard way to do this would be: data List a = List (Ordinal -> a) Ordinal Or a record so you could name them. By your naming, am I correct in assuming that you're implementing transfinite lists? If so, cool! > In addition, there seems to be no way to choose default value for a > given (non-empty) type in Haskell, so I wrote it > data List a = Empty | List(Ordinal -> a, Ordinal) > Here, if a type T has a default element t, I can represent the empty > list by > List(\_ -> t, 0) > making the constructor "Empty" redundant. You could use 'undefined', which has value _|_ (if you're sure that it will never be used). List (const undefined) 0 Or even: List undefined 0 Which are almost, but not quite, identical. (Many argue they should be) Luke From jgoerzen at complete.org Thu Mar 27 12:43:50 2008 From: jgoerzen at complete.org (John Goerzen) Date: Thu Mar 27 13:05:16 2008 Subject: [Haskell-cafe] Seeking Daan Leijen Message-ID: I tried to email this to Daan, but his mail is bouncing... Subject: http://legacy.cs.uu.nl/daan/parsec.html Hi Daan, I noticed Parsec 3.0.0 on Hackage, and went to your homepage to read about the new package. But it looks like your homepage still has the old version put out in 2003. This might cause confusion for some that are looking for new releases at your website. Thanks, -- John PS... The HaXml website has the same problem, and has an incompatible API with the version in Hackage... Some Linux distros are using one, some the other. From westondan at imageworks.com Thu Mar 27 14:19:24 2008 From: westondan at imageworks.com (Dan Weston) Date: Thu Mar 27 14:16:01 2008 Subject: [Haskell-cafe] Re: SoC project: Python-Haskell bridge - request for feedback In-Reply-To: <561cb5bc0803262200g72f64dcna878fd85bf8037da@mail.gmail.com> References: <561cb5bc0803241338x25170cffyda72b0d8446a3bb4@mail.gmail.com> <561cb5bc0803262200g72f64dcna878fd85bf8037da@mail.gmail.com> Message-ID: <47EBE52C.3060202@imageworks.com> I notice that you omit from the advantages of calling Haskell from Python what I consider the most important reason of all (at least from the Haskell community side). The choice of programming language (at least at the top level) is primarily a political or managerial choice, not a technical one. Python is not merely a "terrific glue language", it is often the "blessed" language, and currently the language of choice in some industries, including my own. This is not just "glue code" either: one in-house application has about 100,000 lines of Python code (calling a comparable amount of C++ code)! Any hope of introducing Haskell into this realm requires a way to work Haskell in slowly and from the bottom. As such I view your proposed project as quite valuable, a robust and easy-to-use Python-Haskell bridge (Python on top) being essential to growing the presence of Haskell in non-academic circles. Of course, it may be for this very political reason that you have omitted the above from your list, in which case I completely understand. :) Dan Micha? Janeczek wrote: > Hi, > > This is my second take on the project proposal. > I have expanded on a few points, and hopefully > also clarified a little bit. > > Please comment :) > > Regards, > Michal > > > Python-Haskell bridge > ===================== > > Description > ----------- > > This project will seek to provide a comprehensive, high level (and thus > easy to use) binding between Haskell and Python programming languages. > This will allow using libraries of either side from each language. > > If we decide to support function callbacks, these two functionalities > (embedding Haskell in Python, and vice versa) become interrelated. > In this light, it makes sense to implement them in the scope of the > same project. > > > Advantages of calling Haskell from Python > ----------------------------------------- > > * Robust components > > It might be beneficial to implement safety-critical componenets > in a strongly, statically typed language. Since Python itself is > a terrific "glue language", such components would usually be purely > functional, leaving IO to the Python side. > Embedding Haskell code in this way is of particular interest when > there already is a large existing Python infrastructure. One can > implement new functionality in a form of Haskell plugin/component, > even if complete rewrite is not feasible. > > * Performance improvements for speed-critical code > > Haskell compiled to native code is typically an order of magnitude > faster than Python. Aside from that, advanced language features > (such as multicore parallel runtime, very lightweight threads > and software transactional memory) further serve to improve the > performance. Haskell could become a safe, high level alternative > to commonly used C extensions. > > * Access to sophisticated libraries > > While its set of libraries is not as comprehensive as that of > Python, Haskell can still offer some well tested, efficient > libraries. Some of the examples might be: > > * rich parser combinator libraries (like Parsec) > * persistent, functional data structures (i.e. Data.Map, > Data.IntMap, Data.Sequence, Data.ByteString) > * QuickCheck testing library to drive analysis of Python code > > > Advantages of calling Python from Haskell > ----------------------------------------- > > * Python as a scripting language for Haskell applications > > Python is widely considered to be more approachable for regular > users. As such, it could be used as a configuration/extension > language for applications that benefit from extra flexibility. > One example of such application is xmonad window manager. > > * Access to a large number of libraries > > As a much more popular language, Python has built up an impressive > suite of libraries. There already are Haskell projects which rely > on Python code to implement missing functionality, for example > a paste bin application hpaste, which uses Pygments syntax coloring > library. > > > Deliverables > ------------ > > * A low level library to access and manage Python objects from Haskell > > * Library support for wrapping Haskell values in Python objects. This > is necessary to allow function callbacks. In addition, thanks to that > feature large and/or lazy data structures can be efficiently passed > from Haskell to Python > > * A set of low level functions to convert built-in data types between > Haskell and Python (strings, numbers, lists, dictionaries, > generators etc.) > > * A high level wrapper library for Haskell that simplifies embedding > and calling Python code > > * A set of functions, and possibly a tool, to wrap up monomorphic > functions and expose them to Python through foreign export facility > > * A way (an external tool, or a Template Haskell macro) to easily > derive conversion functions for user-defined data types/objects > > * Documentation and a set of examples for all of above > > > Optional goals > -------------- > > In order of increasing amount of work and decreasing priority: > > * Exporting a wider class of functions to Python > > * A Python module that inspects a compiled Haskell module and > transparently exposes functions within. This might be possible > thanks to GHC API > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From donnie at darthik.com Thu Mar 27 14:23:34 2008 From: donnie at darthik.com (Donnie Jones) Date: Thu Mar 27 14:19:52 2008 Subject: [Haskell-cafe] GSoC Project Proposal: Parallel Profiling Tools for GHC. Message-ID: Hello Everyone,GSoC Project: Parallel Profiling Tools for GHC. Student: Donnie Jones Mentor: Simon Marlow Project based upon suggestion by Simon Marlow: http://hackage.haskell.org/trac/summer-of-code/ticket/1559 Overview: For Haskell there are currently no tools to investigate the performance of parallel programs. This project would extend the Haskell compiler GHC to support profiling of parallel programs. Parallel programs are inherently difficult to analyze and the prevalence of multi-core processors has increased the need for tools to facilitate gaining performance from parallelism. The ability to profile parallel programs in GHC could lead to improvements in GHC's RTS, and insights into writing parallel Haskell code. Goals: * Investigate the use of the GranSim framework for parallel profiling in GHC i. Decide what is needed to commit the GranSim port to the GHC tree i. Build additional profiling tools upon the GranSim framework * Testing of performance hit accrued from parallel profiling i. Investigate improving performance, possible modifications to GranSim port * Construct tests to measure the performance improvements of parallel programs i. Building benchmarks for parallel programs, related to ticket: http://hackage.haskell.org/trac/summer-of-code/ticket/1544 * Improve upon GranSim visualization of profiles to clarify parallel profiling i. Possibly add new visualization profiles, if time allows I am sure that further details will need to be developed with the help of Simon Marlow; however, I am unsure if some of these details can be defined without first investigating the potential use of GranSim. I look forward to your feedback. Thank you. __ Donnie Jones -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080327/bc022e50/attachment.htm From haberg at math.su.se Thu Mar 27 14:24:18 2008 From: haberg at math.su.se (Hans Aberg) Date: Thu Mar 27 14:20:38 2008 Subject: [Haskell-cafe] Recursion problem in infinite list model In-Reply-To: <7ca3f0160803270951y9fb1d26u1ae1977f6bfcbc06@mail.gmail.com> References: <7CD6C496-9327-4982-90D3-82240C8BFD28@math.su.se> <47EBAC98.5020709@goto10.org> <7ca3f0160803270732y5163f102xc2feb4e02865fa2c@mail.gmail.com> <7ca3f0160803270951y9fb1d26u1ae1977f6bfcbc06@mail.gmail.com> Message-ID: <1458B555-C079-450F-8EDC-B06EE810FF67@math.su.se> On 27 Mar 2008, at 17:51, Luke Palmer wrote: > By your naming, am I correct in assuming that you're implementing > transfinite lists? > If so, cool! Yes, it is an old idea I brought up now. If list length is written also for infinite lists, then concatenated lists get indexed by the sum of their ordinals (and length too). So length x does not cause non-termination if x is an infinite list, but a value. In addition, one needs to restrict to singly linked lists; a list is essentially a cashed lazy function. I wrote a class Ordinal for ordinals below epsilon_0, which are the ones generated by the first uncountable ordinal (the set of natural numbers), and ordinal sum, product and exponentiation, which can be represented explicitly using CNF (Cantor's normal form). These are not large in mathematical terms, but in computers, I think they will suffice a long go. I haven't debugged it yet. But if somebody is interested, just let me know. I think Haskell should have such a module, worked up by computer programmers, who surely can do a better job than me :-). Small ordinal infinities arise naturally when one has say orders f floating windows, or and TeX has (I think) orders of stretchability. >> The reason I used a "data" construct was that I include the size of >> the list, excluded in order to keep the example as simple as >> possible: >> data List a = List(Ordinal -> a, Ordinal) > > This could still be a newtype, because of the tuple you used here. A > more standard > way to do this would be: > > data List a = List (Ordinal -> a) Ordinal > > Or a record so you could name them. Thank you. I tend to favor tuplet notation because the are more methematical-like, though I have noticed, it is somewhat cumbersome in Haskell pattern matching. >> In addition, there seems to be no way to choose default value for a >> given (non-empty) type in Haskell, so I wrote it >> data List a = Empty | List(Ordinal -> a, Ordinal) >> Here, if a type T has a default element t, I can represent the empty >> list by >> List(\_ -> t, 0) >> making the constructor "Empty" redundant. > > You could use 'undefined', which has value _|_ (if you're sure that > it will never > be used). > > List (const undefined) 0 > > Or even: > > List undefined 0 > > Which are almost, but not quite, identical. (Many argue they > should be) I think I need just something that can be plugged into the function spot when length is 0. Hans Aberg From dons at galois.com Thu Mar 27 14:30:05 2008 From: dons at galois.com (Don Stewart) Date: Thu Mar 27 14:26:34 2008 Subject: [Haskell-cafe] Re: SoC project: Python-Haskell bridge - request for feedback In-Reply-To: <47EBE52C.3060202@imageworks.com> References: <561cb5bc0803241338x25170cffyda72b0d8446a3bb4@mail.gmail.com> <561cb5bc0803262200g72f64dcna878fd85bf8037da@mail.gmail.com> <47EBE52C.3060202@imageworks.com> Message-ID: <20080327183005.GA15899@scytale.galois.com> Remember that there are two proposals here, one potentially to the Python team, one to the Haskell team . Of course the Haskell guys are strongly interested in the use case Dan describes -- mitigating risk by using Haskell for small components first, as part of larger legacy systems. The Python guys are more interested in Python use from Haskell, by the looks of it. -- Don westondan: > I notice that you omit from the advantages of calling Haskell from > Python what I consider the most important reason of all (at least from > the Haskell community side). > > The choice of programming language (at least at the top level) is > primarily a political or managerial choice, not a technical one. Python > is not merely a "terrific glue language", it is often the "blessed" > language, and currently the language of choice in some industries, > including my own. This is not just "glue code" either: one in-house > application has about 100,000 lines of Python code (calling a comparable > amount of C++ code)! > > Any hope of introducing Haskell into this realm requires a way to work > Haskell in slowly and from the bottom. As such I view your proposed > project as quite valuable, a robust and easy-to-use Python-Haskell > bridge (Python on top) being essential to growing the presence of > Haskell in non-academic circles. > > Of course, it may be for this very political reason that you have > omitted the above from your list, in which case I completely understand. :) > > Dan > > Micha? Janeczek wrote: > >Hi, > > > >This is my second take on the project proposal. > >I have expanded on a few points, and hopefully > >also clarified a little bit. > > > >Please comment :) > > > >Regards, > >Michal > > > > > >Python-Haskell bridge > >===================== > > > >Description > >----------- > > > >This project will seek to provide a comprehensive, high level (and thus > >easy to use) binding between Haskell and Python programming languages. > >This will allow using libraries of either side from each language. > > > >If we decide to support function callbacks, these two functionalities > >(embedding Haskell in Python, and vice versa) become interrelated. > >In this light, it makes sense to implement them in the scope of the > >same project. > > > > > >Advantages of calling Haskell from Python > >----------------------------------------- > > > >* Robust components > > > > It might be beneficial to implement safety-critical componenets > > in a strongly, statically typed language. Since Python itself is > > a terrific "glue language", such components would usually be purely > > functional, leaving IO to the Python side. > > Embedding Haskell code in this way is of particular interest when > > there already is a large existing Python infrastructure. One can > > implement new functionality in a form of Haskell plugin/component, > > even if complete rewrite is not feasible. > > > >* Performance improvements for speed-critical code > > > > Haskell compiled to native code is typically an order of magnitude > > faster than Python. Aside from that, advanced language features > > (such as multicore parallel runtime, very lightweight threads > > and software transactional memory) further serve to improve the > > performance. Haskell could become a safe, high level alternative > > to commonly used C extensions. > > > >* Access to sophisticated libraries > > > > While its set of libraries is not as comprehensive as that of > > Python, Haskell can still offer some well tested, efficient > > libraries. Some of the examples might be: > > > > * rich parser combinator libraries (like Parsec) > > * persistent, functional data structures (i.e. Data.Map, > > Data.IntMap, Data.Sequence, Data.ByteString) > > * QuickCheck testing library to drive analysis of Python code > > > > > >Advantages of calling Python from Haskell > >----------------------------------------- > > > >* Python as a scripting language for Haskell applications > > > > Python is widely considered to be more approachable for regular > > users. As such, it could be used as a configuration/extension > > language for applications that benefit from extra flexibility. > > One example of such application is xmonad window manager. > > > >* Access to a large number of libraries > > > > As a much more popular language, Python has built up an impressive > > suite of libraries. There already are Haskell projects which rely > > on Python code to implement missing functionality, for example > > a paste bin application hpaste, which uses Pygments syntax coloring > > library. > > > > > >Deliverables > >------------ > > > >* A low level library to access and manage Python objects from Haskell > > > >* Library support for wrapping Haskell values in Python objects. This > > is necessary to allow function callbacks. In addition, thanks to that > > feature large and/or lazy data structures can be efficiently passed > > from Haskell to Python > > > >* A set of low level functions to convert built-in data types between > > Haskell and Python (strings, numbers, lists, dictionaries, > > generators etc.) > > > >* A high level wrapper library for Haskell that simplifies embedding > > and calling Python code > > > >* A set of functions, and possibly a tool, to wrap up monomorphic > > functions and expose them to Python through foreign export facility > > > >* A way (an external tool, or a Template Haskell macro) to easily > > derive conversion functions for user-defined data types/objects > > > >* Documentation and a set of examples for all of above > > > > > >Optional goals > >-------------- > > > >In order of increasing amount of work and decreasing priority: > > > >* Exporting a wider class of functions to Python > > > >* A Python module that inspects a compiled Haskell module and > > transparently exposes functions within. This might be possible > > thanks to GHC API > >_______________________________________________ > >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 haberg at math.su.se Thu Mar 27 14:39:52 2008 From: haberg at math.su.se (Hans Aberg) Date: Thu Mar 27 14:36:12 2008 Subject: [Haskell-cafe] Recursion problem in infinite list model In-Reply-To: <7ca3f0160803270951y9fb1d26u1ae1977f6bfcbc06@mail.gmail.com> References: <7CD6C496-9327-4982-90D3-82240C8BFD28@math.su.se> <47EBAC98.5020709@goto10.org> <7ca3f0160803270732y5163f102xc2feb4e02865fa2c@mail.gmail.com> <7ca3f0160803270951y9fb1d26u1ae1977f6bfcbc06@mail.gmail.com> Message-ID: On 27 Mar 2008, at 17:51, Luke Palmer wrote: > A more standard way to do this would be: > > data List a = List (Ordinal -> a) Ordinal I used data List a = Empty | (Ordinal->a) :+ Ordinal which might then be simplified by dropping "Empty". Hans Aberg From ninegua at gmail.com Thu Mar 27 14:48:23 2008 From: ninegua at gmail.com (Paul L) Date: Thu Mar 27 14:44:39 2008 Subject: [Haskell-cafe] Terminating GLUT/GLFW programs In-Reply-To: <7ca3f0160803251542s2624f614w64ef8e22a437ce13@mail.gmail.com> References: <47E75F0D.4090500@telenet.be> <001b01c88e9b$45107280$cf315780$@be> <856033f20803251237q2b5366e1vbbd07147e1570371@mail.gmail.com> <7ca3f0160803251540i55c9935j1370b978af0d1951@mail.gmail.com> <7ca3f0160803251542s2624f614w64ef8e22a437ce13@mail.gmail.com> Message-ID: <856033f20803271148x3dc02feu6a0d63184fbd1f51@mail.gmail.com> On 3/25/08, Luke Palmer wrote: > Er, not Ctrl, of course... Mod-Shift-C. /me goes to punish his hand > for compusive "send" presses. I believe that is to kill a window rather than a normal window close. -- Regards, Paul Liu Yale Haskell Group http://www.haskell.org/yale From jsnow at cs.pdx.edu Thu Mar 27 14:58:36 2008 From: jsnow at cs.pdx.edu (Jim Snow) Date: Thu Mar 27 14:53:31 2008 Subject: [Haskell-cafe] announce: Glome.hs raytracer (memory leak with parMap) In-Reply-To: References: <47EAC120.1050909@cs.pdx.edu> <20080327024935.GA29895@matrix.chaos.earth.li> Message-ID: <47EBEE5C.6090805@cs.pdx.edu> pepe wrote: > > On 27/03/2008, at 3:49, Ian Lynagh wrote: >> On Wed, Mar 26, 2008 at 02:33:20PM -0700, Jim Snow wrote: >>> >>> -Memory consumption is atrocious: 146 megs to render a scene that's a >>> 33k ascii file. Where does it all go? A heap profile reports the max >>> heap size at a rather more reasonable 500k or so. (My architecture is >>> 64 bit ubuntu on a dual-core amd.) >> >> I haven't looked properly yet, but it looks like something is leaking >> memory that shouldn't be. The attached Gloom.hs uses constant memory, >> but if you replace the "map" with the commented out "(parMap rnf)" then >> the memory use seems to keep increasing, even once it has run display >> once and is running it a second or third time. >> > > In my system the leak only appears with +RTS -N1 (which is the default). > If I use -N2 or higher, then your version runs in constant memory with > (parmap rnf). > > Cheers > pepe Using Ian Lynagh's Gloom.hs (I'm not sure if that's a typo, but it's a convenient way to distinguish it from my original Glome.hs): With parMap and +RTS -N2, I get 59 megs total mapped memory, 18 megs resident all three iterations. With parMap and +RTS -N1, I get 53/21, then 99/66, then 145/112 megs total/resident. With map and no RTS options, memory use is 37/4.8 all three iterations. I'm using ghc 6.8.2 on 64-bit ubuntu. -jim From jgoerzen at complete.org Thu Mar 27 15:27:56 2008 From: jgoerzen at complete.org (John Goerzen) Date: Thu Mar 27 15:29:48 2008 Subject: [Haskell-cafe] Re: SoC project: Python-Haskell bridge - request for feedback References: <561cb5bc0803241338x25170cffyda72b0d8446a3bb4@mail.gmail.com> <561cb5bc0803262200g72f64dcna878fd85bf8037da@mail.gmail.com> <47EBE52C.3060202@imageworks.com> Message-ID: FWIW, my MissingPy project accomplishes part of this (calling Python from Haskell) already. -- John On 2008-03-27, Dan Weston wrote: > I notice that you omit from the advantages of calling Haskell from > Python what I consider the most important reason of all (at least from > the Haskell community side). From jgoerzen at complete.org Thu Mar 27 15:26:39 2008 From: jgoerzen at complete.org (John Goerzen) Date: Thu Mar 27 15:30:00 2008 Subject: [Haskell-cafe] Web server libraries Message-ID: Hi again, I'm currently working on a project that has a Web interface to data stored in a SQL database. I wrote this thing in WASH a few years back. Overall, this has been acceptable, but the non-Haskell-adepts around here run away screaming from the code. Not only that, but we don't get control over the names of the form elements, which can make interacting with other software that sometimes plonks users down halfway through the process -- well, interesting. Also, WASH supports nothing better than CGI, which is a big minus when talking to SQL databases. What I really want is some sort of simple tool that supports FastCGI or some such, has basic support for form data input validation and marshalling to/from Haskell types, and basic control flow. I don't need, or really particularly want, something that uses hs-plugins to compile pages on demand (I'm using Haskell for it's static safety, after all). Nor do I need fancy templating systems or session support (we use HTTP auth and are fine with it for now.) So I've looked around a bit at the landscape. Any recommendations? I've found these: HSP: big on "dynamic pages". I don't want to make my webserver able to compile Haskell code. Develop code, compile, test, make sure it's right, then push to production every 6 months around here. WASH: Pretty much the right niche, but the event model is hard to use. HAppS: Frankly it is a big collection of confusing packages to me. What documentation exists doesn't seem to be relevant anymore, and it seems to be designed to not use a SQL database. FastCGI: Relies upon CGI for a good part of processing. Does not seem to have any form data validation support built in. Thanks again, -- John From jgoerzen at complete.org Thu Mar 27 15:08:41 2008 From: jgoerzen at complete.org (John Goerzen) Date: Thu Mar 27 15:31:17 2008 Subject: [Haskell-cafe] HTTP client libraries Message-ID: Hi folks, I was recently looking for HTTP client libraries for Haskell. I investigated several, and it seems that there aren't any really ready for primetime. Am I missing anything? Here's what I found: * Bjorn's String-based HTTP It eats RAM. Does not appear to read data lazily, returns a String, and may have a memory leak as well. Does not appear to be suited for anything except very small file downloads. * nominolo's ByteString port of Bjorn's HTTP Appears to exist only in a darcs repo linked from his personal blog. Makes me hesitant to use it in production code, for fear that it won't be around long-term. * tagsoup Broken in many ways. Does not support chunked encoding that is mandated by HTTP RFC. Will be incompatible with numerous HTTP servers, and the manual states as much. Port 80 hardcoded. * network-minihttp Doesn't appear to actually be very useful as a client. Also, as far as I have been able to deduce, none of these have built-in support for https (SSL) URLs. There is also a Curl binding (or two?) floating around, which I haven't investigated. It would be nicer to have a native Haskell solution. Or should I just go write one? -- John From donnie at darthik.com Thu Mar 27 15:50:05 2008 From: donnie at darthik.com (Donnie Jones) Date: Thu Mar 27 15:46:21 2008 Subject: [Haskell-cafe] Re: GSoC Project Proposal: Parallel Profiling Tools for GHC. In-Reply-To: References: Message-ID: Hello, I added some additional goals below. On Thu, Mar 27, 2008 at 2:23 PM, Donnie Jones wrote: > Hello Everyone,GSoC Project: Parallel Profiling Tools for GHC. > Student: Donnie Jones > Mentor: Simon Marlow > Project based upon suggestion by Simon Marlow: > http://hackage.haskell.org/trac/summer-of-code/ticket/1559 > > Overview: > For Haskell there are currently no tools to investigate the performance of > parallel programs. This project would extend the Haskell compiler GHC to > support profiling of parallel programs. > > Parallel programs are inherently difficult to analyze and the prevalence > of multi-core processors has increased the need for tools to facilitate > gaining performance from parallelism. The ability to profile parallel > programs in GHC could lead to improvements in GHC's RTS, and insights into > writing parallel Haskell code. > > Goals: > * Investigate the use of the GranSim framework for parallel profiling in > GHC > i. Decide what is needed to commit the GranSim port to the GHC tree > i. Build additional profiling tools upon the GranSim framework > > * Testing of performance hit accrued from parallel profiling > i. Investigate improving performance, possible modifications to > GranSim port > > * Construct tests to measure the performance improvements of parallel > programs > i. Building benchmarks for parallel programs, related to ticket: > http://hackage.haskell.org/trac/summer-of-code/ticket/1544 > > * Improve upon GranSim visualization of profiles to clarify parallel > profiling > i. Possibly add new visualization profiles, if time allows * Develop a single application for visualization of profiles i. application would build visualizations of the desired information as needed i. application would generate reports with specific numbers from the analysis, rather than only images with graphs i. application would interactively sort / rank threads based upon states, such as running, blocking, etc. i. application would integrate the visualization tools into a single program (which may lead to support for other profiling models than just parallelism) > > > I am sure that further details will need to be developed with the help of > Simon Marlow; however, I am unsure if some of these details can be defined > without first investigating the potential use of GranSim. > > I look forward to your feedback. > Thank you. > __ > Donnie Jones > Thank you. __ Donnie Jones -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080327/ee33d6a2/attachment.htm From ndmitchell at gmail.com Thu Mar 27 16:00:20 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Thu Mar 27 15:56:38 2008 Subject: [Haskell-cafe] HTTP client libraries In-Reply-To: References: Message-ID: <404396ef0803271300m1de34cdal38c79a30a7c634e7@mail.gmail.com> Hi > * tagsoup > > Broken in many ways. Does not support chunked encoding that is > mandated by HTTP RFC. Will be incompatible with numerous HTTP > servers, and the manual states as much. Port 80 hardcoded. I'd just like to stress that the one in tagsoup shouldn't be used for anything! It is only there to be a demo of tagsoup parsing, since otherwise an HTML parser is a bit dull. The haddock currently says: "It is very restricted, and it not intended for proper use" I guess I can make the warning a bit more violent. (And fix the grammar...) As soon as someone decides what is the answer to your HTTP question, the one in tagsoup will be removed. Thanks Neil From nominolo at googlemail.com Thu Mar 27 16:19:53 2008 From: nominolo at googlemail.com (Thomas Schilling) Date: Thu Mar 27 16:16:21 2008 Subject: [Haskell-cafe] HTTP client libraries In-Reply-To: References: Message-ID: On 27 mar 2008, at 20.08, John Goerzen wrote: > Hi folks, > > I was recently looking for HTTP client libraries for Haskell. I > investigated several, and it seems that there aren't any really ready > for primetime. Am I missing anything? Here's what I found: > > * Bjorn's String-based HTTP > > It eats RAM. Does not appear to read data lazily, returns a String, > and may have a memory leak as well. Does not appear to be suited > for anything except very small file downloads. > > * nominolo's ByteString port of Bjorn's HTTP > > Appears to exist only in a darcs repo linked from his personal blog. > Makes me hesitant to use it in production code, for fear that it > won't be around long-term. > No, it also leaks handles. I am now convinced that a fold/enumerator- based interface is the best solution but haven't gotten around to implementing it. It also isn't particularly well-tested (closer to not at all). It was a proof-of-concept (and to test what improvements are possible), but we never had the time or energy to complete it. > * tagsoup > > Broken in many ways. Does not support chunked encoding that is > mandated by HTTP RFC. Will be incompatible with numerous HTTP > servers, and the manual states as much. Port 80 hardcoded. > > * network-minihttp > > Doesn't appear to actually be very useful as a client. > > Also, as far as I have been able to deduce, none of these have > built-in support for https (SSL) URLs. > > There is also a Curl binding (or two?) floating around, which I > haven't investigated. It would be nicer to have a native Haskell > solution. Or should I just go write one? It would be a good summer of code project, but I don't know if someone will apply for it. Also, if you need it right now (or want to refer to a reliable implementation in your book) you probably don't want to count on that to work out. > > -- John > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From westondan at imageworks.com Thu Mar 27 17:07:23 2008 From: westondan at imageworks.com (Dan Weston) Date: Thu Mar 27 17:03:39 2008 Subject: [Haskell-cafe] Re: SoC project: Python-Haskell bridge - request for feedback In-Reply-To: References: <561cb5bc0803241338x25170cffyda72b0d8446a3bb4@mail.gmail.com> <561cb5bc0803262200g72f64dcna878fd85bf8037da@mail.gmail.com> <47EBE52C.3060202@imageworks.com> Message-ID: <47EC0C8B.2070900@imageworks.com> I did not see MissingPy on Hackage (presumably it would be next to MissingH?) I found it (listed on http://www.complete.org/jgoerzen/softindex.html) at http://darcs.complete.org/missingpy Is this the right place to get it? Dan John Goerzen wrote: > FWIW, my MissingPy project accomplishes part of this (calling Python > from Haskell) already. > > -- John > > On 2008-03-27, Dan Weston wrote: >> I notice that you omit from the advantages of calling Haskell from >> Python what I consider the most important reason of all (at least from >> the Haskell community side). > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From niklas.broberg at gmail.com Thu Mar 27 17:23:06 2008 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Thu Mar 27 17:19:24 2008 Subject: [Haskell-cafe] Web server libraries In-Reply-To: References: Message-ID: > HSP: big on "dynamic pages". I don't want to make my webserver able > to compile Haskell code. Develop code, compile, test, make sure it's > right, then push to production every 6 months around here. Being one of the main developers of HSP, I guess I should reply to this. :-) HSP is indeed big on dynamic pages, if by dynamic you mean pages that can return different results on different calls. The compile-on-demand feature used to be a part of the old runtime for HSP, but in the current incarnation that has been lifted out. And HSP as such is much more a programming model - an API basically - than any particular deployment scheme. HSP's basic model is much more low-level than e.g. WASH, as we haven't really had time to add any flesh to the bare bones yet. But looking at the bright side, at least we don't have a hard to use event model... And HSP would definitely give you control over the names of elements if you find that you need it. There is - currently - no built-in support for form validation in HSP, bare bones and all that, but it's definitely a feature that we would *like* to support. We just haven't gotten there yet. So if you wanted to use HSP, we would be happy to accept a feature request from you. It would be great to be able to have actual use cases to work with to help the design of such form validation. Easy support for SQL databases is another feature high up on the wish list. Right now it should be about as easy as as from any other Haskell application, except... ...HSP also currently only supports CGI, but that's perhaps the number one priority to get it working in different environments. We were thinking primarily of using the HAppS server utility as a runtime environment, but FastCGI support would perhaps be an even easier task. Again, a feature request would be most welcome, with some ideas for what you want to get out of the FastCGI integration. Also, one of the explicit design goals of HSP from the very beginning has been to make it easy to understand for non-Haskell users. Just like PHP allows you to take the step from writing static HTML pages to writing dynamic PHP pages without pause, we wanted to "lure" prospective web programmers into the Haskell world and in the darkness bind them... Maybe something for your co-workers? :-) So to summarize, HSP is a very simple model - perhaps *too* simple right now - and aims to support much of what you ask for in a not too distant future. Please drop a few feature requests our way so we have something tangible to work with. Feature requests go here: http://code.google.com/p/hsp/issues/entry Cheers, /Niklas From dons at galois.com Thu Mar 27 17:28:53 2008 From: dons at galois.com (Don Stewart) Date: Thu Mar 27 17:25:29 2008 Subject: [Haskell-cafe] Re: SoC project: Python-Haskell bridge - request for feedback In-Reply-To: References: <561cb5bc0803241338x25170cffyda72b0d8446a3bb4@mail.gmail.com> <561cb5bc0803262200g72f64dcna878fd85bf8037da@mail.gmail.com> <47EBE52C.3060202@imageworks.com> Message-ID: <20080327212853.GA18093@scytale.galois.com> Oh, I thought I added that as "related work" to the ticket page. If its not, couldyou add it? jgoerzen: > FWIW, my MissingPy project accomplishes part of this (calling Python > from Haskell) already. > > -- John > > On 2008-03-27, Dan Weston wrote: > > I notice that you omit from the advantages of calling Haskell from > > Python what I consider the most important reason of all (at least from > > the Haskell community side). > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From paulrbrown+haskell-cafe at gmail.com Thu Mar 27 17:33:33 2008 From: paulrbrown+haskell-cafe at gmail.com (Paul Brown) Date: Thu Mar 27 17:29:49 2008 Subject: [Haskell-cafe] Web server libraries In-Reply-To: References: Message-ID: <4249453d0803271433q2982385dm4acd85e3d7cbe167@mail.gmail.com> On Thu, Mar 27, 2008 at 12:26 PM, John Goerzen wrote: > What I really want is some sort of simple tool that supports FastCGI > or some such, has basic support for form data input validation and > marshalling to/from Haskell types, and basic control flow. > So I've looked around a bit at the landscape. Any recommendations? Your assessment of FastCGI is on, but it's not that difficult to get the validation/unmarshalling that you want out of a little work with Read/Show, since the flow would be something like this on every pass: bag of name/value pairs -> Haskell structure -> IO (e.g., to db) -> Html The HAppS approach to laying out URL space is nice, and I whipped up something relatively ugly but quick using Parsec. -- paulrbrown@gmail.com http://mult.ifario.us/ From paulrbrown+haskell-cafe at gmail.com Thu Mar 27 17:38:21 2008 From: paulrbrown+haskell-cafe at gmail.com (Paul Brown) Date: Thu Mar 27 17:34:37 2008 Subject: [Haskell-cafe] HTTP client libraries In-Reply-To: References: Message-ID: <4249453d0803271438v345912d9ndcf8f9c4c066dc07@mail.gmail.com> On Thu, Mar 27, 2008 at 12:08 PM, John Goerzen wrote: > * Bjorn's String-based HTTP > It eats RAM. Does not appear to read data lazily, returns a String, > and may have a memory leak as well. Does not appear to be suited > for anything except very small file downloads. Do you know why it's eating RAM? With the issue with open sockets resolved (I know, I have to send that patch to Bjorn...), I haven't had observable stability or leaking issues. I'm using it to hit JSON/XML services like Twitter, del.icio.us, Google reader, etc. Laziness here is a bit of a mixed bag, since if you're too lazy, you'll try to read the stream after it's long gone. (Principle of Least Surprise) We do need a real (HTTPS, support for encoding, possibility to be lazy) HTTP client library, and a binding for libcurl may be the short path. -- paulrbrown@gmail.com http://mult.ifario.us/ From g9ks157k at acme.softbase.org Thu Mar 27 17:43:57 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Thu Mar 27 17:40:33 2008 Subject: [Haskell-cafe] Equality constraints in type families In-Reply-To: <7b92c2840803251907y159ffcf7t4b8b439701963d06@mail.gmail.com> References: <7b92c2840803101651x3673691eid310ab137805eeff@mail.gmail.com> <933DC899-6A42-4BE1-ADC5-E52FB1AEC0A9@cse.unsw.edu.au> <7b92c2840803251907y159ffcf7t4b8b439701963d06@mail.gmail.com> Message-ID: <200803272243.57347.g9ks157k@acme.softbase.org> Am Mittwoch, 26. M?rz 2008 03:07 schrieb Hugo Pacheco: > > The extra syntax has its advantages (more local information) and > > disadvantages (more clutter). We weren't convinced that we need the > > extra syntax, so left it out for the moment. However, this is > > something that can always be changed if experience shows that programs > > are easier to understand with extra syntax. It doesn't affect the > > type theory and is really a pure language design question. I'd be > > glad to hear some more opinions about this matter. > > I would go for the braces as Claus suggested, I would do so, too. Best wishes, Wolfgang From g9ks157k at acme.softbase.org Thu Mar 27 17:48:46 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Thu Mar 27 17:45:06 2008 Subject: [Haskell-cafe] Equality constraints in type families In-Reply-To: <200803272243.57347.g9ks157k@acme.softbase.org> References: <7b92c2840803101651x3673691eid310ab137805eeff@mail.gmail.com> <7b92c2840803251907y159ffcf7t4b8b439701963d06@mail.gmail.com> <200803272243.57347.g9ks157k@acme.softbase.org> Message-ID: <200803272248.46340.g9ks157k@acme.softbase.org> Am Donnerstag, 27. M?rz 2008 22:43 schrieb Wolfgang Jeltsch: > Am Mittwoch, 26. M?rz 2008 03:07 schrieb Hugo Pacheco: > > > The extra syntax has its advantages (more local information) and > > > disadvantages (more clutter). We weren't convinced that we need the > > > extra syntax, so left it out for the moment. However, this is > > > something that can always be changed if experience shows that programs > > > are easier to understand with extra syntax. It doesn't affect the > > > type theory and is really a pure language design question. I'd be > > > glad to hear some more opinions about this matter. > > > > I would go for the braces as Claus suggested, > > I would do so, too. Hmm, but then we should also introduce braces for ordinary type synonyms: type ReaderWriterT m = ReaderT (WriterT m) x :: {ReaderWriterT IO} Char > [?] Best wishes, Wolfgang From valgarv at gmx.net Thu Mar 27 18:02:39 2008 From: valgarv at gmx.net (Ariel J. Birnbaum) Date: Thu Mar 27 17:58:56 2008 Subject: [Haskell-cafe] MonadMemory class Message-ID: <200803280002.39437.valgarv@gmx.net> Two questions came to mind while thinking of memory references in Haskell: 1. Is there a "standard" equivalent of the following: class (Monad m) => MonadMemory m r | m -> r where new :: a -> m (r a) read :: r a -> m a write :: r a -> a -> m () What kind of axioms should an instance of this class satisfy? 2. How would a "pure" instance of this class look like (obvious unsafePerformIO-based solutions aside)? Is it even possible in pure Haskell? Thanks much! -- Ariel J. Birnbaum From g9ks157k at acme.softbase.org Thu Mar 27 18:12:30 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Thu Mar 27 18:08:57 2008 Subject: [Haskell-cafe] reactive programming, what's hot? In-Reply-To: <1f3dc80d0803211145o159d6e75vbabafce38ab2194d@mail.gmail.com> References: <1f3dc80d0803211145o159d6e75vbabafce38ab2194d@mail.gmail.com> Message-ID: <200803272312.31055.g9ks157k@acme.softbase.org> Am Freitag, 21. M?rz 2008 19:45 schrieb Greg Fitzgerald: > [?] > Are there other purely functional reactive libraries in active development? > Why might one choose one over another? There is also Grapefruit (). It?s still far away from being mature. One upside of it is that it stresses efficiency. > Thanks, > Greg Best wishes, Wolfgang From hpacheco at gmail.com Thu Mar 27 18:12:53 2008 From: hpacheco at gmail.com (Hugo Pacheco) Date: Thu Mar 27 18:09:11 2008 Subject: [Haskell-cafe] Equality constraints in type families In-Reply-To: <200803272248.46340.g9ks157k@acme.softbase.org> References: <7b92c2840803101651x3673691eid310ab137805eeff@mail.gmail.com> <7b92c2840803251907y159ffcf7t4b8b439701963d06@mail.gmail.com> <200803272243.57347.g9ks157k@acme.softbase.org> <200803272248.46340.g9ks157k@acme.softbase.org> Message-ID: <7b92c2840803271512m2816bd2am3e9fd93358114db9@mail.gmail.com> The reason for the braces in type families is because type indices are treated differently than normal parameters. I don't think this should be adopted for type synonyms either. Cheers, hugo On Thu, Mar 27, 2008 at 9:48 PM, Wolfgang Jeltsch < g9ks157k@acme.softbase.org> wrote: > Am Donnerstag, 27. M?rz 2008 22:43 schrieb Wolfgang Jeltsch: > > Am Mittwoch, 26. M?rz 2008 03:07 schrieb Hugo Pacheco: > > > > The extra syntax has its advantages (more local information) and > > > > disadvantages (more clutter). We weren't convinced that we need the > > > > extra syntax, so left it out for the moment. However, this is > > > > something that can always be changed if experience shows that > programs > > > > are easier to understand with extra syntax. It doesn't affect the > > > > type theory and is really a pure language design question. I'd be > > > > glad to hear some more opinions about this matter. > > > > > > I would go for the braces as Claus suggested, > > > > I would do so, too. > > Hmm, but then we should also introduce braces for ordinary type synonyms: > > type ReaderWriterT m = ReaderT (WriterT m) > > x :: {ReaderWriterT IO} Char > > > [?] > > Best wishes, > Wolfgang > _______________________________________________ > 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/20080327/3aaa311d/attachment.htm From bulat.ziganshin at gmail.com Thu Mar 27 18:30:33 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu Mar 27 18:26:57 2008 Subject: [Haskell-cafe] MonadMemory class In-Reply-To: <200803280002.39437.valgarv@gmx.net> References: <200803280002.39437.valgarv@gmx.net> Message-ID: <964574708.20080328013033@gmail.com> Hello Ariel, Friday, March 28, 2008, 1:02:39 AM, you wrote: class (Monad m) =>> MonadMemory m r | m -> r where there are more than one way to define such class. look at http://haskell.org/haskellwiki/Library/ArrayRef for examples -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From derek.a.elkins at gmail.com Thu Mar 27 18:35:53 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Thu Mar 27 18:32:13 2008 Subject: [Haskell-cafe] MonadMemory class In-Reply-To: <200803280002.39437.valgarv@gmx.net> References: <200803280002.39437.valgarv@gmx.net> Message-ID: <1206657354.5533.50.camel@derek-laptop> On Fri, 2008-03-28 at 00:02 +0200, Ariel J. Birnbaum wrote: > Two questions came to mind while thinking of memory references in Haskell: > > 1. Is there a "standard" equivalent of the following: > > class (Monad m) => MonadMemory m r | m -> r where > new :: a -> m (r a) > read :: r a -> m a > write :: r a -> a -> m () > This has come up a few times and been written by many Haskellers (usually called MonadRef.) The problem is the functional dependencies. Any choice you make is either too limiting or too annoying to use and it was never agreed which would be best. > What kind of axioms should an instance of this class satisfy? There are quite a few obvious ones, but I'm not sure it's particularly necessary. > > 2. How would a "pure" instance of this class look like (obvious > unsafePerformIO-based solutions aside)? Is it even possible in pure Haskell? The issue here is a type one, not a semantics one. I believe the only way to purely get such an interface (in current Haskell) is to use unsafeCoerce. Other than that, it's a straightforward state monad. From ryani.spam at gmail.com Thu Mar 27 19:00:33 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Thu Mar 27 18:56:48 2008 Subject: [Haskell-cafe] MonadMemory class In-Reply-To: <200803280002.39437.valgarv@gmx.net> References: <200803280002.39437.valgarv@gmx.net> Message-ID: <2f9b2d30803271600w190cfce6s75063a910797261f@mail.gmail.com> On 3/27/08, Ariel J. Birnbaum wrote: > class (Monad m) => MonadMemory m r | m -> r where > new :: a -> m (r a) > read :: r a -> m a > write :: r a -> a -> m () > > What kind of axioms should an instance of this class satisfy? Here's some thoughts: (~=) means "equivalent excluding allocation effects". (==) means "equivalent" 1) Unreferenced allocations do nothing: (new a >> m) ~= m 2) Read+Write laws: (read r >>= write r) == return () (new x >>= read) ~= return x (write r x >>= read) == (write r x >> return x) 3) References are independent: If m does not refer to r, then: (read r >>= (\x -> m >> return x)) == m >> read r (write r x >> m) == m >>= (\v -> write r x >> return v) > 2. How would a "pure" instance of this class look like (obvious > unsafePerformIO-based solutions aside)? Is it even possible in pure Haskell? Yes, it is possible with unsafeCoerce. It's possible without unsafeCoerce if you add a Typeable constraint or pass a GADT type representation to new. To be truly safe you need higher-rank types and use the same trick that ST does. But there's not much point; you may as well use ST. At that point, it's actually a pretty simple state monad: data HeapItem = forall a. HeapItem a newtype Ref s a = Ref Integer newtype RefM s = RefM (State (Integer, Map Integer HeapItem)) -- use unsafeCoerce to extract elements in read. Handling garbage collection is tricky, though. -- ryan From agl at imperialviolet.org Thu Mar 27 19:27:56 2008 From: agl at imperialviolet.org (Adam Langley) Date: Thu Mar 27 19:24:12 2008 Subject: [Haskell-cafe] HTTP client libraries In-Reply-To: References: Message-ID: <396556a20803271627s2da60f7nc255b8c05dc20c8f@mail.gmail.com> On Thu, Mar 27, 2008 at 12:08 PM, John Goerzen wrote: > * network-minihttp > > Doesn't appear to actually be very useful as a client. > > Also, as far as I have been able to deduce, none of these have > built-in support for https (SSL) URLs. The client doesn't do a lot, but I don't know what you would want from a client. Email me a list of use cases and ;) It does support HTTPS, however. See examples/webcat.hs AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org From valgarv at gmx.net Thu Mar 27 20:00:20 2008 From: valgarv at gmx.net (Ariel J. Birnbaum) Date: Thu Mar 27 19:56:38 2008 Subject: [Haskell-cafe] MonadMemory class In-Reply-To: <964574708.20080328013033@gmail.com> References: <200803280002.39437.valgarv@gmx.net> <964574708.20080328013033@gmail.com> Message-ID: <200803280300.20536.valgarv@gmx.net> > look at http://haskell.org/haskellwiki/Library/ArrayRef for examples Thanks, Data.Ref.Universal looks just like it! One question though. In: ?class (Monad m) => Ref m r | m->r, r->m where Why is the second fundep necessary? -- Ariel J. Birnbaum From valgarv at gmx.net Thu Mar 27 20:01:32 2008 From: valgarv at gmx.net (Ariel J. Birnbaum) Date: Thu Mar 27 19:57:50 2008 Subject: [Haskell-cafe] MonadMemory class In-Reply-To: <1206657354.5533.50.camel@derek-laptop> References: <200803280002.39437.valgarv@gmx.net> <1206657354.5533.50.camel@derek-laptop> Message-ID: <200803280301.33081.valgarv@gmx.net> > This has come up a few times and been written by many Haskellers I was quite certain of that, hence my puzzlement at being unable to find it =) > > What kind of axioms should an instance of this class satisfy? > There are quite a few obvious ones, but I'm not sure it's particularly > necessary. I'm still curious, though. In general I think it's a GoodThing (TM) if stuff (especially the sort of typeclasses) come with a semantic base we can use for reasoning about it; in the sort of way the Monad class comes with the monad laws. > The issue here is a type one, not a semantics one. An issue nevertheless, IMHO > I believe the only > way to purely get such an interface (in current Haskell) is to use > unsafeCoerce. I'm not so sure about calling unsafeCoerce 'pure' ;) -- Ariel From dons at galois.com Thu Mar 27 20:02:18 2008 From: dons at galois.com (Don Stewart) Date: Thu Mar 27 19:58:49 2008 Subject: [Haskell-cafe] HTTP client libraries In-Reply-To: <4249453d0803271438v345912d9ndcf8f9c4c066dc07@mail.gmail.com> References: <4249453d0803271438v345912d9ndcf8f9c4c066dc07@mail.gmail.com> Message-ID: <20080328000218.GC18093@scytale.galois.com> paulrbrown+haskell-cafe: > On Thu, Mar 27, 2008 at 12:08 PM, John Goerzen wrote: > > * Bjorn's String-based HTTP > > It eats RAM. Does not appear to read data lazily, returns a String, > > and may have a memory leak as well. Does not appear to be suited > > for anything except very small file downloads. > > Do you know why it's eating RAM? With the issue with open sockets > resolved (I know, I have to send that patch to Bjorn...), I haven't > had observable stability or leaking issues. I'm using it to hit > JSON/XML services like Twitter, del.icio.us, Google reader, etc. > > Laziness here is a bit of a mixed bag, since if you're too lazy, > you'll try to read the stream after it's long gone. (Principle of > Least Surprise) > > We do need a real (HTTPS, support for encoding, possibility to be > lazy) HTTP client library, and a binding for libcurl may be the short > path. And we have a curl binding, already in wide use. http://code.haskell.org/curl.git/ a release to hackage is imminent. From pkeir at dcs.gla.ac.uk Thu Mar 27 20:02:50 2008 From: pkeir at dcs.gla.ac.uk (Paul Keir) Date: Thu Mar 27 19:59:06 2008 Subject: [Haskell-cafe] Parsec Expected Type Message-ID: <3CDFB8AFEA98E34CB599475AB11589C80CC9BF@EX2.ad.dcs.gla.ac.uk> Hi, Does anyone know why this reduced Parsec production stops compilation, and how I can fix it? tester = reserved "parameter" <|> do { reserved "dimension"; symbol ":" } Thanks, Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080328/7dba0fbe/attachment.htm From valgarv at gmx.net Thu Mar 27 20:03:12 2008 From: valgarv at gmx.net (Ariel J. Birnbaum) Date: Thu Mar 27 19:59:29 2008 Subject: [Haskell-cafe] MonadMemory class In-Reply-To: <2f9b2d30803271600w190cfce6s75063a910797261f@mail.gmail.com> References: <200803280002.39437.valgarv@gmx.net> <2f9b2d30803271600w190cfce6s75063a910797261f@mail.gmail.com> Message-ID: <200803280303.12296.valgarv@gmx.net> > (write r x >>= read) == (write r x >> return x) You probably mean (write r x >> read r) == (write r x >> return x)? > 3) References are independent: > If m does not refer to r, then: > (read r >>= (\x -> m >> return x)) == m >> read r > (write r x >> m) == m >>= (\v -> write r x >> return v) What if m writes to r' which is read by another thread, which in turn writes another value into r? What exactly does "does not refer to r" mean? > It's possible without unsafeCoerce if you add a Typeable constraint or pass > a GADT type representation to new. Care to develop? > To be truly safe you need higher-rank types and use the same trick > that ST does. Here I was, naively thinking I could put off learning about that for now ;) > But there's not much point; you may as well use ST. Not much *practical* point, I agree. I mostly asked out of curiosity. > Handling garbage collection is tricky, though. Can it even be done without compiler support? -- Ariel J. Birnbaum From chak at cse.unsw.edu.au Thu Mar 27 20:04:46 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Thu Mar 27 20:01:15 2008 Subject: [Haskell-cafe] Equality constraints in type families In-Reply-To: <7b92c2840803270946g7cb69fe6ue72f1e08e10a9efc@mail.gmail.com> References: <7b92c2840803101651x3673691eid310ab137805eeff@mail.gmail.com> <00cf01c889e6$06ae9fd0$b9387ad5@cr3lt> <004d01c88da5$f744a350$ee3d8351@cr3lt> <006e01c88e67$f6afef40$321e7ad5@cr3lt> <638ABD0A29C8884A91BC5FB5C349B1C32AB9E0C8B1@EA-EXMSG-C334.europe.corp.microsoft.com> <41687A81-42E7-4306-BFAA-5D816E1689E1@cse.unsw.edu.au> <7b92c2840803270945l7ea4aec7id0489e18a981c392@mail.gmail.com> <7b92c2840803270946g7cb69fe6ue72f1e08e10a9efc@mail.gmail.com> Message-ID: <655A80F9-8FAA-46BD-B107-B8C66CFAE03A@cse.unsw.edu.au> Hugo Pacheco: > Sorry, I meant > > type FList a x = Either One (a,x) > type instance F [a] = FList a We should not allow such programs. Manuel > > > On Thu, Mar 27, 2008 at 4:45 PM, Hugo Pacheco > wrote: > > > The current implementation is wrong, as it permits > > type S a b = a > type family F a :: * -> * > type instance F a = S a > > Why do we need to forbid this type instance? Because it breaks the > confluence of equality constraint normalisation. Here are two > diverging normalisations: > > (1) > > F Int Bool ~ F Int Char > > ==> DECOMP > > F Int ~ F Int, Bool ~ Char > > ==> FAIL > > > (2) > > F Int Bool ~ F Int Char > > ==> TOP > > S Int Bool ~ S Int Char > > ==> (expand type synonym) > > Int ~ Int > > ==> TRIVIAL > > This does mean that a program such as > > type FList a = Either One ((,) a) > type instance F [a] = FList a > > will be disallowed in further versions? > Doesn't this problem occur only for type synonyms that ignore one or > more of the parameters? If so, this could be checked... > > hugo > > From g9ks157k at acme.softbase.org Thu Mar 27 20:05:59 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Thu Mar 27 20:03:57 2008 Subject: [Haskell-cafe] Monad instance for Data.Set, again In-Reply-To: References: Message-ID: <200803280106.00061.g9ks157k@acme.softbase.org> Am Montag, 24. M?rz 2008 20:47 schrieb Henning Thielemann: > [?] > Here is another approach that looks tempting, but unfortunately does not > work, and I wonder whether this can be made working. > > module RestrictedMonad where > > import Data.Set(Set) > import qualified Data.Set as Set > > class AssociatedMonad m a where > > class RestrictedMonad m where > return :: AssociatedMonad m a => a -> m a > (>>=) :: (AssociatedMonad m a, AssociatedMonad m b) => > m a -> (a -> m b) -> m b > > instance (Ord a) => AssociatedMonad Set a where > > instance RestrictedMonad Set where > return = Set.singleton > x >>= f = Set.unions (map f (Set.toList x)) > [?] The problem is that while an expression of type (AssociatedMonad Set a, AssociatedMonad Set b) => Set a -> (a -> Set b) -> Set b has type (Ord a, Ord b) => Set a -> (a -> Set b) -> Set b, the opposite doesn?t hold. Your AssociatedMonad class doesn?t provide you any Ord dictionary which you need in order to use the Set functions. The instance declaration instance (Ord a) => AssociatedMonad Set a says how to construct an AssociatedMonad dictionary from an Ord dictionary but not the other way round. But it is possible to give a construction of an Ord dictionary from an AssociatedMonad dictionary. See the attached code. It works like a charm. :-) Best wishes, Wolfgang -------------- next part -------------- {-# LANGUAGE ExistentialQuantification, MultiParamTypeClasses, FlexibleInstances, TypeFamilies #-} import Data.Set (Set) import qualified Data.Set as Set class Suitable monad val where data Constraints monad val :: * constraints :: monad val -> Constraints monad val class NewMonad monad where newReturn :: (Suitable monad val) => val -> monad val newBind :: (Suitable monad val, Suitable monad val') => monad val -> (val -> monad val') -> monad val' instance (Ord val) => Suitable Set val where data Constraints Set val = Ord val => SetConstraints constraints _ = SetConstraints instance NewMonad Set where newReturn = Set.singleton newBind set1 set2Gen = let set2Constraints = constraints result result = case set2Constraints of SetConstraints -> Set.unions $ map set2Gen $ Set.toList set1 in result From hpacheco at gmail.com Thu Mar 27 20:11:11 2008 From: hpacheco at gmail.com (Hugo Pacheco) Date: Thu Mar 27 20:07:26 2008 Subject: [Haskell-cafe] Equality constraints in type families In-Reply-To: <655A80F9-8FAA-46BD-B107-B8C66CFAE03A@cse.unsw.edu.au> References: <7b92c2840803101651x3673691eid310ab137805eeff@mail.gmail.com> <004d01c88da5$f744a350$ee3d8351@cr3lt> <006e01c88e67$f6afef40$321e7ad5@cr3lt> <638ABD0A29C8884A91BC5FB5C349B1C32AB9E0C8B1@EA-EXMSG-C334.europe.corp.microsoft.com> <41687A81-42E7-4306-BFAA-5D816E1689E1@cse.unsw.edu.au> <7b92c2840803270945l7ea4aec7id0489e18a981c392@mail.gmail.com> <7b92c2840803270946g7cb69fe6ue72f1e08e10a9efc@mail.gmail.com> <655A80F9-8FAA-46BD-B107-B8C66CFAE03A@cse.unsw.edu.au> Message-ID: <7b92c2840803271711y13a7366aj9976d87489dbf34e@mail.gmail.com> Yes, but doesn't the confluence problem only occur for type synonyms that ignore one or more of the parameters? If so, this could be checked... On Fri, Mar 28, 2008 at 12:04 AM, Manuel M T Chakravarty < chak@cse.unsw.edu.au> wrote: > Hugo Pacheco: > > Sorry, I meant > > > > type FList a x = Either One (a,x) > > type instance F [a] = FList a > > We should not allow such programs. > > Manuel > > > > > > > On Thu, Mar 27, 2008 at 4:45 PM, Hugo Pacheco > > wrote: > > > > > > The current implementation is wrong, as it permits > > > > type S a b = a > > type family F a :: * -> * > > type instance F a = S a > > > > Why do we need to forbid this type instance? Because it breaks the > > confluence of equality constraint normalisation. Here are two > > diverging normalisations: > > > > (1) > > > > F Int Bool ~ F Int Char > > > > ==> DECOMP > > > > F Int ~ F Int, Bool ~ Char > > > > ==> FAIL > > > > > > (2) > > > > F Int Bool ~ F Int Char > > > > ==> TOP > > > > S Int Bool ~ S Int Char > > > > ==> (expand type synonym) > > > > Int ~ Int > > > > ==> TRIVIAL > > > > This does mean that a program such as > > > > type FList a = Either One ((,) a) > > type instance F [a] = FList a > > > > will be disallowed in further versions? > > Doesn't this problem occur only for type synonyms that ignore one or > > more of the parameters? If so, this could be checked... > > > > hugo > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080328/320637e8/attachment.htm From lrpalmer at gmail.com Thu Mar 27 20:26:26 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Thu Mar 27 20:22:40 2008 Subject: [Haskell-cafe] Parsec Expected Type In-Reply-To: <3CDFB8AFEA98E34CB599475AB11589C80CC9BF@EX2.ad.dcs.gla.ac.uk> References: <3CDFB8AFEA98E34CB599475AB11589C80CC9BF@EX2.ad.dcs.gla.ac.uk> Message-ID: <7ca3f0160803271726m21c444c5x7c417afd686eb9b6@mail.gmail.com> Hi Paul, 2008/3/27 Paul Keir : > Hi, > > Does anyone know why this reduced Parsec production stops compilation, and > how I can fix it? > > tester = reserved "parameter" > <|> do { reserved "dimension"; symbol ":" } Look at the types of "reserved" and "symbol" (from http://www.haskell.org/ghc/docs/latest/html/libraries/parsec/Text-ParserCombinators-Parsec-Token.html): symbol :: String -> CharParser st String reserved :: String -> CharParser st () The type of a do block is the same as the type of its last statement. But (reserved "parameter") and (symbol ";") do not have the same type. Luke From jgoerzen at complete.org Thu Mar 27 20:47:20 2008 From: jgoerzen at complete.org (John Goerzen) Date: Thu Mar 27 20:43:30 2008 Subject: [Haskell-cafe] HTTP client libraries In-Reply-To: <4249453d0803271438v345912d9ndcf8f9c4c066dc07@mail.gmail.com> References: <4249453d0803271438v345912d9ndcf8f9c4c066dc07@mail.gmail.com> Message-ID: <200803271947.21179.jgoerzen@complete.org> On Thursday 27 March 2008 04:38:21 pm Paul Brown wrote: > On Thu, Mar 27, 2008 at 12:08 PM, John Goerzen wrote: > > * Bjorn's String-based HTTP > > It eats RAM. Does not appear to read data lazily, returns a String, > > and may have a memory leak as well. Does not appear to be suited > > for anything except very small file downloads. > > Do you know why it's eating RAM? With the issue with open sockets It appears to be insufficient laziness. You'll probably never notice it because you're only downloading small files. Trying to download a 20MB file resulted in 500MB RAM usage for me before I killed it. -- John From jgoerzen at complete.org Thu Mar 27 20:50:03 2008 From: jgoerzen at complete.org (John Goerzen) Date: Thu Mar 27 20:46:16 2008 Subject: [Haskell-cafe] Re: SoC project: Python-Haskell bridge - request =?iso-8859-1?q?for=09feedback?= In-Reply-To: <47EC0C8B.2070900@imageworks.com> References: <561cb5bc0803241338x25170cffyda72b0d8446a3bb4@mail.gmail.com> <47EC0C8B.2070900@imageworks.com> Message-ID: <200803271950.05859.jgoerzen@complete.org> On Thursday 27 March 2008 04:07:23 pm Dan Weston wrote: > I did not see MissingPy on Hackage (presumably it would be next to > MissingH?) > > I found it (listed on http://www.complete.org/jgoerzen/softindex.html) > at http://darcs.complete.org/missingpy > > Is this the right place to get it? Yes, it is. I have not had the need for it lately, and thus haven't made recent releases to upload to Hackage. It did work solidly when I used it, so hopefully it can be at least some value to someone. -- John From g9ks157k at acme.softbase.org Thu Mar 27 20:53:59 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Thu Mar 27 20:50:20 2008 Subject: [Haskell-cafe] Equality constraints in type families In-Reply-To: <7b92c2840803271512m2816bd2am3e9fd93358114db9@mail.gmail.com> References: <7b92c2840803101651x3673691eid310ab137805eeff@mail.gmail.com> <200803272248.46340.g9ks157k@acme.softbase.org> <7b92c2840803271512m2816bd2am3e9fd93358114db9@mail.gmail.com> Message-ID: <200803280153.59721.g9ks157k@acme.softbase.org> Am Donnerstag, 27. M?rz 2008 23:12 schrieben Sie: > The reason for the braces in type families is because type indices are > treated differently than normal parameters. I don't think this should be > adopted for type synonyms either. > > Cheers, > hugo In a way, there is also different treatment in the case of type synonyms. If you have the definition type ReaderWriterT m = ReaderT (WriterT m), you cannot leave out the m but you can leave out the result type parameter. I think, it would be good if the syntax of type synonyms and type synonym families was consistent. Best wishes, Wolfgang From ok at cs.otago.ac.nz Thu Mar 27 20:59:17 2008 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Thu Mar 27 20:55:38 2008 Subject: [Haskell-cafe] Wumpus World In-Reply-To: <47EB4BF5.6070807@gmail.com> References: <370295.79690.qm@web30201.mail.mud.yahoo.com> <47EB4BF5.6070807@gmail.com> Message-ID: <5D26F362-D029-4A57-A727-52F554D8A5F0@cs.otago.ac.nz> On 27 Mar 2008, at 8:25 pm, Robert Wills wrote: > This might also be relevant: > http://web.engr.oregonstate.edu/~erwig/zurg/ But note that the Prolog code that they compared against was, um, let's put this kindly, seriously naive. For example, (a) it has 36 SLOC. You can do it naturally in 20. (b) it has 8 predicates. You can do it naturally in 4. (c) it does lots of list munching, and that inefficiently. You can do it much more naturally with the only list being the solution. Indeed, a very minor rewrite from the natural code gives you a Prolog program where NO heap storage is allocated except the list of move names. (d) It generates candidate solutions and then rejects ones that take too long. It is easier and more natural to reject over-time paths before extending them to solutions, so the Prolog code they used for comparison is *structurally* inefficient. 30 years ago people were writing papers showing that Lisp was better than very badly written Prolog. Now they are writing papers showing that Haskell is better than very badly written Prolog. How things have changed! NOT. Also note that the paper says "The most important feature of Haskell that supports [the impression that Haskell is good at this kind of thing] is the availability of multi-parameter type classes..." and that Haskell 98 had no multi-parameter type classes, which are a pretty advanced part of the language for beginners to understand. From der_eq at freenet.de Thu Mar 27 21:12:28 2008 From: der_eq at freenet.de (Henning =?ISO-8859-1?Q?G=FCnther?=) Date: Thu Mar 27 21:09:12 2008 Subject: [Haskell-cafe] Functional dependencies with Type Classes Message-ID: <1206666748.13298.27.camel@localhost> Hi, suppose there are two (identical) classes: > class Res a b | a -> b where > getRes :: a -> b and > class Res2 t where > type Member t > getRes2 :: t -> Member t It is easy to automatically make every instance of Res2 an instance of res: > instance Res2 a => Res a (Member a) where > getRes x = getRes2 x However, declaring every instance of Res an instance of Res2 seems impossible, as the following doesn't compile > instance Res a b => Res2 a where > type Member a = b > getRes2 x = getRes x Question is: How to do this? The reason I need it is because I use a library which uses functional dependencies, but my classes shall be type families. Regards, Henning From anton at appsolutions.com Thu Mar 27 21:26:35 2008 From: anton at appsolutions.com (Anton van Straaten) Date: Thu Mar 27 21:21:36 2008 Subject: [Haskell-cafe] Unescaping with HaXmL (or anything else!) Message-ID: <47EC494B.2040105@appsolutions.com> I want to unescape an encoded XML or HTML string, e.g. converting " to the quote character, etc. Since I'm using HaXml anyway, I tried using xmlUnEscapeContent with no luck, e.g. with HaXml 1.19.1: let (CString _ s _) = head $ xmlUnEscapeContent stdXmlEscaper $ [CString False "This is a "quoted string"" ()] in s The result is unchanged, i.e. "This is a "quoted string"". Am I doing something wrong, or are my expectations wrong, or is this a bug? Or, is there any other library that includes a simple unescape function for XML or HTML? (The Network.URI module includes an unescape function, but that's specific to URIs, naturally.) Anton From ryani.spam at gmail.com Thu Mar 27 21:33:55 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Thu Mar 27 21:30:10 2008 Subject: [Haskell-cafe] MonadMemory class In-Reply-To: <200803280303.12296.valgarv@gmx.net> References: <200803280002.39437.valgarv@gmx.net> <2f9b2d30803271600w190cfce6s75063a910797261f@mail.gmail.com> <200803280303.12296.valgarv@gmx.net> Message-ID: <2f9b2d30803271833t5a1b1b19pdff55712c6870ce8@mail.gmail.com> On 3/27/08, Ariel J. Birnbaum wrote: > > (write r x >>= read) == (write r x >> return x) > You probably mean (write r x >> read r) == (write r x >> return x)? Yes. Oops! > > 3) References are independent: > > If m does not refer to r, then: > > (read r >>= (\x -> m >> return x)) == m >> read r > > (write r x >> m) == m >>= (\v -> write r x >> return v) > What if m writes to r' which is read by another thread, which in turn writes > another value into r? > What exactly does "does not refer to r" mean? I was going for an intuitive definition, not quite a formal one. An approximation is: doesn't have a reference to "r" or to any other reference that refers to r (recursively). I was not considering parallelism; that does break this axiom. A weaker form of the axiom which doesn't break in the face of parallelism and is more formal: (new x >>= (\r -> m >> return r)) == (m >> new x) > > It's possible without unsafeCoerce if you add a Typeable constraint or pass > > a GADT type representation to new. > Care to develop? Sure: http://ryani.freeshell.org/haskell/RefMonad.hs Here's the module header: {-# LANGUAGE GADTs, ExistentialQuantification, Rank2Types #-} module RefMonad ( TypRep(..), -- TypRep a, GADT reifying type representation of a Typeable, -- typeclass of types that have a TypRep typRep, -- :: TypRep a Dynamic(..), -- Dynamic (TypRep a) a castDyn, -- :: Typeable a => Dynamic -> Maybe a RefM, -- RefM s a. abstract, instance of Monad. -- s represents the "heap state" runRefM, -- :: (forall s. RefM s a) -> a -- "forall" forces us to not care about the initial state of the heap. Ref, -- Ref s a. abstract reference to objects of type a newRef, -- :: Typeable a => a -> RefM s (Ref a) readRef, -- :: Ref s a -> RefM s a writeRef -- :: Ref s a -> a -> RefM s () ) Things to notice: 1) RefM & Ref have to be abstract, otherwise we can break type safety by constructing invalid heaps or references, leading to "error" in one of the fromMaybe calls in readRef. 2) newRef has a Typeable constraint; this allows us to avoid unsafeCoerce by doing "dynamic" casts using a type equality check. 3) Check out the type of runRefM. 4) No garbage collection :( > > To be truly safe you need higher-rank types and use the same trick > > that ST does. > Here I was, naively thinking I could put off learning about that for now ;) It's not that complicated; the trick is all in the type of runST (which I copy in runRefM) runRefM :: (forall s. RefM s a) -> a Now, references can't escape from runRefM; consider: runRefM (newRef (1 :: Integer)) newRef (1 :: Integer) has type forall s. RefM s (Ref s Integer) Trying to apply runRefM to this we get (forall s. RefM s (Ref s Integer)) -> Ref s Integer which won't typecheck because the type variable "s" escapes from quantification. > > But there's not much point; you may as well use ST. > Not much *practical* point, I agree. I mostly asked out of curiosity. Of course, learning is its own reward :) > > Handling garbage collection is tricky, though. > Can it even be done without compiler support? I'm not sure. I'm suspect not, but I can't prove it. -- ryan From ryani.spam at gmail.com Thu Mar 27 22:03:40 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Thu Mar 27 21:59:54 2008 Subject: [Haskell-cafe] Recursion problem in infinite list model In-Reply-To: References: <7CD6C496-9327-4982-90D3-82240C8BFD28@math.su.se> <47EBAC98.5020709@goto10.org> <7ca3f0160803270732y5163f102xc2feb4e02865fa2c@mail.gmail.com> <7ca3f0160803270951y9fb1d26u1ae1977f6bfcbc06@mail.gmail.com> Message-ID: <2f9b2d30803271903v70c841f4r1868f7cef8f2c3@mail.gmail.com> Another way to defer the evaluation of the second argument of (-+) is like this: (-+) :: a -> List a -> List a x -+ y = List(f) where f 0 = x f k = case y of List g -> g (k-1) This is exactly what the lazy pattern will do at compile-time. Does this give you a better understanding of how lazy patterns work and why they fix the problem? -- ryan On 3/27/08, Hans Aberg wrote: > On 27 Mar 2008, at 17:51, Luke Palmer wrote: > > > A more standard way to do this would be: > > > > data List a = List (Ordinal -> a) Ordinal > > I used > data List a = Empty | (Ordinal->a) :+ Ordinal > which might then be simplified by dropping "Empty". > > Hans Aberg > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From s.clover at gmail.com Fri Mar 28 00:07:08 2008 From: s.clover at gmail.com (Sterling Clover) Date: Fri Mar 28 00:03:57 2008 Subject: [Haskell-cafe] Web server libraries In-Reply-To: References: Message-ID: <56815270-E934-4C6D-97D1-549F799C2A5A@gmail.com> While hvac, which I announced here recently, is not yet ready for primetime, so to speak, you may want to take a look at it -- with a few tweaks it should match your specs. (darcs get http:// community.haskell.org/~sclv/hvac/) It does include some templating, though you don't have to use it significantly, but then again, I find it hard to automate data validation without it (how else do you control showing results?), and it does allow for session support, although it isn't necessary. It is, however FastCGI based and has built-in connection pooling. It should theoretically be able to speak to any database that HDBC speaks to, although it does need a little work (here's the modification issue) to ensure the strong atomicity constraints work properly with anything but sqlite. Additionally, the validation functionality should be very powerful and intuitive, and the control flow combinators equally so, which are also written to parse RESTful parameters as part of url strings as well. Not sure what you mean by marshalling to-from Haskell types -- the validation provides one side of it, and on the other, as you well know, HDBC gives a very convenient way to deal with the SQL end :-) The less tested/more dicey parts of hvac are all those that deal with atomicity and caching, and if you're not relying on those, then that shouldn't be an issue either. And the only questions there, in my mind at least, are to what degree running everything out of STM (i.e. optimistically) could lead to problems in high-contention environments -- so again, possibly not an issue for your needs in any case. As for event model -- hvac tries to be nonjudgemental, though it is request rather than continuations-based and is mainly designed to be REST. One could implement a "conversations" layer over sessions without too much work -- alternately, control flow can be parameter based, much as one would do in plenty of other web frameworks. Finally, although the atomic stuff is what makes hvac fun, one could rip out either the controller or validation sections without too much work and act directly over FastCGI. On its own even, the FastCGI lib isn't perfect, but as Paul Brown noted, its not too hard to build a few nice structures on top of it to handle whatever you throw at it. Regards, Sterl. On Mar 27, 2008, at 3:26 PM, John Goerzen wrote: > Hi again, > > I'm currently working on a project that has a Web interface to data > stored in a SQL database. I wrote this thing in WASH a few years > back. Overall, this has been acceptable, but the non-Haskell-adepts > around here run away screaming from the code. Not only that, but we > don't get control over the names of the form elements, which can make > interacting with other software that sometimes plonks users down > halfway through the process -- well, interesting. Also, WASH supports > nothing better than CGI, which is a big minus when talking to SQL > databases. > > What I really want is some sort of simple tool that supports FastCGI > or some such, has basic support for form data input validation and > marshalling to/from Haskell types, and basic control flow. I don't > need, or really particularly want, something that uses hs-plugins to > compile pages on demand (I'm using Haskell for it's static safety, > after all). Nor do I need fancy templating systems or session support > (we use HTTP auth and are fine with it for now.) > > So I've looked around a bit at the landscape. Any recommendations? > > I've found these: > > HSP: big on "dynamic pages". I don't want to make my webserver able > to compile Haskell code. Develop code, compile, test, make sure it's > right, then push to production every 6 months around here. > > WASH: Pretty much the right niche, but the event model is hard to use. > > HAppS: Frankly it is a big collection of confusing packages to me. > What > documentation exists doesn't seem to be relevant anymore, and it seems > to be designed to not use a SQL database. > > FastCGI: Relies upon CGI for a good part of processing. Does not seem > to have any form data validation support built in. > > Thanks again, > > -- John > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From dan.doel at gmail.com Fri Mar 28 00:21:11 2008 From: dan.doel at gmail.com (Dan Doel) Date: Fri Mar 28 00:17:30 2008 Subject: [Haskell-cafe] Sound typeable via type families? Message-ID: <200803280021.12039.dan.doel@gmail.com> Hello, Recently, someone (I forgot who, exactly) mentioned in #haskell this article: http://okmij.org/ftp/Haskell/types.html#unsound-typeable where Oleg demonstrates that Typeable makes the type system unsound, and one can get back unsafeCoerce (which is used in the implementation, I suspect). However, this evening, Ryan Ingram showed how to construct a safe Typeable using GADTs. The problem with that, of course, is that GADTs aren't open, so one can only have a predefined number of Typeables. However, it occurred to me that data families don't have that problem, so I took a shot and came up with the following: {-# LANGUAGE TypeFamilies, ScopedTypeVariables, GADTs , MultiParamTypeClasses, FlexibleInstances, OverlappingInstances #-} class Typeable t where data TypeRep t :: * typeRep :: TypeRep t instance Typeable Int where data TypeRep Int = TInt typeRep = TInt instance Typeable Integer where data TypeRep Integer = TInteger typeRep = TInteger instance Typeable () where data TypeRep () = TUnit typeRep = TUnit data TEq a b where Refl :: TEq a a class (Typeable a, Typeable b) => TEquality a b where teq :: TypeRep a -> TypeRep b -> Maybe (TEq a b) instance (Typeable a) => TEquality a a where teq _ _ = Just Refl instance (Typeable a, Typeable b) => TEquality a b where teq _ _ = Nothing cast :: forall a b. (TEquality a b) => a -> Maybe b cast a = do Refl <- teq ta tb return a where ta :: TypeRep a ta = typeRep tb :: TypeRep b tb = typeRep Which, somewhat to my surprise, actually works. And, of course, if one tries to pull off Oleg's trick: newtype Oleg a = Oleg { unOleg :: a } instance Typeable (Oleg a) where TypeRep (Oleg a) = ... typeRep = ?? Well, it won't work, because TypeRep () ~/~ TypeRep (Oleg a). However, obviously, this depends on overlapping instances (if there's some other way, I'd be happy to know; if type inequality contexts are available, I wasn't able to find them), and I've heard that type families don't play well with overlap. Does that not apply to data families? Will this construction still work in 6.10 and beyond? Also, this doesn't seem to be a suitable basis for Dynamic. Trying to extend the GADT solution presented resulted in errors unless incoherent instances were turned on (clearly not a good sign), and even then, it didn't actually work. Is it possible to do better, and come away with something that will actually work for Dynamic, and be sound? Is there some other trick waiting to pull unsafeCoerce out of this setup (seems doubtful, as it isn't used in the code, and the type families folks have no doubt done plenty of work to ensure soundness)? Comments appreciated. -- Dan From haskell-cafe at jbapple.com Fri Mar 28 02:00:57 2008 From: haskell-cafe at jbapple.com (Jim Apple) Date: Fri Mar 28 01:57:16 2008 Subject: [Haskell-cafe] Running classical logic Message-ID: <27c593d70803272300l71c80cdatacf8d78b097f1a48@mail.gmail.com> We can't safely extract a t out of IO t, but we can run an IO t, interact with the environment, and then see the t. Griffin ( http://citeseer.ist.psu.edu/griffin90formulaeastypes.html ) explained that we can do the same thing with (t -> r) -> r by interacting with the context. That is, he defined a function c :: ((t -> r) -> r) -> t buy interaction with the reduction context of calls to c. I don't expect such a function to be definable in Haskell without some magic, but even with magic, I'm not sure how to write such a function. On #haskell a couple of days ago, we came up with data Empty deriving Typeable toEmpty :: a -> Empty toEmpty = unsafeCoerce fromEmpty :: Empty -> a fromEmpty = unsafeCoerce type Bot = forall x . x griffinC :: Cont Bot a -> IO a griffinC (Cont f) = do key <- newUnique catch (evaluate $ f $ \v -> throwDyn (hashUnique key,toEmpty v)) (\x -> case x of DynException d -> case fromDynamic d of Just (u,y) -> if u == hashUnique key then return $ fromEmpty y else throwIO x Nothing -> throwIO x _ -> throwIO x) The Unique is used to keep the later griffinC calls from being cast to the wrong types. The more I look at this, the less I understand it. Any clues? Jim P.S. Thanks to #haskell, and especially roconnor for the fine help From jsnow at cs.pdx.edu Fri Mar 28 02:28:42 2008 From: jsnow at cs.pdx.edu (Jim Snow) Date: Fri Mar 28 02:23:31 2008 Subject: [Haskell-cafe] Glome raytracer bug: bad output with -O2 -fasm Message-ID: <47EC901A.3050207@cs.pdx.edu> I was trying to get Blinn highlights working with my raytracer, and kept getting ugly artifacts. After trying a bunch of things, I finally compiled without -O2, and the artifacts went away. Here's what I mean: http://syn.cs.pdx.edu/~jsnow/glome/Glome.hs-noartifact.png http://syn.cs.pdx.edu/~jsnow/glome/Glome.hs-artifact.png Here's the offending code, run "./make" and "./run" and you should see the artifacts if your setup is the same as mine. (Requires OpenGL.) http://syn.cs.pdx.edu/~jsnow/glome/glome.hs-0.2-bug.tar.gz The artifacts also go away if I use -fvia-C. It doesn't seem to matter whether I use Floats or Doubles in the rendering code. The artifacts also show up with -O1. Have I stumbled across a known compiler bug? Or perhaps an OpenGL bug? (The bug could, of course, be in my code, but then one might expect to get the same erroneous output every time regardless of compiler flags.) To reiterate, I'm using ghc 8.6.2. thanks, -jim From haberg at math.su.se Fri Mar 28 04:28:19 2008 From: haberg at math.su.se (Hans Aberg) Date: Fri Mar 28 04:24:40 2008 Subject: [Haskell-cafe] Recursion problem in infinite list model In-Reply-To: <2f9b2d30803271903v70c841f4r1868f7cef8f2c3@mail.gmail.com> References: <7CD6C496-9327-4982-90D3-82240C8BFD28@math.su.se> <47EBAC98.5020709@goto10.org> <7ca3f0160803270732y5163f102xc2feb4e02865fa2c@mail.gmail.com> <7ca3f0160803270951y9fb1d26u1ae1977f6bfcbc06@mail.gmail.com> <2f9b2d30803271903v70c841f4r1868f7cef8f2c3@mail.gmail.com> Message-ID: <48736FCE-3B59-4626-A424-B54FF443F992@math.su.se> On 28 Mar 2008, at 03:03, Ryan Ingram wrote: > Another way to defer the evaluation of the second argument of (-+) > is like this: > > (-+) :: a -> List a -> List a > x -+ y = List(f) where > f 0 = x > f k = case y of List g -> g (k-1) > > This is exactly what the lazy pattern will do at compile-time. Thank you for inputs - I discovered adding ordinal length made it tricky to get the lazy evaluation I called for. The problem is that I use data List a = (Ordinal->a) :+ Ordinal and then in (-++) :: a -> List a -> List a x -++ (b:+ q) = f:+(1+q) where f 0 = x f k = b(k-1) possibly I need to get both b and q to be lazy. I tried experimenting with putting i ~also on them, but it did not seem to work. So I may have to experiment a bit more, and perhaps return with a more completet example later. But inputs are welcome. > Does > this give you a better understanding of how lazy patterns work and why > they fix the problem? I had such rewriting in mind as well, but could not figure out the right blend. The manual call the lazy pattern "irrefutable". The terminology you use here is more intuitive. It show a problem in language design: Haskell has mad a choice of strict and lazy evaluation in different context, but it has the disadvantage of hiding away the semantics. Something to think about when designing the next lazy computer language. :-) Hans Aberg From pkeir at dcs.gla.ac.uk Fri Mar 28 05:02:19 2008 From: pkeir at dcs.gla.ac.uk (Paul Keir) Date: Fri Mar 28 05:01:35 2008 Subject: [Haskell-cafe] Parsec Expected Type References: <3CDFB8AFEA98E34CB599475AB11589C80CC9BF@EX2.ad.dcs.gla.ac.uk> <7ca3f0160803271726m21c444c5x7c417afd686eb9b6@mail.gmail.com> Message-ID: <3CDFB8AFEA98E34CB599475AB11589C80CC9C0@EX2.ad.dcs.gla.ac.uk> Thanks, I'd thought it was something to do with incompatible types. I can now create a simpler problem: tester2 = reserved "parameter" <|> symbol ":" Certainly I could use reserved ":" instead of symbol, but where is my thinking with symbol here going wrong? Surely the above example isn't so odd? Paul -----Original Message----- From: Luke Palmer [mailto:lrpalmer@gmail.com] Sent: Fri 3/28/2008 12:26 AM To: Paul Keir Cc: haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] Parsec Expected Type Hi Paul, 2008/3/27 Paul Keir : > Hi, > > Does anyone know why this reduced Parsec production stops compilation, and > how I can fix it? > > tester = reserved "parameter" > <|> do { reserved "dimension"; symbol ":" } Look at the types of "reserved" and "symbol" (from http://www.haskell.org/ghc/docs/latest/html/libraries/parsec/Text-ParserCombinators-Parsec-Token.html): symbol :: String -> CharParser st String reserved :: String -> CharParser st () The type of a do block is the same as the type of its last statement. But (reserved "parameter") and (symbol ";") do not have the same type. Luke -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080328/69d305b7/attachment.htm From lemming at henning-thielemann.de Fri Mar 28 05:20:51 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri Mar 28 05:15:50 2008 Subject: [Haskell-cafe] Unescaping with HaXmL (or anything else!) In-Reply-To: <47EC494B.2040105@appsolutions.com> References: <47EC494B.2040105@appsolutions.com> Message-ID: On Thu, 27 Mar 2008, Anton van Straaten wrote: > I want to unescape an encoded XML or HTML string, e.g. converting " to > the quote character, etc. > > Since I'm using HaXml anyway, I tried using xmlUnEscapeContent with no luck, > e.g. with HaXml 1.19.1: > > let (CString _ s _) = > head $ xmlUnEscapeContent stdXmlEscaper $ > [CString False "This is a "quoted string"" ()] in s > > The result is unchanged, i.e. "This is a "quoted string"". > > Am I doing something wrong, or are my expectations wrong, or is this a bug? > > Or, is there any other library that includes a simple unescape function for > XML or HTML? Tagsoup must contain such a function but it doesn't seem to export it. From jason.dusek at gmail.com Fri Mar 28 05:34:18 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Fri Mar 28 05:30:31 2008 Subject: [Haskell-cafe] compilation succeeds -- execution fails Message-ID: <42784f260803280234u7862f0f9xda69fee5df5bb613@mail.gmail.com> I have a program here: https://svn.j-s-n.org/public/haskell/cedict currently at revision 302, which compiles okay but I can't get it to work. I'm using the FFI to take a (currently small) array and translate it into a Map. It compiles fine and loads fine -- but it doesn't run fine: GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Prelude> import Data.Char.CEDICT Prelude Data.Char.CEDICT> traditional 'a' Loading package array-0.1.0.0 ... linking ... done. Loading package containers-0.1.0.1 ... linking ... done. Loading package parsec-2.1.0.0 ... linking ... done. Loading package utf8-string-0.2 ... linking ... done. Loading package cedict-0.1.1 ... linking ... : unknown symbol `___stginit_cedictzm0zi1zi1_DataziCharziCEDICTziMatter_' ghc-6.8.2: unable to load package `cedict-0.1.1' Prelude Data.Char.CEDICT> I'm on a Mac -- Leopard. A whole bunch of things *could* be wrong -- I'd appreciate some help in narrowing the list. -- _jsn From nominolo at googlemail.com Fri Mar 28 05:40:15 2008 From: nominolo at googlemail.com (Thomas Schilling) Date: Fri Mar 28 05:36:36 2008 Subject: [Haskell-cafe] compilation succeeds -- execution fails In-Reply-To: <42784f260803280234u7862f0f9xda69fee5df5bb613@mail.gmail.com> References: <42784f260803280234u7862f0f9xda69fee5df5bb613@mail.gmail.com> Message-ID: <2008C6B0-7580-43B7-BF1F-7EC812DF02EE@googlemail.com> Did you try removing all .hi and .o files? On 28 mar 2008, at 10.34, Jason Dusek wrote: > I have a program here: > > https://svn.j-s-n.org/public/haskell/cedict > > currently at revision 302, which compiles okay but I can't get > it to work. I'm using the FFI to take a (currently small) > array and translate it into a Map. > > It compiles fine and loads fine -- but it doesn't run fine: > > GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help > Loading package base ... linking ... done. > Prelude> import Data.Char.CEDICT > Prelude Data.Char.CEDICT> traditional 'a' > Loading package array-0.1.0.0 ... linking ... done. > Loading package containers-0.1.0.1 ... linking ... done. > Loading package parsec-2.1.0.0 ... linking ... done. > Loading package utf8-string-0.2 ... linking ... done. > Loading package cedict-0.1.1 ... linking ... : > unknown symbol > `___stginit_cedictzm0zi1zi1_DataziCharziCEDICTziMatter_' > ghc-6.8.2: unable to load package `cedict-0.1.1' > Prelude Data.Char.CEDICT> > > I'm on a Mac -- Leopard. A whole bunch of things *could* be > wrong -- I'd appreciate some help in narrowing the list. > > -- > _jsn > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From g9ks157k at acme.softbase.org Fri Mar 28 05:47:53 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Fri Mar 28 05:44:39 2008 Subject: [Haskell-cafe] Functional dependencies with Type Classes In-Reply-To: <1206666748.13298.27.camel@localhost> References: <1206666748.13298.27.camel@localhost> Message-ID: <200803281047.53280.g9ks157k@acme.softbase.org> Am Freitag, 28. M?rz 2008 02:12 schrieb Henning G?nther: > Hi, > > suppose there are two (identical) classes: > > class Res a b | a -> b where > > getRes :: a -> b > > and > > > class Res2 t where > > type Member t > > getRes2 :: t -> Member t > > It is easy to automatically make every instance of Res2 an instance of > > res: > > instance Res2 a => Res a (Member a) where > > getRes x = getRes2 x > > However, declaring every instance of Res an instance of Res2 seems > impossible, as the following doesn't compile > > > instance Res a b => Res2 a where > > type Member a = b > > getRes2 x = getRes x > > Question is: How to do this? The reason I need it is because I use a > library which uses functional dependencies, but my classes shall be type > families. > > Regards, > Henning Hello Henning, I also came across this problem half a year ago, tried to find a solution and came to the conclusion that there is none. It seems as if functional dependencies are a trap: Once you?ve started using them it is impossible to escape them by switching to type families. So you?ll probably have your own code use functional dependencies too (This was the ?solution? I used in my case.) or you have to rewrite the library to use type families. Best wishes, Wolfgang From dekudekuplex at yahoo.com Fri Mar 28 05:59:19 2008 From: dekudekuplex at yahoo.com (Benjamin L. Russell) Date: Fri Mar 28 05:55:33 2008 Subject: [Haskell-cafe] Wumpus World In-Reply-To: <938B3F1C-6C2F-4EA2-9AAF-20828D95E187@cs.otago.ac.nz> Message-ID: <49343.38306.qm@web30203.mail.mud.yahoo.com> --- "Richard A. O'Keefe" wrote: > [snip] > > The Prolog results at > http://shootout.alioth.debian.org/ > are only for the open source system SWI Prolog, > which is basically > a one-man effort. The commercial SICStus Prolog is > substantially > faster. Some of the Prolog benchmark versions look > distinctly odd. The commercial SICStus Prolog is also substantially more expensive (see http://www.sics.se/isl/sicstuswww/site/index.html), at 153 euros for a Personal License (see http://www.sics.se/isl/sicstuswww/site/order4.html). Prices for Academic, Single-User Commercial, and Multi-User Commercial licenses are even more expensive, at 1560, 1980, and 7800 euros, respectively. An Evaluation License is only valid for 30 days. Not all students and researchers can afford a Personal License. Can you recommend an alternative, fast Prolog development system under a free licensing agreement, such as GPL/GLPL? Benjamin L. Russell From haberg at math.su.se Fri Mar 28 06:07:14 2008 From: haberg at math.su.se (Hans Aberg) Date: Fri Mar 28 06:03:31 2008 Subject: [Haskell-cafe] Recursion problem in infinite list model In-Reply-To: <2f9b2d30803271903v70c841f4r1868f7cef8f2c3@mail.gmail.com> References: <7CD6C496-9327-4982-90D3-82240C8BFD28@math.su.se> <47EBAC98.5020709@goto10.org> <7ca3f0160803270732y5163f102xc2feb4e02865fa2c@mail.gmail.com> <7ca3f0160803270951y9fb1d26u1ae1977f6bfcbc06@mail.gmail.com> <2f9b2d30803271903v70c841f4r1868f7cef8f2c3@mail.gmail.com> Message-ID: <758EEB02-7E3C-47FB-862C-ECCA3DBA29A3@math.su.se> On 28 Mar 2008, at 03:03, Ryan Ingram wrote: > Another way to defer the evaluation of the second argument of (-+) > is like this: > > (-+) :: a -> List a -> List a > x -+ y = List(f) where > f 0 = x > f k = case y of List g -> g (k-1) > > This is exactly what the lazy pattern will do at compile-time. Does > this give you a better understanding of how lazy patterns work and why > they fix the problem? > I have various other patterns that need to be forced lazy - inputs welcome. In the code below, where I have put in a "0" instead of the first uncountable ordinal w, if I include in "show" the case a == 0, then h (list 6) won't print, as then the value of "a" is computed. And in the ordinal version data List a = (Ordinal->a) :+ Ordinal then the function (-+) :: a -> List a -> List a x -+ ~(y :+ q) = f:+(1+q) where f 0 = x f k = y(k-1) does not compute, because there is a similar problem with the 1+q evaluation, I think this is because the class Ordinal + uses case: instance Num Ordinal where x + y | finite x && finite y = toOrdinal(tcoef x + tcoef y) x + y | lexp x < lexp y = y x + y | lexp x == lexp y = prepend (lexp x, lcoef x + lcoef y) (trail y) x + y = prepend (lexp x, lcoef x) ((trail x) + y) So these patterns perhaps should be made lazy. though I do not know exactly how. Hans -------- infixr 5 :+ data List a = (Integer->a) :+ Integer instance Show a => Show (List a) where -- show (f:+a) | a == 0 = "[]" show (f :+ a) = "[" ++ show (f(0)) ++ concat ["," ++ show (f(toInteger i))| i<-[1..]] ++ "]" list :: Integer -> List Integer list x = (\z -> x+z) :+ 0 (-+) :: a -> List a -> List a x -+ ~(y :+ q) = f:+(1+q) where f 0 = x f k = y(k-1) first :: List a -> a first (f :+ _) = f 0 rest :: List a -> List a rest (y :+ _) = f :+ 0 where f k = y(k+1) h :: List a -> List a h x = (-+) (first x) (h (rest x)) -------- From Andrew.Butterfield at cs.tcd.ie Fri Mar 28 06:34:19 2008 From: Andrew.Butterfield at cs.tcd.ie (Andrew Butterfield) Date: Fri Mar 28 06:30:35 2008 Subject: [Haskell-cafe] Wumpus World In-Reply-To: <49343.38306.qm@web30203.mail.mud.yahoo.com> References: <49343.38306.qm@web30203.mail.mud.yahoo.com> Message-ID: <47ECC9AB.1090203@cs.tcd.ie> Benjamin L. Russell wrote: > > > Not all students and researchers can afford a Personal > License. Can you recommend an alternative, fast > Prolog development system under a free licensing > agreement, such as GPL/GLPL? > For Mac users, https://www.cs.tcd.ie/open-prolog/ might be worth a look > From Tom.Schrijvers at cs.kuleuven.be Fri Mar 28 06:45:04 2008 From: Tom.Schrijvers at cs.kuleuven.be (Tom Schrijvers) Date: Fri Mar 28 06:42:27 2008 Subject: [Haskell-cafe] Wumpus World In-Reply-To: <49343.38306.qm@web30203.mail.mud.yahoo.com> References: <49343.38306.qm@web30203.mail.mud.yahoo.com> Message-ID: > Not all students and researchers can afford a Personal > License. Can you recommend an alternative, fast > Prolog development system under a free licensing > agreement, such as GPL/GLPL? SWI-Prolog is about the best and most popular open Prolog system: http://www.swi-prolog.org It's not the fastest, just like GCC doesn't generates the fastest code. Who cares? If you want speed, then Yap is the best open Prolog system. http://www.ncc.up.pt/~vsc/Yap/ Cheers, Tom -- Tom Schrijvers Department of Computer Science K.U. Leuven Celestijnenlaan 200A B-3001 Heverlee Belgium tel: +32 16 327544 e-mail: tom.schrijvers@cs.kuleuven.be url: http://www.cs.kuleuven.be/~toms/ From jerzy.karczmarczuk at info.unicaen.fr Fri Mar 28 06:50:29 2008 From: jerzy.karczmarczuk at info.unicaen.fr (jerzy.karczmarczuk@info.unicaen.fr) Date: Fri Mar 28 06:46:43 2008 Subject: [Haskell-cafe] Wumpus World In-Reply-To: <47ECC9AB.1090203@cs.tcd.ie> References: <49343.38306.qm@web30203.mail.mud.yahoo.com> <47ECC9AB.1090203@cs.tcd.ie> Message-ID: > Benjamin L. Russell wrote: >> >> >> Not all students and researchers can afford a Personal >> License. Can you recommend an alternative, fast >> Prolog development system under a free licensing >> agreement, such as GPL/GLPL? You have quite a choice if you relax your licensing requirements: http://www.thefreecountry.com/compilers/prolog.shtml You will find there the GNU-Prolog, whose licensing should be as you wish. Jerzy Karczmarczuk From g9ks157k at acme.softbase.org Fri Mar 28 06:55:18 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Fri Mar 28 06:51:43 2008 Subject: [Haskell-cafe] Sound typeable via type families? In-Reply-To: <200803280021.12039.dan.doel@gmail.com> References: <200803280021.12039.dan.doel@gmail.com> Message-ID: <200803281155.18200.g9ks157k@acme.softbase.org> Am Freitag, 28. M?rz 2008 05:21 schrieb Dan Doel: > [?] > However, obviously, this depends on overlapping instances (if there's some > other way, I'd be happy to know; if type inequality contexts are available, > I wasn't able to find them), and I've heard that type families don't play > well with overlap. Does that not apply to data families? Will this > construction still work in 6.10 and beyond? > > Also, this doesn't seem to be a suitable basis for Dynamic. Trying to > extend the GADT solution presented resulted in errors unless incoherent > instances were turned on (clearly not a good sign), and even then, it > didn't actually work. Is it possible to do better, and come away with > something that will actually work for Dynamic, and be sound? I don?t know exactly whether this helps here but with open type families you will be able to define a type-level type equality decision. See the mail at . > [?] Best wishes, Wolfgang From haberg at math.su.se Fri Mar 28 08:40:49 2008 From: haberg at math.su.se (Hans Aberg) Date: Fri Mar 28 08:37:05 2008 Subject: [Haskell-cafe] Recursion problem in infinite list model In-Reply-To: <2f9b2d30803271903v70c841f4r1868f7cef8f2c3@mail.gmail.com> References: <7CD6C496-9327-4982-90D3-82240C8BFD28@math.su.se> <47EBAC98.5020709@goto10.org> <7ca3f0160803270732y5163f102xc2feb4e02865fa2c@mail.gmail.com> <7ca3f0160803270951y9fb1d26u1ae1977f6bfcbc06@mail.gmail.com> <2f9b2d30803271903v70c841f4r1868f7cef8f2c3@mail.gmail.com> Message-ID: <3A565266-3084-48CF-A739-09DE789367AF@math.su.se> On 28 Mar 2008, at 03:03, Ryan Ingram wrote: > Another way to defer the evaluation of the second argument of (-+) > is like this: > > (-+) :: a -> List a -> List a > x -+ y = List(f) where > f 0 = x > f k = case y of List g -> g (k-1) > > This is exactly what the lazy pattern will do at compile-time. Does > this give you a better understanding of how lazy patterns work and why > they fix the problem? I can isolate the problem with the addition in the code below, where I have defined a type Natural just in order to introduce a user defined operator. - For ordinals, it is more complicated. Then h (list 6) only printouts "[N 6,", after which it gets stuck in the Natural.+. Adding ~ to (N x) + (N y) does not help, nor other variations. But replacing Natural with integer, produces the normal infinite list printout. So it must be here it is stuck. Hans -------- infix 5 :+ data Natural = N Integer deriving (Eq, Show) instance Num Natural where fromInteger x = N x abs x = x signum 0 = 0 signum _ = 1 (N x) + (N y) = N(x + y) data List a = (Natural->a) :+ Natural instance Show a => Show (List a) where show (f :+ _) = "[" ++ show (f(0)) ++ concat ["," ++ show (f(N (toInteger i)))| i<-[1..]] ++ "]" list :: Natural -> List Natural list x = (\z -> x+z) :+ 0 (-+) :: a -> List a -> List a x -+ ~(y :+ q) = f:+(1+q) where f 0 = x f k = y(k-1) first :: List a -> a first (f :+ _) = f 0 rest :: List a -> List a rest (y :+ _) = f :+ 0 where f k = y(k+1) h :: List a -> List a h x = (-+) (first x) (h (rest x)) -------- From haberg at math.su.se Fri Mar 28 09:23:28 2008 From: haberg at math.su.se (Hans Aberg) Date: Fri Mar 28 09:19:45 2008 Subject: [Haskell-cafe] Recursion problem in infinite list model In-Reply-To: <2f9b2d30803271903v70c841f4r1868f7cef8f2c3@mail.gmail.com> References: <7CD6C496-9327-4982-90D3-82240C8BFD28@math.su.se> <47EBAC98.5020709@goto10.org> <7ca3f0160803270732y5163f102xc2feb4e02865fa2c@mail.gmail.com> <7ca3f0160803270951y9fb1d26u1ae1977f6bfcbc06@mail.gmail.com> <2f9b2d30803271903v70c841f4r1868f7cef8f2c3@mail.gmail.com> Message-ID: I have fixed the problem now. In the last letter, with the Natural class, I had not added instance Num Natural where (N x) - (N y) = N(x - y) which the Ordinal class then in fact has one. Then it turns out that it is merely the fact that "show" had some cases looking at the list length that blocked its output. So there, one should probably have some recursion that extracts elements one by one, without computing list length, and adds a termination 2]" if the remaining list is empty. So it seems possible to emulate Haskell list behavior with this model, which is one thing I wanted to know. Hans From lemming at henning-thielemann.de Fri Mar 28 09:43:52 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri Mar 28 09:38:50 2008 Subject: [Haskell-cafe] Monad instance for Data.Set, again In-Reply-To: <200803280106.00061.g9ks157k@acme.softbase.org> References: <200803280106.00061.g9ks157k@acme.softbase.org> Message-ID: On Fri, 28 Mar 2008, Wolfgang Jeltsch wrote: > But it is possible to give a construction of an Ord dictionary from an > AssociatedMonad dictionary. See the attached code. It works like a > charm. :-) Yeah, type families! In which GHC release they will be included? Sometimes I wonder how many single type extensions we will see in future or whether there will be one mechanism which subsumes all existing ones in a simple manner. (Full logic programming on type level? Manual determination of the class dictionary to be used?) From jonathanccast at fastmail.fm Fri Mar 28 10:05:50 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Fri Mar 28 10:02:06 2008 Subject: [Haskell-cafe] Parsec Expected Type In-Reply-To: <3CDFB8AFEA98E34CB599475AB11589C80CC9C0@EX2.ad.dcs.gla.ac.uk> References: <3CDFB8AFEA98E34CB599475AB11589C80CC9BF@EX2.ad.dcs.gla.ac.uk> <7ca3f0160803271726m21c444c5x7c417afd686eb9b6@mail.gmail.com> <3CDFB8AFEA98E34CB599475AB11589C80CC9C0@EX2.ad.dcs.gla.ac.uk> Message-ID: On 28 Mar 2008, at 2:02 AM, Paul Keir wrote: > Thanks, I'd thought it was something to do with incompatible types. > I can now create a simpler problem: > > tester2 = reserved "parameter" <|> symbol ":" > > Certainly I could use reserved ":" instead of symbol, but where is > my thinking with symbol here going wrong? Surely the above example > isn't so odd? > What type do you expect tester2 to return? jcc -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080328/93dac467/attachment.htm From jgoerzen at complete.org Fri Mar 28 09:42:28 2008 From: jgoerzen at complete.org (John Goerzen) Date: Fri Mar 28 10:04:37 2008 Subject: [Haskell-cafe] Re: HTTP client libraries References: <4249453d0803271438v345912d9ndcf8f9c4c066dc07@mail.gmail.com> <20080328000218.GC18093@scytale.galois.com> Message-ID: On 2008-03-28, Don Stewart wrote: > paulrbrown+haskell-cafe: > And we have a curl binding, already in wide use. > > http://code.haskell.org/curl.git/ > > a release to hackage is imminent. Do you mean this? http://hackage.haskell.org/cgi-bin/hackage-scripts/package/curl-1.3.1 Looks like it's not quite as current as your Git repo. -- John From jgoerzen at complete.org Fri Mar 28 09:40:28 2008 From: jgoerzen at complete.org (John Goerzen) Date: Fri Mar 28 10:06:18 2008 Subject: [Haskell-cafe] Re: HTTP client libraries References: <396556a20803271627s2da60f7nc255b8c05dc20c8f@mail.gmail.com> Message-ID: On 2008-03-27, Adam Langley wrote: > On Thu, Mar 27, 2008 at 12:08 PM, John Goerzen wrote: >> * network-minihttp >> >> Doesn't appear to actually be very useful as a client. >> >> Also, as far as I have been able to deduce, none of these have >> built-in support for https (SSL) URLs. > > The client doesn't do a lot, but I don't know what you would want from > a client. Email me a list of use cases and ;) You know, it actually looks very nice to me. I don't know what I was looking at before, but I've poked around at your sources a bit and I like what I see. The fact that I can get a result as a lazy ByteString is nice. Your Source type is an interesting approach, too. -- John From lrpalmer at gmail.com Fri Mar 28 11:09:26 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Fri Mar 28 11:05:56 2008 Subject: [Haskell-cafe] Glome raytracer bug: bad output with -O2 -fasm In-Reply-To: <47EC901A.3050207@cs.pdx.edu> References: <47EC901A.3050207@cs.pdx.edu> Message-ID: <7ca3f0160803280809x650e9275rceceb12fb8c69be7@mail.gmail.com> On Fri, Mar 28, 2008 at 6:28 AM, Jim Snow wrote: > I was trying to get Blinn highlights working with my raytracer, and kept > getting ugly artifacts. After trying a bunch of things, I finally > compiled without -O2, and the artifacts went away. > > Here's what I mean: > http://syn.cs.pdx.edu/~jsnow/glome/Glome.hs-noartifact.png > http://syn.cs.pdx.edu/~jsnow/glome/Glome.hs-artifact.png > > Here's the offending code, run "./make" and "./run" and you should see > the artifacts if your setup is the same as mine. (Requires OpenGL.) > http://syn.cs.pdx.edu/~jsnow/glome/glome.hs-0.2-bug.tar.gz > > The artifacts also go away if I use -fvia-C. It doesn't seem to matter > whether I use Floats or Doubles in the rendering code. The artifacts > also show up with -O1. Have I stumbled across a known compiler bug? Or > perhaps an OpenGL bug? (The bug could, of course, be in my code, but > then one might expect to get the same erroneous output every time > regardless of compiler flags.) > > To reiterate, I'm using ghc 8.6.2. You probably mean 6.8.2. Works for me in all cases. % uname -a Linux madhatter 2.6.22-gentoo-r8 #6 PREEMPT Sat Oct 20 04:19:22 GMT 2007 i686 AMD Turion(tm) 64 Mobile Technology ML-40 AuthenticAMD GNU/Linux % ghc --version The Glorious Glasgow Haskell Compilation System, version 6.8.2 Looks to me like Glome is depending on some very fine details of floating point arithmetic. Luke From s.clover at gmail.com Fri Mar 28 11:52:29 2008 From: s.clover at gmail.com (Sterling Clover) Date: Fri Mar 28 11:48:42 2008 Subject: [Haskell-cafe] Web server libraries In-Reply-To: <20080328143603.M94048-100000@a0.redline.ru> References: <56815270-E934-4C6D-97D1-549F799C2A5A@gmail.com> <20080328143603.M94048-100000@a0.redline.ru> Message-ID: Yipe. It's just been pointed out to me that the hvac repo was missing a key file. I just committed it and tried a fresh pull and build, and it seems to work properly now. Apologies to all who couldn't get it working. Regards, Sterl. On Fri, 28 Mar 2008, Sterling Clover wrote: > While hvac, which I announced here recently, is not yet ready for > primetime, so to speak, you may want to take a look at it -- with a > few tweaks it should match your specs. (darcs get http:// > community.haskell.org/~sclv/hvac/ ) > [...] -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080328/0e8c6005/attachment.htm From janeczek at gmail.com Fri Mar 28 12:38:56 2008 From: janeczek at gmail.com (=?UTF-8?Q?Micha=C5=82_Janeczek?=) Date: Fri Mar 28 12:35:15 2008 Subject: [Haskell-cafe] Re: SoC project: Python-Haskell bridge - request for feedback In-Reply-To: References: <561cb5bc0803241338x25170cffyda72b0d8446a3bb4@mail.gmail.com> <561cb5bc0803262200g72f64dcna878fd85bf8037da@mail.gmail.com> <47EBE52C.3060202@imageworks.com> Message-ID: <561cb5bc0803280938i44237b4bl25f02e233e48e7da@mail.gmail.com> On Thu, Mar 27, 2008 at 8:27 PM, John Goerzen wrote: > FWIW, my MissingPy project accomplishes part of this (calling Python > from Haskell) already. > > -- John Yes, MissingPy was mentioned in the original project description, and I have hopes of reusing substantial parts of it. I'd like to make it more comprehensive (in particular, have it support higher order functions when calling Python code), and possibly also easier/more transparent to use. And there of course comes the second side of the project, calling Haskell from Python Regards, Michal From mads_lindstroem at yahoo.dk Fri Mar 28 11:48:52 2008 From: mads_lindstroem at yahoo.dk (Mads =?ISO-8859-1?Q?Lindstr=F8m?=) Date: Fri Mar 28 14:17:46 2008 Subject: [Haskell-cafe] MonadMemory class In-Reply-To: <200803280002.39437.valgarv@gmx.net> References: <200803280002.39437.valgarv@gmx.net> Message-ID: <1206719332.4167.3.camel@localhost.localdomain> Hi Ariel J. Birnbaum wrote: > Two questions came to mind while thinking of memory references in Haskell: > > 1. Is there a "standard" equivalent of the following: > > class (Monad m) => MonadMemory m r | m -> r where > new :: a -> m (r a) > read :: r a -> m a > write :: r a -> a -> m () I do not think you can call it standard, but TypeCompose http://hackage.haskell.org/cgi-bin/hackage-scripts/package/TypeCompose-0.5 do implement Data.RefMonad, which does what you are describing. Greetings, Mads Lindstr?m > > What kind of axioms should an instance of this class satisfy? > > 2. How would a "pure" instance of this class look like (obvious > unsafePerformIO-based solutions aside)? Is it even possible in pure Haskell? > > Thanks much! From jason.dusek at gmail.com Fri Mar 28 14:33:52 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Fri Mar 28 14:37:30 2008 Subject: [Haskell-cafe] compilation succeeds -- execution fails In-Reply-To: <2008C6B0-7580-43B7-BF1F-7EC812DF02EE@googlemail.com> References: <42784f260803280234u7862f0f9xda69fee5df5bb613@mail.gmail.com> <2008C6B0-7580-43B7-BF1F-7EC812DF02EE@googlemail.com> Message-ID: <42784f260803281133x6fdb33a2v7ea9cca59e0d8ae2@mail.gmail.com> Thomas Schilling wrote: > Did you try removing all .hi and .o files? Yes. I tried it again this morning, and I've got the same error -- same unknown symbol, &c. I don't have trouble with most Haskell programs on my Mac, so I assume it's the way I'm connecting to C that is the problem. I've pasted in the relevant code below my signature -- it seems plain enough to me, but I've not done much with foreign declarations. The `Ptr Char` declarations, for example, point to things which are actually C ints -- they are all valid Unicode code points, so I figure there's no harm done. -- _jsn module Data.Char.CEDICT.Lists where import Foreign import Foreign.C import Foreign.Storable import Foreign.Marshal.Array {-# INCLUDE "c/data.h" #-} foreign import ccall unsafe "&" ts :: Ptr Char foreign import ccall unsafe "&" ts_len :: Ptr Int forTradSimp = pairUp $ readIn ts_len ts foreign import ccall unsafe "&" st :: Ptr Char foreign import ccall unsafe "&" st_len :: Ptr Int forSimpTrad = pairUp $ readIn st_len st readIn lenPtr arrPtr = unsafePerformIO $ peekArray len arrPtr where len = unsafePerformIO $ peek lenPtr pairUp [] = [] pairUp [item] = [] pairUp (a:b:rest) = (a, b):(pairUp rest) forLookup = [ ("\64013",[("huo4","to vomit")]) , ("\64012",[("wu4","duplicate of Big Five A461")]) , ("\40868",[("xie2","to harmonize / to accord with / to agree")]) , ("\40866",[("he2","harmonious")]) ] From dons at galois.com Fri Mar 28 14:06:25 2008 From: dons at galois.com (Don Stewart) Date: Fri Mar 28 14:42:17 2008 Subject: [Haskell-cafe] [GSoC] Parallel Benchmarking and Profiling In-Reply-To: References: Message-ID: <20080328180625.GA32404@scytale.galois.com> etienne: > Hello, > > I am putting together a student proposal to participate in Google's > Summer of Code with one of the following project ideas. > > Parallel programming benchmarking and benchmark suite > - http://hackage.haskell.org/trac/summer-of-code/ticket/1544 > > Are there open source projects and real world applications that rely > on GHC's parrallel programming primitives and libraries? I have found There's many applications on hackage that depend on Control.Concurrent, forkIO, Channels, MVars and software transactional memory. Relatively few yet depend on `par` and lightweight parallelism. > many references to LOLITA, but it seems to be old and not available > online. The idea page suggests porting existing benchmark suites such > as PARSEC, but PARSEC is 5G of C code. Most of it seems to come from > existing applications already written in C. It might also be Yes, the benefit here would be to build up a set of haskell programs that do lean on the parallel libraries and primitives. Porting algorithms from the benchmark suite would be one useful way to do that. > interesting to automate the discovery of optimal strategies through > empirical data, and to modify the thresholds dynamically. See the recent paper by Satnam Singh and Tim Harris, http://research.microsoft.com/~satnams/fdp.pdf on feedback-directed implicit parallelism for Haskell. > Parallel profiling tools for GHC > - http://hackage.haskell.org/trac/summer-of-code/ticket/1559 > > Simon Marlow wrote on the idea page that Gransim was ported to a more > up-to-date GHC. The documentation available on the web seems to be for > GHC 0.29 but it describes many options for logging and visualising the > activity of threads and processors over time. Getting GHC to display > that information on the frontpanel would make a nice project. > > Do you have any comments or suggestions? > > Thank you, > > Etienne Laurin > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From bulat.ziganshin at gmail.com Fri Mar 28 15:05:03 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Fri Mar 28 15:02:35 2008 Subject: [Haskell-cafe] [gsoc] mingw64 ghc port Message-ID: <1549400385.20080328220503@gmail.com> Hello haskell-cafe, it's probably a bit too late, but i recalled that there is one project that will be very useful - it's porting ghc to mingw64 platform, allowing it to generate 64-bit windows platforms. may be someone will find it interesting -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From ryani.spam at gmail.com Fri Mar 28 15:07:55 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Fri Mar 28 15:04:10 2008 Subject: [Haskell-cafe] Sound typeable via type families? In-Reply-To: <200803280021.12039.dan.doel@gmail.com> References: <200803280021.12039.dan.doel@gmail.com> Message-ID: <2f9b2d30803281207s7c9e919bx3ef96acc25deb92a@mail.gmail.com> On 3/27/08, Dan Doel wrote: > class Typeable t where > data TypeRep t :: * > typeRep :: TypeRep t This is a really interesting idea. Sadly, I can't think of a way to make it work. The biggest problem is the TEquality class; by putting teq in a typeclass, the decision of which teq to call (and thus, whether or not to return Just Refl or Nothing) is made at compile time. The GADT solution puts that decision off until run-time; the case statement in teq allows a decision to be made at that point. What we'd really like to do is something like the following: class Typeable t where data TypeRep t :: * typeRep :: TypeRep t typeEq :: forall t2. TypeRep t2 -> Maybe (TEq t t2) instance Typeable Int where data TypeRep Int = TInt typeRep = TInt typeEq rep = case rep of TInt -> Just Refl _ -> Nothing But you can't case analyze t2 in this way; each TypeRep is an independent data type and there's no way to determine which one you have (aside from some sort of typeable/dynamic constraint, and then we have a circular problem!) Perhaps there is a solution, but I'm not clever enough to find it. -- ryan From jason.dusek at gmail.com Fri Mar 28 17:01:49 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Fri Mar 28 16:58:05 2008 Subject: What Does This Message Mean? (Re: [Haskell-cafe] compilation succeeds -- execution fails) Message-ID: <42784f260803281401j710830edl11754cd9648206ea@mail.gmail.com> The message unknown symbol `___stginit_cedictzm0zi1zi1_DataziCharziCEDICTziMatter_' says that it can't find the initializer for` Data.Char.CEDICT.Matter` in `cedict-0.1.1` (this is 'z-encoding', if I remember correctly). So, the odd thing is, that is not the part with the C FFI stuff in it -- that's in `Data.Char.CEDICT.Lists`. Is there a usual thing that is wrong when the initializer can not be found? -- _jsn From dons at galois.com Fri Mar 28 17:08:09 2008 From: dons at galois.com (Don Stewart) Date: Fri Mar 28 17:04:24 2008 Subject: What Does This Message Mean? (Re: [Haskell-cafe] compilation succeeds -- execution fails) In-Reply-To: <42784f260803281401j710830edl11754cd9648206ea@mail.gmail.com> References: <42784f260803281401j710830edl11754cd9648206ea@mail.gmail.com> Message-ID: <20080328210809.GK32404@scytale.galois.com> jason.dusek: > The message > > unknown symbol `___stginit_cedictzm0zi1zi1_DataziCharziCEDICTziMatter_' > > says that it can't find the initializer for` > Data.Char.CEDICT.Matter` in `cedict-0.1.1` (this is > 'z-encoding', if I remember correctly). So, the odd thing is, > that is not the part with the C FFI stuff in it -- that's in > `Data.Char.CEDICT.Lists`. Is there a usual thing that is wrong > when the initializer can not be found? > Missing --make or possibly missing linking against C libs. From pkeir at dcs.gla.ac.uk Fri Mar 28 17:21:21 2008 From: pkeir at dcs.gla.ac.uk (Paul Keir) Date: Fri Mar 28 17:17:36 2008 Subject: [Haskell-cafe] Parsec Expected Type References: <3CDFB8AFEA98E34CB599475AB11589C80CC9BF@EX2.ad.dcs.gla.ac.uk> <7ca3f0160803271726m21c444c5x7c417afd686eb9b6@mail.gmail.com> <3CDFB8AFEA98E34CB599475AB11589C80CC9C0@EX2.ad.dcs.gla.ac.uk> Message-ID: <3CDFB8AFEA98E34CB599475AB11589C80CC9C2@EX2.ad.dcs.gla.ac.uk> Could tester2 return "some kind of base type", which the two inherit from? I don't know. I'm really only presenting the ugly tester2 function because I'm looking for a Parsec-concordant solution to what appears a simple problem. What I'd like is to parse either the string "parameter", or the string ":". I'm using 'reserved' and 'symbol' because they seem to correspond well to the concepts in the language I'm parsing. I could try, tester3 = reserved "parameter" <|> do { symbol ":"; return () } but that's feels a bit contrived; or I could use 'reserved' twice. Perhaps I'd express my confusion better if I ask: Why are 'reserved' and 'symbol' different types? Paul (Haskell Novice) -----Original Message----- From: Jonathan Cast [mailto:jonathanccast@fastmail.fm] Sent: Fri 3/28/2008 2:05 PM To: Paul Keir Cc: Luke Palmer; haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] Parsec Expected Type On 28 Mar 2008, at 2:02 AM, Paul Keir wrote: > Thanks, I'd thought it was something to do with incompatible types. > I can now create a simpler problem: > > tester2 = reserved "parameter" <|> symbol ":" > > Certainly I could use reserved ":" instead of symbol, but where is > my thinking with symbol here going wrong? Surely the above example > isn't so odd? > What type do you expect tester2 to return? jcc -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080328/b7615f6f/attachment.htm From dan.doel at gmail.com Fri Mar 28 17:22:07 2008 From: dan.doel at gmail.com (Dan Doel) Date: Fri Mar 28 17:18:25 2008 Subject: [Haskell-cafe] Sound typeable via type families? In-Reply-To: <2f9b2d30803281207s7c9e919bx3ef96acc25deb92a@mail.gmail.com> References: <200803280021.12039.dan.doel@gmail.com> <2f9b2d30803281207s7c9e919bx3ef96acc25deb92a@mail.gmail.com> Message-ID: <200803281722.07933.dan.doel@gmail.com> On Friday 28 March 2008, Ryan Ingram wrote: > This is a really interesting idea. Sadly, I can't think of a way to > make it work. > > The biggest problem is the TEquality class; by putting teq in a > typeclass, the decision of which teq to call (and thus, whether or not > to return Just Refl or Nothing) is made at compile time. The GADT > solution puts that decision off until run-time; the case statement in > teq allows a decision to be made at that point. > > What we'd really like to do is something like the following: > > class Typeable t where > data TypeRep t :: * > typeRep :: TypeRep t > typeEq :: forall t2. TypeRep t2 -> Maybe (TEq t t2) > > instance Typeable Int where > data TypeRep Int = TInt > typeRep = TInt > typeEq rep = case rep of > TInt -> Just Refl > _ -> Nothing > > But you can't case analyze t2 in this way; each TypeRep is an > independent data type and there's no way to determine which one you > have (aside from some sort of typeable/dynamic constraint, and then we > have a circular problem!) > > Perhaps there is a solution, but I'm not clever enough to find it. Yes, I thought about it a while longer after sending my mail, and I can't see an immediate way of making things work. I imagine one would need some sort of open GADTs to do the job. Currently we have two things that look close; GADTs which can hold the necessary evidence, but are closed, and type families, which are open, but don't allow inspection of values to direct typing. I suppose I was initially fooled by doing things like: cast () :: Maybe () ==> Just () Which looks just like Data.Typeable. However, when one goes to write more generic functions: foo x = case cast x of Just i -> (show :: Int -> String) i Nothing -> "Whatever." The type of foo ends up as '(TEquality a Int) => a -> String', which makes it a bit more clear that we're dealing with compile-time phenomena. I'll probably think on it some more, but I'm not holding out much hope at this point. Thanks for your thoughts, though (and, to Wolfgang, for the pointer to the other discussion, although I don't know if that or any of the new type families stuff coming in 6.10 will be the solution). -- Dan From ganesh at earth.li Fri Mar 28 18:20:55 2008 From: ganesh at earth.li (Ganesh Sittampalam) Date: Fri Mar 28 18:17:07 2008 Subject: [Haskell-cafe] Monad instance for Data.Set, again In-Reply-To: <200803280106.00061.g9ks157k@acme.softbase.org> References: <200803280106.00061.g9ks157k@acme.softbase.org> Message-ID: On Fri, 28 Mar 2008, Wolfgang Jeltsch wrote: > But it is possible to give a construction of an Ord dictionary from an > AssociatedMonad dictionary. See the attached code. It works like a > charm. :-) This is really cool, and with much wider applicability than restricted monads; it gives us a general way to abstract over type class constraints. The NewMonad class is also very straightforward and I think will cause much fewer type-checking headaches and large type signatures than Oleg's solution. Ganesh From westondan at imageworks.com Fri Mar 28 19:08:30 2008 From: westondan at imageworks.com (Dan Weston) Date: Fri Mar 28 19:04:44 2008 Subject: [Haskell-cafe] Monad instance for Data.Set, again In-Reply-To: <200803280106.00061.g9ks157k@acme.softbase.org> References: <200803280106.00061.g9ks157k@acme.softbase.org> Message-ID: <47ED7A6E.7010805@imageworks.com> I'm having trouble embedding unconstrained monads into the NewMonad: > {-# LANGUAGE ...,UndecidableInstances #-} > > instance Monad m => Suitable m v where > data Constraints m v = NoConstraints > constraints _ = NoConstraints > > instance Monad m => NewMonad m where > newReturn = return > newBind x k = > let list2Constraints = constraints result > result = case list2Constraints of > NoConstraints -> (x >>= k) > in result SetMonad.hs:25:9: Conflicting family instance declarations: data instance Constraints Set val -- Defined at SetMonad.hs:25:9-19 data instance Constraints m v -- Defined at SetMonad.hs:47:9-19 Since Set is not an instance of Monad, there is no actual overlap between (Monad m => m) and Set, but it seems that Haskell has no way of knowing that. Is there some trick (e.g. newtype boxing/unboxing) to get all the unconstrained monads automatically instanced? Then the do notation could be presumably remapped to the new class structure. Dan Wolfgang Jeltsch wrote: > Am Montag, 24. M?rz 2008 20:47 schrieb Henning Thielemann: >> [?] > >> Here is another approach that looks tempting, but unfortunately does not >> work, and I wonder whether this can be made working. >> >> module RestrictedMonad where >> >> import Data.Set(Set) >> import qualified Data.Set as Set >> >> class AssociatedMonad m a where >> >> class RestrictedMonad m where >> return :: AssociatedMonad m a => a -> m a >> (>>=) :: (AssociatedMonad m a, AssociatedMonad m b) => >> m a -> (a -> m b) -> m b >> >> instance (Ord a) => AssociatedMonad Set a where >> >> instance RestrictedMonad Set where >> return = Set.singleton >> x >>= f = Set.unions (map f (Set.toList x)) > >> [?] > > The problem is that while an expression of type > > (AssociatedMonad Set a, AssociatedMonad Set b) => > Set a -> (a -> Set b) -> Set b > > has type > > (Ord a, Ord b) => Set a -> (a -> Set b) -> Set b, > > the opposite doesn?t hold. > > Your AssociatedMonad class doesn?t provide you any Ord dictionary which you > need in order to use the Set functions. The instance declaration > > instance (Ord a) => AssociatedMonad Set a > > says how to construct an AssociatedMonad dictionary from an Ord dictionary but > not the other way round. > > But it is possible to give a construction of an Ord dictionary from an > AssociatedMonad dictionary. See the attached code. It works like a > charm. :-) > > Best wishes, > Wolfgang > > > ------------------------------------------------------------------------ > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From jsnow at cs.pdx.edu Fri Mar 28 20:41:15 2008 From: jsnow at cs.pdx.edu (Jim Snow) Date: Fri Mar 28 20:35:58 2008 Subject: [Haskell-cafe] Glome raytracer bug: bad output with -O2 -fasm In-Reply-To: <7ca3f0160803280809x650e9275rceceb12fb8c69be7@mail.gmail.com> References: <47EC901A.3050207@cs.pdx.edu> <7ca3f0160803280809x650e9275rceceb12fb8c69be7@mail.gmail.com> Message-ID: <47ED902B.9060406@cs.pdx.edu> Luke Palmer wrote: > On Fri, Mar 28, 2008 at 6:28 AM, Jim Snow wrote: > >> I was trying to get Blinn highlights working with my raytracer, and kept >> getting ugly artifacts. After trying a bunch of things, I finally >> compiled without -O2, and the artifacts went away. >> >> Here's what I mean: >> http://syn.cs.pdx.edu/~jsnow/glome/Glome.hs-noartifact.png >> http://syn.cs.pdx.edu/~jsnow/glome/Glome.hs-artifact.png >> >> Here's the offending code, run "./make" and "./run" and you should see >> the artifacts if your setup is the same as mine. (Requires OpenGL.) >> http://syn.cs.pdx.edu/~jsnow/glome/glome.hs-0.2-bug.tar.gz >> >> The artifacts also go away if I use -fvia-C. It doesn't seem to matter >> whether I use Floats or Doubles in the rendering code. The artifacts >> also show up with -O1. Have I stumbled across a known compiler bug? Or >> perhaps an OpenGL bug? (The bug could, of course, be in my code, but >> then one might expect to get the same erroneous output every time >> regardless of compiler flags.) >> >> To reiterate, I'm using ghc 8.6.2. >> > > You probably mean 6.8.2. > > Yes, my mistake. 6.8.2. > Works for me in all cases. > > % uname -a > Linux madhatter 2.6.22-gentoo-r8 #6 PREEMPT Sat Oct 20 04:19:22 GMT > 2007 i686 AMD Turion(tm) 64 Mobile Technology ML-40 AuthenticAMD > GNU/Linux > % ghc --version > The Glorious Glasgow Haskell Compilation System, version 6.8.2 > > Looks to me like Glome is depending on some very fine details of > floating point arithmetic. > > Luke > After looking into this for awhile, I found that the problem was that in computing my Blinn factor: blinn = fmax 0 $ (vdot halfangle n) ** shine the (vdot halfangle n) was sometimes negative, resulting in blinn being "NaN". OpenGL apparently interprets "NaN" as "1.0" for the purposes of color*, so those patches were rendered bright white. It's still a bit mysterious why the case where (vdot halfangle n) is negative only occurs if I compile with "-fasm", but I can work around it for now. -jim * I'm using the binary-only nvidia drivers; different OpenGL implementations may behave differently. From ryani.spam at gmail.com Fri Mar 28 21:12:25 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Fri Mar 28 21:08:38 2008 Subject: [Haskell-cafe] Parsec Expected Type In-Reply-To: <3CDFB8AFEA98E34CB599475AB11589C80CC9C2@EX2.ad.dcs.gla.ac.uk> References: <3CDFB8AFEA98E34CB599475AB11589C80CC9BF@EX2.ad.dcs.gla.ac.uk> <7ca3f0160803271726m21c444c5x7c417afd686eb9b6@mail.gmail.com> <3CDFB8AFEA98E34CB599475AB11589C80CC9C0@EX2.ad.dcs.gla.ac.uk> <3CDFB8AFEA98E34CB599475AB11589C80CC9C2@EX2.ad.dcs.gla.ac.uk> Message-ID: <2f9b2d30803281812q40e393b8uabb096b2af581b44@mail.gmail.com> On 3/28/08, Paul Keir wrote: > What I'd like is to parse either the string "parameter", or the string ":". > I'm using 'reserved' and 'symbol' because they seem to correspond well to > the concepts in the language I'm parsing. I could try, > > tester3 = reserved "parameter" <|> do { symbol ":"; return () } Actually this is exactly on the right track. But I agree, it looks a bit contrived. Maybe this looks better to you? > tester3 = reserved "parameter" <|> (symbol ":" >> return ()) Or you could factor this behavior out into a new combinator: > or_ :: Parser a -> Parser b -> Parser () > or_ x y = (x >> return ()) <|> (y >> return ()) > tester3 = reserved "parameter" `or_` symbol ":" -- ryan From ryani.spam at gmail.com Fri Mar 28 21:19:49 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Fri Mar 28 21:16:03 2008 Subject: [Haskell-cafe] Monad instance for Data.Set, again In-Reply-To: <47ED7A6E.7010805@imageworks.com> References: <200803280106.00061.g9ks157k@acme.softbase.org> <47ED7A6E.7010805@imageworks.com> Message-ID: <2f9b2d30803281819r57ab25c0j8e4ec71de7113875@mail.gmail.com> On 3/28/08, Dan Weston wrote: > I'm having trouble embedding unconstrained monads into the NewMonad: > Is there some trick (e.g. newtype boxing/unboxing) to get all the > unconstrained monads automatically instanced? Then the do notation could > be presumably remapped to the new class structure. The usual trick here is to use newtypes. (Yes, it sucks) > newtype OldMonad m = OldMonad m > unwrapMonad :: OldMonad m -> m > unwrapMonad (OldMonad m) = m > instance Monad m => Suitable (OldMonad m) v where > data Constraints (OldMonad m) v = NoConstraints > constraints _ = NoConstraints > instance Monad m => NewMonad (OldMonad m) where > newReturn = OldMonad . return > newBind x k = OldMonad $ unwrapMonad x >>= unwrapMonad . k From allbery at ece.cmu.edu Fri Mar 28 21:41:46 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Fri Mar 28 21:38:00 2008 Subject: [Haskell-cafe] Parsec Expected Type In-Reply-To: <2f9b2d30803281812q40e393b8uabb096b2af581b44@mail.gmail.com> References: <3CDFB8AFEA98E34CB599475AB11589C80CC9BF@EX2.ad.dcs.gla.ac.uk> <7ca3f0160803271726m21c444c5x7c417afd686eb9b6@mail.gmail.com> <3CDFB8AFEA98E34CB599475AB11589C80CC9C0@EX2.ad.dcs.gla.ac.uk> <3CDFB8AFEA98E34CB599475AB11589C80CC9C2@EX2.ad.dcs.gla.ac.uk> <2f9b2d30803281812q40e393b8uabb096b2af581b44@mail.gmail.com> Message-ID: <4159B665-02FD-45E7-ACF7-57941F99EE28@ece.cmu.edu> On Mar 28, 2008, at 21:12 , Ryan Ingram wrote: > On 3/28/08, Paul Keir wrote: >> What I'd like is to parse either the string "parameter", or the >> string ":". >> I'm using 'reserved' and 'symbol' because they seem to correspond >> well to >> the concepts in the language I'm parsing. I could try, >> >> tester3 = reserved "parameter" <|> do { symbol ":"; return () } > > Or you could factor this behavior out into a new combinator: > >> or_ :: Parser a -> Parser b -> Parser () >> or_ x y = (x >> return ()) <|> (y >> return ()) > >> tester3 = reserved "parameter" `or_` symbol ":" Or if you'd like to be inscrutable: import Data.Function or_ = (>> return ()) `on` (<|>) -- 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 bertram.felgenhauer at googlemail.com Sat Mar 29 04:29:52 2008 From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer) Date: Sat Mar 29 04:26:11 2008 Subject: [Haskell-cafe] compilation succeeds -- execution fails In-Reply-To: <42784f260803280234u7862f0f9xda69fee5df5bb613@mail.gmail.com> References: <42784f260803280234u7862f0f9xda69fee5df5bb613@mail.gmail.com> Message-ID: <20080329082952.GA4372@zombie.inf.tu-dresden.de> Jason Dusek wrote: > I have a program here: > > https://svn.j-s-n.org/public/haskell/cedict > > currently at revision 302, which compiles okay but I can't get > it to work. I'm using the FFI to take a (currently small) > array and translate it into a Map. > > It compiles fine and loads fine -- but it doesn't run fine: > > GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help > Loading package base ... linking ... done. > Prelude> import Data.Char.CEDICT > Prelude Data.Char.CEDICT> traditional 'a' > Loading package array-0.1.0.0 ... linking ... done. > Loading package containers-0.1.0.1 ... linking ... done. > Loading package parsec-2.1.0.0 ... linking ... done. > Loading package utf8-string-0.2 ... linking ... done. > Loading package cedict-0.1.1 ... linking ... : > unknown symbol `___stginit_cedictzm0zi1zi1_DataziCharziCEDICTziMatter_' This is a cabal pitfall. Note that this is a symbol from Data.Char.CEDICT.Matter. (The 'zi' represents a dot) The problem is that this module wasn't packaged up in the library; you have to list it in the extra-modules field in the cabal file, along with the other used Data.Char.CEDICT.* modules. See also http://hackage.haskell.org/trac/hackage/ticket/128 HTH, Bertram From dominic.steinitz at blueyonder.co.uk Sat Mar 29 04:56:56 2008 From: dominic.steinitz at blueyonder.co.uk (Dominic Steinitz) Date: Sat Mar 29 04:53:25 2008 Subject: [Haskell-cafe] Re: Haddock Help Required References: <47E7D75C.8010406@blueyonder.co.uk> Message-ID: David Waern gmail.com> writes: > > 2008/3/24, Dominic Steinitz blueyonder.co.uk>: > > What should I be using for the file name for the read-interface option > > in haddock? > > You must use a file that is on your own hard drive and that is > generated with version 2.0 of Haddock, since that is what you're > using. The interface file format was changed in Haddock 2.0 due its > use of GHC data types, so you can't use 0.x interface files. > > You need to generate base.haddock with Haddock 2.0. One way to do > that, is to make sure Haddock 2.0 is installed, then get the GHC 6.8.2 > sources (with core libs) and build that with Haddock docs enabled. > > Hope this helps, > David > Thanks I've done this dom@lagrange:~/asn15/asn1> haddock -v -html -o hdoc Pretty.hs -B /usr/lib/ghc-6.8.2 --optghc="-fglasgow-exts" --read-interface=http://www.haskell.org/ghc/docs/6.8.2/html/libraries/base,/home/dom/ghc-6.8.2/libraries/base/dist/doc/html/base/base.haddock but now when I click on e.g. Integer I get directed to http://www.haskell.org/ghc/docs/6.8.2/html/libraries/base/GHC-Num.html#t%3AInteger which doesn't exist. Integer actually exists in http://www.haskell.org/ghc/docs/6.8.2/html/libraries/base/Prelude.html#t%3AInteger What do I need to do to get haddock to point at the right links? Dominic. From pkeir at dcs.gla.ac.uk Sat Mar 29 09:53:08 2008 From: pkeir at dcs.gla.ac.uk (Paul Keir) Date: Sat Mar 29 09:50:25 2008 Subject: [Haskell-cafe] Parsec Expected Type References: <3CDFB8AFEA98E34CB599475AB11589C80CC9BF@EX2.ad.dcs.gla.ac.uk> <7ca3f0160803271726m21c444c5x7c417afd686eb9b6@mail.gmail.com> <3CDFB8AFEA98E34CB599475AB11589C80CC9C0@EX2.ad.dcs.gla.ac.uk> <3CDFB8AFEA98E34CB599475AB11589C80CC9C2@EX2.ad.dcs.gla.ac.uk> <2f9b2d30803281812q40e393b8uabb096b2af581b44@mail.gmail.com> <4159B665-02FD-45E7-ACF7-57941F99EE28@ece.cmu.edu> Message-ID: <3CDFB8AFEA98E34CB599475AB11589C80CC9C3@EX2.ad.dcs.gla.ac.uk> Many thanks guys, you've really taught me how to catch a fish here! Paul -----Original Message----- From: Brandon S. Allbery KF8NH [mailto:allbery@ece.cmu.edu] Sent: Sat 3/29/2008 1:41 AM To: haskell-cafe@haskell.org Cafe Cc: Paul Keir Subject: Re: [Haskell-cafe] Parsec Expected Type On Mar 28, 2008, at 21:12 , Ryan Ingram wrote: > On 3/28/08, Paul Keir wrote: >> What I'd like is to parse either the string "parameter", or the >> string ":". >> I'm using 'reserved' and 'symbol' because they seem to correspond >> well to >> the concepts in the language I'm parsing. I could try, >> >> tester3 = reserved "parameter" <|> do { symbol ":"; return () } > > Or you could factor this behavior out into a new combinator: > >> or_ :: Parser a -> Parser b -> Parser () >> or_ x y = (x >> return ()) <|> (y >> return ()) > >> tester3 = reserved "parameter" `or_` symbol ":" Or if you'd like to be inscrutable: import Data.Function or_ = (>> return ()) `on` (<|>) -- 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/20080329/e17c5212/attachment.htm From chaddai.fouche at gmail.com Sat Mar 29 10:10:37 2008 From: chaddai.fouche at gmail.com (=?ISO-8859-1?Q?Chadda=EF_Fouch=E9?=) Date: Sat Mar 29 10:06:49 2008 Subject: [Haskell-cafe] [GSoC] Porting HaRe to use the GHC API Message-ID: For those unfamiliar with it, HaRe[1] is a refactoring tool in Haskell for Haskell. It already supports a wide range of useful refactoring and have Emacs and Vim bindings. Unfortunately, HaRe currently uses the Programmatica front-end to do his parsing, and Programmatica only knows Haskell 98, which make the tool far less useful for those that use GHC extensions in their programs. Moreover, Haskell' is bound to arrive one day and will encompass some of those extensions. My proposal for the SoC is to port HaRe (its parsing and refactoring) to use the GHC API instead of Programmatica. The advantages are : * GHC API already supports (by definition) all the GHC extensions, HaRe could be used for any Haskell program. * GHC development is unlikely to stop in the foreseeable future, thus HaRe could evolve with the language rather than having to catch up from time to time. * A certain number of refactoring can be added that exploit the GHC extensions * The GHC API is becoming a mature and generally useful tool, having more libraries that use it can't hurt its growth There already has been some works done to port HaRe to the GHC API in 2005 that did not run to completion but the API has evolved for the better since then and using this report [2] and the current API, I hope to complete the port during the summer. I'm familiarizing myself with the GHC API, Programmatica, Strafunski and HaRe and I'll do an internship at the university of Kent for three months in the summer, which should place me in the best situation to do this work. Refactoring is an important feature of the modern IDE, often quoted by the newcomers who search for the best environment to develop in Haskell. HaRe addresses this point but isn't usable for most programs actually written, which is really a shame (consult the list of supported and future refactoring [3] to get a taste of what you're missing...). Comments, reactions ? You can also propose refactoring, if I complete the port early, I'll try to add some refactoring to HaRe. [1] http://www.cs.kent.ac.uk/projects/refactor-fp/hare.html [2] http://www.cs.kent.ac.uk/pubs/2005/2266/ [3] http://www.cs.kent.ac.uk/projects/refactor-fp/catalogue/ -- Chadda? Fouch?, student in M1, majoring in CS, Ecole Normale Sup?rieure in Lyon. From stefanor at cox.net Sat Mar 29 12:41:58 2008 From: stefanor at cox.net (Stefan O'Rear) Date: Sat Mar 29 12:38:12 2008 Subject: [Haskell-cafe] compilation succeeds -- execution fails In-Reply-To: <42784f260803281133x6fdb33a2v7ea9cca59e0d8ae2@mail.gmail.com> References: <42784f260803280234u7862f0f9xda69fee5df5bb613@mail.gmail.com> <2008C6B0-7580-43B7-BF1F-7EC812DF02EE@googlemail.com> <42784f260803281133x6fdb33a2v7ea9cca59e0d8ae2@mail.gmail.com> Message-ID: <20080329164157.GA3055@localhost.localdomain> On Fri, Mar 28, 2008 at 11:33:52AM -0700, Jason Dusek wrote: > Thomas Schilling wrote: > > Did you try removing all .hi and .o files? > > Yes. I tried it again this morning, and I've got the same > error -- same unknown symbol, &c. > > I don't have trouble with most Haskell programs on my Mac, so > I assume it's the way I'm connecting to C that is the problem. > I've pasted in the relevant code below my signature -- it > seems plain enough to me, but I've not done much with foreign > declarations. > > The `Ptr Char` declarations, for example, point to things > which are actually C ints -- they are all valid Unicode code > points, so I figure there's no harm done. The only type that you are allowed to assume corresponds to a C int is CInt, in the Foreign.C.Types module. This probably isn't the problem, but it could make problems of its own on a 64-bit or otherwise weird system. Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080329/90a2ffe7/attachment.bin From agl at imperialviolet.org Sat Mar 29 13:02:04 2008 From: agl at imperialviolet.org (Adam Langley) Date: Sat Mar 29 12:58:16 2008 Subject: [Haskell-cafe] Re: HTTP client libraries In-Reply-To: References: <396556a20803271627s2da60f7nc255b8c05dc20c8f@mail.gmail.com> Message-ID: <396556a20803291002i425f20cbyab6abe99fe3c899f@mail.gmail.com> On Fri, Mar 28, 2008 at 6:40 AM, John Goerzen wrote: > Your Source type is an interesting approach, too. I'm still not sure if it's actually a good idea. But if you do have any requests, I'm very open to them. I think that a fetchBasic which walks redirects would be a good start but, other than that, I'm rather distracted with elliptic curve groups at the moment. AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org From dons at galois.com Sat Mar 29 18:38:34 2008 From: dons at galois.com (Don Stewart) Date: Sat Mar 29 18:34:46 2008 Subject: [Haskell-cafe] ANNOUNCE: xmonad 0.7 released Message-ID: <20080329223834.GD22951@scytale.galois.com> http://xmonad.org The xmonad dev team is pleased to announce xmonad 0.7! The headlines: The 0.7 release of xmonad provides several improvements over 0.6, including improved integration with GNOME, more flexible "rules", various stability fixes, and of course, many new and interesting features in the extension library (general support for window decorations, utf8 support, scratch pad terminals, pointer control) and more! New GNOME support: Active, automated support for GNOME utilities. We know our users often like to use GNOME menus, tools and status bars, and we'd like to announce that xmonad actively supports GNOME! Extensions for communicating with and utilising gnome utilities come in the library suite, as well as extensive documentation and support. For more information see the GNOME/xmonad integration page on the wiki. A period of active development: In the past year, the xmonad development team received contributions from over 60 developers, making xmonad one of the largest window manager development teams around, and dwarfing other tiling window manager projects. Yet, at the same time, the core code base remains at around 1000 lines of code, with another 7000 lines in the extension library -- a significant achievment! Change logs: http://haskell.org/haskellwiki/Xmonad/Notable_changes_since_0.6 http://xmonad.org/changelog-0.7.txt http://xmonad.org/changelog-xmc-0.7.txt About: xmonad is a tiling window manager for X. Windows are arranged automatically to tile the screen without gaps or overlap, maximising screen use. Window manager features are accessible from the keyboard: a mouse is optional. xmonad is extensible in Haskell, allowing for powerful customisation. Custom layout algorithms, key bindings and other extensions may be written by the user in config files. Layouts are applied dynamically, and different layouts may be used on each workspace. Xinerama is fully supported, allowing windows to be tiled on several physical screens. Features: * Very stable, fast, small and simple. * Automatic window tiling and management * First class keyboard support: a mouse is unnecessary * Full support for tiling windows on multi-head displays * Full support for floating, tabbing and decorated windows * Full support for Gnome and KDE utilities * XRandR support to rotate, add or remove monitors * Per-workspace layout algorithms * Per-screens custom status bars * Compositing support * Powerful, stable customisation and reconfiguration * Large extension library * Excellent, extensive documentation * Large, active development team, support and community Get it! Information, screenshots, documentation, tutorials and community resources are available from the xmonad home page: http://xmonad.org The 0.7 release, and its dependencies, are available from hackage.haskell.org: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/xmonad xmonad packages are available in the package systems of at least: Debian, Gentoo, Arch, Ubuntu, OpenBSD, NetBSD, FreeBSD, Gobo, NixOS, Source Mage, Slackware and 0.7 packages will appear in coming days (some are already available). On the fly updating to xmonad 0.7 is supported. You should be able to upgrade to xmonad 0.7 from 0.6 and earlier, transparently, without losing your session. Load the new code with mod-q and enjoy. Extensions: xmonad comes with a huge library of extensions (now more than 7 times the size of xmonad itself), contributed by viewers like you. Extensions enable pretty much arbitrary window manager behaviour to be implemented by users, in Haskell, in the config files. For more information on using and writing extensions see the webpage. The library of extensions is available from hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/xmonad-contrib Full documentation for using and writing your own extensions: http://xmonad.org/contrib.html This release brought to you by the xmonad dev team: Spencer Janssen Don Stewart Jason Creighton David Roundy Brent Yorgey Devin Mullins Braden Shepherdson Roman Cheplyaka Lucas Mai Featuring code contributions from over 60 developers: Aaron Denney Adam Vogt Alec Berryman Alex Tarkovsky Alexandre Buisse Andrea Rossato Austin Seipp Bas van Dijk Ben Voui Brandon Allbery Chris Mears Christian Thiemann Clemens Fruhwirth Daniel Neri Daniel Wagner Dave Harrison David Glasser David Lazar Dmitry Kurochkin Dominik Bruhn Dougal Stanton Eric Mertens Ferenc Wagner Gwern Branwen Hans Philipp Annen Ivan Tarasov Jamie Webb Jeremy Apthorp Joachim Breitner Joachim Fasting Joe Thornber Joel Suovaniemi Juraj Hercek Justin Bogner Kai Grossjohann Karsten Schoelzel Klaus Weidner Mathias Stearn Mats Jansborg Matsuyama Tomohiro Michael Fellinger Michael Sloan Miikka Koskinen Neil Mitchell Nelson Elhage Nick Burlett Nicolas Pouillard Nils Anders Danielsson Peter De Wachter Robert Marlow Sam Hughes Shachaf Ben-Kiki Shae Erisson Simon Peyton Jones Stefan O'Rear Tom Rauchenwald Valery V. Vorotyntsev Will Farrington Yaakov Nemoy timthelion As well as the support of many others on the #xmonad and #haskell IRC channels, and the wider Haskell and window manager communities. Thanks to everyone for their support! From chak at cse.unsw.edu.au Sat Mar 29 23:54:01 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Sat Mar 29 23:52:39 2008 Subject: [Haskell-cafe] Equality constraints in type families In-Reply-To: <7b92c2840803271711y13a7366aj9976d87489dbf34e@mail.gmail.com> References: <7b92c2840803101651x3673691eid310ab137805eeff@mail.gmail.com> <004d01c88da5$f744a350$ee3d8351@cr3lt> <006e01c88e67$f6afef40$321e7ad5@cr3lt> <638ABD0A29C8884A91BC5FB5C349B1C32AB9E0C8B1@EA-EXMSG-C334.europe.corp.microsoft.com> <41687A81-42E7-4306-BFAA-5D816E1689E1@cse.unsw.edu.au> <7b92c2840803270945l7ea4aec7id0489e18a981c392@mail.gmail.com> <7b92c2840803270946g7cb69fe6ue72f1e08e10a9efc@mail.gmail.com> <655A80F9-8FAA-46BD-B107-B8C66CFAE03A@cse.unsw.edu.au> <7b92c2840803271711y13a7366aj9976d87489dbf34e@mail.gmail.com> Message-ID: Hugo Pacheco: > Yes, but doesn't the confluence problem only occur for type synonyms > that ignore one or more of the parameters? If so, this could be > checked... You can't check this easily (for the general case). Given type family G a b type FList a x = G a x type instance F [a] = FList a Does FList ignore its second argument? Depends on the type instances of G. Manuel > > > On Fri, Mar 28, 2008 at 12:04 AM, Manuel M T Chakravarty > wrote: > Hugo Pacheco: > > Sorry, I meant > > > > type FList a x = Either One (a,x) > > type instance F [a] = FList a > > We should not allow such programs. > > Manuel > > > > > > > On Thu, Mar 27, 2008 at 4:45 PM, Hugo Pacheco > > wrote: > > > > > > The current implementation is wrong, as it permits > > > > type S a b = a > > type family F a :: * -> * > > type instance F a = S a > > > > Why do we need to forbid this type instance? Because it breaks the > > confluence of equality constraint normalisation. Here are two > > diverging normalisations: > > > > (1) > > > > F Int Bool ~ F Int Char > > > > ==> DECOMP > > > > F Int ~ F Int, Bool ~ Char > > > > ==> FAIL > > > > > > (2) > > > > F Int Bool ~ F Int Char > > > > ==> TOP > > > > S Int Bool ~ S Int Char > > > > ==> (expand type synonym) > > > > Int ~ Int > > > > ==> TRIVIAL > > > > This does mean that a program such as > > > > type FList a = Either One ((,) a) > > type instance F [a] = FList a > > > > will be disallowed in further versions? > > Doesn't this problem occur only for type synonyms that ignore one or > > more of the parameters? If so, this could be checked... > > > > hugo > > > > > > From hpacheco at gmail.com Sun Mar 30 00:14:08 2008 From: hpacheco at gmail.com (Hugo Pacheco) Date: Sun Mar 30 00:10:28 2008 Subject: [Haskell-cafe] Equality constraints in type families In-Reply-To: References: <7b92c2840803101651x3673691eid310ab137805eeff@mail.gmail.com> <006e01c88e67$f6afef40$321e7ad5@cr3lt> <638ABD0A29C8884A91BC5FB5C349B1C32AB9E0C8B1@EA-EXMSG-C334.europe.corp.microsoft.com> <41687A81-42E7-4306-BFAA-5D816E1689E1@cse.unsw.edu.au> <7b92c2840803270945l7ea4aec7id0489e18a981c392@mail.gmail.com> <7b92c2840803270946g7cb69fe6ue72f1e08e10a9efc@mail.gmail.com> <655A80F9-8FAA-46BD-B107-B8C66CFAE03A@cse.unsw.edu.au> <7b92c2840803271711y13a7366aj9976d87489dbf34e@mail.gmail.com> Message-ID: <7b92c2840803292114t69f0111av64b869793e6bf710@mail.gmail.com> On Sun, Mar 30, 2008 at 3:54 AM, Manuel M T Chakravarty < chak@cse.unsw.edu.au> wrote: > Hugo Pacheco: > > Yes, but doesn't the confluence problem only occur for type synonyms > > that ignore one or more of the parameters? If so, this could be > > checked... > > You can't check this easily (for the general case). > I was most interested in knowing that this assumption was enough, and it looks like it does. > > Given > > type family G a b > type FList a x = G a x > type instance F [a] = FList a > > Does FList ignore its second argument? Depends on the type instances > of G. > > Manuel > I haven't thought of that, thanks for the example. hugo -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080330/da8f9892/attachment.htm From hpacheco at gmail.com Sun Mar 30 00:28:02 2008 From: hpacheco at gmail.com (Hugo Pacheco) Date: Sun Mar 30 00:24:37 2008 Subject: [Haskell-cafe] Equality constraints in type families In-Reply-To: <7b92c2840803292114t69f0111av64b869793e6bf710@mail.gmail.com> References: <7b92c2840803101651x3673691eid310ab137805eeff@mail.gmail.com> <006e01c88e67$f6afef40$321e7ad5@cr3lt> <638ABD0A29C8884A91BC5FB5C349B1C32AB9E0C8B1@EA-EXMSG-C334.europe.corp.microsoft.com> <41687A81-42E7-4306-BFAA-5D816E1689E1@cse.unsw.edu.au> <7b92c2840803270945l7ea4aec7id0489e18a981c392@mail.gmail.com> <7b92c2840803270946g7cb69fe6ue72f1e08e10a9efc@mail.gmail.com> <655A80F9-8FAA-46BD-B107-B8C66CFAE03A@cse.unsw.edu.au> <7b92c2840803271711y13a7366aj9976d87489dbf34e@mail.gmail.com> <7b92c2840803292114t69f0111av64b869793e6bf710@mail.gmail.com> Message-ID: <7b92c2840803292128n4f9615e2i2f872fe84e356859@mail.gmail.com> Anyway, do you think it is feasible to have a flag such as -fallow-unsafe-type-families for users to use at their own risk? (supposing we know how to guarantee these constraints). I speak for my own, there are currently some nice thinks that I can only accomplish with partially applied type synonyms in type families, otherwise code starts to get dummier in terms of type contexts and context variables. Thanks, hugo On Sun, Mar 30, 2008 at 4:14 AM, Hugo Pacheco wrote: > On Sun, Mar 30, 2008 at 3:54 AM, Manuel M T Chakravarty < > chak@cse.unsw.edu.au> wrote: > > > Hugo Pacheco: > > > Yes, but doesn't the confluence problem only occur for type synonyms > > > that ignore one or more of the parameters? If so, this could be > > > checked... > > > > You can't check this easily (for the general case). > > > > I was most interested in knowing that this assumption was enough, and it > looks like it does. > > > > > > Given > > > > type family G a b > > type FList a x = G a x > > type instance F [a] = FList a > > > > Does FList ignore its second argument? Depends on the type instances > > of G. > > > > Manuel > > > > I haven't thought of that, thanks for the example. > > hugo > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080330/3c56f397/attachment.htm From jason.dusek at gmail.com Sun Mar 30 01:09:51 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Sun Mar 30 01:06:13 2008 Subject: [Haskell-cafe] compilation succeeds -- execution fails In-Reply-To: <20080329082952.GA4372@zombie.inf.tu-dresden.de> References: <42784f260803280234u7862f0f9xda69fee5df5bb613@mail.gmail.com> <20080329082952.GA4372@zombie.inf.tu-dresden.de> Message-ID: <42784f260803292209y466fb57dhe5a821b8d8996a0@mail.gmail.com> Bertram Felgenhauer wrote: > Jason Dusek wrote: > > It compiles fine and loads fine -- but it doesn't run fine: > > unknown symbol `___stginit_cedictzm0zi1zi1_DataziCharziCEDICTziMatter_' > > This is a cabal pitfall. Thank you -- this tip saved my bacon. -- _jsn From jason.dusek at gmail.com Sun Mar 30 01:21:32 2008 From: jason.dusek at gmail.com (Jason Dusek) Date: Sun Mar 30 01:17:42 2008 Subject: [Haskell-cafe] compilation succeeds -- execution fails In-Reply-To: <20080329164157.GA3055@localhost.localdomain> References: <42784f260803280234u7862f0f9xda69fee5df5bb613@mail.gmail.com> <2008C6B0-7580-43B7-BF1F-7EC812DF02EE@googlemail.com> <42784f260803281133x6fdb33a2v7ea9cca59e0d8ae2@mail.gmail.com> <20080329164157.GA3055@localhost.localdomain> Message-ID: <42784f260803292221x1120f342i9a36a4784a05f101@mail.gmail.com> Stefan O'Rear wrote: > The only type that you are allowed to assume corresponds to a C int is > CInt, in the Foreign.C.Types module. This probably isn't the problem, > but it could make problems of its own on a 64-bit or otherwise weird > system. So say I turn everything back to pointers to CInt, what is the accepted way to convert from CInt to Int and CInt to Char? Is relying on the fact that CInt always wraps a Haskell integer an okay way to go? I might was well learn these things now, before I get into bad habits. -- _jsn From martine at danga.com Sun Mar 30 01:37:29 2008 From: martine at danga.com (Evan Martin) Date: Sun Mar 30 01:34:07 2008 Subject: [Haskell-cafe] announce: hgdbmi (GDB/MI interface) Message-ID: <3a6f89fc0803292237y2eb97853q4d061f4993dd6c92@mail.gmail.com> Just in case someone else needed this, here you go: GDB/MI lets programs drive GDB. It can be used, for example, by GDB frontends. This module wraps attaching GDB to a process and parsing the (surprisingly complicated) GDB/MI output. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hgdbmi From stefanor at cox.net Sun Mar 30 02:00:30 2008 From: stefanor at cox.net (Stefan O'Rear) Date: Sun Mar 30 01:56:46 2008 Subject: [Haskell-cafe] compilation succeeds -- execution fails In-Reply-To: <42784f260803292221x1120f342i9a36a4784a05f101@mail.gmail.com> References: <42784f260803280234u7862f0f9xda69fee5df5bb613@mail.gmail.com> <2008C6B0-7580-43B7-BF1F-7EC812DF02EE@googlemail.com> <42784f260803281133x6fdb33a2v7ea9cca59e0d8ae2@mail.gmail.com> <20080329164157.GA3055@localhost.localdomain> <42784f260803292221x1120f342i9a36a4784a05f101@mail.gmail.com> Message-ID: <20080330060030.GA4260@localhost.localdomain> On Sat, Mar 29, 2008 at 10:21:32PM -0700, Jason Dusek wrote: > Stefan O'Rear wrote: > > The only type that you are allowed to assume corresponds to a C int is > > CInt, in the Foreign.C.Types module. This probably isn't the problem, > > but it could make problems of its own on a 64-bit or otherwise weird > > system. > > So say I turn everything back to pointers to CInt, what is the > accepted way to convert from CInt to Int Same as any other pair of whole-number types - fromIntegral. > and CInt to Char? fromIntegral and toEnum > Is relying on the fact that CInt always wraps a Haskell integer an > okay way to go? What do you mean by wraps? It's an opaque type... Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080329/b36fd454/attachment.bin From rendel at rbg.informatik.tu-darmstadt.de Sun Mar 30 07:29:35 2008 From: rendel at rbg.informatik.tu-darmstadt.de (Tillmann Rendel) Date: Sun Mar 30 07:26:32 2008 Subject: [Haskell-cafe] Parsec Expected Type In-Reply-To: <3CDFB8AFEA98E34CB599475AB11589C80CC9C2@EX2.ad.dcs.gla.ac.uk> References: <3CDFB8AFEA98E34CB599475AB11589C80CC9BF@EX2.ad.dcs.gla.ac.uk> <7ca3f0160803271726m21c444c5x7c417afd686eb9b6@mail.gmail.com> <3CDFB8AFEA98E34CB599475AB11589C80CC9C0@EX2.ad.dcs.gla.ac.uk> <3CDFB8AFEA98E34CB599475AB11589C80CC9C2@EX2.ad.dcs.gla.ac.uk> Message-ID: <20080330112935.GA31391@rbg.informatik.tu-darmstadt.de> Paul Keir wrote: > What I'd like is to parse either the string "parameter", or the > string ":". I'm using 'reserved' and 'symbol' because they seem to > correspond well to the concepts in the language I'm parsing. You may consider using reservedOp for ":", depending on how ":+" should be parsed: for ":+" use reservedOp for ":" "+" use symbol If you use reserved, then ":name" will be parsed as ":name" not ":" "name" as you probably expect. generally, reserved is for identifier-like keywords, and reservedOp for operator-like keywords. > Perhaps I'd express my confusion better if I ask: Why are 'reserved' > and 'symbol' different types? I have no idea. They aren't in the Parsec manual on Daans site: http://legacy.cs.uu.nl/daan/download/parsec/parsec.html You can fix this by defining reserved name = ParsecToken.reserved tokenParser name >> return name instead of reserved = ParsecToken.reserved tokenParser to "import" the reserved component from the tokenParser to the toplevel. Now, reserved :: String -> CharParser st String Another option is to fix it the other way, by defining symbol name = ParsecToken.symbol tokenParser name >> return () or to fix it in a ad-hoc manner, by defining ignored = (>> return ()) and using it in the approbiate places, like parameterOrColon = reserved "parameter" <|> ignored (symbol ":") Tillmann From jules at jellybean.co.uk Sun Mar 30 12:10:51 2008 From: jules at jellybean.co.uk (Jules Bean) Date: Sun Mar 30 12:06:57 2008 Subject: [Haskell-cafe] [GSoC] Porting HaRe to use the GHC API In-Reply-To: References: Message-ID: <47EFBB8B.7060205@jellybean.co.uk> Chadda? Fouch? wrote: > Comments, reactions ? You can also propose refactoring, if I complete > the port early, I'll try to add some refactoring to HaRe. Comment: Yes please!!!! From iavor.diatchki at gmail.com Sun Mar 30 13:54:10 2008 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Sun Mar 30 13:50:20 2008 Subject: [Haskell-cafe] Re: HTTP client libraries In-Reply-To: References: <4249453d0803271438v345912d9ndcf8f9c4c066dc07@mail.gmail.com> <20080328000218.GC18093@scytale.galois.com> Message-ID: <5ab17e790803301054p35d8fb20r9c9caae3db80375b@mail.gmail.com> Hi, On Fri, Mar 28, 2008 at 6:42 AM, John Goerzen wrote: > On 2008-03-28, Don Stewart wrote: > > paulrbrown+haskell-cafe: > > > And we have a curl binding, already in wide use. > > > > http://code.haskell.org/curl.git/ > > > > a release to hackage is imminent. > > Do you mean this? > > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/curl-1.3.1 > > Looks like it's not quite as current as your Git repo. Is this surprising? Hackage is not a revision control system. The curl package on hackage is a fairly recent version of the git repo. -Iavor From claudiusmaximus at goto10.org Sun Mar 30 14:22:01 2008 From: claudiusmaximus at goto10.org (Claude Heiland-Allen) Date: Sun Mar 30 14:15:02 2008 Subject: [Haskell-cafe] compilation succeeds -- execution fails In-Reply-To: <42784f260803292221x1120f342i9a36a4784a05f101@mail.gmail.com> References: <42784f260803280234u7862f0f9xda69fee5df5bb613@mail.gmail.com> <2008C6B0-7580-43B7-BF1F-7EC812DF02EE@googlemail.com> <42784f260803281133x6fdb33a2v7ea9cca59e0d8ae2@mail.gmail.com> <20080329164157.GA3055@localhost.localdomain> <42784f260803292221x1120f342i9a36a4784a05f101@mail.gmail.com> Message-ID: <47EFDA49.30709@goto10.org> Jason Dusek wrote: > Stefan O'Rear wrote: >> The only type that you are allowed to assume corresponds to a C int is >> CInt, in the Foreign.C.Types module. This probably isn't the problem, >> but it could make problems of its own on a 64-bit or otherwise weird >> system. > > So say I turn everything back to pointers to CInt, what is the > accepted way to convert from CInt to Int and CInt to Char? Type class methods: -- for numbers like Int, CInt fromIntegral :: (Num b, Integral a) => a -> b -- for Char fromEnum :: (Enum a) => a -> Int toEnum :: (Enum a) => Int -> a > Is > relying on the fact that CInt always wraps a Haskell integer > an okay way to go? I don't know what you mean by this. > I might was well learn these things now, > before I get into bad habits. Hope this helps, Claude -- http://claudiusmaximus.goto10.org From jonathanccast at fastmail.fm Sun Mar 30 14:18:59 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Sun Mar 30 14:15:13 2008 Subject: [Haskell-cafe] compilation succeeds -- execution fails In-Reply-To: <42784f260803292221x1120f342i9a36a4784a05f101@mail.gmail.com> References: <42784f260803280234u7862f0f9xda69fee5df5bb613@mail.gmail.com> <2008C6B0-7580-43B7-BF1F-7EC812DF02EE@googlemail.com> <42784f260803281133x6fdb33a2v7ea9cca59e0d8ae2@mail.gmail.com> <20080329164157.GA3055@localhost.localdomain> <42784f260803292221x1120f342i9a36a4784a05f101@mail.gmail.com> Message-ID: On 29 Mar 2008, at 10:21 PM, Jason Dusek wrote: > Stefan O'Rear wrote: >> The only type that you are allowed to assume corresponds to a C >> int is >> CInt, in the Foreign.C.Types module. This probably isn't the >> problem, >> but it could make problems of its own on a 64-bit or otherwise weird >> system. > > So say I turn everything back to pointers to CInt, what is the > accepted way to convert from CInt to Int Use fromIntegral to go CInt -> Int, Int -> CInt. This only depends on CInt being an Integral type. > and CInt to Char? Use toEnum . fromIntegral jcc From igloo at earth.li Sun Mar 30 14:55:37 2008 From: igloo at earth.li (Ian Lynagh) Date: Sun Mar 30 14:51:45 2008 Subject: [Haskell-cafe] announce: Glome.hs raytracer In-Reply-To: <20080327024935.GA29895@matrix.chaos.earth.li> References: <47EAC120.1050909@cs.pdx.edu> <20080327024935.GA29895@matrix.chaos.earth.li> Message-ID: <20080330185537.GA6607@matrix.chaos.earth.li> On Thu, Mar 27, 2008 at 02:49:35AM +0000, Ian Lynagh wrote: > On Wed, Mar 26, 2008 at 02:33:20PM -0700, Jim Snow wrote: > > > > -Memory consumption is atrocious: 146 megs to render a scene that's a > > 33k ascii file. Where does it all go? A heap profile reports the max > > heap size at a rather more reasonable 500k or so. (My architecture is > > 64 bit ubuntu on a dual-core amd.) > > I haven't looked properly yet, but it looks like something is leaking > memory that shouldn't be. Bug filed here: http://hackage.haskell.org/trac/ghc/ticket/2185 Thanks Ian From paul at cogito.org.uk Sun Mar 30 14:57:18 2008 From: paul at cogito.org.uk (Paul Johnson) Date: Sun Mar 30 14:53:38 2008 Subject: [Haskell-cafe] Announce: Decimal arithmetic package Message-ID: <47EFE28E.70701@cogito.org.uk> I